Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing APDUs for openpgp #167

Open
namelessmasses opened this issue Nov 27, 2024 · 0 comments
Open

Implementing APDUs for openpgp #167

namelessmasses opened this issue Nov 27, 2024 · 0 comments

Comments

@namelessmasses
Copy link

namelessmasses commented Nov 27, 2024

I'm currently working on implementing the APDUs for openpgp in a fork that I'll be happy to PR back upstream.

I've been working through documenting a few use-cases and have some questions based on the SW1/SW2 responses I've been seeing in contrast to the Functional Specification of the OpenPGP Application on ISO Smart Card Operating Systems v3.4.1 and ISO/IEC 7816-4.

I have been testing request-responses with a Yubikey 5Ci and a Yubikey 5 NFC both with firmware 5.4.3. Submitting raw APDUs via OpenSC and observing the responses. I'm observing some differences in contrast with the specification. I have everything documented in a fork.

Specific questions follow.

VERIFY

Respond with actual access status

The functional spec states in 7.2.2,

If the command is called with P1 = 00 and no data (Lc empty), then the actual access status of the addressed password in P2 is returned. If the password is still verified the cards answers with normal status bytes (SW1-SW2 = 9000). If the password is not checked and the verification is required, then the card answers with the status bytes 63CX, where 'X' encodes the number of further allowed retries.

I'm observing both Yubikeys respond 6A80 (Incorrect parameters in command data field).

See my documentation for specific command request APDUs.

Do Yubikeys support "respond with actual access status"? If so, then please help by providing details of the correct APDU format.

"Unverifying"

The functional spec states in 7.2.2,

If the command is called with P1 = FF, then Lc shall be empty (no data in the command data field). The addressed password in P2 is reset to the status 'not verified'. To use commands that are protected by this password, VERIFY with correct password data has to be called again.

I'm observing both Yubikeys respond 6A80 (Incorrect parameters in command data field).

See my documentation for specific command request APDUs.

Do Yubikeys support "unverifying" PW1/PW3? If so, then please help by providing details of the correct APDU format.

PSO:DECIPHER

The functional spec 7.2.11 PSO:DECIPHER has me a little confused. Perhaps Yubico can directly provide some clarity by sharing the exact format of both the data field of, and the response body to, INS=2A,P1=80,P2=86 that the Yubikey will expect and return.

Future PRs...

...for this, and other SDKs.

Again, I'd be happy to get this working and submit a PR. I also observe that neither [python-yubico](https://github.com/Yubico/python-yubico) nor [Yubico.NET.SDK](https://github.com/Yubico/Yubico.NET.SDK) have direct API support for the openpgp application. If I can get clarification on the above questions from Yubico, I'd be more than happy to implement the API support for iOS, .NET, and python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant