Hi,
Summary: either I'm doing something wrong or with current (and more generally >0.12.0) OpenSC, Aladdin eToken Pro 64k devices seem to work only with a single User PIN and secure keys. I have a bunch of Aladdin eToken Pro 64k USB tokens and have been using one of them with OpenSC for a few years now. My use-case settled on generally having one "secure" key with PIN and one "convenience" key with no PIN, used as a second factor where no authentication would've been used otherwise. Unfortunately, it looks like I've locked it down yesterday, entering too many PUK's for User PIN in a row (and I think I forgot the PUK). (btw, I do remember SO PIN/PUK and they seem to work, am I correct in the assumption that User PIN and related keys can't be recovered from it with this token?) Creating simiilar configuration with OpenSC 0.13.0 (and 0.12.2, though due to different known issue, where OpenSC fails to query PINs from non-pinpad) proved to be quite impossible - insecure keys don't seem to work when created (I think I've created previous one with 0.11.x). I can accept (though with much regret) that it's expected behavior now, but wanted to confirm, especially since current toolkit operation doesn't look right. It's possible to work around the limitation, using second PIN with static insecure password, but unfortunately it doesn't seem to work anymore either. I wrote a simple bash script (attached as "sc_test.sh", https://raw.github.com/gist/4258342/ ), testing different permutations, fully formatting and erasing token between these ops, following seem to be the most relevant: 1. Init token with default profile and SO PIN. 2. Add User PIN. 3. Generate "secure" RSA key on-card, protected by User PIN. 4. Generate "insecure" RSA key on-card. 5. Decrypt using "insecure" key fails with the following: "Decrypt failed: Security status not satisfied" Workaround-way: 1. Init token with default profile and SO PIN. 2. Add User-1 PIN. 3. Generate "secure" RSA key on-card, protected by User-1 PIN. 4. Add User-2 PIN. 5. Generate "secure" RSA key on-card, protected by User-2 PIN. And here I don't understand what happens: % pkcs15-init -G rsa/2048 --public-key-label key2 -u decrypt -a 02 Using reader with a card: Aladdin eToken PRO 64k User PIN [user1] required. Please enter User PIN [user1]: Security officer PIN [Security Officer PIN] required. Please enter Security officer PIN [Security Officer PIN]: Why ask for PIN of user1, if it's in the first slot and I specifically asked it for a second (which I've just created in step 4): PIN [user1] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x3A], local, unblock-disabled, initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0x00 Reference : 3 (0x03) Type : ascii-numeric Path : 3f005015 PIN [user2] Object Flags : [0x3], private, modifiable ID : 02 Flags : [0x3A], local, unblock-disabled, initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0x00 Reference : 5 (0x05) Type : ascii-numeric Path : 3f005015 Private RSA Key [Private Key] Object Flags : [0x3], private, modifiable Usage : [0x22], decrypt, unwrap Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 16 (0x10) Native : yes Path : 3f005015 Auth ID : 01 ID : 942340b4ccd22a44561c9d951c67ff22d81b596d GUID : {2756f23b-ea95-9daf-04dd-bfbbaeb21fb2} Private RSA Key [Private Key] Object Flags : [0x3], private, modifiable Usage : [0x22], decrypt, unwrap Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref : 17 (0x11) Native : yes Path : 3f005015 Auth ID : 02 ID : 70a81d1d8a0ba70b6b352f9171a9b282d41be24c GUID : {9c42953c-32c4-703f-db7c-29083f4c7f90} Why it didn't even ask for PIN of user2, whose key it should be (last one above)? 6. Trying to decrypt with User-2 key yields the same as with insecure ones: "Decrypt failed: Security status not satisfied" 7. Key, generated for User-1 works. I'm far from an expert on such devices, but the step 5 above seem very counter-intuitive and I'm inclined to think it's some kind of a bug or maybe broken hardware, so any input on what happens there is much appreciated. I've also tired insecure keys with onepin profile (and different token) to the same effect. Hopefully I'm doing something wrong there, otherwise I can submit a bugreport, if such behavior is unexpected. Versions involved: opensc 0.13.0 [gcc 4.7.2] Enabled features: zlib readline openssl openct OpenCT 0.6.20 I've also tried OpenSC 0.12.0, with no luck. OpenSC 0.11.x doesn't seem to build here anymore due to some dep-issues, though I didn't look into the matter thoroughly. I recall there was --split-keys option for the CardOS, but keys just for "decrypt" doesn't seem to work in the scenarios described above either. Full logs of the script run (executed commands + output and only output with "set -x" stuff grepped-out) along with the script itself are attached. OpenSC / OpenCT logs with debug enabled seem to be relatively large for the list (~600 KiB gzipped), so I've uploaded these here (shouldn't require sign-in): https://docs.google.com/open?id=0B0lOZ5LbHGZzOU9DaU9DcDh2X1U https://docs.google.com/open?id=0B0lOZ5LbHGZzRkdDczQtUGlpR00 If any other potentially-useful data can be collected, I'll be happy to collect/attach it as well, even if it won't lead to anything. Also, as I have several more of these tokens (which I'm pretty sure I shouldn't miss), I'll be happy to send a few out for testing/debugging, if the problem is worth looking into. Thanks in advance for any advice on the matter. -- Mike Kazantsev // fraggod.net
sc_test.script.log.gz
Description: GNU Zip compressed data
sc_test.script.output_only.log.gz
Description: GNU Zip compressed data
sc_test.sh
Description: application/shellscript
signature.asc
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
