Bitcoin Forum
November 23, 2017, 10:55:41 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
   Home   Help Search Donate Login Register  
Pages: [1]
Author Topic: Ideas/brainstorming for secure timer.  (Read 892 times)
Offline Offline

Activity: 1218

Gerald Davis

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

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?
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Hero Member
Offline Offline

Posts: 1511477741

View Profile Personal Message (Offline)

Reply with quote  #2

Report to moderator
Hero Member
Offline Offline

Activity: 728


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

Why not add an RTC?

Here's a breakout board for your prototyping pleasure:

Or this:

      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]
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!