[Cryptography] Best internet crypto clock

Arnold Reinhold agr at me.com
Sat Oct 18 22:40:48 EDT 2014


On Oct 17, 2014, at 8:17 PM, Tom Mitchell <mitch at niftyegg.com> wrote:

> On Sun, Oct 12, 2014 at 7:18 AM, Arnold Reinhold <agr at me.com> wrote:
> > On Oct 9, 2014, at 1:52 AM, Tom Mitchell <mitch at niftyegg.com> wrote:
> > ...
> > A free running tick counter that never overflows is a good thing.   Freedom
> > from time of day issues leap seconds and more make it easy.  The frequency
> > choice is open and precision and accuracy is open.   An external  map of ticks to
> > historic real world time (and temperature) is interesting in the right context.
> 
> A simple counter with no overflow would work, of course, but Inexpensive cpu clock chips, like the DS-1307 family, provide a 99 year range with one second resolution and have all the circuitry for dual supply (5 VDC and battery) with very low power (500 na) operation on battery.  Another possible advantage over a straight counter: yy-mm-dd-hh-ss in a time stamp is a lot easier to explain to a judge and jury than a long hexadecimal constant.
> 
> Here's a data point. I installed a cheap digital video recorder for a surveillance system just over four years ago. It's not connected to the Internet and I never adjusted the clock since installing it. I had to pull a clip off of it last week and the clock was 44 minutes fast. That's about a minute a month.
> 
> So if the device grabbed the current NIST beacon signed it with its internal clock and had the resulting certificate time stamped by an external authority once a month, that should be enough to establish minute accuracy.
> 
> I am with you except for the "grab NIST beacon" part.  This implies that
> the clock can be set and reset.  This muddies the accuracy and precision stuff further.
> If it can be reset based on an external reference then the jury can be told that
> the reference is unreliable even if the device is understood...
>     http://pdfserv.maximintegrated.com/en/an/AN504.pdf

No, you misunderstood me. My conception is that the clock can never be reset or adjusted once the device is FIPS-140 sealed during the manufacturing process. For example, a module that contains the clock chip, crystal and battery, as described in the Maxim application note above, might first be plugged into a station that starts up the clock and set its time. If the NVRAM on the clock chip were used, it would be initialized as well. The clock module would then be plugged into the camera board. The camera board would include a hardware interface that did not permit writing to the clock module. A parallel interface might wire the write line off. An I2C serial interface might use a special state machine that never asserts the write bit. 

My "grab NIST beacon" step is part of creating an electronic document that might be called a Clock Calibration Certificate (CCC). The camera gets the latest NIST beacon, appends its current clock reading, signs it with its secret key, and then send the resulting document to a time stamping authority. The timestamped document is our CCC (or maybe we have the camera add a second internal clock time stamp and sig).  Each CCC bounds the actual time that corresponds to the internal clock reading. It is no sooner that the time of the NIST beacon value and no later that the time stamp authority's time stamp. CCCs can be generated periodically or at the start of a picture-taking session. The CCCs can be stored on the camera, as they are small compared to even a single photo, and/or backed up to the cloud, a server or a registrar. Each image file might have the latest CCC attached and perhaps enough older CCCs to allow the camera clock's drift rate to be calculated, allowing more precise time measurements. 

There are a variety of ways of using the CCC, but the point is that each one is an irrefutable comparison of internal clock time with time traceable to national standards.
> 
> Some of this has been addressed with key generation devices where
> management can connect the device and set and reset the device
> while matching it to a user or user group account.

That is a possibility, but I like the simplicity of a device that cannot have its clock and security parameters altered.

> 
> For the specific case of validating a photo equivalent without a preexisting trust anchor
> the problem is hard.
> 
> One special case involving security camera images where a cell phone 
> image (any camera)  and security camera data of the same public 
> location can be compared and the relative location of people in motion
> can be matched.   Now the date time has value in finding the corresponding
> video images captured and archived from multiple angles and from multiple
> authorities.  

If the camera has Internet access, it might be able to use the same approach of getting a NIST beacon, appending it to an image or set of images, then hashing everything. Or maybe use the NIST beacon number as the key for a keyed hash. Then time stamp the hash

> 
> The low cost and low power of a DS-1307 does make it interesting.  It also
> moves a power requirement away from programmable logic or processing
> that do not need to be on all the time.
> 

One fewer wheel to re-invent. 

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141018/73d5e442/attachment.html>


More information about the cryptography mailing list