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

I've wanted to post some tangential developments on related projects but I can't now because alcohol has the better of me.

But I still went WTF when I saw this : NFC Bitcoin wallet implant

Who needs a key ring?

Thank you again for your offer to help with this project! 

I wanted to move quickly forward with the alpha models--and since the design was already complete--I went with exactly what I had.  I did an initial spin of 10 PCBs (that were delivered yesterday).  This will allow me to migrate my firmware to the "real hardware" sooner.  My colleague (who produced the Sigsafe renderings) is a consultant for Tinkerine (3-D printer manufacturer in Vancouver), so he has a bunch of equipment in his basement, and we've been using that to experiment with the Sigsafe enclosures.

I intend to take you up on your offer for help and I am very much looking forward to meeting you.  My critical path right now is to confirm that the Gerber files are correct for the boards we just produced, and then to take a first stab at documenting the communication APDUs.  Thank you again, and I'll get in touch with you by PM shortly...

3-D printing is no longer limited to low-quality plastics.  For example, with direct metal laser sintering, it's possible to produce decent metal parts that would be suitable for low-quality gears.  Remember, this is a plastic gear for a coffee maker that we're talking about replacing--not a steel helical gear for a vehicle transmission.  Also, and although it's not 3-D printing, there are services like Protomold's "First Cut" that CNC machine your part based on your STL files out of the material of your specification--entirely automated.

Like Adrian pointed out, the point that the design is open and that an experienced individual can choose to fix the problem using the technique he deems most suitable (3D print metal + enamel coating, CNC machine from delrin, or just get by for another few months with a 3D plastic gear) is the bigger picture here I think.  

@2112 I appreciate bringing attention to some of pitfalls of product development. I can't agree more that many overlook the what may be the basics for some. On the topic of 3D printing I can't but wonder if I am as ignorant of economics as Joe Blog is of 3D printing, I think we are nearing peek 3D printing.

I am no strange to product design and development with over 25 years of experience in the industry. It appears Peter is still in early concept development stages. I believe Peter will have access to experienced talent and advisers through this project.

I take it you're excited about the product and keen to see it succeeded, me too.

You could produce a single gear that would work temporarily in an emergency. But replacing a single gear in a gear transmission causes radically faster wear of the both gears. So the failures cascade. This is the reason why the "gear drives" are sold as "matching sets".

From school days I remember workshop making a replacement gears from the obsolete soft plastic called "textolite" and replacing this "waste" gear frequently just so they can save the other gear, of much higher diameter, which they couldn't produce using available tools.

Anyway, if you guys don't have a genuine mechanical engineer involved in the project, then don't use the crutch of 3D printing. I understand that you aren't working on a "gear" but on a small, pocketable, (or purse-able, if there are any women using Bitcoin) "widget".

See if you could fit your electronics in a known, sturdy, small package, like a NIVEA creme 1oz tins: "classic" for a shielding metal case and "soft" for the EMF-transparent plastic case. Those things are nothing fancy, they may even look ridiculous, unless you call them "camouflage case" or "steganographic case".

Since this is mostly a software & electronic thread, I'm going to make another comparison: 3D printing is to mechanical engineering like Microsoft Visual Basic (classic, not .NET) is to software engineering. You can slap something together that may be able to impress inexperienced people. But you are highly unlikely to produce something durable. And you may push your overall project to a near failure (like Trezor) with endless delays and cost overruns. I tried to convince slush and stick in their thread to avoid trying to get fancy and trendy, you could search their thread for "eyelet". They didn't listen. Maybe someone here will listen.

@2112 I run a 3D printing bureau, while I agree with your sentiment generally you are correct but SLS nylon printing would render a functional replacement gear for under $100, and for a similar cost we could CNC one from acetal, still cheaper than replacing the drive unit limited by today's tech and economics of scale.

But the fact the design is not open is the problem.

Peter is moving in the correct direction his idea is consistent with Chris Anderson's Free ideas. Peter just needs time to lock on to the value proposition, then everything can be open.

I just quoted this for posterity: height of a naiveté about 3D printing a "plastic gear". Yeah, you could print it and it would probably last couple of days as a replacement for a properly molded/machined gear. 3D printed stuff is most often about order of magnitude weaker than the part manufactured using classic methods. Geared transmissions are the prime example of that problem.

I understand that this is a side-argument to the primary of "open source" or "blueprints available" argument.

But with the introduction of 3D printing you've seriously weakened your reasoning and completely messed up your cost comparison.

Basically I'm typing this in in this thread to highlight that references to 3D printing usually mean that the proponent has no idea what he's doing and the effort will be delayed and over budget. For a recent example hop over to the Trezor thread. They 3D printed a prototype that is very expensive/nearly impossible to properly manufacture by injection molding and other conventional methods. It was basically painting a bulls-eye on themselves that says: vendor, rip me off, I'm out of my engineering expertise area and easily fall for bullshit sales techniques.

