Authors: Xavier Bignalet, Product Line Manager, Microchip Technology Inc.
Nicolas Demoulin, EMEA Marketing Director – Security Products, Microchip Technology Inc.
We hear a lot about device management, but what exactly is it, how do we implement it, and how do we approach device management during the deployment phase and when the products are in the field?
Some large companies have started doing it themselves, but what they manage is basically the lifetime of the certificate. If we look at the changes in safety standards, the main ones are EN 303645, the initial safety standard in Europe, OCPP and IEC15118 for electric vehicle charging, from the Open Charge Alliance, Matter and many others.
All of them require revoking the certificate. This is good, but when we look for a new certificate a few things are required from this phase on. It is necessary to renew the certificate after revoking the previous one, and before something goes wrong, the connectivity related to the certificates will have to be audited to verify, for example, that there is not a DDoS attack. Some companies do this better than others, but standards require more and more certificate rotations, which is not an easy task.
If we think of it as a four-step process, the first step is to import the device. If it's an embedded device made up of silicon devices that's going to connect to a cloud platform, how do you import your device's identity, which is represented by a certificate chain, into pretty much any cloud platform? The second step, when the device is already represented by the certificate on a cloud platform, is how to revoke the device. And once revoked, you'll want to renew the identity. Next you'll want to audit it. So there are four steps: import, revoke, rotate and audit.
Import before product launch
The import must be carried out before launching the product on the market. If we take thermostats for a house as an example, before the customer buys the thermostat, the company that manufactures the product has to import the device into its platform. The company must then be in a position to transfer ownership.
To import the fleet on the platform, the company of this product must choose the certifying authority. You can choose from numerous providers or you can be your own authorities. Companies that choose this route essentially become a Microchip customer. Microchip initiates a secret exchange with its secure hardware module in its factories and in its secure element, and the customer itself. The customer signs a certificate request (CSR) and grants Microchip the authority to provision the secure element on their behalf with the credential associated with that certificate chain. This establishes a chain of trust between Microchip and the customer.
Microchip performs its secure provision using HSM, thus providing the keys within its secure element. What Microchip would recommend here is the TrustFLEX secure element as it is preconfigured to know exactly what your actual implementation will be in practice.
Once the application that uses the birth certificate and key verification is defined, the next step is to upload the embedded birth certificate to the secure element.
The birth certificate can be obtained in two ways: from the PKI tailored to the client or the client uses the birth certificate provided by Microchip. After the birth certificate is uploaded to the cloud platform, the device fleet, thermostat, or any other product is put on hold until end customers purchase the product. The company then transfers ownership of the company to the customer in question, who will begin to bond with the thermostat they have purchased.
However, the useful life of the product continues; For example, when a house is sold and the thermostat is sold with it, what happens to the certificate? That's when revocation and rotation come into the picture. Revocation and renewal go hand in hand. If we simply revoke the certificate, it's as if the device is out of service. A renewal system allows assigning a new identity to the thermostat and linking it to a new user.
There is another case study that illustrates the need for rotation: the short-term rental market. Imagine the lock on a door that a tenant needs to open for a week, after which a different tenant has to access it.
The landlord will probably want different tenants to have different passwords, which would need to be changed weekly. That is when you can resort to certificate rotation and synchronize it with the rental companies' calendar to offer that experience to the user. It's all in sync with how well those certificates are revoked or renewed.
Once the new holder is verified, so that it is trusted by the platform, the chain of trust is preserved thanks to the management of the certificate chain. The result is the generation of a new owner that the device management platform can take over and control depending on customer needs, customer requirements or the situation.
Microchip's ATEC608 TrustFLEX and another similar device, the TA100, are intended for this type of device management. They go beyond device management by offering secure authentication, secure boot, and OTA verification. Key verification must be performed within those safe limits of the silicon, which allows for key rotation once they have been verified. There are many other possible cases or one-time authentication.
Change management
All of the above describes the management of the device from the point of view of the secure element. The market sees the locked secure element that does not allow anything to be changed, but this is not entirely true. We may establish policies to effect configuration changes. This is how the TrustFLEX is configured. It allows you to do this, and the TA100 is probably even more powerful thanks to the variety of rights and permissions it can handle.
If we think about the difficulties, they require skills to answer questions like the following: How to implement the management of that device worldwide? How to implement device management during the prototype development phase and during the production phase? What happens when the product is marketed and subsequently?
When you want to withdraw the product from the market, you have to deactivate it so that it can no longer be used. This allows companies to manage their warranties in a very controlled way, one that is better than just returning it without anyone knowing what to do next. A company could request a revocation at the time the device is returned to the store and later learn that that certificate is associated with a product with a money-back guarantee.
There is also the issue of acquisitions. Let's say our thermostat company grows and acquires another thermostat company. What happens then with the architecture of the first certificate? How will it evolve after the acquisition of that company? Device management services can help in these cases.
At Microchip we would like to encourage our customers to implement device management for several reasons. Regulation, transfer of ownership, scalability, and product warranty expiration are factors driving the market to adopt device management.
