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

Thanks for the informative reply. So address reuse cannot expose the random number generator scheme of the machine. It is a problem when k is reused but a  sequence of k's generated cannot give any info about the random generation algorithm so other private keys generated by the machine are safe.

Also multiple time signing with different k's does not weaken ECDSA right? For example reducing the search space.

Is the 1st or 2nd a problem for sigsafe? Isnt it using just 1 address?

Whenever a signature is created, it becomes possible to expose the public key. Normally bitcoin public keys are hashed before creating an address, protecting them with ECDSA, and hashing for privacy. But if the address is reused, signatures will expose the public key, meaning you wallet is only protected with ECDSA. Bitcoin assumes ECDSA is safe to use, ie, you cannot go from public key to private key..

There are issues when you create a signature in ECDSA - it requires a random number, k & a hash of the transaction. The algorithm computes a number r from k, and computes the signature s, and returns (r, s). If you have two signatures, from the same private key, and the same r (aka, k), you can use algebra to solve for the private key.

This can be avoided by using deterministic k values in signatures though, so that they never sign with the same k.


The first is your least concern anyway! The second shouldn't be a problem, but the android wallet vulnerability has shown people need to draw from high entropy randomness, otherwise the keys just aren't strong enough. Someone else may eventually find one. I quite like the deterministic scheme, it goes a good job of preventing the second. 

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

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.

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.

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.  

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.

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.

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



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?)

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.  

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.

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

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

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.

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

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

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

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.

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


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.  


Potentially yes.  These trackers are pretty interesting.  


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.

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.