[tc] Regole di base per il TC?

Alessandro Bottoni alessandro-bottoni a libero.it
Lun 18 Set 2006 17:54:15 CEST


Davide Vernizzi ha scritto:
> Alessandro Bottoni ha scritto:
>> 1) La generazione delle EK deve essere fatta obbligatoriamente "on
>> deployement", in modo che nemmeno volendolo le aziende abbiano la possibilità
>> di tenersi una copia delle chiavi master ed usarle per risalire al device e 
>> da esso al suo utente. 
> 
> Questo tecnicamente ha qualche problema. Quello che può essere utile, invece, 
> è cercare di avere ogni singola attestazione effettuata utilizzando il 
> protocollo DAA che permette di avere una privacy perfetta senza rilasciare 
> mai la chiave pubblica.

Si, anche. Se devo essere sincero, preferirei comunque che le EK venissero
generate dall'utente o comunque da una terza parte scelta dall'utente. Il fatto
che (secondo i creatori della DAA) non sia possibile risalire alla EK da una o
più AIK non mi rassicura più di tanto. Le ragioni sono tre:
- il manufacturer che installa il TPM può benissimo tenersi un elenco abusivo
delle EK (e tutto il discorso della DAA và subito a farsi fottere)
- incrociando i dati sul traffico (e sommandoli a quelli derivanti dagli IP) si
può arrivare ugualmente a stabilire l'identità (l'IP) comune a più AIK, anche
senza sapere quale EK si trova a monte, e questo è già un bel rischio. Se poi
l'utente fa la cazzata di non usare DAA per una sola di queste identità, la sua
privacy và completamente a farsi fottere anche per tutte le sue altre identità.
- La EK resta comunque accessibile dal software locale (almeno in certi casi).
Deve quindi essere possibile rigenerarla a volontà per compensare eventuali
"leaking", esattamente come si fa con le chiavi di GPG. Ricordo a questo
proposito che alcune applicazioni non si accontenteranno di sapere che sotto
hanno un TPM genuino. In alcuni casi, ne vorranno conoscere l'identità (e qui
DAA non può essere d'aiuto).

E poi, in ogni caso, la EK "marca" il device in maniera (quasi) indelebile e
questo non mi sta bene. Dovrebbe semmai marcare lo user (come una smart card),
visto che la fiducia che è in gioco in rete è (o dovrebbe essere) una fiducia
tra utenti, non tra macchine. Il fatto che tutta la tecnologia delle Trusted
Platform sia stata studiata per verificare _da remoto_ la trustability della
piattaforma mi  sta profondamente sulle balle (almeno nel contesto di Internet
e del libero mercato. Non avrei nulla da dire sull'uso delle TP in contesti
chiusi come le banche e le applicazioni militari).

>> 2) Tutte le funzionalità del TPM devono essere accessibili solo localmente
>> (attraverso una prova di presenza fisica, come la pressione di un tasto), in
>> modo da escludere completamente la possibilità che venga usata la Remote
>> Attestation per rovistare su una macchina da remoto.
> 
> Sì.. o quanto meno tutte devono essere accettate dall'utente proponendo in 
> modo chiaro una richiesta di autorizzazione.

Infatti. Credo che abbiano molta importanza la struttura e la user friendlyness
del software di gestione per queste cose. Appena ho un attimo di tempo butto
giù due righe su questi argomento per spiegare qual'è il problema.

>> 3) Il TPM deve essere prodotto (su licenza) sul territorio nazionale/europeo
>> e/o sotto la sorveglianza delle forze dell'ordine per evitare che venga 
> dotato
>> di feature non richieste.
> 
> Assolutamente d'accordo... mi sembra il minimo

Autarchia! Autarchia!

> Aggiungerei:
> 4) Possibilità di rigenerare la EK sempre e creazione di un meccanismo per 
> validare la nuova chiave in modo da non perdere i privilegi di una macchina 
> TC compliant anche con la nuova chiave (forse mi sono espresso male. Se 
> volete spiegazioni chiedete pure).

Tutto chiaro. Sono d'accordissimo.

> 5) Garanzia di accesso ad Internet, contenuti fondamentali anche per chi non 
> ha un sistema senza TPM o altro.

Sacrosanto!

> 6) Garanzia di accesso ai contenuti protetti in presenza di un qualunque 
> sistema ritenuto sicuro (come un sistema debba essere ritenuto sicuro è una 
> questione difficile, ma se ne può discutere).

Già, se ne può e se ne deve discutere. Comunque, questi rompiballe dovrebbero
imparare ad accontentarsi della sicurezza invece di pretendere anche la
"trustability" della piattaforma utente. Vedi il mio delirio "sicurezza e
fiducia" qui:

http://alessandrobottoni.interfree.it/download/sicurezza_e_fiducia.pdf

>> Fatemi sapere che tipo di reazioni organiche vi dà (erezione, nausea, 
>> sonno...) 
> 
> Reazioni assolutamente positive a questo genere di mail. Credo che sia 
> fondamentale discure in questo modo tra di noi.

Bene! Vedo che si va nella direzione giusta. Vediamo di mettere insieme qualche
proposta sensata da sottoporre al TCG ed al "legislatore".

CU

PS: Vi siete studiati la procedura per la attestation di una piattaforma
locale? Per certi aspetti è fichissima ma per certi altri è francamente
delirante. Ci vuole una Smart Card come dispositivo di interrogazione della
piattaforma. Li voglio proprio vedere gli user alle prese con le Smart Card, le
EK e le AIK...

-- 
------------------------
Alessandro Bottoni



Maggiori informazioni sulla lista tc