//php echo do_shortcode(‘[responsivevoice_button voice=”US English Male” buttontext=”Listen to Post”]’) ?>
Cryptographic keys are at the heart of security solutions used across the Internet of Things (IoT). These keys can reside within chips—MPUs, for example—but they must be customized for every device within an IoT network. From a supply chain standpoint, once chips are customized, they can’t be returned or re-sold. This ties up a lot of dollars in inventory. Moreover, provisioning, or loading, these keys onto chips is complex and expensive. Prior to 2015, developers had to order a minimum of 100,000 units to get fully customized security solutions.
EE Times recently sat down with Xavier Bignalet, security product marketing manager, Microchip Technology, to discuss the supply chain implications for solutions that are scalable, cost-effective and most of all secure.
Xavier, we know supply chain partners play a role in provisioning keys, yet the process remains complex and expensive. What are the market challenges, as you see them?
The big dilemma is: at which point in the supply chain customization kicks in. The marketplace is extremely fragmented from a volume standpoint. I think everybody started to realize that a couple of years ago. So you end up with a market where you need anywhere from 10 to a million keys because of the diversity of IoT projects.
And that’s the paradox: Everyone wants to sell units out the door but each piece of silicon is customized down to a single unit due to cryptographic keys.
It’s a logistics problem coupled with a security ecosystem problem. The more parties—distributors or contract manufacturers for example—the keys pass through the more opportunities there are for exposure or “leaks” of the cryptographic keys.
You have two different types of cryptographic keys: symmetric and asymmetric.
In a network, you have to authorize users to change and update things within an embedded system. So the question here is, how do you distribute keys inside this environment and how can you preserve the trust during development and deployment? Customers frequently ask us, “Where is your decryption key?” At one time or another, that key is going to be stored out in a memory zone.
The keys are the most critical piece of information in the system, no matter whether it’s connected or not. So you want to isolate [the keys] from everything and everyone. Now, how do you make them exist and load them into the semiconductor for any project size? That’s the big problem.
And ideally, you really need a team that understands all the cryptographic requirements that are needed and are versed in security requirements—the type of keys, the strength of keys, the cryptographic algorithm, all that stuff, line by line, use case by use case. That’s a lot of expertise.
One alternative for customers is to add a secure authentication IC, separate from an MPU or MCU. The device is a piece of silicon that’s equipped with physical security protections that physically separate the keys from the application code.
So now you need people and a tool, right? And that’s exactly how Microchip has organized its solution. We have a dedicated field application engineering team specialized in security that is able to use specifically developed tools to onboard at scale a wide variety of customers.
Wouldn’t the secure authentication IC be added to a customer’s bill of material?
Yes, but from a network perspective, your keys need to operate within a secure boundary. That’s where your unique keys are, whether they are symmetric or asymmetric. Within that secure boundary, it’s very important to have both the crypto engine and the keys in the same boundary. That’s the location where you build cryptographic responses to feed to the application code.
A secure element is one way to decrease security risks and cost. We’re dealing with secure memory with a crypto engine and some logic, and that’s all there is. Integrating such functions, including the physical protections inside a microcontroller, is very taxing. More taxing than keeping the secure authentication as a discrete architecture. It’s additional to the BOM but cheaper than an equivalent integrated solution.
But we also have another solution. The way Microchip sets up its infrastructure, we are able to securely provision keys on different customers with different project sizes, whether it’s a small project within a big corporation or a company just getting started. It’s really about project size, not about customer size.
Right. You still have the issue of scaling costs for lower volumes.
And we have a tool called the Trust Platform Design Suite that feeds device configuration, as well as kicks off the secret exchange needed for our secure key provisioning service. The provisioning is all done within Microchip audited factories. Then we drop-ship the secure elements anywhere in the world, following relevant export-control regulations
How does that address cost and scale?
It’s simplified. We know use cases—threats—because we’ve defined them with our customers. Those use cases exist because we have supported threat-model exercises before. So we now offer an optimized “laundry list” of use cases. Now you take the silicon, which is a blank page. Whatever the silicon, maybe just a microcontroller, you need to implement those use cases. That’s knowledge, and that knowledge needs to fill into what turns into code and configuration.
That’s where the tool comes in. We have a 3-tier approach. The first tier is called Trust & Go. The second tier is TrustFlex. And the third tier is TrustCustom. We provide software and kits that customers can use. That includes all the device supports because we have that trust platform, which is a tool that helps with that very deep customization. We use configurators to help set up the use cases down to the bits and bytes.
Essentially, we started to say, “OK, those are the most common security use cases where being requested to support, let’s program them into the silicon for the customer instead of waiting for the customer to ask questions.” And this is how TrustFlex came about. We started with the memory zone of those devices.
TrustFlex provides the flexibility for users to bring their own credentials to those pre-sets devices. This tier offers the silicon with secure key provisioning starting at 2,000 units minimum ordering quantity.
The questions customers ask are about key generation are: “Where did you get them? How much are you going to charge? How do you push [keys] into the device?” There were also questions about PKI, public key infrastructure and certificates. We’re going to program them into the Trust & Go silicon, so you end up with not just the secure element but also the certificates.
Trust & Go targets orders that can be as low as 10 units.
Once we ship the parts to the client, we also construct what we call the manifest file. It’s a digital file that will contain all the serial numbers, certificates and public keys associated with the project. We provision with the private key and we digitally deliver the manifest to customers.
And that’s the supply chain secret. All the customer has to do is upload that manifest that has all the public credentials, and the non-sensitive credentials are in their cloud accounts. We’ve worked with partners to make sure all the APIs were in place and they have all been delivered. And then that’s what you established, the authentication between the cloud platform and the silicon itself.
