RSA

The RSA algorithm was developed by Ron Rivest, Adi Shamir, and Leonard Adleman in 1977. Today, it is the most popular asymmetric algorithm, being used in around 90% of systems. The RSA algorithm is based on the “integer factorization problem.” While it is easy to multiply two primes together, it is very time-consuming to factor a large number into its constituent primes. This allows us to create a one-way function that is easy to compute, but the resulting product is hard to factorize.

The mathematical RSA identity is shown below:

${\left.{\text{m}}^{\text{e}}\right)}^{\text{d}}mod\text{n}=\text{m}$

From this, we can derive functions to encrypt and decrypt the plain text:

${\text{m}}^{\text{e}}mod\text{n}=\text{c}$

${\text{c}}^{\text{d}}mod\text{n}=\text{m}$

• m Plain text message
• d private key
• e & n public key
• c is the ciphertext

Here, we can see that the encryption and decryption function is identical. We just need to use the appropriate values for each operation.

The size of the public modulus n is important for two reasons. First, the values for the plaintext n and cyphertext c must be within the integer ring (the modulus) defined by n. Secondly the maximum bit size of the message is equal to the bitsize of n. Finally, the public and private key values e and d must also exist within the integer ring defined by n. For our cryptosystem to be secure, n must contain many key pairs to be invulnerable to brute force attacks. In ever-increasing computing power and advances in factorizing algorithms, a safe value for n needs to be a minimum of 2048 bits.

Unlike a symmetrical cipher, we cannot just pick an encryption key at random. Since the public and private keys are related, they have to be calculated.

RSA key generation uses the following algorithm:

• First we select two large primes p and q
• We can then calculate n = p.q
• Next calculate φ(n) = (p-1).(q-1) which is known as the Totient
• Now we must select e such that it is a prime less than φ(n) – 1
• Now d.e = mod φ(n)
• Hence d = e^−  1 mod φ(n)

We can select values for p and q using a random number generator then test to see if the numbers are prime. Two methods to do this are the Millar Raban primality test and the Fermat primality test as shown in Fig. 5.3.

We now have to select e, the public exponent. Again, this must be prime and within the cyclic group defined by “n.” This gives us an opportunity to improve the performance of the RSA algorithm. Here, we can select the value 65537. This value is useful because it is prime and is 2^16 + 1 or Hexadecimal 10001. This improves the RSA encryption algorithm's performance by reducing the number of multiplies. While “e” can be a relatively small value, “d” the private key is the same bit size as n (2048 bit), so decryption is many times slower.

Exercise: RSA small numbers

This exercise demonstrates using the mbedTLS big number library to implement a demonstration version of the RSA algorithm. The values used in this example are very small and give a weak cipher, which should not be used in any real application.

• In the Pack Installer and select Exercise 5.1.

The bignum library is enabled in mbedTLS_config.h

          #define MBEDTLS_BIGNUM_C

The example code declares a set of multiprecision integer to be used for the RSA values:

          mbedtls_mpi P, E, N,Q,D,M,C, X;

Each value is initialized and Prime values are loaded into P,Q,E and M:

          void initLargeNum(void)

We can then compute the RSA key pair with void computeKeys(void)

This is done by first calculation the Totient:

   mbedtls_mpi_mul_mpi( &N, &P, &Q );   mbedtls_mpi_sub_int(&Q, &Q, 1 );   mbedtls_mpi_sub_int(&P, &P, 1 );   mbedtls_mpi_mul_mpi( &L, &P, &Q );

We can then derive the key pair using an inverse modulus calculation, which is part of the bignum library:

          mbedtls_mpi_inv_mod( &D, &E, &L );

Once the key pair has been calculated, we can use two functions to encrypt and decrypt plain text:

   void computeRSA(void){mbedtls_mpi_exp_mod( &X, &C, &D, &N, NULL );   }   void computeMessage(void){mbedtls_mpi_exp_mod( &C, &M, &E, &N, NULL );   }

As you can see, the encrypt and decrypt functions contain the same “mod a log” code but the type of operation depends on which key you use.

• Build the code and start the debugger.
• Start the Tera Term console.
• Examine the functions, then run the code.
• Observe the output in the Tera Term console (Fig. 5.4).

  

Malleability

In the last exercise, we used the “school book” version of RSA. Even if we used large numbers, this is not a fully fledged cryptosystem. The core RSA algorithm is malleable. In other words, the cypher text can be modified by an attacker, and it will still decrypt to a meaningful value. We can see this by attacking our previous example if we take an integer S and apply this to the cypher text c.

${\text{S}}^{\text{e}}·\text{c}$

Then, when we decrypt

