Sigsafe: An electronic key tag for signing bitcoin transactions

1  

Sigsafe: An electronic key tag for signing bitcoin transactions

Peter R [email protected]

sigsafe.org

Abstract. A small electronic key tag for signing bitcoin transactions over a non-exploitable air gap is described. The tag communicates via a simple protocol with a NFC-enabled host, harvesting power directly from the NFC electromagnetic field and eliminating the need for a battery. After receiving a signature request from a host device, the tag checks the request against a set of rules and signs the transaction, provided none are violated. User-defined signing rules permit various levels of security from none (sign all requests), to locking the spend addresses, limiting the value of transactions, and requiring a password from the tag’s owner or cryptographic authentication from the host. Malware, hackers or thieves cannot feasibly extract the private keys even with physical access to the tag. A tag manufacturer could store a funded private key within each device sold, with a rule to produce only bitcoin-signed messages, as a proof-of-intent bond to earn customers’ trust.

1. Introduction

Bitcoin is a peer-to-peer electronic cash system that allows users to store, transport and exchange funds with other users across the world, without the assistance of a third party or the permission of an authority. To authorize a bitcoin transfer, a user must sign his transaction using a seventy-eight digit number (256-bit) referred to as a private key. The fundamental security challenge in bitcoin is managing these keys: lose them and the coins can no longer be spent, allow them to fall into the wrong hands and the coins can be stolen.

Key management solutions balance ease of spending with security of stored bitcoins. A small balance used on a daily basis should be easy to spend, while a large balance accessed on a quarterly basis should be highly secure. In all cases, it should be extremely difficult to leak private keys to a hacker, malware, or a thief with physical access.

Any device connected to the internet and running on a third-party operating system is subject to key-loss due to hacking or malware by all but the most diligent computer users—modern-day operating systems are simply too complex for the average user to secure. Keys printed on laminated archival-quality paper and stored in a vault eliminate the concern with hackers and malicious software, but spending these offline funds

2  

becomes a time-consuming process. What is needed is a device that combines the security of an offline paper key with the usability of an online wallet.

This manuscript describes such a device: a small electronic tag that signs bitcoin transactions subject to user-defined signing rules over an air gap interface and without risk of leaking keys even to an attacker with physical access. The device uses the near-field communication (NFC) standard, allowing it to communicate directly with NFC-enabled phones and laptops, existing contactless-payment readers at PoS terminals, or through a HTML5 web browser that supports the Web NFC API [1]. Section 2 illustrates the device form factor and electronics hardware, while Section 3 considers the amount of electrical energy required to produce an elliptic curve digital signature algorithm (ECDSA) signature. Section 4 provides rationale for the backup battery and then calculates its expected lifetime under different operating conditions. Section 5 describes the signing rules including the ability to lock spending to white-listed addresses, limit the value transferred, require a password from the user, or require cryptographic authentication from the NFC host. Section 6 outlines how a host issues requests to the tag, and then gives examples of how the tag can be used as part of a cold/hot wallet system or as a “tap-and-pay” device at a bitcoin-enabled NFC point-of-sales (PoS) terminal. Section 7 describes advanced features of the tag such as support for hierarchal deterministic wallets and multisig, and general-purpose identification. Section 8 explores various vectors that an attacker may pursue when attempting to extract private keys, while Section 9 describes the “proof of intent” concept that manufacturers can use to demonstrate to customers that private keys stored on the device are secure. The manuscript concludes in Section 10.

2. Hardware

The bitcoin signing tag consists of a small circuit board enclosed by a plastic case with a hole for attachment to a key ring (Fig 1). A QR-code representing one of the tag’s bitcoin addresses (sticker address) is adhered to the plastic case, facilitating deposits through optical methods.

