Sigsafe: A NFC key tag for signing bitcoin transactions

[Peter R]

Sigsafe: A NFC key tag for signing bitcoin transactions

I wanted to share a project I’ve been working on.  It’s called “sigsafe” and it is an electronic key tag that signs bitcoin transactions over a non-exploitable air gap.  The device is probably too simple to be considered a hardware wallet; instead, it’s more like a paper wallet that can produce ECDSA signatures.  The device has both high-security applications such as implementing a cold/hot wallet system where the cold wallet can only send coins to the hot wallet, and low-security applications such as a “tap and pay” tag for purchasing retail items at PoS terminals.  Because the device uses the NFC standard, it is highly interoperable with existing phones, laptops, PoS terminals, and other RFID readers.  In fact, when HTML5 browsers begin to support the Web NFC API, it should be possible to create webpages that request signatures from the sigsafe to complete an online payment or to login to a website using the bitID protocol and a single tap.




Here is a link to the white paper: http://sigsafe.ca/sigsafe.pdf

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.

[1713241277]

1713241277

[1713241277]

1713241277

[1713241277]

1713241277

[Peter R]

UPDATE: September 7, 2014



Demonstration video: http://vimeo.com/105458967


UPDATE: August 4, 2014

Below are two pictures of the PCBs for our first nine alpha-model sigsafe bitcoin-signing tags.  The first image shows all nine lined up in two rows with a penny and a ruler for a scale reference.  Most of the board space is NFC antenna--the sigsafe electronics are very simple.  



This picture shows the top (right) and back-side (left) of a sigsafe.  The components on the top side include a low-cost microcontroller, a NFC transceiver, two bi-color LEDs, a few MOSFETs, supporting passive components, and solder pads to attach the optional 0.5mm thick battery.  The NFC loop antenna is visible from the backside of the circuit board.



It really works too:

Code:

$ tx=`pybtctool mktx d511b9d6b05f8f9dbac56b632acafeffb40c6025f694ae1d738c0d5edaab5308:0 1KxvX5Hx8nh36ig2gT5bpeEcqLQcwJsZGB:50000`
$ sigsafe sign $tx | pybtctool pushtx -s

UPDATE: June 9, 2014

To help illustrate potential use cases for an ECDSA signing tag like the sigsafe, a colleague and I prepared some additional images.  

This image shows the sigsafe about to sign a transaction (over NFC) that presumably sends 1.66 BTC to the Android hot wallet.  In an application like this, the sigsafe would be stored in a safe or another secure location, and would be configured to only sign transactions that transfer funds to the hot wallet.  The sigsafe could also require cryptographic authentication from the Android wallet or a password from the user.  



This image shows the sigsafe acting like a "tap-and-pay" device at a traditional PoS terminal.  The sigsafe is compliant with ISO 14443-4, so it already "speaks the same language" as these PoS terminals.  However, the terminals would need to be programmed to support bitcoin payments and the sigsafe protocol.  In an application like this, the sigsafe might be configured with a per-TX and a daily spend limit.  




PRESS COVERAGE:

[Adrian-x]

It looks like a cool product,

The biggest concern that comes to mind, what happens if I lose the Sifsafe? can the private key to the Hot Wallet be stored remotely.


Is there any value in integrating key finder as part of the package? something like this: http://www.thetileapp.com or this: http://www.stickrtrackr.com/


If one was to use Sifsafe at PoS payment terminals could it integrate with coinjoin, to anonymize purchasing habits.

[Peter R]

The biggest concern that comes to mind, what happens if I lose the Sifsafe?

That is an important concern.  There are two security issues regarding lost/stolen sigsafe tags:

  #1.  Can someone who has possession of your tag access your funds?
  #2.  Can you recover your funds without your tag?

To address concern #1, the user would set signing rules for the tag (or buy tags with the rules pre-programmed).  If this was a tag a user was using to make day-to-day retail purchases, he might setup a password and a daily withdrawal limit.   On the other hand, if this was a tag for a cold wallet, he may lock the spend address so that coins can only be sent to his hot wallet.  In either case, the tag is fully functional to the user, yet if he loses it, the probability that someone will be able to access his funds can be kept quite small.

To address concern #2, it would be critical for the user to keep back-ups of any private keys that he loads into the sigsafe, and that he keeps the backup "twin" sigsafe tag secure at home (I expect sigsafes would be sold in twinned pairs).  

can the private key to the Hot Wallet be stored remotely.

Each tag can hold multiple keys: Key0, Key1, … , KeyN .

Private keys programmed into the tag by the user can be stored/backed-up however the user likes, so yes.

But Key0 on each pair of sigsafe tags is not known by anyone in the world except the two tags (not even the manufacturer).  Key0 cannot be backed up, and this is why sigsafe tags would likely be purchased in pairs.  Of course, the user is not required to use Key0.  

Is there any value in integrating key finder as part of the package? something like this: http://www.thetileapp.com or this: http://www.stickrtrackr.com/

