whose implementation we want to keep secret
Questo di solito è un indicatore del fatto che il tuo schema non è sicuro. L'implementazione stessa non dovrebbe essere necessariamente segreta. Il segreto dovrebbe essere il materiale chiave, non l'algoritmo o l'implementazione stessa. Tutto ciò rientra nel principio di Kerckhoffs .
Now the question is, can we ever realistically hope to prevent an attacker from gaining access to the key?
Assolutamente no. Posso pensare ad almeno cinque attacchi dalla cima della mia testa che rompono questo, iniziando con il dumping di tutta la memoria tramite PCI-e DMA.
Come esempio di come sia assolutamente impossibile tenere le chiavi nascoste quando un utente malintenzionato ha accesso fisico, guarda la scena homebrew della console di gioco. Xbox 360 e PS3 avevano un'intera gamma di controlli di sicurezza incorporati nel silicio della CPU, con archiviazione della chiave segreta on-die, RAM isolata per unità di esecuzione sicure, catena di trust crittografica dal bootloader fino alle applicazioni ( giochi), e tutti i tipi di altri controlli intelligenti ... e ci sono voluti solo 12 mesi affinché le persone rompessero ogni piattaforma (nel caso della PS3 erano 12 mesi dopo che Sony aveva ucciso il supporto Linux). Accesso fisico significa che l'attaccante alla fine lo farà fare come preferisce e ottenere l'accesso a tutti gli ultimi bit di dati sul dispositivo.
I'm saying that to secure this system, A or B needs to somehow be connected to an external validation source C, that the attacker does NOT have phyiscal access to. Is this correct?
Non sono sicuro di come si applica la "validazione" qui, ma in sostanza è necessario mantenere f(x) da eventuali perdite, quindi deve essere memorizzato ed eseguito su un sistema che l'utente (o un utente malintenzionato) non ha accesso a
Dovrai considerare anche gli effetti di un utente malintenzionato che utilizza il tuo servizio remoto come un oracolo, che in sostanza è. Ad esempio, l'hard disk della PS3 è stato crittografato e nessuno ha potuto accedere alle chiavi di decrittazione (queste erano on-die e accessibili solo da un'unità di esecuzione isolata) ma, a causa di un difetto nel processo di crittografia, hanno usato la stessa chiave e IV per ogni settore: puoi scattare un'istantanea del disco, caricare un film sulla PS3, cercare il grande blocco di settori che è cambiato, quindi sovrascrivere quei settori con qualsiasi altro dal disco (ad esempio, il sistema operativo stesso), avviare la PS3 esegue il backup, scarica nuovamente il film e il sistema decodifica i settori del disco (senza che tu sappia mai quale fosse la chiave!) e restituisce il testo in chiaro originale. Gli sviluppatori di homebrew hanno utilizzato questo attacco oracle per decrittografare i dati senza aver mai bisogno di sapere quale fosse la chiave. Dovresti considerare attacchi simili contro il tuo sistema.