[e-privacy] CS: Server sicuri

[Emanuele Olivetti]

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- 

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.