[Security-devroom] Talk submission: unifying access to PKCS #11 tokens
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.
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@lists.fosdem.org http://lists.fosdem.org/mailman/listinfo/security-devroom
-- @MartinPaljak.net +3725156495
participants (2)
-
Martin Paljak -
Nikos Mavrogiannopoulos