In this blog, Zymbit’s Scott Miller addresses some of the missing parts in the Raspberry Pi security equation.
Raspberry Pi is an awesome platform that offers people access to a full-fledged portable computing and Linux development environment. The board was originally designed for education, but has since been embedded into countless ‘real world’ applications that require remote access and a higher standard of security. One of, if not, the most notable omissions is the lack of a robust hardware-based security solution.
At this point, a number of people would stop here and say, “Scott, you can do security on RPi in software just fine with OpenSSL/SSH and libgcrypt. And especially with the Model 2, there are tons of CPU cycles left over.” Performance is not the primary concern when we think about security; the highest priority is to address the issue of “hackability,” particularly through remote access.
What do you mean by “hackability?”
Hackability is a term that refers to the ease by which an attacker can:
- take over a system;
- insert misleading or false data in a data stream;
- decrypt and view confidential data.
Perhaps the easiest way to accomplish any or all of the aforementioned goals is for the attacker to locate material relating to security keys. In other words, if an attacker can gain access to your secret keys, they can do all of the above.
Which security features are lacking from Raspberry Pi?
Aside from not having hardware-based security engines to do the heavy lifting, there’s no way to secure shared keys for symmetric cryptography or private keys for asymmetric cryptography.
Because all of your code and data live on a single SD card, you are exposed. Meaning, someone can simply remove the SD card, pop it into a PC and have possession of the keys and other sensitive material. This is particularly true when the device is remote and outside of your physical control. Even if you somehow try to obfuscate the keys, you are still not completely safe. Someone with enough motivation could reverse engineer or work around your scheme.
The best solution for protecting crypto keys is to ensure the secret key material can only be read by standalone crypto engines that run independently from the core application CPU. This basic feature is lacking in the Raspberry Pi.
Securing Raspberry Pi with silicon and software
With this in mind, Zymbit has decided to extract some of the core security features from the Zymbit.Orange and combine them into a tiny device that embeds onto the Raspberry Pi, providing seamless integration with Zymbit’s remote device management console. Meet the ZymKey!
ZymKey for secure remote device management
ZymKey brings together silicon, firmware drivers and software services into a coherent package that’s compatible with Zymbit’s secure IoT platform. This enables a Raspberry Pi to be accessed and managed remotely, firmware to be upgraded and access rights to be administered.
Secure software services
Zymbit’s Connect libraries enhance the security and utility of Raspberry Pi in the following ways:
- Add message authentication to egress messages to the Zymbit cloud by attaching a digital signature, which proves that the data originated to a specific Raspberry Pi/Key combination. (Meaning that it was not forged or substituted along the way).
- Assist in providing security certificates to the Zymbit cloud.
- Authenticate security certificates from the Zymbit cloud.
- Optionally help to encrypt/decrypt the content of messages to/from the Zymbit cloud.
Data that is encrypted/authenticated through ZymKey will be stored in this encrypted/authenticated form, thereby preserving the privacy and integrity of the data.
In addition to its standard attributes, developers can access lower level features through secure software services, including general cryptography (SHA-256 MAC and HMAC with secure keys, public key encryption/decryption), password validation, and ‘fingerprint’ services that bind together specific hardware configurations.
Stealth hardware
ZymKey’s low-profile hardware plugs directly into the Pi’s expansion header while still allowing Pi-Plates to be added on top. Lightweight firmware drivers run on the RPi core and interface with software services through zymbit.connect. It should also be noted that a USB device is in the works for other Linux boards.
At the heart of the ZymKey is the newly released ATECC508A CryptoAuthentication IC. Among some of its notable specs are:
- ECC asymmetric encryption engine
- SHA digest engine
- Random number generator
- Unique 72-bit ID
- Tamper prevention
- Secure memory for storing:
- Sensitive key material – an important thing to point out is that private keys are unreadable by the outside world and, as stated above, are only readable by the crypto engine.
- X.509 security certificates.
- Temporary items: nonces, random numbers, ephemeral keys
- Optional encryption of transmitted data across the I2C bus for times when sensitive material must be exchanged between the Raspberry Pi and the ATECC508A
Life without ZymKey
Raspberry Pi can be used with the Zymbit Connect service without the ZymKey; however, the addition of ZymKey ensures that communications with Zymbit services are secured to a higher standard. Private keys are unreadable by the outside world and usable only by the ATECC508A, thus making it difficult (if not practically impossible) to compromise.
Each ZymKey has a unique set of keys. So, if, on the off chance that a key is compromised, only that key is affected. Simply stated, if you have several Raspberry Pi/ZymKey pairs deployed and one is compromised, the others will still be secure.
Once again, it is certainly possible to achieve the above goals purely through software (OpenSSL/libgcrypt/libcrypto). However, especially regarding encryption paths, without ZymKey’s secure storage, key material must be stored on the Raspberry Pi’s SD card, exposing private keys for anyone to exploit.
Stay tuned! The ZymKey will be making its debut on Kickstarter in the coming days.
Like this:
Like Loading...
