AES vs SSL/TLS: Encryption for the internet of things

The adoption of devices for the internet of things will depend very much on their communication to the Internet being secure. There are many aspects to being able to secure connections between client devices and servers. The primary step is to properly encrypt the data stream so that it doesn’t provide confidential data to someone who has been able to intercept the messages and to avoid a malicious user to impersonate either the client device or the server. This step is imperative. If you don’t do this, and do it right, don’t bother with anything else.

Two very popular encryption protocols for device to server communications are TLS and AES, which is also sometimes referred to as Rijndael. Even when the link-layer is encrypted (such as WPA2 for Wi-Fi), it is important to use one of these methods to encrypt the data stream so that snooping is impossible once it makes it into transport mechanisms that are not encrypted, such as the Ethernet upstream port of a Wi-Fi access point.

Fig 1: Simplified connection using AES encryption.

AES is an open encryption standard first established by the United States National Institute of Standards and Technology (NIST) in 2001, and sometimes also referred to as FIPS 197 for the government standard publication that established it.

AES uses symmetric cryptography, which means that the same key is used to encrypt and decrypt the data. This then means that the greatest vulnerability is the unauthorized distribution of the encryption key. For that reason, this encryption method cannot be relied upon if different entities control the server and the end devices. However, if the server and devices are controlled by the same owner, then the advantage to using symmetric cryptography is not having to manage expiring certificates like the in the case of TLS.

While details of the cipher used are beyond our current purpose, AES is considered so secure that it is approved by the NSA to be used in Top Secret information when using 192 or 256 bit keys. It is important to note that AES should not be used by itself, but in a cipher chain. The most common method is to use an initialization vector (IV) to scramble the unencrypted data before being encrypted. This ensures that two identical messages don’t result in identical encrypted data, which prevents someone from inferring patterns even from the encrypted data stream.

TLS (the successor to SSL) is well known as the protocol that encapsulates HTTP and SMTP to provide secure web browsing via HTTPS, and secure email client/server communications via SMTPS. The protocol uses asymmetric cryptography to authenticate the other party. Once the two parties have authenticated each other, they exchange a symmetric key to encrypt the rest of the data transmission during the session. The encryption normally uses the AES standard.

Asymmetric cryptography uses public/private keys for encrypting the data between the two devices. Data that is encrypted with the public key can only be decrypted by the private key, and vice-versa. In this fashion, two parties can exchange their public keys and can each decrypt data that the other party encrypts with their private key. This is necessary when the two parties might connect to multiple devices not controlled by the same entity. For example, when you use your browser to connect to your bank, public/private keys allow for your session to be secured without you being able to decrypt your neighbor’s separate connection to the same bank.

Fig 2: Simplified connection using SSL/TLS protocol.

The vulnerability in this approach is being able to trust that one is communicating to the right counterparty. Since the device receives the public key at the time of communication, someone who impersonates the server can send its own public key and start receiving data from the end device. This is what is normally referred to as a Man in The Middle attack. In the deployment of an IoT device, it can be done either via a malicious DNS hack on a vulnerable system, or by DNS redirection at a lab that intends to reverse engineer the device’s communications.

The solution to this vulnerability is for the certificates which contain the public keys to be themselves signed by a third party that both the device and the server implicitly trust. This third party is a Certificate Authority . The device must then keep the certificate of the Certificate Authority stored to be able to verify that the server’s certificate is valid.

Another situation that can cause problems for devices using TLS is the installation in sites that use proxy servers for communications. Having a proxy server creates two connections, one between device and proxy, and then another between proxy and cloud server. Because the device and the cloud server never connect directly, the data must be decrypted at the proxy server and re-encrypted. If a provider of IoT devices will support deployment behind a proxy server, relying solely on TLS means that the owner of the proxy will be able to see all the data. This does not happen if the data is encrypted end-to-end with AES.

The total system architecture needs to drive the decision of which encryption methodology is used. It is not enough to say that one supports TLS and is thus secure. One can only look at the recent news of IoT devices becoming inoperative, such as the Wink Hub issue in April of 2015, to see that maintaining expiring TLS certificates can cause major problems in the deployment of IoT devices.

If a manufacturer controls both the server and the end devices, then the symmetric key paradigm presents a lower maintenance option which provides end to end security. But if the end devices need to be able to communicate to public APIs by other services, then TLS is necessary. The main drawback of the symmetric key approach is the possibility of the key becoming compromised and having to replace it in all devices. While TLS has that solved by invalidating certificates, there is a big concern with TLS because of the management of the expiration of certificates.

Implementing any security protocol for an IoT device can be a daunting task. Using the right encryption mechanism can leave a system vulnerable if the total system implementation does not follow best practices. One way to ensure the most secure system possible is to use a network coprocessor, or device server, that has security built in. For example, the Lantronix XPort Pro has the security built in for Ethernet-connected devices, while the Lantronix xPico Wi-Fi can help you add security to devices that need to be connected to a Wi-Fi network.