Kais Belgaied's Weblog at Sun

Bridging the two worlds of cryptographic APIs

Those who follow the Open Solaris security community have probably seen Darren Moffat's latest announcement on Open Slaris' Security list, about OpenSolaris contribution to OpenSSL.

Sun just contributed the OpenSSL PKCS#11 engine to the OpenSSL community This is a very significant development in the cryptographic programming interfaces arena.

Over the last decade, many proprietary APIs for cryptography were developed, deployed with some limited success, and were usually tied to their owner's application.

Two major APIs however, reached the critical mass of adoption by multiple vendors to become de-facto standards for applications that need to include encryption, decryption, key management, etc ... in their security mechanisms.

The first one is OpenSSL's, which is a simple and quite intuitive interface. Its "killer" application is the Apache Webserver. It has many other consumers, and many computer science introduction to security and cryptography classes use OpenSSL's libcrypto.

PKCS#11 (Public Key Cryptographic Standard # 11, also known as the CryptoKi or Cryptographic Token Interface) is the other one. It originated from a consortium of vendors of cryptographic solutions, fostered by RSA security, Inc. Its earlier versions initially followed the model of a single user of a personal cryptographic device, referred to as a "Token". The closest image illustrating this model is a smartcard. Soon enough, PKCS#11 evolved to a full-fledged cryptographic API. In addition to basic encryption operations, it offers secure persistent storage of keys, as well defined access controls and authentication mechanisms. NSS, used by Mozilla, the JES webserver , and LDAP directory servers are among the biggest users of PKCS#11 natively.

The presence of the two de-facto standards, meant so far that vendors of hardware cryptographic accelerators need to write deploy, and maintain two cryptographic libraries in order to maximize their utilization by customer applications. the fact that the two standards evolve independently at their own pace, meant that Vendors have to produce patches and updates to keep up with both.

There're a more fundamental difficulty though, having been the techinical leader of the Solaris Cryptographic Framework team, I learned the difficulty of having to juggle with two models for invoking cryptographic functions: A sessionless model, OpenSSL's, where all the information to execute a crypto operation (algorithm, keys, plaintext and ciphertext locations) are readily available within the context of that operation, and a session-oriented model (the PKCS#11 way) where the caller established a session, authenticated it as the case may be, creates or retrieves the key objects, then performs crypto operation in the context of that session. The challenge was to put in place a robust, flexible, and scalable framework that internally interfaces vendors plugging in as providers that expose either model, while externally exposes a unified programming interface. Offering the same level of pluggability and programmability in both userland and kernel added a whole other dimension to the challenge ;) (but that's another story, for a future blog, perhaps)

With the PKCS#11 OpenSSL engine now part of the OpenSSL distribution, vendors of cryptographic cards can focus on developing a PKCS#11 library for their hardware, and be useful for all user level consumers of with OpenSSL's libcrypto or PKCS#11 cryptoki. This benefit covers any operating system that the vendor supports a PKCS#11 interface with their driver on.

For vendors that write to the kernel level cryptographic SPI (service provider interface) in Solaris 10 and later update releases, the crypto hardware can be utilized by other kernel level solaris consumers, such as Kerberos, IPsec, or Kernel SSL proxy.

It is exciting to see the industry maturing, enough to have such a smooth consolidation effort materializing, without sacrificing either APIs. It's exciting because vendors, less burdened by supporting multiple APIs, can focus on innovating in their core competences: faster, safer, and better quality hardware cryptography. Posted by kais ( May 06 2006, 09:17:45 PM PDT ) Permalink Comments [0]