en
de
Internet of Things

SSL isn’t enough for Internet of Things

25 June 2014
| |
Reading time: 4 minutes

For most applications of the Internet, Transport Layer Security is considered the gold standard for security. For a majority of users, a web site that runs over HTTPS is safe – and in the World Wide Web, it most likely is: there is direct interaction between a user (via a browser) and a server system. The user needs to implicitly trust the server, as it processes all data and operations displayed in the browser anyway.

Even for basic Internet of Things applications, this assumption is no longer sufficient. Looking at two very different simple scenarios, the need to consider the system from end to end becomes visible.

Basic architecture

Typical IoT-Architecture

Typical IoT-Architecture, Zühlke

The system we’re looking at consists of a simple temperature sensor. It sends a measurement every five seconds via Bluetooth. A gateway device is connected to the Internet via LAN. It captures the measurement from this and a set of other wireless sensors to a cloud service. A user connects to the cloud service with a tablet.

For more details why this architecture makes a lot of sense, this blog post provides some solid background.

Scenario: Prevent Tampering

Prevent Tampering

Prevent Tampering

In this scenario, the temperature sensor is part of a wearable medical device that sends vital data to a hospital. The data does not contain any information that might identify the patient, so the confidentiality of the data is not critical. The system does not need to provide security against unauthorized parties trying to read messages.

However, the hospital needs to have a reliable history of the patient’s vital data. They need to be absolutely sure that the incoming messages have been sent from the correct sensors so that a physicist can make decisions based on the data.

In order to fulfill these requirements, the sensor signs each message it sends to the gateway with a key that has been assigned to it during productions. The gateway device can read the message in order to create local alarm messages. Before it sends the sensor message to the cloud service, it signs the message with its own key so the message’s way can be traced.

The cloud service stores the sensor messages until they are downloaded into an archiving system. It also processes them in order to provide the physicist with reports about the patient’s health, and raises alarms when critical situations occur. In order to do this, the cloud service needs to access the message content. The digital signatures on the messages allow verification that the data is authentic.

If the connection between the gateway and the cloud service uses transport layer security, it does not hurt – but there is no benefit either. It does not solve the problem of proving the authenticity of the data.

Scenario: Ensure Privacy

Ensure Privacy

Ensure Privacy

In this scenario, the temperature sensor is part of a home automation solution. It records the room temperature in the living room. It sends data to a gateway device that controls the heating system. The tenants can view the temperature on a smart phone app.

While this is convenient, they are concerned that burglars could gain access to the home automation data and glean at which times there’s no one at home. They do not trust the cloud solution: the cloud provider company is known to use data to build up precise profiles on user’s behavior, which would be useful for planning housebreaking.

For the connection between sensor and gateway, there are no specific requirements. However, there needs to be end-to-end encryption between the gateway and the client application. The cloud service can queue messages, but it does not know their content. The client application decrypts the messages, aggregates and visualizes the data.

Transport layer security between the gateway and the cloud, or between the cloud and the mobile device, would not solve the security requirements of the solution.

Don’t rely on SSL

To be clear: if it is possible to use transport layer security, it should be used.  An additional layer of protection does not  harm, and mechanisms like PFS are helpful in case that parts of the system get compromised.

However, the communication patterns in Internet of Things applications are different from the standard pattern of a World Wide Web application. The transport layer may or may not provide a solution for the individual security requirements. In any case, the end-to-end scenario needs to be considered.

Comments (5)

Avatar

Michael Holdmann

26 June 2014 at 15:16

This is one of the reasons why XMPP is being used by US DoD, Intel, UPnP, Allseen, Intel, Bosch Apple, Google and many more. Coversant Inc. chose XMPP for its IoT-SB and was certified by Defense Information Services Agency as it uses TLS with SCRAM SHA-1 Plus SASL External. We place certificates on both sides of connection, client and server for both C2S and S2S connection/federation, with 2048 bit keys and the plus enables channel binding which mitigates man in middle attacks, we also allow white and black listing directly on server. This part of the protocol itself and not external equipment or applications other then the libraries. XMPP also allows the use of any PKI or other data encryption technology if desired. With XMPP only the client call out to server which allows you to close all incoming ports on a firewall limiting intrusion possibilities. All relationships are trusted and are peer to peer not client server.

Avatar

Frank Pilhofer

26 June 2014 at 16:26

Both scenarios involve communicating with a cloud provider that you do not trust. If you trusted the cloud, then in the first scenario, the cloud service could identify the client using a SSL client certificate and also sign the message upon reception. Same in the second scenario: if the cloud was trusted, the issue would disappear. So, wouldn’t it be better to use or build a service that you do trust?

    Christian Heger

    Christian Heger

    26 June 2014 at 16:33

    In the first scenario, there is in fact trust in the cloud. It’s true that we could use the gateway’s certificate used in SSL to authenticate the client, but then, as long as we can authenticate the gateway in any reliable way, we do not strictly need encryption. What we cannot do using SSL is to authenticate an individual sensor or sensor hub connected to the gateway, which is a requirement in the first scenario (admittedly, it was constructed that way).

    Avatar

    Michael Holdmann

    26 June 2014 at 16:50

    Frank- you are incorrect with stating the second scenario is the same. You can deploy your own XMPP server and connect to your legacy and/or new future systems, federation and interoperability are one of the advantages of XMPP.

    Coversant does this with the US DoD, as well as an HVAC RDM system of 200k buildings and 125-1500 devices per building and RDM for 1,000,000 set top box cable company including 100% anonymous gathering of user activity for secure and private reporting to ONLY the ratings agency not the cable company.

    We do have SaaS offering on AWS and Azure, you are in complete and private control of your data and connections, we have no way of knowing what connections with who and where data is going, only how many connected devices for billing purposes. With XMPP you can also security tag individual lines in message body for delivery of specific data to specified clearance levels. These are peer to peer not client server connections, the server acts as a broker only.

    In regards to traffic sniffing an entity could only get information on which domain you are connected to as once the connection and encryption are made and channel bound there is no way of knowing who in the domain you are sending data to.

    So you do have to make sure you trust the applications, systems and databases, suppliers, partners vendors you associating with, whether they be provided in cloud or on closed system, if you use the internet for connection and delivery though XMPP is best choice, if you have the budgets and expertise to purchase and run a dark fiber (or Lit) for private line connections between each device and applications/partner/supplier/system and then you would be correct that it is the best way to go about it, however an island in this day and age is not efficient or necessarily able to be done as it was in the 90’s and prior.

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog

Subscribe

Or would you like to discuss a potential project with us? Contact us »