Si noti che non-ripudio riguarda il convincere una terza parte (un giudice): Alice firma un messaggio e lo invia a Bob, in modo che non solo Bob sia convinto che il messaggio provenga davvero da Alice e non è stato alterato, ma Bob può mostrarlo a Charlie e anche Charlie sarà convinto. Qui, hai solo un client e un server, non una terza parte, quindi "non ripudio" non è rilevante qui. Questo sembra più un problema di autenticazione .
La prima risposta è che non è possibile per i seguenti motivi: la macchina è completamente compromessa, l'utente malintenzionato potrebbe leggere l'intero contenuto. L'utente malintenzionato può quindi eseguire un clone della macchina in una macchina virtuale e consentire al clone di parlare con il server. Il clone riferirà che tutto va bene, mentre l'attaccante saccheggia il sistema reale. Dal punto di vista di un crittografo, una differenza che può essere fatta tra due entità, dall'esterno (ad esempio un vero cane da guardia e una finta), solo se non sono in grado di calcolare le stesse cose e la capacità di calcolare equivale a conoscenza : il watchdog può calcolare una risposta al server che l'attaccante non può fingere solo se il cane da guardia conosce alcuni dati segreti che l'attaccante non ha, e, per costruzione, questo non succede .
La seconda risposta è che potrebbe essere fattibile ma richiede che le condizioni siano corrette. Se osserviamo da vicino il problema, vediamo che l'obiettivo dell'attaccante è di parlare con il server, emettendo messaggi che la macchina compromessa non può produrre. Ciò significa che il watchdog può funzionare in modo affidabile solo se il compromesso è distruttivo . Ad esempio, supponiamo che:
- Il client sotto supervisione utilizza un insieme di file di sistema (il sistema operativo con il suo kernel e librerie e utilità).
- In condizioni normali, questi file non sono completamente noti all'attaccante (potrebbe avere copie di alcuni o di molti di essi, ma non tutti).
- Ma il server conosce tutti i file, esattamente.
- Un compromesso riuscito necessariamente "danneggia" almeno un file (questo è il punto difficile) e il contenuto modificato non può essere recuperato in seguito dall'autore dell'attacco.
In queste condizioni, puoi utilizzare quanto segue:
- Crea un archivio di tutti i file di sistema, in ordine alfabetico. Il formato di archivio deve includere i nomi e il contenuto del file ed essere deterministico: se si crea l'archivio due volte , si ottiene il doppio dello stesso file di output, esatto fino all'ultimo bit. Il file di archivio non è archiviato su disco o RAM; è hashed al volo con SHA-256.
- Sia K l'output SHA-256. A intervalli regolari, il client parla al server; il server invia una sfida casuale C e il client risponde con HMAC / SHA-256, calcolato su C e usando K come chiave.
- Il server usa le sue conoscenze dei file client per ricalcolare K e verificare l'output HMAC.
Il protocollo challenge-response con HMAC previene attacchi di replay. MitM non si applicano neanche. In realtà, qui ci occupiamo di motivi di teoria dell'informazione, non di "cripto normale".
Sfortunatamente, è molto difficile garantire le condizioni di cui sopra. La segretezza dei contenuti del dispositivo è quasi impossibile da ottenere quando il dispositivo è un prodotto di consumo (l'utente malintenzionato può acquistare altre istanze del dispositivo, aprirle e visualizzarne tutti i contenuti) e la maggior parte dei compromessi è non distruttivo, almeno per quanto riguarda i file di sistema: i buffer overflow e le vulnerabilità simili portano a exploit solo sulla RAM, senza alcuna modifica ai file di sistema.
Quindi quello che espongo qui è più un concetto teorico che qualsiasi cosa pratica. Tuttavia, questo dovrebbe aiutare a capire il problema: per evitare alterazioni nascoste, il cane da guardia deve possedere un "segreto" che non sarà rivelato attraverso un compromesso completo, che è paradossale e richiede un po 'di imbrogli con condizioni assurde. p>