Page 1 Confidential

IoT security: real problems and solutions

Introduction “IoT security” is a popular topic, and there is not a single week without a conference featuring a paper or a keynote about security, an announcement from hardware or software companies introducing new solutions, or an article in the press. Avnet has an established history in helping customers bring their IoT solutions to market, and this paper aims at defining the real issues behind “IoT security,” the real challenges for our customers in both hardware and embedded / server software and solutions as we envision them for the next six to eight years, until our world becomes all IPv6 and 6LoWPAN.

We could start like many others, explaining how connected devices are at risk, how hackers can ruin business models, and how much everyone should look into cryptography. We will not.

The main problem our customers face is the cost of personalizing the devices they manufacture with unique IDs, MAC addresses, keys and certificates, either on the production line or during field deployment. Surprisingly or not, technical solutions for personalization very often provide an additional toolset enabling the highest level of security at no additional cost.

We will demonstrate how the security architecture of the Internet of Things should leverage the security architecture of the Internet as we have been building it for more than 20 years. We will explain the challenges of properly provisioning and securing low-power non IPv6 connected sensors and devices.

In the past 15 years, enterprise Information Technology (IT) architects have successfully upgraded their security schemes from an all-wired world based on desktop computers to all-wireless-mobile laptop and smartphone fleets without compromising on security, and even improving it. A similar evolution is happening now: beyond laptops and smartphones, industries are looking to connect many devices, machines and objects to application servers through private and public networks, as shown here.

Page 2 Confidential

What needs to be solved The cost of personalizing connected devices Regardless of the application and the security scheme associated with it, there is always a point in the life of a device connecting to another or to a distant server when someone needs to program unique identifiers and secret keys into a memory.

This process is called personalization. This is a hurdle, often a burden, and always a cost in the manufacturing process or for the end-user.

Let us take a straight-forward example: adding a WiFi printer to a home network. At some point, you will need to manually associate the printer with the router so that they can share the same passkey. Whether you do it manually, via NFC or with a USB cable, the printer needs to know the secret key. In this case, the burden is not supported by the printer manufacturer but by you, the end user.

The same thing applies in the business world but on a larger scale. One example from building automation is an alarm system. This comprises a central unit and several peripherals communicating locally via an RF protocol, and may be sold individually or bundled. Someone, whether the manufacturer, the installer, or the end-user in DIY mode needs to “pair” or “associate” the peripherals with the central unit, and then register the central unit with the global surveillance service.

In all these cases, someone has to bear the cost of going through this personalization and pairing process, either the manufacturer of the device, the service provider or the end user himself at the expense of a true out-of-the-box experience.

The complexity of these processes often makes them a weakness in the security of such networks. How often do you renew your home WiFi pass-key? Probably never because it is too much of a hassle. How often are secret AES keys renewed in many systems? Not often and possibly never for exactly the same reason.

Networking and security: the importance of “end-to-end” Link and network security are being addressed by every single communication and networking technology at different levels of the protocol stacks such as IPsec for IP, WPA for 802.11, 802.15.4, Bluetooth and so on. However, they should not be mistaken for end-to-end application security.

Indeed, having a WPA-secured WiFi connection to a local router is definitely not sufficient to “http” privately into a distant server, bearing in mind that most local network keys are hardly ever renewed for the reason explained above.

As illustrated below, it is fairly common that the data generated by a sensor or a machine will be conveyed through many different networks of different sorts belonging to a variety of service providers before reaching the targeted application server:

Page 3 Confidential

Each leg is only responsible for its own security, and is unaware of the legs behind or in front of it. As a consequence, the data has to be decrypted and re-encrypted within each gateway, from one leg to the next. It is often said that the security level of a whole system is defined by its weakest link. Therefore, the need to trust several connectivity providers as well as the gateway manufacturers interconnecting them is clearly a weakness.

If the data is carried over IP all the way, there is an option of “tunneling” from the sensor to the application server. However, this is the only possibility that comes close to “end-to-end” security in this scheme.

The solution is an extra level of end-to-end device-to-server security taking care of:

- Device authentication to server

- Server authentication to device

- Secure session key establishment

- Data integrity

- Data confidentiality if needed

Page 4 Confidential

Solutions End-to-end security in the IP world

SSL (Secure Socket Layer) It has been more than 20 years since Netscape released the initial public version of SSL (numbered 2.0 as 1.0 was never released because of flaws) in 1995.

The idea was simple: how could Internet clients communicate securely and privately end-to-end with applicative remote servers delivering email, banking and e-commerce services through the public Internet regardless of their hardware/software platform and OS (Operating System)?

“Securely and privately end-to-end” meant the client was able to authenticate the server, not exposing passwords and confidential information to any third party including Internet Service Providers (ISPs) and Telecom Operators. It also had to keep eavesdroppers and hackers at bay.

