Service Assisted Communication and Simplifying a PKI

Published 2014-09-09 originally at SAIFE's Blog as The Secure Internet of Things, Part 3: Service Assisted Communication and Simplifying a PKI and cross-posted here.

Because many of the devices in the IoT are headless and have limited ability to interact with their owners, there needs to be a way to authenticate them without passwords, and without the shortcomings of the existing 0000 and 1234 problems in the Bluetooth world. I’ve written about the concept of Public Authentication, and specifically Public Key Infrastructures (PKIs); in the context of the Internet of Things, though, public authentication takes on new challenges:

• How do we distribute certificates to these mass-produced devices?
• And, how can they discover other devices on the network to perform data synthesis?

My solution is for the constrained devices to seek help from the cloud whenever the help is safe, and without exposing their data. I’ve described this concept in a variety of ways in the five years we’ve been working on SAIFE’s PKI; six months ago the eminent Clemens Vasters at Microsoft wrote an article describing the same idea and called it Service Assisted Communication. That, I think, hits the nail on the head.

Before going into detail about Service Assisted Communication, let me tell you about the state of things today, in brief.

This is the third topic in a series; the previous topic was Different PAN Parts: Auth-Only, Confidential and No Consequence

The Past: Everything’s A Server

Internet-enabled devices of yesteryear typically connect to my home LAN, acquire an IP address, and host a crummy web application to interact with or configure the device. My sprinkler system, solar power inverters, and security cameras do exactly that. In order to fiddle with these things I need to be connected to my LAN. If I’m traveling, I use a VPN. VPNs, though, are a lot of hassle to configure and use. For most people that’s just one step too many.

Amusingly, the availability of connectivity on my phone sometimes leads to frustration. I can try to change the timing on my sprinkler system and fail to connect while sitting on my couch; disabled Wi-Fi strikes again.

Some have taken to exposing these devices directly to the Internet; you can find random people’s Axis webcams via Google if you look hard enough.

Today: Move the Server to the Cloud

The latest version of my home sprinkler controller now has “cloud support”, where the sprinkler makes an outbound connection from my LAN to a server and waits for commands. The app on my phone can do the same, and the server relays the messages back and forth.

-Irrigation Caddy

This kind of model, reaching out to a server run by the manufacturer, is becoming more common. The Nest thermostat does the same thing, that way you can interact with your home wherever you are.

Both the thermostat and the sprinkler controller control resources that cost me money: water and power. They are not devices of no consequence as I have previously defined, but neither are they confidential. I just want to be sure that whoever turns on my water, or sets my air conditioning target temperature is authentic.

Avoiding Home Firewalls

Nest, Irrigation Caddy, and many others use the standard approach of providing security over the Internet using TLS and then using their policies to protect your data when it reaches their computer systems. Once it’s at the Cloud Service Provider, the data is decrypted and stored; the provider has your data.

In exchange for the recurring fee you’re paying, you expect them to construct their IT infrastructure to protect your data. For Nest that’s not a big deal to me; I trust them to protect my thermostat’s settings. I get a little more worried about cameras and locks.

Take for example the Lockitron, an (admittedly super cool) Internet-connected deadbolt actuator. The device has a protected link to Electric Imp’s cloud service, and the App also has a protected link to Electric Imp. This model requires me to trust the service provider in the middle (and the company that built the thing, of course). While every interaction I’ve had with Hugo Fiennes, the CEO of Electric Imp, has been very positive, I still pause at the idea that someone spoofing my Wi-Fi to MITM the Imp could unlock my door.

I would prefer that the service provider in the middle just assist with setting up communication between my phone and my door lock. The communication, the exchange of understandable data, should be limited to the devices I control. In my nirvana, I want end-to-end protection, and the service provider in the middle should see nothing but ciphertext.

Tomorrow: Service Assisted Communication

When Clemens coined the term Service Assisted Communication, he established 7 principles to guide implementation:

1. Security trumps all other capabilities. If you can’t implement a capability securely, you must not implement it. You identify threats and mitigate them or you don’t ship product. If you employ a mitigation without knowing what the threat is you don’t ship product, either.
2. Devices do not accept unsolicited network information. All connections and routes are established in an outbound-only fashion.
3. Devices generally only connect to or establish routes to well-known services that they are peered with. In case they need to feed information to or receive commands from a multitude of services, devices are peered with a gateway that takes care of routing information downstream, and ensuring that commands are only accepted from authorized parties before routing them to the device.
4. The communication path between device and service or device and gateway is secured at the application protocol layer, mutually authenticating the device to the service or gateway and vice versa. Device applications do not trust the link-layer network.
5. System-level authorization and authentication must be based on per-device identities, and access credentials and permissions must be near-instantly revocable in case of device abuse.
   • [This is going to be covered in topic 5, “How Oracles Trivialize PKI Revocations, And Why That’s Great” - J.C.]