${\left.{\text{S}}^{\text{e}}·\text{c}\right)}^{\text{d}}=\text{S}·\text{m}\text{m}\text{o}{\text{d}}_{\text{n}}$

If S = 2, an attacker has managed to double the value of m and the receiving station will accept this as valid data.

Exercise: RSA malleability

• Go back to the project in exercise 5.1.
• Uncomment the schoolBookAttack() function in main.c.

Here, we are taking the value “2” and raising it to the power of the public exponent e and then multiplying the cyphertext:

   void schoolBookAttack (void){mbedtls_mpi S;

mbedtls_mpi_init( &S );  mbedtls_mpi_read_string( &S, 16,"00002" );  mbedtls_mpi_exp_mod( &S, &S, &E, &N, NULL );  mbedtls_mpi_mul_mpi( &C, &C, &S );     }

• Build the code and rerun the example (Fig. 5.5).

  

The attacker has successfully modified the encrypted message from 0x55 to double its value 0xAA. There has been a banking error in your favor.

RSA padding

We can overcome this malleability weakness by adding a padding scheme to the plaintext data. There are a number of different padding schemes, but the idea is to place a pattern alongside the plaintext prior to encryption. When we decrypt, we can check the padding to detect any manipulation of the cyphertext. This has the effect of armoring the ciphertext to make it resistant to any malleability attacks.

PKCS 1_1.5

The original form of padding for the RSA cryptosystem was described in the PKCS1_1.5 document published by the RSA corporation. In this scheme, the total plaintext size is defined by the modulus n. The start of the plaintext contains the padding as a header followed by the data. The header starts with two bytes that define the block padding scheme. For PKCS1_1.5 the header value is set to 0x02. The remainder of the header is filled with random data until the start of the message data with a null byte delimiter between the random values and the message data. There must be a minimum of eight bytes of random data. The format is shown in Fig. 5.6.

While this scheme is still widely used it is subject to a number of protocol attacks, most notably one called Bleichenbacher's Attack.

Exercise: mbedTLS RSA key generation and cipher

In this exercise, we will generate a pair of RSA keys and then use them to encrypt and decrypt a symmetrical encryption key. The keys will be stored in keyfiles within the evaluation boards file system.

• In the Pack Installer and select Exercise 5.2.

To generate the RSA keys, we create a context for the RSA cipher along with contexts for a random number generator and entropy pool.

   mbedtls_rsa:context rsa;mbedtls_entropy_context entropy;   mbedtls_ctr_drbg_context ctr_drbg;

The example code will initialize the RNG and open files to store the public and private keys.

Then we can initialize the RSA cipher with its context and our choice of padding system.

          mbedtls_rsa:init( &rsa, MBEDTLS_RSA_PKCS_V15, 0 );

We can generate the RSA keys with a single function call. This uses random values to search for suitable primes. A weakness in our RNG implementation would result in predictability, which could be exploited by an adversary.

   mbedtls_rsa:gen_key( &rsa,mbedtls_ctr_drbg_random,&ctr_drbg,KEY_SIZE,EXPONENT )

The definitions used in the function call define the required bit size for the private key and the value to be used for the public exponent “e.”

   #define KEY_SIZE 2048   #define EXPONENT 6557

Once generated we can check both keys:

   mbedtls_rsa:check_pubkey( &rsa )   mbedtls_rsa:check_privkey( &rsa )

and then use the public key to encrypt an array holding some plain text such as a symmetric cipher encryption key.

   mbedtls_rsa:pkcs1_encrypt( &rsa,mbedtls_ctr_drbg_random,NULL,MBEDTLS_RSA_PUBLIC,PT_LEN,rsa:plaintext,rsa:ciphertext )

We can then decrypt the cipher text with the private key and check it matches the original plaintext.

   mbedtls_rsa:pkcs1_decrypt( &rsa,mbedtls_ctr_drbg_random,NULL, MBEDTLS_RSA_PRIVATE,&len,rsa:ciphertext,rsa:decrypted,sizeof(rsa:decrypted) );

• Run the code and observe the diagnostic messages displayed on the terminal.
• Also make a note of the time taken to run the example. We will compare RSA to other algorithms later in this chapter.

RSA problems

One inherent problem with RSA is that if the private key is ever compromised, an adversary will be able to decode any previous and future messages that have been encrypted with the public key. There is a second public-key cryptosystem that avoids this problem and provides “perfect forward secrecy.”

The Diffie Hellman (DH) Key agreement system

Like RSA, the Diffie Hellman (DH) system is based on a mathematical one-way function. While RSA is based on the integer factorization problem, DH is based on the discrete logarithm problem. That is, exponentiation can be used to create a one-way function, and that exponentiation is commutative.

