Protezione dei dati su un dispositivo remoto

2

Sfondo

Sto sviluppando un servizio che consiste in un piccolo dispositivo client senza testa (ad esempio OLinuXino) che conterrà dati sensibili.

Il dispositivo verrà collegato a una rete remota (magari dietro un firewall) e il suo obiettivo è quello di aprire automaticamente un tunnel ssh inverso a un server (ad esempio, non presidiato).

Il dispositivo conterrà una chiave per connettersi al server ssh e quella chiave non dovrebbe essere utilizzata su un altro dispositivo.

Il dispositivo verrà distribuito ai clienti in modo che chiunque possa avere accesso fisico ad esso.

Non voglio che qualcuno possa ottenere i dati da un determinato dispositivo e il mio obiettivo è rallentare il recupero dei dati sensibili.

Almeno, se dovesse succedere, vorrei che il server lo rilevasse e bloccasse ogni ulteriore accesso usando la chiave da quel dato dispositivo. In realtà, se qualcuno cerca di fare qualcosa di cattivo con il dispositivo, potrei sicuramente bloccarne l'accesso (e mettere in blacklist quella persona o azienda).

Il dispositivo è una piccola macchina Linux (che esegue Debian Wheezy). Per ora non ho intenzione di utilizzare un chip resistente agli smorzatori (come descritto qui )

Avviso

Ho già sentito parlare di Mandos, ma sembra funzionare solo sulla rete locale, sebbene il mio dispositivo e il mio server si trovino su siti remoti.

Ho letto anche questa domanda: Per lo sblocco remoto dei volumi LUKS tramite SSH, come posso verificare l'integrità prima di inviare la passphrase? e sono consapevole che ciò che voglio raggiungere può essere impossibile. Ma il mio obiettivo qui è quello di aggiungere la massima sicurezza possibile a quel dispositivo.

La mia soluzione attuale: Il mio primo pensiero è quello di crittografare il volume rootfs del dispositivo per proteggere i dati su di esso (basato su questa soluzione ). Quando il dispositivo è acceso, si connette incustodito al server (con initramfs) e apre un primo tunnel ssh inverso (con una chiave per me meno importante da perdere).

Ho intenzione di rimuovere i connettori e / o i driver della tastiera o dello schermo sul dispositivo.

Il server quindi (senza supervisione):

  1. utilizza il tunnel inverso per connettersi al dispositivo;
  2. carica sul dispositivo un programma che controlla che nessun file sia stato modificato;
  3. carica sul dispositivo un piccolo programma che controlla l'hardware del dispositivo (indirizzo cpuid e mac) e lo esegue per ottenere queste informazioni;
  4. se uno dei precedenti non ha funzionato o ha restituito informazioni errate, blocca l'accesso al dispositivo e l'account del cliente (ad esempio il server non li accetterà più per connettersi), eventualmente cancella tutti i dati sul dispositivo;
  5. se i passaggi 2 e 3 sono andati a buon fine, decodifica il volume rootfs e consente il lancio del vero servizio di sistema;

Tutti i filesystem sul dispositivo sono montati in sola lettura usando union filesystem (aufs).

Dopodiché, il primo tunnel inverso viene chiuso e il dispositivo si avvia.

Dopo l'avvio viene aperto un nuovo tunnel con la chiave "reale". A quel tempo, i dati sensibili vengono decifrati nella RAM del dispositivo.

Il mio obiettivo: Il mio obiettivo è proteggere il rootf del dispositivo o una parte dei dati al suo interno, bloccando o rallentando chiunque voglia leggerlo.

Le mie domande

Domanda 1: quali sono i rischi della mia soluzione? quali sono gli exploit possibili per ogni passaggio?

Domanda 2: ci sono altre possibili soluzioni che sarebbero migliori per raggiungere il mio obiettivo?

    
posta lauhub 09.09.2014 - 11:16
fonte

1 risposta

1

Per rispondere alla tua prima domanda: penso che il grosso rischio con il tuo set-up sarebbe che non puoi impedire l'accesso al tuo initramfs. Ciò consentirebbe a un utente malintenzionato di acquisire conoscenze sul proprio set-up, che consente quindi un tipo di attacco MITM completo, accedendo al proprio software (con la chiave privata integrata). Da quel momento le possibilità sono infinite in quanto è possibile decodificare il pacchetto che si desidera inviare al dispositivo, ottenendo l'accesso a quelle chiavi SSH che si desidera mantenere alla massima sicurezza. O magari modificando del codice in modo che tu pensi che tutto vada bene, ma in realtà non lo è.

La rimozione di alcuni connettori non ti aiuterà ad attaccare determinati che potrebbero semplicemente ri-saldare quei connettori. E un attaccante molto determinato con tempo e denaro potrebbe semplicemente fare un pieno dump delle memorie flash e iniziare a lavorare in quel modo.

Il fatto è che la sicurezza fisica apre una vasta gamma di possibilità per attaccare un dispositivo, il che non può quasi mai essere impedito (a meno che non sia intrappolato in macchina o così).

Un altro rischio che vedo è che il tuo set-up è relativamente complesso, quindi le cose potrebbero rompersi. Ad esempio, quando non è possibile aprire un tunnel SSH semplice a causa di una regola del firewall. Oppure, se il software dropbear che si desidera utilizzare ha una vulnerabilità critica esternamente sfruttabile. Come lo risolveresti?

Domanda 2: senza fornire maggiori dettagli su ciò che si desidera effettivamente ottenere con questi dispositivi senza testa, è difficile dare qualche consiglio su quale potrebbe essere una soluzione migliore nel proprio caso. Sembra che tu non abbia assolutamente fiducia nei luoghi o nelle persone che installi quel dispositivo. Che cosa ti fa ancora voler farlo in primo luogo se non c'è affatto fiducia?

    
risposta data 20.01.2018 - 14:26
fonte