HSMs are unbeatable​ for crypto (part 1)

Por: Dr. Roberto Gallo

In this second short article, my objective is having you understanding the (sometimes subtle) things that make HSMs a unique technology. I hope you enjoy it! If you missed the first, check it here.

Just to frame the discussion and you and I talk the same, I refer to the OASIS definition of a computing service. I use it because it is generic enough to encompass services provided by any and all HSMs I know: “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.”

With that in mind, you can categorize HSMs’ services in four groups, which will be described in greater details below (and in the next articles): cryptographic, key management, AAA, and secure code execution.

We will start with crypto.

CRYPTOGRAPHIC SERVICES

Are those services directly related to encryption/decryption, digital signature/verification, message authentication, etc. Some keywords here are AES, TDES, RSA, ECDSA, HMAC. These services are directly used to achieve the well-known security objectives that I am sure you heard of: “confidentiality,” “authentication,” “non-repudiation,” and “data integrity,” among others (yes, there are many other security objectives — check the Handbook of Applied Cryptography for a few more).

Historically speaking, those services were the first to appear in HSMs, for reasons that are still there today:

1. Performance.

For example, an RSA 2048 private-key operation (sign, decryption) requires a few million arithmetic instructions to complete. Today, with multi-core, multi-gigahertz computers they can be achieved in much less than one millisecond, but in the 1980’s and 1990’s this operation could require many seconds, hindering a number of applications.

Even today, when high output scenarios are in place such as SSL tunnel establishment, people may choose to use HSMs as for raw performance alone. I would say, however, that this might be the least important reason someone would invest in an HSM today. Surprised? I hope not.

For HSMs whose proposition is high performance, usually, it is achieved by two distinct, complementary mechanisms: (a) parallelism and (b) hardware accelerated operations. In fact, some crypto chips used in HSMs can have more than one hundred parallel computing units, each one with specialized circuitry capable of performing algorithm specific operations, say, in ten times fewer clock cycles than a general purpose processor!

2. Secure Key Handling.

I regard this as the most fundamental HSM service but incredibly missed by many security professionals. Before defining “secure key handling,” I will share with you a few examples:

• If a key owned by a (regular) user is marked as private and sensitive, even the most privileged HSM superuser cannot read or use it!;
• At generation time, a key can be labeled as not exportable so that even the key owner cannot read or export, only use it!;
• Even with physical device access, a curious admin or an adversary cannot learn or use a key not owned by them!;

Are there any of these use cases new to you? If not, great! If yes, it is okay as long as you’ve grasped the feeling behind it: HSMs’ cryptographic services are about control over the key usage so that only the rightful owners can use it and in precise ways. That’s how I informally define “secure key handling”.

Misusage and tamper tentatives are either blocked, logged, leave physical tampering traces, or result in the destruction of the sensitive material. Cool countermeasures, right?

Each vendor has its secret sauce when it comes to achieving the above properties, and they do depend on device features and adherence to industry standards, but the most common items are:

• Sound business logic insulating keys and users and enforcing specific security policies;
• An interface to interact with such business logic (e.g., KMIP, PKCS#11, OpenSSL engine, CAPI/CNG, etc.), i.e., means to perform the crypto operations;
• Removing the superusers or at least diminishing their power;
• Preventing business logic tampering either by hardwired circuitry or by using a non-bypassable secure boot sequence, with a hardware-protected root of trust;
• Hardware separation of security functions;
• Mechanisms for physical tamper evidencing, such as seals, epoxy enclosures, etc.;
• For some devices, active anti-tamper mechanisms, such as perforation sensors, voltage manipulation sensors, zeroize circuitry, etc.;

At this point I recommend you stopping and thinking: “how likely one will get serious ‘secure key handling’ in an, say, a COTS Dell server with a Linux distro”?

You are right if you mentalized the meme: “one does not simply…”

And because crypto is as secure as the keys are, then secure key handling is probably the most important drive behind HSM usage.

Well, I will stop here in this article to keep it short.

WHAT IS NEXT?

In the next article, I continue describing the crypto services, and we will be talking about the correctness of crypto implementations and side-channel attacks in HSMs. Check it out!