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.
acceptPublicKey, balance calculations -- I like that!
getPublicKeyTransactions -- why do we need that?
getPaymentRequest, returnPaymentRequest -- yep these are exactly what's needed to enable use with secure devices. browsing through the code shows that the relevant code that has to be split out is all in a critical block. the signed transaction will have to be checked for viability once it's imported back into the client.
Another thing you'd want to be able to do is test the private key signing without actually doing a transaction.
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.
Why do we need in-band authentication? Why not just encrypt the JSON with the secure device's public key? I think it's best to use established secure protocols like TLS if at all possible.