161–170 of 204 posts
Is there a way to make the lifetime of the key last more than a year?
Earlier quoted context omitted.
Yeah, that is why you should not [always (depends on your use case)] generate it on a YubiKey. You need to have: - an offline master private key backup (air-gapped) - primary YubiKey (daily use) - backup YubiKey (locked away) - revocation certificate (separate storage) (it is your kill-switch) Having a second YubiKey enrolled is the standard practice. What people do wrong is: - They generate directly on YubiKey - The…
Does OpenSSH's `sshd` even support GPG key revocation? (Assuming you're talking about using the GnuPG card application of Yubikeys, since the newer "native" FIDO security key implementation of OpenSSH does not support importing existing keys to my knowledge.)
Short answer is that it does not.
Earlier quoted context omitted.
> So the malware needs to trick you into performing the TouchID gesture. That's not meaningfully more difficult than tricking you into revealing your key file password. >Instead of on each sign operation. But from your video each sign operation also requires a touchid prompt?
> That's not meaningfully more difficult than tricking you into revealing your key file password. No, but that's meaningfully more difficult to do without an intervention from the user. Say your computer is infected, the malware won't silently do it: it will have to interact with you . And an important part is that you apparently don't have to make the key exportable: > So if that's in your threat model don't make th…
Earlier quoted context omitted.
Is there a way to import an existing (compatible) key and still mark it as non-exportable? That seems more useful for the SSH key scenario: Generate a key in memory and back it up to offline storage once, and otherwise only use it in a way totally non-exportable by any malware. This sentence > The exportable private key is encrypted with Elliptic Curve Encryption Standard Variable IVX963 algorithm which is backed by…
No. There is no way to import an existing key into the Secure Enclave. Only Apple is allowed to do that. The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption. This also means that passkeys on macOS/iOS are (at some point) exposed as clear text.
AFAIK this is what "secretive" was doing all the time.
Secretive is a bit friendlier to set up but I'll probably switch to this anyway so I have one less app on my computer. Plugging my blog post for how to achieve this on Windows 11: https://cedwards.xyz/tpm-backed-ssh-keys-on-windows-11/
Is storing ssh-key in tpm possible on Linux?
Does anybody know if there is something similar for gpg keys? E.g. for commit signing? That is, natively with the Secure Enclave, not exportable.
Git commits can be signed with ssh keys.
On Linux, GPG supports TPM2, but I'm not sure if that also works on macOS.
Fundamental services like DNS, which was designed as distributed going down was the cause last 2 outages and really need to think of alternatives methods to ensure resilience. Shift left, design better.
How can I get such a key into my iPhone too, so that I can sign emails and file and such with the same private key when I'm on my phone, and my public key is valid for all such operations ? Will iCloud take care of that ? And then I want it all usable from my (multiple) email clients...
Earlier quoted context omitted.
How can the "cartel" "blacklist" anyone? The only thing the FIDO alliance can do is not include a vendor's attestation key as trusted in their vendor database, and software solutions aren't on that list to begin with. > The fundamental flaw is that enrolling an authenticator requires it to be present [...] Yes, but that doesn't mean you can't backup the full authenticator state. Here's a toy WebAuthN implementation t…
> How can the "cartel" "blacklist" anyone? All they have to do is publish a "best practices" statement or some RP certification program mandating attestation to be used (and some PR around how only "certified" RPs are secure) and job done. The only reason they didn't do that yet is that Apple is refusing to play ball and support attestation (but this may change). The threat was clearly there in the original Github is…
Again, you don't inherently have to do this if you only use non-resident keys (which many sites allow; my hardware authenticator does not even support resident keys).
Synchronized resident keys are not the only possible WebAuthN implementation, even though they are getting currently heavily pushed by big stakeholders. The big advantage they come with, though, is that they lost hardware attestation in the process, so everybody is free to use their own implementation instead.
Thinking about it some more: I'm pretty sure that there are crypto wallets that support FIDO (or maybe just U2F, i.e. the predecessor of CTAP2?) as a secondary application, and they are almost always based on a passphrase you can back up and replicate across authenticators as you wish.
> Seems like a shit ton of complexity and effort to work around a problem OpenSSH elegantly solved 30 years ago.
There are very good reasons for requiring the private key at registration time and for mandatory per-site keys in WebAuthN/FIDO, which are arguably the two main differences between WebAuthN and SSH at a protocol level:
Global keys would be a privacy nightmare (as they would become global identifiers), and being able to register a public key without a private key risks both users accidentally registering a key they don't have access to (i.e. availability), and getting social engineered into registering somebody else's key that is not even physically present with them.
But again, per-site keys can absolutely be implemented without having to keep state on the authenticator, since they can be deterministically derived from a root secret.