Tag Archives: Zymbit.Orange

Enhance Raspberry Pi security with ZymKey


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.

Zymkey_004-1

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.

Zymkey-System-Overview-5-1

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.

Zymkey-System-Detail-1

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.

ZYMKEY-RPi-Annotated-2

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.

Why should you care about securing your IoT devices?


In this blog, Zymbit’s Scott Miller reviews some of the security features of Zymbit.Orange, how they work, and more importantly, why they matter.


Internet of Things (IoT) devices are, by nature, light on resources, diverse, widely proliferated and often at the ‘edge’ of the network beyond the control of any network administration; perfect ingredients for digital chaos and anarchy!

11245478_1091243084226194_4187312776059801785_n1

Cloud and big data applications depend on the quality of the data they ingest and key factors in quality are the authenticity, integrity and privacy of data they collect from the edge for the network. For the IoT to get real sustainable traction, the data coming from such edge devices must be “trusted” — from the core silicon all the way to the data services.

Fortunately, the Zymbit platform addresses many of the common security threats found in real world applications, whether using embedded ARM CPUs or Maker development boards. For Raspberry Pi and Arduino developers, Zymbit.Orange IoT motherboard makes it easy for developers to implement applications with secure access to communications interfaces as well as cryptographic services. What’s more, Zymbit.Orange can also be used standalone.

Zymbit-Orange-in-Hand-RPI-Atmel-Wing

In this blog, Zymbit VP of Embedded Scott Miller reviews some of the key security features of Zymbit.Orange, how they work, and more importantly, why they matter.

Who Should Read This Blog?

  • Anyone building IoT devices who is not a security expert, and doesn’t have the time or budget to become one;
  • Anyone who has deployed a connected embedded design;
  • Any Maker using Raspberry Pi or Arduino at the edge of the network… and now needs to add security.

Security Considerations for IoT Edge Devices

Securing IoT devices requires a system architecture that addresses some fundamental needs. Let’s take a look at them:

Data Privacy

Generally speaking, data should be kept private if it is integral to a proprietary process or if it is personal in nature. In each case, the data must be protected from prying eyes using encryption techniques that extend from the publishing source — the IoT edge device — to the cloud and onwards to subscribers. Additionally, the administrator of the data should be able to select who or what is able to subscribe to the data stream.

Data Authentication

Most data transactions/interactions are based upon the assumption that you know that the data really came from the presumed edge device. But how can you be sure? And, how can you be sure that your subscribers are receiving that authentic data?

In order for data to be trusted, it must be proven that it originated from a given edge device at the time that it was reported to have been recorded. Data authentication can be accomplished in many ways, but a digital signature is generally regarded as one of the most secure. One application of a digital signature applied to a timestamped block of data involves computing a one-way hash (e.g. SHA-256) of the timestamped data block and then asymmetrically encrypting the hash using a private key. When the data is received at the cloud, the hash of the data is computed and is compared to the hash that accompanied the data block after it is decrypted using the public key. If the hashes are the same, the data is optionally stored on the Zymbit cloud server along with the signature and transferred to the subscribers in a manner similar to the way the edge device transferred it to the cloud.

IP Protection & Threats from Counterfeits

Counterfeit products have an adverse economic impact on businesses and they also introduce serious vulnerability into enterprise systems. In the industrial sectors there have been numerous examples of ‘black market’ spares and generic devices that have introduced back doors into large scale enterprise systems, so much so that the U.S. Government has its own hotline for reporting such breaches.

Zymbit.Orange employs a number of architectural strategies with the goal of protecting software IP:

  • Isolate embedded services in special purpose hardware (e.g. dedicated embedded CPUs) so that it becomes harder to “hack & crack” an application running on an app CPU:

Security-Orange-Mother-Board-2

  • Some of these embedded services include:
    • Securely transacting data through otherwise unsecured channels:
      • Ethernet
      • Wi-Fi
      • Cellphone modem
      • Low-power radio
    • Interacting with and controlling attached user interfaces
    • Collecting physical data from sensors that are serviced by the embedded services hardware cluster
    • Generic encryption/decryption and data authentication/validation
    • Application image update and application health monitoring
  • These isolated embedded services require valid credentials in order to authenticate the users (e.g. applications running on Arduino or Raspberry Pi) of those services.
  • The special purpose CPUs must have their hard programming paths (e.g. JTAG or SWD) disabled so that the firmware that runs on them cannot be hijacked, replaced or corrupted.
  • Tamper event detection (e.g. attempts to open the case or manipulate the real time clock) — when a tamper event is detected various actions can be taken. Some of these actions might include:
    • Recording the tamper event
    • Deliberately “bricking” the system by erasing critical firmware
    • Erasing critical data which would take the system offline
    • The above actions can be configured by the system administrator
  • Application designers must have the means to encrypt and attach digital signatures for the application images they produce. Image decryption and signature validation are accomplished using the embedded services mentioned above.
  • Software updates can be exclusively disseminated via a secure cloud network utilizing encryption and image authentication.

