Securing Your Raspberry Pi
Hardware Security Module for Raspberry Pi
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.
Security layers protect core digital assets
Security is not an absolute science but in general its true that each additional layer of security makes it harder to penetrate to the core of a device. Of course this assumes each layer is tightly integrated into a coherent and logical security schema:
Check device integrity > Authenticate device identity > Enable crypto and key services > Execute secure cryptoauthentication tasks
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.
Key & CryptoEngine services
At the core of every zymbit security module is hardware-rooted key store and companion encryption engine. These components are sometimes referred to as a 'secure element' or 'hardware root of trust'. Zymbit's series-4 security modules use the ATECC508A or ATECC608A, a specialized security chip from MicroChip, protected with an additional layer of security supervision delivered by dedicated microcontroller. This 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.
Key generation and storage
(Crypto) 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 zymbit security modules is to generate, store and manage keys in a secure manner. Keys are generated inside the secure silicon cryptoengine 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.
Integrating zymbit security modules into your application.
Zymbit security modules are designed to be easy to integrate. An API is 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.
Check out the following examples at the zymbit community