[tc] simulazione tpm / RA

[Davide Vernizzi]

In questo momento sono in Germania per un meeting.... la mail è molto
lunga e ci vuole un po' per pensarci. Risponderò la prossima settimana
temo.

On Nov 15, 2007 11:36 AM, Salvatore Caratozzolo
<s.caratozzolo2 a campus.unimib.it> wrote:
> nessun commento? :(
> strano!!
>
> On Wed, 14 Nov 2007 12:51:46 +0200
>   "Salvatore Caratozzolo"
>
> <s.caratozzolo2 a campus.unimib.it> wrote:
> > volevo fare un esempio di una Remote Attestation +
> > controllo PCR con un server!
> > mettiamo di trovarci in una rete aziendale dove ci sono
> >5
> > computer con TPM + un server con TPM.
> >
> > LATO CLIENT
> > la PRIMA VOLTA tutti e 5 i client eseguono Trustedgrub e
> >a
> > SO caricato creano la AIK (una chiave firma creata a
> > partire dalla EK) e la fanno anche autofirmare dal TPM
> > (nel senso che si crea una sorta di digest per evitare
> >la
> > perdita di pacchetti nella rete, se arriva solo mezzo
> > pacchetto almeno con il digest si accorge che manca
> > qualcosa o che il pacchetto è corrotto!).
> > i clients successivamente creano un set di good-values,
> > cioè i valori dei PCR che il server deve accettare per
> > buoni e si registra nel server via http, ad sempio ma
> > poteva essere fatto anche in altri modi giusto?
> > nella registrazione invieranno sia l'AIK che il set di
> > Godd-values!
> > nei set of good-values oltre ai digest presenti nei PCR
> >si
> > inserisce anche il digest della macchina che ospita il
> > server (si potrebbe indicare indirizzo ip + nome
> >macchina
> > o link http) e/o digest di programmi che si vuole essere
> > sicuri che siano originali, volendo si potrebbe eseguire
> > l'extend di due programmi sullo stesso PCR_10, tanto il
> > risultato finale sarà cmq qualcosa di univoco, basta non
> > cambiare l'ordine dell'extend! se estendiamo nel pcr_10
> >i
> > digest di Word e poi di Kate in un successivo riavvio
> > l'ordine deve essere ancora quello altrimenti si ha un
> > digest finale diverso!.
> >
> > LATO SERVER
> > il server ha anch'esso installato Trustedgrub e i digest
> > presenti nei SUOI PCR vengono "assicurati" ,
> >"certificati"
> > ad ogni avvio grazie al SEAL di un file (l' UNseal viene
> > eseguito appena il SO è stato caricato, oppure quando
> > l'amministratore lo richiede in un momento qualsiasi
> >basta
> > che sia prima di ricevere le remote attestation e le
> > configurazioni dei PCR dei clients).
> > se l' UNSEAL avviene correttamente (cioè se i PCR hano
> >dei
> > valori originali) allora fino a quel momento ho tutto
> > nella norma!
> > il server rimane in attesa di richieste di registrazione
> >o
> > di certificazione!
> > mettiamo che sia la prima volta che si esegue il
> > sistema!quindi il server non ha ancora un Database e
> > rimane solo in attesa di una o + registrazioni!
> > attraverso un http server installato nella stessa
> > macchina, riceve i pacchetti
> > AIK_firmato+set-of-good-values da ciascun client e li
> > salva in un suo Database.
> > il Database è cifrato con il TPM con una chiave
> >simmetrica
> > , che a sua volta è cifrata e salvata dentro il TPM con
> > una chiave asimmetrica, questa a sua volta è salvata nel
> > TPM.
> > il DB potrebbe essere benissimo quel file di cui parlavo
> > prima, usato come metodo sicuro che i PCR del boot del
> > server siano allo stato originale.
> >
> > ad ogni successivo avvio ogni client dovrà mandare, dopo
> > che il SO è stato caricato, lo stato dei PCR +
> >AIK_firmata
> > al server e rimanere in attesa della sua risposta come
> > assicurazione che tutto si trovi nella norma!fino a quel
> > momento ogni client deve rimanere bloccato!(mettiamo che
> > durante l'attesa un attaccante con la modifica di un
> > modulo kernel riesca ad aprire documenti e ad inviarli
> >via
> > mail prima che il server mandi la risposta la cosa
> > potrebbe danneggiare la società!!).
> > il server riceve la richiesta, confronta i dati ricevuti
> > con quelli presenti nel DB decifrato dopo il boot e
> > risponde.
> > se i PCR sono allo stato originale allora i client si
> > trovano in uno stato fidato e possono proseguire con il
> > lavoro!
> > mettiamo caso che invece il server sia irraggiungibile o
> > che  sia stato oggetto di un attacco DOS, il client puo'
> > rimanere in attesa al max per 5 mn (esempio!) e proporre
> >a
> > chi sta davanti al pc se rimandare il pacchetto o
> > contattare l'amministatore della rete via telefono!
> > se invece il server risponde negativamente allora il
> > client o manda un'avviso via mail o contatta per sms
> >(come
> > sono fantasioso!!!) all'amministratore!cmq la macchina
> > resta bloccata finchè non viene inserita un psw di root
> > per entrare e finche non viene inserita la owner
> >password
> > del TPM che permetta di fare le opportune modifiche!
> >
> >
> > ok questa visione generale come vi sembra? verosimile?
> > troppo fantasiosa?
> >
> >
> >
> > _______________________________________________
> > tc mailing list - http://itlists.org/notcpa
> > tc a no1984.org
> > http://lists.no1984.org/mailman/listinfo/tc
>
> _______________________________________________
> tc mailing list - http://itlists.org/notcpa
> tc a no1984.org
> http://lists.no1984.org/mailman/listinfo/tc
>



-- 
Davide