$\text{K}\text{=}{\left.{\alpha }^{\text{x}}\right)}^{\text{y}}={\left.{\alpha }^{\text{y}}\right)}^{\text{x}}\equiv {\left.{\alpha }^{\text{x}}\right)}^{\text{y}}mod\text{p}$

DH uses this identity to create a key exchange protocol. To set up, we need to select a large prime p, then both stations with a large integer alpha to be our domain parameters, which are public values. The value of alpha must be within the cyclic group (modulus integer ring) of p-2.

At the beginning of communication, the master station shares its domain parameters. Then both stations select a session private key, which is a second integer within the cyclic group of p-2. They then both compute their respective public key:

${\text{K}}_{\text{p}\text{r}}=\text{e}\text{l}\text{e}\text{m}\text{e}\text{n}\text{t}\text{i}\text{n}\text{c}\text{y}\text{c}\text{l}\text{i}\text{c}\text{g}\text{r}\text{o}\text{u}\text{p}\text{o}\text{f}\text{p}‐2$

${\text{K}}_{\text{p}\text{u}\text{b}}={\alpha }^{{\text{K}}_{\text{p}\text{r}}}mod\text{p}$

Both sides can now exchange their public keys and can compute a shared secret as follows:

${\left.{\text{K}}_{\text{p}\text{u}\text{b},\text{B}}\right)}^{{\text{K}}_{\text{p}\text{r},\text{A}}}={\text{K}}_{\text{A}\text{B}}={\left.{\text{K}}_{\text{p}\text{u}\text{b},\text{A}}\right)}^{{\text{K}}_{\text{p}\text{r},\text{B}}}$

The DH algorithm is not a cryptosystem like RSA. It is used to agree on a shared secret which will be different for every set of domain and session parameters. This means that if any station's private key is compromised, it will be of no use in recalculating the shared secret of other sessions, hence the concept of perfect forward secrecy.

Exercise: DH small numbers

This exercise demonstrates using the mbedTLS big number library to implement a demonstration version of the DH algorithm. Like the RSA, small numbers exercise, the values used in this example are very small and give a weak cipher which should not be used in any real application.

• In the Pack Installer and select Exercise 5.3.
• Open Main.c

The code initializes a set of MPI numbers and initializes the domain values Alpha and P along with private key values for two stations a and b.

   mbedtls_mpi_init( &Pub_A );   mbedtls_mpi_init( &Pub_B );   mbedtls_mpi_init( &a );   mbedtls_mpi_init( &b );

   mbedtls_mpi_init( &Alpha );   mbedtls_mpi_init( &P );   mbedtls_mpi_init( &Secret_A );   mbedtls_mpi_init( &Secret_B );   mbedtls_mpi_read_string( &P, 16,"0001D" );   mbedtls_mpi_read_string( &Alpha, 16,"00002");   mbedtls_mpi_read_string( &a, 16,"00005");   mbedtls_mpi_read_string( &b, 16,"0000C");

Using the domain values, we can then compute the public key for each station.

   mbedtls_mpi_exp_mod( &Pub_A, &Alpha, &a, &P, NULL );   mbedtls_mpi_exp_mod( &Pub_B, &Alpha, &b, &P, NULL );

By exchanging public keys each station can now compute the shared secret.

   mbedtls_mpi_exp_mod( &Secret_A, &Pub_B, &a, &P, NULL );   mbedtls_mpi_exp_mod( &Secret_B, &Pub_A, &b, &P, NULL );

• Build the code.
• Start the debugger and run the code (Fig. 5.8).

  

• The results of each calculation are displayed in the debugger console window.

In a practical system, the initial value for the prime p is chosen using a random number generator and one of the prime verifying algorithms we saw with the RSA algorithm. The integers used to compute the public keys should also be selected using a random number generator to prevent the selection of weak values which an adversary could guess (Table 5.2).

Exercise: Diffie Hellman Key agreement

In this exercise, we will configure the evaluation board as a server and allow the PC to connect over a WiFi connection. A client on the PC will then request the DH domain parameters along with its public key. The client will use these values to calculate its public key and will then send this to the server. Both the server and client will calculate a shared secret. The server will use the shared secret to encrypt a text message which is sent to the client for decryption.

• In the Pack Installer select Exercise 5.4.
• Set the server project as the active project.

The embedded node is designed to run as a server with the address 192.168.0.10. You may need to adjust this to work with your WiFi network. When the PC client starts it will ask you to input the server address.

