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!
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.
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:
- 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).
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.
Like this:
Like Loading...
Atmel | Bits & Pieces 