[cap-talk] Access control for IoT

[Alan Karp]

For reasons that I don't understand, I got a slot at an invitation only IEEE workshop on security and privacy for IoT.  (Maybe not enough people are willing to go to Washington, DC, in February.)  Invitees can submit papers, and 15 will be selected for presentation.  Mine is at http://alankarp.parseapp.com/Access-Control-for-IoT.pdf.

The submission deadline has passed, so it's too late for me to fix any errors.  However, if you find things that need changing, I can address them in the presentation should I get one of the slots.

--------------
Alan Karp

[Tony Arcieri]

I would just generally love to see more talk about the capability perspective towards solving the IoT problem. Most of the solutions I've heard so far either make extreme sacrifices for security to improve UX, or vice versa. There is a middle ground...

_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

--

Tony Arcieri

[Kenton Varda]

Indeed, capabilities have always seemed to me like an obvious fit for IoT.

Current practice seems to be that all IoT devices connect to the respective manufacturer's cloud servers. How are they supposed to interoperate? Will I have to make sure all of my devices come from the same company? Do people really want their entire house to be under the direct control of and sending all data to Nest/Apple/whomever?

In my dream world devices speak Cap'n-Proto-based protocols to a house-local Sandstorm server. :)

-Kenton

[Jack B. Dennis]

Quoting Alan Karp <alan...@gmail.com>:

> For reasons that I don't understand, I got a slot at an invitation only
> IEEE workshop on security and privacy for IoT. (Maybe not enough people
> are willing to go to Washington, DC, in February.) Invitees can submit
> papers, and 15 will be selected for presentation. Mine is at
> http://alankarp.parseapp.com/Access-Control-for-IoT.pdf.

Wow! Well done, Alan. I hope you get a speaking slot!

Jack Dennis

> The submission deadline has passed, so it's too late for me to fix any
> errors. However, if you find things that need changing, I can address them
> in the presentation should I get one of the slots.
>
> --------------
> Alan Karp

[Tim Coote]

Good to see some other points of view on IoT security. This is one of the specific issues that triggered my joining this list!

I’ve been struggling to get the point over about authorisation transfer to various groups and found that they generally agree intellectually, but still seem to think in terms of authentication creating authorisation. Naming is another related issue. I’d concluded that Things in IoT shouldn’t be identified just with individual hardware objects, even though the model has value from a usability point of view (esp. when things go wrong). In fact, most current IoT devices are much too clever to easily compose and get useful compound behaviours out of.  The issue seems to be a tension between makers of Things and service providers who are more interested in the Internet aspects. The different interests create different motivations over features vs control (inc. security).

I’d be intrigued on points of view on privacy issues to do with aggregated data. All providers that I’ve worked encountered are salivating at mining behavioural and other data. So the question is, will general users get so spooked that they will only use well controlled systems or will they covet the functionality more. I’m pitching the former, but can see an argument for the latter. If the former is true, then I’ve concluded that the provider of the IoT service needs an opt-in policy for retaining any data. (Datensparsamkeit, as I’ve seen the approach described).

tc

[Alan Karp]

I think one reason for lack of interoperability is the desire for lock-in by the vendors.  Another is lack of standards.

As far as privacy versus functionality, I believe 99+% of people will choose the latter without blinking an eye. 

--------------
Alan Karp

[Tony Arcieri]

On Sat, Jan 16, 2016 at 9:59 AM, Alan Karp <alan...@gmail.com> wrote:

I think one reason for lack of interoperability is the desire for lock-in by the vendors.  Another is lack of standards.

As far as privacy versus functionality, I believe 99+% of people will choose the latter without blinking an eye.

IoT is in a tough spot. Devices are constrained, so implementers often seek to cut corners on the systems they use in order to boost performance and/or reduce power usage.

At the same time, these devices require lots of functionality out of the cryptosystems they use for secure operation and access control.

These two constraints don't play well together, and the result is often quite broken.

I was just at RealWorldCrypto where a speaker from Microsoft was talking about a transport encryption protocol designed for non-IP-based transports used by IoT devices. He threw up a slide with a protocol description and someone in the audience broke it on the spot (identity misbinding attack).

SecureRF is pushing their "Algebraic Eraser" public key algorithm, which they claim has performance which scales linearly to the key size as opposed to quadratically like ECC or RSA:

https://twitter.com/kennyog/status/688409890914717700

But it was already broken once, and apparently a new paper is coming out next week breaking their "fix".

I have seen plenty of IoT frameworks from real cryptographers which look rather interesting, but these are all research projects which are half-baked and don't have a suitable implementation for use on real hardware.

All that said, as far as I can tell there really isn't anything to recommend so far that remotely resembles a real option in this space. The best I can recommend are half-baked research projects.

--

Tony Arcieri

[Tim Coote]

