Topic: Sigsafe: A NFC key tag for signing bitcoin transactions - page 5. (Read 23252 times)

Totally Good but i need this Machine is released in Indonesia

so the country will accept the new currency = Bitcoin

How much you estimate for a card,tag,EDC

The Sigsafe communicates with an interface device over NFC using the ISO 7816 APDU command structure for exchanging binary data.  To facilitate debugging and easier integration by developers, I've implemented a serial communication interface that is accessible via the edge connector when the Sigsafe PCB is removed from its enclosure.  This allows the Sigsafe to communicate with a computer over USB (as a virtual COM port).  Over this serial interface, the Sigsafe supports:

   - binary APDU commands
   - HEX encoded APDU commands
   - text-based abstractions of APDU commands

The text-based commands are the easiest to understand, so I'll only cover some of those with this post today.  

For this experiment, I have Sigsafe firmware running on a board (that I designed for a different project) with a 16-bit Texas Instruments microcontroller with 16 kilobytes of RAM.  The first step is to fire-up HyperTerminal (I love how bitcoin makes retro text-based tools cool again).  I typed "?" and the Sigsafe responds with an intro screen (all computed on the microcontroller and simply echoed by Hyperterminal), and then I asked the Sigsafe to hash an insecure brain wallet:




To demonstrate that the Sigsafe can perform the necessary cryptographic operations, let's turn this into a bitcoin address.  The next step is to instruct the Sigsafe to multiply this 256-bit number with the base point G for secp256k1 to determine the corresponding public key.  We do this with the priv2pubkey command.  The "%" symbol tells the Sigsafe to use the last output as the current input.




Next hash the public key with sha256:




And then hash it again with ripemd160:




And lastly apply bitcoin's custom base58check encoding to the resulting hash to get the bitcoin address "1Pq3SXz94SCnQVGxNUqUe7g2sqxjH8g72E."




Now, if a wallet developer wanted to provide support for Sigsafe they wouldn't need to know all those details.  For example, we could have converted the original text string to a bitcoin address in a single step:




Comparing these results to those generated by the site brainwallet.org results in an identical match:





In normal use cases, the Sigsafe wouldn't be hashing or computing brainwallets at all.  It is designed to store private keys and produce signatures.  So let's give that a try.  Today I'll only cover bitcoin-signed messages, as there is a lot to talk about with bitcoin transactions that I'll save for future posts.  

First let's hash our pass phrase again to get the private key into RAM (the Sigsafe can of course also generate random keys internally but that too is a topic for another day).  We then use the "store_key" command to tell the device to burn this key into flash memory.  (Once the key is burned into flash, the Sigsafe will never allow the key to be erased or read in clear-text form again.)  The Sigsafe responds with the key index (which is 1 since this is the first key we've loaded):  




Next we ask the device to produce a bitcoin signed message of a certain string using Key #1:




Verifying this signature at brainwallet.org shows that it was indeed produced with the private key associated with bitcoin address 1Pq3SXz94SCnQVGxNUqUe7g2sqxjH8g72E.





A bitcoin-signed message via a text-based terminal prompt all running on a $2 processor using less than 16K of RAM.  In later posts I'll cover APDU commands in more detail, bitcoin transaction signing, and Sigsafe signing rules.

Yes, then you will hear phrases like, "too good to be true" and write-off the whole thing.

So hard to pick a good coins / coin services sometimes. The people want to offer you everything. But soon a coin will come that does, and everyone will be scared of it!

Its a scary world out there. considering the number of scams out there, people would at times suspect the legitimacy of a completely genuine project. But lets hope this project indeed does what it says it will. and i will most certainly be interested in getting my hands on its tech.

Unfortunately, there is no mainstream browser support for webNFC yet.  It is in "draft" stage at the World Wide Web Consortium.  Mozilla seems to have made some progress for Firefox OS (mobile only), and it appears possible to interact with an NFC reader with a Chrome app.  Of course, you can interact directly with an NFC device using a custom program or Android app too.   

Here's a brief update: http://www.programmableweb.com/news/w3c-launches-draft-nfc-api/interview/2014/02/06

The last reference I made to kickstarter in this thread turned out to be a scam, this one looks more credible, and offers a back end solution.

This looks like a very good product.
The potential are unlimited.
This system has the potential to replace the existing card system.

and with news that MasterCard recently filed for a patent related for bitcoin incorporation into its existing payment system, this product will be something to lookout for.

also, as adrian-x mentioned, this will really help people who have fallen prey to scams.

I would really love to take a try at this device, and maybe even try the NFC HTML5 api to push the potential of this gadget.

this looks really good! Is there an ETA for this? 

an NFC kickstarter project with a little more Credibility some what related.

https://www.kickstarter.com/projects/donatien-garnier/micronfcboard-easy-nfc-for-the-internet-of-things

