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
Topic: Ideas/brainstorming for secure timer. (Read 1015 times)
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?
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?
Jump to: