Dipende molto da ciò che stai affrontando (il tuo scenario ).
Un utente "normale" può essere considerato affidabile con una macchina headless e un'installazione Linux chiusa, chiudendo semplicemente GRUB. Questo e un adeguato contratto / licenza sarebbero sufficienti. Puoi scollegare tastiera e mouse dalla scheda madre, sigillare l'unità e esportare solo il tuo servizio e SSH.
Il livello successivo è la crittografia del disco: un tipo più sofisticato ma ancora bagnato dietro le orecchie proverà a montare il disco da un'altra macchina, e potrebbe anche non sapere che esiste una cosa come una ext4 o una NTFS - possibilmente "Il disco deve essere formattato!" sarà sufficiente a spaventarlo, o proverà con un lettore extfs e non sarà in grado di accedere alla partizione crittografata.
Questo è più o meno dove vorresti fermarti. L'aggiunta aggiunge complessità e non può ancora raggiungere la sicurezza totale .
Il livello successivo è un utente abbastanza esperto da capire che se il disco è crittografato eppure si avvia , significa che la sequenza di avvio ha accesso alla chiave di decodifica. Ho sentito di driver sperimentali (che lavorano principalmente attraverso l'oscurità) che nascondono la chiave in posti strani, dalla memoria CMOS inutilizzata alle EEPROM esterne, ma come dice la vecchia battuta, abbiamo già stabilito come andrà a finire, ora discutiamo solo del prezzo - quanti sforzi saranno necessari da un determinato hacker con accesso completo all'hardware per irrompere. Perché se è determinato abbastanza, farà .
Esistono driver (e dispositivi hardware non rilevabili e metodi di virtualizzazione) che consentono di intercettare sia la porta parallela che il traffico USB. Controllando l'orologio hardware e l'I / O, diventa possibile un attacco di replay che consente l'avvio in un sistema manomesso, consentendo quindi l'accesso al disco decrittografato dal "fuori" di una VM o avviando servizi aggiuntivi che consentano lo stesso. Quindi è necessario aggiungere sofisticati meccanismi di autocontrollo per evitare questo.
A questo punto, controlla le risposte al nuovo problema e considera l'utilizzo di un PC appositamente progettato dove non è possibile rimuovere il disco rigido. Ricorda che "non posso" significa che tu e io non potremmo, ma Chuck Norris qualcuno (di nuovo: abbastanza determinato, abbastanza ricco, abbastanza informato, abbastanza spietato ) can.
Qualcosa che potresti provare (e ancora non fornisce una sicurezza completa) è quello di richiedere che la macchina sia sempre connessa a Internet. Sì, i dati sono al sicuro all'interno e non escono, ma quando si avvia , la macchina può accedere a un server esterno e ottenere la sua password di decrittografia da lì usando uno schema resistente agli attacchi di replay.
Ovviamente, se ti trovi contro un hacker determinato, un giorno la macchina che si connette al tuo server non sarà la macchina reale ma una parte di codice sovvertito che tenterà di rubare la chiave di decrittazione. Con un po 'di fortuna, tuttavia, questo non riuscirà al primo tentativo e nei registri di keyserver vedrai una sequenza di alcuni riavvii e richieste chiave mentre il ragazzo supera le difese.
Un'altra possibilità sarebbe quella di consentire all'utente di inserire una risposta a una sfida via SMS. Ciò garantirebbe al cliente che il server non può esporre nulla e che avresti ancora una sorta di impulso sulla situazione.
Modifica dell'architettura
Un'altra possibilità che mi viene in mente è che il PC dell'utente contiene i loro dati, ma non contiene il tuo servizio . Questo viene scaricato direttamente in memoria in modo sicuro da Internet ed eseguito ad ogni avvio. Avresti bisogno di un'applicazione "supervisore" che ne esaminasse l'ambiente e ne determinasse la sicurezza e la non-compatibilità, quindi le richieste tramite SSL e la presentazione di una chiave di licenza l'ultima versione dell'applicazione binaria dal tuo server. Il download binario e inizia a fare quello che deve fare sui dati nel PC di destinazione, senza mai essere salvato su disco.
Il server può verificare l'indirizzo IP del chiamante se appartiene a una rete di clienti noti.
Ora l'attaccante deve ingannare l'applicazione supervisore (che ancora connettere e richiedere un binario anche se rileva un ambiente manomesso, lo farà semplicemente includendo un suggerimento sottile che agisce sotto costrizione - un " simbolo di buona fortuna hawaiana " se lo si desidera), e a meno che l'attaccante non sia il cliente stesso, anche ingannare il server e impadronirsi del computer. Ancora possibile, intendiamoci, ma molto più difficile.