And here I was thinking wow this power tech is quit advanced, thinking they had a demonstrable functioning prototype.
my bad I should have looked into it a little more and always remember stay critical.

@D&T I lol,ed at the $999 option it's worth the investment if you've fallen victim to a scam before.

Damn limitations of the physical universe.  It does point out what makes a "good" scam good.  Take an idea that is loosely based in reality that is only invalid due to scale.  Everyone knows RF signals have "some" energy so the idea of a widget powered by RF signals is more plausible than one powered by a microscopic fusion core.

Still best response to the thread

looks too good to be true it is too good to be true.

the energy source powering the referenced device above is pure fantasy apparently.

http://mobile.slashdot.org/story/14/06/23/2357200/500k-energy-harvesting-kickstarter-scam-unfolding-right-now

Yes, this product is in active development.  We hope to have alpha models produced towards the end of the summer.  These units will be made available to partner developers, as well as used for FIPS 140-2 cryptographic module compliance testing in the early fall.  We intend to be in open beta (selling to the bitcoin community) by early 2015, assuming there's demand to move forward. 

That being said, I have little control over support from interface devices such as Bitcoin wallets and point-of-sales terminals.  I expect that some wallet support will be ready, but I think meaningful support by point-of-sales equipment is still a ways off (and even that statement is assuming the idea of rule-based bitcoin signing tags for brick-and-mortar purchases is accepted).  I would be keen to partner with someone in the point-of-sales equipment business interested in integrating bitcoin payments (no hardware changes required!).  

it is a really interesting concept
do you have a plan to make it?
is there any approx date?

You really should be talking to asciilifeform and the others on irc http://bitcoin-assets.com/

I think the "chicken and egg" problem will apply most acutely to integration at brick-and-mortar PoS terminals.

But bitcoin has taught me the value of a network.  Things like Gavin's Payment Protocol (BIP70) and Lawrence Nahum's extension for instant confirmations via green-addresses are important in reinforcing this network effect.  If a spec is simple, clear, flexible and robust, and if community members feel they've had some input, then people will just begin to adopt it.  It's the easiest way to move forward.  

For this reason, I'm trying to think of Sigsafe as just one realization of a larger class of devices that could share a common communication interface and function, as well as be compatible with equipment already widely deployed.    

From my research, I've learned that Android phones with NFC, contactless PoS terminals, and the majority of new RFID readers adhere to ISO/IEC 14443.  This means they share a common radio frequency, power and signal interface (14443-2), initialization and anti-collision schemes (14443-3) and a common transmission protocol (14443-4).  So bitcoin signing tags and smartcards that adhere up to ISO 14443-4 will automatically be hardware compatible.  

Communication with both contact and contactless smartcards is consistent up to the application layer using the application protocol data unit (APDU) specification from ISO/IEC 7816.  What this means is that bitcoin signing devices with firmware the supports APDU commands will be largely software compatible up to the application layer.  

I think if we can achieve this and make everything clear and easy, first we will see bitcoin wallets begin to interface with devices like sigsafe.  And then if another company can build a different version of a bitcoin signing tag knowing how to make their device compatible with existing wallets, then they will be incentivized to do so, especially if the profit margins are good.  Next thing you know and perhaps a lot of people will have these devices from 3 different manufacturers that all share a compatible interface.  

Then an innovator will hack an Android phone or tablet to accept "tap-and-pay" NFC payments at his store.  This will begin to catch on--but people will complain about security: "I'm not touching my bitcoin tag to that hack!"  When investors with deeper pockets begin to notice the opportunity, they'll be pleasantly surprised to learn that it just requires some software updates and an entire line-up of PoS terminal can suddenly accept bitcoin.  In fact, the existing spec already allows for two-way authentication to quell the fears of stollen coins.  

Or at least that's one way it could happen  Perhaps people will decided that they don't like the idea, or perhaps some big company will lock it down in a proprietary and closed format.  Time will tell.  This project started out as an excuse for me to learn about the protocol, so whatever happens I've already learned a lot.  

Looks cool~

I guess the big question now is, when will the early devices be seen? Prototypes, CE and industry show appearances and/or demos? There are hints about the future in this post:


There is more of a chicken and egg situation with these devices than with the technological angle that other hardware wallet designers have come up with, but I am reminded of what French supermarket Monoprix implied when they announced web-only bitcoin support later this year (which was that the technology for in-person bitcoin payments wasn't as usable as the online solutions). Sigsafe is a candidate to bridge that gap, as it seems that all a retailer needs is a PoS reader and till that supports the device, and a software upgrade both at the outlet level and for their finance department.

Here's a recent story about this project on Coindesk: http://www.coindesk.com/sigsafe-key-tag-brings-bitcoin-payments-nfc-devices/