Different PAN Parts: Auth-Only, Confidential and No Consequence

Published 2014-08-06 originally at SAIFE's Blog as The Secure Internet of Things, Part 2: Different PAN Parts – Auth-Only, Confidential, and No Consequence and cross-posted here.

Where the Internet of Things meets locations in the physical world, I envision scores of devices networking together to make life more efficient, whether that Personal Area Network (PAN) is an office, a warehouse, or a home. These devices all need to communicate one way or another, but whether they do so with 6LoPAN, WiFi, LTE, or some other technology, I categorize these devices’ security needs into three groups: Devices which only need to be authentic; devices whose input and output are confidential; and those devices which are really of no consequence even if they are accessible to the neighbors.

This is the second topic in a series; the first topic was Prevalence of Well Known Peers in the Internet of Things.

PAN Device Security Categories

This table gives some examples of each of the three categories I’m discussing:

I will describe the security implications of each in turn.

Authentication-Only

Many devices in our daily lives should, optimally, authenticate who is using them. Just as your front door lock authenticates the inserted key as being the correct shape, a digital door lock should authenticate anyone trying to unlock it, be they your child, your in-laws, or the sketchy vacuum salesman.

These devices aren’t sending or receiving secrets; if a neighbor sets up his software defined radio and antenna to monitor your network, it doesn’t matter if he can see your thermostat being changed, or your doors opening and closing. What matters is he can’t change your thermostat, or unlock your doors – at least, not unless you want him to.

These devices aren’t confidential; they don’t need encryption techniques for their data. They really need easy-to-use public authentication, like what we’re building with SAIFE. They tend to be built with high-end microcontrollers or inexpensive application processors; they can be powerful enough to perform the necessary public key cryptography for public authentication.

The Contiki open source OS, along with flavors of real-time Linux, ThreadX, and MQX seem likely candidates to serve as the software base for this category of devices.

Confidential

There are relatively few devices which send and receive truly confidential data. Security cameras are the most obvious to me; I don’t have a cloud-enabled security camera because the camera’s not confidential from the service provider. Intercoms, occupancy sensors (are your kids outside?) and your personal computers are other examples of confidential devices.

Devices that need confidentiality need communications security; their data should be enciphered so that the shady van with the big antenna can’t see or hear inside your house… at least not with your own equipment.

These devices tend to be built around powerful processors, and it’s within reason to ask for them to perform data encryption while performing their primary function, like recording audio and video, or displaying videos of cats configuring PKIs.

Since these devices are powerful, some of them will run full operating systems like Android, iOS, Windows and Linux. Of course, many will still choose to run on ligher-weight OSes as well.

No Consequence

Devices of no security consequence are primarily sensors which, if spied upon or cloned, would be nothing more than an inconvenience, and rather unlikely at that. Generally built upon the smallest of micro-controllers (or Arduinos), these devices just aren’t a big deal. We want them to be cheap and perhaps even replaceable.

As an example, in my house I have probes relaying the volumetric water content of my garden to my PAN (there’s source code too). At most I care that they aren’t used for computer crime, but in practice they would be a poor attack platform anyway.

Being as low-end as possible, many of these devices will be based on what I heard once termed as while(1){} OSes, or homegrown process loops rather than what we would typically term an operating system.

Many of the billions of devices in Cisco’s Internet of Things vision meet this definition. That said, when you get twenty thousand sensors in one network, you still have to manage them all.

Managing The PAN

Many of the actions we think about as device management fall under the Authenticate category of security as well: updates, many kinds of configuration, status reporting… the list goes on. Other than the occasional secret, most devices should be most careful that any management commands they are given are from an authentic source.

Luckily, the well known peers concept lets us scale down the concept of a Public Key Infrastructure to handle all of these categories of nodes. How, exactly, I will cover in the next topic, Service Assisted Communication and Simplifying a PKI.

Topics in the Series

This topic is part of a series to describe a hybrid approach to providing security to the Internet of Things:

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