In the server we first declare the necessary contexts for the DH, AES ciphers and random number generator. We then initialize them as well as starting the local file system.

   mbedtls_dhm_context dhm;   mbedtls_aes_context aes;   mbedtls_dhm_init( &dhm );   mbedtls_aes_init( &aes );

The full example code initializes the filesystem, networking, and random number generator before loading the servers DH parameters from the embedded file system.

   f = fopen( "dh_prime.txt", "rb" ) ) == NULL )   mbedtls_mpi_read_file( &dhm.P, 16, f )   mbedtls_mpi_read_file( &dhm.G, 16, f )   fclose( f );

We then calculate the session DH parameters and extract the public parameters into a buffer ready to be sent over the network.

   mbedtls_dhm_make_params( &dhm,(int) mbedtls_mpi_size( &dhm.P ),buf,

&n,  mbedtls_ctr_drbg_random,  &ctr_drbg )

The server then opens a network port and waits for a remote connection.

The client connects to the server then sends its DH public parameter. Next, the client will reply with its public parameter.

The server can then load the local context with the clients public DP parameters and calculate the shared secret.

   mbedtls_dhm_read_public( &dhm, buf, dhm.len );   mbedtls_dhm_calc_secret( &dhm,buf,sizeof( buf ),&n,mbedtls_ctr_drbg_random,&ctr_drbg );

Once we have the shared secret, it can be used as the encryption key to wrap the plaintext reply.

   mbedtls_aes_setkey_enc( &aes, buf, 256 );   memcpy( buf, PLAINTEXT, 16 );   mbedtls_aes_crypt_ecb( &aes, MBEDTLS_AES_ENCRYPT,buf,buf );

The server will then send the encrypted packet back to the client.

The client-side follows a similar set of API calls to generate the session DH parameters and exchange public values with the server. The major difference is that it creates an ephemeral session key pair and shares the public values with the server.

   mbedtls_dhm_make_public( &dhm,(int) dhm.len,buf,n,mbedtls_ctr_drbg_random,&ctr_drbg )

Once the client has received the servers’ public values, it is able to calculate the same shared secret as the server. When the ciphertext packet arrives from the server, it can use the shared secret to decrypt the message back to the original plaintext.

• In the server project copy the DH_prime.txt file from the PC_app folder to the SD card and place this into the evaluation board.
• Build the server project and start the debugger.
• Run the server code so it is waiting for a connection.
• Open a Windows command window and run the dh_client executable located in the PC_app folder (Fig. 5.9).

  

The two stations will display their progress as they negotiate a secure connection.

Like RSA, the DH algorithm uses very large numbers and needs the use of the mbedTLS “big number library.” However, unlike RSA, the DH algorithm can be implemented with a different style of number line which greatly improves its performance.

Addition

While doing algebraic operations on a curve may seem a bit odd, it is possible to perform addition of two points as shown in Fig. 5.11.

To add two points, P and Q, we bisect them with a line and extend this line until it cuts the curve at a third point. If we then reflect this point across the X-axis, we get a result R = (P + Q).

Point doubling

We can also calculate P + P by extending the tangent of point P until it cuts the curve at a new point. Again this point is reflected across the x-axis to give us a result of 2P, as shown in Fig. 5.12.

Group element

For our integer ring to become a cyclic group we also need a neutral element φ such that

$\text{P}+\phi =\text{P}$

On a standard number line, the neutral element would be zero, but on our elliptic curve, it is not clear what we can use. In practice, we can define a point at “plus” infinity along the Y-axis as the neutral element. So we can consider φ to be asymtotic to each point on our curve

$\text{P}+\left.-\text{P}\right)=\phi$

If we use our point addition method to calculate −  P it turns out that the inverse of P is its mirror across the X-axis as shown in Fig. 5.13.

To create a discrete logarithmic problem on an elliptic curve, we use another property of elliptic curve addition: adding a point P to itself is the equivalent of raising P by a power on a linear number line.

So in effect:

${\text{P}}^{\text{d}}=\text{T}$

is expressed as

$\left.\text{P}+\text{P}+\text{P}+\text{P}+\text{P}\right)=\text{T}$

Addition d times

Which can written as

$\text{d}\text{P}\text{=}\text{T}$

We can then take our base point P and calculate its powers and use these as the basis for a discrete logarithm problem. As we will see in the next exercise, the public key is T and d is the private key.

To create an elliptic curve cryptosystem, we need to define a suitable curve (not easy). In practice, the EC curves supported by mbedTLS come from NIST, the Internet Engineering Task Force or the original researcher, Neil Koblitz. It should be noted that because of their underlying structure, the NIST curves have a higher performance than the IETF Brainpool curves (Table 5.3).

Exercise: Elliptic Curve Diffie Hellman

