OpenSC › Developer

Re: Creating data object not supported in opensc's PKCS#11?

Classic

List

Threaded

6 messages Options

Geoffrey Elgey

Re: Creating data object not supported in opensc's PKCS#11?

G'day,

Stef Hoeben wrote:
> guess the data object is in slot 5 or 6 instead of slot 4. The reason
> has to do with pkcs11 'virtual slots'[1] in which the stuff in a
> virtual slot corresponds to one PIN. And because the data object you
> made isn't pin-protected, it ends up in one o the next virtual slots.

Okay, I managed to get some spare time to look at writing data objects
using the opensc-pkcs11 library, and with the small patch mentioned
previously. It seems that data objects are created, but I need to view
them using a different slot to the one used when creating the data objects.

Here's a session using a Cryptoflex 32K card. First I initialize the
card and look at the slots:

$ pkcs15-init --erase-card -T
$ pkcs15-init --create-pkcs15 -T
New Security Officer PIN (Optional - press return for no PIN).
Please enter Security Officer PIN:
$ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so --list-slots
Available slots:
Slot 0 SCR 331 00 00
token label: OpenSC Card
token manuf: OpenSC Project
token model: PKCS #15 SCard
token flags: token initialized
serial num : 000088BAFFFF0200
Slot 1 SCR 331 00 00
token label: OpenSC Card
token manuf: OpenSC Project
token model: PKCS #15 SCard
token flags: token initialized
serial num : 000088BAFFFF0200
Slot 2 SCR 331 00 00
token label: OpenSC Card
token manuf: OpenSC Project
token model: PKCS #15 SCard
token flags: token initialized
serial num : 000088BAFFFF0200
Slot 3 SCR 331 00 00
token label: OpenSC Card
token manuf: OpenSC Project
token model: PKCS #15 SCard
token flags: token initialized
serial num : 000088BAFFFF0200
Slot 4 (empty)
Slot 5 (empty)
Slot 6 (empty)
Slot 7 (empty)

The first test was to create a data object without specifying a user
pin. Slots 0-3 all show that the token is initialized, and that no login
is required. I would expect that any operation that needs a pin will
fail gracefully.

Using my custom application:

$ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
--slot 0 --create x y z
## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
## Opening session for slot = 00 ... ok
========== Creating data objects ==========
=== Creating object X ===
## Creating object with template:
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = TRUE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_APPLICATION: length = 4, value = test
CKA_LABEL: length = 1, value = x
CKA_VALUE: length = 3, value = 66:6F:6F
CKA_OBJECT_ID: length = 0, value = <empty>
Segmentation fault (core dumped)
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075065504 (LWP 28309)]
0x4015507f in add_pins_to_keycache (p11card=0x40159200, slot=0x401594c0)
at framework-pkcs15.c:2611
2611 if (p15_data->pin[CKU_SO].len) {

Hmmm. Perhaps some pre-condition checks are required here, to verify if
a user pin has been presented.

So now I add a user pin and create three data objects:

$ pkcs15-init --store-pin --auth-id 01 -T
New User PIN.
Please enter User PIN:
Please type again to verify:
Unblock Code for New User PIN (Optional - press return for no PIN).
Please enter User unblocking PIN (PUK):
Please type again to verify:

$ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
--slot 0 --pin 00000000 --create x y z
## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
## Opening session for slot = 00 ... ok
## Performing login with PIN '00000000' .... ok
========== Creating data objects ==========
=== Creating object X ===
## Creating object with template:
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = TRUE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_APPLICATION: length = 4, value = test
CKA_LABEL: length = 1, value = x
CKA_VALUE: length = 3, value = 66:6F:6Fh
## Creating object ... ok: handle = 0001
=== Creating object Y ===
## Creating object with template:
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = FALSE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_APPLICATION: length = 4, value = test
CKA_LABEL: length = 1, value = y
CKA_VALUE: length = 3, value = 62:61:72
## Creating object ... ok: handle = 0002
=== Creating object Z ===
## Creating object with template:
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = FALSE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_APPLICATION: length = 4, value = test
CKA_LABEL: length = 1, value = z
CKA_VALUE: length = 3, value = 62:61:7A
## Creating object ... ok: handle = 0003
===========================================
========== Viewing data objects ==========
## Searching for data objects ... ok
## Found 3 data object(s)
## Finalizing search ... ok
## Viewing attributes of object 0001
## Getting attribute values ... failed: user not logged in
## Viewing attributes of object 0002
## Getting attribute values ... failed: user not logged in
## Viewing attributes of object 0003
## Getting attribute values ... failed: user not logged in
==========================================
## Finalizing ... ok

The above output shows that the application created a session on slot 0,
and successfully created three data objects. Attempting to view the data
objects in the same session failed, however.

So next I tested that pkcs11-tool can view the data objects, first on
slot 0:

$ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so --slot 0
--list-objects

As expected, no data objects visible in this slot. So try slot 1:

$ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so --slot 1
--list-objects
Data object 1
label: 'x'
application: 'x'
app_id: -1
flags: modifiable
Data object 2
label: 'y'
application: 'y'
app_id: -1
flags: modifiable
Data object 3
label: 'z'
application: 'z'
app_id: -1
flags: modifiable

The data objects created in slot 0 are now visible in slot 1 (the app_id
value looks dodgy here, it should display "<empty>" rather than -1).

pkcs11-tool provides a limited view of the data object, so next I tried
my own application to view data objects on slot 1:

$ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
--slot 1 --view
## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
## Opening session for slot = 01 ... ok
========== Viewing data objects ==========
## Searching for data objects ... ok
## Found 3 data object(s)
## Finalizing search ... ok
## Viewing attributes of object 0001
## Getting attribute values ... ok
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = FALSE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_LABEL: length = 1, value = x
CKA_APPLICATION: length = 1, value = x
CKA_OBJECT_ID: length = 64, value =
FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
CKA_VALUE: length = 3, value = 66:6F:6F
## Viewing attributes of object 0002
## Getting attribute values ... ok
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = FALSE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_LABEL: length = 1, value = y
CKA_APPLICATION: length = 1, value = y
CKA_OBJECT_ID: length = 64, value =
FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
CKA_VALUE: length = 3, value = 62:61:72
## Viewing attributes of object 0003
## Getting attribute values ... ok
CKA_CLASS: length = 4, value = CKO_DATA
CKA_TOKEN: length = 1, value = TRUE
CKA_PRIVATE: length = 1, value = FALSE
CKA_MODIFIABLE: length = 1, value = TRUE
CKA_LABEL: length = 1, value = z
CKA_APPLICATION: length = 1, value = z
CKA_OBJECT_ID: length = 64, value =
FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
CKA_VALUE: length = 3, value = 62:61:7A
==========================================
## Finalizing ... ok

So now I can view the attributes of the data objects, but there's still
a few issues:

o when I created the data objects, that one marked "x" specified a
private object, which has not been honoured. In framework-pkcs15.c, the
CKA_PRIVATE attribute is ignored when creating keys, and checked for
'false' when creating a certificate. Apparently this attribute has no
significance when creating a data object, and I assume that there's no
analog for it in PKCS#15. Is there a way to store the CKA_PRIVATE
attribute for objects in PKCS#15?

o the application did not specify a value for the CKA_OBJECT_ID value,
but this has been stored as the value -1. The app_oid field of the
sc_pkcs15init_dataargs type always gets initialized to -1, from
examination of the source code. I thought this meant "value not present"
but apparently not if it gets stored, and with a length of 64 as well?

> (Btw: to protect a data object with a PIN, I think you need to modify
> the profile file -- that's something for our todo list...)
>
> Could you check if that's the case? If it's not acceptible for you
> (data objects in another virtual slot), we could make a profile
> option 'put_non_pin_protected_objects_into_the_first_virtual_slot' or
> so (what do the others think?)

I'm not sure I understand the rationale behind virtual slots and which
slot gets used for which purpose. Why is it that I use slot 0 to create
the data object, but must use slot 1 to view the same data object? And
if one data object is private and another public, are different slots
always required?

> Also, your patch sets a CKA_ID, but it seems that's no attribute for
> a data object?

Correct, I've removed CKA_ID from pkcs15_create_data.

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

Stef Hoeben

Re: Creating data object not supported in opensc's PKCS#11?

Hi,

thx for the report. Will look at it and try to fix the bugs (soon,
hopefully:-)

About virtual slots: it's a 'trick' to get around pkcs11's limitation that
there's only 1 user PIN per slot. So the OpenSC pkcs11 puts each PIN
with it's corresponding data in a separate 'virtual slot', as well as
the non-PIN
protected data. (See the pkcs11 standard for more info, or in opensc.html.)

But it's not such a nice solution, as in your case: you create a data object
in the first virtual slot, but because it's not related to the PIN, it
ends up
in the second virtual slot (or in the 3rd if you would have 2 user PINs on
the card, etc.)

That why I proposed to put non-PIN related data it in the first virtual
slot,
instead of in a different virtual slot.

Cheers,
Stef

Geoffrey Elgey wrote:

> G'day,
>
> Stef Hoeben wrote:
>
>> guess the data object is in slot 5 or 6 instead of slot 4. The reason
>> has to do with pkcs11 'virtual slots'[1] in which the stuff in a
>> virtual slot corresponds to one PIN. And because the data object you
>> made isn't pin-protected, it ends up in one o the next virtual slots.
>
>
> Okay, I managed to get some spare time to look at writing data objects
> using the opensc-pkcs11 library, and with the small patch mentioned
> previously. It seems that data objects are created, but I need to view
> them using a different slot to the one used when creating the data
> objects.
>
> Here's a session using a Cryptoflex 32K card. First I initialize the
> card and look at the slots:
>
> $ pkcs15-init --erase-card -T
> $ pkcs15-init --create-pkcs15 -T
> New Security Officer PIN (Optional - press return for no PIN).
> Please enter Security Officer PIN:
> $ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so
> --list-slots
> Available slots:
> Slot 0 SCR 331 00 00
> token label: OpenSC Card
> token manuf: OpenSC Project
> token model: PKCS #15 SCard
> token flags: token initialized
> serial num : 000088BAFFFF0200
> Slot 1 SCR 331 00 00
> token label: OpenSC Card
> token manuf: OpenSC Project
> token model: PKCS #15 SCard
> token flags: token initialized
> serial num : 000088BAFFFF0200
> Slot 2 SCR 331 00 00
> token label: OpenSC Card
> token manuf: OpenSC Project
> token model: PKCS #15 SCard
> token flags: token initialized
> serial num : 000088BAFFFF0200
> Slot 3 SCR 331 00 00
> token label: OpenSC Card
> token manuf: OpenSC Project
> token model: PKCS #15 SCard
> token flags: token initialized
> serial num : 000088BAFFFF0200
> Slot 4 (empty)
> Slot 5 (empty)
> Slot 6 (empty)
> Slot 7 (empty)
>
> The first test was to create a data object without specifying a user
> pin. Slots 0-3 all show that the token is initialized, and that no login
> is required. I would expect that any operation that needs a pin will
> fail gracefully.
>
> Using my custom application:
>
> $ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
> --slot 0 --create x y z
> ## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
> ## Opening session for slot = 00 ... ok
> ========== Creating data objects ==========
> === Creating object X ===
> ## Creating object with template:
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = TRUE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_APPLICATION: length = 4, value = test
> CKA_LABEL: length = 1, value = x
> CKA_VALUE: length = 3, value = 66:6F:6F
> CKA_OBJECT_ID: length = 0, value = <empty>
> Segmentation fault (core dumped)
> ...
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075065504 (LWP 28309)]
> 0x4015507f in add_pins_to_keycache (p11card=0x40159200, slot=0x401594c0)
> at framework-pkcs15.c:2611
> 2611 if (p15_data->pin[CKU_SO].len) {
>
> Hmmm. Perhaps some pre-condition checks are required here, to verify if
> a user pin has been presented.
>
> So now I add a user pin and create three data objects:
>
> $ pkcs15-init --store-pin --auth-id 01 -T
> New User PIN.
> Please enter User PIN:
> Please type again to verify:
> Unblock Code for New User PIN (Optional - press return for no PIN).
> Please enter User unblocking PIN (PUK):
> Please type again to verify:
>
> $ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
> --slot 0 --pin 00000000 --create x y z
> ## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
> ## Opening session for slot = 00 ... ok
> ## Performing login with PIN '00000000' .... ok
> ========== Creating data objects ==========
> === Creating object X ===
> ## Creating object with template:
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = TRUE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_APPLICATION: length = 4, value = test
> CKA_LABEL: length = 1, value = x
> CKA_VALUE: length = 3, value = 66:6F:6Fh
> ## Creating object ... ok: handle = 0001
> === Creating object Y ===
> ## Creating object with template:
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = FALSE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_APPLICATION: length = 4, value = test
> CKA_LABEL: length = 1, value = y
> CKA_VALUE: length = 3, value = 62:61:72
> ## Creating object ... ok: handle = 0002
> === Creating object Z ===
> ## Creating object with template:
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = FALSE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_APPLICATION: length = 4, value = test
> CKA_LABEL: length = 1, value = z
> CKA_VALUE: length = 3, value = 62:61:7A
> ## Creating object ... ok: handle = 0003
> ===========================================
> ========== Viewing data objects ==========
> ## Searching for data objects ... ok
> ## Found 3 data object(s)
> ## Finalizing search ... ok
> ## Viewing attributes of object 0001
> ## Getting attribute values ... failed: user not logged in
> ## Viewing attributes of object 0002
> ## Getting attribute values ... failed: user not logged in
> ## Viewing attributes of object 0003
> ## Getting attribute values ... failed: user not logged in
> ==========================================
> ## Finalizing ... ok
>
>
> The above output shows that the application created a session on slot 0,
> and successfully created three data objects. Attempting to view the data
> objects in the same session failed, however.
>
> So next I tested that pkcs11-tool can view the data objects, first on
> slot 0:
>
> $ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so --slot 0
> --list-objects
>
> As expected, no data objects visible in this slot. So try slot 1:
>
> $ pkcs11-tool --module /usr/local/lib/pkcs11/opensc-pkcs11.so --slot 1
> --list-objects
> Data object 1
> label: 'x'
> application: 'x'
> app_id: -1
> flags: modifiable
> Data object 2
> label: 'y'
> application: 'y'
> app_id: -1
> flags: modifiable
> Data object 3
> label: 'z'
> application: 'z'
> app_id: -1
> flags: modifiable
>
> The data objects created in slot 0 are now visible in slot 1 (the app_id
> value looks dodgy here, it should display "<empty>" rather than -1).
>
> pkcs11-tool provides a limited view of the data object, so next I tried
> my own application to view data objects on slot 1:
>
> $ ./p11-add-data-object --module /usr/local/lib/pkcs11/opensc-pkcs11.so
> --slot 1 --view
> ## Loading module: /usr/local/lib/pkcs11/opensc-pkcs11.so ...ok
> ## Opening session for slot = 01 ... ok
> ========== Viewing data objects ==========
> ## Searching for data objects ... ok
> ## Found 3 data object(s)
> ## Finalizing search ... ok
> ## Viewing attributes of object 0001
> ## Getting attribute values ... ok
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = FALSE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_LABEL: length = 1, value = x
> CKA_APPLICATION: length = 1, value = x
> CKA_OBJECT_ID: length = 64, value =
> FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
>
> CKA_VALUE: length = 3, value = 66:6F:6F
> ## Viewing attributes of object 0002
> ## Getting attribute values ... ok
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = FALSE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_LABEL: length = 1, value = y
> CKA_APPLICATION: length = 1, value = y
> CKA_OBJECT_ID: length = 64, value =
> FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
>
> CKA_VALUE: length = 3, value = 62:61:72
> ## Viewing attributes of object 0003
> ## Getting attribute values ... ok
> CKA_CLASS: length = 4, value = CKO_DATA
> CKA_TOKEN: length = 1, value = TRUE
> CKA_PRIVATE: length = 1, value = FALSE
> CKA_MODIFIABLE: length = 1, value = TRUE
> CKA_LABEL: length = 1, value = z
> CKA_APPLICATION: length = 1, value = z
> CKA_OBJECT_ID: length = 64, value =
> FF:FF:FF:FF:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
>
> CKA_VALUE: length = 3, value = 62:61:7A
> ==========================================
> ## Finalizing ... ok
>
> So now I can view the attributes of the data objects, but there's
> still a few issues:
>
> o when I created the data objects, that one marked "x" specified a
> private object, which has not been honoured. In framework-pkcs15.c, the
> CKA_PRIVATE attribute is ignored when creating keys, and checked for
> 'false' when creating a certificate. Apparently this attribute has no
> significance when creating a data object, and I assume that there's no
> analog for it in PKCS#15. Is there a way to store the CKA_PRIVATE
> attribute for objects in PKCS#15?
>
> o the application did not specify a value for the CKA_OBJECT_ID value,
> but this has been stored as the value -1. The app_oid field of the
> sc_pkcs15init_dataargs type always gets initialized to -1, from
> examination of the source code. I thought this meant "value not
> present" but apparently not if it gets stored, and with a length of 64
> as well?
>
>> (Btw: to protect a data object with a PIN, I think you need to modify
>> the profile file -- that's something for our todo list...)
>>
>> Could you check if that's the case? If it's not acceptible for you
>> (data objects in another virtual slot), we could make a profile
>> option 'put_non_pin_protected_objects_into_the_first_virtual_slot' or
>> so (what do the others think?)
>
>
> I'm not sure I understand the rationale behind virtual slots and which
> slot gets used for which purpose. Why is it that I use slot 0 to
> create the data object, but must use slot 1 to view the same data
> object? And if one data object is private and another public, are
> different slots always required?
>
>> Also, your patch sets a CKA_ID, but it seems that's no attribute for
>> a data object?
>
>
> Correct, I've removed CKA_ID from pkcs15_create_data.
>
> -- Geoff
>

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

Eric Norman

Re: Creating data object not supported in opensc's PKCS#11?

On May 24, 2005, at 1:20 PM, Stef Hoeben wrote:

> About virtual slots: it's a 'trick' to get around pkcs11's limitation
> that
> there's only 1 user PIN per slot. So the OpenSC pkcs11 puts each PIN
> with it's corresponding data in a separate 'virtual slot', as well as
> the non-PIN
> protected data. (See the pkcs11 standard for more info, or in
> opensc.html.)

Here's my rather incomplete thinking about the relationship between
PKCS11
slots and virtual slots.

I don't think it's a good idea to invent a new profile keyword for
every combination
that someone can think of.

Rather, I would like to see a general mechanism that maps slots to card
capabilities. Here's an example of what opensc.conf might look like;
please
excuse any errors in the syntax.

app opensc-pkcs11 {
slot+0 = {
public = {read-any-certificate, crypto-verify, crypto-encrypt};
pin1 = {crypto-sign, crypto-decrypt};
}
slot+1 = {
public = {};
pin2 = {generate-key, store-own-certificate,
store-useful-certificate, read-key, change-pin1};
}
slot+2 = {
public = {};
pin3 = {store-trusted-certificate, delete-certificate,
delete-key, erase-file, unlock-pin1};
}
}

The idea is that each slot has two states, either someone has supplied
a PIN
appropriate for that slot and will unlock the associated capabilities,
or it might
have "public" capabilities that can always be done. In the above
configuration
someone who knows PIN1 can get the card to sign or decrypt, but that's
it. They
can't write any files or otherwise change what's on the card. This is
normal
operation.

To generate keys or store some things or export the private key, you
need to
know PIN2 and login to the second slot.

PIN3 will allow someone to make even more drastic changes to the card.

Note that there's really no distinction between a user PIN and a
security officer's
PIN. In the above example, presumably a "security officer" is the only
one that
knows PIN3 and therefore would be able to perform the operations
available
at the third slot.

One of things that I'm trying to accomplish here is to allow a user to
unlock a
card for routine operations but not enable changes to her card if she
plugs it
into rogue equipment.

Eric Norman
University of Wisconsin

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

Peter Stuge

Re: Creating data object not supported in opensc's PKCS#11?

In reply to this post by Stef Hoeben

On Tue, May 24, 2005 at 08:20:12PM +0200, Stef Hoeben wrote:
> About virtual slots: it's a 'trick' to get around pkcs11's
> limitation that there's only 1 user PIN per slot.
[..]
> But it's not such a nice solution, as in your case:

On Tue, May 24, 2005 at 06:22:18PM -0500, Eric Norman wrote:
> Here's my rather incomplete thinking about the relationship between
> PKCS11 slots and virtual slots.
>
> I don't think it's a good idea to invent a new profile keyword for
> every combination that someone can think of.
>
> Rather, I would like to see a general mechanism that maps slots to
> card capabilities.
[..]
> The idea is that each slot has two states, either someone has supplied
> a PIN appropriate for that slot and will unlock the associated
> capabilities, or it might have "public" capabilities that can always
> be done. In the above configuration someone who knows PIN1 can get
> the card to sign or decrypt, but that's it. They can't write any
> files or otherwise change what's on the card. This is normal
> operation.

I agree with Stef. The virtual PKCS#11 slots are not at all nice.

Question is how we can deal with the PKCS#11 design better..

I like your idea, Eric. It's usage oriented, and maps onto PKCS#11
ideas; different usages have their own PINs.

But I still do not (at all!) like the fact that there must always be
a static number of fake readers in the PKCS#11 layer because of their
bad design choices.. I guess I'm not alone.

What is the intended use of PKCS#11? Is the idea that it should be
the single worldwide standard for applications that want to access
crypto-enabled tokens? Must say, the limitation sucks in that case..
I'll go grab the standard and read up a bit.

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

David Corcoran

Re: Creating data object not supported in opensc's PKCS#11?

Peter,

Look at the current version and a previous. In fact, they have
removed the notion of virtual slots so I'm not even sure of a
way to support multiple pins in the current version ....

Dave

On May 24, 2005, at 9:07 PM, Peter Stuge wrote:

> On Tue, May 24, 2005 at 08:20:12PM +0200, Stef Hoeben wrote:
>
>> About virtual slots: it's a 'trick' to get around pkcs11's
>> limitation that there's only 1 user PIN per slot.
>>
> [..]
>
>> But it's not such a nice solution, as in your case:
>>
>
> On Tue, May 24, 2005 at 06:22:18PM -0500, Eric Norman wrote:
>
>> Here's my rather incomplete thinking about the relationship between
>> PKCS11 slots and virtual slots.
>>
>> I don't think it's a good idea to invent a new profile keyword for
>> every combination that someone can think of.
>>
>> Rather, I would like to see a general mechanism that maps slots to
>> card capabilities.
>>
> [..]
>
>> The idea is that each slot has two states, either someone has
>> supplied
>> a PIN appropriate for that slot and will unlock the associated
>> capabilities, or it might have "public" capabilities that can always
>> be done. In the above configuration someone who knows PIN1 can get
>> the card to sign or decrypt, but that's it. They can't write any
>> files or otherwise change what's on the card. This is normal
>> operation.
>>
>
> I agree with Stef. The virtual PKCS#11 slots are not at all nice.
>
> Question is how we can deal with the PKCS#11 design better..
>
> I like your idea, Eric. It's usage oriented, and maps onto PKCS#11
> ideas; different usages have their own PINs.
>
> But I still do not (at all!) like the fact that there must always be
> a static number of fake readers in the PKCS#11 layer because of their
> bad design choices.. I guess I'm not alone.
>
> What is the intended use of PKCS#11? Is the idea that it should be
> the single worldwide standard for applications that want to access
> crypto-enabled tokens? Must say, the limitation sucks in that case..
> I'll go grab the standard and read up a bit.
>
>
> //Peter
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>

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

Stef Hoeben

Re: Creating data object not supported in opensc's PKCS#11?

Hi,

ah, yes.. Guess the 'virtual slots trick' was in an appendix anyway, it was
more an example on how one could handle multiple user PINs.

So even if we would 'upgrade' to the current pkcs11 version, it won't
prevent us to keep virtual slots (just because there's no alternative),
IMHO.

Apart from that, I still like my solution better: put everything into the
first slot, except for 2nd, 3rd, ... user PINs and the keys/certs/data that
depend on them. As there's usually only 1 user PIN, we would usually
have 1 'normal' slot containing everything. Less confusing.

Pls. convince me otherwise :-) Or perhaps it's possible to reconcile
this solution with Eric's? (Also: Eric's solution is quite some work,
I think, so we have to find someone who want to implement it.)

Cheers,
Stef

Note: the keys/certs associated with a UserConsent Pin would end up
in the 1st (virtual) slot because the UserConsent Pin would be invisible
in pkcs11. This way, even a big group of 2-user-PIN cards (eID)
have everyting into the same slot. At least, that's how it's done in the
Belgian pkcs11 and at least 2 commercial pkcs11 libs I know about.

David Corcoran wrote:

> Peter,
>
> Look at the current version and a previous. In fact, they have
> removed the notion of virtual slots so I'm not even sure of a
> way to support multiple pins in the current version ....
>
> Dave
>
>
>
> On May 24, 2005, at 9:07 PM, Peter Stuge wrote:
>
>> On Tue, May 24, 2005 at 08:20:12PM +0200, Stef Hoeben wrote:
>>
>>> About virtual slots: it's a 'trick' to get around pkcs11's
>>> limitation that there's only 1 user PIN per slot.
>>>
>> [..]
>>
>>> But it's not such a nice solution, as in your case:
>>>
>>
>> On Tue, May 24, 2005 at 06:22:18PM -0500, Eric Norman wrote:
>>
>>> Here's my rather incomplete thinking about the relationship between
>>> PKCS11 slots and virtual slots.
>>>
>>> I don't think it's a good idea to invent a new profile keyword for
>>> every combination that someone can think of.
>>>
>>> Rather, I would like to see a general mechanism that maps slots to
>>> card capabilities.
>>>
>> [..]
>>
>>> The idea is that each slot has two states, either someone has supplied
>>> a PIN appropriate for that slot and will unlock the associated
>>> capabilities, or it might have "public" capabilities that can always
>>> be done. In the above configuration someone who knows PIN1 can get
>>> the card to sign or decrypt, but that's it. They can't write any
>>> files or otherwise change what's on the card. This is normal
>>> operation.
>>>
>>
>> I agree with Stef. The virtual PKCS#11 slots are not at all nice.
>>
>> Question is how we can deal with the PKCS#11 design better..
>>
>> I like your idea, Eric. It's usage oriented, and maps onto PKCS#11
>> ideas; different usages have their own PINs.
>>
>> But I still do not (at all!) like the fact that there must always be
>> a static number of fake readers in the PKCS#11 layer because of their
>> bad design choices.. I guess I'm not alone.
>>
>> What is the intended use of PKCS#11? Is the idea that it should be
>> the single worldwide standard for applications that want to access
>> crypto-enabled tokens? Must say, the limitation sucks in that case..
>> I'll go grab the standard and read up a bit.
>>
>>
>> //Peter
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>>
>>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>

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