View Issue Details

IDProjectCategoryView StatusLast Update
0000076easycwmpQuestionpublic2015-10-05 14:39
Reporterfeckert Assigned Tomohamed.kallel  
Status resolvedResolutionno change required 
Summary0000076: NONCE_PRIV_KEY

could you please explain why the value NONCE_PRIV_KEY in digestauth.c is not randomized during runtime with /dev/random?

Kind regards Flo
TagsNo tags attached.
e-mail notification



2015-08-26 10:16

administrator   ~0000271

The digest source code was originally imported from libmicrohttpd open source (as indicated in the top of the digestauth.c). we did not spend much time in order to improve it. Please feel free to make any suggesstion (patch) to generate randomly the NONCE_PRIV_KEY.


2015-10-01 19:02

administrator   ~0000284

The NONCE_PRIV_KEY is not the real nonce sent in the digest authentication packet. this constant string is used as constant to generate a random nonce by the function

static void calculate_nonce(uint32_t nonce_time, const char *method,
        const char *rnd, unsigned int rnd_size, const char *uri,
        const char *realm, char *nonce)

So in the reality the nonce in the packet is random and it's not constant. You can check that in the traffic.

So nothing to do for this issue


2015-10-02 10:27

administrator   ~0000285

From feckert (by email)

That is not completly right, its maybe unrealisitc but if some one
knows the NONCE_PRIV_KEY (get source code and time )! See explanation
in source

         * Second level vetting for the nonce validity
         * if the timestamp attached to the nonce is valid
         * and possibly fabricated (in case of an attack)
         * the attacker must also know the random seed to be
         * able to generate a "sane" nonce, which if he does
         * not, the nonce fabrication process going to be
         * very hard to achieve.

I think it will be more save 99,99% if we can get the NONCE_PRIV_KEY
from /dev/urandom (unblocking read)) or /dev/random (blocking read).
If the service starts he will look in this device and get a random
number only valid for this server session run. And if the service will
restart a new one will be read from the decvice. Because it is a
service we should use unblocking read.

Wenn the service starts we will open urandom and get fill NONCE_PRIV_KEY

Pseode c code
int dev_random= open("/dev/random", O_RDONLY);
char nonce_priv_key[28];
size_t length = 0;
while (randomDataLen < sizeof nonce_priv_key)
    ssize_t result = read( dev_random, nonce_priv_key + length,
(sizeof nonce_priv_key) - length);
    if (result < 0)
        // error, unable to read /dev/random
    length += result;


2015-10-02 11:51

administrator   ~0000286

Last edited: 2015-10-02 11:53

Thanks feckert for your reply!
May be a Connection request does not need a such seurity level especially if your device is configured with a firewall that allow only CR coming from ACS. I think a random nonce based on time is sufficient.

But your answer and remark are interesting and good!
I will try to add your patch suggestion in a future delivery (inchallah).


2015-10-02 12:07

administrator   ~0000287

Last edited: 2015-10-02 12:08

The "/dev/random" is better than "/dev/urandom" for the security purpose, but since the "/dev/random" is a blocking read then It's better to use "/dev/urandom".


2015-10-05 14:39

administrator   ~0000292

fixed in EasyCwmp-1.1.7

Issue History

Date Modified Username Field Change
2015-08-24 10:37 feckert New Issue
2015-08-26 10:16 mohamed.kallel Note Added: 0000271
2015-10-01 19:02 mohamed.kallel Note Added: 0000284
2015-10-01 19:03 mohamed.kallel Status new => resolved
2015-10-01 19:03 mohamed.kallel Resolution open => no change required
2015-10-01 19:03 mohamed.kallel Assigned To => mohamed.kallel
2015-10-02 10:27 mohamed.kallel Note Added: 0000285
2015-10-02 10:28 mohamed.kallel Status resolved => new
2015-10-02 11:51 mohamed.kallel Note Added: 0000286
2015-10-02 11:53 mohamed.kallel Note Edited: 0000286
2015-10-02 12:07 mohamed.kallel Note Added: 0000287
2015-10-02 12:08 mohamed.kallel Note Edited: 0000287
2015-10-05 14:39 mohamed.kallel Note Added: 0000292
2015-10-05 14:39 mohamed.kallel Status new => resolved