In this exercise, we replace the standard DH algorithm with the elliptic curve version and compute the server and client keys and shared secret. In the elliptic curve version of the DH algorithm, the public and private keys are points on the elliptic curve. In the code below, the values in the ECDH context are as follows:

• • grpThe elliptic curve to use
• • QThe public key
• • Qpthe peer public key
• • dThe private key
• • Xa coordinate on the elliptic curve
• • zThe shared secret

• In the Pack Installer select Exercise 5.5.
• Build the project then download it using the debugger

The project has code that first creates and initializes a context for both the client and server stages:

   mbedtls_ecdh_context ctx_cli, ctx_srv;   mbedtls_ecdh_init( &ctx_cli );   mbedtls_ecdh_init( &ctx_srv );

The next few function calls are symmetrical for both the client and server here we will look at the client version.

For the client we first load the common elliptic curve.

   mbedtls_ecp_group_load( &ctx_cli.grp,MBEDTLS_ECP_DP_CURVE25519 );

We can then generate the public and private keys using a random number as a seed.

   mbedtls_ecdh_gen_public( &ctx_cli.grp,&ctx_cli.d,&ctx_cli.Q,mbedtls_ctr_drbg_random,&ctr_drbg );

The public key MPI is then exported as a binary string to be shared with the server code.

   unsigned char cli_to_srv[32];   mbedtls_mpi_write_binary( &ctx_cli.Q.X, cli_to_srv, 32 );

The public key can then be read by the peer, in this case the server.

mbedtls_mpi_read_binary( &ctx_srv.Qp.X, cli_to_srv, 32 )

This process is repeated by the server code.

Once the public keys have been exchanged both the server and the client can compute a shared secret z.

   mbedtls_ecdh_compute_shared( &ctx_srv.grp,&ctx_srv.z,&ctx_srv.Qp,&ctx_srv.d,mbedtls_ctr_drbg_random, &ctr_drbg );

• Run the code and the process will be printed to the console window

Both the server and client will calculate the same shared secret. This exercise is comparable to Exercise 5.2, which uses RSA. Here we can see that the EC version is much faster.

RSA signing

The RSA approach to signing data is very straight forward and elegant. If we want to sign a message to authenticate it as originating from us, we go through the following 2-step process. First, compute the hash of the plain text we want to sign. Second, we encrypt the hash using the RSA algorithm, but we use our private key. The resulting ciphertext is the signature of our plaintext. We can send the plaintext and signature to any other station along with our public key. The receiving station can authenticate the plain text by decrypting the signature using our public key. This will reveal the per calculated hash of the plaintext. They can now compute the hash of the plaintext, which should match the signature hash. If this is the case, we have confirmed the integrity of the plaintext and also its origin, as the signature could only have been created with our private key (Fig. 5.14).

In practice, the process is slightly more difficult as we have to add padding to the signature to prevent an existential attack. Like the RSA encryption and decryption functions, the different padding strategies are directly implemented by the mbedTLS signing API calls.

Exercise: RSA signature

In this exercise we will calculate and verify the signature of a file of plaintext data using the RSA algorithm.

• In the Pack Installer select Exercise 5.6
• Open main.c

At the start of the code, we define each of the RSA public and private key numbers as an ASCII string:

   #define RSA_N"9292758453063D803DD603D5E777D788"      "8ED1D5BF35786190FA2F23EBC0848AEA" ..............     "5E94BB77B07507233A0BC7BAC8F90F79"

We then define a multiprecision integer and initialize it along with the RSA context:

   mbedtls_mpi K;   mbedtls_mpi_init( &K );   mbedtls_rsa:init( &rsa, MBEDTLS_RSA_PKCS_V15, 0 );

We can then set the RSA public and private keys by reading in each MPI number:

   MBEDTLS_MPI_CHK( mbedtls_mpi_read_string( &K, 16, RSA_N ) );   MBEDTLS_MPI_CHK( mbedtls_rsa:import( &rsa,&K,NULL,NULL,NULL,NULL ) );

To create the signature, we first calculate the HASH of the plaintext file:

          mbedtls_sha1_ret( rsa:plaintext, PT_LEN, sha1sum )

Then, we compute the signature using the private key and use the pkcs1 padding scheme:

   mbedtls_rsa:pkcs1_sign( &rsa,myrand,NULL,MBEDTLS_RSA_PRIVATE,MBEDTLS_MD_SHA1,0,       sha1sum_0,rsa:ciphertext );

