Mbed TLS overview and features

In this article, I’d like to discuss Mbed TLS, which I’ve touched on several times in the past, as a protocol that encrypts communications, the Transport Layer Security (TLS) is the IoT It is frequently used as a means of achieving security. It is also often used as a means of authenticating devices as well as encrypting communications.

SSL and TLS
Common Key and Public Key
How TLS Communication Works
Embedded and TLS
Hardware Encryption Support

SSL and TLS

By the way, TLS is frequently referred to as SSL (Secure Sockets Layer). Why do we have two names, SSL and TLS? SSL was developed in 1994 by Netscape Communications Corporation, the same company that developed the Netscape Navigator web browser, which was widely used at the time. The protocol was released by an American company. The following year, 1995, the company’s browser was released with SSL 2.0 implemented. However, this SSL 2.0 was found to have a significant vulnerability, so by the end of 1995, SSL 3.0 was released.

Since 1996, SSL standardization has been transferred from Netscape Communications to the TLS Working Group of the IETF (The Internet Engineering Task Force, a voluntary organization that promotes the standardization of Internet technologies), and TLS 1.0 was released in 1999. The differences in functionality between TLS 1.0 and SSL 3.0 are not numerous, but the details of the specification have changed. In addition, the version number used during negotiation is 3.1 to indicate that TLS 1.0 is a newer standard than SSL 3.0.

TLS thus emerged, with TLS 1.1, TLS 1.2, and TLS 1.3 being released in 2006, 2008, and 2018, respectively. for SSL, SSL 2.0 and SSL 3.0 were banned in 2011 and 2015, respectively, so that we now have The protocol used by the web browser should be TLS.

Common Key and Public Key

Before explaining how TLS works, it is necessary to explain “symmetric key cryptography” and “public key cryptography”. Symmetric key cryptography is a method that uses the same key for encryption and compounding (restoring the encrypted data). Symmetric key cryptography is frequently used everywhere because it can compute encryption faster than public key cryptography and requires less computer load. Let’s take the example of Caesar’s cryptography to explain terms used in cryptography, such as “key.

The Caesar cipher is a cipher said to have been used by Julius Caesar of ancient Rome. Many people generally think of this method when they think of encryption. In Caesar’s encryption, “ABC” is shifted to “CDE” and so on. This act of shifting is an algorithm, and the number of shifts is the key. In this example, two letters of the alphabet are shifted, so the key is “2”.

In symmetric key cryptography, the same “key” is used to encrypt the plaintext (the original text) and to decrypt the encrypted text into the plaintext. This is why it is called “symmetric key cryptography”. The weakness of common-key cryptography is that the key must be distributed, even though it can be decrypted if the key is compromised. Also, as long as the key is available, anyone with the key can also perform encryption and forge information.

Public key cryptography is the solution to this key delivery problem. There are two types of public key cryptography: a “public key” for encryption and a “private key” for decryption.

Communication using public key cryptography is done this way.

Mr. B (the receiver) creates a public key and a private key.
B makes the public key available to the public.
A sends the cipher to B, using the public key to encrypt it.
After receiving the ciphertext, Mr. B decrypts it using the private key.

Since only Ms. B has the private key, she cannot decrypt the ciphertext even if a third party who does not have the private key obtains it. Also, Mr. A has only the public key and cannot decrypt the ciphertext since he does not have the private key. In public-key cryptography, a ciphertext encrypted with a private key can only be decrypted with the public key, and a ciphertext encrypted with a public key can only be decrypted with the private key.

This public key cryptosystem also has some problems. For example, in step 2 above, Mr. C pretends to be Mr. B and hands Mr. A Mr. C’s public key to Mr. A. In this case, Mr. A’s public key can be decrypted by Mr. C’s private key. In order to prevent this kind of man-in-the-middle attack, the public key is checked by a trusted third party (Certification Authority (CA)) and digitally signed. The mechanism for authentication of the public key by the Certification Authority (CA) is called the Public Key Infrastructure (PKI).

