nuvious
commented
3 years ago I agree with your concern, but I would classify it as a low probability attack vector and thus adding digital signatures is a lower priority (but still a priority) implementation. I classify it as low probability because I think the most realistic scenario for this would be if an attacker got their hands on a backup of a user's home directory or access to it in some read-only fashion. This could allow them to get the hash and attack it as described. At that point if the duress script is fine to run on its own they could simply run it by attempting login with the duress password; say for a DOS attack scenario. However if they wanted to modify the script to their end they would need a user session at which point they could potentially re-generate a key and resign everything after modification.
Despite it being low probability of attack I do plan on implementing digital signatures via openssl or PGP as an optional feature but just have to figure out a good convention to keep it as cross platform as possible across all POSIX systems. The implementation would require that the system have a repository of trusted public keys associated with private keys used for signing duress scripts and/or one master key used to sign all scripts. Best practice in this instance would also recommend the private key used for signing be stored on a different system or offline entirely which is reasonable to assume as achievable for someone looking for this extra added layer of security. In the short term that will have me focusing on the crypt implementation since that will still be needed even if digital signatures are added to associate scripts with passwords and store them according to standard conventions. Overall though if we're worried about someone using an easily guessable password, I'd be worried just as much about them misconfiguring sudo, keeping their private key in their home directory, etc.
Despite my assessment though it would add some extra layer of integrity assurance even if it's marginal so it's in the development pipeline, just not in the near future.
Regardless thanks for your input! I'm more than willing to keep the discussion open to refine the target implementation for digital signing.
lifehome
Hi there,
I think there are chances that a duress password could be the utmost simple one, which means it could be a dictionary word or easily being brute force and guessed it out. An adversary could also use PII or related information from the victim, to potentially guess what is the password(either the correct one or the duress code).
SHA256 is great, and it does the job on checksum, but not when it comes to the case that we should also protect the duress script itself.
I suggest introducing an option to add cryptographically signed duress script, ideally would be PGP signed, on top of the sha256 hashed script. So that the user can always know if the file has been tampered with, and failover to the sha256 hashed script if the validation failed.
Regards, Ivan