Subject: [core] Draft on secure enrollment

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 15 Oct 2012 16:15:52 +0000

I'd like to propose one possible way to get the initial keys needed for CORE on the devices. I wrote up a draft at

  http://www.ietf.org/internet-drafts/draft-jennings-core-transitive-trust-enrollment-01.pdf

(do read the PDF version not the txt version as the txt version is missing the figures)

One things i like about this is you can probably build sensors that are running in the closer to 32k of flash wight this approach. Part of what got it so small was an extremely small set of crypto algorithms required. This is obviously an early sketch of and many details would need to be worked out but I think there is enough in the draft to be able to understand the idea and discuss it.

---

From: Johannes Gilger <[email-masked]>
Date: Tue, 16 Oct 2012 10:23:46 +0200

Hello Cullen,

I read the draft (and remembered your presentation at the Smart Object
Security Workshop) and have some small questions about the scheme in
general. The core of my questions is: Why do you need the Transfer Agent
(and the Manufacturer) to be involved in the enrollment?

For example, I could modify the scheme like this:

- Leave out the TA and the OTP
- Transfer DevSecret from Device to Introducer (QR-Code)
- Transfer DevSecret from Introducer to Controller (Backend)
- Use DevSecret to enroll Device (In-Band)

The way I see it this would have the following drawbacks:

1. Someone else could read the secret and try to enroll the device
   before I can.
2. Someone could reset the device and enroll it again with himself
   because there is no online entity (TA) which keeps track of the
   enrollment runs.
2. The device will need some sort of discovery mechanism to find a/the
   controller on its current network when it is activated (this might be
   the hard part, please educate me).

Is there anything else I am missing? Is there another motivation for
having the online TA? Why do we need an OTP *and* a DevSecret? Could we
just use the DevSecret in place of the OTP? Or would it be unacceptable
for the TA to know the DevSecret which we'll use in the first few
packets to change the permanent DevSecret?

I guess I haven't quite wrapped my head around it yet. But the draft
itself reads very nicely, and I guess it fits the requirements for a lot
of deployment scenarios. Stealing of OTPs could be prevented by hiding
the QR-Code beneath a scratch-off field, if that is something that is
acceptable for quick deployments without opening the box.

Regards,
Jojo

-- 
Dipl.-Inform. Johannes Gilger
Research Group IT-Security
RWTH Aachen University
Mies-van-der-Rohe-Straße 15
52074 Aachen

Office: 211
Phone: +49 241 80 20781

http://itsec.rwth-aachen.de

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Wed, 17 Oct 2012 15:42:47 +0000

Hello Cullen and Johannes,

In some use cases, the manufacturers would like to ensure that only the authorized devices can be installed in a system. Correct me if I am wrong, this could prevent device cloning such that OTP that has already been used cannot be activated/associated with the controller. In this context, there are benefits for having the Transfer Agent, and I see the role of 'introducer' as a commissioning tool that is used to identify the device to be installed. Maybe it's good to separate the use case of a completely stand-alone deployment where no online connectivity is available, then the scheme suggested  by Johannes is probably sufficient. In case that online connectivity is available, devices can be validated with the TA in the backend.

I also have the same question as Johannes, why do we need so many secrets, i.e., OTP, DevSecret, TaSecret?
Presumably, if the TA also knows the DevSecret or the OTP, then a secure channel can be established between them without requiring the TaSecret. Just a question, is the TaSecret unique per device or it's a common secret for all devices?

I quite like the idea that the OTP or DevSecret is hidden as a scratch-off field.

Lastly, how about device replacement and re-installation of the device? Requiring the user to bring the device back to the manufacturer is not so convenient in my opinion.

Kind regards,
Sye Loong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Johannes Gilger
Sent: dinsdag 16 oktober 2012 10:24
To: core WG
Cc: Cullen Jennings (fluffy)
Subject: Re: [core] Draft on secure enrollment

Hello Cullen,

I read the draft (and remembered your presentation at the Smart Object Security Workshop) and have some small questions about the scheme in general. The core of my questions is: Why do you need the Transfer Agent (and the Manufacturer) to be involved in the enrollment?

