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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |