Bitcoin Forum
December 04, 2016, 08:33:14 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Ideas/brainstorming for secure timer.  (Read 820 times)
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
May 31, 2012, 01:12:06 AM
 #1

I am programming a cryptographic processor to operates as a "bitcoin security module" which will act as a second line of defense protecting hotwallets.  The hardware will handle transaction signing without revealing the private key.  Of course that by itself doesn't provide much security as an attacker/malware can simply request the device sign a tx in lieu of stealing the private keys directly.  The security would come from the enforcement of rules (nonvolatile once initialized and stored internal to the hardware module).  Rules which limit max tx size, max volume, max aggregate BTC flow, max BTC acceleration, and enforce tx signing delays.

To ensure that requires the device to have independent timer (the security model of the device is that the host is potentially compromised and can't be relied upon for secure information such as timestamps).   The hardware has a hardware timer which records the number of msec since power-on (500ms precision) but it is limited to 26 days.  The device has no battery backup so it internal timer will reset to 0 on power loss (both for the device and for the host OS so it includes reboot of host OS).

Now detection of a overflow/reset is trivial.  On each tx record the current timestamp and if smaller than prior timestamp then device has been reset (or overflowed due to being on for >26 days).

The question is how to handle that event.  How to retain timestamp coherency through resets.

One option is to have the device supplied a timestamp upon initialization.  That will require an admin password/key to be used on each startup (likely a good idea anyways) and also every 26 days.  This potentially exposes the system to an attacker/malware detecting the admin password/key.  This risk may not be unreasonable.  The device is intended to be used on secured server as a second line of defense to protect the private keys (aka Bitcoinica hack).  Compromising the server doesn't necessarily given the attackers the hardware password/key as in routine operation it isn't needed.

Still I wonder if there is a better way.

Simple version:
Given: hardware independent time since power on clock .
Limits: clock has limit of 26 days, clock has no battery backup
Query: how can you securely ensure coherence of timestamps through power disruption and/or overflow?
1480840394
Hero Member
*
Offline Offline

Posts: 1480840394

View Profile Personal Message (Offline)

Ignore
1480840394
Reply with quote  #2

1480840394
Report to moderator
1480840394
Hero Member
*
Offline Offline

Posts: 1480840394

View Profile Personal Message (Offline)

Ignore
1480840394
Reply with quote  #2

1480840394
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480840394
Hero Member
*
Offline Offline

Posts: 1480840394

View Profile Personal Message (Offline)

Ignore
1480840394
Reply with quote  #2

1480840394
Report to moderator
Revalin
Hero Member
*****
Offline Offline

Activity: 728


165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g


View Profile
May 31, 2012, 03:00:48 AM
 #2

Why not add an RTC?  http://datasheets.maxim-ic.com/en/ds/DS3234.pdf

Here's a breakout board for your prototyping pleasure: http://www.sparkfun.com/products/10160

Or this: http://www.sparkfun.com/products/99


      War is God's way of teaching Americans geography.  --Ambrose Bierce
Bitcoin is the Devil's way of teaching geeks economics.  --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!