Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tinydtls-dev] Secure Random Number Generator ?

Shouldn’t Cookies also be generated by a Crypto-Secure PRNG ?

 

As I said before, this is not really a performance or other real issue. All you need is 3DES and several pages of Flash (to handle wear-out over device lifetime due to CTR updates).

 

From: tinydtls-dev-bounces@xxxxxxxxxxx [mailto:tinydtls-dev-bounces@xxxxxxxxxxx] On Behalf Of Raul Fuentes
Sent: Wednesday, May 11, 2016 2:33 PM
To: tinydtls developer discussions <tinydtls-dev@xxxxxxxxxxx>
Subject: Re: [tinydtls-dev] Secure Random Number Generator ?

 

Hi,

Another thing that will impact with the PRNG  and tinydtls is the starting time.  For motes and Linux's implementation, they are beginning with EPOCH 0 (January 1th, 1970 00:00:00.0). This mean that the cookies generated by TinyDTLS are, probably, vulnerable to repetition attacks.

This can be verified with the first  Client Hello generated by the motes, where the date will be January 1th, 1970 00:00~

                                                                                        

 

2016-05-11 13:07 GMT+02:00 Frank Gerlach <Frank_Gerlach@xxxxxxxx>:

Hello list,

Obviously, a good PRNG (or a hardware RNG) is required for protocols like DTLS and TLS.

 

The default implementation is very, very, very weak.

 

EPAM could contribute a small, yet secure PRNG mechanism.

 

It requires just the 3DES algorithm and 16+8 octets of Flash memory (in reality a bit more, because the Flash must be written on each boot cycle and a single page may wear out before the device-end-of-life) to operate.  Max Performance (octets/s) is much better than /dev/random.

 

Are you interested ?

 

Kind regards

 

Frank Gerlach

 

 

 

This is the default:

 

/**

* Fills \p buf with \p len random bytes. This is the default

* implementation for prng().  You might want to change prng() to use

* a better PRNG on your specific platform.

*/

static inline int

dtls_prng(unsigned char *buf, size_t len) {

  while (len--)

    *buf++ = rand() & 0xFF;

  return 1;

}

 

 

This is the algorithm I suggest:

 

/************************************************************************************************

* The following mechanism provides Cryptographically Strong Pseudo-Random Numbers,

* even on very limited devices.

 *

 * The Basic Concept is very simple:

*

 * 1.) Have 128 (or 256) bits of physical randomness PHRANDOM_SECRET in persistent memory.

* 2.) Have a 64 bit counter CTR in persistent memory.

* 3.) Have a symmetric cipher Ciphertext = SCipher(Key,Plaintext). E.g. 3DES.

* 4.) To obtain a word of pseudo-random bits:

*        4.1 calculate RandomData = SCipher(PHRANDOM_SECRET,CTR)

*        4.2 increment CTR

*        4.3 persist CTR to storage

*

 *

 *

 * Arguably, it could also replace the /dev/random system of Linux and be a better alternative

* to that, because the various sources of "randomness" in /dev/random are not properly

* understood.

*

 * Bandwidth of the system is only limited by computational requirements of the symmetric cipher.

* Parallelization can be easily achieved and can allow for unlimited scalability.

*

 * The current implementation is made for the ESP8266 device, but can be easily adapted to

 * other information systems - either small or large.

*

 *

 * Note 1: It does of course "not hurt" to collect (somewhat) random data and to XOR-mix it into the

*         secure physical random number. A hash function could be used to the same end,

*         e.g. Davies-Meyer-3DES Hash.

*         This is NOT STRICTLY NECESSARY, though. The only requirement is to keep the random

*         128 bit number secure. That might include eventual deletion/replacement.

*

 * Note 2: Other symmetric Block ciphers such as GOST 28147-89, Chiasmus, AES or Blowfish

 *         could be used instead 3DES. Of course, all ciphers must be considered "cryptographically strong",

*         which is a quality that will change over the span of several decades.

 *

 * Note 3: Hardware which has a limited number of write cycles (typically some type of EEPROM/Flash memory)

*         should keep track of the number of write cycles for each Flash page and make

 *         sure only "expected good" Flash Memory pages are being used for the storage of

 *         CTR and PHRANDOM_SECRET. Typically, a Flash page can only be correctly written 1000 to 10000

*         times.

 *        

 */

bool getSecureRandomness(uint64_t* secureRandomNumber)

{

    if( g_prngIsInitialized == false )

    {   

        if( !loadPhysicalRandomness(g_desKEY) )

        {

            return false;

        }

        three_des_key_setup(g_desKEY, g_three_schedule, DES_ENCRYPT);

        g_prngIsInitialized = true;

    }

    if( (g_prngCounter == 0) || (g_prngCounter == g_prngCounterNextLoad)  )

    {

     

        if( loadCounterAndIncrement(&g_prngCounter,PRNG_COUNTER_INCREMENT) )

        {

            g_prngCounterNextLoad = g_prngCounter + PRNG_COUNTER_INCREMENT;

        }

        else

        {

            return false;

        }

    }

   

    three_des_crypt((BYTE*)&g_prngCounter,(BYTE*)secureRandomNumber,(const BYTE (*)[16][6])g_three_schedule);

    g_prngCounter++;

}

 

 

Frank Gerlach

Senior Software Engineer

 

Office: +375 17 389 0100 x 23178   Cell: +375 29 877 4976    Email: frank_gerlach@xxxxxxxx

Minsk, Belarus (GMT+3)   epam.com

 

CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) to which it is addressed and contains information that is legally privileged and confidential. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. All unintended recipients are obliged to delete this message and destroy any printed copies.

 


_______________________________________________
tinydtls-dev mailing list
tinydtls-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tinydtls-dev

 


Back to the top