The circuit board contains a low-cost microcontroller, NFC transceiver, loop antenna, bi-color light-emitting diodes (LEDs), and an optional battery. The microcontroller communicates with a NFC host, decodes transaction requests, checks requests against signing rules, and signs authorized transactions. The NFC transceiver implements the required NFC communication protocol and extracts energy to power the microcontroller during transaction signing when no battery is available. The LED blinks red for unauthorized transactions and green when an authorized transaction is signed.

3  

FIGURE 1 Example bitcoin signing key tag.

The optional backup battery is a non-rechargeable lithium manganese dioxide cell

separated from the NFC antenna by a sheet of sintered ferrite to reduce the attenuation of the NFC field by the cell’s lithium anode. It sources burst currents to the microcontroller to expedite ECDSA operations and, depending on the needs of the user, it powers a clock to keep track of time. The battery should last several years, after which the device still retains the ability to sign bitcoin transactions.

3. Energy and time required to produce an ECDSA signature

A low-power MSP430 microcontroller with hardware multiplier has been reported to generate digital signatures using bitcoin’s secp256k1 curve in 0.45 s at an 8.0 MHz clock speed [1] . The TI MSP430F5xx series of microcontrollers draw roughly 0.20 mA per MHz, suggesting that generating an ECDSA signature requires 0.70 mA-s of charge (0.20 × 10-3 C/s / MHz × 0.45 s × 8 MHz = 0.70 x 10-3 C). Assuming the microcontroller operates at 2.5 V, this implies an energy consumption of less than 2 mJ per signature (0.70 × 10-3 C × 2.5 J/C = 1.8 mJ).

4  

If a battery is not used with the tag, bitcoin transaction signing times depend on the rate at which energy can be harvested from the NFC field. For example, the NFC interface chip AS3953 by AMS harvests up to 16.5 mW (5 mA at 3.3 V) [3]; however, experimentation by the author, using a standard-power (1 W) NFC reader and a mock-up antenna with a battery shielded by sintered ferrite, indicated that 3 mW to 9 mW is a more conservative estimate. This suggests signing times without a battery should fall between 0.2 s and 0.6 s depending on the distance between the tag and the reader.

If a battery is used, the microcontroller is free to draw much larger burst currents. For example, the MSP430F5xx microcontrollers can be clocked at up to 25 MHz from a 2.5 V source capable of delivering at least 5 mA, thereby producing signatures in approximately 150 ms.

4. Backup battery and clock

Although a battery is not strictly necessary, in addition to expediting ECDSA operations, including one allows the microcontroller to operate a low-power clock to keep track of the passage of time. Knowledge of time permits time-dependent spending limits to be enforced as will be discussed in Section 5.

A potentially suitable battery is the 3V foil-wrapped LiMnO2 cell CP452922 from Powerstream. It has a physical size of 22 × 29 × 0.45 mm, a capacity of 16 mA-hr, and supports burst currents up to 40 mA. Ignoring leakage current and other energy losses, such a battery could produce approximately 80,000 ECDSA signatures over its useful life. If the tag produces on average 3 signatures per day, it will consume approximately 2.1 mC doing so. Over a 24 hr period, this is equivalent to an average current draw of 23 nA. When not producing signatures, the tag enters a low-power sleep mode. If the clock is not enabled, the device consumes approximately 180 nA through the microcontroller and conservatively another 50 nA due to leakage at the system level. Under these conditions, the average current consumption including ECDSA signing is approximately 253 nA, implying a useful battery life up to seven years. The current consumption increases to approximately 1.5 µA when the microcontroller is keeping time, reducing the life of a 16 mA-hr battery down to one year if the clock is continuously enabled.

5. Signing rules

The user can specify signing rules independently for each private key stored in the tag. To prevent tampering by an attacker, it is only possible to modify these rules if the tag is unlocked by providing it with cryptographic proof of control (e.g., proof of knowledge of the relevant private key). Under no conditions is it possible to read or erase private keys.

5  

