Keywords: Digital security, authentication
Implementing Secure Authentication Without Being a Cryptography Expert
Digital security is one of the most publicized topics in electronic design today. Encryption is probably the first word that comes to mind when engineers think about security with authentication coming to mind for only a few of those same engineers. Yet, authentication is a fundamental function of secure devices or transactions.
Consider authentication in terms of home banking. Clearly, you’d want confidential information such as balances and account numbers to be encrypted. This is what happens when your internet browser displays the green lock with https://. That said, the first thing the internet browser checks when establishing a secure connection is that the bank website is genuine; in other words, it authenticates the bank website. Without authentication, you could be sending login and password information to a mock-up site and this indeed would be extremely harmful since these credentials can be further reused to run any kind of unauthorized transactions on behalf of an unsuspecting bank account holder. Secure internet browsing is generally achieved through the TLS/SSL protocol, which ensures authenticity and confidentiality aside from encryption.
Authentication is also important for Internet of Things (IoT) applications: an untrusted endpoint could put a whole infrastructure at risk. Let’s consider smart meters connected to the electrical power distribution system. An easy way for an attacker to disrupt the grid is to load a virus or malware into smart meters. Infected meters could then send fake messages to the infrastructure reflecting a power consumption largely different from the actual one, which in turn would cause the grid to become unbalanced. If the grid is overreporting, it would cause what seems like excess power to be diverted elsewhere, but if the grid is underreporting, it would cause a surge of power; in the worst case, the attack could trigger a full power outage by unbalancing the grid. In order to avoid this situation, both the hardware of the meter and its firmware must be verified as genuine. The process of authenticating the firmware is called secure boot.
Now that we understand the importance of it, let’s discuss how to implement authentication. The most trivial way to authenticate is to use a password. In our smart-meter example, the device could send a password to the grid-control system. The server would verify the password and then authorize further transactions. While this method is easy to understand, it is by far not the best one. An attacker could easily spy on the communication, record the password, and reuse it to authenticate a nongenuine piece of equipment. For this reason, we consider password-based authentication weak.
A much better way to perform authentication in the digital world is the challenge-response method. Let’s take a look at two flavors of the challenge-response method: one based on symmetric cryptography and another one based on asymmetric cryptography.
Symmetric cryptography-based authentication relies on a shared secret. The host and the device to be authenticated hold the same secret number. The host sends a random number, the challenge, to the device. The device computes a digital signature as a function of the secret and the challenge and sends it back to the host. The host then runs the same computation and compares the result. If both computations match, then the device is authenticated (Figure 1). In order to make sure that the result cannot be mimicked, it’s essential to use a function that has adequate mathematical properties. For example, making it impossible to retrieve the secret without the mandatory computation result. Secure hash functions, such as SHA-256, support these requirements. For the challenge-response method, the device proves it knows a secret without disclosing it. Even if an attacker were to intercept the communication, the attacker still cannot access the shared secret.
Figure 1. Authentication based on symmetric cryptography relies on a secret number shared between the host and the device.
Authentication based on asymmetric cryptography relies on two keys: a private and a public key. The private key is known only by the device to be authenticated, while the public key can be disclosed to any entity willing to authenticate the device. As in the previously discussed method, the host sends a challenge to the device. The device computes a signature based on the challenge and the private key and sends it back to the host (Figure 2). But here, the host uses the public key to verify the signature. It’s also critical that the function used to compute the signature has certain mathematic properties. The most commonly used functions for the asymmetric schemes are RSA and ECDSA. Here also, the device proves it has knowledge of a secret, the private key, without disclosing it.
Figure 2. Asymmetric key authentication relies on public and private keys.
Challenge-response authentication always needs the object to be authenticated to hold a secret. In symmetric cryptography, this is the shared secret between the host and the device. For asymmetric cryptography, this is the private key. In any case, the security brought by challenge-response authentication breaks when the secret is revealed. Here’s where security ICs can help. One fundamental feature of security ICs is to provide strong protection of keys and secrets.
Maxim offers three families of solutions to support authentication:
Within authentication ICs, the SHA-256-based products support authentication using shared secrets (Figure 3), while ECDSA-based ICs use a private/public key pair (Figure 4). In addition to the cryptographic engines, these products feature onboard EEPROM memory. This memory is configurable and can be used to store authenticated user data such as calibration information for sensors.
SHA-256-based products are the most affordable solutions. While they enable mutual authentication, the distribution of the shared secret requires some precautions so that the secret is not exposed during device manufacturing and setup. The secret can be programmed in a Maxim factory to circumvent this drawback.
Figure 3. SHA-256 secure authentication is based on shared secrets.
Maxim’s DS28E15/DS28E22/DS28E25 ICs are based on the SHA-256 technology and differ by their internal memory size. Since the same secret is stored on both the host and device sides, we recommend using a coprocessor such as the DS2465 on the host side.
Asymmetric cryptography-based products such as DS28C36 and DS28E35 offer a more flexible scheme because the key does not need to be protected against disclosure on the host side. However, to offload public-key math and provide additional secure operations, host-side coprocessors such as the DS2476 (companion IC to the DS28C36) are available to simplify development of the system solution.
Figure 4. ECDSA-based authentication relies on a private/public key pair.
Maxim offers secure microcontrollers ranging from the MAX32590 (ARM9 running at 384MHz) application-class processor that can run advanced operating systems such as Linux down to small-footprint coprocessors such as MAX32555 or MAXQ1061.
These microcontrollers support both symmetric and asymmetric cryptography for digital signature and authentication as well as encryption algorithms. They feature hardware accelerators for SHA, RSA, ECDSA, and AES as well as a full cryptography library providing a turnkey API aligned to standards. They have built-in secure boot, so that firmware authenticity is always guaranteed. Thanks to their comprehensive set of crypto functions, they can handle multiple authentication schemes.
The MAXQ1061 is a co-processor that not only enables authentication but also handles the most critical steps of the TLS/SSL standard secure communication protocol over IP. Handling TLS protocol within the chip improves the level of security and offloads the main processor from computing-intensive tasks. This is very valuable for resource-constrained embedded systems.
Low-power microcontrollers such as MAX32626 target wearable devices, so are not "security-centric" ICs. With attacks becoming more and more frequent, however, this product has been designed with the security challenges of tomorrow in mind. Hence, MAX32626 has a hardware Trust Protection Unit supporting authentication as well as hardware AES for encryption and a built-in secure boot.
|DS2465||DeepCover Secure Authenticator with SHA-256 Coprocessor and 1-Wire Master Function||Samples|
|DS2476||DeepCover Secure Coprocessor||Samples|
|DS28C36||DeepCover Secure Authenticator||Samples|
|DS28E15||DeepCover Secure Authenticator with 1-Wire SHA-256 and 512-Bit User EEPROM||Samples|
|DS28E22||DeepCover Secure Authenticator with 1-Wire SHA-256 and 2Kb User EEPROM||Samples|
|DS28E25||DeepCover Secure Authenticator with 1-Wire SHA-256 and 4Kb User EEPROM||Samples|
|DS28E35||DeepCover Secure Authenticator with 1-Wire ECDSA and 1Kb User EEPROM||Samples|
|MAX32555||DeepCover Secure Arm Cortex-M3 Flash Microcontroller||Samples|
|MAX32590||DeepCover Secure Microcontroller with ARM926EJ-S Processor Core||Samples|
|MAX32626||Ultra-Low-Power Arm Cortex-M4 with FPU-Based Microcontroller (MCU) with 512KB Flash and 160KB SRAM||Samples|
|MAXQ1061||DeepCover Cryptographic Controller for Embedded Devices||Samples|
|EE-Mail||Subscribe to EE-Mail and receive automatic notice of new documents in your areas of interest.|
|Download||Download, PDF Format (236.3kB)|
|© Mar 06, 2017, Maxim Integrated Products, Inc.|
APP 6391: Mar 06, 2017
APPLICATION NOTE 6391, AN6391, AN 6391, APP6391, Appnote6391, Appnote 6391, A1372