Real World Crypto conference

[Hal Murray]

fallenpegasus at gmail.com said:
> An idea that is being floated is an extension to UEFI and equivalents to
> allow admins to set or pin a cert, a signing cert, or a psk, that will be
> used by a trusted time source.  But people are waiting on the release and
> stabilization of the new secure ntp standard(s) before having UEFI et al
> start pushing it.

Pinning a cert gets you tangled up with certs.  I think you can avoid a huge 
pile of code if you just pin the public key of several servers.  The question 
is how deep does that key get buried.  Is it in a file system where it is 
easy to update?  Does that box (or that level of a bigger/smarter box) even 
have a file system?

> Another idea is to be pushing time around on the BMC-connected management
> network, and let the BMC set the motherboard clock before the main CPU
> boots.  This will require a trusted and secured ntp client running on the
> BMC

I think the BMC is a reasonable example of the category of small/dumb box I'd 
like to support.  Think IoT.  The low end can be pretty low.

I see several general approaches:

  Get your time from a within a trusted network.  How much you need to trust 
depends on how paranoid you are.  If you have smart switches, do you have to 
consider the bad guys taking over your switch?  How about WiFi?

  If your box has a RTC/TOY clock you can use it.  But batteries die and 
clocks go berserk.  You can sanity check with dates from the file system and 
build date of the code.  (You need a plan for gear that's been in storage for 
a long time.)

  You can ask a human operator.  They make mistakes.

  You can start with public keys from several servers.  The idea is to 
require sane answers from N out of M servers.  Normally when picking N and M, 
you would consider dead servers and broken servers.  Now you also have to 
consider leaked private keys and the lifetime of the gear and/or how often 
you get to update the list of keys.

You can obviously use various combinations.


> Other ideas are to let the L2/L3 switches try to keep accurate time, and to
> raise alarms if they ever see an NTP packet heading towards a machine in
> early boot stage with a time field that is too incorrect. 

Do you want your switches wasting cycles on that?  (and probably screwing up 
the timing while it is at it)

It also sounds like an opportunity for harassment.  Just send a packet and 
the alarm bells go off.


-- 
These are my opinions.  I hate spam.