Once the signature has been computed, a receiving station can recompute the hash and then verify the integrity of the plaintext using the sending stations public key:

   mbedtls_rsa:pkcs1_verify( &rsa,NULL,NULL,MBEDTLS_RSA_PUBLIC,MBEDTLS_MD_SHA1,0,sha1sum_1,rsa:ciphertext );

• Build the project.
• Place the SD card with the helloBig.txt file into the evaluation board.
• Run the code to generate and verify the signature.

Elliptic Curve Digital Signature Algorithm

An alternative to signing messages with RSA is the Digital Signature Algorithm, which is a NIST standard FIPS 128 - 3.

The ECDSA algorithm is more complex than RSA and has separate sign and verify algorithms. The ECDSA algorithm can also be implemented using elliptic curve cryptography, which is becoming more widely used for small embedded systems.

To sign a message, we need to select and compute a range of variables as shown in Table 5.4.

Exercise: ECDSA

In this exercise, we will generate an ECDSA key pair and then compute and verify an ECDSA signature.

• In the Pack Installer, select Exercise 5.7

We can first select an elliptic curve from our library.

          #define ECPARAMS MBEDTLS_ECP_DP_SECP192R1

Then create a context for the signing and verifying algorithms and initialize.

   mbedtls_ecdsa:context ctx_sign, ctx_verify;   mbedtls_ecdsa:init( &ctx_sign );   mbedtls_ecdsa:init( &ctx_verify );

In addition, we must create a random number generator so that we can generate a key pair.

   mbedtls_ecdsa:genkey( &ctx_sign,ECPARAMS,mbedtls_ctr_drbg_random,&ctr_drbg );

Before calculating the signature we must first calculate the message hash.

•           unsigned char hash[] = = {0xFa,0xce,0x33......};

Now we can calculate the signature.

   unsigned char sig[512];   mbedtls_ecdsa:write_signature( &ctx_sign,MBEDTLS_MD_SHA256,hash,sizeof( hash ),sig,&sig_len,mbedtls_ctr_drbg_random,&ctr_drbg );

Now we have the signature we can verify it is correct. Our receiving station must setup the same elliptic curve and also copy the signing public key.

          &

Now we can verify the signature:

   mbedtls_ecdsa:read_signature( &ctx_verify,hash,sizeof( hash ),sig, sig_len );

• Run the code and the results will be printed to the console window.

You will also see that the process of key generation, signing, and verification is significantly faster than the RSA examples.

Certificate authority

First we will create a “certificate authority” certificate, which will be used to sign the server and client certificates.

• In the templates tab select the “Certificate Authority” template, right click and select “Create Certificate” (Fig. 5.18).

  

Select the source tab This certificate will be our “Root of Trust” and, as such, will be self-signed. The algorithm used to sign the certificate is SHA256. This is the current minimum standard you should use to sign a certificate (Fig. 5.19).

• Select the subject tab (Fig. 5.20).

  

  

Enter an internal name and a common name. These can be different, but in this case, I have used IoT_CA. The template has set the other distinguished name fields, but you can change them to match your needs.

• Select the Extensions tab (Fig. 5.21).

  

Here, the type of certificate is configured as “certificate authority” and there is a default time range of 20 years.

• Select the Key Usage tab.

This dialog allows you to limit the properties of the certificate. By leaving everything blank, we are not adding any restrictions to our basic certificate. Once you have a working system, you can experiment with these fields.

• Go back to the subject tab (Fig. 5.22).

  

• Press the create button to generate the key (Fig. 5.23).

  

Here, we will generate a 2048 bit RSA key

• Finally, press OK on the subject dialog to create the certificate.

The new certificate and key can be viewed in the certificates window (Fig. 5.24).

and the private keys window (Fig. 5.25).

The certificate authorities private key is securely held in the XCA database and must always be kept secret as it is used to sign the server and client certificates.

Server certificate

• Go back to the templates tab and this time select the “broker” template and create a new certificate (Fig. 5.26).

  

Here we are using the term Broker as another name for Server. We will see the role of a “broker” in the next chapter.

• In the source tab select the IoT_CA certificate as the signing source (Fig. 5.27).

  

• Select the subject tab (Fig. 5.28) and set the common name to IoT_Broker

  

• Select the extensions tab (Fig. 5.29) and set the certificate type to end entity.

  

This time the type of certificate is set to “End Entity” and the life time of the certificate is limited to 10 years.

• Return to the subject tab and create the key and certificate as we did for the “certificate authority” certificate.

Device certificate

Now we are going to repeat the process one more time to create a device certificate. This will then give us all the certificate and keys we need to build a secure networked system.

• In the templates tab select the device template, right click and select “Create Certificate” (Fig. 5.30).

  

• In the source field, we must again use the IoT_CA certificate for signing (Fig. 5.31).

  

