Certificate Management for Embedded Systems

(A Gentle Introduction to Asymmetric Encryption and SSL Certificates)

An important feature in digital certificates is the use of asymmetric algorithms to ensure key establishment. In order to understand certificates, we need to understand the fundamentals of asymmetric key establishment.

Introduction to asymmetric algorithms

Asymmetric key algorithms use two different keys at once -- a combination of a private key and a public key. The private key is known only to your host platform, while the public key is given by your host platform to any other device that wants to communicate securely with it.

The SSL protocol can use several types of asymmetric key algorithms, mainly RSA and ECCDH. RSA, an algorithm developed in 1977, is the most widely used algorithm. ECCDH is a newer technology that promises much faster processing at the same security level, paramount in embedded devices with limited CPU power. ECC is short for Elliptic Curve Cryptography. We will not go into the details of how these two algorithms function. You can find plenty of information on the Internet that describes RSA and ECC.

The following diagram shows a typical RSA key exchange. Bob wants to send an encrypted message to Alice.

Asymmetric Encryption

Alice starts by sending her public key (A's public) to Bob so Bob can use the public key to encrypt a message. Bob uses Alice's public key and encrypts a message. The encrypted message is sent to Alice. Since only Alice has the private key, only Alice can decrypt the encrypted message. An eavesdropper will not be able to decode the encrypted message.

In addition to providing one way asymmetric encryption, the asymmetric key encryption algorithm can also be used for signing messages. Signature management is simply the reverse of the one way encryption.

Sending a Signed Messages

Alice wants to send a signed message to Bob. Alice encrypts the message by using her private key. The public key and the encrypted message are sent to Bob. Bob uses Alice's public key to decrypt the message. Alice's private key is only known to Alice so no one else can use her private key to encrypt a message. For this reason, the signature is deemed valid if the decryption on Bob's side is successful. Note: anyone receiving the message sent from Alice can decrypt the message so the asymmetric key encryption when used for signing messages does not provide any type of protection from, for example, eavesdropping. It's strictly used to verify the sender.

Although Bob decrypts the message and verifies that it comes from Alice, Bob has no electronic means of trusting Alice. If Bob and Alice had met in person prior to Alice sending the message, Alice could have physically given Bob her public key. Bob would then have been able to trust encrypted messages sent electronically from Alice. This is a fundamental problem with public key cryptography. The SSL protocol solves this problem by using a trusted third party. We will go more into using a third party when we explain how SSL certificates work.

There are a few limitations with asymmetric key encryption. The size of the data being encrypted cannot be larger than the key length. For example, an RSA key with length 1024 can theoretically not encrypt more than 1024 bits (128 bytes). The practical size is actually less than 128 bytes since the RSA encryption function requires some padding. Another limitation is the processing power required to perform the arithmetic.

Asymmetric encryption is therefore typically used to encrypt short messages such as a signature or exchanging the symmetric key used by the SSL protocol. A signature is typically a message digest that has been encrypted with the private key. A message digest is a hash of the data that requires signature. The SSL protocol supports several hash algorithms, including MD5, SHA1, and SHA256.

Signed Message Data

In the following example, Alice wants to send a signed message to Bob:

  1. Alice calculates a message digest of the data
  2. Alice encrypts the message digest using her private key
  3. Alice sends the data, the encrypted message digest, and the public key to Bob
  4. Bob decrypts the message digest using Alice's public key
  5. Bob calculates his own message digest on the received data and verifies that his calculated digest matches the decrypted message digest received from Alice

Signing messages is an important component of the SSL protocol as it makes it possible to provide trust management. A signature is a message digest encrypted with the subject's private key. The subject is Alice in the above example.

Introduction to Certificates

SSL provides trust management in addition to providing encrypted and private communication. Trust is provided by a known third party.

Alice wants to communicate with Bob, but before doing so she wants to know if Bob is trusted. The only way Alice can verify the identity of Bob is to use a well known trusted third party. In order to provide trust, Bob's public certificate must be signed by the same well known third party. This third party is known as a Certificate Authority or CA for short. Your browser and/or host platform generally contains a list of well known CAs that it trusts. This list is pre-installed in your browser and/or host platform.

Certificate Components

In a typical SSL usage scenario, a server, in this case Bob, is configured with a certificate containing a public key as well as a matching private key.

The public key is embedded inside the public certificate together with a number of other components that identifies Bob as the owner of the certificate. All data in the certificate is signed using the CA's private key.

As we previously explained, a signature is a message digest signed with a private key. The signature algorithm type is also embedded in the certificate. An example of a signature algorithm is sha1WithRSAEncryption. This means the message digest is calculated using SHA-1 and the message digest is signed using RSA.

If Alice has a copy of the CA's public key, she can validate Bob's certificate by decrypting the message digest using the CA's public key. The certificate is deemed valid if the decrypted message digest matches the digest Alice calculates from all data in the certificate.

Alice starts by connecting to Bob. If Alice is a browser, and Bob is a server, then Alice connects to the domain name "Bob". The SSL/TLS handshake starts immediately after Alice successfully connects to Bob. Bob's public certificate is transferred to Alice during the TLS handshake phase.

Certificate Validation

Alice verifies that the certificate she received from Bob is valid by decrypting the message digest and by comparing the decrypted message digest with her own calculated message digest. The certificate is deemed valid if the two message digests match; however, she still does not trust Bob since she has not validated Bob's CA. Alice now uses the CA identification found in the received certificate and looks up the identity in her own CA list. Bob is trusted if Bob's CA is found in her own CA list. Alice will not trust Bob if Bob's CA is not found in Alice's CA list.

At this point you may think that Alice trusts Bob, but there is one important security check that remains. At this point, Alice has verified that the certificate received from Bob is valid and signed by a CA found in her own CA list. However, a person performing a man in the middle attack could potentially send Alice another certificate signed with the same known CA. This is possible since the person performing the attack can have legally purchased a certificate from the CA. To prevent the man in the middle attack, Alice must make sure that the domain name "Bob", i.e. the server she connected to, matches the domain name found in the certificate. The domain name is part of Bob's identification and is embedded in the certificate. Alice can finally trust Bob if the domain name in the certificate matches "Bob".

In the above scenario, only Bob needed to provide his certificate's credentials. This is the typical use case for browser to server communication. For example, when you navigate to your bank, you want to make sure the browser helps you verify that the bank's web site is trusted and that it is not hijacked by someone attempting to spoof you. The bank's server, Bob, also requires that Alice identifies herself, but this is typically done by logging into the site, not by using client SSL certificates for identification purposes.

How to Use SSL Certificates in Embedded Devices

When using SSL, only servers are required to provide a certificate. However, in many cases, an embedded device will operate as an SSL client that connects to a server. Such a setup falls within the typical Machine to Machine (M2M) definition. In such cases, it is common to use certificates for the client. This ensures that only certified (valid and registered) devices can connect to the server.

What this means is that you will likely require a certificate regardless of using a client or server SSL stack in the device.

The SSL protocol can provide mutual trust management, but it's not common to do so when using a browser. Using the SSL protocol to authenticate the clients is more common in Machine to Machine solutions, where no humans are involved during the connection phase. SharkSSL provides dual authentication, where both peers can authenticate each other.

In an M2M deployment scenario, you will in many cases install the server and device infrastructure including the certificates. It is for this reason we recommend that you create your own root certificate and become your own CA if you design M2M solutions. It becomes much easier to manage the certificates if you are the CA. You can also sign certificates for non standard domain names such as "localhost", "target1", etc..

When using existing equipment, such as a browser connecting to your secure device web server, you may consider signing your server's certificate with a well known CA. The reason for this is that the browser is already configured with a Certificate Authority Store (the browser's CA database). If you are not using a well known CA that is already in your browser's CA Store, you will have to ask the user to install your root certificate. This is the solution we selected for the SharkSSL server demos provided on our site. We provide users instructions for how to install Real Time Logic's root certificate when running our server demos.

Although this was a quick introduction to digital signatures, SSL certificates, and trust management, it should be sufficient for you to use this information as a base when working with certificates. For more information, see the following two articles on Wikipedia:

SSL certificate tip for small microcontrollers:
You should avoid using CAs that provide chained certificates if you are developing a secure solution for small resource constrained embedded devices. The reason for this is that certificates are large and a chained certificate is even larger since the chain (the intermediate CA) must be embedded in the client and/or server's certificate. The problem with large certificates is that SharkSSL must be configured for larger buffers.

IoT Security: Creating X.509 Chain of Trust

The following IoT Security video provides a practical example that you can follow and setup on your own computer for learning purposes. The comprehensive video tutorial guides you through the process of setting up secure and trusted communication.

The video shows how to create an Elliptic Curve Cryptography (ECC) certificate for the server, how to install the certificate in the server, and how to make the clients connecting to the server trust this certificate. The server in this video is installed on a private/personal computer on a private network for test purposes.

Related Articles:

Posted in Whitepapers