Security Module for Raspberry Pi

Measured identity, data encryption and signing, anchored to a hardware root of trust with layered physical and digital security. 

 

Why secure 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, making it easy to extract sensitive data, proprietary software and credentials that are stored on the SD card.

 

Security checklist

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 is not an absolute science, so we suggest you 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 you need to protect. 

• 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.

 

Use layered security for defense in depth

Security is not binary, or black and white.  Its more useful to think in terms of shades of grey, or layered security:  each additional layer makes it harder for an attacker to penetrate to the core digital assets inside a device. This idea is often referred to as ‘defense-in-depth’.

Good cyberphysical security is anchored to a solid ‘Hardware Root of Trust’ – sometimes referred to as secure-element – to which each subsequent layer is tied and integrated into a coherent multi-level 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 hardware security modules use the ATECC508 / ATECC608 family of  secure elements from MicroChip.  The secure element is further protected with an additional layer of security provided by dedicated ‘security supervisor’ microcontroller. Zymbit’s dual secure processor architecture isolates the key store from direct attacks from the host computer and provides a more robust and flexible method for device identity and physical security.

Zymbit is a MicroChip Security Design Partner > 

 

Dual secure-processor architecture

Zymbit security modules use a dual secure-processor architecture. A security supervisor microcontroller 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.

 

 

Secure key generation and storage

Encryption keys are a fundamental component of secure and trusted systems. Keys are used

• Lock and unlock encrypted data volumes
• Sign and verify files, 
• Protect trusted communication channels
• 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 Raspberry Pi and similar single board computers, keys are often generated in software and 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 module 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 asymmetric key operations.

 

Physical security matters

Devices that are unattended are exposed to physical attacks; common exploits include removing the SD card, probing data buses, attaching debug tools and even side-channel power analysis and glitching attacks. 

Learn how easy it is to steal encryption keys from a physically exposed device, check out these fun examples of side channel attacks:  

• Breaking AES with ChipWhisperer – Piece of cake (Side Channel Analysis 100)
• How to Steal an Encryption Key With a €20 Software Defined Radio and €200 of Parts

Despite the value of physical protection, it is often overlooked because its feels low tech and can be tricky to execute in a reliable manner.  Zymbit security modules make it easy too add physical security to a design. Each modules comes with 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-event in software and lock up or permanently destroy keys.

Device integrity, identity and authentication

To ensure the safe and secure operation of a device, the following conditions should be true: 

• Device has physical integrity – no breaches of physical perimeter.
• Devices has stable power and temperature conditions – no power and freeze attacks. 
• Device has identifiable system components – measured identity & authentication.

Once these conditions are true, a system should provide autonomous access (no person or external service required) to the cryptographic services required to support operations like secure boot, file decryption and secure communications.  

 

Autonomous operation

Zymbit security modules automatically generate a multi-factor device identity by measuring various system parameters (factors) of the host computer and combining these with additional factors that are unique to each instance of security module. The result is a unique device ‘fingerprint’ which is stored inside the Zymbit security module.  A process called ‘binding’ is use to permanently associate and lock the fingerprint to the device hardware. Removal or replacement of the SD card, computer or zymbit security module, will result in a change in measured fingerprint and failure to authenticate. 

Zymbit security modules continuously check the physical integrity of the device, namely perimeter, power quality, temperature and shock. If any of the parameters fall outside expected norms, then the security module will deny cryptographic services. Additional policies can be configured to ‘self destruct’ by permanently destroying key material.  

 

 

Zymbit security modules

Zymbit security modules are designed to protect embedded Linux computers in unattended applications. Modules are easy to integrate and tough to infiltrate and are available with different forms and features. 

 

Learn more >