Hello Nikos, Il 10/05/2011 11.23, Nikos Mavrogiannopoulos ha scritto: > On Tue, May 10, 2011 at 9:40 AM, Giuliano Bertoletti<g...@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
