Scambio di chiavi con una parte non fidata

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.

Se l'utente malintenzionato ha accesso fisico al computer dell'agente, l'utente malintenzionato può utilizzare il computer dell'agente e inviare eventuali richieste nella sua identità.

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

Bene, dovresti comunque utilizzare le chiavi di crittografia per proteggersi dagli attacchi virtuali, ma potrebbero esserci altre soluzioni che possono essere utilizzate in aggiunta alla crittografia.

Alcune idee che ti vengono in mente.

1. È possibile richiedere che la connessione provenga da un indirizzo IP specifico disponibile solo collegandosi al cavo di rete sulla stazione dell'agente. In questo modo, l'utente malintenzionato dovrebbe falsificare le richieste sul posto e non può semplicemente copiare le chiavi per utilizzarle successivamente altrove.

2. A seconda del computer dell'agente, è possibile che gli attacchi richiederanno l'interruzione del sistema operativo per accedere ai dati interni. Se questo è un componente necessario dell'attacco, è possibile utilizzare un canale di comunicazione continuo per rilevare quando il sistema operativo è terminato. Il server può assumere che si tratti di un attacco (non sapendo) e che le credenziali siano squalificate.

   L'override dell'amministratore può essere utilizzato per indicare che l'interruzione era un problema tecnico (come il problema di connessione a Internet o il riavvio del router) invece di un attacco, nel qual caso le credenziali possono essere nuovamente qualificate.

3. Utilizzare un dispositivo One Time Password separato che l'utente conserva in suo possesso. YubiKey o GAuthenticator sono possibili implementazioni di questo. Questo non è un proiettile argentato, ma renderebbe più difficile per un utente malintenzionato forgiare una richiesta, poiché dovrebbe installare un programma che attende e quindi utilizza la password One Time. Il tuo server può imporre la prevenzione di Replay Attack per rendere l'aggressore meno invisibile.

Ancora una volta, le tue opzioni sono limitate quando l'utente malintenzionato ha accesso fisico alla macchina, ma forse queste saranno d'aiuto. Benvenuto in Security Stack Exchange!

La crittografia è l'unico modo in cui è possibile stabilire quel tipo di fiducia e, se ciò viene portato via, non ti rimane nulla. Potresti stare fisicamente sul computer dell'agente, ma hai detto che il computer potrebbe essere stato violato, quindi non proverebbe nulla.

Dovrai fare qualcosa di diverso in modo da evitare di mettere tutta la tua fiducia nel computer dell'agente. Prendi in considerazione la possibilità di separare le chiavi dalla macchina. Potresti dare all'agente una smart card con le chiavi. L'agente inserirà le chiavi nel computer solo quando lo sta usando, ma le tenga in tasca quando non lo fa.

È anche possibile utilizzare un modulo di sicurezza hardware (HSM) nel computer dell'agente e richiedere all'agente di utilizzare qualcosa come l'autenticazione a due fattori per accedere alle chiavi per avviare la comunicazione con il server.

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

Bene, se l'agente deve utilizzare il segreto per autenticarsi sul server, allora l'agente deve avere qualche forma di accesso al segreto al momento dell'autenticazione ed è vulnerabile agli attacchi di rappresentazione a almeno durante questo periodo. Quindi è davvero una domanda su come possiamo:

1. Riduci al minimo il modulo dell'accesso dell'agente al segreto;
2. Riduci al minimo l'intervallo che il segreto è disponibile pure.

Una tecnica per fare # 1 è dare all'agente un modulo di sicurezza hardware - un modulo hardware isolato e rinforzato che genera e memorizza le chiavi, ma non consente ai segreti di fuggire da esso. In questo caso, l'agente non può effettivamente vedere le chiavi segrete: tutto ciò che può fare è inviare i dati all'HSM e richiederne l'esecuzione con le chiavi memorizzate.

Una rapida ricerca di "modulo di sicurezza hardware Raspberry Pi" mostra alcuni link, che potresti voler leggere. ( Questo è quello che ho trovato più interessante, personalmente.) potrebbe anche voler cercare informazioni sull'interfacciamento di Raspberry Pi con smartcard o dispositivi come Yubikeys, che sono anche processori crittografici esterni.

Una tecnica per # 2 è di proteggere il segreto di autenticazione primario dell'agente con un segreto o fattore secondo , esterno all'agente. Una soluzione potrebbe essere:

1. Proteggere con password la chiave di autenticazione dell'agente, ad esempio utilizzando la crittografia basata su password;
2. Prestare molta attenzione che l'agente non memorizzi copie di password o segreti di lunga durata; cancellali immediatamente dalla memoria non appena hai finito con loro.

Il lato negativo qui è che quando è richiesta l'autenticazione, l'utente deve inserire la password.

Per un'applicazione reale di queste idee, prendi in considerazione Guida alla sicurezza iOS di Apple . Le chiavi principali del telefono o del tablet si trovano all'interno di "Secure Enclave" (un 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]

Quando il telefono è bloccato, scarta o crittografa le chiavi master in modo che le applicazioni non possano eseguire operazioni con loro:

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]