Intel vpro (il trusting nascosto)

[Riccardo Furlan]

167_@... scrive il 5/2/2007 10:47 AM:
>
> problema gia' risolto , visto che la HP rende illegale non accettare
> la licenza di XP

HP non legifera. HP non può rendere illegale niente.

HP propone un contratto commerciale (legalmente valido, fino a prova
contraria), che si può accettare o meno.
Si può scegliere di comprare hardware HP o di un altro costruttore, che
abbia contratti più seri e non lesivi dei diritti dei consumatori.


ciao
mala
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc

[Daniele Masini]

Davide Vernizzi ha scritto:

> Insisto. Dai comandi del TPM versione 1.2 Rev 94 [1]:
>
> 14.1 TPM_CreateEndorsementKeyPair
> This command creates the TPM endorsement key. It returns a failure code
> if an
>  endorsement key already exists.
>  
> 14.2 TPM_CreateRevocableEK
>
> e
>
> 14.3 TPM_RevokeTrust
> This command clears the EK and sets the TPM back to a pure default
> state. The generation
> of the AuthData value occurs during the generation of the EK. It is the
> responsibility of the
> EK generator to properly protect and disseminate the RevokeTrust AuthData.
>
> Come si vede se la EK è stata creata revocabile (usando il comando 14.2)
> e se chi ha creato
> la EK fornisce AuthData (che è una specie di password che serve a
> revocare la chiave), l'owner
> del TPM può rigenerare la EK.

Già. SE chi ha creato la EK fornisce le info opportune...
Ma c'è quel SE che mi piace molto poco (per non dire di peggio).

> Non serve avere una versione diversa del TPM, basta avere un TPM 1.2 con
> chiavi revocabili,
> essere l'owner ed essere in possesso di AuthData. È un problema tra
> l'acquirente e il
> manufacturer.

Il fatto è che l'utente medio non coglierà mai queste "sottigliezze".
E comunque rimarrebbe il problema dei certificati eventualmente
associati alla vecchia EK.
Sinceramente preferisco i sistemi di sicurezza precedenti al TC.

Saluti,

Daniele

--
Registered GNU/Linux User # 335746
http://www.vandali.org/DanieleMasini
GPG fingerprint: 444A 193A 28C2 2A99 1966 B2A5 4216 2453 4272 1648
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc

[Davide Vernizzi-2]

On 5/2/07, Daniele Masini <d.masini@...> wrote:

Già. SE chi ha creato la EK fornisce le info opportune...
Ma c'è quel SE che mi piace molto poco (per non dire di peggio).

Su questo non posso che darti piena ragione. Ma il punto centrale è
che il problema non è avere o meno un TPM, ma avere un TPM
"decente" .

In ogni caso il problema della EK lo vedo non troppo grave, almeno in
teoria. Le chiavi sono protette con la SRK che è generata dall'utente.
L'EK serve solo come garanzia che il TPM è genuino ed in teoria non
dovrebbe mai uscire dal TPM se non per richiedere un AIK o delle
credenziali DAA.
Il vero problema resta la remote attestation: quali informazioni vengono
richieste durante la RA e come vengono calcolate queste informazioni?

> Non serve avere una versione diversa del TPM, basta avere un TPM 1.2 con
> chiavi revocabili,
> essere l'owner ed essere in possesso di AuthData. È un problema tra
> l'acquirente e il
> manufacturer.

Il fatto è che l'utente medio non coglierà mai queste "sottigliezze".
E comunque rimarrebbe il problema dei certificati eventualmente
associati alla vecchia EK.
Sinceramente preferisco i sistemi di sicurezza precedenti al TC.

Non capisco cosa c'entrino ora i certificati vecchi.. una volta rigenerata
la EK i certificati vecchi possono essere distrutti senza rimpianti.
I sistemi pre-TC... il TC è una tecnologia sicuramente interessante con
alcuni spunti che possono essere utili ed altri che sicuramente possono
essere dannosi. Per quel che mi riguarda come ricercatore e come
utente il mio lavoro deve essere quello di identificare gli aspetti utili
ed usarli sbarazzandosi di quelli dannosi.

--
Davide
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc

[Alessandro Bottoni-2]

Ne abbiamo parlato estesamente a Settembre dell'anno scorso:

http://oceanidigitali.it/drupal/EK_regeneration

Alessandro Bottoni
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc

[Davide Vernizzi-2]

On 5/2/07, Alessandro Bottoni <alessandro.bottoni@...> wrote:

Ne abbiamo parlato estesamente a Settembre dell'anno scorso:

http://oceanidigitali.it/drupal/EK_regeneration

"Nel funzionamento quotidiano, vengono usate soprattutto come chiavi "master" con cui vengono firmate e certificate le chiavi di secondo livello generate dal TPM ed usate per i normali compiti crittografici (cioè, ad esempio, le "Attestation Identity Key", o AIK)."

