[e-privacy] CS: Server sicuri

Sat Jul 9 15:15:45 CEST 2005

L'idea e' buona, ma richiede tempo di sviluppo, e non mette a
priori al sicuro da tutto; chi ti dice che il /dev/kmem che
vai a testare non sia in realta' una macchina vistuale vmware
od UML che gira dentro un supervisore, il quale puo' monitorare
qualunque cosa ?

Io continuo a pensare ad una soluzione pratica (quasi) immediata,
 evolvibile nel tempo, fatta di 3 componenti

1) una sede il piu' sicura e/o il piu' ispezionabile possibile

2) una macchina con un sigillo che non sia falsificabile, e che
    faccia il boot solo da hdu. Anche semplice, tipo quella
    adottata dal Flug del foglio di carta con le firme incollato
    sulle viti del case.

3) un meccanismo di boot come quello proposto sul documento
    del cifroserver (un sistema minimale boota, lancia un demone
    ssh limitato e magari un messaggio di posta, e poi aspetta
    un login da remoto con certificato e password. Allora
    decripta il disco su cui c'e' tutto e fa l'equivalente di
    un chroot, continuando il boot da li. La cosa non e'
    cosi' semplice ma dovrebbe essere realizzabile con un
    paio di accorgimenti. Leonardo e Leandro potrebbero
    spegare meglio la cosa.

Chiaramente, se il punto 3 non e' dimostrabilmente sicuro,
ricevendo la richiesta di password potrei avere il dubbio che me
la stia chiedendo un sistema compromesso fisicamente. La cosa
e' pero' molto pratica comunque, perche'

1) se ho urgenza di far ripartire il server, gli do' la pwd ed
appena possibile vado a verificare il sigillo
2) altrimenti prima verifico il sigillo e poi lo faccio ripartire

La soluzione non e' perfetta, ma e' abbastanza pratica ed adattabile,
 e mi porta comunque a poter rilevare con certezza se il server 
 e' stato compromesso o no

Problema aperto: verificare il sigillo, in maniera affidabile,
 da remoto.

Bella domanda. Ad intuito, potrei dire che una soluzione solo
 software non mi sembra praticabile, ma che deve avere anche
 una componente hardware.  Una rom incollata nel sigillo che si
 rompa con certezza in caso di manomissione, interrogabile ?

JM2C.   Marco

<
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- 
> 
> 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
-- 

+--------------- http://www.winstonsmith.info ---------------+
| il Progetto Winston Smith: scolleghiamo il Grande Fratello |
| the Winston Smith Project: unplug the Big Brother          |
| Marco A. Calamari marcoc at dada.it http:// www.marcoc.it     |
| DSS/DH:  8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B |
+ PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 ----------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050709/1b23bfd6/attachment.pgp>