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

Sigsafe support for BIP32 hierarchal deterministic keychains

I think I worked out a fairly simple way for a Bitcoin Signing Class device like the sigsafe to support BIP32 address chains.  It just requires adding one additional optional argument to the "SignRawTransaction" APDU command.  First, let's take a look at BIP32.

Why would BIP32 be useful for sigsafe?

The BIP32 spec was originally published (2012-02-11) by Pieter Wuille.  It describes a method to create hierarchal deterministic (HD) keychains and wallets that "can be shared partially or entirely with different systems, each with or without the ability to spend coins."

Here's an example of how an HD keychain would be useful for a Bitcoin Signing Class device like the sigsafe:

Imagine that a bitcoin user at a brick-and-mortar coffee shop wants to pay for a latte with his sigsafe but doesn't want to use the same bitcoin address over and over (for privacy reasons).  When the point-of-sales (PoS) terminal issues the "GetInfo" APDU command, instead of returning a single bitcoin "spend address," the sigsafe could return an "public keychain" for spending.  What is amazing about HD wallets is that with knowledge of the public keychain, the PoS terminal can figure out what bitcoin addresses the sigsafe can spend from (i.e., what addresses the sigsafe can calculate the private key for) without any sort of security breach.  The PoS terminal would scan for unspent outputs across the keychain domain¹ and construct a transaction that spends the amount owing for the coffee to the merchant's address, returning change to a different bitcoin address in the same keychain.  The PoS terminal would send this raw transaction to the sigsafe using "SignRawTransaction"--with one additional detail that I'll get to later.  Provided none of the signing rules are violated, the sigsafe would produce the required ECDSA signatures, return the signed transaction to the PoS terminal, and the PoS terminal would broadcast to TX to the network to complete the transaction.  

What does a BIP32 keychain look like?

A bitcoin keypair consists of a private key, d, and a public key, Q.  The public key can be determined from the private key using the equation

     Q = d G

where G is the (x,y)-coordinates of a special point on the secp256k1 elliptic curve known as the "base point."  Also note that elliptic curve multiplication is of course implied rather than regular vector multiplication.  To sign a bitcoin transaction, knowledge of d is required, but to verify the signature only knowledge of Q is required.  There is no feasible way to calculate d from Q.

In BIP32, instead of ECDSA public and private keys, we need to think in terms of public and private extended keys or "keychains".  (Note that I am now deviating from Pieter Wuille's notation, in an effort to be consistent with the NSA's FIPS 186-3, and IMO also abstract the notation in a useful way.)

   public keychain :  Q = (Q_parent, c)

   private keychain : d = (d_parent, c)

The parameter c is called the "chain code," is constant for a given keychain, and is 256-bits long.  I like to think of Q and d as vectors such that the ith element is the ith child key for that chain.  So Q₄ means the the child ECDSA public key at index four, and d₇ means the child ECDSA private key at index seven.  The BIP32 spec describes how to calculate Q_i as a function of (Q_parent, c, i) and how to calculate d_i as a function of (d_parent, c, i).

