Topic: Sigsafe: A NFC key tag for signing bitcoin transactions (Read 23169 times)

Did this Project get cancelled?  I am assuming so with the inactivity, but it seemed like a great idea! I only came across it from your post here

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

off topic, but technically after the feature set was defined (thus, my point  )

And yet you got GreenAddress?

I'd suggest you keep working on the specification and tests - doing NFC correctly is not that easy (in a portable & working way), this is already great work and can turn into an even greater resource.

I don't think you should count on a commitment by a wallet developer to continue - I didn't get one, Trezor had to work on their own wallet, Mycelium are doing their own device ...

Sigsafe at a Crossroad

Hopefully some readers can help me decide what to do next because this project is now at a crossroad.

I've proven that a passive NFC device can parse and sign a bitcoin transaction and demonstrated that in a video.  I've obtained hands-on experience with elliptic curve cryptography, I've learned how bitcoin transactions are structured at the bit level, and I now I have a working device I can use to secure my personal bitcoins much better than the wad of paper wallets that inspired the project in the first place.  In short, I've achieved a lot of what I set out to achieve.  Of course, I was also hoping this would turn into something that others could use; non-bitcoin R&D is no longer as fulfilling to me ...

So the question is, do I keep pushing forward?  The next steps would be time and resource consuming.  If I had a firm commitment from one or more developers of popular Android wallets that "yes, if we can prove that this works, we will add NFC hardware wallet support to our main line of code" then I think I would probably continue.  

But this device has limitations:

- It would only work seamlessly on Android phones at the moment.  Many computers would need an external USB NFC reader, and it's unclear if/when the NFC chip in the new iPhone 6 will be "open" to custom Apps.

- There's no screen.    

But of course it has advantages too:

- It's very simple and intuitive to use.

- It's low cost.

- It's more secure than using multisig paper wallets without also having an offline machine (but less secure than a fully offline machine).  

- NFC will likely become more widespread given Apple's new payment system.

- Android is > 80% of the smartphone market worldwide.

- Since the device has a sophisticated Cortex M3 processor, it's a good platform for developing more sophisticated devices (for example, a device with a tiny low-power screen that could draw power from the NFC EM field).

So, what should I do?

Yes, the microcontroller can be entirely powered from the EM field produced by the NFC reader, and it can draw enough current to perform elliptic curve operations at a reasonable speed (currently about 1.5 s for a multiplication and I think this can still be improved).   

I'm using the AS3953 chip from AMS.  It sources up to 5mA at 3.3V for your external circuitry, but in practice if I draw 3-4mA the voltage falls closer to 2.5V.  It's a bit tricky to get this chip working because you'll simultaneously be debugging the reader side and the target side, so let me know if I can help. 

I'm using an "Energy Micro" Cortex M3 from Silabs, as these have good efficiency and very low sleep currents.  With no LEDs illuminated, I'm able to perform elliptic curve multiplication running its internal RC oscillator at 21 MHz powered entirely from the EM field (in the video, I was running the micro at 21 MHz).  At faster clock speeds, the device browns out. 

So it seems the ARM can be powered from
EM field. Willing to share the part number of
the NFC chip?