Quote from: ben-abuya on June 24, 2011, 05:10:45 PM

getPublicKeyTransactions -- why do we need that?

The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later. It would use this request to ask for them. As an aside, the secure device should only make this request upon a command from the user. That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data.

Quote from: ben-abuya on June 24, 2011, 05:10:45 PM

Quote from: kjj on June 23, 2011, 09:56:10 PM

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.

Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below. Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.

My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.