È fondamentalmente possibile sviluppare un sistema informatico (chiaramente) trasparente?

Con l'hardware esistente, no, è fondamentalmente impossibile dimostrare che il codice che si esegue è effettivamente il codice da eseguire e nient'altro. Questo è facilmente visibile per quanto riguarda la riservatezza: immagina, ad esempio, che tu esegua un'applicazione di conteggio dei voti; gli elettori si collegano ad esso e inviano il loro voto. L'applicazione "onesta" non perde i dati dei voti individuali, sebbene veda tutti i voti e sappia cosa ha votato ciascun elettore. Tuttavia, dall'esterno, si vedono solo i pacchetti di rete che vanno e vengono, quindi non è possibile stabilire se qualche altra parte del sistema sta controllando i contenuti della RAM contemporaneamente o meno. In pratica, un manutentore del sistema dannoso eseguirà l'applicazione in una macchina virtuale e catturerà istantanee VM ogni volta che un nuovo elettore si connette. In virtù della VM che emula una macchina "vera", questo tipo di attività dannosa non può essere scartato in modo affidabile.

Alcune cose possono ancora essere fatte per cercare di ottenere alcune garanzie che il codice che viene eseguito è quello previsto:

• L'hardware può essere installato in una stanza fisicamente protetta, sotto controllo, con procedure di accesso che richiedono almeno due operatori umani e videocamere che registrano il tutto. Questo è comunemente fatto per le autorità di certificazione di root: quel tipo di macchina è su PC offline, tenuto in una gabbia in una stanza protetta e utilizzato occasionalmente (ad esempio, su base mensile) per rilasciare alcuni certificati all'autorità di certificazione intermedia e per creare un nuovo CRL. L'intero processo mira a garantire che, in effetti, la macchina farà solo ciò che dovrebbe fare; e questo è tutto procedure , senza software speciale.

• Per alcune operazioni, ci sono possibili protocolli crittografici. Ad esempio, per i sistemi di voto, si può usare la crittografia omomorfica , consentendo al sistema centrale di calcolare i voti senza avere accesso a il contenuto del voto effettivo. Poiché gli elettori inviano solo voti crittografati, devono dimostrare che i contenuti sono "validi" (hanno crittografato uno 0 o un 1, ma non un altro valore): ciò avviene con prove di zero-conoscenza . Notare la sfumatura qui: l'elettore non sta dimostrando che sta usando uno specifico codice open source che crittografa il suo voto; ma prova che ciò che alla fine invia alla macchina di controllo è in effetti la crittografia di un voto valido, indipendentemente dal modo in cui lo ha effettivamente calcolato.

Il post di Tom è un buon inizio su questo. Tuttavia, c'è un approccio più diretto che ho creato anni fa: un'implementazione standard su diversi componenti hardware che si controllano a vicenda. L'ho derivato perché mi sono reso conto che il problema di sovversione in realtà si riduceva a quello dei produttori o dei revisori di cui ti fidi. Il problema dell'attacco richiede che il nemico sappia cosa sta colpendo. Diversità / offuscamento aiutano lì. Quindi, assumendo che ogni persona abbia un hardware o strumenti di cui si fidano, la soluzione emerge naturalmente dal fatto che tutti possano calcolare lo stesso risultato usando gli stessi dati. L'uso di schede embedded e I / O ad alta velocità rende il processo sia economico che veloce.

Quindi, inizi con una toolchain certificata per il codice. Ho descritto come costruirne uno qui su HN:

link

Può anche usare Oberon System come componente perché è un compilatore non ingombrante, ben documentato, flessibile, facile da capire e portatile. C'è anche lo Scheme, inclusa la variante VLISP che è stata verificata matematicamente su x86, PPC e ARM.

Ad ogni modo, il punto è che hai (a) una mappatura da HLL a binario, (b) interfaccia OS con lo stesso, (c) hardware diverso, fidato per ciascuna parte, (d) ogni interfaccia implementata + toolchain per esso , (e) parser I / O robusto + mediazione I / O per hardware. Questi sono combinati con uno switch che esegue i passaggi del software in blocchi fissi con verifiche saltuarie (ad es. Hash) sui risultati, mentre la macchina condivisa per pubblicare le stampe graziose e le distribuisce. Ognuna di queste parti può vedere una deviazione e chiamarla. Con un protocollo votante decente e amp; I / O, questo può scalare fino a circa il numero di verificatori che il server di aggregazione può gestire.

Quindi, c'è la tua risposta. È quello che mi è venuto in mente per risolvere la sicurezza dei sistemi di costruzione di cui le parti reciprocamente sospette devono fidarsi. Supponevo che alla fine avremmo visto attacchi hardware da parte di TLA. La soluzione era la diversità, l'offuscamento, il semplice bootstrap e la facile verifica che siamo tutti sulla stessa pagina. Il catalogo Snowden e TAO ha confermato le mie previsioni e ha convalidato questo e altri metodi. Questo può essere applicato alla maggior parte dei problemi ad eccezione di tempo reale o prestazioni elevate. Tuttavia, ci sono versioni in tempo reale di ogni componente in altri progetti. Semplicemente non ho lavorato su di loro e non posso dire come sarebbe l'integrazione.