Locking the spend address. Requests are only signed if the transaction moves funds to a white-listed address, such as the hot address of a cold/hot wallet system. If a thief gained physical access to the tag, he would only be able to move funds into the owner’s hot wallet. It is unlikely that a thief in possession of the tag would simultaneously be in possession of the hot wallet’s private key.

Setting a transaction-based spend limit. Transaction requests seeking authorization for amounts greater than a user-defined spending limit will not be signed. To prevent a malicious host device from draining the balance with several small transactions in quick succession, the tag will run its clock for a short amount of time after producing a signature, ignoring new signature requests. Since the energy harvested from the NFC field during signing is sufficient to run the microcontroller for several seconds after the field is disabled, the backup battery is not required to implement this signing rule.

Setting a time-based spend limit. When this signing rule is enabled, the tag runs its clock as required when in sleep mode, enabling it to tabulate the amount of bitcoins spent each hour, day, or week and disallow transactions if certain limits are exceeded. Use of time-based signing rules may significantly decrease battery life.

Implementing password protection. The user can specify a password for the tag. The host must include this password when making a request or the transaction will not be signed. For example, a phone-based bitcoin wallet would prompt the user for their password and append this to the request being made. To deter brute-forcing of simple passwords (e.g., 4-digits), the required delay between signing requests increases with the number of failed password attempts.

Requiring cryptographic authentication. The host device must sign a random nonce generated by the tag. The tag checks the signature from the host, and, unless the signature verifies to a trusted address, the transaction request will not be signed. For example, the tag could trust certain brands of PoS terminals deployed throughout brick-and-mortar stores.

Producing only bitcoin-signed messages. The tag will only produce bitcoin-signed messages for private keys that have this option set.

6. Communication with a host device and example use cases

When unpowered, the tag appears as a RFID, allowing a RFID or NFC reader to learn about the device. Upon entering the NFC magnetic field, the tag “wakes up,” harvesting power directly from the field. The host makes a transaction request to the tag, the tag checks the request against its signing rules, and, when permitted, transmits the required signatures back to the host (Fig 2).

6  

FIGURE 2 Typical communication flow chart between a bitcoin-signing tag and a NFC host.

Example 1: A simple cold/hot wallet system. A practical use for a bitcoin signing tag is implementing a cold/hot wallet system. The owner simply locks the tag’s spending address so that only transactions that move bitcoins to the hot wallet (or change back to the cold wallet address) are signed.

For example, the user’s hot wallet could be an app for a phone or software running on a computer with an external NFC reader. The tag’s sticker address is imported to the wallet in watch-only mode. The user initiates a transfer from this watch-only address to the white-listed hot wallet. The hot wallet assembles the transaction and prompts the user to sign. Upon bringing the tag into the NFC field generated by the wallet’s NFC reader, the wallet software reads the sticker address.  

7  

Sticker address Nonce Public encryption key

The wallet software confirms that the tag controls the cold address and then transmits the user’s transaction request over NFC.

Request (sign bitcoin transaction)

Password Cryptographic authentication

The tag parses the transaction, and, if all outputs are assigned to the white-listed hot address (or as change returned to the cold wallet address), it signs the transaction and transmits the required signatures to the host.

Acknowledgement or error code

Signature (if authorized)

The wallet app then completes the transfer by broadcasting the signed transaction to the bitcoin network.

Example 2: Debit card emulation. With a bitcoin-enabled contactless PoS terminal, the tag can emulate a legacy debit card. Signing rules may include a maximum transaction value, daily spending limits, and password authentication.

To receive a payment, the merchant enters the amount requested on the PoS terminal. The user enters his password (if required) into the PoS terminal, and then scans his tag, allowing the PoS terminal to read the sticker address and the public encryption key (if used).

Sticker address Nonce Public encryption key

The PoS terminal assembles a bitcoin transaction that spends the amount requested by the merchant from the user’s sticker address, returning any change to the same address and transmits the request over NFC to the tag. If the public-encryption-key field was set, the PoS terminal must encrypt the password.

