Internet of Things (IoT) product companies have been struggling for years to simplify manufacturing, security, and provisioning. Well, I was just chatting with those clever lads and lasses at Infineon about their latest offering in the ongoing battle against the nefarious scoundrels who will steal or compromise your silicon chips if given half a chance. I can’t wait to tell you all about this, but first…
…all sorts of thoughts are bouncing around my poor old noggin with regard to SMADs (Steve and Max’s Awesome Displays) and robot heads and suchlike. This all started out when my chum Steve Manly and I set out to create 10-character displays, where each character is a modern incarnation of a 21-segment display from Victorian times (see Recreating Retro-Futuristic 21-Segment Victorian Displays).
As you may or may not know, I write a monthly column for Practical Electronics, which is the UK’s premier electronics, computing, and maker hobbyist magazine. I touched on our Victorian displays in a couple of my columns, but my readers want something they can build and play with themselves. Thus it was that Steve and I came up with our SMAD boards, each of which boasts 45 tricolor WS2812 LEDs. These LEDs are daisy-chained together, thereby allowing them to be controlled using a single digital microcontroller output pin.
Front view of a SMAD (Image source: Steve Manley)
SMADs are 80 x 80 mm in size, multiple SMADs can be daisy-chained together, and they have breakaway corners, which allow them to be used in circular frames if required.
We also created 3D printed “shells” that mount in front of the SMADs. These shells, which are 10 mm thick, are divided into segments that compartmentalize the light from the LEDs. We then mount a diffuser layer on the front of the shells, and top everything off with a 1 mm-thick facia (face plate).
We started with 29-segment shells that map onto the outlines shown on the board above. This gave us 13 segments with one LED, and 16 segments with two LEDs each. Since the color of each LED can be individually controlled, we can implement all sorts of interesting effects with the 2-LED segments.
I was a happy camper at this point — I was planning on building a pseudo robot head using two SMADs as eyes — but Steve couldn’t restrain himself from 3D printing some 45-segment shells with one LED in each segment, just to see what they would look like. Dang, but they do look good, allowing for the creation of some very tasty stained-glass effects.
As a result, I ended up using four SMADs to create two pseudo robot heads — one with 29-segment shells and the other with 45-segment shells (I’m toying with the idea of building a third head with one of each, where the 45-segment “eye” will look like it’s wearing a monocle). In fact, I just posted this video showing my two heads “talking” to each other using Morse code.
The reason I use the “pseudo” qualifier with respect to my current heads is that they are static platforms with no ability to move. But all that’s about to change because Steve and I are now working on creating heads that can pan-and-tilt, and that are equipped with SMAD eyes that can also pan-and-tilt, but that will be a story for another day. Suffice it to say that my next column here on EEJournal will take a deep dive into our SMADs, which isn’t something you expect to hear yourself say too often (that column will be posted on Tuesday 26 October 2021, so mark your calendar now).
Leaping from topic to topic with the agility of a young mountain goat, something else I was just ruminating on was how different things were in the not-so-distant past. A couple of years ago, for example, my chum Rick Curl came into town on business, and he stopped by my office to say “Hi.” Rick hails from the city of Birmingham, Alabama, which is about 90 miles south of Huntsville where I currently hang my hat.
On that trip, Rick brought a copy of a scrapbook that was created by his great-grandfather. This book is jam-packed with cuttings from the Birmingham News. The cutting shown on the right in the image below is from 1922, which was only two years after the first commercial radio broadcast.
Scrapbook (left) and cutting from a 1922 issue of the Birmingham News (right).
I find it strange to think how we have such amazing electronics systems these days, but that relatively few people have any interest in learning anything about them apart from how to use them. By comparison, although electronic systems were rudimentary at best in the 1920s, people were sufficiently interested in knowing more about them that the local newspaper would print “how to” articles of this ilk.
Counterfeiting has been around since people first appeared on the scene — not just currency, but anything that has a perceived value. I’m sure that folks in the 1920s had their own problems with counterfeiting, but I think they would have been horrified with how bad things have gotten today.
These days, for example, we have all sorts of issues with silicon chips destined for deployment in the connected devices that feed data to (and are fed data by) the IoT. As I wrote in a previous column, due to the actions of nefarious ne’er-do-wells, “[…] systems delivered to the end users may contain cloned parts, counterfeit parts, or cheap-and-cheerful substitutions that degrade the reliability of the system, thereby impacting the reputation of the creators of the system. In some cases, the entire system may be a phony reproduction, thereby denying the original designers of that system their rightful remuneration. And — believe it or not — all of this is the good news, because the worst-case scenario is that the firmware contains malware designed to compromise your systems and either steal, corrupt, or ransom your data.”
What we need are ways to provision our silicon chips in such a way as to extend the chain of trust all the way from the chips into the cloud. In this context, the term “provisioning” refers to the process of inserting cryptographic keys and other secure information into the silicon chips. Problems with legacy (we could be kind and say “traditional”) provisioning options include the fact that they require things like hardware security modules (HSMs) and complex manufacturing processes. In addition to substantial NRE and operational costs, these legacy solutions also leave us exposed to any contract manufacture vulnerabilities, especially in the case of contract manufacturers who work hand-in-hand with the cyberhacker arms (no pun intended) of nation states.
All of which leads us back to the chaps and chapesses at Infineon, who have been much on my mind recently. Just a few months ago, for example, I was telling the tale of how I became friends with Sree Harsha Angara at Cypress Semiconductor, which is now a part of Infineon (see Modus Toolbox ML, TinyML, and the AIoT). And only a few months before that, I was regaling you with Infineon’s OPTIGA Authenticate IDoT, whose role it is to verify and validate the identity of things (IDoT) (see ID for the IoT? We Need the IDoT!).
Well, I’m delighted to tell you that, today — literally as I pen these words — the guys and gals at Infineon have just launched their CIRRENT Cloud ID service, which automates cloud certificate provisioning and IoT device-to-cloud authentication. Employing simple, robust manufacturing processes, this high-security, low-risk, fully auditable and trackable solution replaces high NRE and operational costs with much lower BOM costs.
Cloud ID is quick and easy to set up. A user establishes a free CIRRENT account and configures cloud-to-cloud connection between the CIRRENT Cloud ID Service and their Product Cloud. A Cloud ID compatible batch of chips, containing X.509 certificates, is delivered to the manufacturing location where a technician registers them using a smartphone. The X.509 certificates are automatically provisioned to the product cloud. Users can log into the CIRRENT console to download their certificates, and to audit and track registrations and provisioning.
How Cloud ID works (Image source: Infineon)
I understand that this takes a bit of effort to wrap one’s brain around, so let’s come at things from a slightly different angle. Consider the image shown below. Let’s assume that you are a product company with your own product cloud; also, that you’ve established a free CIRRENT account with its accompanying CIRRENT cloud.
CIRRENT Cloud ID Extends Chain of Trust from Silicon to Cloud
(Image source: Infineon)
Let’s start in the lower left-hand corner with the fact that each chip has a unique X.509 Device Certificate (IDevID) built in. Asymmetric cryptography prevents security compromises because the private key never leaves the device.
A QR-code scan on the manufacturing line triggers registration of compatible chips and provisioning of the device certificates in your CIRRENT cloud (upper left-hand corner), which communicates this information to your product cloud (upper right-hand corner).
When your chip is built into an IoT product, and that product is deployed into the field (lower right-hand corner), and it is activated and starts communicating with your product cloud using secure encrypted channels, you can identify spoofed or unauthorized devices and prevent them from pumping compromised data into your product cloud.
Cloud ID is ideal for cloud-connected product companies in the industrial, consumer, healthcare, medical, and manufacturing industries. As usual, there’s far more information than I can cover in this column. Suffice it to say that Infineon CIRRENT Cloud ID is available now, and that you can learn more about it and try it out for yourself with a free virtual kit by visiting https://www.cypress.com/CIRRENTCLOUD_ID
As always, I welcome your erudite comments, insightful questions, and perceptive suggestions.
