[Security-devroom] Talk submission: unifying access to PKCS #11 tokens

[Martin Paljak]

Hello,

Interesting stuff. I added this to the wiki [1] schedule draft as well.

There are two proposals out there that I know of: the "PKCS#11 URL scheme" [2] and "PKCS#11 registry / FHS standard " [3].

Similar topics have been discussed several times lately and I'm sure the talk will create a lot of questions, discussions and synergy.


Thanks,

Martin

[1] https://www.opensc-project.org/opensc/wiki/FOSDEM2011
[2] http://tools.ietf.org/html/draft-pechanec-pkcs11uri-02
[3] http://wiki.cacert.org/Pkcs11TaskForce#PKCS11_in_FHS_Proposal

On Dec 17, 2010, at 3:01 PM, Nikos Mavrogiannopoulos wrote:

> Affiliation:
> GnuTLS, Katholieke Universiteit Leuven & IBBT
> 
> Bio: Original author of the GnuTLS cryptographic library. Has worked
> on several security
> related projects and products. Currently works as a researcher in K.U.Leuven.
> 
> Talk Duration: 30 minutes
> Cryptographic services in modern operating systems today are being
> accessed by applications by using libraries, either high level ones
> that hide all details, or low level ones that force the user to deal
> with an amount of (un)interesting details of each cryptographic
> algorithm.
> Applications in the GNU/Linux and *BSD operating systems usually share
> the same libraries for cryptographic operations and protocols. Those
> can be one of Botan, OpenSSL, NSS, GnuTLS and maybe some more. This is
> quite a variety of choices which we believe is because of the
> different programming style that each library enforces, the different
> algorithms it provides and the ease of usage, which are subjective
> issues that depend on the eye of the beholder.
> 
> However this diversity of cryptographic libraries has some
> disadvantages. For operations such as signing/encryption involving
> PKCS #11 hardware tokens, or software modules, objects need to be
> referenced. Currently there is no uniform way of referencing those
> objects and each of the libraries has its own conventions or delegate
> the burden of referencing objects to the application. This in effect
> makes sharing of those object references between different
> applications impossible and users are required to learn each
> application's unique interface. Moreover the fact that usually there
> are more than one PKCS #11 providers in a system, but no way to
> globally enable them for all cryptographic applications, leaves the
> burden of setup to users.
> 
> We will discuss the challenges posed and and propose a solution.
> _______________________________________________
> Security-devroom mailing list
> Security-devroom at lists.fosdem.org
> http://lists.fosdem.org/mailman/listinfo/security-devroom

-- 
@MartinPaljak.net
+3725156495