Non sono d'accordo.. la EK serve per richiedere una AIK (provando la genuinità del TPM), ma le chiavi vengono firmate e protette con la SRK che è rigenerabile dall'utente.

"Nello stesso modo, un eventuale fornitore di servizi in rete (home banking, ad esempio) può vincolare l'accesso al suo servizio ad una certa macchina."

Anche qui mi sembra leggermente inesatta la cosa... può avvenire se il fornitore del servizio e la PrivacyCA che certifica l'AIK colludono, mentre se questo non avviene oppure se si utilizza il protocollo DAA risalire all'EK a partire dall'AIK o dalle credenziali DAA è impossibile.
Ma di nuovo, il problema sta al di fuori dei confini del TPM, ovvero nell'implementazione del servizio.

"Non solo potrebbero decifrare praticamente qualunque messaggio inviato tra due macchine su questo pianeta ma potrebbero inviare a loro volta messaggi indistinguibili da quelli legittimi"

Dissento su questo punto... non si può usare l'EK per firmare altro che non sia una richiesta di certificato per l'AIK o per le credenziali DAA.
Il TPM non può avere alcuna idea di quello che sta facendo il sistema operativo soprastante. Se, ad esempio, sto comunicando con qualcuno proteggendo i dati usando PGP, non vedo come un'organizzazione a caso (ad esempio NSA), anche essendo in possesso della mia coppia EK possa essere in grado di rompere la sicurezza delle mie comunicazioni PGP... sempre a patto che io stia usando un sistema operativo di cui mi fido.

--
Davide
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc

[Alessandro Bottoni-2]

Davide Vernizzi ha scritto:

> "Nello stesso modo, un eventuale fornitore di servizi in rete (home
> banking,
> ad esempio) può vincolare l'accesso al suo servizio ad una certa macchina."
>
> Anche qui mi sembra leggermente inesatta la cosa... può avvenire se il
> fornitore del servizio e la PrivacyCA che certifica l'AIK colludono, mentre
> se questo non avviene oppure se si utilizza il protocollo DAA risalire
> all'EK a partire dall'AIK o dalle credenziali DAA è impossibile.
> Ma di nuovo, il problema sta al di fuori dei confini del TPM, ovvero
> nell'implementazione del servizio.

Questo è uno dei punti deboli cruciali del TC: il TC difende il sistema
(non certo l'utente) da attacchi /esterni/. Non tenta nemmeno di
difendere il sistema e/o l'utente da un comportamento scorretto dei
produttori e/o degli operatori /interni/ del sistema.

Purtroppo, come la storia insegna, sono proprio i produttori e gli
operatori interni al sistema a rappresentare la vera minaccia (per
l'individuo, il mercato e la democrazia), specialmente in un mondo, come
quello neo-con di George W. Bush, dove si teorizzano e si giustificano
la menzogna e la manipolazione degli utenti a "fini superiori".

> "Non solo potrebbero decifrare praticamente qualunque messaggio inviato tra
> due macchine su questo pianeta ma potrebbero inviare a loro volta messaggi
> indistinguibili da quelli legittimi"
>
> Dissento su questo punto... non si può usare l'EK per firmare altro che non
> sia una richiesta di certificato per l'AIK o per le credenziali DAA.
> Il TPM non può avere alcuna idea di quello che sta facendo il sistema
> operativo soprastante. Se, ad esempio, sto comunicando con qualcuno
> proteggendo i dati usando PGP, non vedo come un'organizzazione a caso (ad
> esempio NSA), anche essendo in possesso della mia coppia EK possa essere in
> grado di rompere la sicurezza delle mie comunicazioni PGP... sempre a patto
> che io stia usando un sistema operativo di cui mi fido.

Se si entra in possesso di una copia delle EK di una macchina, la si può
emulare in tutto e per tutto, impadronendosi della sua identità ed
agendo al suo posto. Mi sembra un po' difficile sostenere che non si
possano interecettare e decifrare i messaggi che sono diretti agli
utenti del sistema, anche se ti posso concedere che potrebbe esistere un
secondo strato crittografico (GPG) che protegge questi dati.

Il problema è che questo secondo strato crittografico esiste solo se
l'utente lo crea esplicitamente e lo utilizza. Diversamente, l'unico
arbitro e l'unico garante della sicurezza resta un TPM che può essere
"fotocopiato" dal suo produttire (cioè dal gioverno che lo controlla e/o
da qualunque malintenzionato che lavori per il produttore).

CU

Alessandro Bottoni
_______________________________________________
tc mailing list - http://itlists.org/notcpa
tc@...
http://lists.no1984.org/mailman/listinfo/tc