The TLS and Java Card story for IoT and more

I always hear that when the TLS protocol is used between a client and a server then everything is secure to exchange data in between the two ! I would like to stress a little bit this assumption in particular in the context of the IoT where billions of devices connect to the cloud. Indeed if we make abstraction of the way keys and sensitive secrets are generated and used on both sides the protocol is hopefully secure (version TLS 1.3 is the latest one) but we obviously need to consider the handshake part of the TLS protocol during which authentication and secrets sharing are performed.

Not to enter into too much details here, let's assume that the TLS version and the TLS ciphersuite used between both parties are state of the art for the purpose of this post.

IoT Device and IoT Cloud mutual authentication

1. Server/Cloud Authentication The TLS protocol performs a server authentication done by a client during the TLS handshake protocol. This is a mandatory part from which session keys are generated and shared by both sides. Then, session keys are used by the TLS record protocol that permits to exchange data securely. We may call this a secure channel. Data passing within this secure channel depends on this TLS server authentication step.

2. Client/Device Authentication The TLS protocol allows also for a client authentication done by the server during the TLS handshake protocol. This part is optional and rarely not to say never used in the context of IoT. To make it short: It implies too much management constraints and time processing. Consequently, other means are usually used to perform client authentication. Most of them are token based e.g OAUth2 tokens are used. Those tokens are passed from the client to the server throw the secure channel we just mentioned. In other words the passing of a genuine token is directly dependent on the TLS handshake protocol at the time of server authentication. This clearly makes the TLS server authentication processing on the critical path of the security of the solution.

Focusing on the server authentication side then: when you access the internet/cloud from a browser (to take a PC/mobile world example), your browser is equipped with a list of root certificates from vendors around the world which are used to authenticate the target server. The security of the process comes from the fact that you trust your browser. With IoT, you now have devices directly connected to the cloud you may not consider trusted. The whole TLS story in this context is at risk. Luckily solutions are possible.

Trusted Hardware

When you cannot trust a device on the whole, the solution is to reduce the scope of what you want to protect: you factorize your sensitive operations and assets and manage them within a dedicated trusted hardware that offers software and/or hardware protections from software and/or physical attacks. There are a few of such solutions for different use cases, with different specificity and different level of trust. We can mention TPM (Trusted Platform Module), TEE (Trusted Execution Environment), SE (Secure Element) as examples of such trusted hardware.

A first concern is that those are usually used to host a private key or a secret to perform device authentication but rarely used to host root certificates and process the TLS server authentication phase. TPM is not a run-time making it hard anyway but the two others are hosting run-time environment though.

A second concern is that those trusted hardware take different forms i.e for the SE case, some are discrete hardware (removable SE, embedded SE) or directly integrated on the device hardware platform (integrated SE). This does not help to provide a generic solution for the TLS server authentication.

Oracle Java Card as the unified framework for TLS authentication

Oracle Java Card framework is a security oriented framework running above a Secure Element and that successfully protects the most security demanding use cases since more that 20 years now: payment, Identity, Network access ... Its run-time capability and security oriented features make the development of a TLS server authentication application straight forward by guaranteeing its end to end security i.e. all phases of the TLS handshake protocol are secured and can be coupled also with the device authentication chosen mean. More than that, this is the only framework capable to adapt to the different family of trusted hardware avoiding fragmentation of the security solutions which is so critical in the IoT business.

Source: oracle.com