Request (sign bitcoin transaction)

Password (encrypted)

Cryptographic authentication

The tag verifies the user’s password and confirms that the sum of all outputs not returned to the sticker address is no greater than the maximum spend limits. If these rules are met, the tag signs the transaction and sends the required signature back to the PoS terminal.

Acknowledgement or error code

Signature (if authorized)

8  

 The PoS terminal then broadcasts the transaction to the bitcoin network to complete the purchase.

Example 4: Unlocking the tag to add a new private key or to modify signing rules. All communication with the tag is carried out on a per-request basis. Certain requests, such as updating signing rules or adding a new private key, require cryptographic authentication. For example, to unlock the tag to update the hot wallet address, the host must sign the nonce read from the tag with the private key to the cold wallet address (which is assumed to be the sticker address in this example).

Sticker address Nonce Public encryption key

The host device transmits its request to the tag (e.g., update hot wallet address) along with the signature produced by signing the nonce:

Request (update hot wallet address)

Password Cryptographic authentication

(nonce signed by sticker address)

The tag then parses the request, sees that it involves changes to protected memory, and thus verifies the signature before proceeding. If the host provided the correct signature and if the request was completed successfully, the tag responds with an acknowledgement; otherwise it returns an error code.

Acknowledgement or error code

Signature

7. Advanced functionality

Tags may support more advanced functionality such as hierarchal deterministic wallets, multisig, and general-purpose identification.

Hierarchal deterministic wallets for improved privacy. For increased privacy, the bitcoin signing tag may support hierarchal deterministic wallets such as those based on BIP32. If this feature is implemented, the tag stores a private key seed, allowing it to sign transactions that spend coins from any bitcoin address on the corresponding address chain. A NFC host device could read the corresponding public key seed, allowing it to scan for bitcoin balances along the entire address chain. The host gains flexibility in structuring transactions for improved privacy, for example by avoiding change returned to the send address.

Multisig wallets. One or more signing tags can be used to create sophisticated multisig wallets. For example, a phone-based “smart wallet” could create and partially sign a transaction and relay the transaction to the tag over NFC; the tag would then

9  

complete the signature and relay it back to the phone. The wallet could manage and secure funds as desired by the user. For example, a small amount of funds could be spendable by the phone alone, larger daily purchases could require a second signature from a tag attached to user’s physical key chain, and very large transfers could use a different tag normally kept locked in a safe or a safety deposit box.

Identification feature. There are several cases where it may be useful to produce ECDSA signatures that do not directly involve bitcoin. For example, because the tag produces bitcoin-signed messages upon request, it could sign random text generated by a separate entity to authenticate a user. Such a feature could be used to login to an online account through an HTML5 web browser that support the Web NFC API [1], act as a loyalty card at a participating merchant, unlock the front door of your home, or perhaps in the future even start your car. Because your private key is never exposed, there is little risk of using the same key for multiple locks.

8. Attack vectors

Malicious actors may attempt to extract the private keys from the bitcoin signing tag using multiple methods.

Influencing the per-message secret number k. Prior to generating a digital signature using ECDSA, a non-zero per-message secret number must be generated [4]. If the same number is used to sign more than one message, an attacker can determine the private key algebraically from the signatures. Rather than relying on a clock-jitter-based random number generator [5], the tag employs a deterministic scheme for generating the k value [6], making it impossible for an attacker to influence the selection of k.

Electronically accessing flash memory. The tag’s private keys are stored in the microcontroller’s flash memory. Prior to loading firmware, this memory is accessible using the JTAG and bootstrap loader interfaces. Setting the JTAG security lock irreversibly disables the JTAG interface, while the bootstrap loader can be erased when loading the device firmware. No further communication with the device beyond what is enabled by the source code is possible [7].

