At 12:28 08/03/2008 -0300, you wrote:
I have created two pairs of keys:
- Putting 0x0000 for all the ACLs (private key 0 and public key 2);
- Putting the ACLs recommended by muscleTools when creating the keys
(private key 1 and public key 3).
When I try to crypt using the first pair, I can't do anything. But when I
try to crypt using the second pair, I can crypt and decrypt, but the
result at the end isn't equal to the beginning.
all replies assume that you are using applet 0.9.8 and the code available at
<http://www.linuxnet.com/musclecard/files/mcardapplet-0.9.8-GXPRAD.tgz>
and btw, I hope I will no hurt someone but who manages that applet ?
is that code packaged in "com.sun.javacard.samples.CardEdge"
the right one? (sun & samples look both strange!)
the tarball also contains some classes with same package name under a
GemXpressoRADIII directory but these files have null length, does it mean
G+ provided a not redistributive implementation ?
my concern is that the found code looks like 2.0 sources, has lack of tests
and quite poor implementation (slow and EEPROM destructive).
I created the keys using the scheme that the public key number is always 2
units greater then the private key, is it OK?
both ids shall be unique (not used twice) and in range 0 .. 7
no relationship exists between them.
Where can I obtain a documentation about the meaning of the ACLs?
apparently nowhere.
the ACL array define a set of conditions to be fulfilled for various
operations,
one byte per operation.
an operation is possible (or, an ACL is granted) if all bits of that ACL
set to '1'
are also equal to '1' in a global security status.
the "global security status" placeholder is the variable logged_ids defined
as a short (int16) while only the lower 8 bits are used.
the way to define specific conditions for ACL is to verify PIN(s),
the verification of a PIN with Id /i/ turns to '1' the bit /i/ of the
security status.
so, if you define that the signature condition for your private key
(meaning the 3rd int16 given as ACL during key generation) is '0004'
you must verify the PIN Id 2 before using that key.
(PIN Id 0 sets bit 0, Id 1 sets bit 1 and so on).
you can also define something like ACL(use) = '0003' to enforce
verification of PINs Id 0 AND 1 to be done to allow use of a key.
1)
$ muscleTool
MuscleCard shell - type "help" for help.
muscleTool > tokens
1. MuscleCard Applet
ListTokens Success.
muscleTool > connect 1
Connect Success.
2)
muscleTool [MuscleCard Applet] > listkeys
Key Type Key Num SIZE READ WRT USE
--------------- ------- ----
RSA PRIVATE CRT 0 1024 ALW ALW ALW
RSA PRIVATE CRT 1 1024 NEV Pin1 Pin1
RSA PUBLIC 2 1024 ALW ALW ALW
RSA PUBLIC 3 1024 Pin1 Pin1 ALW
3)
muscleTool [MuscleCard Applet] > verify 1
so you can write/use priv key 1, read/write pub key 3
muscleTool [MuscleCard Applet] > crypt 3
I guess this should mean: use the key Id 3 for what is supposed to
(ie data encipherment or signature verification)
0. Abort this selection.
1. Verify
2. Encrypt
Choose (0-2): 2
inputted data will be encrypted.
Please enter text to encrypt in hexadecimal ASCII (at most 1023 characters)
statement is invalid.
the key's length is 1024 bits, 128 bytes.
for verification, the input shall be 128 bytes.
for encryption, longest input text is 128 characters if RAW mode
(no padding) is used. it's only 117 bytes if PKCS#1 padding is used.
Enter text : 3031
Select the algorithm:
0. Abort this selection.
1. RSA with no padding
2. RSA with PKCS#1 padding
Choose (0-2): 1
ok, so wrap the data with "no padding".
the application should (shall!) throw an error since you provide
2 bytes where 128 are expected.
instead some hazardous and hard to read things happen.
my understanding is that a modular exponentiation (encryption)
is done over either 3031 00....(x126)....00 or a buffer fully
filled-in with 00s (or noise).
at that point an APDU reference of the CardEdge applet will
definitively help I didn't find it, at least in the applet tarball.
Result :
77018EBFF08214E606BD4D6BBE341007F69AF6A32675A9ED8394658491D2578BA2B7044C0CE18FC1770E044D93E61C572FB62B3E0EB8D4CCA92872055A2AB39E93C5E1E9109D6A9AC979ACF9A79CCD97E50D9DB3C8DF1733F0F4C9A29A1C9C1324ECA5F31E710C7DF58149F5F94861B2960CF6BEDAE151FC8CE17B064BE547F7
it will be usefull to check that ciphertext.
a log with a dump of the key is required.
Crypt Successful.
muscleTool [MuscleCard Applet] > crypt 1
1. Sign
2. Decrypt
Choose (0-2): 2
it's the right option
Please enter text to decrypt in hexadecimal ASCII (at most 1023 characters)
same as above
longest input length for signature generation is 128 (X509, ie RAW mode)
117 bytes for PKCS#1, and it should not be longer than 56 bytes for
a safe system.
Enter text :
77018EBFF08214E606BD4D6BBE341007F69AF6A32675A9ED8394658491D2578BA2B7044C0CE18FC1770E044D93E61C572FB62B3E0EB8D4CCA92872055A2AB39E93C5E1E9109D6A9AC979ACF9A79CCD97E50D9DB3C8DF1733F0F4C9A29A1C9C1324ECA5F31E710C7DF58149F5F94861B2960CF6BEDAE151FC8CE17B064BE547F7
Select the algorithm:
1. RSA with no padding
2. RSA with PKCS#1 padding
Choose (0-2): 1
Result :
7BAE4A30262F2110522759135CF5581BB818F8A44080ABCA4DEF7398535C13213F8668AB442D6FDC18B270C7881F23DCAC1F78415C455441F114A36F12C59F0411A2054E06FB393585B5214160CC7EA2DAED3CD4DCA93634C1D402B0AC22206B06BAA82036539489D79194B81C37EC7496D5AC68B984DEF5ED0FFC2FFBB1D8C8
private key components are required to check if the exponentiation is correct
(we may think it is correct since no misalignment of data occurs (only useless
EEPROM copies))
can you generate a new log with:
a) the transmitted APDU (don't know if the tool does that)
b) the reading of the components of the keys
Sylvain.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
