yubikey 5.7.x firmware uses an aes192 default management key instead of 3des

[smferris]

ykAuthenticate() hardcodes alg3DES for the piv management key, but newer yubkeys that have 5.7.x firmware are now defaulting to an aes192 key.

I suspect this default key change is why yubikey-agent (which uses piv-go) is unable to setup the yubikey, and errors out with:

‼️ The default Management Key did not work

[smferris]

I created a TDES key using the default byte pattern using the ykman GUI, and then everything worked as expected, so that's the workaround for now, but this will be a pain point as the number of new yubikeys in the field grows.

Would it make sense to try AES192 if TDES fails and the key is the default value, or vice versa? Giving the caller some way to specify the key type would also help, so that it could at least be plumbed down from a command line argument.

[smlx]

I think logic could be added using this knowledge:

• from v5.3 there is the KeyInfo extension that supports key metadata and was recently implemented for piv-go.
• from v5.4.2 AES-192 is available as a management key type (default in v5.7).

So therefore by inspecting the key version you could do this in SetManagementKey:

• if version < 5.4.2, assume 3DES management key type for both ykAuthenticate and ykSetManagementKey.
• if version >= 5.4.2
  • use the KeyInfo API to inspect the management key type to use in ykAuthenticate
  • default to AES-192 for ykSetManagementKey

Does that make sense?

[smferris]

Makes sense to me, and I'd certainly prefer a solution that autodetected the key type so that it works with all firmware versions, and newer firmware can use aes-192 rather than get downgraded to 3des.

[Quantu]

I've got a working solution that determines the current key type from the slot metadata if available, else assumes 3DES. It also allows setting the management key to different key types (determining which key type to set based on whether you pass in a 16, 24, or 36 byte key. For 24 byte keys it tries AES192 first and falls back to 3DES).

#149

[ericchiang]

This should be fixed on the v2 branch, but I want to make sure there's some agreement that we don't need to change any other APIs before tagging (#153). Is #149 sufficient to fix this issue?

[Quantu]

I believe #149 is sufficient. I have verified it working with yubikeys that only support 3DES, support AES+3DES but default to 3DES, and support AES+3DES but default to AES192. I have also verified it working for all three AES key lengths in the standard (128/192/256).

Also, fixing this issue also fixes #109

[ericchiang]

The v2 version now supports different management keys. Switching to that should be sufficient?