I think you touched on two interesting topics here: the importance of trust in our future decentralized economy, and the inevitability of open designs.  Both topics deserve thoughtful essays, but I'll just talk about "open designs" right now.  I'll start with an anecdote:

======
I have a fancy Miele espresso maker. The kind that is permanently mounted in a cabinet, has water lines, grinds beans fresh for each cup, etc.  Anyways, it broke one day and I called Miele to fix it for me.  

The women on the other end said, "Our service technicians aren't very familiar with those machines so we can't guarantee that they'd be able to fix it."  

I said, "But you'll still charge me for the service call anyways, right?"

She said, "Yup."  

I said, "Give me the straight goods, do you think your guy will fix it?"

She said, "…..……probably not."

I took the machine apart and eventually identified the little plastic gear that was broken.  But I couldn't buy just that gear--I had to buy an entire "motor drive unit" for $450. Anyways, I got it working, but if you look at the time I spent plus the cost of the unnecessary parts, this little plastic gear ended up taking about $1,000 of energy to fix!  
======

Now imagine if this design was fully open.  I wouldn't even call Miele.  I would call my local "fixer guy," he'd take the machine apart, identify what was broken by cross-referencing the exploded-view engineering drawings, go online to download the STL file, print it on his 3-D printer, and install it for me.  This would give someone local a job, save me a huge amount of money and time (instead of spending a day fixing a coffee maker I can work on bitcoin), and reduce the impact on the environment (we would only print the part we needed--not the entire "brew drive unit").  

If we look at the whole world as a single system, then I think it is obvious that open-designs lead to better allocation of resources the closed designs.  So society, at least in aggregate, seems to come out ahead with open-designs.  The question is how do we get here in a way that investors who pay for development can still recoup their investments and earn a profit for the risk they took.  I have several ideas (many related to trust like you point out, as well as leveraging network effects) that I'll save for a future post.

Trust is a valuable asset IMO. Even when two devices conform to the same standards, and pass all the same tests, whose device would you pick if it was a choice between a dominant corporate vendor and a smaller independent vendor? I'd go with the smaller independent. The majority would trust the dominant corporation, but I think we need to move away from that culture.

Another aspect when considering the trust factor is the progress in 3D printing. It would surprise me if it weren't possible for a user to assemble their own hardware-based crypto key device by the end of this decade (that's probably too conservative). It would be more expensive to do compared to a mass produced device, especially when you add in the time it takes to research the project and any failed attempts. But personally, I'll be doing just that once the cost becomes low enough, hardware wallet would be a very desirable use of home-fab technology that could handle it.

So, to look at it another way, where's your revenue coming from once literally all you can sell is open designs?

The communication protocol will certainly be open.  I've been talking with other people working on related projects and there is a definite interest to create some sort of "industry standard" OpenNFC bitcoin interface protocol.  The idea is that a NFC reader at a brick-and-mortar store could send a payment request to a Sigsafe tag or to an Android phone using the exact same protocol.  And then the Android phone could turn around and act as the reader and request a payment from another phone or from a tag like Sigsafe!  Various levels or security can be enabled by authenticating the reader or the tag (or both) using cryptographic techniques.  Lots of interesting stuff becomes possible...

Hopefully we can make some serious progress on the OpenNFC interface starting mid August - October.  I'd like to work towards a standard set of APDU commands structured according to ISO/IEC 7816, as described earlier in this thread.  This way, the application layer for our protocol would be the same as that used by traditional contact and contactless smart cards.

Regarding the design itself, it is not completely clear yet what aspects will be open and what aspects will be closed.  This really becomes a business decision and one I can't make without consultation to (current and potential) stakeholders.  In general with bitcoin, I think you want to make a design open enough so that people are free to take what you've done and apply it in ways that you never thought of--so they need an open platform to do that.  But there still needs to be some mechanism that cements your business as one that remains needed (providing a useful product or service).  What is critical is that people trust you and your business, and that you have some provable reason for why they should trust you.  Fully open designs are one method, but partially closed designs where the closed portion is auditable by running unit tests is probably another.  The "proof-of-intent" bond I described in the white paper is potentially useful here too, as it allows a device manufacturer to place his funds at risk on the same device used by the customer.  

What's helpful about Sigsafe when it comes to bitcoin security is that it is only one side of the bitcoin-transaction equation.  Since it doesn't assemble the bitcoin TX, and it is not physically capable of broadcasting a TX, there is no method that rouge firmware could steal a users coins.  The most significant firmware risk is a faulty k-value during ECDSA operations.  But since Sigsafe uses deterministic signatures, this behaviour is fully auditable, whether the firmware is open-source of closed source.    

