Re: [opensc-devel] Bug in engine_pkcs11
Hello, On May 10, 2011, at 10:02 , Giuliano Bertoletti wrote: A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of CK_SLOT_ID can be a valid slot identifier—in particular, a system may have a slot identified by the value 0. It need not have such a slot, however. Notice also that by matching the supplied value against slot_index you won't loose anything in case slot_index = slot_id. For real life use, both fixed slot ID-s and fixed slot indexes seem to be necessary (have a look at pkcs11-tool) To make it simple: do you have a patch, that fixes both cases (so that a slot index and a hardcoded slot ID can be used)? -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
Hello, unfortunatelly I'm still fighting with the compiler to rebuild the engine_pkcs11 library (under Windows / Mingw or Visual C++). Once I get it to work, I would be happy to supply the patch (shouldn't take too long to patch). To be more accurate I cannot link the OpenSSL libraries to libp11 because mingw produced a libcrypto.a while libtool expects a .lo object. Giulio. Il 10/05/2011 9.24, Martin Paljak ha scritto: Hello, On May 10, 2011, at 10:02 , Giuliano Bertoletti wrote: A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of CK_SLOT_ID can be a valid slot identifier—in particular, a system may have a slot identified by the value 0. It need not have such a slot, however. Notice also that by matching the supplied value against slot_index you won't loose anything in case slot_index = slot_id. For real life use, both fixed slot ID-s and fixed slot indexes seem to be necessary (have a look at pkcs11-tool) To make it simple: do you have a patch, that fixes both cases (so that a slot index and a hardcoded slot ID can be used)? -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On Mon, May 9, 2011 at 9:53 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: This is a matter of interpretation. Either is not constant and user is not suppose to know of. Apart of the special case of having a single slot, so you expect 0 I presume. You can check which slot is what simply by using: pkcs11-tool --list-slots --module /usr/lib/pkcs11/ To me slots and slot ids shouldn't be included in any APIs or user interfaces involving PKCS #11. They do not make sense to end-user or even the application itself. In gnutls we have p11tool that does operations on PKCS #11 cards without any knowledge of slots. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On Tue, May 10, 2011 at 9:40 AM, Giuliano Bertoletti g...@symbolic.it wrote: Hello Nikos, just a few notes. The pkcs#11 standard adresses cryptographic devices in general, not only smart-cards which might (or might not) have a single slot. Cryptographic devices such HSMs are capable of supporting many many slots. Slot can also be added and removed at wish. And this is exactly the reason why they shouldn't be used for object identification and usage (the typical use-case of PKCS #11). They're used, for example, in multi user remote signatures where you setup a server, connect it to a device, and have thousands (even millions sometime) of users remotely operate the device. Typically each user has a slot assigned which is protected with its own pin. I don't fully understand the use-case but I don't really see that a mainstream and neither good example of PKCS #11 usage. You lower all the security of the PKCS #11 to security of PIN over the network? A hardware token should imply proximity and visibility to the token IMO. What is the point to have a hardware token in US to sign for me while I'm in europe? How do I know it is my token or someone else isn't signing with it? The correct way to locate a particular user key is for the application to query by token name (returned by C_GetTokenInfo), but this might require a lookup that is beyond the capability of the engine. Why not? In the millions slot case you mentioned it might be a problem iterating through the available slots, but in typical cases this is not a stopper. regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
Hello Nikos, Il 10/05/2011 11.23, Nikos Mavrogiannopoulos ha scritto: On Tue, May 10, 2011 at 9:40 AM, Giuliano Bertolettig...@symbolic.it wrote: And this is exactly the reason why they shouldn't be used for object identification and usage (the typical use-case of PKCS #11). I partially agree, but consider that typically an administrator alters the slots layout only when the system is under maintenance and often does that to extend the number of user/slots. So the indexing remains the same, only new space is allocated at the end. I don't fully understand the use-case but I don't really see that a mainstream and neither good example of PKCS #11 usage. You lower all the security of the PKCS #11 to security of PIN over the network? A hardware token should imply proximity and visibility to the token IMO. What is the point to have a hardware token in US to sign for me while I'm in europe? How do I know it is my token or someone else isn't signing with it? In contexts like this, security works in a layered way, where outer levels are weaker than inner levels. The HSM is used to protect the keys in the sense that they cannot leave the device, but the authentication that triggers their usage still works with a PIN. There exists devices where you connect the keyboard directly to the device, so a PIN cannot be keylogged by a trojan running on the host. But this is clearly not the case. Over a network, you can protect the communication between inner server and user with a challenge response mechanism, so you can use a pocket token while you're in Europe, to authenticate to the server in the US, and then the server in the US drives the HSM to do the signature (through pkcs#11). The SSL connections can be supported by the HSM server-side and by the pocket token client side while the PIN is delivered through the encrypted channel. This is not bullet proof however, because a clerk having phisical access to the server can steal your PIN when you do the signing by dumping the data spilling out of the SSL tunnel, and later sign on your behalf. Still he cannot steal your keys and it's job is far more complex than in a scenario where no hardware device is present and the server harddrive could be imaged and later inspected. For stronger methods however you have to run the server checking logic and terminate the SSL connection inside the HSM (top notch devices allow execution of arbitrary code inside). But this imply usage of proprietary libraries and is of course beyond pkcs#11. Why not? In the millions slot case you mentioned it might be a problem iterating through the available slots, but in typical cases this is not a stopper. You're right. I meat that this would imply a greater effort to encode that, respect to change the matching slot_id to slot_index. Whether or not you decide to do this is your decision (but would surely appreciated by many people in my opinion). I pointed out the slot_id matter instead because it is just wrong to start from the assumption that the user knows it and it won't change between multiple executions. Kind Regards, -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On Tue, May 10, 2011 at 1:18 PM, Giuliano Bertoletti g...@symbolic.it wrote: I pointed out the slot_id matter instead because it is just wrong to start from the assumption that the user knows it and it won't change between multiple executions. Same for index. Sorry, I still cannot see your point. Had you argued that you wish to use slot description I would have understood. However, both id and index are generated at runtime and can change at any point in time. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
Use this[1] to build using cross compiler. [1] https://www.opensc-project.org/build On Tue, May 10, 2011 at 10:36 AM, Giuliano Bertoletti g...@symbolic.it wrote: Hello, unfortunatelly I'm still fighting with the compiler to rebuild the engine_pkcs11 library (under Windows / Mingw or Visual C++). Once I get it to work, I would be happy to supply the patch (shouldn't take too long to patch). To be more accurate I cannot link the OpenSSL libraries to libp11 because mingw produced a libcrypto.a while libtool expects a .lo object. Giulio. Il 10/05/2011 9.24, Martin Paljak ha scritto: Hello, On May 10, 2011, at 10:02 , Giuliano Bertoletti wrote: A list of CK_SLOT_IDs is returned by C_GetSlotList. A priori, any value of CK_SLOT_ID can be a valid slot identifier—in particular, a system may have a slot identified by the value 0. It need not have such a slot, however. Notice also that by matching the supplied value against slot_index you won't loose anything in case slot_index = slot_id. For real life use, both fixed slot ID-s and fixed slot indexes seem to be necessary (have a look at pkcs11-tool) To make it simple: do you have a patch, that fixes both cases (so that a slot index and a hardcoded slot ID can be used)? -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
Hello Alon, Il 10/05/2011 18.13, Alon Bar-Lev ha scritto: Last message in this thread, as I think nothing is wrong and you try to tweak implementation to suit your needs. Your assumption that only administrator is responsible for slot management is totally wrong. 1 Every USB reader that is unplugged/plugged by user will most probably result in a new slot index and slot id. This is done in order to invalidate all previous slot id references. Well, actually the expected behaviour of a PKCS#11 compliant implementation, if you unplug the token from the USB port, is to clear the flag: CKF_TOKEN_PRESENT of the flags field in the CK_SLOT_INFO structure (returned by C_GetSlotInfo). This until you call C_GetSlotList again, where the library has a chance to take another snapshot of the slots layout. If your application is performing some operation on a token (es. Signing) when you remove it, the caller should get a CKR_DEVICE_REMOVED error and behave accordingly. Yet the slot_id remains valid. From the PKCS#11 standard: All slots which C_GetSlotList reports must be able to be queried as valid slots by C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is checked at the time that C_GetSlotList, for list length prediction (NULL pSlotList argument) is called. If an application calls C_GetSlotList with a non-NULL pSlotList, and then the user adds or removes a hardware device, the changed slot list will only be visible and effective if C_GetSlotList is called again with NULL. Even if C_ GetSlotList is successfully called this way, it may or may not be the case that the changed slot list will be successfully recognized depending on the library implementation. On some platforms, or earlier PKCS11 compliant libraries, it may be necessary to successfully call C_Initialize or to restart the entire system. As for the administrator responsibility, when dealing with pocket tokens, administrator and user is the same person. So if he unplugs a token, he physically alters the hardware and should know that this has consequencies. Regards, -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
On May 10, 2011, at 15:38 , Alon Bar-Lev wrote: On Tue, May 10, 2011 at 1:18 PM, Giuliano Bertoletti g...@symbolic.it wrote: I pointed out the slot_id matter instead because it is just wrong to start from the assumption that the user knows it and it won't change between multiple executions. Same for index. Sorry, I still cannot see your point. Had you argued that you wish to use slot description I would have understood. However, both id and index are generated at runtime and can change at any point in time. From practical experience, ID *should* be treated as opaque whereas index offset could be more predictable (as is the case with nCipher, probably others have similar glitches). While both are inherently wrong they are seen in the wild. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Bug in engine_pkcs11
This is a matter of interpretation. Either is not constant and user is not suppose to know of. Apart of the special case of having a single slot, so you expect 0 I presume. You can check which slot is what simply by using: pkcs11-tool --list-slots --module /usr/lib/pkcs11/ On Mon, May 9, 2011 at 7:51 PM, Giuliano Bertoletti g...@symbolic.it wrote: Hello, I think I've found a bug in the OpenSSL engine_pkcs11. The slot_index supplied from the command line to OpenSSL and actually directed to engine_pkcs11, is incorrectly parsed by the latter which treats it as if it were the slot_id. Most pkcs#11 implementations assume slot_index = slot_id, so there're no issues in these cases. However some implementations (for example the nCipher Hardware Security Modules product line I'm working with) do not follow such convention (the pkcs#11 does not require that). For example to access slot#0 with such devices, I need to issue something like: openssl req -config ./openssl.cnf -new -out ncipher.pem -days 365 -engine pkcs11 -keyform engine -key slot_761406613 because nCipher's C_GetSlotList adds a constant before filling the array returned by C_GetSlotList: i.e.: slot_id[index] = 761406613 + index. That could be easily corrected in engine_pkcs11 by checking the slot_index supplied against the array index rather than the array value returned by C_GetSlotList. Consider that in no way, the user is supposed to know the slot_ids. They're internal values to be treated as opaque pointers that the library gives to the driving application and that the application is supposed to later return as they are: (i.e. typically for accessing slots with C_OpenSession or C_GetSlotInfo) Kind Regards, Giuliano Bertoletti -- Giuliano Bertoletti Pre-Sales Engineer - Technological Dept. Symbolic S.p.A. Viale Mentana, 29 I-43121 - Parma Tel. +39 0521 708811 Mob. +39 346 8749890 Fax +39 0521 776190 g...@symbolic.it www.symbolic.it ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
