Advertisement

Last April, the Heartbleed bug caused us to update all our passwords. Then in September, the Shellshock bug forced Linux users to update their bash shell. More recently, the Poodle exploit put an end to SSL 3.0.
Network security is constantly under threat, which is worrisome, considering how much of our life is getting intertwined with the Internet. With the predicted rapid growth of the Internet of Things and the resulting explosion of connected, low power devices, embedded device designers need to understand and worry about network security like never before. With that in mind, I thought a brief introduction to TLS might be useful for embedded designers.
When you log in to a website and start exchanging personal information, you do so over a secure connection. The “s” in “https” informs you of this fact. This secure connection is established using the Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocol. TLS is based on SSL, so you can think of TLS as the newer flavor of SSL.

So, when you connect to a server, how do the endpoints decide which protocol version and encryption algorithms to use?


When the client establishes a secure connection, a SSL/TLS handshake is performed between the client and server. The client initiates the handshake with a client hello message, which contains, amongst other parameters, a client_version field. According to RFC 5246 (TLS version 1.2), this field should contain the latest version of the TLS protocol that the client supports. Common values include “{3,0}” for SSL 3.0, “{3,1}” for TLS 1.0, “{3,2}” for TLS 1.1 and “{3,3}” for TLS 1.2. The server must respond to this message with the server hello message. This response contains a server_version field, which either confirms the client-specified TLS version if the server supports it, or informs the client of the latest
TLS version supported by the server. In the latter case, if the client agrees to use the server specified version, then the handshake will proceed as normal; otherwise, the client must generate a protocol_version alert.

You may have heard about the recent POODLE exploit, which has caused the end of SSL 3.0. Because of the way the SSL/TLS handshake works, browser and servers that support SSL 3.0 are susceptible to a man-in-the-middle attack that can downgrade TLS to SSL 3.0. And once a connection has been downgraded to SSL 3.0, its encryption can be broken. This is why clients and servers must explicitly disable SSL 3.0 support even if they support a higher version of the TLS protocol.



In addition to the protocol version, the exchange of client and server hello messages also negotiates a cipher suite. The client provides a list of cipher suites that is ordered based on the client’s preference. The server responds with the selected cipher suite. The selected suite will determine how session keys will be exchanged (e.g., using RSA), what cipher will be used (e.g., AES CBC) and how data integrity will be ensured (e.g., SHA-1)

Let’s take a look at the data integrity algorithm. If we are using a cipher block chaining (CBC) mode cipher, the data integrity options are:

• MD5
• SHA-1
• SHA-2 (256 bits)

From a security perspective, MD5 is not considered secure, and SHA-1 is starting to be phased out: NIST required Federal agencies to stop using SHA-1 in 2010, and both Google Chrome and Mozilla Firefox have announced plans to phase it out. That leaves SHA-2 as the only secure option. It is also the most computationally expensive of the three, running approximately 55% slower than MD5 and 25% slower than SHA-1, according to one benchmark. In CBC mode, the block cipher options are:

• Advanced Encryption Standard (AES)
• Camellia
• SEED
• ARIA
• International Data Encryption Algorithm (IDEA)
• Triple Data Encryption Standard (3DES)
• Data Encryption Standard (DES)
• RC2

DES and RC2 are not supported in the later version of TLS because they are no longer considered secure. Triple DES is still approved by NIST, but is considered weaker than AES.

AES is a US government standard that is widely used in industry. There is a lot of hardware support available for AES, whether it is in processors, such as the Intel and AMD AES instruction set, or in FPGAs with an abundance of AES cores available.

Camellia, SEED, ARIA, and IDEA are all considered secure, but a few Internet queries will quickly reveal that there are far fewer hardware options available for these protocols.

The open source Crypto++ Library, which implements all of these ciphers, provides performance benchmarks on its website. Those results are favorable to AES, which seems to enjoy two to three times the speed of Camellia, SEED and IDEA.

In addition to CBC mode, the most recent version of TLS 1.2 added support for authenticated encryption ciphers, for AES, Camellia and ARIA. This type of encryption simultaneously provides authentication and is viewed as more secure.
It should be noted that the cipher suite selection performed during the TLS handshake will depend on the selected TLS version and the specific TLS implementation. The TLS RFC states that implementations are not expected to support all cipher suites, but rather only the ones meeting the cryptographic requirements of their applications. Therefore the cipher suite selected will depend on the SSL/TLS software (e.g. openSSL, LibreSSL, Network Security Services) and its configuration.

Once the client and server have agreed on a protocol version and a cipher suite, they will perform authentication and exchange session key information according to the cipher suite selection. Then the TLS handshake will end with a message exchange indicating that encrypted data will start flowing. At this point the higher level application, whatever it may be, can start exchanging sensitive information. This happens until the session is terminated or renegotiated; TLS supports an option for renegotiating the session, thus going through the TLS handshake to re-establish the selected protocol version, cipher suite and session keys.

It doesn’t seem like too long ago when embedded devices were, by their very nature, somewhat immune to security treats. As we scatter embedded devices everywhere and connect them to the all mighty cloud, we not only increase our exposure to computer security breaches, but also make ourselves a more interesting target for would-be attackers. Whereas network security use to concern only web developers, it is becoming an indispensable skill for embedded engineers as well. We probably all like the idea of developing products that could exist in everyone’s home (finally you could show your non-engineer friends what you do), that is until we accidentally open everyone house to hackers.

Bernard Vachon has more than 18 years of experience developing scalable embedded software, with a focus on telecommunications and multimedia protocols. His strengths include Linux, C/C++, and networking, as well as significant experience managing engineering projects. Prior to joining Cardinal Peak, Mr. Vachon worked for 9 years at Carrier Access (now part of Dell Computer). He holds a M.Eng. in Engineering Management from the University of Colorado at Boulder, and a B.Eng. in Computer Engineering from McGill University.

Advertisement
Advertisement