Potentially yes.  These trackers are pretty interesting.  

If one was to use Sifsafe at PoS payment terminals could it integrate with coinjoin, to anonymize purchasing habits.

Yes, sigsafe tags could sign coinjoin transactions to anonymize purchasing habits.  Advanced sigsafe tags could also support BIP32 address chains to avoid returning change to the spend address.

I don't think the challenge with this project will be technical; I think it will be organizational and your concern regarding anonymizing purchasing habits is important here.  The sigsafe already speaks the same language as standard NFC payment terminals (ISO 14443-4).  But there are defined standards built on top of this, for instance, for MasterCard® PayPass™ and Visa payWave®.  If we could publish our own standards for sigsafe, and if it became recognized in the community as robust, then it would clear a path for software upgrades to existing PoS terminals to seamlessly accept bitcoin in addition to the legacy alternatives.

[roslinpl]

Device looks pretty good!

I am just not too sure how long it will take to break it ;P if I will use it on a keychain I might be able to drop it or put it on a rain...

But I like this idea and it is kinda cool idea and another device to manage your BTC.

[Peter R]

Device looks pretty good!

I am just not too sure how long it will take to break it ;P if I will use it on a keychain I might be able to drop it or put it on a rain...

Thanks for the compliment.  

Although you would (should) have a backup in the unlikely event the device becomes damaged, if you are still worried about physical robustness and water damage then a sigsafe that is fully encapsulated in plastic resin would be your preferred choice.  This would be completely waterproof and highly robust to impact damage (but even regular injection-molded polycarbonate cases will be robust to impact damage such as dropping your keys).  

If you opt for a fully waterproof device, the issue is that it is unlikely that a battery could be included  This means that the sigsafe will not be able to enforce time-dependent spending limits (such as limiting spending to 1 BTC per week).  

[Adrian-x]

If you opt for a fully waterproof device, the issue is that it is unlikely that a battery could be included  This means that the sigsafe will not be able to enforce time-dependent spending limits (such as limiting spending to 1 BTC per week).  

It is totally possible to mitigate that concern, you have an Inductive charger / key holder where ever you keep your keys.

[Carlton Banks]

If you opt for a fully waterproof device, the issue is that it is unlikely that a battery could be included  This means that the sigsafe will not be able to enforce time-dependent spending limits (such as limiting spending to 1 BTC per week).  

It is totally possible to mitigate that concern, you have an Inductive charger / key holder where ever you keep your keys.

That would make these class of devices (RFID-type) a great candidate for novel battery technologies, as there is little room for a huge amount of substrate (and so the BoM per device would be as minimally impacted as possible). Something that needs life long reliability and that is necessarily tamper-resistant could use an innovative battery technology, although alot of these solid state battery solutions are permanently "5 years away".

[Peter R]

If you opt for a fully waterproof device, the issue is that it is unlikely that a battery could be included  This means that the sigsafe will not be able to enforce time-dependent spending limits (such as limiting spending to 1 BTC per week).  

It is totally possible to mitigate that concern, you have an Inductive charger / key holder where ever you keep your keys.

Yes, this would be very cool and hopefully this becomes doable very soon.  I identified three obstacles to doing this at this moment in time. None are "show stoppers":

  1.  The NFC standard for recharging small devices with EM fields in not finished, so the charging devices that currently exist are mostly custom.  This doesn't mean you can't use them, but I expect in a few years it will be common to have "inductive charging pads" that are highly interoperable between devices.  

  2.  The rechargeable battery most suitable for this application would be a lithium polymer cell, with a charge voltage of 4.1V.  I couldn't find any NFC tag interface chips that allowed you to bleed off more than 3.3V from the NFC field.  This means that I'd need to make a custom energy harvester.  Not a show stopper, but I bet once the NFC charging standard is complete, that NFC tag ICs will come with integrated lithium-polymer battery chargers.  

  3.  Based on my research, it is not advisable to completely encapsulate batteries due to the fact that they off-gas.  I talked to PowerStream and they basically said "don't do it," so I think we'd need to really make sure this was safe if we wanted to make a waterproof sigsafe with a battery.  

Thanks for the input, BTW!  I'm glad you like the inductive charging idea too.  Hopefully it could be made to work somehow.

[Peter R]

I should make it clear that IMO the challenge of adding a battery to a waterproof device is more about off-gasing (and charging voltage inconveniences), than battery life of the non-rechargeable batteries. The non-rechargeable battery I am presently using will last from 1 - 7 years depending on how the device is used, and the extent to which time-dependent spending rules are applied.  By adding just another 1mm to the device thickness, we could push the battery life to 3 - 20 years.  

Remember also, that these devices still work when the battery is completely dead.  They just sign bitcoin transactions more slowly and can't enforce time-limited withdrawals (since they no longer have a clock).  

[2112]

How about supercapacitor instead of the rechargeable battery? Would that meet your goals?

