Sigsafe: A NFC key tag for signing bitcoin transactions

[Peter R]

... for the less tech savvy of us, I think a button of some sort still provides the best protection. I do understand that the button can add a cost, but then it may be cheaper to just make it some sort of a small switch or even lever.

The idea is that this device is for the less tech savvy (I'm imagining my dad).  The button isn't required because the "tapping" motion is the button press.  

A valid argument for a screen can be made (and if a screen was included a button would make sense too), but I worry that something with a tiny screen would be too hard to read and confusing for someone like my dad.  He would know to keep his sigsafe secure and he would be able to tap it against his phone to authorize larger transfers too.    
  

[Peter R]

I was thinking more about the "lack of a screen" concern when using the sigsafe as a second signer, as I was paddle boarding on the ocean this afternoon.  The more I think about this, the more confident I am that it's an edge concern and that sigsafe reduces the attack surface significantly.

Let's brainstorm the ways that coins could be stolen remotely:

1. Key logger
2. Wallet.dat stealer
3. Bad k-value used during signing
4. Low-entropy seed / supply-chain mole
5. Man-in-the-middle attack
6. ?

Sigsafe as a second signer solves #1 and #2 by design.  All wallets can eliminate #3 by using deterministic signatures.  #4 is addressed with sigsafe so long as the wallet you pair it with is independently controlled.  That leaves #5 and #6.  

We can resist #5 with "per tap" spend limits, locking the spend address, PIN access, authenticating the wallet, etc.

But how exactly could malware perform a MITM attack in the first place?  It would need to insert itself between the wallet app and the NFC API (which seems very difficult), fool the wallet app into thinking that it opened a handle to the NFC device normally, and, decrypt the wallet app's private keys, and steal any sigsafe authentication credentials.  When the user requests a transfer from the multisig address, the super-malware would have to manipulate the partially-signed transaction, re-sign it with the private key that it stole from the wallet app, modify the pubkey hash in the output script, use the stolen sigsafe authentication credentials to fool the sigsafe into thinking that it's the wallet so that sigsafe signs, and then connect to the internet to push the modified TX to the network.  

This seems far fetched to me.  I think most people lose the coins under their personal control because their wallet.dat file was stolen and cracked (e.g., from a wallet backup stored in a compromised email account).  Sigsafe solves this problem nicely.  

[dillpicklechips]

I agree, because the sigsafe is using multisig you have strengths and weaknesses for both the phone and sigsafe but together they are quite secure.

[intron]

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

[Peter R]

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

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. 

[intron]

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

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. 

Thanks a lot, like the details:-)

[Peter R]

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

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 (e.g., "tap to sign").

- 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?  [see poll at top]

[dillpicklechips]

So, what should I do?

I wish you luck in making the right call. I'd suggest messaging the mycellium developers. They seem to be dominating with android and have very leading edge features.

[starsoccer9]

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?

Just wanted to mention that adding windows phone support shouldnt be a problem either. Tho windows phone is a smaller percentage of the market but it is still something that should be considered.

[Newar]

I'd love to see this go forward.

Maybe write a nice email to (Android) wallet developers and see what you get for feedback? I don't think there's more than 10.

[railzand]

voted 'none of the above', but my 'no' is not about ubiquity. where do you live, Antarctica?
sigsafe is ideologically unsound. bitcoin is not for normal people, cups of coffee or tanks of gas.
financially, though, it could go all the way, because of everyone's stupidity and fashion-following - some idiot vc will snap it up.
you've written the opening chapters of '50 Hard Wallets of Grey'

[btchip]

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

[Newar]

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

And yet you got GreenAddress?

[btchip]

And yet you got GreenAddress?

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

[Newar]

And yet you got GreenAddress?

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

Just trying to be a bit more optimistic.



Came accross this "Aegis" wallet I have not heard of before and they seem to be involved with NFC technology already.
https://bitcointalk.org/index.php?topic=697430.msg7880853#msg7880853

[fulgurite]

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.

I like it, it will be useful and convenient if it can be created.

[gtraah]

PLEASE Speak to "Jan" on this forum, he is from mycelium and thinking about offline signing, this would be there PERFECT match

[Bonam]

I think you should go ahead with it. But then, I'm biased!

[Adrian-x]

here is an interesting product applepay plus in a card. just add bitcoin - (BIP: 70)?

http://thenextweb.com/apps/2014/10/07/plastc-one-payment-card/ check out the video, looks like you can program the NFC its also powered with wireless inductive charging.

[unamis76]

After the crossroad, where is this at? Is this being developed further? Did any wallet commit to support sigsafe?

I think this is a great idea that should become mainstream...