Side-channel attack. By monitoring the amount of time and energy it takes for a processor to produce ECDSA signatures, researchers claim it may be possible to recover private keys by observing as little as 200 test signatures [8]. Although there does not appear to be evidence that such an attack has ever been successful in any practical setting, by ensuring that all signatures require the same amount of time and energy, or by adding randomness to the time and energy, potential side-channel attacks are defeated.

Observing the keys with scanning electron microscopy. Equipped with the firmware source code and a map of the processor die, an attacker may be able to identify the physical location where the private key is stored and infer the state of each bit in memory

10  

using electron microscopy. There does not appear to be evidence that such an attack has ever been successful in a practical setting.

NSA back door. Speculation exists that large corporations such as Texas Instruments have been compromised to provide “back doors” on all processors for NSA access; however, there is no evidence that this is the case, especially for small, low-cost 16-bit processors such as the MSP430.

9. Proof of intent

Manufacturers producing bitcoin-signing tags can demonstrate their proof of intent by placing bitcoins at risk alongside their customers’. For example, a manufacturer may control the address 1SigSaFePaToHGy4qxgNcxwd5r6sEXmFg and deposit 10 BTC as a proof-of-intent bond. Because signing rules for a particular key cannot be changed without cryptographic proof of that key, the manufacturer could write the private key for this bitcoin address to each device sold, specifying the signing rule “produce bitcoin-signed messages only.” A customer could use his tag to produce a bitcoin-signed message with the manufacturer’s private key, thereby proving that the manufacturer’s funds are subject to the same risks as the customers’.

Consumer advocacy groups could monitor the manufacturer’s proof-of-intent address, and, if the funds ever moved, raise concerns within the bitcoin community that a particular brand of tag may have been compromised. Bitcoin users would naturally favor manufacturers with proven track records that posted large proof-of-intent bonds.

10. Conclusion

A small electronic key tag for signing bitcoin transactions over a non-exploitable air-gap was described. The device communicates with a NFC host, drawing power from the NFC field and eliminating the need for a battery. User-defined signing rules permit various levels of security from none (sign all requests), to locking the spend addresses, limiting the value of transactions, and requiring a password from the tag’s owner or cryptographic authentication from the host. Two example uses were considered: implementing a cold/hot wallet system with a signing tag, and using a tag as a debit card emulator for PoS purchases in brick and mortar stores. The manuscript explored possible attack vectors including influencing the random number generator, electronically accessing flash memory, performing a side-channel attack, or reading the private keys with a scanning electron microscope. Lastly, the paper introduced the concept of “proof of intent” as a way for manufacturers to earn customers’ trust.

11  

References

[1] “Web NFC API,” from World Wide Web Consortium, http://www.w3.org/TR/nfc/, (public working draft) January 2014.

[2] C.P.L Gouvêa, L.B. Oliveira, J. López, “Efficient Software Implementation of Public-Key Cryptography on Sensor Networks Using the MSP430X Microcontroller,” in Journal of Cryptographic Engineering, vol 3, pages 19 – 29, 2012.

[3] “AS3953 : 14443 High Speed Passive Tag Interface Datasheet,” from Austria Micro Systems Product Literature, Rev 1.0, 2013.

[4] “Suite B Implementer’s Guide to FIPS 186-3 (ECDSA),” from NSA Literature, February 3, 2010.

[5] L. Weslund, “Random Number Generation Using the MSP430,” from Texas Instruments Literature, SLAA338, October 2006.

[6] T. Pornin, “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA),” from RFC 6979, ISSN: 2070-1721, August 2013.

[7] “MSP430TM Programming Via the JTAG Interface User's Guide,” from Texas Instruments Product Literature, SLAU320M, July 2010 (Revised February 2014).

[8] N. Benger, J van de Pol, N.P. Smart, Y. Yar, “‘Ooh Aah... Just a Little Bit’: A small amount of side channel can go a long way,” from International Association for Cryptologic Research, 2014.