Secure System on Module (SSOM)
At the foundation of a connected gateway for the Internet of Things
Security is always a risk function and not an absolute.
[Dr. Craig Wright, while pretending he’s indeed Mr. Satoshi Nakamoto or the misterious inventor of Bitcoin]
A tale of secure identification
The latest story around Mr. Satoshi Nakamoto is an example of how difficult a task any product must perform while talking to some cloud service in the Internet. Mr. Nakamoto is not a real person. He’s instead the name used by a person that first depicted how the Bitcoin architecture should work but never revealed his identity. From time to time researchers try to identify the real Mr. Nakamoto without success. Recently (at the time of this writing) the Australian businessman and inventor Dr. Craig Wright claimed that he’s indeed Mr. Nakamoto. How do you prove that you’re the real person behind some entity that appeared for years on the Internet, produced documents, started chat conversations, exchanged email messages, was an endpoint for transactions? Dr. Wright wanted to publish evidence that he possessed a private key able to digitally sign documents that already appeared on the Internet in the past and were believed to originate from the real Mr. Nakamoto.
Today this evidence is under serious doubts and perhaps Mr. Nakamoto is still an unknown person (or group of persons). The same principle applies to products that need to talk to Cloud service on the Internet: how can I (the owner or producer of the system) be sure that exactly that product is talking exactly with that service? Isn’t it too simple for someone to impersonate the device or the service and start talking in fake ways?
Identify connected products
Any product and service must provide credentials or evidence that it can sign pieces of information in a way that is unique and previously known by parties. This is the main security measure in the age of the Internet of Things, and the first specification a design engineer should take care of while talking to the product manager. It’s not good excuse for not implementing it a missing specification about identification; sooner or later someone will perhaps pay for the missing feature.
Edge computing vs Cloud computing
Edge compunting happens each time a product itself (or a very small gateway for a range of products located in the same building or room) produces and consumes information that comes and goes to the surrounding environment, while talking to another party that is not located in the same neighborhood usign the Internet as a channel.
Edge: computing where the data originates (industrial, process automation)
Cloud computing happens usually on the other side (of the Internet) where all products that belong to a class store, retrieve and compute aggregated information.
Cloud: computing where the data is stored for future usage and for cooperation between actors
Edge vs cloud is a model of communication at the foundation of the Internet of Things paradigm enabling a range of functionalities difficult to imagine before.
The edge and the cloud are both products and services that talk each other, whose identification is critical to safety and privacy. At the same time information exchanged between the parties should not be available to anyone able to listen on the same conversation.
Hacking the kettle
Don’t understimate the effects of an intrusion. As an example think of any device that you put inside your home or company, requiring you to enable and configure Wifi access to your building access point. All devices will have private details maintained inside their memory, that makes it possible for anyone stealing the content to enter your own network and start spying on your very private traffic.
Difficult to believe? Recently a case became famous of an Internet connected kettle that proved to be easily hacked in a way that makes it possible for anyone to collect Wifi passwords from owners of this product model. The same hacking may apply to any product designed to store security related information. The main point here is that it doesn’t matter which functionality the product performs, and what kind of information the device needs to exchange, as long as it’s connected to a Cloud service on the Internet and for doing so it needs to maintain access credentials for local, remote, end to end or end to service secure log in.
Search engines for vulnerable interfaces
The very common functionalities found in a house (fridge, kettle, light, door bell) and company (telephone, employee presence log, heating and chilling systems) connected to the Internet are the most valuable hacking doors for masses of curions or malicious developers. The simplest and commonly found is a functionality, the wider is the interest because of the product being well known and diffused on the market.
The impact of hacking and penetrating a product is often very limited over the functionalities of the device itself: stealing Wifi passwords using the connected kettle was not a proof of concept for “let’s prepare a tea for free”, instead it was amazing how simple can be to start sniffing your private Wifi network without ever entering the doors of your house or office.
While hacking some very complicated and difficult to understand office firewall or industrial machinery doesn’t fit the needs for newspaper or blog content, hacking the fridge or car or door bell is nearly perfect to feed something titled “the danger of living in a connected world” that soon thousands of curious readers will share on their socials. Negative marketing effect can be unrecoverable.
Today serach engines exist for vulnerable interfaces: automatic crawlers searching for backdoors and poorely secured services exposed on the Internet, ready to be listed. You can easly find catalogues of available security webcams, open routers, control panels for industrial plants. Connecting and interacting is as easy as reading the latest news on your favourite online newspaper.
Secure by design, secure by default
There’s no point in explaining the client how to proactively secure the latest connected product out of the box if it’s way to easy to avoid the guidelines. The rule is: design your next product to be secure and sell it configured to be secure by default. Or in case this is not affordable be prepared to be listed as potentially unsecure (which may be acceptable in case of very high volumes and very good marketing department).
An example of a secure by default product is one that owns a unique default user/password pair (for some login operation), forcing users to change it with an equally strong one at its first usage. This is expensive and annoying, but unavoidable when an access breach is too big a damage.
Extremely secure products
Enabling secure identification and communication for a product may involve many different layers of measures, not excluding a carefully written use case model that makes it possible for the design engineer to forecast all potential weakening operations by the user
Examples are listed here:
- localy storing credentials in a unhackable way;
- securely provisioning credentials during production;
- securely upgrade credentials and algorithms;
- performing calculations on messages in unspyable ways.
The impressive list of security components offered by ViggenTwo and its unique NXP iMX6UL ARM-based CPU is a good example and a sound starting point for an extremely secure product design. But keep in mind that security is involved in all steps during the design and production of a new device, including (perhaps most importantly) while deciding how and when the product will be connected to a cloud service or partner. Use cases play an important role in determining exactly the number and complexity of security measures that a device should implement, summing up to a product cost that may or may not be affordable for the business model. Starting with a CPU platform offering the maximum range of secure components as an option makes taking a decision simple and effective without loosing opportunities.
- High Assurance Boot (HAB) feature in the System Boot up to RSA-4096 signature verification
- Secure Non Volatile Storage (SNVS)
- TrustZone (TZ) Architecture in the ARM Cortex A7 Platform, TrustZone aware Interrupt Controller (GIC) and TrustZone Watchdog Timer (WDOG-2)
- TrustZone Address Space Controller (TZC-380) — providing security address region control functions on DDR memory space
- On-chip RAM (OCRAM) with TrustZone protection using OCRAM controller
- 64 Kbyte of on-chip Secure RAM
- On chip OTP (OCOTP) with on-chip electrical fuses
- Central Security Unit (CSU)
- Secure JTAG Controller (SJC)
- Locked mode in the Smart Direct Memory Access (SDMA) controller
- DryICE (real-time monitors for frequency, temperature and voltage)
- Several tamper pins with 5 active tamper detection sources support
- Hardware Cryptographic Accelerators:
- Symmetric: AES-128, AES-192, AES-256, DES, 3DES, and ARC4
- Hash Message Digest and HMAC: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and MD-5
- Public Key RSA (up to 4096 bit) and ECC (up to 1023 bit)
- DPA protection for 3DES engine
- True and Pseudo Random Number Generator
- Bus Encryption Engine (BEE)
Extending to the ViggenTwo IoT protyping platform, even more options are available:
- Latest generation NFC antenna
- Software programmable radio components for 2,4GHz and ISM bands
- Mounting options that enables for a very secure product assembly
Stefano Costa, design engineer, electronic systems
[Disclaimer: I work for Bluewind srl, the design house that sells the ViggenTwo SOM]
