Hi Amanda,
Thanks for the clarification regarding PIN verification.
The applet is so bug-free for that sequence - the applet is NOT
responsible of the incorrect result.
The error is either due to muscle-tool application or to the card-module.
According my understanding, it's certainlyt the last, ie the card-module
since it's responsible of APDU building.
Are you using a downloaded binary or do you generate it yourself ?
If the later, you may want to try with an "official binary", if any.
Regards,
Sylvain.
Amanda Ortega a écrit :
Hi, Sylvain.
First of all, thank you for the analysis of the log!
Answering to your question about PIN verification, I verified the two
PINs (PIN #0 and PIN #1) before the sequence that I sent to this list.
How can I know what is wrong: applet or muscle-tool? I will try to
test this with another card, in order to see if is the card module
that is wrong...
Amanda
2008/3/27, Sylvain Ferey <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
At 12:57 21/03/2008 -0300, Amanda Ortega wrote:
>The sequence of APDUS obtained through pcscd -fda to the same
sequence of
>encrypt/decrypt is:
hereafter is the analysis of your log:
* List Keys, reset sequence & get first entry
> B0 3A 00 00 0B
< 00 03 FF 04 00 00 00 00 00 00 00
< 90 00
key Id: 00
key type: 03 : RSA CRT Private key
key partner: FF
key size: 0400 : 1024 bits
key ACL: 0000 0000 0000
* List Keys, get next entry
> B0 3A 01 00 0B
< 01 03 FF 04 00 FF FF 00 02 00 02
< 90 00
* List Keys, get next entry
key Id: 01
key type: 03 : RSA CRT Private key
key partner: FF
key size: 0400 : 1024 bits
key ACL: FFFF 0002 0002
* List Keys, get next entry
> B0 3A 01 00 0B
< 02 01 FF 04 00 00 00 00 00 00 00
< 90 00
key Id: 02
key type: 01 : RSA Public key
key partner: FF
key size: 0400 : 1024 bits
key ACL: 0000 0000 0000
* List Keys, get next entry
> B0 3A 01 00 0B
< 03 01 FF 04 00 00 02 00 02 00 00
< 90 00
key Id: 03
key type: 01 : RSA Public key
key partner: FF
key size: 0400 : 1024 bits
key ACL: FFFF 0002 0002
note: "key partner" would be set since generation was certainly
performed
on card, but it is undefined.
we can assume that:
- keys '00' & '02' are the first unprotected key-pair
- keys '01' & '03' are the 2nd PIN-protected key-pair
* ComputeCrypt, init cipher
> B0 36 03 01 05 00 03 01 00 00
< 90 00
uses Public Key '03' (P1 = 03')
cipher_mode: 00 the value '01' is documented for RSA_X509,
according
the source code, the value '00' shall
indeed be used.
cipher_dir.: 03 "data encrypt" (fine)
data_location: 01 optional init data are in the APDU
data_length: 0000 no init data
Enter text :
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
30303030303030303030303030303030
* ComputeCrypt, process cipher
> B0 36 03 03 83
uses Public Key '03' (P1 = 03')
data field:
data_location: 01 data are in the APDU
data_length: 0080 length of data (to be encrypted)
data:
01 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30
here the first byte is invalid.
the muscle-tool is buggy and does not transmit the right data.
< 61 82 (response is 130 bytes long)
* Get Response
> 00 C0 00 00 82
<
response_length: 0080 (useless field, the terminal does know
the length of data it's just receiving)
response_data_field: (the wrapped text)
50 E1 01 65 72 3A DF 21 48 5A C8 0E 09 24 59 0C
FB 13 A5 79 9D BF 60 32 9B 1E D7 DD F3 DA B4 DF
F0 02 BB 9A B4 B7 09 B0 64 62 9E 67 9E D1 65 A8
9D 61 B2 CD 8F 81 25 CF AC 88 4F 73 66 22 0F 5C
92 AF E4 42 80 4F 39 D3 9E A5 97 06 A4 45 D6 8B
97 37 65 3C 2E 2E 5C E2 B0 BC F6 1B 75 F6 D1 AF
0D 9A 44 C3 A2 61 27 D8 9F 96 F8 60 43 D0 8E 79
B4 5D FA F8 00 C9 6D FB F6 55 F7 68 63 EA 31 E1
< 90 00
* List Keys, reset sequence & get first entry
> B0 3A 00 00 0B
< 00 03 FF 04 00 00 00 00 00 00 00
< 90 00
key Id: 00
key type: 03 : RSA CRT Private key
key partner: FF
key size: 0400 : 1024 bits
key ACL: 0000 0000 0000
* List Keys, get next entry
> B0 3A 01 00 0B
< 01 03 FF 04 00 FF FF 00 02 00 02
< 90 00
key Id: 01
key type: 03 : RSA CRT Private key
key partner: FF
key size: 0400 : 1024 bits
key ACL: FFFF 0002 0002
* ComputeCrypt, init cipher
> B0 36 01 01 05 00 04 01 00 00
< 90 00
uses RSA CRT Private Key '01' (P1 = 01')
cipher_mode: 00 the value '01' is documented for RSA_X509,
according
the source code, the value '00' shall
indeed be used.
cipher_dir.: 04 "data decrypt" (fine)
data_location: 01 optional init data are in the APDU
data_length: 0000 no init data
the USE ACL of key '01' is '0002' so PIN #2 (1 based), no Verify
PIN was
performed in this part of script but a Verify may have been issued
some
(long?) time ago and no card reset has been issued - to be confirmed.
Enter text :
50E10165723ADF21485AC80E0924590C
FB13A5799DBF60329B1ED7DDF3DAB4DF
F002BB9AB4B709B064629E679ED165A8
9D61B2CD8F8125CFAC884F7366220F5C
92AFE442804F39D39EA59706A445D68B
9737653C2E2E5CE2B0BCF61B75F6D1AF
0D9A44C3A26127D89F96F86043D08E79
B45DFAF800C96DFBF655F76863EA31E1
* ComputeCrypt, process cipher
> B0 36 01 03 83
uses Private Key '01' (P1 = 01')
data field:
data_location: 01 data are in the APDU
data_length: 0080 length of data (to be encrypted)
data:
01
50 E1 01 65 72 3A DF 21 48 5A C8 0E 09 24 59 0C
FB 13 A5 79 9D BF 60 32 9B 1E D7 DD F3 DA B4 DF
F0 02 BB 9A B4 B7 09 B0 64 62 9E 67 9E D1 65 A8
9D 61 B2 CD 8F 81 25 CF AC 88 4F 73 66 22 0F 5C
92 AF E4 42 80 4F 39 D3 9E A5 97 06 A4 45 D6 8B
97 37 65 3C 2E 2E 5C E2 B0 BC F6 1B 75 F6 D1 AF
0D 9A 44 C3 A2 61 27 D8 9F 96 F8 60 43 D0 8E 79
B4 5D FA F8 00 C9 6D FB F6 55 F7 68 63 EA 31
< 61 82
only the first 127 bytes of the given data are transmitted.
a leading byte '01' is inserted and replace the last byte
of the ciphertext - same bug of muscle-tool that does not
transmit the right data.
* Get Response
> 00 C0 00 00 82
< 00 80
37 03 01 22 C1 35 C7 BD F9 B4 3D A9 16 B8 B5 99
33 E5 74 1D 38 FE 9E 9C 87 84 16 C2 6A 14 B3 81
1D 8A 54 42 12 8F AB 0D 4D 1D 31 72 56 0B 52 1A
F0 95 C8 D7 31 FA FA 8F 7E 02 D7 4A 35 C9 F6 9F
57 90 94 2A E8 BE BA 4E 46 17 40 02 79 24 A8 F8
D6 C4 97 8A C3 94 C9 5A E6 91 77 1D 92 28 83 A7
F6 F6 A9 F3 91 3F 7F 4E 32 99 73 F9 7D B2 9A 74
B9 1D B2 F2 44 FB 2A 03 78 F9 2C 22 FC 18 92 BF
< 90 00
that's a signature of 01 50 E1 ... EA 31, not the unwrapping
of the first given plain text.
conclusions:
- either you did transmit the PIN in a previously (not provided)
sequence or the applet is buggy and fail to verify ACL.
- the muscle-tool (itself or the card module you used) is buggy.
the '01' inserted at the beginning of msg may let one thinks that
the tool performs a PKCS#1 padding of the data but if so it shall
insert a '02' for public key encryption, it can also be an echo of
the menu choice figure, but if so why it is not present at the
beginning of the data field (instead of beginning of the plain /
cipher
text). I did not check the muscle-tool source files to learn more.
Sylvain.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