> On 16 Jan 2016, at 18:26, Tony Arcieri <bas...@gmail.com> wrote:
>
> IoT is in a tough spot. Devices are constrained, so implementers often seek to cut corners on the systems they use in order to boost performance and/or reduce power usage.
>
> At the same time, these devices require lots of functionality out of the cryptosystems they use for secure operation and access control.
>
> These two constraints don't play well together, and the result is often quite broken.

[snip]

> All that said, as far as I can tell there really isn't anything to recommend so far that remotely resembles a real option in this space. The best I can recommend are half-baked research projects.
>

There seems to be a bit of a mindset issue when it comes to IoT, with a desire to put all of the software on the edge sensors/actuators. This doesn’t strike me as a good design as these devices are really hard to write and deploy code to. Since many useful usecases combine sensors/actuators, the edge network can be very flakey, and often not really fit for purpose*, I concluded that a better, more flexible design was to manage the local network with a small, but reasonably capable computer ($20 BoM buys you a late 20th C computer with radio hardware). In this model ‘Things’ actually span several nodes, and you’ve only got to concentrate on getting relatively constrained code to work on the tiny devices. When they do misbehave (or someone simply plugs in one with different firmware to what’s been seen before), the compute node can see what’s going on on the network and take action if necessary.

The security model does not need to be very complex and the HomePlug AV mechanisms ought to suffice.

When implemented with the simplistic model, the cost of supporting variation gets to be much more than the incremental hardware costs and you cannot evolve very quickly either.

* typically, the short distance networking protocols include application level concepts make combining networks difficult. Some have quite poor application level models (e.g. ZWave locks cannot tell whether a door is locked, so you need an extra channel to provide that information).

tc
> --
> Tony Arcieri

[Valerio Bellizzomi]

On Sat, 2016-01-16 at 10:26 -0800, Tony Arcieri wrote:
> On Sat, Jan 16, 2016 at 9:59 AM, Alan Karp <alan...@gmail.com> wrote:
>
> > I think one reason for lack of interoperability is the desire for lock-in
> > by the vendors. Another is lack of standards.
> >
> > As far as privacy versus functionality, I believe 99+% of people will
> > choose the latter without blinking an eye.
> >
>
> IoT is in a tough spot. Devices are constrained, so implementers often seek
> to cut corners on the systems they use in order to boost performance and/or
> reduce power usage.
>
> At the same time, these devices require lots of functionality out of the
> cryptosystems they use for secure operation and access control.

most devices used for IoT come with 32K of memory, do not run true
operating system, they run small programs that provide only the required
control/information functionality. Those devices have ethernet or wifi
links. How do you implement access control given that the device will
connect to a local server?

> These two constraints don't play well together, and the result is often
> quite broken.
>
> I was just at RealWorldCrypto where a speaker from Microsoft was talking
> about a transport encryption protocol designed for non-IP-based transports
> used by IoT devices. He threw up a slide with a protocol description and
> someone in the audience broke it on the spot (identity misbinding attack).
>
> SecureRF is pushing their "Algebraic Eraser" public key algorithm, which
> they claim has performance which scales linearly to the key size as opposed
> to quadratically like ECC or RSA:
>
> https://twitter.com/kennyog/status/688409890914717700
>
> But it was already broken once, and apparently a new paper is coming out
> next week breaking their "fix".
>
> I have seen plenty of IoT frameworks from real cryptographers which look
> rather interesting, but these are all research projects which are
> half-baked and don't have a suitable implementation for use on real
> hardware.
>
> All that said, as far as I can tell there really isn't anything to
> recommend so far that remotely resembles a real option in this space. The
> best I can recommend are half-baked research projects.
>

[Tony Arcieri]

On Mon, Jan 18, 2016 at 10:42 AM, Valerio Bellizzomi <val...@selnet.org> wrote:

most devices used for IoT come with 32K of memory, do not run true
operating system, they run small programs that provide only the required
control/information functionality. Those devices have ethernet or wifi
links. How do you implement access control given that the device will
connect to a local server?

As I said in my last message:

 

> All that said, as far as I can tell there really isn't anything to
> recommend so far that remotely resembles a real option in this space. The
> best I can recommend are half-baked research projects.

As to how these research projects are trying to solve these constraints: 

- Minimize cryptographic primitives: instead of bundling both a hash function and symmetric cipher (possibly as hardware), use a hash function to implement an Even-Mansour stream cipher

- Minimalistic transport encryption: abandon TLS and ship a tiny, constrained transport encryption protocol

- Software update framework: support incremental download, data-at-rest authentication, and reflashing of device firmware with a fallback to the old firmware on error

Even without the IoT constraints these are challenging engineering goals in and of themselves. I'll point to transport encryption (specifically key exchange) as the thing that's most routinely screwed up with homebrewed protocols.