Malicious Attack Defense

Although we aren’t hearing too much about it yet in the press, malicious attacks will soon be launched on IoT devices in a manner similar to PC viruses and cell phones today. Motivations will range from ‘hackers because they can’ to corporate espionage to cyber terrorism. And the the consequences of such attacks can be much more serious than data loss; many IoT devices interact with the physical world and that can cause bodily harm even loss of life. If you think this is sensationalist then wait until the first examples begin to surface.

The good news is that the serious innovators amongst us are thinking about this and looking for solid and practical solutions. Malicious attacks can be prevented or made very difficult to achieve using the same countermeasures we reviewed earlier in IP protection.

Securing Your Edge Devices – Raspberry Pi and Arduino, Too

We love the accessibility and affordability of open source devices and support the communities that are building amazing applications using Arduino and Raspberry Pi. Yet neither was designed with core security in mind and consequently, before applications can be scaled, their vulnerabilities need to be addressed. So let’s first explain their security shortcomings:

Security Vulnerabilities – Raspberry Pi:

  • No built in cryptographic engine
    • While the Pi can perform encryption in software, overall performance suffers as a result.
  • Removable SD card – no physical security
    • This means that an attacker with direct access to a Raspberry Pi based device can steal and clone the software and data on the card or deliberately corrupt the contents of the card.
  • No secure key store
    • Because the SD card is removable and the SD card is the only means of storing anything on the Pi, shared static keys and private certificates are now completely viewable and modifiable. Even if one chooses to encrypt a data volume for key and certificate storage, the key for decrypting the data volume must be exposed at some point. This fact makes data authentication on the Pi infeasible.
  • Susceptibility to power cycling exploits
    • Because there is frequently no intrusion detection or monitoring, simple repeated power cycling of the device may lead to failure and thus denial of service.
  • Lack of real-time clock
    • Prevents the system from responding properly in case of communications outage.

Security Vulnerabilities – Arduino:

  • No built in cryptographic engine
    • Crypto shields are available for purchase, but packaging Arduino shields tends to be very clumsy and difficult to deploy, not just due to the physical size issues associated with stacking shields but also because the Arduino shield framework suffers from resource bus (SPI/I2C) and GPIO pin allocation issues, so simply stacking a new shield on an Arduino may prove to be impossible when other shields are stacked.
  • No way to validate or secure the Arduino executable image if the debugging/programming interface is available. Even if an Arduino based “thing” had a crypto shield attached, an attacker with direct access could potentially:
    • Corrupt or erase the executable image.
    • Gain access to shared keys stored in RAM or flash.
    • “Patch” in their own code which would allow them to take control of the system.
  • Many Arduinos have very limited amounts of RAM and flash, making it extremely difficult to implement robust, secure communications solutions.

Zymbit has solved these problems for Raspberry Pi and Arduino developers by implementing an isolated security framework on the Zymbit.Orange IoT motherboard.

Adding Security With the Zymbit.Orange IoT Motherboard

At the heart for the Zymbit.Orange architecture is a Secure Services Cluster that isolates edge facing application CPUs from each other and from the outbound network connection. Isolation is achieved using a combination of data security (authenticate and encrypt), power security (turn off the CPU) and physical security (tamper proof and enclosure intrusion detection).

Security Orange Mother Board

We use Atmel silicon for all three aspects of security because their solutions are well thought out, affordable and have good performance characteristics.

Secure Silicon Review

The security services cluster within Zymbit.Orange is comprised of three blocks:

Secure Communications Hub

  • Atmel | SMART SAM E70 – high performance advanced connectivity CPU
  • Primary purpose:
    • Provides secure access to communications and UI interfaces
    • Performs tamper detection
    • Provides secure software updates for applications processors via the Zymbit cloud
  • CPU features:
    • 300MHz Cortex-M7
    • AES encryption engine
    • Low latency TRNG (True Random Number Generator)
    • Integrity Check Monitor (ICM) for generating and comparing digests of certain memory areas

Supervisory MPU

  • Atmel | SMART SAML21J17A – ultra low-power microcontroller unit
  • Primary purpose:
    • Power supervision and monitoring
    • Real-time clock
    • Secure programming and debugging interface for the on-board Arduino Zero application CPU
  • CPU features:
    • 48MHz Cortex-M0+
    • AES encryption engine
    • Low latency True Random Number Generator (TRNG)

Secure Key Generation and Storage

  • Atmel ATECC508
  • Primary purpose:
    • Asymmetric (public key) crypto
    • Digital signature generation/validation
    • Password validation
  • Features:
    • Secure key storage
    • Asymmetric encryption
    • Ephemeral key generation

Using these components, Zymbit.Orange provides a secure interface to all essential services for user applications running on the on-board Arduino Zero and/or Raspberry Pi. The dedicated on-board hardware significantly increases the overall security of these platforms without interfering with user applications. It is just as easy to develop an Arduino or Linux project on Zymbit.Orange from scratch or to adapt an existing application to take advantage of the on-board services because they do not interfere with the application CPU programmability.