The magic of BIP32 is that (for some reason that I don't yet understand )

   Q_i = d_i G.

This is very significant because it means that an external device can calculate the public keys for a given keychain without gaining knowledge of the corresponding private keys!

Sigsafe support

A given keychain has 2^32 child keys and neither the sigsafe nor a point-of-sales terminal have a reliable way of knowing at which index unspent outputs might be lying.  It would not be practical for a PoS terminal to scan 2^32 bitcoin addresses to look for spare coins!  

My idea (and I'm not completely happy with it) is to use signing rules to limit the range of the child index between 0 and N-1, where N can be no smaller than 2^8 = 256  (but could be specified as greater than 256 by the GetInfo packet).  The sigsafe would only sign transaction that return change to indices less than N but could still spend outputs at higher indexes.  The interface device would know to look for unspent outputs between 0 and 255, but could optionally look for inputs outside of this range.  It would just need to make sure that when it contructs the raw transaction, that all outputs are returned to an index within the domain.  

The next issue, is that the sigsafe doesn't have a lot of computational power.  If it was given a raw transaction that spends outputs on its keychain, it would still take it a long time (even with N=255) to figure out what private keys it needs to produce a valid signature.  For this reason, I think the interface device should use an optional argument with "SignRawTransaction" to specify the keychain and index that any inputs or outputs in the raw transaction are controlled by or sent to.  This way, the sigsafe can create the needed ECDSA keypairs at run-time, sign the transaction if authorized, and then forget that it ever happened.  


TL/DR: I think we just need to add a P2=FF option to the SignRawTransaction APDU to specify the keychains and indices used by the TX:


    
¹A reduced domain compared to the 2^32 possible child keys.

Yes, by configuring the appropriate signing rules this is already possible.  What you want to do is configure a key (or keychain) in the sigsafe that does not lock the spend address, but does require authentication from the Android wallet.  This way the Android wallet can construct a raw transaction that spends from this key (or keychain) to, e.g., your friend, pass the transaction to the sigfsafe for signing, and then broadcast the signed transaction to the network.  

At an abstract level, the sigsafe is a device that stores keys (or keychains) and sign transaction request provided none of the signing rules set up for that particular key (or keychain) are violated.  

For example, a single sigsafe device could be configured with

  - a low-security key (or keychain) that signs any transaction (perhaps with a per-transaction spend limit of 0.05 BTC and a daily spend-limit of 0.1 BTC).
  - a medium-security key (or keychain) that signs any transaction provided the interface device making the request successfully authenticates itself
  - a high-secuity key (or keychain) the only signs transactions that spend funds to a white-listed address (such as a pre-defined hot wallet).  

The two example application I gave earlier where just things that could be created by configuring signing rules in certain ways.  I was thinking that non-technical users could just buy sigsafes already setup specifically for their desired use case (e.g., hot/cold wallet system, or daily-spending tag) so that the sigsafes would work securely right out of the box and without risk of the user "forgetting to setup the signing rules."  So that's why I gave the two specific examples, but a lot more is actually already possible.  Here are the sigsafe signing rules so far (from sigsafe.pdf).  Each of these rules can be applied separately to each key (or keychain) stored in the device:

Locking the spend address.  Requests are only signed if the transaction moves funds to a white-listed address, such as the hot address of a cold/hot wallet system. If a thief gained physical access to the tag, he would only be able to move funds into the owner’s hot wallet. It is unlikely that a thief in possession of the tag would simultaneously be in  possession of the hot wallet’s private key.

Setting a transaction-based spend limit.  Transaction requests seeking authorization for amounts greater than a user-defined spending limit will not be signed. To prevent a malicious host device from draining the balance with several small transactions in quick succession, the tag will run its clock for a short amount of time after producing a signature, ignoring new signature requests. Since the energy harvested from the NFC field during signing is sufficient to run the microcontroller for several seconds after the field is disabled, the backup battery is not required to implement this signing rule.

Setting a time-based spend limit.  When this signing rule is enabled, the tag runs its clock as required when in sleep mode, enabling it to tabulate the amount of bitcoins spent each hour, day, or week and disallow transactions if certain limits are exceeded. Use of time-based signing rules may significantly decrease battery life.

Implementing password protection.  The user can specify a password for the tag. The host must include this password when making a request or the transaction will not be signed. For example, a phone-based bitcoin wallet would prompt the user for their  password and append this to the request being made. To deter brute-forcing of simple  passwords (e.g., 4-digits), the required delay between signing requests increases with the number of failed password attempts.

Requiring cryptographic authentication.  The host device must sign a random nonce generated by the tag. The tag checks the signature from the host, and, unless the signature verifies to a trusted address, the transaction request will not be signed. For example, the tag could trust certain brands of PoS terminals deployed throughout brick-and-mortar stores.

Producing only bitcoin-signed messages.  The tag will only produce bitcoin-signed messages for private keys that have this option set.

Your previous descriptions suggested something different, e.g. : "implementing a cold/hot wallet system where the cold wallet can only send coins to the hot wallet" "this image shows the sigsafe about to sign a transaction (over NFC) that presumably sends 1.66 BTC to the Android hot wallet"

This tells me the Sigsafe is receiving a request to generate a signed tx for an amount to an address, sending it to the Android device, broadcast from the Android device, and then spent from the wallet on the Android device once it confirms. Whereas it is perhaps better described as a separation of two aspects of the wallet; the address chains stored on the broadcast device and then the spending keys (as well as the address chains, really) stored on the Sigsafe. So no actual transfer between a wallet on the Sigsafe and a wallet on the broadcast device takes place.

DRAFT APDU commands: GetInfo, SignRawTransaction and Authenticate

Updated June 11, 2014 for better BIP32 support and to allow proprietary interpretations of standard BSC APDU commands.

The first APDU command-response pairs that I'd like to propose for our Bitcoin Signing Class devices (BSCs) are "getinfo," "signrawtransaction," and "authenticate."  I am imagining that getinfo is a flexible command that an interface device could use to learn about the specifics of any BSC device, while I am imagining that "signrawtransaction" is essentially the same as its bitcoin RPC namesake.  Authenticate is a command used to unlock the BSC with a password or to cryptographically authenticate the interface device.  The following post is a very rough and incomplete draft!

GetInfo

I'd like to define a very basic but still generally useful "get info" command (we can later use P1 and P2 to get more complete information from the BSC). The interface device would include an ECDSA public key in its command packet, or optionally sets these bytes to all zeroes. The purpose of transmitting a public key to the BSC is that it can be used to set-up a shared-secret using the elliptic curve Diffie-Hellman technique. The shared secret could later allow for password transmission between the interface device and the BSC in cyphertext (e.g., using the shared secret for xor encryption). This is the method the sigsafe uses to exchange password information with a PoS terminal or an Android Wallet to defend against man-in-the-middle attacks.


The response to this command can be somewhat device dependent, but I think in all cases the device should respond in turn with an ECDSA public key (or set those bytes to zero).  In addition to completing the Diffie-Hellman exchange, this public key can be thought of as "Key0" for the BSC, and something like a unique identifier.  If the BSC could freely produce bitcoin-signed messages with the associated private key for "Key0", then the BSC immediately becomes a general purpose authentication device.  For example, the BSC could be scanned at a grocery store and the public key input into the store's reward program.  The grocery store terminal could ask the BSC to produce a bitcoin-signed message of some random string for authentication purposes each time the user shops at the store.  But the same BSC could be used to unlock the doors to one's home or to login to Gmail in the future, for the "username/password" problem is now eliminated.    


BSC devices with different requirements could define their own BSC types.  To implement Sigsafe V1, the only additional information the interface device requires (whether that device is a PoS terminal or the user's trusted wallet) is a default spend keychain and a random nonce.



SignRawTransaction

I can't think of any case where a BSC shouldn't support the command "signrawtransaction."  Of course the BSC can choose not to sign the transaction unless specific conditions are met, but I think ideas where the device signs arbitrary hashes of binary data or just releases private keys are too insecure.  If the device can't parse and sign raw bitcoin transactions, then I don't think it qualifies as a BSC device.  Here is the description of the JSON-RPC API version of signrawtransaction:


Because RAM may be very limited on a device like the sigsafe, but it still might be necessary to check parent transactions, I propose that the arguments of signrawtranscation be transmitted as separate APDU pairs (but using a common instruction code).  I further propose that array arguments such as the parent transactions be sent one by one.  The command would "execute" when the raw transaction is loaded (when P2 = 00).  The transaction would either get signed and sent back in the response data, or the command would fail and an error code would be returned encoded in SW1 and SW2.


The response data (for P2=00) will typically be the fully- or partially-signed transaction or an error code if something went wrong.  I wrote up a big long table for various responses and error codes, but I didn't include it because it is probably too much detail for this stage of the discussion.  


Authenticate

I'm getting sleepy, but I want to hit "post" before I retire for the evening.  Here is a very rough version of the APDU for "authenticate."  The idea is that the interface device would successfully authenticate itself (if required) in order for "signrawtransaction" to complete successfully.



A device like sigsafe could be used at PoS terminals that support only "signrawtransaction" and "getinfo" (and "authenticate" depending on security settings).  The terminal would read the default "spend" public keychain using getinfo (and authenticate itself or the user if required).  The PoS terminal would look for unspent outputs associated with this keychain, and assemble a transaction that spends the amount owing to the vendor, returning change to another address on the keychain.  The PoS terminal would then transmit that raw transaction to the sigsafe (along with parent transactions when necessary and the keychain indices used) using "signrawtransaction."  The sigsafe would sign the transaction provided none of its signing rules were violated.  The PoS terminal would then broadcast the transaction to the bitcoin network to complete the transaction.  


Note that these APDUs would be applicable to contactless technology such as the sigsafe keytag, but also to devices formatted as contact smart cards, like the hypothetical device shown below (that I don't plan on manufacturing at this point in time):



The obstacle to doing this (with the current electronic design) is either living with a "bump" about 1mm in height where the processor and NFC IC are located, or investing additional resources to produce an electronic design perhaps using wafer-level chip-scale packaging such that sigsafe electronics and plastic package fits within the 0.8mm thickness of a typical smartcard.

Bitcoin Signing Class (BSC) device APDUs

Communication with a sigsafe-compatible device is carried out using smartcard application protocol data units (APDUs).   The structure of the APDU is defined by ISO/IEC 7816 (see here too).  The benefit of using a well-known standard is the ease with which software that already supports ISO/IEC 7816 can be adapted to support bitcoin payments using a standard Bitcoin APDU library.  For example, both contact (chip & pin) and contactless (NFC) smartcards used as traditional debit and credit cards employ ISO/IEC 7816.  This means that software for existing point-of-sales equipment can be modified, possibly no deeper than the application layer, to support connectivity with sigsafe-compatible devices.  

What is an APDU?

Smartcard APDUs represent the application layer for communication between an interface device and a card.  This is Level 7 of the abstraction layers defined by the OSI model.  An "interface device" could be an Android phone, a point-of-sales terminal, a USB RFID reader, or some new piece of hardware that hasn't been invented yet.

All APDUs consist of a command-reponse pair.  The command is issued by the "interface device" and the response is sent by the "card."  The byte-level data for a typical APDU exchange might look like this:


Now let's dissect this example.  The format for all APDU commands is:


"CLA" is the "instruction class."  For our example, it was the byte B0.  B0 could be the instruction class used to identify all Bitcoin Smartcard APDUs (certain instruction classes are already defined by ISO/IEC 7816 but B0 is not one of them--I'll discuss these details in another post).  

"INS" is the "instruction code."  For our example, it was the byte 13.  Devices in our Bitcoin Signing Class (CLA = B0) should know what "13" means.  

"P1" and "P2" are arguments that can be added to the command.  In our example they are both zero and have no meaning.  

"Lc" is a variable number of bytes that encode how much data the interface device will include in the "command data" section.  This part is a bit tricky, but in our example it's easy: Lc is 1 byte long and is equal to 05.  This means that the next 5 bytes are the command data.  

"command data" is a variable amount of bytes that get sent to the card to complete the instruction.  In our example, it is the 5 bytes "48 65 6C 6C 6F".  If you have your ASCII character codes memorized, you'll recognize that this spells "Hello".  

"Le" is a variable number of bytes that encode the maximum amount of data (Ne) that the card is permitted to send back to the interface device.  In our example, it is the byte FF, meaning that the card can send back up to 255 bytes of data.  (There are ways to allow up to 65535 bytes of data, that I'll explain in another post).  


Now on to the response.  The format of all APDU responses is:


"response data" is a variable amount of data that can be no longer than Ne (the amount of bytes permitted by the interface device).  It is always 2 bytes less than the size of the reponse packet.  In our example it is the bytes "47 6F 6F 64 62 79 65" which encode the ASCII text "Goodbye".  

"SW1" and "SW2" make up the response trailer.  These bytes are used to indicate the command processing status.  The bytes "90 00" used in our example indicate success.  


This concludes the example of a simple data exchange between a Bitcoin Signing Class device and an interface device using ISO/IEC 7816 smartcard APDUs.  Next post we'll try to come up with some instruction codes that are actually useful for bitcoin transactions  

I apologize.  I think I misunderstood your first post.

I think what you proposed here is exactly what the sigsafe is designed to do.  It receives an unsigned transaction from any device, signs it provided doing so doesn't violate any of its signing rules, and returns the signed transaction.  Basically, it's like signrawtransaction subject to additional (user-defined) constraints applied on a privatekey-by-privatekey basis.

Does that make sense?

My idea assumes the RFID is capable to receive an unsigned transaction from the mobile device holding the keychain, which signs and returns the transaction to be broadcast either by the mobile device itself or even back to the POS for broadcast (maybe a little too clunky the latter way). I'm not familiar with the specific capabilities of the communication standard your RFID device uses, but in any event I think this could be a good use of a future standard if this is not possible with what we have today (I agree that sharing the private key with the mobile device would be a poorer model in comparison to your lower security mode, little different to using most mobile wallets available now)

Yes, but not right away.  First I'd like to get the sigsafe working well as a paper wallet that can also sign approved transactions--something more for high-security than for day-to-day spending.  

Then when some progress has been made on the brick-and-mortar PoS front, I'd be more inclined to work out the details for hierarchal deterministic address chains (I've spent some time on this problem, but there are some nuances that I need to think about in more detail).

(It looks like this will be easier than I initially imagined.) 


Let me make sure I'm following: is your idea is to transfer a keychain from the sigsafe to an approved broadcast device so that the broadcast device can immediately spend?  

Hypothetically, the sigsafe could create a new class of keychains that grants read permissions to any broadcast device that is able to sign the sigsafe nonce with a valid unlock key.  But this would seem to affect my security model.  Right now, there is only one class of private key and it is neither erasable nor readable.  I did this for two reasons:

1.  I can be confident that the user won't accidentally erase his keys or leak them to an attacker.

2.  The manufacturer can load his own private key as a "proof of intent" bond with the signing rules set to "produce bitcoin-signed messages only."  

A new keychain class could be created (and I'll have to do this anyways to implement HD wallets) but I am still uncertain whether it's a good idea to grant read-access to the keychains (even after the broadcast device has been authenticated).  

Here's an example of how a manufacturer could potentially get a bad reputation: he sells 100,000 sigsafe devices to a malicious reseller who sets up the devices to release the keys if the nonce is signed by his private key.  Since the device is NFC, this can probably be done without even taking the device out of the packaging.  But I think most users will just use the device as it comes out of the box, trusting the manufacturer who's worked hard to build his reputation, but now suddenly there is a bit of a security breach.  There's 100,000 sigsafe devices that the distributor could scan to extract the default key chains.  Perhaps he slowly collects keychains until there's a huge amount of funds accessible, and he steals them all at once.  

I just made up this ^^ example now, so perhaps it's flawed.  But the point is that we'd have to be careful that we're not opening up an attack vector without realizing it.  Probably the best idea is to have "consumer grade" devices that are extremely simple and with easily-understandable security assumptions.  And then allow advanced users to just do whatever they want using hardware with slightly different firmware (e.g., the "advanced" firmware might not be loaded with the manufacturer's proof-of-intent bond, so it would appear like a counterfeit device by default).

TL/DR:  I think that the standard consumer-grade device should have as few "features" as possible.  

Will you use one of the (now proliferating) BIP32 wallet structures? (I would assume yes)

If so, it would be cool to have a third operating mode (kind of intermediately secure): you could have a keychain derived from the private key from the Sigsafe stored in a phone wallet app or on a laptop. It would save the time of waiting for transfer confirmation to approved devices (which can occasionally take too long for some uses). And you'd still be well protected from a malign POS reader trying to extract private keys from the device RAM. It could be considered a safe way to spend from a valuable wallet if in a hurry (and the valuable outputs may be on a keychain you did not load onto your broadcast device).

To help illustrate potential use cases for an ECDSA signing tag like the sigsafe, a colleague and I prepared some additional images.  


This image shows the sigsafe about to sign a transaction (over NFC) that presumably sends 1.66 BTC to the Android hot wallet.  In an application like this, the sigsafe would be stored in a safe or another secure location, and would be programmed to only sign transactions that transfer funds to the hot wallet.  The sigsafe could also require cryptographic authentication from the Android wallet or a password from the user.  




This image shows the sigsafe acting like a "tap-and-pay" device at a traditional PoS terminal.  The sigsafe is compliant with ISO 14443-4, so it already "speaks the same language" as these PoS terminals.  However, the terminals would need to be programmed to support bitcoin payments and the sigsafe protocol.  In an application like this, the sigsafe might be programmed with a per-TX and a daily spend limit. 

The device is designed to securely store private keys, and then use those keys to sign authorized transactions.  The user can load additional private keys but it is not possible for him to erase or read keys from the device (even if the user is fully authenticated).

To produce an ECDSA signature, the private key must be multiplied by r (which depends on the per-message secret number k).  To complete this multiplication, the private key (or pieces of it) must exist in RAM at least as ephemeral stack variables.  But I don't see how this is an issue (regardless of RAM clearing) because if your are worried about leaking data from RAM you are probably already worried about leaking data from flash.  

Nevertheless, the device is "hard reset" each time it enters an NFC field, so (except for the real-time clock) there are purposely no "memory effects."

Could the ram be cleared after signing the transaction no? Assuming the stored private keys can be encrypted.

on a related note, not totally relevant, I saw this. ifind cool key locator.
Edit: Scam

The sigsafe supports simple password protection and has provision to cryptographically authenticate a host device, but I think that feature is overkill for most users.  NFC has an ultra short range (only a few centimeters) so it would be very difficult to conduct a man-in-the-middle attack.  

If somehow a man-in-the-middle attack is conducted (I have some ideas how this is possible), the user is still protected by the signing rules.  For example, if a sigsafe is used for day-to-day spending in the future, then perhaps the user sets a $50 maximum transaction limit (for anything more the user needs to provide a password and this is immune to MITM as it is transmitted by the PoS terminal to the sigsafe in cyphertext).


Thanks!  Bitcoin + NFC seems like such a natural to me--perhaps it will be the thing that finally makes NFC take off.  But I think there is a big future for ECDSA signing tags, far beyond bitcoin.  A single sigsafe tag could unlock the doors to your home, authenticate you to a bitcoin exchange or to Gmail, act as a loyalty card at a grocery store, and so much more.  ECDSA signing tags + ubiquitous NFC could solve the "username / password" problem that drives so many of use crazy!    

And yes, when these devices become fully commoditized, they will be extremely cheap like you said.  

Exactly.  The risk with repeat k-values (the Android hack) was due to a faulty RNG.  The sigsafe uses deterministic k values (RFC 6979) that, if implemented correctly, eliminate this risk entirely.  

Also remember that each sigsafe comes with the manufacturer's private key (that unlocks, for example, 10 BTC) programmed as Key1 as a "proof-of-intent" bond.  The sigsafe will produce bitcoin-signed messages with this key upon demand.  A user, auditor, or attacker can try to extract the manufacturer's proof-of-intent key from the device to steal the bond.  If the bond gets stollen, then the entire bitcoin community will see that at least one sigsafe device somewhere in the world was compromised.  This motivates the manufacturer to ensure the devices he sells are secure.  

I think initially sigsafe tags would be most useful as the "cold" part of a cold/hot wallet system.  A good example of this is the gambling site just-dice.com.  Its cold storage address is http://blockchain.info/address/19Zmw5kMbkTjA7qRUdUEiwLqgRaMRRLDkh and when necessary it transfers 500 BTC to its hot wallet.  Dooglus could use a sigsafe to make it easier and more secure to move funds from the cold wallet to the hot wallet.  It would be easier because he would just have to take the tag out of his safe and tap it against an NFC reader.  It would be more secure because it could be programmed to:

   - only sign transactions that move funds to the just-dice hot wallet
   - require a password before signing
   - it could even require cryptographic authentication from the host device making the signing request.

The risk of lost funds can be made extremely low with proper use of the sigsafe.  

In a case like just-dice, the public key to the cold wallet is already known because dooglus needs to produce bitcoin-signed message to convince his bankrollers that he actually controls the funds.  So dooglus has 43,000 BTC free for the taking if you think address re-use is not secure!

I think for a bitcoin user who wants a simple but secure way to store his funds, the sigsafe would be a very useful device.  

When the sigsafe tags are first released, assuming there's demand to move forward, we will charge what the market can bear in order to recoup tooling and engineering costs as quickly as possible.  

If there is real demand for ECDSA signing tags, I think these tags could become very inexpensive in large volumes (like "give-away as promotional material" cheap), especially if the backup battery and sintered ferrite film can be eliminated (at the cost of losing time-dependent signing rules).  This kind of cost reduction would be several years away and require several orders of magnitude growth in the bitcoin user base.

If the PRNG on the device is cryptographically strong and has no weaknesses or backdoors then there is no issue with key reuse.  From an academic point of view each additional signature does slightly reduce the security of the key but this has no real world practical value.  Even with millions of signatures the key would still be not breakable by brute force.

However proving a device is using a random k value with high entropy is very difficult.  It would be better for the device (if possible) to use a deterministic but still secret k values and deterministic signatures.  There is an existing standard RFC 6979.  Since the k value and derived signature are deterministic it becomes very easy to audit the device.  Load the device with a known private key, have it generate a series of test signed transactions, then compare that to the output of a reference client (also using RFC 6979).  Any deviation would be immediately recognizable.

The protocol (which hasn't been written) will become open-source and use standard NFC NDEF messages.  This means that software packages can be written for existing wallets to enable sigsafe connectivity.  

Thank you for the compliment, Nutschig!