Il correttore di checksum ROM può difendere in modo affidabile da manomissioni / hacking non fisici di una macchina per il voto?

1

Ogni volta che ci sono elezioni negli Stati Uniti, vengono sollevate domande sulle vulnerabilità della sicurezza e sull'hacking / manomissione delle macchine per il voto (sono sicuro che non si tratta nemmeno di fenomeni USA).

Ovviamente, prevenire gli hack di livello hardware è un insieme di pesci completamente diverso, ma se supponiamo che la macchina sia fisicamente sicura - se non altro, perché ce ne sono così tanti , in tutto gli Stati Uniti, quindi è quasi impossibile manomettere quantità abbastanza significative anche solo contando gli stati di swing ), il seguente approccio sarebbe un modo ragionevolmente affidabile per prevenire manomissioni / hacking non fisici di una votazione macchina?

  1. Avere una real ROM (non modificabile) che memorizza il codice di controllo

  2. Il controllo del codice verifica che il software della macchina per il voto sia valido (presumibilmente, calcolando il checksum e verificando il checksum con valori validi noti - ad esempio, archiviato su un sito Web dell'ufficio elettorale federale).

    • Utilizza la crittografia a chiave pubblica per assicurarti che le somme di controllo recuperate siano effettivamente acquisite correttamente (utilizzando la chiave pubblica dell'ufficio elettorale federale).
  3. Se il checksum non va a buon fine, usa l'hardware separato NON controllato dal resto dell'elettronica nella macchina per il voto, per segnalare almeno il malfunzionamento del segnale, o persino bloccare la funzionalità di votazione.

Poiché il codice di controllo è al 100% nella ROM, richiederebbe un accesso fisico alla macchina con cui fare confusione (e se è sufficientemente protetto, ad esempio all'interno di un compartimento saldato, sarebbe molto difficile avvitarlo).

UPDATE : per essere chiari, le ipotesi qui sono:

  • Ogni attacco è esterno al venditore della macchina, e quindi, il software scritto per essa dal venditore fa esattamente ciò che si suppone faccia a meno di errori adeguatamente spiegati da stupidità .

    Non ci sono trojan intelligenti nel codice, non c'è alcun vettore di attacco nel compilatore usato dal venditore. Il contesto della domanda è difendersi contro un attacco da parte di una terza parte su una macchina funzionante perfettamente valida .

    Ragioni: perché il contesto in cui ho posto la domanda era rappresentato da attacchi di terze parti nella vita reale (e non in trojan). Inoltre, poiché altrimenti, la domanda diventa banale per rispondere e non interessante. Ovviamente è possibile sottoporre il fornitore a risorse sufficienti, duh.

  • Puoi anche presumere di poterti fidare delle firme di checksum sul sito federale - perché è irrilevante, ma è semplice come avere stagisti di tutte le parti interessate che siedono lì tutto il giorno delle elezioni con la stampa di checksum originale e verifica che il sito Web corrisponda ancora alla stampa.

  • Ci sono state obiezioni sollevate sull'ipotesi che la sicurezza fisica attraverso "oscurità" (o volume puro) sia abbastanza efficace perché ci sono solo poche zone di oscillazione. Questa è in realtà una supposizione valida da fare.

    Motivazione: nella pratica politica degli Stati Uniti, dato il margine di errore del sondaggio (testimone delle elezioni del 2016), sapere cosa sarebbe lo stato / i recinti dello swing è quasi impossibile. Non importa che nelle elezioni a cambiamento più ampio, come il 2008 o il 2016 o il 1992, la quantità di macchine che è necessario manomettere per influenzare effettivamente l'esito del college elettorale (invece di spostare leggermente il margine di voto) richiede che TONS di stati / distretti cambi. L'elezione del 2000 con le aree specifiche della Florida era un outlier, non una regola - e persino in quelle elezioni, prevedendo che la Florida sarebbe stata uno stato altalenante con quelle aree specifiche non fu facile.

posta DVK 25.11.2016 - 18:08
fonte

3 risposte

1

Ci sono molti presupposti nella tua descrizione, e non tutti sono validi.

Supponendo che la sicurezza fisica sia un problema. I funzionari elettorali hanno accesso alle macchine e presumibilmente hanno le chiavi delle interiette bloccate. La manomissione fisica nascosta è sempre possibile. Qualcuno potrebbe nascondere un Raspberry Pi all'interno del cabinet che sostituisce la macchina principale, e potrebbe rispondere in tutti i modi giusti. Anche i funzionari elettorali non saprebbero la differenza.

Supponendo che ci sia sicurezza nei numeri è un grosso problema. Non riesco a trovare la fonte in questo momento, ma un po 'di tempo fa ho letto un articolo sul blog di Schneier che un attaccante non deve corrompere un intero stato di swing, ma solo alcuni quartieri swing all'interno di uno o due distretti dello swing all'interno dello stato . Prevedere quali distretti essere corrotto è interamente possibile. Teoricamente, l'esito di tutte le elezioni presidenziali potrebbe essere alterato alterando solo poche decine di macchine per il voto in tutto il paese.

Supponendo che ci sia "una" domanda da verificare è un problema. La macchina ha un sistema operativo, un'interfaccia utente, un lettore di schede, un registratore, ecc. Il checksum dovrebbe rappresentare la totalità della macchina e tutte le sue periferiche, non solo un singolo programma.

Stai descrivendo cosa è simile al processo UEFI Secure Boot. Microsoft, Intel e altri hanno avuto problemi nel tentativo di ottenere che questo fosse effettivamente un modo efficace per proteggere una macchina (una presentazione di Blackhat mostrava dei modi per aggirarla.) Senza una specifica implementazione operativa e anni di analisi e attacco, è impossibile pronunciarsi " X è sicuro "; anche con un'implementazione funzionante, non conosco nessuno che possa mettere in gioco la loro reputazione sulla sicurezza professionale in base a una simile dichiarazione per le macchine per il voto.

    
risposta data 25.11.2016 - 18:56
fonte
1

La risposta di John fa già il seguente punto in modo molto conciso, ma ho pensato di estenderlo un po ':

Hai trovato un modo per verificare che il software in esecuzione sulla tua macchina per il voto corrisponda alla firma del software in archivio presso l'ufficio elettorale federale. A tale scopo, utilizzare un controllo indipendente memorizzato nella ROM che verifica la firma digitale dell'intero stato del software della macchina per il voto utilizzando la crittografia a chiave pubblica.

Supponendo che la tua macchina per il voto sia fisicamente sicura, la chiave privata utilizzata per firmare il software sia sicura, la crittografia a chiave pubblica utilizzata per creare la firma sia sicura, tutto l'hardware e il programma di controllo stesso va bene e così via, garantisce che la macchina per il voto sia ok?

No . L'unica cosa è la garanzia è che tu sai che c'è una copia binaria esatta del software che è in esecuzione sulla macchina di voto elettronico al momento del controllo da qualche parte presso l'ufficio elettorale federale. Ma non sai ancora se questo software sta facendo quello che dovrebbe fare e se continuerà a fare ciò che è previsto per cinque secondi dopo il controllo.

Non sai se il software contiene una parte di codice intelligente che scarica il codice malevolo da qualche parte subito dopo il completamento del controllo e rimuove le parti dannose prima che sia necessario il prossimo controllo. Non sai se esegue un po 'di magia sul conteggio finale, o ignora ogni decimo voto "sbagliato", o fa qualche altra cosa nefasta. Devi ancora fidarti delle persone che hanno scritto il software, delle persone che hanno ispezionato il software scritto, delle persone che hanno firmato digitalmente il software e di un sacco di altre persone che non hai nemmeno realizzato.

Ora, idealmente, il software su una macchina per il voto dovrebbe contenere solo poche centinaia di righe di codice c molto semplice (in pratica, se si preme questo pulsante, quindi aumentare un contatore qui, e stampare qui questa ricevuta cartacea ...) che potrebbe essere controllato indipendentemente da un singolo individuo in un'ora o due, ma in qualche modo lo ritengo improbabile. Le immagini googling delle macchine per il voto Diebold, vedo delle schermate con istruzioni grafiche sull'uso. Questo richiede già molte migliaia di righe di codice. Pensa al codice per caricare queste istruzioni grafiche da un qualche tipo di memoria, che significa codice I / O, driver di archiviazione, parser di formato file, driver di visualizzazione, routine di visualizzazione grafica ecc. E questo è solo per visualizzare le istruzioni grafiche su uno schermo. Tutto questo codice potrebbe contenere parti dannose e non abbiamo ancora nemmeno toccato la parte votante. Quindi il paragrafo di John su di esso non è solo una "domanda", ma un intero zoo, incluso un sistema operativo completo, è molto importante. Chi può verificare la correttezza di un intero sistema operativo?

È un sogno irrealizzabile. Un programmatore capace, responsabile della scrittura di software per la macchina per il voto, potrebbe sempre essere corrotto o ricattato per aggiungere codice malevolo in qualche angolo oscuro del sistema, e presumo che la possibilità che venga rilevata sarebbe piccola. Dovrebbe esserci un'enorme quantità di revisione tra pari; ogni singolo codice che cambia un programmatore fatto in qualsiasi parte del sistema dovrebbe essere controllato indipendentemente, e quindi ci dovrebbe essere un sistema in atto per assicurarsi che il sistema che è stato firmato nel tuo ufficio elettorale federale fosse in realtà il sistema che è stato revisionato.

Questo è un problema orribilmente complicato. Ad esempio, come possiamo essere sicuri che il codice sorgente che vediamo produce il sistema compilato che firmeremo? Possiamo fidarci del compilatore che viene utilizzato per compilare l'intero sistema? Cosa succede se qualcuno inserisce un codice nel compilatore che si accorge di quando il sistema di voto elettronico è compilato e introduce codice dannoso nel programma compilato che non è presente nell'origine?

Quindi ora è necessario rivedere ogni singola modifica apportata al compilatore.

Il compilatore probabilmente utilizza varie librerie di codici e un runtime di grandi dimensioni. È necessario rivedere tutte le modifiche apportate al runtime e alle librerie utilizzate anche dal compilatore. A proposito, questo vale anche per tutte le librerie utilizzate dal codice della tua macchina per il voto elettronico.

Verificare la firma digitale del software in esecuzione su una macchina per il voto elettronico è una parte molto, molto, molto piccola per assicurarsi che la macchina per il voto elettronico sia a posto.

Come Xiong Chiamiov nel commento alla tua domanda, direi che questa non è la strada da percorrere. Quello che devi fare in realtà è assicurarti che, quando un votante vota, possa scoprire in seguito che il suo voto ha influenzato il risultato finale nel modo giusto. Questo sarebbe generalmente molto facile da fare (dare ad ogni elettore una ricevuta e pubblicare l'elenco di chi ha votato come su un webserver governativo), ma diventa davvero difficile a causa delle restrizioni che il voto democratico ci pone: non possiamo pubblicare elenca perché non ce l'abbiamo: le scelte degli elettori devono rimanere anonime.

    
risposta data 25.11.2016 - 22:08
fonte
0

Un'altra risposta, dopo l'aggiornamento della domanda.

Se sapessi che il software firmato non contiene parti dannose, devi solo difenderti dagli errori.

Supponiamo che il tuo controllore ROM abbia controllato tutti i software del sistema, incluso tutto il contenuto della RAM, più volte, diciamo ogni dieci minuti in media.

In tal caso, anche se un bug consentiva l'esecuzione remota del codice sul dispositivo di votazione, il codice malevolo caricato a distanza sarebbe eseguito solo dieci minuti prima di essere rilevato.

Quindi il codice avrebbe bisogno di cancellarsi e ripristinare lo stato originario del sistema prima del prossimo controllo, e il codice remoto avrebbe bisogno di reinfettare la macchina dopo il completamento del controllo.

Non penso che sia del tutto impossibile, ma potresti guardarti dal farlo eseguendo il controllo a intervalli casuali brevi, rendendo così impossibile per un attacco sapere quando è necessario ripristinare lo stato del sistema ea che ora era sicuro reinfettare la macchina.

Tuttavia vedo un problema nel fare il controllo. Il tuo sistema è sicuro solo se il controllore della ROM controlla la RAM. Quindi il controllore dovrebbe essere abbastanza intelligente da sapere quali parti dovevano rimanere statiche e quali parti della RAM dovevano cambiare durante il normale funzionamento.

Ad esempio, il software utilizza quasi sempre uno stack per il passaggio di argomenti, la memorizzazione di valori e indirizzi di ritorno, ecc. Il controllo ROM dovrebbe escludere lo stack, quindi potrebbe essere un'area in cui il codice dannoso potrebbe nascondersi. Le CPU supportano stack non eseguibili, ma ciò renderebbe impossibile eseguire il codice, non memorizzarlo.

Lo stesso vale per altri segmenti di dati, ad esempio quelli che memorizzano i dati di voto. Parti di questa memoria potrebbero essere utilizzate per memorizzare codice dannoso. Di nuovo, i segmenti di dati possono essere protetti dal codice in esecuzione, almeno su CPU Intel.

Se, tuttavia, l'esecuzione del codice nelle parti dinamiche e non controllate della RAM non era disabilitata, consentirebbe al codice malevolo di funzionare continuamente rimanendo non rilevabile per il controllo della ROM.

Sto pensando a come il codice dannoso potrebbe eseguirsi periodicamente o continuamente senza toccare il codice originale che veniva controllato dal verificatore della ROM. Questo è un problema davvero interessante, ma penso che possa essere risolto. Quindi la sicurezza del tuo sistema (ignorando il gran numero di ipotesi necessarie per arrivare qui) dipendeva in gran parte da quanto bene puoi bloccare le parti non controllabili della RAM.

    
risposta data 26.11.2016 - 01:29
fonte

Leggi altre domande sui tag