While I was driving today, I had some thoughts on what exactly was needed to get my hardware wallet project talking to the client.  Might work for other types of smartcards projects too.

I also had the bright idea of letting the client act as a stand in for a hardware wallet.

Step 1.  Add some new methods to the JSON RPC API.  I think I can get by with just 4, but I may have missed something.  acceptPublicKey tells a node to add a new public key and include it in balance calculations.  getPublicKeyTransactions tells a node to return all transactions involving a given public key.  getPaymentRequest tells the node to give it any pending payment requests.  returnPaymentRequest returns the signed transaction to the node.

Step 2.  Add UI/config file support for these calls.  A set of options to specify a remote JSON server to connect to as a client.  An option to tell the client NOT to generate keys.  A checkbox on the payment page to tell the node to queue up the amount/address pair for delivery to an external device in response to a getPaymentRequest RPC call.  A button to tell the client to ask the other server for transaction requests.  A dialog to display and request confirmation/deletion of queued requests.

At this point, you could have two computers running bitcoin.  One on your main box that has no keys and is unable to send any coins by itself, and a second box that does not connect to the network ever, but only talks RPC to the first box.  All keys are on the second box, so all payments must be relayed through the JSON RPC service from the first box to the second.

Since the second box is on the network too (or it wouldn't be able to talk to the first box), won't it get infested too?  Yup, and that brings up...

Step 3.  Implement JSON over serial.  Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them.  I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us.  I propose that each string be followed by a hash of the command + password.

Step 4.  Implement a security system that allows the developers (or the use, I suppose) to allow/disallow certain RPC to come in from or go out to certain interfaces.

Step 5.  Build hardware that talks this protocol over various forms of serial.

I think that this approach has a bunch of advantages.  First, it allows everyone with a junk box sitting around the ability to set up a secure offline wallet without needing any special hardware.  Second, it allows debugging to take place on computers which have excellent debugging tools, at least initially.  And when we get to the step where we are working with hardware, we will have a protocol to target that is known to work.