As an aside, digital signatures take advantage of the public key cryptosystem’s feature that “only the person with the other key can decrypt the data” to confirm that the creator of the data has not been spoofed or that the data has not been tampered with. Digital signatures are made by encrypting the hash values obtained by performing an operation, called a hash, that generates a fixed length of data from the given data, using public key cryptography.

How TLS Communication Works

Now that you understand public key cryptography, let’s explain how TLS works. For example, when you are browsing the web with HTTPS, HTTP communication takes place over the secure connection provided by TLS, and although TLS uses public key cryptography, not all communication is encrypted with public key cryptography. In general, public-key cryptography requires more complex calculations than symmetric key cryptography. For this reason, data is often encrypted using a temporary symmetric key (session key) and only the delivery of the symmetric key is done using public key cryptography. Taking HTTPS as an example, the communication is done as follows.

The client (web browser) sends a list of available encryption methods to the server.
The server chooses the strongest symmetric key cipher that is available to both parties.
The server sends the server certificate containing the public key to the client to prevent the server from being spoofed.
The client creates a shared key (session key), encrypts it with the server’s public key, and sends it to the server. The server decrypts the received shared key with the private key.
A session key is used for encryption and encrypted communication.

Embedded and TLS

The implementation of TLS and cryptography is not only quite complex, but also requires continuous maintenance, including vulnerability testing and countermeasures. There are only a few well known server-side TLS implementations, such as OpenSSL and GnuTLS. No. The only small embedded implementations are wolfSSL and Mbed TLS. The only small embedded implementations are wolfSSL and Mbed TLS.

Mbed TLS was formerly an open source library called PolarSSL, developed and maintained by a company called Offspark, which was acquired by Arm. As I mentioned earlier, not many implementations of TLS exist, so Mbed TLS is not limited to Mbed, but is used extensively, mainly for embedded applications.

By the way, the main recent cloud services for IoT assume that the communication with the device (microcontroller) is encrypted with TLS. Also, device authentication is done using certificates. Instead of using a shared key, such as a traditional ID and password, it now uses a public key cryptography mechanism. Both AWS IoT and Google Cloud IoT Azure IoT Hub also uses TLS for authentication in this way.

As for the actual implementation, the Arm folks in charge of the project have created samples for each of their cloud services, which are very helpful. From what I’ve seen, a sample has been made for the FRDM-K64F, so it seems to be easiest to try it out on this board.

Hardware Encryption Support

As described in this FRDM-K64F platform page, recently, microcontrollers have also been equipped with a hardware encryption support function for use with TLS and other encryption methods. The FRDM-K64F, as an example, has the following two lines of security features In the FRDM-K64F as an example, the following two lines were listed as security features.

Hardware CRC and random-number generator modules
Hardware encryption supporting DES, 3DES, AES, MD5, SHA-1 and SHA-256 algorithms

First, let’s take a look at the first CRC and random-number generator modules, which are well known methods used for error detection but are not resistant to data tampering. Next, random-number generator modules have a significant impact on the performance of the cryptographic process. Many security-related calculations use random numbers. For example, the generation of a cryptographic key requires a random number as a starting point. If the random numbers can be generated in hardware instead of software, the cryptographic process will be much faster.

The randomness of the random numbers is also important. Since random numbers are used in the cryptographic process, it is important that an attacker cannot detect them. the K64 Reference Manual, the initial The strength of a random number or cipher can be increased by devising a certain type (seed) in the value and making it unpredictable to the attacker.

A random number generator (RNG) equipped with this mechanism is often referred to as a true random number generator (TRNG, True Random Number Generator). For example, the STM32F4 TRNG is designed to generate stronger random numbers using the physical phenomenon of analog noise.

The second, hardware encryption support, doesn’t need to be explained in much detail. As the name implies, it accelerates the execution of the algorithms described by the hardware implementation.