Sigsafe: A NFC key tag for signing bitcoin transactions

[fbueller]

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. 

[1715537628]

1715537628

[1715537628]

1715537628

[1715537628]

1715537628

[ThePurplePlanet]

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.  

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?

[Peter R]

Peter R,

Great product! My opinion is that the largest barrier to wide adoption is the dearth of secure storage. Paper wallets are fragile and impractical, but they're still the best cold storage we have.

Can you tell me more about key 0, and the intention there? How can the manufacturer NOT know it, when they create a pair of Sigsafes?

I'm an embedded software guy, and I'm open to talk about these ideas.

Thank you for the compliment, Nutschig!

[Peter R]

How much thought has been given to the mobile wallet software, which will create the transactions to sign? Will you create a new wallet or build on a currently existing wallet?

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.  

[DeathAndTaxes]

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.

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.

[Peter R]

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.  

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.

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.

[Peter R]

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

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.  

[Peter R]

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.

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 deterministic signatures create the k value, there is an existing standard RFC 6979.  Since the k values and thus signatures 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 transactions and signatures and compare that to the output of a reference client (also using RFC 6979).  Any deviation would be immediately recognizable.

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.  

[Peter R]

Have you found any research on possible spoofing of NFC data? Any ideas for authenticating the message to be signed by Sigsafe?

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

(I'm absolutely convinced you're on the right track, and that hardware keyrings are the future of Bitcoin and all public-key cryptography. At full scale, the hardware cost may be <$10, certainly cheaper than USB flash drives, with the only arms race being "to the bottom" by minimizing extraneous components and features.)

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.  

[Adrian-x]

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

[epere]

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

[Peter R]

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

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

[Peter R]

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. 

[Carlton Banks]

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

[Peter R]

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

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

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

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.  

[Carlton Banks]

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.

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)

[Peter R]

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.

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)

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?

[Peter R]

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:

Code:

// This is a command the interface device might send:  
B0 13 00 00 05 48 65 6C 6C 6F FF  

// This is how the card might respond: 
47 6F 6F 64 62 79 65 90 00

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

Code:

CLA (1 byte)  INS (1 byte)  P1 (1 byte)  P2 (1 byte)  Lc (0, 1 or 3 bytes)  command data (var bytes)  Le (0, 1 or 3 bytes)

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

Code:

response data (var bytes)  SW1 (1 byte)  SW2 (1 byte)

"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  

[Peter R]

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.

Code:

GetInfo command APDU sent from interface device:  

B0 66 00 00 21 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx FF

CLA          = B0
INS          = 66
P1           = 00
P2           = 00
Lc           = 21  
command data = xx … xx: compressed secp256k1 public key in standard bitcoin format (33 bytes)
Le           = FF  

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.    

Code:

GetInfo response APDU:

Version (1 byte)  PublicKey0 (33 bytes)   BSCType (2 bytes)   up to 219 bytes of BSCType-specific information    SW1   SW2

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.

Code:

Sigsafe BSCType:

CC 01

Sigsafe V1 getinfo data:

BIP32 public keychain (65 bytes)  random nonce (32 bytes)

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:

signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] [sighash="ALL"]

Sign as many inputs as possible for raw transaction (serialized, hex-encoded). The first argument may be several variations of the same transaction concatenated together; signatures from all of them will be combined together, along with signatures for keys in the local wallet. The optional second argument is an array of parent transaction outputs, so you can create a chain of raw transactions that depend on each other before sending them to the network. Third optional argument is an array of base58-encoded private keys that, if given, will be the only keys used to sign the transaction. The fourth optional argument is a string that specifies how the signature hash is computed, and can be "ALL", "NONE", "SINGLE", "ALL|ANYONECANPAY", "NONE|ANYONECANPAY", or "SINGLE|ANYONECANPAY". Returns json object with keys:

hex : raw transaction with signature(s) (hex-encoded string)
complete : 1 if rawtx is completely signed, 0 if signatures are missing.
If no private keys are given and the wallet is locked, requires that the wallet be unlocked with walletpassphrase first.

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.

Code:

SignRawTransaction APDU:    

CLA          = B0
INS          = 80
P1           = 00 : standard BSC interpretation
             = xx : proprietary interpretation (P1=CC for sigsafe-only interpretations)
P2           = 00 : raw transaction in command data field expressed in binary (arg1)
             = 01 : optional parent transaction in command data field expressed in binary (arg2)
             = 02 : optional private key in command data field expressed in binary (arg3)
             = 03 : optional sighash specifier (arg4)

             = FF : optional keychain and index for outputs controlled by or sent to a BIP32 keychain (for P1=CC)

Lc           = encodes number of bytes in "command data field"  
command data
Le           = encodes max number of response bytes allowed

response data
SW1
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.

Code:

Authenticate APDU:    

CLA          = B0
INS          = FA
P1           = 00 : standard BSC interpretation
             = xx : proprietary interpretation (P1=CC for sigsafe-only interpretations)
P2           = 00 : password authentication
             = 01 : cryptographic host authentication (for P1=CC). 
Lc           = encodes number of bytes in "command data field"  
command data = user password xor encrypted with shared-secret (P1=00)
             = bitcoin-signed message of 32-byte sigsafe nonce (P1=01)
Le           = encodes max number of response bytes allowed

response data
SW1
SW2

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.

[Carlton Banks]

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.

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)

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?

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.