-
Notifications
You must be signed in to change notification settings - Fork 37
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
Sending raw apdu commands to generate private-public key pair RSA2048 #51
Comments
The output you've pasted there does not match what you wrote above. You wrote:
But in the command output you pasted:
The "7C .." response looks like it was to your general authenticate command, not the generate asymmetric key command. This response to the generate asymmetric key command looks correct (7F 49 .. with an 81 inside that's 0x100 long), but truncated -- I suspect because you sent a case 3 command APDU (with no Le byte) when you need a case 4, and either the card or your reader has cut the rest of the response off as a result. Is this a T=0 card? I would try adding the extra Le byte (set to zero) at the end of your generate asymmetric command APDU, to turn it into case 4 format. |
Hi, |
From you output, you are running multiple opensc-tools each with its own "-s" option. |
You could also try the OpenSC |
i will try the |
I am interested in understanding what problems where you having with |
Hi, , I am facing the same issue. I am sending plain APDU requests to a smart card (java card 3), but I am not sure how to retrieve the public key. I would appreciate any help on this matter. |
@asalkhanbadr What tool are you using to send the APDU? Looks like the reader, applet or java card 3 has a problem returning a response to the "47" command with more the 256 bytes. The command looks like using short APDU. 7F 49 82 01 09 81 82 01 00 looks like the start of a correct response with tag 74 49 and length 265 with "Modulus" of length 256. Not shown is the "Modules" or "Public exponent" length 3 with 1 byte tag(82) and 1 byte length (03) (If I did the math correctly.) What it should have returned using T=0 would be would "61 00" then get response for 256 would have returned "61 14" then do second get response. If using T=1, the first command should have returned 256 bytes data and status "61 0E" and get response for 14 bytes to read the rest retuning 90 00. Why the first status "61 09" does not make sense. Try Send: 00 C0 00 00 00 and see if it responses with 256 bytes and status "61 14" You could try using extended APDU something like" 00 47 00 9C 00 00 05 AC 03 80 01 07 00 00 |
Hi @dengert , thank you for your response, the Java card is a physical card and the reader/writer is HID OMNI 3111. According to the data sheet, it supports 115 kb/s data transmission. The protocol supported both by card and reader is T=0. Additionally, I have been using PyApduTool to send APDU commands. Send: 00 47 00 9C 00 00 05 AC 03 80 01 07 00 00 |
Where is the data sheet? What system are you using? Best I can tell HID OMNI 3111 is a serial port, not USB, device from a few years ago. Most smartcard readers today are USB CCID compliant. Can you try and force T=1? The only PIV cards I have seen that use T=0 are 20 years old. The Applet may only support T=1. |
I attach the datasheet so that you can download it. I use a serial to USB port converter to connect the reader to the computer using USB ports. Also, I tried forcing T=1, but every time I got the error message: 'Connect error: The requested protocols are incompatible with the protocol currently in use with the smart card. omnikey_3111.pdf |
Get a different reader. A USB CCID compliant reader. |
I tried to use the same commands as yubico-piv-tool to generate private public key pair:
//select applet
00a4040005a00000030800
00fd000000
00f8000000
//Request for encrypted challenge
0087039b047c028000
-->card provides encrypted challenge to tag 80
//Decrypt encrypted challenge from card in tag 80 while tag 81 is a random number
0087039b167c148008325F7E0D2323C75281080592bbb05e1a58d6
-->card provides encrypted challenge of tag 81
//send private public key pair
0047009a05ac0380010700
-->card responded: 7C 0A 82 08 90 02 37 FE A0 94 5C 60 90 00
Im expecting at the last apdu, public certificate using 2 get response but the card does not output anything.
It just ended with SW 9000 and it should be 61XX.
I do not see any special commands that yubico-piv-tool is sending
Is it because tag 81 has a calculation how to generate a random number that's causing this? or is there a timing involved in key generation that must be satisfied? or is it because opensc-tool has a bug?
The text was updated successfully, but these errors were encountered: