µTasker SSL/TLS

IoT (Internet of Things) has been the new buzz word for some time now, even if it is doesn't represent anything really new in any way seeing as "things" have been communicating autonomously across the Internet for years before the expression was thought up. Nevertheless, whether the name has a signifiant new meaning or not, it probably has concentrated attention on the fact that this can be useful and started a major drive to actually utilise the capability (and of course not missing out ouf the next billion dollar industry).

One of the major areas of concern which the IoT throws up is that of security and it is anticipated that this topic will further develop as IoT solutions develop. For this reason secured network connections for small embedded is being considered here.

Of course the subject is not new and all browsers, and many every day PC software applications, have supported secure connections for over 20 years. Originally SSL (Secure Socket Layer) and later its successor TLS (Transport Layer Security) are included in all PC operating systems and widely used. There are others but we will stick to these due to their popularty.

Security is a complex topic and has many faces (authentication, confidentiality, integrity, non-repudiation) and the (many) algorithms involved are not necessarily something that everyone can understand or has the time available to attempt to. Software implementations therefore require not only the thorough understanding of the issues involved but also the correct application of the parts required to avoid becoming easy targets for malicious security experts to potentially easily find and utilise weaknesses.

OpenSSL

The OpenSSL cryptography library contains implementations of the best regarded algorithms, is maintained by leading security experts and made available for general use. It is a free implementation of the SSLv2/SSLv3/TLS protocol - www.openssl.org - based on the SSLeay library developed by Eric Young and Tim Hudson.

For this reason it was decided that the use of the definitive source for security should be further investigated for use by memory-constrained devices, as will often be the basis for practical IoT devices.

mbed TLS

The security project PolarSSL was taken over by ARM in late 2014 and rebranded as mbed TLS. Its code is easily avaialble as open source but also with a supported option called "mbed Partnership". Although the features of mbed TLS are reduced in comparison to OpenSSL it is somewhat easier to get started with, especially for Windows users because it includes a VisualStudio project allowing its library to be easily built and a number of test projects showing many features in operation. Being lighter in weight it also promises to be more suitable for embedded systems.

Mainly due to the easier Windows based approach with various examples that work without complicated preparation work, plus the fact that it has backing from ARM, it was deviced that mbed TLS may be preferred by many people and this needs to be seriously considered alongside OpenSSL.

SSL

SSL is available as SSLv2 and SSLv3 specifications, whereby there was no official SSLv1 specification and this version doesn't exist in practice. Due to recent evidence of potentially serious weaknesses in SSLv3 it is suspected that only its successor TLS should be used today.

TLS

TLS is SSLv3's successor. Originally released as specification TLSv1 it is presently at TLSv1.2, whereby the latest version resolves some newly detected risks in the earlier specification. It is in fact suggested that SSLv3 is effectively dead SSL versus TLS – What’s the difference? and it may be best strategy to only work with the latest TLS revision and not consider the need for SSL at all.

SSL/TLS is suited to securing TCP connections and thus popular as a security layer above TCP for HTTP etc. It is however not generally suitable for securing connection-less links such as UDP.

Since TLS is not a completely different protocol to SSL, but instead a refined version of the original SSL protocol with a defined set of parameters that may be used, SSL/TLS will be used as a general term from this point on, as is often the practice

Basics of SSL/TLS

The first thing that is found is that SSL/TLS is not a single layer that sits above TCP but has two layers; above TCP is the Record Layer which carries a number of different message types. As well as carrying application data, other message types at the next layer are Alert, Handshake and Change Cipher Spec.

The most fundamental part of the secure connection is how it is actually established. Since this is taking place above the TCP layer a TCP client begins by establishing a standard TCP connection, which may be on a dedicated port number to aid in recognition - such as TCP port number 443 for an HTTPS connection (as opposed to TCP port 80 for an unsecure HTTP connection). With the TCP connection established the SSL/TLS handshake can begin.

1. The client sends a ClientHello handshake frame which includes a list of algorithms that it is willing to support, along with a random number that it has just generated for the unique session.
2. The server chooses one of the offered (cipher) algorithms and informs the client which one is to be use, along with a certificate containing the server's public key as well as a unique random number of its own. This handshake step contains a series of actual Certificate handshake messages, starting with a ServerHello and ending with a ServerHelloDone.
3. The client verifies the server's certificate and extracts the server's public key before using it to encrypt a random secret string called the pre_master_secret, which is generates for the unique session. The message returned to the server is known as the ClientKeyExchange message.
   Based on the pre_master_key and the client's and server's random numbers both client and server independently calculate encryption and MAC keys that will be used during the session.
4. The Finished handshake message completes the connection stage. This is sent by both sides to confirm that they have completed the initialising process. This message is protected using the negotiated algorithms which avoids any possibility of the handshake mechanism being tampered with in any way.

After these few 'simple' steps there now exists a secure connection that uses an agreed set of cryptographic algorithms and a common set of cryptographic keys. The handshake cannot be compromised by attackers between the client and server manipulating frame content and the keys cannot be known by observing the procedure. The result is that hundreds of billions of dollars worth of on-line transactions and further trillions of funds can be safely exhanged throughout the world every year!

Of course the details concerning the individual steps are a result of many years of mathematical developments (both by governments, military and accademic institutes) and over forty years of research and investigations into potential weaknesses and refinement to achieve the level of security that is presently acceptable.

Initially it will be assumed that the embedded system is the server in the process; in fact an HTTPS server to be concrete to allow easy testing with any modern browser. It is expected that a modern browser will expect a good level of security and thus not be willing to connect to a server that doesn't at least achieve its minimum requirements concerning algorithm usage. A check with Firefox as delivered in version 35.0.1 showed that it, as client, uses TLSv1.2 and lists the following 16 cipher suites that it is willing to use:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
• TLS_ECDHE_RSA_WITH_RC4_128_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_RC4_128_MD5

It is assumed that the embedded server must therefore support at least one of these to be able to establish a connection with this browser. It is also assumed that each of these cipher suites enable a connection of the minimum required security level.

Certificates

SSL/TLS is based on public key cryptology, which means that the server's public key is divulged to the client and then used as a shared but not secret input to the exhanges. Public key encryption is practical due to the fact that no secret keys have to be exchanged but has a complication in that the client needs to be sure that the public key that it is receiving is really from the server that it is exchanging the data with and has not been supplied by a man-in-the-middle attacker.

This is where certificates come in - see step two of the handshake - meaning that the server supplies its public key in a certificate that can be vouched for as being from the claimed source by a trusted third party, known as a Certificate Authority (CA), which involves a third entity in the exchange. This Public Key Infrastructure (PKI) is the subject of complete books in itself!

In the public Internet a reputable CA, such as VeriSig (now Symantec), will be involved and would have generated the certificate for use during a certain period of validity after carefully confirming the authenticity of the person or organisation using the key. A certificate for a web server typically costs between $400 and $1'500 a year depending on the security and trust level required.

In private (and test) networks the certificate may be self-signed/generated and a local CA issues certificates to local clients which are configured to accept the CA as being trusted. It is assumed that a self-signed certificate is suitable for development work.

Certificates are usually formatted in X.509 format, whereby there exist 3 different versions - X.509v1, X.509v2 and X.509v3.

Getting Started

As has already been determined, an HTTPS web server with its certificate requirements (certificates can also be required at a client too if the server needs to authenticate the client but this is an exception to the general case) is in fact the more complicated side but it still does seem like the best starting place. Also since a certificate will be needed to be able to start secure communication this also makes sense as the starting point of a journey into the SSL work.

Specifically, a CA (Certificate Authority) to self-sign a root certificate and then issue a certificate was considered as a first leg of the journey. In fact the OpenSSL shell does include enough commands to allow this to be performed and in fact it doesn't need to be embedded in any way. On the other hand though it was still of interest to be able to start experimenting with embedded operations in order to start comparing potential solutions that not only allow tasks to be performed but also represent practical implementatiosn for embedded projects.

The first thing that one learns when starting out with such operations is that there are many possible options involved and many more potentially important things that need to be considered in the choice of such options. For example, is the private key an RSA, DSA, or DH type, how long is it, in what format is it to be saved in (DER or PEM?), how is it going to be protected? eg. is is saved in encrypted form with a pass phrase to unlock it, and with which encryption is it to be protected? ae128, aes256, des3 or others? How will it be later protected in an embedded system since it makes little sense in going to the lengths or securing a system if an attacker just needs to open up the physical server (which is unlikely to be in a protected zone) and read out the secret key details?

In fact it was decided that the process of private key generation represented a basic element that would be more suitable for a first practical comparison. It is not the most basic element because it calls on more basic methods such as random number generation, a number of agorithms and big number mathematics which form the basis of much security related work. It is not overly complicated with decisions that need to be made and both OpenSSL and mbed TLS contain methods that can be used fairly conveniently to generate a key in a PC environment. Since private key generation is fundamental to SSL (bith cleint and server need a secret key) it was envisaged that moving this process to an embedded environment could represent a suitable test vehicle to initiate development work.

The goal was therefore set to use both OpenSSL and mbed TLS key generation methods as references and embed both solutions into a Kinetis device. Since some Kinetis parts include cryptographic acceleration support it was envisaged that some of the code could be adapted to make use of the hardware and also the available hardware would likely dictate the most suitable options for private key generation. Not only would this offer the opportunity to get to know the techniques involved but the work would allow the capabilities of the two packages to be compared as well as the actual effort required in each case, plus some indication about code size, memory requiremenst and executions speeds to be gained.

This part project is documentated at the Private Key Generation page.

Present State of Developments

The µTasker project presently doesn't include support for SSL/TLS based secure connections, although it is understood that projects based on it have added SSL for their own security requirements (STR91XF). An integrated solution is being investigated and further developments will be reported here as appropriate.

For specific questions and feedback please use the following forum entry: SSL/TLS Secure Connections