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]>: > > 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
