Subject: Re: [core] RawPublicKeys

From: Rene Struik <[email-masked]>
Date: Tue, 14 Feb 2012 09:38:00 -0500

Hi Johannes:

There are some deployment scenarios on some (very) old slides of mine,
from IETF-77, March 2010, that may be of interest:
http://www.ietf.org/proceedings/77/slides/core-1.pdf
Those example deployment scenarios have been harvested from users in the
process control, HVAC, etc. communities.

Some comments below.

Best regards, Rene

On 14/02/2012 6:49 AM, Johannes Gilger wrote:
> Hi everyone,
>
> I'm fairly new to this list, so bear with me if I miss the more subtle
> points of IoT security provisioning or topics you might have discussed
> outside the mailinglist.
>
> On 17/11/11 17:22, Alper Yegin wrote:
>> The above text explains how the network node authenticates/authorizes
>> the device.  But, how does the device authenticate/authorize the
>> network node? For that, the "identity" of the network node's public
>> key needs to be known to the device. But how?
> In my understanding of the functionality of an interface-constrained IoT
> device, there is no need for the node to identify the network. In fact,
> there is no meaning behind any identity as far as the node is concerned.
>
> The only thing that matters is that the network can identify the node
> (as has been discussed) and that the network can ensure that it is the
> only one able to command the node. This goes beyond what has been
> discussed here, and I may be outside the topic, but it all boils down to
> the Resurrecting Duckling model [1].
RS>>
This is correct in the more limited model of the resurrecting duckling
policy framework by Ross Anderson et al. However, this disregards that a
device may be in a sequence of networks, where it remembers state
transitioning from one to the next. As an example, one may have the
following:
a) device is "bare", without knowledge of the world;
b) device gets imprinted by whatever first device communicates with it
(resurrecting duckling). This results in the Id of the
"imprinting"/configuring device to be stored with the device and, from
now on, that device being the only one allowed to change its state;
c) device gets some other parms from configuring device, including Id of
network device (the one it is supposed to synch-up with). This would
result in it having an arbitration mechanism to identify the network itself.
d) configuration device may now imprint other parms, hand-over control
to other configuration device (new mother duck, so to speak), etc.
e) device joins network and has sufficient parms to not only
authenticate another device, but also filter according to policies
(since it has been set up with policies as part of configuration).
[...]
<<RS
>
> On 20/12/11 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> One possible design that some of you had mentioned to me is to print
>> the fingerprint of the public key on the device(sensor) and to then,
>> when you introduce the device into your network, to verify the
>> fingerprint on the device with the value shown on the server for
>> inclusion in the access control list. This works nicely in a smaller
>> environment, such as a home network. 
> [...] 
>> Having public-key derived identities printed on a device presumes that
>> a device's public key will never change over its lifecycle. Moreover,
>> it assumes that the public key is available prior to printing the bar
>> code. 
> [...] 
>> These devices are assumed to have no trusted platform on board. What
>> if someone else clones a device, produces a million copies, and
>> pollutes the market place this way (one of the scenarios described in
>> draft-garcia-core-security-03 (Section 3.1)). It seems that one is
>> just out of luck then.
> That is one large problem, if we assume to have no trusted platform on
> board. A lot of the things I came up with when looking at IoT security
> bootstrapping rely on having a secure chip, at least when
> interface-constrained (no display) publicly accessible devices are
> concerned.
>
> If we have *no* trusted platform, we can not really generate the key in
> advance and print/etch it on the box, as anyone could clone our keypair.
> Keep in mind that the printing / reading is an out-of-band channel. 
RS>>
Longer term, one cannot assume every device to have a trusted platform
on board. The best one can hope for is tamper evidencing mechanisms,
either on the device itself (e.g., PUF technology) or by exploiting
network-based polling techniques (I could elaborate on the latter more
separately).
<<RS
> So now we have to generate our own keypair, which has to happen on the
> node itself, since we do not have any interfaces. After the key has been
> generated, the node has to transfer the public key to us, using the
> wireless link. If we consider devices completely void of any other
> interface, there simply is no secure channel to communicate the device's
> public key to us.
>
> I think that if we want to be on the safe side, there are two options:
>
>  - A trusted platform with an ECC-keypair which is used as a CGA and
>    printed on the case of the device or etched on the chip.
>  - Some kind of tamper-evident out-of-band channel, even if its just an
>    LED. It just needs integrity, not confidentiality.
>
> Of course, with the first option, the manufacturer has to get the
> freshly generated ECC pubkey from the device as well, just like the
> user. This is where I trust that it's easier for a large company to
> build an actual Faraday cage to ensure no interference than it is for
> people employing the technology.
RS>>
If public-key based, this is RA (Registration Authority) functionality
and does not require a Faraday cage, just authenticity.
<<RS
> I could go on and talk about how one might need the printed CGA to be
> tamper-evident as well, but its obvious that there are many attack
> scenarios and possible mitigations.
>
> On 21/12/11 11:29, Alper Yegin wrote:
>> The issue I'm raising is that, there story has two sides. We gotta be
>> talking about not only how the network authorizes the device, but also
>> how the device authorizes the network. What you describe above is the
>> former, latter one is missing.
>>
>> It's not like the device will/shall be OK to talk to anyone who wants
>> to talk to itself. Device needs to authenticate and authorize the
>> other end as well, using ACLs etc. 
> Why not? Looking at the Resurrecting Duckling again, the device will
> talk to anyone when its in the "imprintable" state. After it has been
> imprinted by an authority (hopefully the right one, or you'll have to
> reset the device and try again), it will identify the network as the
> party which holds the newly agreed symmetric key.
RS>>
Once again, fine if one only has "one configuration stage", but discards
multiple (re)configuration processes along the device's lifetime.
<<RS
>> How do we introduce the ACL into such devices? There's gotta be an
>> interface for that.
> The ACL is this:
>  - The symmetric key agreed with the first party to start imprinting has
>    all the authority.
>  - The authority can add and modify the ACL (using in-band messages).
RS>>
Or some other authority designated via policy configuration could do this...
<<RS
>> Note that this is an issue for asymmetric-crypto. With the symmetric
>> crypto, device can assume whoever holds the same PSK is already
>> authorized hence I don't also need to maintain an ACL. Symmetric
>> crypto has other issues though (e.g., how did you get the PSK here and
>> there?)
> See above. After asymmetric crypto was used to establish a symmetric key
> (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the
> asymmetric key will only be needed again if the device is reset.
RS>>
Main missing part in lots of discussion is not the crypto part, but the
policy part (authorization vs. authentication, etc.). Just sprinkling in
ephemeral Diffie-Hellman with ECDSA (expensive btw - there are far more
efficient solutions) is not sufficient, since it only addresses
authentication, not authorization issues.
<<RS
> On 22/12/11 10:02, Alper Yegin wrote:
>> Alper> I thought we were trying to solve the problem of "dealing with interface-less devices". 
>> Alper> Maybe we shall re-state the problem statement, if that's not it.
RS>>
One interface that is not used sufficiently yet is the in-band one, by
just using the communication channel itself to communicate policy
management messages. Of course, this does require language constructs,
frame structures, state machines, and the-like. Using this in-band
channel and a time-based trigger by itself together go a long way.
<<RS
> I think this is what we should be talking about, in this or another
> thread.
>
> These are my thoughts,
> would like to hear what you guys think,
> Jojo
>
>
> [1] - http://www.cl.cam.ac.uk/~fms27/duckling/
>
>

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363