Subject: [Dtls-iot] Fwd: [dice] #4 (profile): Random Number Generation

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Jun 2014 20:19:23 +0200

-------- Original Message --------
Subject: [dice] #4 (profile): Random Number Generation
Date: Fri, 20 Jun 2014 14:43:25 -0000
From: dice issue tracker <[email-masked]>
To: [email-masked]
CC: [email-masked]

#4: Random Number Generation

 TLS requires random numbers and there have been problems with random
 number generation on embedded devices [Heninger]. A reference to RFC 4086
 is already in the draft.

 Random numbers are required in three places in TLS:

 * initial random nonces exchanged by the client and the server,
 * random value encrypted with the server's public key in case of key
 transport or when certain ciphersuites are used
 * ephemeral key pairs (e.g., as part of an Diffie-Hellman exchange)

 Recommendation: IoT devices using TLS must use a hardware-based random
 number generator since the typical sources contributing to the randomness
 pool are not available on an embedded device (such as mouse movement,
 keyboard input, etc.).

-- 
---------------------------------------+-------------------------------
 Reporter:  [email-masked]  |      Owner:  Hannes Tschofenig
     Type:  defect                     |     Status:  new
 Priority:  major                      |  Milestone:
Component:  profile                    |    Version:
 Severity:  Active WG Document         |   Keywords:
---------------------------------------+-------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dice/trac/ticket/4>
dice <http://tools.ietf.org/dice/>

---

From: Russ Housley <[email-masked]>
Date: Sat, 21 Jun 2014 15:32:01 -0400

I like hardware devices for random numbers, but we do not really care what implementation approach is used as long as the result is quality random numbers.  I'd prefer to state the requirement and not the mechanism.  There is an opportunity in the security considerations to warn implementers that mouse movement, keyboard input, and so on are not available as entropy in most embedded devices.  So, then need to seek other sources for entropy.

Russ

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Jun 2014 09:39:25 +0200

Hi Russ,

you are right that the actual implementation details do not matter. Will
make it more generic and add a discussion about the problems embedded
systems are facing. Some of it is already in the document via the
reference to [Heninger].

I think it is very important to the reader to convey the message
regarding random number generation since I see cases where Internet
protocols are ported to embedded platforms but little thought it spent
on the circumstance that the previously available sources of randomness
suddenly don't exist anymore.

I was also wondering about the reaction from the group since there are
participants who have been involved in the design of some of those IoT
systems and I am curious about their approach for solving this issue.
Another one, which I haven't added to the issue tracker yet, is the use
of a clock. Not even the Raspberry Pi has a real-time clock...

Ciao
Hannes

   [Heninger]
              Heninger, N., Durumeric, Z., Wustrow, E., and A.
              Halderman, "Mining Your Ps and Qs: Detection of Widespread
              Weak Keys in Network Devices", 21st USENIX Security
              Symposium, https://www.usenix.org/conference/
              usenixsecurity12/technical-sessions/presentation/heninger,
              2012.

On 06/21/2014 09:32 PM, Russ Housley wrote:
> I like hardware devices for random numbers, but we do not really care
> what implementation approach is used as long as the result is quality
> random numbers.  I'd prefer to state the requirement and not the
> mechanism.  There is an opportunity in the security considerations to
> warn implementers that mouse movement, keyboard input, and so on are
> not available as entropy in most embedded devices.  So, then need to
> seek other sources for entropy.
> 
> Russ
> 
> 
>> Subject: [dice] #4 (profile): Random Number Generation Date: Fri,
>> 20 Jun 2014 14:43:25 -0000 From: dice issue tracker
>> <[email-masked]> To: [email-masked] CC:
>> [email-masked]
>> 
>> TLS requires random numbers and there have been problems with
>> random number generation on embedded devices [Heninger]. A
>> reference to RFC 4086 is already in the draft.
>> 
>> * initial random nonces exchanged by the client and the server, *
>> random value encrypted with the server's public key in case of key 
>> transport or when certain ciphersuites are used * ephemeral key
>> pairs (e.g., as part of an Diffie-Hellman exchange)
>> 
>> Recommendation: IoT devices using TLS must use a hardware-based
>> random number generator since the typical sources contributing to
>> the randomness pool are not available on an embedded device (such
>> as mouse movement, keyboard input, etc.).
> 
> _______________________________________________ dtls-iot mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dtls-iot
>