Open
Description
Hi! I am writing a PIV application for SoloKeys, and found some idiosyncrasies in this repository (which is named piv-go
and not yubico-piv-go
👼).
This is the start of the "handshake" when I run @FiloSottile's https://github.com/FiloSottile/yubikey-agent:
10055575 APDU: 00 A4 04 00 05 A0 00 00 03 08
00001734 SW: 61 11 4F 06 00 00 10 00 01 00 79 07 4F 05 A0 00 00 03 08 90 00
00001345 APDU: 00 FD 00 00 00
00004496 SW: 04 03 04 90 00
00000965 APDU: 00 A4 04 00 08 A0 00 00 05 27 20 01 01
00002205 SW: 04 03 04 01 05 00 05 0F 00 00 90 00
00000661 APDU: 00 01 10 00 00
00000929 SW: 00 52 F7 43 90 00
For one, you send instruction 0xFD
(getVersion) against the PIV app, I guess because Yubico implements it there. Secondly, instruction 0x01
is used, is this also an idiosyncrasy? As ISO 7816-4 does not contain it. I can "fake" responses here, but it would be neat if answering these commands for non-Yubikeys would not be mandatory.
Also, the "AID" in
Line 336 in 564f246
[0x00, 0x00, 0x10, 0x00]
or additionally its version [0x01, 0x00]
.Metadata
Metadata
Assignees
Labels
No labels
Activity
FiloSottile commentedon May 10, 2020
BTW, I know it's named
yubikey-agent
, but if feasible I'd be happy for it to also support SoloKeys!ericchiang commentedon May 10, 2020
Yep I'm not surprised this only works with YubiKeys since it's the only thing I've tested against. Much of the spec logic is ported directly from the ykpiv C codebase. That's also what's up with all the "YubiKey" structs :)
It'd be good to understand what changes we'd need to make to support other smart cards that implement PIV. Given that, if it's a larger change I likely won't have bandwidth to maintain it. For example I don't own a SoloKey.
If you send changes that don't expose new APIs and keep the YubiKey portions running, I'm happy to test and merge them. If you'd like to add new APIs (e.g. add a SoloKey type), I'd like to discuss that before taking PRs.