HSMs are Unbeatable for Crypto (Part 2)

Por: Dr. Roberto Gallo

In this short article, I continue to explain how HSMs deliver so much regarding cryptographic services and why you probably have to think again if you are not doing crypto with this technology.

Just to recap, in the first part of this article (here), I’ve explained that one could categorize HSMs’ services in four groups (cryptographic, key management, AAA, and secure code execution). Then, I’ve started to describe why this technology is unique regarding (1) performance and (2) secure key handling.

So, let’s resume the describing the motivation, characteristics, and rationale behind Cryptographic Services in HSMs.

3. Algorithmic Correctness.

It is fiercely difficult to get crypto done right. It should suffice to observe the recent history of big names failing because of small errors: from Sony’s ECDSA key being recovered, to Debian’s OpenSSL random number generator not being even pseudo-random. And there are many other cases.

There are many reasons why getting crypto working right is thought, some of them:

• even tiny errors can lead to catastrophic outcomes (e.g. nonce reuse in ECDSA lead to the private key recovery in the Sony Case);
• simple software tests have poor coverage when checking for crypto errors (how would you check a PRNG?);
• crypto is particularly sensitive to parameters choice;
• there are more ways to use crypto algorithms in the wrong fashion than in the right (e.g., if one uses RSA signature without padding, a.k.a. raw, then if an attacker gets signature of text A and signature of text B, then he/she can forge the signature of A*B — a classical attack);
• algorithms can only be combined in very precise forms without reducing or worst, failing altogether (e.g., using RSA 2048 bits for key distribution and then using AES 128 for encryption is likely to result in a security level at ~ 112 bits);
• implementations can easily suffer modifications (intentional or not) and go unnoticed (e.g., unintentional: library dependencies, platform underlying data types, endianness, bugs. Intentional: sabotage, profit, or fun & fame, see: http://www.underhanded-c.org)

So, because of that, vendors concentrate a lot of effort in making sound, trustworthy implementations of crypto and even in some cases, making them difficult for people using them wrong.

The correctness of the implementations is achieved in a layered approach, regarding technology, processes, and people, by:

• employing high-skilled personnel with specific education in the R&D cycle;
• enforcing strict control over the software, hardware product lifecycle, reducing the chances of (un)intentional errors, from conception to disposal;
• using top-notch, crypto-oriented correctness verification techniques at R&D, compile/synthesize, and execution/usage time;
• going through third-party, neutral verification/certification processes, and
• preventing algorithm tampering (check item “2. Secure Key Handling” in the first part of this short article to see how), by using physical and logical countermeasures

So, the message is: if you want to do it right, you ought to use an HSM for crypto.

Ps. If you need more info to convince yourself that it is easy to make crypto wrong, I recommend you take a look at Practical Cryptography by Niels Ferguson and Bruce Schneier, Cap 2.7 “Cryptography is Very Difficult” and Cap. 2.8 “Cryptography is the Easy Part.”

4. Side-Channel Analysis (and Attacks) – SCA

Unless you are a hermit, it is almost sure you’ve heard about the SPECTRE attack that affects most of the moderns CPUs, including those from Intel and many ARM instances.

Although this attack was discovered in late 2017 and came to the general public attention only in 2018, the very underlying ideas (and enabling phenomena) were known to the crypto community for more than a decade, and to the Defense sector at least since the 1970’s.

The idea is the following: every time you compute, store, display or transmit any bit of information, the underlying physical system is disturbed and this “disturbance” can usually be read in more than one way.

I will give you two examples:

• if you are old enough, you might remember those old Sound Blaster audio cards. In some computers, when they were processing something more intense, you actually could hear a distinctive noise at your sound boxes (How that come?);
• when you are gaming, mining bitcoin, trying to crack a password or doing any other more productive CPU-intensive task, your computer will get hotter;

That happens because the information is encoded in physical variables. In other words, that bit of information that you see in your programming language of choice is an abstraction of the physical variables in your system.

For instance, if you were using a classic RS232 serial line, the bit “0” would be associated with a positive (TxD/RxD to the GND) voltage from +3V to +15V and the bit “1” would be associated to -15V to -3V.

So what? You see that there is “principal” communication channel which is composed of the TxD and RxD lines, however, if data is being transmitted or received, there will also exist an electrical current and thus a magnetic field (by Ampère Law). And this magnetic field can be measured (even without touching the wires) and be used to deduct the voltage levels and thus, the information bits. In other words, the magnetic field in the example above would serve as a secondary way to read the data, a “secondary channel.”

Modern side-channel attacks (SCA) can be much more sophisticated than that. They can involve:

• employing multivariate statistical techniques;
• specially crafted tools for measuring physical quantities;
• and using artifacts/test-benches to stimulate the target system in specific ways so that variable samples can be acquired.

A few keywords here are SCA, DPA, EMA, DEMA, CPA.

The good part is that HSMs’ vendors know SCA very well and use a variety of logical and physical countermeasures to their devices, many of them unavailable on standard, server-grade systems. Depending on the device class, the employed countermeasures can resist even against motivated, educated, well-funded adversaries.

I will refrain myself from diving at specific countermeasures, but at this point, I believe you have a good feeling why HSMs are unbeatable for Crypto.