Come fidarsi degli IC?

In teoria, per accertare che cosa fa un chip, lo spezzi e lo decodifichi. In pratica, questo sarà quasi impossibile da fare. In realtà, anche per software , per il quale si ha il codice sorgente , non si può garantire che il codice faccia sempre ciò che credi che faccia (altrimenti saremmo in grado di produrre codice senza bug).

Questo non è un nuovo problema, e le agenzie di intelligence (un ossimoro) si sono imbattute in esso molte volte. Quando la CIA vuole accertarsi che i computer della Casa Bianca non siano pieni di backdoor controllati dalla Cina, cosa fanno? Bene, certamente danno un'occhiata ai chip per qualsiasi cosa ovvio (un modem GSM integrato ha una dimensione minima, può essere visto con una scansione a raggi X del chip). Tuttavia, alla fine, si basano su metodi di indagine classici che hanno dimostrato la loro efficienza dai tempi di Giulio Cesare: tracciare la fonte di ciascun componente, chi li ha progettati, chi li ha prodotti, chi li ha trasportati e così via, con controlli di background su tutti persone coinvolte e revisione delle procedure. Questo non è molto diverso dal "software certificato" (ad es. Common Criteria ), per il quale design, specifiche, background degli sviluppatori e metodologie di sviluppo sono ispezionato.

Un modo per vederlo è che l'hardware non è malvagio - le persone lo sono. Quindi controlla le persone, non l'hardware.

Nel caso della CIA, ciò significa che molto preferiscono i chip del Taïwan rispetto ai chip della Cina continentale.

Solo per chiarire le cose.

Mi sembra che ci siano due domande distinte qui: "Devo fidarmi del mio produttore?" e "Può un TPM essere dannoso?".

Ecco alcuni commenti sul secondo:

Un TPM non può fare questo tipo di cose, è un dispositivo passivo / stupido. In genere è collegato tramite un bus standard (LPC). Mentre l'LPC ha accesso DMA tramite l'interrupt LDRQ #, il TPM non ha accesso a tale interrupt. In altre parole, non può accedere al motore DMA né può comunicare da solo con altri dispositivi. Qualsiasi attacco che il TPM potrebbe svolgere dovrebbe essere passivo, come un attacco di canale laterale.

I nuovi TPM implementati da Intel sono attualmente in esecuzione come applicazione all'interno di Platform Controller Hub precedentemente Memory Controller Hub, ovvero Northbridge. Sono in esecuzione su Intel Management Engine a parte AMT e raggruppato sotto l'ammiraglia di vPro. È possibile vedere Intel ME come un sistema operativo in esecuzione su ring -3 poiché è in esecuzione su una CPU completamente separata (non la CPU principale) e ha accesso completo alla memoria del sistema (tramite Intel UMA). Pertanto, qualcuno potrebbe obiettare che quegli iTPM (TPM integrati, benché sia qualsiasi applicazione in esecuzione su ME) abbiano la capacità di essere attivi e fare il genere di cose che descrivi.

A quel punto la domanda è, potrebbe qualcuno backdoor Intel ME / AMT? Si è possibile. Improbabile, ma possibile. Dovresti sfruttarlo , altrimenti ti serviranno le chiavi di firma ME. Inoltre, tornando alla tua prima domanda, il tuo produttore potrebbe backdoor Intel ME / AMT? La stessa risposta.

P.S. a un certo punto la storia dietro a BadBIOS si è messa in discussione se ciò stesse realmente accadendo (cioè un exploit molto potente e portatile).

Ho fatto un discorso a Blackhat alcuni anni fa (in realtà 10 ora) che ha rivisitato Trusting Trust: link

Ho seguito un articolo scritto per Linux Journal nel 2005: link

Ho svolto ricerche su questo argomento per quasi 15 anni e posso dire che l'articolo di Thompson è che a meno che non si verifichi OGNI componente nel proprio ambiente, non è possibile. Mentre la logica ti dice che un pezzo di hardware o software trojan potrebbe avere un blob binario sospetto che fa un guscio inverso, in realtà potrebbe essere molto più sottile. L'articolo del 2005 ha evidenziato un esempio di creazione di uno stub per strncpy e in realtà l'utilizzo di strcpy. Se si guardasse i simboli dopo la compilazione, tutto sembrerebbe giusto, ma ovunque si pensi che un buffer overflow sia stato interrotto da strncpy che ora diventa un vettore di attacco.

