ICMC15: Effective Cryptography—Or: What's Wrong With All These Crypto APIs?

Thorsten Groetker, CTO, Utimaco

Effective cryptography means it needs to work and be secure, but it also has to get you where you need to go quickly and calculate the results fast 

There are many well known crypto APIS - but there's something wrong with all of the.

PKCS#11 and security issues. There are numerous key extraction attacks known. Jolyon Clulow "on the Security of PKCS#11" and the Tookan project ("Attacking and Fixing PKCS#11 Security Tokens". There are CVE entries as well, but they don't necessarily note PKCS#11.

Why does PKCS#11 have these issues? Confusing sest of mechanisms and attributes - you need automated model checkers to determine secure configurations.  Functions are broken into fine grain operations, which opens the door to eavesdropping and insertion attacks. 

[Note: these are the opinions of the speaker, not my own, as with all my blogs from this conference]

PKCS#11 is not the worst of the bunch. These same attacks can be used against Microsoft CryptoAPI (CAPI), JCE/JCA and Mixed APIs. For example, under JCE/JCA there are wrap-decrypt attacks unless they are prevented by underlying devices. For CAPI, exchange keys can be also used to encrypt/decrypt data to open door to wrap-decrypt attacks.

Efficiency is development cost and time to market. If the team is more comfortable with an API, it will be easier for them to adopt and implement. 

"Simplicity is a prerequisite for reliability." - Edsger Dijkstra. (and hence for security)  Authentication should not be an after thought. We need multi-factor and multi-person (Mout of N) authentication. And don't forget about audit logging!

People tend to underesestimate the cost of data transfers - server -> CSP -> Middleware -> Network Appliance -> Driver -> HSM.  

If you implemented your cryptographic functions as atomic HSM commands it will be faster and more secure.

KMIP is trying to come to the rescue with the concept of batched requests.  This addresses some performance issues, but it is not suited as a general crypto programming paradigm.

Crypto apps running within the secure perimeter of an HSM will become the norm. Drivers include security, eas of use, performance, multi-tenancy, custom logging, portability and cost.  Thorsten believes that firewalling and binding a key to a specific app or device will become a hard requirement.

A PKCS#11 host program will have access to 50+ functions, 200 attributes [XXX - something got lost here - mechs were also mentioned] [Note: I don't believe there is really any PKCS#11 library that implements every mech, every attribute, every functions].

Don't forget how dramatically an easy-to-use API combined with firewalling and enabled 3rd party apps can change an established market. Think about how much things have changed from our old Nokia cell phones with buttons to an Android or iOS phone.

Managed languages make this even easier.

But are people really going to develop embedded apps for HSMs?

Introducing CryptoScript: You eed to write a script, load the signed script (automatically compiled under the hood and executed one where it spawns threads and registers functions as commands), and invoke newly registered CryptoScript commands from the host application in high level languages.

Inside the utimaco HSM there's a boot loader, OS, administrative modules , cryptographic modules and SXI (Cryptographic eXtended services Interface). CryptoScript is on top of all that.

The basic concept is to be small, efficient and portable under the MIT license for easy portability.  The language was pared down by removing application program interfaces, native debug I/F, aux lib and OS facilities. They've enhanced this by adding secure managed memory, command handling, authentication and secure messaging. 

CryptoScript does not allow direct memory addressing and no buffer/stack overflows.

Once you've got CryptoScript Modules - they are loaded in a virtual HSM, so they cannot direct the actual HSM file system and memory.

A question from the audience: If PKCS#11 sucks, due to complexity - how does the problem go away just because we implement it on the HSM?  Answer: the attack vector is removed, CryptoScript has better debugging, and it's faster to develop.
 
Post by Valeie Fenwick, syndicated from Security, Beer, Theater and Biking!