Skip to main content
shopping_basket Basket 0
Log in

Industrial Security Part 5: About embedded authentication

After explaining several essential topics of cryptology and IT security in parts 1 to 4, I want to show you a perfect implementation of these methods. Here is the scenario: Vendor Sir Barcley is producing a system called PrintoFax with built-in computing intelligence at his factory. Pete owns one of these systems. He frequently needs to replace a device called PrintoInk which OEM Helen provides. But there is Susan, who is producing a cheap copy of PrintoInk devices. This bothers Helen and Sir Barcley because their customers might experience malfunctions of the system when using the inferior copied devices. Pete is ambiguous about buying a reasonable copy or rather staying with a quality proven OEM device. At least he would like to have a chance to reliably know what he is buying. Here comes the solution:

The device (PrintoInk) is equipped with Maxim’s DS28E38 chip. When Pete replaces one of the devices and plugs it into the system (PrintoFax), a 1-Wire bus connection between system and device is established. The system is operating a verification algorithm to verify that the device is an original produced at the OEM’s factory. The system indicates the result for Pete’s convenience, and Sir Barcley might decide to prohibit the use of rip-offs by disabling any further functions of the system until an OEM device is plugged in.

But how can this small chip guarantee a valid verification? And why can’t Susan just copy that chip?

Implementation of a PKI into hardware

Remember what we learned about a PKI (public key infrastructure) in part 4? You can implement such infrastructure into hardware. The OEM generates private and public key pairs. The secret keys are placed into the devices’ authenticator chips. For each device, she hands over the public key and other individual data (like the serial number of the device) to a CA (it could be herself). The CA generates a certificate from the public key and individual data of the device. The CA signs the certificate with the CA’s private key and hands over the certificate to the OEM. The OEM puts the individual certificates into the devices’ authenticator. The CA puts his single public key into each of the systems (we refer now to as “host”) which will later need to prove the authenticity of the devices. The host does this job by reading the plain individual data (serial number and device’s public key) and the certificate from the authenticator. It uses these data objects and the CA’s public key to run a verification algorithm. The result reliably tells the system if the certificate is authentic or not.


If the certificate is authentic, the public key inside the authenticator must be generated by the OEM and should belong to the individual device. In a second step, the host then checks if the public key really does belong to the particular device’s authenticator. It “challenges” the authenticator to use its private key to sign a random message from the host and send it back. The host can check the result using a verification algorithm and the public key.

But let’s have a closer look at how this PKI can be implemented in a real factory world.

Steps to do at the factory site

Sir Barcley knows the topmost secret: A key-pair of an asymmetric keys aKpriv and aKpub. As we will need more keys, we are distinguishing them by adding another letter. This pair gets an “F” for “factory”. He is running a certification service for the OEM on one of his computers. This keeps a secret private key aKprivF and a public key aKpubF. The computer is locked up in a high-security sector of the factory behind a couple of firewalls. Susan would have no chance to spy out the aKprivF without getting grilled by the high-voltage fence around the security sector.

Sir Barcley does place a copy of sKpubF on every PrintoFax system (host) which leaves the factory. He does not want to give Susan any chance to replace that key on the systems, so she is using a “secure boot” procedure on the systems. This ensures that the firmware (including the aKpubF) can’t be changed.

During EOL testing OEM Helen requests a certificate from Sir Barcley’s computer. It is generating a certificate signed with Sir Barcley’s private key. The computer returns the certificate to Helen, and she puts it into the authenticator’s memory. So each device gets a certificate during EOL testing.

The systems later can read the certificates from the devices. By using the aKpubF stored in each system, they can rely on the certificate to be issued by the CA and not bad Susan.

But you know from part 4 that being able to decrypt the certificate is not the final aim of this concept. Susan could simply buy a device and copy the certificate in her own rip-offs. So there is more:


It’s all about the content of the certificate which needs to be individual and strongly bound to the hardware of the individual device. Let’s assume Helen would simply put a unique device ID into the certificate. If Susan could build devices which would all have the ID of the one she took the certificate from, then she would be the winner. So Maxim has provided more than this. Yes, each chip has a unique ID (having the two components “MAN” and “ROM”). But each chip also has a pair of asymmetric keys aKprivD and aKpubD. “D” stands for “device” to distinguish them from the factories’ keys. The devices hand over their individual ID (MAN and ROM) as well as their individual public Key (also called “Q(x,y)”, which in ECDSA is composed of the two values x and y) to the EOL tester. The EOL tester calculates the hash h(m) from this data m and requests a certificate from the CA computer. The CA computer is signing the hash with its private key aKprivF (called “d” in ECDSA).  Please read the parts 3 and 4 if you do not know “hash”, “ECC”, “signature” and so on). The CA computer uses ECDSA (the elliptic curve digital signature algorithm) and needs its RNG (random number generator) to generate an ”ephemeral” key k. The result is a digital signature. As we have learned in part 4, it consists of the two parts “r” and “s”.  These two values are returned to the EOL tester and get stored in the device’s authenticator memory.