Quando si tratta di hardware questo processo è ancora più difficile perché non è possibile eseguire solo stringhe sul binario. Una combinazione di preoccupazioni e leggi sulla proprietà intellettuale mantengono un gran numero di operazioni minori di qualcosa di simile a un dispositivo mobile. Il jailbreak ha avuto un certo successo nell'aprire questa scatola nera, ma non una tonnellata.

Guarda questo blog che ho scritto in risposta alla vulnerabilità di iPhone SMS nel 2009: link Un sacco di reazioni da scocciatore a questo bug è stato quello di avere AT & T disabilitare il piano SMS per l'iPhone e le persone si sentivano al sicuro. In realtà, anche se non disponi di un piano SMS, il tuo telefono riceve speciali aggiornamenti SMS dal corriere che fanno cose come l'ottimizzazione della rete, gli aggiornamenti delle torri, ecc ... Una backdoor nel dispositivo potrebbe essere semplice come premere un aggiornamento della torre al tuo telefono che ti dice che il catetere IMSI nella tua cappa vicina è una torre portante ufficiale e va bene per noi.

In breve, a meno che non produciate tutti i componenti, scrivete tutto il software, possedete la compagnia telefonica e siete in grado di approvare leggi favorevoli per la ricerca che non potete sapere se il vostro dispositivo è backdoor.

Non riesco a rispondere completamente "come fidarsi?", ma voglio contribuire almeno a un'idea utile. Come già affermato nelle altre risposte, ci sono due opzioni:

1. Tu fai tutto da solo (l'IC), da questo hai evidentemente una buona base per la fiducia.
2. Puoi prendere qualcosa già fatto e analizzarlo e testarlo.

Mentre queste opzioni presentate eccellono nel loro attributo di cedere un livello di fiducia totale, sono ovviamente impraticabili. Il prezzo da pagare per la fiducia, in termini di tempo e impegno materiale, è enorme.

In parte l'idea che voglio aggiungere come alternativa limitata alle due opzioni presentate, può dipendere dal sacrificare un po 'di comfort o funzionalità. La logica dell'idea è che:

1. Dal momento che non siamo in grado di osservare i componenti di insight (ad esempio il chip TPM, il processore dell'anello -3 Intel AMT ...) non ci possiamo fidare di loro. Non possiamo vedere l'intuizione a causa della complessità e della miniatura del componente.
2. Per la stessa ragione (complessità e dimensioni) è anche impossibile sostituirli con sostituti fatti da sé.
3. Secondo la disposizione che i componenti, hanno una separazione fisica gestibile (cioè essere separati chip) e una separazione funzionale (cioè la loro funzionalità non è "tutto"), sarebbe possibile implementare uno schema in cui si modifica l'hardware in un modo in cui l'hardware separa i componenti l'uno dall'altro tramite un'interfaccia logica del proprio e quindi di un design affidabile e di un controller.

Per prendere questo da un abstract a un livello più pratico lasciatemi illustrare con un esempio.

Supponiamo che tu abbia un IC malicouis nel tuo sistema che, come suggerito nella tua domanda, userebbe il GSM / comunicazione per inviare dati a un utente malintenzionato. Dato che soddisfiamo 3 e la funzionalità dei tuoi IC non dipende e quindi separabile funzionalmente dalla comunicazione, oltre che fisica separabile da un dispositivo di comunicazione (supponiamo che l'unico GSM / modem disponibile fosse un dispositivo USB inserito), allora puoi fidarti il tuo IC non sta inviando i dati all'attaccante facendo in modo che il dispositivo USB non sia fisicamente e collegato in modo funzionale.

Come nel software (come ad esempio essere visto nell'apparmor LSM) l'idea è di limitare ogni IC per isolamento / separazione al solo necessario collegamento funzionale necessario.

Anche se forse è impossibile produrre un IC complesso, potrebbe essere molto più semplice realizzare uno molto meno complesso che si connette semplicemente su richiesta (cioè via software) tramite l'hardware commuta i componenti in base alle loro esigenze attuali. Limitando le connessioni disponibili, è possibile ottenere un po 'di fiducia.