But this all does bring up interesting questions: how should bitcoin businesses earn a profit?  What is the best balance between "open-enough" to allow people to build upon your work, and "closed-enough" to (hopefully) retain some sort of advantage for your efforts?  

Looks like some interesting kit.

So all open source? Which license?

Solid.  If due to the limits of the architecture you didn't get RFC6979 implemented I personally would still prefer a simple deterministic function like k=SHA256(key|mdigest) over the open ended risk of a random k.  Using a random k in my opinion is just bad practice and that goes beyond just Bitcoin specific uses (just ask Sony).

Yes, I was just walking through the process for posterity.  


Yes, this is my intention, I just haven't got that far yet.  Presently, I am determining k by applying sha256 to the privkey concatenated with the message digest, simply because I haven't got the HMAC hash function working yet.

The micro I'm presently using has 16-bit "ints" and so far all of the open-source C code I've integrated has required some rework in order to get it to work--but that's a topic for another post too.  If I'm not too lazy busy I should make some pull requests to integrate these changes which improve portability (for example for the Trezor Crypto library).  


Yes, I think Test Driven Development is very important with Bitcoin.  One reason I'm making all of my cryptographic primitives accessible via the text (and APDU) interface is so the device can be plugged into a computer and unit tests can be executed over a serial connection.  

I would also recommend supporting RFC6979 (deterministic signatures).  It provides a level of confidence for users (they can verify your device produces the same signature for the same key and message as any other RFC6979 compatible software/device).  This can be important as it is possible for a hardware device to intentionally produce signatures which are valid but are cryptographically weak under certain conditions. The good news is there are some python libraries which have implemented RFC6979 (or at least a Bitcoin specific subset of it). 

If you are a proponent of Test Driven Development, RFC6979 makes unit test verification of signature generation easier.  For a given message digest and private key there is only one correct RFC6979 signature.

I am too lazy busy (yeah that is it) to copy the private key from the screenshot but if you include it in another post I will verify I am getting the same outputs.

This is how it should be.  The wording is unclear so I am not sure if you are just walking through the process or if it seemed unexpected to you.  The Address is the encoded pubKeyHash and the pubkeyhash is different because the pubkeys formats are "different" (although they represent the same value).  As a side note I don't think any wallet supports this but if you have a wallet which has 1,000 uncompressed pubkeys (and thus 1,0000 addresses) with the same raw private key you can generate 1,000 new compressed addresses.


Agreed it is rather poorly documented.  My understand is the 27 is just a "magic number" designed to prevent collision with other prefixes.  It could have just as easily been:
1 = uncompressed & odd
2 = uncompressed & even
3 = compressed & odd
4 = compressed & even

I think I have some notes I saved when I reverse engineered it a while back.  I will see what I can find.