Steps to do at the user site


At Pete’s place, his system needs to verify the authenticity of his devices. His system (host) reads the memory of the authenticator chip of the device under test. It gets MAN, ROM, aKpubD and the signature r/s. Using the public key aKpubF which it has obtained from the factory, it verifies the signature (signed with the private co-key of the factory, aKprivF). As soon as the signature is proven to be authentic (i.e. produced with the unique private key from the factory) it knows that the certificate with MAN, ROM and aKpubD can’t be fake data provided by Susan.


The system now needs to prove that the certificate belongs to this unique device. It uses the public device key (aKpubD) to “challenge” the device. It sends a random number to the device. The device responds with an ECDSA signature of a message digest (using its private key aKprivD). The message digest is a SHA2 hash of the challenge, ROMID, MANID and the data content of the authenticators custom memory page. The system calculates the same hash (it can read the plain data from the authenticator). It uses this hash and the signature from the device together with the device’s public key as input for the ECDSA verification algorithm. A pass verifies the match of device private and public keys. Bingo! There we are: The device is authentic because there can’t be more than one unique device with this private key! Really? Well, that’s a good question and Maxim has even taken care for this challenge…

More features than you would imagine

Having read part 1, you already know that there is no perfect security. Whenever you implemented the next step of security, you can be sure that Susan will find a way to conquer it. Maybe she would be able to just simply copy the authenticator chip by finding a method to read its content. So, first of all, we need excellent read protection of the private key. But Susan could also analyse the crypto chip by sophisticated methods using so-called “side attacks” (measuring timings and currents from the chip architecture) and finally find out the private key of one of the chips. She then could mass-produce her rip-off chips all with the identically copied certificate and private key. Remember that the cost is always affordable when the profit will pay for it. But here is the good news:

The Maxim  DS28E38 does not even permanently store a private key. The private key is generated “on the fly” when it is needed. Well, when I said “does not store”, that was only partly true. Of course, it needs some kind of storage to reproduce the private key which must be unique. The way it can reproduce this unique key is called “chip DNA”. When you mass-produce identical chips, each silicon chip has a unique fingerprint in its internal structure. This fingerprint usually does not interfere with the ordinary chip functionality. But yet it can be detected and ”read” by the internal electronics. The DS28E38 uses this fingerprint to reproduce a unique internal private key. There is no known method to read this fingerprint from outside the chip. Whenever you would use known side attacks to read the fingerprint, you would disturb the silicon structure in such a way that the fingerprint would be changed. So you have some kind of “self-protecting” secret.


Taken with permission from “DeepCover Secure Authenticator with 1-Wire ECDSA and 1Kb User EEPROM”, , © 2017 Maxim Integrated Products, Inc., All Rights Reserved.

There are further functions of the chip which allow for sophisticated use cases:

You can use a 17-bit write-once, then read-only decrement counter. The system can keep track of certain actions done in combination with a specific device. Each time the action takes place, it decrements the counter. The counter value can be signed by the chip, which prohibits faking the value by redirecting a request from the host. This is a secure way to limit the devices life cycle not by time but by use.

Imagine a different use case: The device would be some kind of hardware dongle. If you plug it into the system, the system would e.g. go into an administration mode. But each time the device has been used for an act of administration, the internal counter is decremented. The system will refuse to go into administration mode when the counter has reached zero. So the user gets a limited number of administration accesses to systems where the manufacturer can choose the limit by writing any 17-bit number into the device’s counter during an EOL test.

There is up to 64 Byte of EEPROM space in a “user memory” where the system or the factory can place information and then switch the access to read-only mode. The factory could, e.g. put another certificate there which contains authentic data describing permissions of the device’s owner. The factory could produce devices for specific role owners (e.g. admin, maintenance, programmer) with the role permits written into the user memory. You already know that this data is securely transmitted to the host by including it into a signature.


Taken with permission from “DeepCover Secure Authenticator with 1-Wire ECDSA and 1Kb User EEPROM”, , © 2017 Maxim Integrated Products, Inc., All Rights Reserved.

Isn’t that fantastic? A 3 mm x 3 mm chip uses just three pins to offer all these features for less than two dollars. All you need to implement the features of your product is to understand what we have discussed in the last five parts of this series. I will take you with me on a journey through the DS28E38‘s evaluation kit soon. I will also list some other chips with security functions. But the next part will be a more general explanation of the challenge-response-concept.

Previous parts 1, 2, 3 & 4


Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and analogue electronics for neuroscience labs (and his MD grade). Later: database engineering, C++, C#, industrial hard- and software developer (transport, automotive, automation). Designed and constructed the open-source PLC / IPC "Revolution Pi". Now offering advanced development and exceptional exhibits.
DesignSpark Electrical Logolinkedin