Security Module for Raspberry Pi

HSM for Raspberry Pi

We love Pi

Raspberry Pi is an awesome platform that gives people affordable access to a full-fledged portable computing and Linux development environment. Pis are hackable by design, making them a powerful and fun learning tool, and there is a growing ecosystem of developers, code and hardware that's beginning to fuel a revolution in bare metal programming. We love them and think they deserve a highly standard of security, especially if they are deployed remotely.

Start with the basics

Pi was originally designed for education but it's now graduating into many 'real-world applications' that require remote access and a higher standard of security. A 'higher standard' starts with getting the basics right:

  • Password hygiene - replace defaults with strong username & passwords, unique to each device.
  • Encrypted data & file systems - LUKS, libgcrypt, others
  • Encrypted communications - OpenSSL/SSH, others
  • Robust device ID authentication

  • Fortunately Linux provides some great software based security services that can help protect your Pi.

    But there's a caveat. The effectiveness of these services relies fundamentally upon the secure storage of a few secrets, such as encryption keys and service credentials.

    The key management problem

    Keys are a fundamental component of secure and trusted systems. Keys are used to lock and unlock encrypted data sets, protect trusted communication channels and secure sensitive credentials.

    Where you store those keys and how you manage access to them is a critical detail that is often overlooked, misunderstood or poorly executed.

    On the Pi, and similar low cost computers, keys can only be stored on the removable SD card. But the SD card is easily removed and the keys quickly copied. A basic solution is to encrypt the keys using a master password entered by a real person who has physical access to the Pi. But in remote access applications where there is no person to enter passwords, how do you unlock the keys to unlock the file system and communication channel credentials ? Even with more complex solutions like key obfuscation the fundametal problem remains and a motivated attacker with physical access can work around and release those keys. So in remote access applications you have a real security problem! This is often called the key management problem and it breaks down into two basic challenges.

  • How do you store keys securely on your Pi, or similar device ?
  • How do you communicate (symmetrical) keys securely between trusted parties ?

  • Hardware rooted key stores

    Today's internet infrastructure - cloud, PC's, mobile devices - relies upon keys that are generally stored in tamper-resistant silicon. Generically these are referred to as a 'hardware root of trust'. They come in many different sizes, functionalities and costs:

  • A Hardware Security Module (HSM) appliance installed inside a secure server room - $$,$$$
  • A removable USB Key, used to authenticate a User - $$
  • A Trusted Platform Module, used to authenticate a PC - $$
  • A single chip integrated onto computer motherboard, used to authenticate motherboard - $
  • A security block embedded within a SOC, used to authenticate host device - $

  • Zymkey's deeply protected hardware key store

    At the core of every zymkey is a hardware-rooted key store and companion encryption engine. Zymkey integrates the ubquitous ATECC508A, a specialized security chip from Atmel, with an additional layer of security supervision delivered by dedicated microcontroller, the SAML21. This architecture isolates the key store from direct attacks by the host computer and also enables token-based security suites to be implemented. Layered around that is the zymkey security API and physical tamper sensors for detection of perimeter and hardware breaches.

    Generating keys, injecting keys

    Zymkey's primary mode of operation is to generate key pairs - a private key, and a public key - within the encryption engine. This key generation operation is performed inside the silicon, the private key never leaves the silicon and there are no operational or debug instructions available to read the private key. The private key is 'Private'.

    The corresponding public key can be accessed through the zymkey API to support digital signing, TLS and other assymetric key operations.

    An explanation of the magical workings of assymetric cryptography and public key infrastructure is beyond the scope of this article and generally not necessary for standard applications of zymkey. If you are interested to learn more then this is good starting place: Public Key Cryptography Wiki

    For applications that require an external key to be 'injected' and stored securely we generally recommend that the key be encrypted using zymkey and stored on SD card. This approach reduces the opportunities for hackers to gain access to the key store. OEM's wishing to inject large quantities of keys should contact Zymbit.

    Integrating keys into your application.

    The zymkey API makes it easy to integrate keys and other cryptographic services into your application. Examples of how this can be done are available at zymbit community pages.

  • AWS IoT integration, protecting private keys
  • OpenSSL, Apache setup, generating CSR
  • LUKS encryption of file systems
  • LUKS encryption of Docker containers

  • Further reading

  • Device ID and authentication with zymkey.
  • Protecting Pi in the real world.
  • Key Management
  • ATECC508A overview