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:
- Minimize the form of the agent's access to the secret;
- 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:
- Password-protect the agent's authentication key, for example using password-based encryption;
- 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]