Aladdin eToken Pro 64k (regression?) - insecure keys and >1 User PIN configurations don't seem to work

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Aladdin eToken Pro 64k (regression?) - insecure keys and >1 User PIN configurations don't seem to work

Mike Kazantsev-2
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

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

sc_test.script.log.gz (5K) Download Attachment
sc_test.script.output_only.log.gz (3K) Download Attachment
sc_test.sh (7K) Download Attachment
signature.asc (205 bytes) Download Attachment