[Adrian-x]

How about supercapacitor instead of the rechargeable battery? Would that meet your goals?

Ultimately this tech will replace batteries. Capacitors are already used in watches with solar chargers.

The off gassing is not a problem either I've designed products with IP69K rating using GorTex membrane seals, and there are many off the self solutions.

[Peter R]

How about supercapacitor instead of the rechargeable battery? Would that meet your goals?

Thanks for the comment.  If you knew that the user would place his tag on a charging mat each evening, then I think an off-the-shelf supercap could be made to work.  For example, the 0.05 F XH409HG is 5mm in diameter, 0.9mm tall and looks like it could hold about 20uA-hrs worth of useful energy.  Four of these would allow the device to run its low power clock for 80 / 1.5 ~ 48 hrs, thereby enforcing time-dependent spending rules until the next recharge.  

Or if you could "top up" the supercaps from the NFC field during signing (rather than from an induction charger at home) than I think this would be the perfect solution.  The trouble is that you can only reliably draw 3 - 9 mW from the field and the tag may be in contact for only 1 second (so you can harvest perhaps 5 mJ).  The clock draws about 1.5 uA and over a 24 hr period this is 130 mJ.  So, we'd need to pull at least 25X more power from the NFC field, lengthen signing times to half a minute, or find a clock that uses less than 60 nA, to eliminate the need for the user to "recharge his tag."


In my opinion the non-rechargeable battery is the best compromise at least at this point in time.  It will last several years in most use cases, and the tag still works after the battery dies.  I think if you really want a fully-waterproof signing tag that you just accept the fact that you can't enforce time-dependent signing rules.  

[Peter R]

How about supercapacitor instead of the rechargeable battery? Would that meet your goals?

Ultimately this tech will replace batteries. Capacitors are already used in watches with solar chargers.

New solid-state energy storage devices will open up exciting possibilities for many technologies.  I'm looking forward to it.  

The off gassing is not a problem either I've designed products with IP69K rating using GorTex membrane seals, and there are many off the self solutions.

Definitely.  I think off-gasing would only become a problem if you insist on fully potting your electronics + battery in epoxy or some other plastic.  I'm confident this device can be made highly water resistant (while still allowing off-gas to diffuse) such that it could sit out in the rain or fall in to a lake and not become damaged.  But to make it waterproof such that you could hide it for 2 years in in your toilet-bowl's reserve tank would be difficult with such a tiny and low-cost item I think (or do you disagree, Adrian?)

[2112]

In my opinion the non-rechargeable battery is the best compromise at least at this point in time.  It will last several years in most use cases, and the tag still works after the battery dies.  I think if you really want a fully-waterproof signing tag that you just accept the fact that you can't enforce time-dependent signing rules.  

Thank you very much for your succinct explanation.

Indeed, the security device I've seen (nothing related to Bitcoin) was designed for use on a nearly every day, and the charging period was shorter because the device was completely enclosed during recharge/data exchange.

[Adrian-x]

To me you should consider the product lifestyle as part of the development process and business plan.

In effect get revenue flowing with the simplest product, building a customer base and test the idea as fast as possible.
then add to the product line including new features picking the low hanging fruit first. Proof of principal in the market.

Keep developing until you end up with the perfect product line targeting the full product demographic.

[Peter R]

To me you should consider the product lifestyle as part of the development process and business plan.

In effect get revenue flowing with the simplest product, building a customer base and test the idea as fast as possible.
then add to the product line including new features picking the low hanging fruit first. Proof of principal in the market.

Keep developing until you end up with the perfect product line targeting the full product demographic.

Yes, that is my thoughts as well.  I believe the device proposed in the white paper (minus support for hierarchal deterministic wallets from Section 7) with the (optional) non-rechargeable battery has the least technical risk, the shortest development cycle, and satisfies the needs of the largest pool of users.

Like you said, development can continue and new variants can be created after the first product is released, provided there is actually demand for rule-based ECDSA signing tags like this.  

[jambola2]

In my opinion the non-rechargeable battery is the best compromise at least at this point in time.  It will last several years in most use cases, and the tag still works after the battery dies.  I think if you really want a fully-waterproof signing tag that you just accept the fact that you can't enforce time-dependent signing rules.  

I totally agree with this , it seems the best at this time.

My questions is , how much do you estimate this to cost ?

I'm looking for a really rough estimate.

[fbueller]

djohndiddy: That was your first post on this forum? what issues are you having, or posting to make it appear bad?

I'm very interested in this project, and but not even sure if I'd be able to use it for anything yet. Most computers don't have NFC, phones are further along with this. The Web NFC API is very far away too. So how would people be using it if they received one today?

All my ideas are around authentication, but you need to be able to authenticate anywhere, not just at NFC enabled computers.

[ThePurplePlanet]

I read many times that address reusability is an issue for funds security. Would this be a problem? If yes in  which cases?