• Select the subject dialog.
• Fill out the internal and common name fields with your selected device name (Fig. 5.32).

  

• Here, I have used IoT_Device for the common name.
• Select the certificates window (Fig. 5.33).

  

Now in the certificate window, we can see the certificate hierarchy. The IoT_CA certificate is our “Root of Trust,” and it has signed both the broker and the device certificates. If you have the IoT_CA certificate installed, it can be used to check the signature of either the broker or the device certificate and authenticate the data in the certificate.

• Select each certificate, right click and select export to file (Fig. 5.34).

  

The certificate information is encoded in “Abstract Syntax Notation 1” (ASIN1) using the “Distinguished Encoding Rules” (DER). Here, the heavy lifting is done for us by XCA. When we save the certificate, the binary data is further transformed into a format called “Privacy Enhanced Mail” (PEM), which is base64 encoded binary with a short additional header.

• Leave the export format as PEM and press OK (Fig. 5.35).

  

• Select the Private Keys dialog.

Now we have three keys stored. We need to export the server and device keys so they can be stored in their respective devices. The certificate authority key must never be exposed outside of the XCA database (Fig. 5.36).

• Select the IoT Server key right click and select export to file and save it in a PEM format. Repeat this for the device key

Now in our certs directory, we should have five files: three certificates and two key files (Fig. 5.37). We will use these certificates for server and device authentication later in this chapter.

Certificate and key storage

mbedTLS provides functions to load certificates and keys from static arrays stored in the microcontroller flash memory or from an embedded file system (Table 5.5). The certificates and keys can be stored in DER or PEM format. Keys can be exported and stored in a standard keyfile format that provides password-based encryption with symmetrical ciphers. As we will see in later chapters, the PSA Trusted Firmware creates a Secure Internal Storage volume to hold device secrets. In addition, a Cortex-M33 based microcontroller designed to be an IoT device is likely to provide a key store mechanism, and we will also look at these features in the coming chapters.

Exercise: Parsing X.509 certificates and keys

Here, we will look at how to load and parse stored certificates within our embedded microcontroller using the standard mbedTLS functions.

• Open the pack installer, select project 5.9 and press the Copy button.
• Open main.c

As usual, we start by declaring the necessary contexts that we will need in this example.

Here, we have a context for a certificate authority and a client certificate. We also have a public key context to load our private key.

   mbedtls_x509_crt cacert;   mbedtls_x509_crt clicert;   mbedtls_pk_context pkey;   mbedtls_x509_crt_init( &clicert );

We can then parse anX.509 certificate.

   mbedtls_x509_crt_parse( &clicert,(const unsigned char *) mbedtls_test_cli_crt,mbedtls_test_cli_crt_len );

Since this information is public information, we do not need to store it securely. It can be placed in the microcontroller flash memory as a “C” array.

•           #define TEST_CA_CRT_EC                         
•           "-----BEGIN CERTIFICATE----- "
•           "          MIICUjCCAdegAwIBAgIJAMFD4n5iQ8zoMAoGCCqGSM49BAMCMD4xCzAJBgNVBAYT "
•           "Ak5MMREwDwYDVQQKEwhQb2xhclNTTDEcMBoGA1UEAxMTUG9sYXJzc2wgVGVzdCBF "
•           ………………………………..
•           "uCjn8pwUOkABXK8Mss90fzCfCEOtIA  == "                  
•           "-----END CERTIFICATE----- "

Alternatively, the certificate can be stored in the embedded file system and loaded from a file.

          mbedtls_x509_crt_parse_file (&cacert,"iot_ca.crt");

Once the certificates are loaded, we can verify the validity of the certificates.

   ret = mbedtls_x509_crt_verify( &clicert,&cacert,NULL,NULL,&flags,NULL,NULL );

Similarly, an RSA private key can be loaded directly from an array stored in flash memory.

   mbedtls_pk_parse_key( &pkey,(const unsigned char *) mbedtls_test_srv_key,mbedtls_test_srv_key_len,NULL,0 );

or loaded from a keyfile:

          int mbedtls_pk_parse_keyfile(&pkey,&keyfile,&password);

Once loaded we can test the RSA keys:

          mbedtls_pk_verify

• Build the code and start the debugger.

The code will parse the certificates and display their details to the tera term console window.

Establishing a TLS connection

