On passphrase protected key files

[Filippo Valsorda]

I've been trying to find a threat model that justifies first-class
support for passphrase protected key files (and hence an agent), and I
am not finding any.

If an attacker has local access to your machine, the reality of today's
platforms is that you lost. They will install a keylogger, or read the
agent memory, or replace the agent binary and wait.

If an attacker has a separate account on your system, you should trust
your OS to honor file permissions as well as it protects your account
from running the attacker's code.

If an attacker has cold access to your drive or file system, there's
full disk encryption or FileVault sparseimages or ZFS encrypted mounts
or gocryptfs or TrueCrypt or [insert your favorite].

If an attacker obtains a remote file disclosure vulnerability that
somehow (!?) doesn't pivot into remote code execution... ok I guess with
passphrases it doesn't get your keys, but it gets all your emails from
the browser cache, so...

This train of thought started with "age needs to work as a
password-store backend", but in fact I don't see any reason to use an
encrypted gpg key with pass. Honestly, if you aren't uploading the
password repository to an untrusted remote, I don't even see the need
for encryption in pass.

(Completely different story for hardware backed keys with
touch-to-operate, which throttle exfiltration at one secret per tap, and
provide recoverability. I think age should focus on making those as easy
as possible to use.)

Am I missing a convincing use case for encrypted key files? At this
point I am extremely tempted to say "if you really want them, use SSH
keys, and no you don't get an agent".

[David Collantes]

How about keys stored/used in a shared environment in which other regular users do not have access to your user space, but administration do?

Eventually age will too use SSH keys to encrypt/decrypt, yes? So, I can password protect an SSH key in that case, so the question be, would a password protected age key be smaller than its SSH counterpart?

[K. York]

I think the primary thing these protect against is cold file reads.

Arbitrary file read while the computer is running will usually get you an auth token that lets you run code, yes, but those tokens are useless when the computer's off.

I know of at least one current CS lab environment where everyone's home directory is on NFS and, unfortunately, NFS trusts the MacOS computer to correctly declare who's accessing the file. This has broken several times.

So here we have a case where the attacker can read $HOME, which is the only reliable storage location, and cannot access the rest of the filesystem - those tokens tend to live in volatile locations.

The OS X keychain protects the browser history and cookies, with similar mechanisms used on Windows (CryptProtectData) and on Linux desktops (keychain), which means this style of attack does not actually spell disaster for the web history of the students under the cold arbitrary file read attack.

This points to providing platform protection for key files, with unencrypted for when platform data confidentiality is assured or for key transfer.

[K. York]

Additionally, after discussions with people having more dire threat models than mine – in particular, "police throw your laptop in an evidence bag & attach a debugger to the RAM" – FDE keys would be the first thing extracted, so FDE should not be considered a functional fix for "I read the private key file off the disk".

A laptop thief, who has waited until the machine was in use, can pull the classic 'carry with arm stuck through your Mac to prevent sleep' and then just... use your keys. (I believe this featured in one of the Halloween threads.) Agents do not fix this - only keeping the key unusable until unlocked with knowledge does.

I'm sure you were already planning that an encrypted mount should throw the asymmetric keys and preserve only the file key in memory.

The principle here would be "key material should not be extant when not in use"; a file encryption tool's keys spend a lot of time not in use. Therefore the keys should not be accessible without an affirmative step to access them, such as entering a password or performing a tap.

[Jack Grigg]

On Sat, Nov 30, 2019 at 1:13 AM K. York <kane...@gmail.com> wrote:

Additionally, after discussions with people having more dire threat models than mine – in particular, "police throw your laptop in an evidence bag & attach a debugger to the RAM" – FDE keys would be the first thing extracted, so FDE should not be considered a functional fix for "I read the private key file off the disk".

A laptop thief, who has waited until the machine was in use, can pull the classic 'carry with arm stuck through your Mac to prevent sleep' and then just... use your keys. (I believe this featured in one of the Halloween threads.)

These are an interesting subset of Filippo's local adversary: one that gains local access to the machine but does *not* gain persistent concurrent access alongside the user (either because the user won't trust the device after it is returned, or the device was outright stolen).

 

Agents do not fix this - only keeping the key unusable until unlocked with knowledge does.

Agreed. I use passphrases on my SSH keys with an agent - that I almost always log into on boot, meaning that the only adversary I'm defending against is myself accidentally backing the key up somewhere without encrypting it first.

 

I'm sure you were already planning that an encrypted mount should throw the asymmetric keys and preserve only the file key in memory.

This can be built into the library design, and benefit all use-cases. In rage, for instance, an encrypted OpenSSH key is only decrypted within the specific context of unwrapping a file key (and the decrypted SecretKey is zeroized when the local is dropped at the end of the scope):

https://github.com/str4d/rage/blob/e27f56b0b6a83a00d4535fe80906331ed9ee1263/src/keys.rs#L174-L182

The principle here would be "key material should not be extant when not in use"; a file encryption tool's keys spend a lot of time not in use. Therefore the keys should not be accessible without an affirmative step to access them, such as entering a password or performing a tap.

I don't entirely agree; I think there are valid threat models where having the file encryption key always accessible on-disk is perfectly acceptable. I *do* agree that if you are setting a passphrase on a file encryption key, you should require that affirmative step. I'm currently of the opinion that if your threat model requires having the key itself passphrase-protected (rather than relying on FDE), you shouldn't be using an agent.

Then again, maybe there is a sufficient user base with a threat model like mine (defending against accidental rather than malicious disclosure) that the UX convenience of an agent is worthwhile? I guess it depends on how frequently people are needing to decrypt files - not often enough that it can be done in bulk (which could instead be served by a specific multi-file-decryption tool), but often enough that repeatedly typing the passphrase is a pain point. Anyone know of existing UX research in this area?

I suspect that if we can make the hardware-backed key UX really smooth, we could probably direct most passphrase-requiring use cases towards that instead. And if the remaining use cases aren't very numerous, then encrypted OpenSSH keys might be sufficient.

[Jack Grigg]

Adding some related comments from the Twitter thread (https://twitter.com/SwiftOnSecurity/status/1200706553038417920):

> In banking PGP workflows (which I’ve built) they traditionally like a workflow password not just logical access. It could help adoption even if you don’t see much absolute security value. Also, harder for data scrapers to pull from HDD. Important.

> Think about all the malware that pulls all FTP/web/email credentials on disk. They could install a keylogger but they don’t because they’re looking for fast wins.