Subject: [Dtls-iot] Unique Key Pair per Device

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Jul 2015 19:19:07 +0200

Stephen wrote:

(2) 6.2: Saying that the client key pair "may, for
example, be configured during the manufacturing process
of the device" is not ok really. There have been too
many cases where the same key pair has been used in
whole production runs or worse. You need to add a 2119
instruction here that doing the quoted thing "REQUIRES a
different key pair for each device that SHOULD be
generated and installed in as-secure a manner as
possible." Or similar text. I don't care where that text
is added (6.2 might not be right) so long as it's not
hidden away on page 54:-)

I agree that it would be useful to make this point more clear that there
is a need to have device-specific secrets provisioned. This has been a
source of IoT security vulnerabilities.

I re-read Section 6 and extracted the relevant text from various places
and created a new section that discusses the larger issue. Here is the
proposed text:

6.  Credential Types

   The mandatory-to-implement functionality will depend on the
   credential type used with IoT devices.  The sub-sections below
   describe the implications of three different credential types, namely
   pre-shared secrets, raw public keys, and certificates.

6.1.  Pre-Conditions

   All exchanges described in the subsequent sections assume that some
   information has been distributed before the TLS/DTLS interaction can
   start.  The credentials are used to authenticate the client to the
   server and vice versa.  What information items have to be distributed
   depends on the chosen credential types.  In all cases the IoT device
   needs to know what algorithms to prefer, particularly if there are
   multiple algorithms choices available as part of the implemented
   ciphersuites, as well as information about the other communication
   endpoint (for example in form of a URI) a particular credential has
   to be used with.

   Pre-Shared Secrets:  In this case a shared secret together with an
      identifier needs to be made available to the device as well as to
      the other communication party.

   Raw Public Keys:  A public key together with a private key are stored
      on the device and typically associated with some identifier.  To
      authenticate the other communication party the appropriate
      credential has to be know.  If the other end uses raw public keys
      as well then their public key needs to be provisioned (out-of-
      band) to the device.

   Certificates  The use of certificates requires the device to store
      the public key (as part of the certificate) as well as the private
      key.  The certificate will contain the identifier of the device as
      well as various other attributes.  Both communication parties are
      assumed to be in possession of a trust anchor store that contains
      CA certificates and, in case of certificate pinning, end-entity
      certificates.  Similarly to the other credentials the IoT device
      needs information about which entity to use which certificate
      with.  Without a trust anchor store on the IoT device it will not
      be possible to perform certificate validation.

   We call the above-listed information device credentials and these
   device credentials may be provisioned to the device already during
   the manufacturing time or later in the process, depending on the
   envisioned business and deployment model.  These initial credentials
   are often called 'root of trust'.  Whatever process for generating
   these initial device credential is chosen it MUST be ensured that a
   different key pair is provisioned for each device and installed in
   as-secure a manner as possible.  For example, it is preferable to
   generate public / private keys on the IoT device itself rather than
   generating them outside the device.  Since an IoT device is likely to
   interact with various other parties the initial device credential may
   only be used with some dedicated entities and configuring further
   configuration and credentials to the device is left to a separate
   interaction.  An example of a dedicated protocol used to distribute
   credentials, access control lists and configuration information is
   the Lightweight Machine-to-Machine (LWM2M) protocol [LWM2M].

   For all the credentials listed above there is a chance that those may
   need to be replaced or deleted.  While separate protocols have been
   developed to check the status of these credentials and to manage
   these credentials, such as the Trust Anchor Management Protocol
   (TAMP) [RFC5934], their usage is, however, not envisioned in the IoT
   context so far.  IoT device are assumed to have a software update
   mechanism built-in and it will allow updates of low-level device
   information, including credentials and configuration parameters.

   With all credentials used as input to TLS/DTLS authentication it is
   important that these credentials have been generated with care.  When
   using a pre-shared secret, a critical consideration is use sufficient
   entropy during the key generation, as discussed in [RFC4086].
   Deriving a shared secret from a password, some device identifiers, or
   other low-entropy source is not secure.  A low-entropy secret, or
   password, is subject to dictionary attacks.  Attention also has to be
   paid when generating public / private key pairs since the lack of
   randomness can result in the same key pair being used in many
   devices.  This topic is also discussed in Section 14 since keys are
   generated during the TLS/DTLS exchange itself as well and the same
   considerations apply.

Let me know what you think about this proposed change.

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 21:39:35 +0100

> Let me know what you think about this proposed change.

I like it.

Only thing I'd suggest is to maybe say that you need a good
source of randomness when generating key pairs on-device. And
maybe add a reference to the mind your p's and q's paper as
a counterexample.

Cheers,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Jul 2015 10:06:55 +0200

Hi Stephen,

I included a reference to the randomness section where I discuss this
topic in more detail since the importance of randomness is not only
important for keys provisioned into the device during manufacturing but
also later.

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jul 2015 11:58:01 +0100

> important for keys provisioned into the device during manufacturing but

Works for me, thanks,
S

> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>