[Muscle] Impossible to crypt using *buggy* MuscleTool
sferey
s.ferey at wanadoo.fr
Mon Mar 31 06:30:33 PDT 2008
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 <s.ferey at wanadoo.fr
> <mailto:s.ferey at wanadoo.fr>>:
>
> 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.
>
>
>
More information about the Muscle
mailing list