Is there anything else I am missing? Is there another motivation for having the online TA? Why do we need an OTP *and* a DevSecret? Could we just use the DevSecret in place of the OTP? Or would it be unacceptable for the TA to know the DevSecret which we'll use in the first few packets to change the permanent DevSecret?

I guess I haven't quite wrapped my head around it yet. But the draft itself reads very nicely, and I guess it fits the requirements for a lot of deployment scenarios. Stealing of OTPs could be prevented by hiding the QR-Code beneath a scratch-off field, if that is something that is acceptable for quick deployments without opening the box.

Regards,
Jojo

Office: 211
Phone: +49 241 80 20781

http://itsec.rwth-aachen.de
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Johannes Gilger <[email-masked]>
Date: Thu, 18 Oct 2012 16:09:40 +0200

Hey Sye Loong,

let me see if I understood your argument:

> In some use cases, the manufacturers would like to ensure that only
> the authorized devices can be installed in a system. 
What kind of knowledge does the manufacturer have about the system? I am
building a Smart Object network with components from various vendors,
and one interface-constrained device just happens to be built by
manufacturer x.

> Correct me if I am wrong, this could prevent device cloning such that
> OTP that has already been used cannot be activated/associated with the
> controller.
Cloning? As in copying the keys on the device and putting them in cheap
knock-off hardware? Sure, this would help. But then again I could also
manufacture cheap knock-offs and have them not require any online
procedure during enrollment. Maybe I didn't get your point on this one.

> In this context, there are benefits for having the Transfer Agent, and
> I see the role of 'introducer' as a commissioning tool that is used to
> identify the device to be installed. 
I'm not arguing about the Introducer here, just about the transfer agent
(and online connectivity).

> Maybe it's good to separate the use case of a completely stand-alone
> deployment where no online connectivity is available, then the scheme
> suggested  by Johannes is probably sufficient. In case that online
> connectivity is available, devices can be validated with the TA in the
> backend.
I agree that one benefit of an online TA would be that you can not
simply clone a device along with its proof of authenticity. If that is
one of the more important features of Cullen's proposal, it should be
stated more clearly.

> I also have the same question as Johannes, why do we need so many
> secrets, i.e., OTP, DevSecret, TaSecret?  Presumably, if the TA also
> knows the DevSecret or the OTP, then a secure channel can be
> established between them without requiring the TaSecret. 
No, if we are really using the TA, then we probably need all of these
secrets. The TA must not know the DevSecret or it could eavesdrop on us
changing our key. On the other hand, an attacker that is able to read
the QR code (before or after deployment) could read our DevSecret and in
turn also intercept / modify our messages which refresh the DevSecret.
So the QR code should be separated from the device during installation,
or we have to perform the DevSecret refresh before anyone else can read
the QR code.

Looking at it that way, it could also work to have an OTP on the device
and a symmetric password DevSecret on the controller. The Introducer
could fetch the DevSecret from its controller, send it to the TA along
with the OTP. The TA would forward it to the device (encapsulated with
TaSecret) along with the ID of our controller. In this case, the only
one able to attack us would be the TA, and then only if it can modify
messages while we are changing our DevSecret.

(I assume an integrity-protected Diffie Hellman to generate the
new DevSecret, protected by the current DevSecret).

The proposal under "Open Issue" at the end of the draft would protect
against both: A DevSecret and a ContSecret, where the ContSecret is only
sent to the TA (and then to the device) and the DevSecret is only read
from the QR by the introducer. A locally present attack can not get the
ContSecret and the TA can not read the DevSecret.

> Just a question, is the TaSecret unique per device or it's a common
> secret for all devices?
If it were common for all device, every enrollment message from the TA
could be intercepted as soon as someone gets the TaSecret from the
device.

> Lastly, how about device replacement and re-installation of the
> device? Requiring the user to bring the device back to the
> manufacturer is not so convenient in my opinion.
You can reset the device into factory-settings yourself. The problem is
that you know the QR code by that point, so you could eavesdrop on any
new enrollment, unless we really introduce an additional ContSecret that
is chosen by the new owner of the device.

Hope my thoughts did not come across too convoluted.

Regards,
Jojo

Office: 211
Phone: +49 241 80 20781