A recent proof of concept proposes using an Arduino as low-cost improvised HSM, store cryptographic keys for authentication to Amazon Web Services. This is billed as an example of inexpensive commodity hardware disrupting the stodgy HSM (hardware security module) market. This argument slightly blurs the definition of what exactly constitutes an HSM. The security properties of an HSM can be roughly divided into two categories:
- Reduced software attack surface. That is, the external interface for talking to the HSM is limited to the bare minimum, designed to protect against attacks against the integrity of the software. This threat model assumes an attacker has 0wned the box that the HSM is attached to and is free to send any traffic over the same channel. Beyond addresing the obvious concerns (eg sending malformed requests to trigger a memory corruption vulnerability) HSM try to reduce the risk by locking down the platform. For example the OS is typically immutable, with no room for users to install apps, there are no random “value-added” services running or dubious components such as Java to pose risk even when unused.
- Physical tamper-resistance. The hardware itself resists attempts to pry sensitive data such as cryptographic keys out of the HSM, even when bad guys have unfettered physical access. This is a more formidable adversary: he/she can attempt almost every software attack available to the “authorized” machine (modulo attacks requiring credentials, which may not be available when HSM is captured in isolation) But they can also go after the hardware itself. For example crack the casing of the device open, pull out the disk drive or flash memory, and try to directly scrape data from the disk. They could exploit side-channels by measuring timing with high resolution, observe power consumption or monitor RF emanations during a cryptographic operation. They could even try to deliberately induce faults by operating the chip outside its normal thermal limits, over-clocking or zapping the circuits with lasers.
A design using the Arduino can meet the first criteria, depending on the quality of the software. While it was never engineered for this purpose, the “secure” option described in the post does appear to lock down the environment. For example the keys injected can not be extracted via standard mechanisms of memory access or JTAG interfaces.
But then again so does a Windows 95 box or ancient Palm Pilot connected to the server with a serial cable. When attackers are limited to accessing the so-called “HSM” from a single interface attached to the server, anything can qualify by running a suitably locked down, minimal crypto application in isolation. That code would be limited to handling a small number of external requests over the serial cable. No web surfing, TCP/IP or even a network connection, no PDF viewers or complex image parsers with tricky logic susceptible to memory corruption errors. More precisely, even if those components exist, they can not be invoked by the attacker. Suspending disbelief, the fact that underlying OS is full of vulnerabilities magically becomes irrelevant because latent bugs are not reachable via the one channel that exists between HSM and the server the adversary controls.
In reality one does worry about temporary physical access, where bad guys get their hands on the device for a “limited time” for some definition of limited. While permanent disappearance of an HSM might be noticed sooner or later, it is perfectly reasonable that devices may become temporarily inaccessible due to a network outage or deliberately taken out of service. That creates a perfect opportunity for attackers to take advantage physical presence in the data center. Even destructive attacks are fair game: once all keys extracted, attacker can copy them into a brand new HSM of the same model to replace the unit damaged during the attack. The owners will not be any wiser unless they carefully inspect the casing itself.
The Arduino, along with the hypothetical Win95 box and Palm Pilot fail in this model because they are not hardened against side-channel or direct physical attacks. (Although presumably it takes more than attaching a network cable to the Arduino to pop it, unlike the other off-the-shelf devices.)
A Trusted Platform Module (TPM) built into the server is a much better starting point for HSM functionality on the cheap. By virtue of being built into the motherboard, it avoids cabling and hardware placement problems. It is difficult to find servers shipping with these, although HP appears to have produced them at some point. In the spirit of kludges, one could also imagine attaching a smart card reader to the server, with a card permanently inserted. (Much like connecting Arduino sticks with USB cable to racked servers, this would not fly in a real data-center environment.) As with TPMs, these provide a measure of software and hardware security. For quite a few models those properties are rigorously subject to testing by independent labs for Common Criteria and FIPS certifications. They also happen to be much cheaper than an Arduino unit: programmable blank cards can be purchased for a few dollars at high volume.
In fairness, one area where secure execution environments such as TPMs and smart cards have great disadvantage is speed. While they often feature hardware accelerators for cryptography, they are bottlenecked by I/O. Getting data into and out of the chip takes more time than processing it. With round-trip latency measured on the order of milliseconds, these setups are limited to low volume work loads. By contrast an off-the-shelf embedded system can achieve thousands of HMAC operations per second as the Arduino prototype notes. (Use of HMAC exacerbates the problem, because it requires the full message to be passed to the chip that contains the key. With digital signatures, typically one can get away with passing only the hash.)