Paul Wouters <paul@xxxxxxxxxxxxxx> wrote:
> /dev/random references into /dev/urandom. You are most likely better of
> giving the device a webgui and using the clients javascript to generate
> randomness. (yes I know, I just said to use javascript for private
> keys)
I agree --- generate the certificates in the web UI.
I don't think that this needs the private key to be created in javascript,
just for a .js function to collect some entropy and push it into /dev/random.
> But I'm still thinking of a scheme involving insecure ntp lookups for
> pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow
> down the current time. Of course, all of that is vulnerable to replay
> attacks.
I think that the best bet is to just turn off the time part of the DNSSEC
validation until the time is considered sane.
That limits the replay attack that can be done to replaying previous values
for pool.ntp.org. The IP addreses returned might no longer be NTP clocks,
and this could be annoying for those IPs involved, if there was some kind of
widespread denial of service attack.
Note that the NTP transaction is not protected at all by the DNSSEC, so
if the attacker is on-path and can do this replay attack, they can also just
attack the NTP transaction.
> Also, I believe the rasberry pi's, having the same problem, have a
> "hwclock" service that saves a timestamp on shutdown to the filesystem
> and loads it on boot. That solves the issue for quick reboots.
That also prevents going backwards in time, which is good.
Storing it in config eeprom may be better than flash.
> Another method is the last access time of the filesystem. But I'm not
> sure if that's a linux/ext4+ only feature, or whether the filesystems
> in embedded devices have a similar value stored somewhere.
In general, they want to avoid any writes to the flash, so updating that
value is a not desireable.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
Attachment:
pgpy3D8cTFwFp.pgp
Description: PGP signature