The easiest answer to this problem was to use the same unique secret key on both sides of the communication channel.

The main problem then became: how to distribute this unique secret key without exposing it?

Using an alternate channel could be a solution: After all, banks send us credit/debit card PIN codes in a separate mail, and some websites use our email account to send us a provisional password when registering for a new service or requesting a password reset. Nevertheless, this was no lightning-fast process and certainly not practical for renewing session keys on a regular basis in a seamless and user-transparent way.

The real breakthrough came from the use of asymmetric cryptography.

This technology involved a fundamental transaction invented 20 years previously between 1973 and 1977 by asymmetric cryptography pioneers Clifford Cocks, Whitfield Diffie, Martin Hellman, Ron Rivest, Adi Shamir and Leonard Adleman. They had devised methods for computing a unique shared secret key between two entities communicating over a public channel without exposing any secret information. Simply brilliant! Any acronym bearing RSA (Rivest, Shamir, Adleman) or DH (Diffie-Hellman) refers to these mathematicians. Since Cocks was working for the British secret services, his work and name were kept secret until recently, but he nonetheless deserves the recognition.

Page 5 Confidential

The powerful asymmetric cryptography (RSA, ECC) required much more processing power to encrypt and decrypt data compared with symmetric algorithms (DES, AES), and therefore was not very efficient to encrypt and decrypt every single packet exchanged over the Internet. For this reason, its use has been mostly restricted to the exchange and computation of symmetric session keys to encrypt and decrypt the streams of data exchanged over the Internet.

Back in 1995, it was therefore possible for a client to securely authenticate a server and compute a shared secret session key used to exchange data:

Need for certificates As is illustrated here, servers do not send their public key as is; they send certificates embedding their public key.

Why not send a public key directly?

Because the client needs to be able to differentiate the genuine web site it wants to connect to from a fake one. How to differentiate between www.mybank.com and www.my-bank.com if the latter one wants to impersonate the real bank in order to capture account credentials?

Both will have a public key, but the client needs to check which one corresponds to www.mybank.com

In order to do this, the world relies on Certificate Authorities (CA) who are trusted independent corporations issuing digital certificates that certify the ownership of a public key by the entity named in the certificate.

Let us assume that www.mybank.com wants to issue a public key. Mybank will first send it to a Certificate Authority (CA) along with its credentials and proof of its identity. The CA will check that www.mybank.com is the owner of the public key and issues a digital certificate (complying with the X.509 standard) comprising www.mybank.com’s public key, the name of mybank.com and its other credentials, validity dates signed with CA’s private key.

This digital certificate will then be sent back to www.mybank.com who will share it with web clients requesting a connection.

Upon reception, the client will check the signature of the certificate using the CA public key (which is usually preloaded into the web browser). In this way, thus authenticate the certificate and therefore trust that the public key inside the certificate belongs to www.mybank.com which is the website it is asking to connect to.

Page 6 Confidential

In spite of many ongoing reflections on ways to improve the system, this architecture is the one currently securing the Internet.

TLS (Transport Layer Security) After a few flaws and weaknesses discovered in SSL2.0 and SSL3.0, SSL has evolved to TLS1.x based on improved algorithms for signing, authenticating and encrypting, which will not be detailed here.

In particular, Elliptic Curve Cryptography (ECC) often replaces RSA, as it provides much shorter keys and less calculation complexity along with a higher level of security.

Embedded sensors and IPv6 Whereas the tremendous growth in the expected number of Internet-connected devices has led to migrate the addressing space from 32-bit in IPv4 (4.3B unique addresses) to 128-bit in IPv6 (3.4x1038 unique addresses!), the billions of sensors and devices being deployed are not yet natively IP-compliant.

Indeed, most of these devices are likely to communicate wirelessly and in many cases to run on batteries without maintenance for five to 15 years depending on the use cases.

Although a few IP-friendly wireless technologies such as 802.11 and cellular 3G/4G have been around for years, they still fail the battery life test.

Instead, battery-friendly wireless technologies tend to favor small payloads, extended sleep time, asynchronous behavior and asymmetric communication, very often connecting to gateways with LAN (Local Area Network) connectivity such as Bluetooth, ZigBee, WmBUS, Z-Wave, Enocean, KNX, ioHomeControl, 802.15.4, or more recently without gateways with LPWAN (Low-Power Wide Area Network) technologies such as SIGFOX, LoRaWAN and NB-IoT, to name a few.

Although recent implementations of 6LoWPAN (low-power wireless IPv6) have emerged such as Thread and Bluetooth 4.2, it is expected that a vast quantity of sensors and devices that will be deployed under the IoT banner will actually NOT be IP-friendly until 2025 at least for reasons of backward compatibility and legacy with existing products.

This means that these billions of devices, from smart meters to industrial sensors will not be able to use the Internet Protocol standard to establish a TLS session with the server they will be connecting with.