We can create both a server and client with the mbedTLS library. To create a secure server, we first need to declare and initialize contexts for the SSL configuration and the SSL operating layer.

   mbedtls_ssl_context ssl;   mbedtls_ssl_config conf;   mbedtls_ssl_config conf;   mbedtls_ssl_context ssl;

   mbedtls_pk_parse_key( &pkey,(const unsigned char *) mbedtls_test_srv_key,mbedtls_test_srv_key_len,NULL,0 );

   mbedtls_net_bind( &listen_fd,NULL,"4433",MBEDTLS_NET_PROTO_TCP ) )

   mbedtls_ssl_config_defaults( &conf,MBEDTLS_SSL_IS_SERVER,MBEDTLS_SSL_TRANSPORT_STREAM,MBEDTLS_SSL_PRESET_DEFAULT )

   mbedtls_ctr_drbg_seed( &ctr_drbg,mbedtls_entropy_func,&entropy,(const unsigned char *) pers,strlen( pers ) ) ) != 0 )   mbedtls_ssl_conf_rng( &conf,mbedtls_ctr_drbg_random,&ctr_drbg );

   static void my_debug( void *ctx, int level,const char *file,

int line,  const char *str )

mbedtls_ssl_set_bio( &ssl,&client_fd,mbedtls_net_send,mbedtls_net_recv,NULL );

   int mbedtls_net_send( void *ctx,const unsignedchar *buf,size_t len ){   send (SOCK(ctx), (const char *)buf, len, 0);}   int mbedtls_net_recv (void *ctx,unsigned char *buf,size_t len){   recv (SOCK(ctx), (char *)buf, len, 0);}

   mbedtls_ssl_write(&ssl, buf, len));   mbedtls_ssl_read(&ssl, buf, len);

   mbedtls_ssl_free( &ssl );   mbedtls_ssl_config_free( &conf );

   mbedtls_ssl_config_defaults( &conf,MBEDTLS_SSL_IS_CLIENT,MBEDTLS_SSL_TRANSPORT_STREAM,MBEDTLS_SSL_PRESET_DEFAULT ) ;

   mbedtls_ssl_conf_authmode( &conf,MBEDTLS_SSL_VERIFY_OPTIONAL );

   mbedtls_net_connect( &server_fd,SERVER_NAME,SERVER_PORT,MBEDTLS_NET_PROTO_TCP );   mbedtls_ssl_handshake( &ssl );

Server and client authentication

So far, we have looked at a standard TLS handshake which is typically used when a web browser establishes a secure connection to a website. This system has the attraction that the client only needs to hold the CA certificate, which is public information and can have a long lifetime. However, for an IoT system, we really need to go a bit further and use a client certificate that will allow the server to authenticate the client. This mutual authentication provides a much higher level of security and can remove the need for a further sign-on password. However, it does mean that the client has to be provisioned with its own individual certificate and private key.

In such a system, the server will demand a client certificate once it has sent its certificate. Once the client has validated the server certificate, it will send its certificate to the server. The server will validate the client certificate and reply with a hash of all the existing handshake messages signed with the client's public key (Fig. 5.49).

In our existing server code, we can force the server to authenticate the client by setting an authentication mode:

   mbedtls_ssl_conf_authmode( &conf,MBEDTLS_SSL_VERIFY_REQUIRED );

The server will now request and validate the client certificate as part of the TLS handshake.

On the client side, in addition to the CA certificate, we need to load the client certificate:

   ret = mbedtls_x509_crt_parse( &clicert,(const unsigned char *) mbedtls_test_cli_crt,mbedtls_test_cli_crt_len );

Along with the client private key which must also be added to the TLS configuration context.

   ret = mbedtls_pk_parse_key( &pkey,(const unsigned char *) mbedtls_test_cli_key,mbedtls_test_cli_key_len,                              NULL,                              0 );   ret = mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey ) ;

Exercise: TLS server and client authentication

In this exercise, we will configure our network client and server to perform mutual authentication. The code is basically the same as the last example but has been extended to provision the client with a device certificate and private key. The server is configured to request the device certificate, which will be validated by the servers CA certificate.

• In this exercise you can use the certificates created in exercise 5.9 or use the ones provided in the project directories.
• Open the pack installer, select project 5.11 and press the copy button.
• In explorer navigate to the subdirectory <  project  >PC_Server

Copy the CA and broker certificates created in project 5.9 plus the broker private key to the PC_Server directory or use the existing files.

• Start the tls_server.exe project.
• In explorer navigate to the <  project  >Embedded Clientcerts.
• Copy the IoT_Device.crt certificate and IoT_Device.pem keyfile on to the SD card. Again use the existing files or the ones created in exercise 5.9
• Place the SD card back into the Xpresso board.
• Open the project in <  project  >Embedded Clientproject.
• Examine main.c
• Build the project and download.
• Run the code.
• Examine the debug console window.

This will establish a secure connection which mutually authenticates both the Server and the Client.