Categories: 3d printing (14) arcade cabinet (6) arduino (2) backup (4) blogofile (4) dns (8) mailbox alert (62) making (12) projects (116) RAID (4) rants (24) raspberry pi (2) site (26) ultimaker (4)

PKCS11 library

2008-09-10 | Permalink

Here’s another one from my software wish-list, a full implementation of PKCS#11 as a software library.

Let’s do this as a little brainstorm, in the form of a small FAQ.

A software implementation of an API that is designed for hardware interaction… For the love of crypto, why?

Very good question! The reason I’d like to see a software implementation is simply because not everyone has cryptoki hardware available at all times, or maybe even not at all.

However, in order for libraries or other products to support cryptoki hardware, one would have to either make an elaborate plugin structure, possibly depending on multiple cryptographic libraries, and perhaps even implement it’s crypto multiple times using different API’s.

Of course, one solution is to take a general crypto API such as the very nice OpenSSL project. However, due to its design and implementation, getting it working may be a little more work than one would expect.

So, a completely new crypto library then?

Yes, well, hmm. Implementing all the algorithms is probably going to be a problem; this stuff is hard. So we could make it depend on another library. Again, OpenSSL comes to mind. But that would pose a possible problem; why create a library that implements an API that is then again possibly used by one of the libraries that it uses?

So a more ’light-weight’ crypto library would be nice. Or maybe the cryptographic functions should indeed also be implemented, thereby keeping the number of dependencies low.

So how would it work?

It might be necessary to provide a daemon service; it can store keys and other data in it’s own location that is not readable by other users or software. On the other hand, having yet another service running on a computer that may or may not want to use cryptographic function through this api might be a bit much, so another solution that does not have continual state would be nice.

And when exactly will this be done?

Just a little while after somebody decides to build it, of course! Or maybe a long while. Until somebody (which very well may be me, if i find the time, and the energy to get to it) actually makes a start, it certainly won’t be done.