"

Sigsafe: An electronic key tag for signing bitcoin transactions

Peter R
peter_r@gmx.com
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 tags 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
usersmodern-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





#
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 tags 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.





$

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 cells 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 bitcoins 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).





%
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 LiMnO
2
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.





&
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 owners
hot wallet. It is unlikely that a thief in possession of the tag would simultaneously be in
possession of the hot wallets 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).





'

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 tags 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 users hot wallet could be an app for a phone or software running on
a computer with an external NFC reader. The tags 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 wallets NFC reader,
the wallet software reads the sticker address.





(
Sticker address Nonce Public encryption key
The wallet software confirms that the tag controls the cold address and then transmits the
users 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 users 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 users 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)





)
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





*
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 users 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 tags private keys are stored in the
microcontrollers 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





"+
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 manufacturers private key, thereby proving that the manufacturers funds are
subject to the same risks as the customers.
Consumer advocacy groups could monitor the manufacturers 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 tags 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.






""
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 Gouva, L.B. Oliveira, J. Lpez, 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 Implementers 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.