6. Bi-directional communication for devices that are connected sporadically due to power or connectivity concerns may be facilitated through holding commands and notifications to the devices until they connect to pick those up.
7. Application payload data may be separately secured for protected transit through gateways to a particular service.

If you implement Clemens’ ideas, you have SAIFE’s bidirectionally-authenticated communication network: store-and-forward encrypted messages and all. The problem Clemens doesn’t discuss is how to configure the security; how to sign or issue PKI certificates, or manage the huge numbers considered in the Internet of Things.

When I started building SAIFE, my fundamental concern was to simplify Public Key Infrastructures. The way we’ve done it is to leverage the power of Service Assisted Communication not only for the user’s data, but also for the PKI Management.

Simplifying a PKI through SAC

Question: What if any machine that could do ECDSA could send data to any other compatible machine?

Answer: You can have a basis of trust for everything you do, and you can ignore Internet Protocol addresses in favor of public certificates.

A cornerstone of SAIFE’s PKI model is that any machine can send data to any other machine by using the destination’s public certificate as the address. All messages are signed by the sender, addressed to the public certificate(s) of the receiver(s), and are encrypted directly to the recipients’ keys. Messages are also (typically) given return receipts to indicate they were successfully decrypted.

The messages go through one of many cloud servers we call Continuums, as they provide continuous communication for any compatible machine. Continuums have no keys themselves; they verify the authenticitiy of digital signatures on transiting messages, but cannot decrypt them. The worldwide network of these Continuums provides clients trusted routing over untrusted networks.

In some ways, our collection of Continuum servers is like PubNub or Amazon’s Simple Queueing Service, but with cryptographic verification of all messages in the Cloud. That means the machines at the end can’t get spammed by anonymous users, or DDOSed.

For this model to work, you have to know the public certificates of any machines you want to communicate with, and they need to know yours. As I discussed in the post “Prevalence of Well Known Peers in the Internet of Things”, most of the time IoT devices need to communicate with a small set of peers.

Certificate Distribution: Well Known Peers

Let’s imagine there’s an oracle that, for a given machine, knows the other machines with which it should communicate. The oracle’s job then, is to make sure every machine in the group has the certificates of the other machines.

Several years ago we built an application we called SMC whose job is to track these groups and, when a change occurs, to send encrypted notifications of the change to all the affected machines. These peer-change messages are sent through SAIFE’s network and, being signed by the SMC, are obeyed by the recipients. The SMC-oracle is the key technology that let’s us fulfill Clemens’ requirement that “Devices generally only connect to or establish routes to well-known services that they are peered with.” It sets up those peer relationships.

Note: We’re replacing the SMC with an Internet-of-Things appropriate Dashboard, and a public API to build your own features atop it. The API will be released this year.

Secure Configuration

Configuring a given machine’s list of allowed peer certificates is really a sub-set of the more general configuration. When you can send authentic, confidential commands from a trusted source - whether its our SMC of today, or our Dashboard of tomorrow, or some other technology - you effectively have secure configuration for any machine, wherever it is.

Advantages to the Internet of Things

Service Assisted Communication is a more efficient approach for the higher-degree of interconnection we’re expecting out of the Internet of Things. Notably:

1. Machines can be pre-configured (securely) with their allowed peers.
   • That lets us obey revocation lists without having to download CRLs, wait on OCSP or calculate stapling.
   • We can also avoid the certificate-chain phases of TLS and skip straight to the key agreement.
2. When the service operates in a message-oriented fashion, you can transmit data to multiple recipients without having to maintain multiple data streams.
   • Especially important for machines that can’t handle more than one TLS session.
3. In SAIFE’s implementation, we still support streaming data via the Service, unlike PubNub or Amazon SQS.
   • It still has all the confidentiality and integrity guarantees, but can handle realtime data like video or voice.
4. DDoS Avoidance: Attackers can’t target the machines at the endpoints, as they don’t have inbound ports.
   • The attacks have to hit the Service in the middle, which - in SAIFE’s case - is designed to scale horizontally, fast. Machines using the service just route around the Continuums under attack.
5. NAT, IPv6, and Firewall friendly: As Clemens said, only use outbound ports for those machines at the edge.

I’ll go into more details about Service Assisted Communication and 6LoWPAN in the next topic, and how the ciphertext-only service in the middle concept can scale down depending on the PAN parts.

Topics in the Series

1. Prevalence of Well Known Peers in the Internet of Things
2. Different PAN Parts: Auth-Only, Confidential and No Consequence
3. Service Assisted Communication and Simplifying a PKI
4. Service Assisted Communication’s Applicability to 6LoWPAN
5. How Oracles Trivialize PKI Revocations, And Why That’s Great
6. Certificate-Based Routing In The Fog