Just getting the above right forms the baseline of a secure system, and is already exceedingly difficult to the point few systems manage to do it in a remotely secure manner. User-friendly access control is gravy.

--

Tony Arcieri

[Valerio Bellizzomi]

there is some crypto in the form of a library, ok, or even as hw module.

I've seen software update is a process that needs the device powered off
and on some devices the reflashing is via usb cable.

It depends, if there is a full OS, it can do updates via remote link.

[Tony Arcieri]

On Mon, Jan 18, 2016 at 11:59 AM, Valerio Bellizzomi <val...@selnet.org> wrote:

I've seen software update is a process that needs the device powered off

and on some devices the reflashing is via usb cable.

I consider automatic software updates a baseline requirement for a secure system. If the device needs to be connected to some sort of tether cable and flashed by some 3rd party software utility the user needs to install, those upgrades aren't going to happen.

 

It depends, if there is a full OS, it can do updates via remote link.

An full OS is not a requirement for remote upgradability. However, the only systems I know for doing this in a manner I'd consider secure are proprietary.

--

Tony Arcieri

[Baldur Johannsson]

32 KibiBytes are actually plenty, if you are willing to forego the
usual bloat of compiled C (or such) code and use Forth.

A crypto vocabulary (read library) that does AES, SHA256, RSA or ECC
would be max
8 KibiBytes in compile Forth definitions, I think.

Access control can be done by macaroons (though the expressability of
the caveats will be limited somewhat)

The RSA/ECC would only be used for sign verification of relatively
infrequent firmware updates. (Relativly, that is, to sensor and
actuation messages)

[Ben Kloosterman]

On Tue, Jan 19, 2016 at 8:07 AM, Tony Arcieri <bas...@gmail.com> wrote:

On Mon, Jan 18, 2016 at 11:59 AM, Valerio Bellizzomi <val...@selnet.org> wrote:

I've seen software update is a process that needs the device powered off

and on some devices the reflashing is via usb cable.

I consider automatic software updates a baseline requirement for a secure system. If the device needs to be connected to some sort of tether cable and flashed by some 3rd party software utility the user needs to install, those upgrades aren't going to happen.

 

Not practical / wise for HW / small  ioc .  Yet to see a single mother board auto update - with good reason . HW normally works on no changes  and if there are any changes there is normally a very length cycle before its released. This includes Flash /EEproms  , not to mention that it some cases you can brick the device with some Eeproms if you do  it to often. 

Ben

 

[Tony Arcieri]

On Mon, Jan 18, 2016 at 5:11 PM, Ben Kloosterman <bklo...@gmail.com> wrote:

Not practical / wise for HW / small  ioc .  Yet to see a single mother board auto update - with good reason . HW normally works on no changes  and if there are any changes there is normally a very length cycle before its released. This includes Flash /EEproms  , not to mention that it some cases you can brick the device with some Eeproms if you do  it to often. 

Not true. It is quite common for embedded hardware these days to not only be field updatable, but be able to transparently and incrementally download updates and install them. I will again point to my employer as reference. We do it, so I'm afraid I have to ignore your claims to the contrary.

Likewise, I would argue it's irresponsible to put devices which don't automatically update onto the Internet (that is the subject of this discussion, right? The *Internet* of Things).

There are certainly many applications of hardware for which updates are a bad idea, or devices which are too small or constrained to support automatic updates. But you have to Venn Diagram that with the types of devices it's reasonably responsible to connect to the Internet and assign an IP address to.

I would argue it's irresponsible to put any device on the Internet which is not capable of receiving software updates.

--

Tony Arcieri

[Ben Kloosterman]

First time you try to flash and brick it because there was a power outage or EPROMs fail due to too many write cycles people will not be very happy ...So what people do is NOT change the HW but do flash the OS / app (eg all phones)  however the smaller devices do not have this "double"  system. 

"I would argue it's irresponsible to put any device on the Internet which is not capable of receiving software updates." , there is some validity in this  .. but it may be construed as   "I would argue it's irresponsible to put any device on the Internet which is not capable of receiving software updates and hence IOT devices should not be very small / fixed embedded systems." . Though contentious It maybe valid and for non security reasons as well eg ipv4 phasing out vs ip6 in the future  .   ..  The other side of the coin is such small devices may have a very small surface area to attack , personally im undecided ( though leaning to large devices)  though practically a lot of the HW being used is the same HW for the last 10- 20 years just now connected to a internet  server. 

Ben

On Tue, Jan 19, 2016 at 12:30 PM, Tony Arcieri <bas...@gmail.com> wrote:

There are certainly many applications of hardware for which updates are a bad idea, or devices which are too small or constrained to support automatic updates. But you have to Venn Diagram that with the types of devices it's reasonably responsible to connect to the Internet and assign an IP address to.

