[e-privacy] CS: Server sicuri

[Michele Carla`]

On Sat, 2005-07-09 at 01:43 +0200, Emanuele Olivetti wrote:
> On Fri, Jul 08, 2005 at 03:41:35PM +0200, Marco A. Calamari wrote:
> > Sarebbe IMHO opportuno che le varie persone interessate a discutere
> >  sull'argomento server sicuri (particolarmente dal punto di vista
> >  della privacy, ma anche in generale) lo facessero insieme
> >  e pubblicamente.
> > ...
> 
> Condivido pienamente il tuo parere e gia' che ci sono aggiungo
> altri cents al dibattito, sperando siano utili in un qualche modo.
> 
> -
> 
> Problema: ottenere un server con partizioni crittate che possa fare
> reboot senza l'intervento fisico di chi ha le passwd (solo intervento
> da remoto, automatizzabile) e in contemporanea che non possa essere
> alterato (leggasi "modificate le parti in chiaro se ci sono e
> lette/modifcate le parti crittate") da chiunque abbia accesso fisico
> alla macchina ma non abbia le passwd, pena l'inutilizzabilita' del
> sistema stesso.
> 
> Questo insomma e' un rompicapo.
> 
> Idee per una soluzione, nate anche da alcune discussioni con
> un collega:
> 
> - definizione del problema -
> chiamo A il server che vorremmo fosse "sicuro", situato in un luogo
> che non possiamo raggiungere rapidamente e chiamo B quello che A
> contattera' remotamente per recuperare le password che gli servono per
> montare le proprie partizioni crittate. A e' composto infatti di una
> parte A1 in chiaro (che gli permette di fare boot e poco altro ed e'
> _minimale_) e una parte A2 crittata che contiene servizi e dati da
> proteggere. A1 fa il boot e contatta B per chidere la passwd per poter
> montare ed eseguire A2. E' d'obbligo che A1 si debba autenticare
> presso B per esempio con un certificato ecc. ecc.
> 
> A proposito, B e' considerato sicuro (almeno quello!); supponiamo sia
> il server che teniamo gelosamente nel caveau dell'azienda.
> 
> Il punto debole del sistema fin qui descritto e' proprio A1, perche'
> se qualcuno di non autorizzato ci mette mano (basta un cd knoppix)
> tutto l'impianto di sicurezza cade.
> 
> Il problema iniziale puo' quindi essere riformulato cosi': e'
> possibile fare in modo che B possa essere sicuro che A1, che gli sta
> chiedendo le preziose passwd, non sia stato alterato rispetto
> all'installazione iniziale?
> 
> - Idea -
> L'idea della soluzione e' che B ponga un "problema" ad A1 la cui
> soluzione sia calcolabile solo se A1 non viene alterato. B pone ad A1
> un problema differente ogni volta che viene contattato e restituisce
> le password solo se la soluzione fornita da A1 e' ogni volta corretta.
> 
> - Procedimento -
> Supponiamo che A1 sia un sistema cosi' minimale che ogni volta che
> riparte faccia _esattamente_ le stesse operazioni con gli stessi
> risultati; questo vuol dire eliminare tutto cio' che dipende da
> /dev/random o che ha a che fare con gettimeofday() e cose del
> genere. Non so se sia possibile farlo. E' un punto aperto :)
> 
> Assunta per vera questa minimalita' di A1, possiamo allora ritenere
> che lo stato della memoria di A1 evolva in maniera _identica_ ad ogni
> reboot. Per identica intendo identica byte per byte e quindi per
> esempio 'md5sum /dev/mem' eseguito sempre allo stesso punto
> dell'inizializzazione del sistema deve ritornare sempre esattamente lo
> stesso risultato.
> 
> A questo punto B, per assicurarsi che A1 non sia stato alterato, gli
> manda un programmino da eseguire che alteri lo stato della memoria
> (questo e' quello che inizialmente ho chiamato il "problema"). A1 lo
> esegue e risponde a B nuovamente con qualcosa tipo 'md5sum /dev/mem'
> (che e' quello che ho chiamato "soluzione"), cioe' qualcosa che
> identifichi il nuovo stato della memoria. Il programmino in questione
> e' differente di volta in volta in maniera impredicibile per
> A1. Supponiamo che B conosca a priori il risultato della hash che A1
> sta calcolando [*] e sappia determinare quindi se A1 e' stato alterato
> oppure no. Se la soluzione di A1 e' corretta allora B gli manda le
> passwd per montare A2 e far partire il resto del sistema (i servizi)
> che andavano protetti, altrimenti gli manda una pernacchia :)
> - Fine del procedimento- 
> 

mi sembra molto contorto, e potenzialmente pieno di falle !
realizzare una situazione di questo tipo mi pare mooolto complesso, non
e` detto che ad ogni reboot la macchina si comporti sempre allo stesso
modo... ci sono veramente troppe variabili in gioco !
inoltre come fa B ha sapere se l'hash inviatoli da A1 e` corretto, se B
puo` predirlo perche` non puo` farlo anche qualcun altro che sta nel
mezzo ?

il problema e` classico, e credo lo sia anche la soluzione (vedi
cellulari gsm) !
la soluzione secondo me:
l'autenticazione fra B e A1 avviene tramite un meccanismo di
"challenge-response" (termine fighetto ...per dire esattamente quello
che dicevi te).

premessa: B e A1 conoscono una password segreta, in possesso solo a
loro, inaccessibile a chiunque altro ! (poi spieghero` come)

1) B "sfida" A1 inviandoli una sfilza di numeri random
2) A1 critta (con un qualunque algoritmo simmetrico prestabilito) i
numeri che ha ricevuto da B utilizando la password segreta
3) A1 invia i numeri crittati a B
4) B critta a sua volta gli numeri con la password segreta e lo stesso
algoritmo usato da A1
5) B confronta la stringa crittata che ha ricevuto da A1 e quella che ha
calcolato, se combaciano ...allora A1 e` veramente A1 !

com'e` possibile fare in modo che A1 conosca la password segreta senza
che questa possa essere recuperata pur avendo accesso fisico alla
macchina ?
questo e` un po` piu` palloso:
infatti se la password fosse memorizzata sul HD chiunque con accesso
fisico alla macchina potrebbe ottenerla... quindi ?
la soluzione e` memorizzare la passowrd sullo stesso chip che contiene
l'impementazione (hardware o software) dell'algoritmo crittografico...
esistono in commercio microcontrollori o logiche programmabili, che una
volta programmate non possono essere rilette ! (almeno in modo semplice)
...soprattutto se uno chiude il circuito in una scatola di carburo di
tungsteno con pareti spesse 6 centimetri

...questo e` quanto !

dubbio: supponendo di avere una macchina blindata e inattaccabile...
cosa succede se la postale si presenta a casa di qualche roots chidendo
le password (segreto istruttorio... ???)...

> So che e' un'idea un po' bizzarra, ma almeno rilancio la discussione.
> 
> Qualunque critica (anche la piu' aspra) e' ovviamente ben accetta.
> 
> Ciao a tutti,
> 
> Emanuele
> 
> [*]: o perche' ne ha gia' fatte calcolare in anticipo una gran
> quantita' ad A1, inizialmente quando A1 non era ancora stato messo in
> produzione in una locazione distante, oppure perche' ha una copia
> fisicamente identica ad A1 accanto a lui a cui fornisce gli stessi
> "problemi" e che quindi deve rispondere allo stesso modo di A1.
> 
> 
> _______________________________________________
> e-privacy mailing list
> e-privacy at firenze.linux.it
> https://lists.firenze.linux.it/mailman/listinfo/e-privacy
-- 
Michele Carla` <goldfinger at member.fsf.org>