arekinath
commented
3 years ago The output you've pasted there does not match what you wrote above. You wrote:
//send private public key pair
0047009a05ac0380010700
-->card responded: 7C 0A 82 08 90 02 37 FE A0 94 5C 60 90 00But in the command output you pasted:
>opensc-tool -v -s 00:47:00:9a:05:ac:03:80:01:07
Received (SW1=0x90, SW2=0x00):
7F 49 82 01 09 81 82 01 00 .I.......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.
ble0
dengert
asalkhanbadr
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?