Securing Raspberry Pi
Encrypted file system, HSM, TPM, identity
Essential security for Raspberry Pi
The Raspberry Pi is an awesome computing platform with growing numbers being embedded into real-world commercial and industrial applications. When deployed in the wild, beyond the security of a firewall or physical facility, a higher standard of security is required. Devices in the real world are often unattended and have intermittent connectivity to communications and power; this makes them highly vulnerable to physical tampering, exposing critical data, code and credentials stored on the SD card.
Security is not an absolute science. Start with the basics (most people don’t) and build layers of security that are coherent and appropriate for the value of the digital assets at risk. Developers often deploy code that is worth hundreds of thousands of dollars, even millions, so take a little time to make sure you put the essentials in place, even if it is the last thing you do.
- Password hygiene – replace defaults with strong username & passwords, unique to each device.
- Unique device identity – use a multi-factor system based fingerprint.
- Encrypt data and file systems – use dmcrypt/LUKS, libgcrypt, or others.
- Encrypt communication channels – use OpenSSL, or similar.
- Store keys and credentials in a hardware root of trust – not on the SD card.
- Physical device integrity – detect and respond to physical tampering or perimeter breach.
Layered security provides defence in depth
Security is not binary, but in general its true that each additional layer of security makes it harder to penetrate to the core assets inside a device. This idea is often referred to as ‘defence-in-depth’.Good cyberphysical security is anchored to a solid ‘Hardware Root of Trust’ – sometimes refered to as secure-element – to which each subsequent layer is tied and integrated into a coherent multi-step security schema that looks something like this:
1. Check device integrity – perimeter, power, other
2. Authenticate device against known identity
3. Enable crypto and key services
4. Execute secure crypto services
5. Repeat, continuously, independently from host power or state
Hardware root of trust
At the core of every security module is hardware root of trust, or secure element. These specialized components provide key generation, storage and cryptographic functions in an ultra-secure silicon protected by tamper evident microgrid and small attack surface. Zymbit’s series-4 security modules use the ATECC508A or ATECC608A, a secure element chip from MicroChip, protected with an additional layer of security supervision delivered by dedicated microcontroller. Zymbits two processor architecture isolates the key store from direct attacks by the host computer and provides a more robust and flexible method for device identity and physical security.
Security module architecture
Zymbit security modules use a dual secure-processor architecture. A security supervisor chip manages all interfaces with the outside world – physical and host – while providing an isolation barrier to the hardware root of trust and cryptographic engine and key stores. This architecture provides a robust yet flexible method of integrating security modules into real world applications.
Key generation and storage
Encryption 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 generate and 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 are often stored on the removable SD card. This is a big problem because the SD card is easily removed and the keys quickly copied.
A core function of any security modules is to generate, store and manage keys in a secure manner. In Zymbit security modules, keys are generated inside the secure element, and in the case of asymmetric keys pairs the private-key never leaves the security of the silicon; there aren’t even operational or debug instructions available to read the private-key. The private-key is ‘Private’.
The corresponding public key can be accessed through the zymbit API to support digital signing, TLS and other assymetric key operations.
Devices that are unattended are exposed to physical attacks; common exploits include removing the SD card, probing of data buses or attaching debug tools. Providing some level of physical protection is a good starting point but it’s often overlooked because its seems low tech or hard to execute.
Zymbit security modules provide two perimeter detect circuits which, if broken, signal a breach in the physical perimeter of the host device. Such an event can be used to flag a breach, lock up or permanently destroy keys.
Device integrity, identity and authentication
Measuring the integrity of a device and confirming (authenticating) it’s identity are interelated activities. The first step is to establish a device identity in a ‘trusted environment’ that you control or trust; your lab, your manufacturing partner, your approved field service franchise. Zymbit security modules automatically generate a multi-factor device identity by measuring various parameters (factors) of the host computer and combining these with additional factors that are unique to each instance of security module. The result is essentially a fingerprint of the device. In a process called ‘binding’ the fingerprint is permanently and secretly stored inside the zymbit security module.
At bootup and on a periodic basis the security module will measure the physical integrity of the device – perimeter, power quality, shock – and the identity. If either of these measurements are false, then the security module will remain locked, or self destruct, depending up how it has been configured. If both measurements are true, then the key management and cryptoengine services are enabled by the security supervisor.
Zymbit hardware security modules for Raspberry Pi.
Zymbit security modules are designed to be easy to integrate by software developers, late in the design cycle. Software APIs are available in Python, C, C++, and hardware modules plug directly into the GPIO header of Raspberry Pi, and other single board computers with compatible GPIO headers.