I would argue it's irresponsible to put any device on the Internet which is not capable of receiving software updates.

--

Tony Arcieri

[Valerio Bellizzomi]

well, it is secure as it is, because no one can reflash your device
remotely, you have to do it by hand.

[William ML Leslie]

On 19/01/2016 5:07 pm, "Valerio Bellizzomi" <val...@selnet.org> wrote:
>
> well, it is secure as it is, because no one can reflash your device
> remotely, you have to do it by hand.

There are three vectors that need to be considered here, and for different products they each carry different risks. For example, security cameras that are outside your house should not be reflashable with physical access.

The other two vectors are the automatic update delivery mechanism, which is the most scary IMO, and the API the device exposes.

[Matt Rice]

FWIW security of remote updates is not exactly a new problem, space craft has long had the same issue, I'm not sure if the computer history museum where the last friam was held still has any association with moffet field,

But I recall from a conversation with someone from there that they essentially used a jump table I'm not sure how close of an analogy can be made to the keykos primordial system image though.

Anyhow it is a well researched field for mission critical applications...

the primary difference is that the remoteness of space makes physical attacks difficult..

[Valerio Bellizzomi]

IP cameras *are* reflashable via a web app, they run a minimal linux.
The update is in two steps, download a file to the cam and then flash
it.

[Bill Frantz]

I have been playing with Arduinos for a while now, and their
update process might be a model.

An Arduino is standard microcontroller chip with a boot loader
in its program memory which works over a serial data connection.
The ones with USB interfaces convert the USB data to serial data
internally. The boot loader means you don't have to have a micro
controller programmer to load new code into the machine.

While it is possible to brick the Arduino -- it has no memory
protection -- doing so is quite rare. I have never done it and I
don't know anyone else who has either. I also have never heard
of or experienced wearing out the flash memory, and it gets
written much more frequently during the software development
cycle than it would be updating deployed devices.


If I were to change this architecture to make a secure update
scheme, I would make the following changes:

(1) Have enough program memory to be able to store two versions
of the application software. The current program memory is 32K,
so this won't be a serious budget breaker. We'll call them the
current software and the new software candidate.

(2) Have the boot loader verify the signature of the new
software candidate against a public key installed with the boot
loader. EC may be a win for the signature algorithm. After
successfully verifying the signature, the new software candidate
is copied over the current software completing the update.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz |The nice thing about standards| Periwinkle
(408)356-8506 |is there are so many to choose| 16345
Englewood Ave
www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,
CA 95032

[Valerio Bellizzomi]

On Mon, 2016-01-18 at 17:30 -0800, Tony Arcieri wrote:
> On Mon, Jan 18, 2016 at 5:11 PM, Ben Kloosterman <bklo...@gmail.com> wrote:
>
> > Not practical / wise for HW / small ioc . Yet to see a single mother
> > board auto update - with good reason . HW normally works on no changes and
> > if there are any changes there is normally a very length cycle before its
> > released. This includes Flash /EEproms , not to mention that it some cases
> > you can brick the device with some Eeproms if you do it to often.
> >
>
> Not true. It is quite common for embedded hardware these days to not only
> be field updatable, but be able to transparently and incrementally download
> updates and install them. I will again point to my employer as reference.
> We do it, so I'm afraid I have to ignore your claims to the contrary.
>
> Likewise, I would argue it's irresponsible to put devices which don't
> automatically update onto the Internet (that is the subject of this
> discussion, right? The *Internet* of Things).
>
> There are certainly many applications of hardware for which updates are a
> bad idea, or devices which are too small or constrained to support
> automatic updates. But you have to Venn Diagram that with the types of
> devices it's reasonably responsible to connect to the Internet and assign
> an IP address to.

in practice you have the option to include an ethernet library and:

1) get the IP address via dhcp

2) hardcode the IP address into the program

> I would argue it's irresponsible to put any device on the Internet which is
> not capable of receiving software updates.

it seems after all that an automatic update mechanism is also a possible
attack vector.

[Matt Rice]

I should probably elaborate on this,

What I recall is that the signal sent authenticate, place parameters in a known location and specify an offset into a jump table then jump to the appropriate location...

part of the rationale for this was it was easy to overwrite an entry into the jump table when a signal was no longer going to be sent e.g. because a newer version of that rpc call had been placed in a different offset in the jump table...

presumably the authentication mechanism didn't include per-offset/per authority W/X bits since I don't see space programs needing it...

nor do I know if they had anything similar to the keykos checkpointing mechanism for working sets...

but it seems reasonable to me with an appropriate authentication mechanism the offset into jump table is not terribly dissimilar to a cap id for a fixed number of caps system.

I'm guessing its quite possible that there was a distinction between functions that were called by rpc and those that were relied upon by the devices main loop