search

Yubico / yubico-piv-tool

Command line tool for the YubiKey PIV application
https://developers.yubico.com/yubico-piv-tool
BSD 2-Clause "Simplified" License
300 stars 99 forks source link

What is the key expected key format for x25519 key import and diffie-hellman? #503

Closed gaetan-sbt closed 3 months ago

gaetan-sbt commented 3 months ago

I have imported a x25519 into a Yubikey 5 series, and I'm using it to perform a diffie-hellman between the private key loaded in the yubikey and a public key.

Unfortunately, the output of the diffie-hellman I'm getting back from the yubikey is different from what I'm expecting.

One hypothesis I'm trying to verify is whether I'm using a different key format from what Yubikey expects.

What format is the yubikey expecting for:

I haven't been able to find that information in publicly available docs. It mentions seed, but does not provide more information about what it does with it (mutlitply it with the base point) or how that seed is formatted.

gaetan-sbt commented 3 months ago

Interistingly, whatever the input value I give for the import function, I get the same public key in return.

gaetan-sbt commented 3 months ago

Closing. Probably better to bring this up with ykman.

aveenismail commented 3 months ago

I know the issue is closed but I thought I'd point out to this documentation: https://developers.yubico.com/yubico-piv-tool/Actions/key_import.html

If this isn't resolved yet, was the key import successful? And the certificate? What command did you use to perform these operation?

gaetan-sbt commented 3 months ago

Thanks for the pointer!

I resolved the issue on my side. I wasn't using yubico-piv-tool but a local fork of yubikey.rs to construct the APDU. My fork added support for X25519, but I couldn't find the ADPU specification for it. I found the bug in my fork of yubikey.rs by comparing with the yubikey-manager source code.

Essentially, when I construct the APDU for importing an X25519, I used the correct algorithm ID (0xE1), but the wrong parameter tag (0x7 instead of 0x8) which corresponds to ED25519. When doing so, the yubikey successfully generates a key, but they key is fixed to some value, and it doesn't change depending on what seed I give it, which made me think there was a firmware bug.

So the bug was with my code, but it's a bit of a surprising behaviour by the firmware on invalid input (an error would have been more helpful).