Page 7 Confidential

End-to-end security outside the IPv6 world Is this the end of our story? Certainly not! We are looking for a way to implement this green layer of end-to-end security that sits on top of the other security legs:

We have at least one leg which is not IP, probably low power, low data rate acting as a bottleneck on the whole path (remember if we are IP all the way, go to the previous paragraph, problem solved).

There is a simple answer: if genuine IP TLS is too heavy with too much overhead for this bottleneck, let us tailor a derivative of TLS bearing:

- Cryptography algorithms with shorter keys (ECC) rather than longer ones (RSA)

- Smaller certificates

- Extended session key validity

- A simple capability for a sensor to check a server certificate off-line if needed

- A secure and cheap way to personalize and store certificates together with session

keys in the sensor or device

- Certificate Authority services enabling the issuance and checking of custom

certificates

Page 8 Confidential

This TLS derivative should perform the same functions as the real TLS:

- Mutual authentication

- Very simple and automated provisioning of a sensor/device into a distant application

- Mechanisms for revocation of a sensor/device from a distant application

- Secure AES session key derivation and secure exchange

yielding message integrity and encryption

Secure elements Although many MCUs boast low-power cryptographic engines, they miss the real problems:

- Someone still needs to personalize them at some point, and this has a cost.

- They are not secure and secret keys can be read from their memory or computed

from dynamic supply currents or even from their electromagnetic emissions.

This is the reason why credit card and SIM card chips are not standard Cortex-M3 hardware.

This is the reason why secure elements are useful.

Secure elements are tiny components connecting as peripherals to host MCUs/MPUs and featuring:

- Personalized certificates

- Secure hosting of secret keys

- Handling of cryptography primitives

In short, they are part of the solution together with secure personalization logistics.

Page 9 Confidential

Bottom line: personalizing a connected device Our initial problem was lowering the cost and the burden of personalizing and provisioning connected devices, sensors, machines to local or remote servers. By regrouping the technologies mentioned above, we now have a full set of solutions:

- TLS or TLS-like stacks and APIs capable of mutual authentication, distribution and

renewal of session keys

- Secure elements able to host certificates and handle TLS primitive functions

- Secure logistics in order to personalize secure elements before device

manufacturing eliminating the need to personalize the device itself

- Trusted Certificate Authority services for issuing and checking custom certificates

during the 15-year life of the connected product

Gateway A gateway typically bridges between a Local Area Network (LAN) and the application server through the Internet (IP network). It therefore needs to securely authenticate to the server and securely authenticate the server it is connecting with.

Since the link between the gateway and the server is IP-based, this can be handled with a TLS protocol over any IP connection, whether WiFi, Ethernet or 3G/4G.

A recommended implementation will be our Avnet -personalized secure element as a companion chip to the main processor running our UbiquiOS stack in the gateway, seamlessly handling the TLS with the server running our APIs and performing the task of provisioning the gateway with HTTPS or MQTTS.

IP or 6LoWPAN sensor As seen above, sensors are often battery-operated and need to operate light stacks. 6LoWPAN is the low-power version of IPv6, typically used by the Thread™ networking protocol. In this case, it will be possible to establish a TLS directly between the sensor and the server as explained earlier.

A recommended implementation will be our Avnet- personalized secure element as a companion chip to the sensor microcontroller running our UbiquiOS stack, seamlessly handling the TLS through a provisioned gateway with the server running our APIs and performing the task of provisioning the sensor securely with HTTPS or MQTTS.

Non IP sensor If the sensor is neither IP nor 6LoWPAN-based, it will be necessary to establish a TLS derivative tailored to the local networking technology directly between the sensor and the server.

A recommended implementation will be our Avnet-personalized secure element as a companion chip to the sensor microcontroller running our UbiquiOS stack, seamlessly handling Avnet’s proposed TLS derivative through a provisioned gateway with the server running our APIs and performing the task of provisioning the sensor with the best balance of security and power consumption in accordance with the mechanisms in use with HTTPS and MQTTS.

Page 10 Confidential

Conclusion Avnet and its partners enable customers to benefit from their depth and breadth of expertise in addressing personalization and security schemes for IoT projects.

The company represents several secure element manufacturers, including Infineon, STMicroelectronics, Morpho/Trusted Objects, NXP, Maxim and Microchip/Atmel.

May 2016 saw the inauguration of a new personalization center within our European warehouse, located in Poing, near Munich. This advanced logistics facility is capable of personalizing secure elements in small to large volumes, in order to meet the needs of every customer project.

Avnet is also currently developing its own stacks and APIs. These will be able to handle TLS derivatives and easy provisioning schemes running on various radio links, together with UbiquiOS Technology and services from Avnet.

Avnet is also establishing certification authority services with a trusted partner for customers who do not wish to invest in a full public-key infrastructure themselves.