As a side note the distinction of compressed vs uncompressed is a bitcoin specific requirement.  By the ECDSA standard there is only one pubkey for a private key it just can have multiple forms.  The reason why the Bitcoin message signature needs to encode if the key is compressed is because Bitcoin addresses (which are what will be recognized by the user) are the hash of the pubkey not the pubkey.  Also secp256k1 makes it pretty easy there are only two possible y values for a given x value.  Some curves have more (4 or even .  For this reason it really isn't necessary for the even/odd to be encoded.  It can be determined by brute force (if you can call a check even and then check odd to be "brute force").  The encoding of even/odd saves on average 0.5 verifications per signature (at the cost of a marginally larger signature).



That may be a bug in the implementation.  I would point out however the message signing protocol is rather loosely defined (especially the output).  If you take a look at Bitcoin-core for example you must provide the address in the verification screen and it separates out the address, signature, and message.


You're right there is no reason to default to uncompressed keys certainly not in 2014.  I wouldn't say it is something not on their radar,  pointed it out to bc.i more than two years ago.  I just don't think they care enough to make the change.  Obviously uncompressed keys need to still be supported for backwards compatibility but not only should uncompressed keys not be the default it shouldn't even be possible for users to create them (baring some advanced options).  Case in point if you call getnewaddress in Bitcoin core it will always return an address produced from a compressed key.  The only way to add "new" uncompressed keys is to import a private key in WIF format which lacks the IsCompressed flag.  I can't see a reason other than apathy which has prevented developers from switching over.

A good chance to get on my soapbox, developers make it easier for other developers to adopt good practices.  If you are writing a library or tool it should default to compressed keys.

Example (C# - NBitcoin)

"var k = new Key()" produces a compressed key, to create an uncompressed one requires an explicit declaration "var k = new Key(false)".

I've been adding support for compressed pubkeys in order to minimize the size of the transactions produced by Sigsafe and help reduce blockchain bloat.  For example, in the image below, the Sigsafe determines the other bitcoin address for this sha256 hash:



Although the same private key (in byte form) was used, the resulting bitcoin address is now different than the one calculated earlier:

1BNLp3roCQws6SvC53QuYStShFJNWyh7FG  (bitcoin address for compressed form)

1Pq3SXz94SCnQVGxNUqUe7g2sqxjH8g72E  (bitcoin address for uncompressed form)

This affects bitcoin-signed messages too.  The signature for a bitcoin-signed message does not contain the public key, as a key-recovery algorithm is used.  How then does a verifier determine which of the two addresses to verify the signature too?  The answer is that this bit of information gets encoded in the first byte of the signature.  (I should write a more detailed post describing how to manually sign bitcoin messages, as it does not appear to be nearly as well documented as for signing bitcoin transactions themselves.)  It seems that the rule is:

if bitcoin address corresponds to an uncompressed key
    
        then   first_byte_of_sig = 27 + (y%2)

        else   first_byte_of_sig = 31 + (y%2)

where y is the y-coordinate of the curve point k*G found part way through the ECDSA signing operation.  

I didn't read this documented anywhere, however.  I got the "27" from pybtctool and I got the 31 by inspecting the binary data of signatures produced by brainwallet.org for compressed pubkeys.  Nevertheless, here's the signature produced by Sigsafe for a compressed key:



Brainwallet uses the first byte of the signature to know to hash the recovered pubkey in compressed from to the correct address (1BNLp3roCQws6SvC53QuYStShFJNWyh7FG):



Here's what pybtctool says about the same input:


Notices that it recovers the same uncompressed public key for the bitcoin message signed by the key to 1Pq3SXz94SCnQVGxNUqUe7g2sqxjH8g72E as it does for the message signed by the key to 1BNLp3roCQws6SvC53QuYStShFJNWyh7FG.  In my opinion, it should recover the compressed public key in the second case.

I also noticed that the popular web services:
  
   - bitaddress.og
   - brainwallet.org
   - blockchain.info

all default to using uncompressed pubkeys.  Now that I understand the issue more clearly, I think that by default developers should have their software use compressed pubkeys.  I think the reason this is not done now is that it's simply not on many people's radar.  
    

Ah figured it out. 


So to use the priv2pubkey as is you would just need to append a 0x01 to the privatekey.  Maybe this is common for Python but that seems unnecessarily confusing as the private key doesn't actually include the 0x01.  The actual privatekey will still be 32 bytes.

Yes that is all correct (it is a 0x03 prefix because the x value is odd otherwise it would be 0x02).  Although either one will work there is no advantage to using an uncompressed key and it does mean that inputs are ~25% larger when redeeming P2PkH outputs.  It just adds extra space to the blockchain.  If Satoshi had been aware of compressed pubkeys it would have made sense to simply limit all Bitcoin pubkeys to compressed format.


Yea "kinda".  It depends on what format the private key is in.  A private key is just a 256 bit number so as raw hex then yes there are two possible pubkeys.  In WIF format a trailing 0x01 is added to indicate the produced pubkey should be compressed.

So raw bytes = 2 possible pubkeys for every private key
WIF format = 1 possible pubkey based on the presence of the trailing 0x01.


Python really isn't my language I am sure someone can help more but it looks around line 241 that either compressed or uncompressed.  I am not sure what it is expecting for an input however.  The dynamic types in python always make me a little crazy.  Still if you want your device to always produce compressed keys then you could simply remove that switch statement.  Note there is also a function at line 227 which will take an uncompressed pubkey and returned the corresponding compressed pubkey.

Probably because I'm just learning about compressed vs uncompressed now  .  With respect to the bitcoin address I generated above, it looks like I could have hashed the compressed pubkey:

   03b0224956cdd07b883e0ed06837c6f62680be3a1e3b351ed2c3adcd09ff45aecf

and got the bitcoin address:

   1BNLp3roCQws6SvC53QuYStShFJNWyh7FG   (instead of 1Pq3SXz94SCnQVGxNUqUe7g2sqxjH8g72E)

I suppose when I sign the transaction, I would include only the compressed pubkey rather than the full pubkey, and when a node applies "OP_HASH160," it will hash the compressed pubkey resulting in the (non-b58encoded) second address rather than the first.  Do I understand correctly?  There are always two P2PkH addresses for each private key (corresponding to uncompressed and compressed pubkeys)?

I've been somewhat modelling the Sigsafe text-based terminal commands off of Vitalik Buterin's pybtctool (which has come in very handy for me so my respect to Vitalik), yet I don't see a way to generate a compressed pubkey from a privkey with this tool either.  

Very cool.  I see you used an uncompressed PubKey.  Is there any reason you need to use uncompressed keys over compressed ones?  The later would be preferred for blockchain efficiency.