Key exchange with an untrusted party

Question

Assume there are two parties - an agent and a server. The agent must register itself to the server by sending its identifier over the internet.

And let's say we use public cryptography to encrypt the identifier on the agent device and send it to the server, which uses its private key to decrypt it. Diffie-Hellman key exchange could also be used for this.

This scheme, however, doesn't deal with the fact, that the agent is not secure against physical attacks, in case of which, the public/private keys would get stolen from the agent. Then anyone could imitate the agent and send registration requests with the stolen keys.

Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

EDIT: thank you for your ideas. To be more specific, the agent is a Raspberry Pi computer, integrated into a product that is shipped to customers.

Answer 1

This scheme, however, doesn't deal with the fact, that the agent is not secure against physical attacks, in case of which, the public/private keys would get stolen from the agent. Then anyone could imitate the agent and send registration requests with the stolen keys.

If the attacker has physical access to the agent computer, then the attacker can operate the agent computer, and send any requests in its identity.

Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

Well you should still use cryptographic keys to secure against virtual attacks, but there may be other solutions that can be used in addition to cryptography.

Some ideas that come to mind.

1. You could require the connection to originate from a specific IP address that is only available by connecting to the network cable at the Agent station. In this way, the attacker would have to forge requests on-site, and could not simply copy the keys for later use elsewhere.

2. Depending on your Agent computer, it is possible that attacks will require interruption of the OS to access internal data. If that is a necessary component of the attack, then you can use a continuous communication channel to detect when the OS is terminated. The server can assume it is an attack (not knowing) and the credentials be disqualified.

   Administrator override can be used to indicate the interruption was a technical issue (such as internet connection issue or router restart) instead of an attack, in which case the credentials can be qualified again.

3. Use a separated One Time Password device that the user keeps in his possession. YubiKey or GAuthenticator are possible implementations of this. This is not a silver bullet, but would make it more difficult for an attacker to forge a request, as he would have to install a program that waits, and then eventually makes use of the One Time Password. Your server can enforce Replay Attack prevention to make the attacker less invisible.

Again, your options are limited when the attacker has physical access to the machine, but perhaps these will help. Welcome to Security Stack Exchange!

Answer 2

Cryptography is the only way that kind of trust can be established, and if that is taken away, you're left with nothing. You could physically stand at the agent's computer, but you've said that computer could have been hacked, so that would prove nothing.

You'll have to do something different so you can avoid placing all your trust in the agent's computer. Consider separating the keys from the machine. You could give the agent a smart card with the keys on it. The agent would insert the keys into the computer only when he's using it, but keep them in his pocket when he's not.

You could also use a Hardware Security Module (HSM) in the agent's computer, and require the agent use something like two-factor authentication to access the keys to initiate communication with the server.

Answer 3

Is there a way, to know, undeniably, from the communication, that the party is the agent, without storing cryptographic keys on the agent locally?

Well, if the agent has to use the secret to authenticate itself to the server, then the agent must have some form of access to the secret at authentication time, and is vulnerable to impersonation attacks at least during that span. So it's a question really of how can we:

1. Minimize the form of the agent's access to the secret;
2. Minimize the time span that the secret is available as well.

---

One technique for doing #1 is to give the agent a hardware security module—an isolated, hardened hardware module that generates and stores keys, but doesn't allow secrets to escape from it. In this case, the agent can't actually see the secret keys—all it can do is send data to the HSM and request it to perform operations with the stored keys.

A quick search for "Raspberry Pi hardware security module" pops up some links, which you may want to read. (This one is the one I found most interesting, personally.) You might also want to search for information on interfacing Raspberry Pi to smartcards or devices like Yubikeys, which are off-board crypto processors as well.

---

A technique for #2 is to protect the agent's primary authentication secret with a second secret or factor, external to the agent. One solution might be:

1. Password-protect the agent's authentication key, for example using password-based encryption;
2. Take great care that the agent doesn't store any long-lived copies of password or secret; immediately erase them from memory as soon as you're done with them.

The downside here is that when authentication is required, the user then has to enter the password.

---

For a real-life application of these ideas, consider Apple's iOS Security Guide. The phone or tablet's master keys live inside the "Secure Enclave" (an HSM):

The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It uses encrypted memory and includes a hardware random number generator. The Secure Enclave provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised. Communication between the Secure Enclave and the application processor is isolated to an interrupt-driven mailbox and shared memory data buffers. [p. 7]

When the phone is locked, it discards or encrypts the master keys so that applications may not perform operations with them:

If Touch ID is turned off, when a device locks, the keys for Data Protection class Complete, which are held in the Secure Enclave, are discarded. The files and keychain items in that class are inaccessible until the user unlocks the device by entering their passcode. [p. 9]