.

Le "Endorsement Key" sono una coppia (pubblica e privata) di chiavi crittografiche RSA a 2048 bit usate dei TPM ("Trusted Platform Module", noti anche come "Fritz Chip") delle Trusted Computing Platform per certificare che si tratta di TPM "genuini" e conformi alle specifiche. Queste chiavi servono, ad esempio, per impedire che venga usato un emulatore software (del tutto inaffidabile) al posto di un vero TPM. 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).

Come effetto collaterale, questa coppia di chiavi identifica in modo univoco e non falsificabile il TPM a cui è associata. Si tratta quindi di una situazione simile a quella che si era venuta a verificare con il "Serial Number" del Pentium III: il produttore di software e/o di contenuti multimediali può vincolare l'uso del suo prodotto ad una specifica macchina, identificata dal Serial Number del Pentium III o dalla coppia di chiavi RSA del TPM. 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.

Qual'è il problema con queste chiavi?

Per capirlo, bisogna tenere presente questa situazione:

There are both security and privacy concerns about maintaining this key pair. For security reasons, it must be impossible to export the private key from the TPM, otherwise other entity can pretend to be a TPM (Quello specifico TPM, n.d.r.). Also, access to the public key should be restricted for security reasons. Otherwise, there is a reduced defense against a rogue attempting to take ownership of a TPM.

Private Endorsement Key must be known only to the TPM that holds the endorsement key. The TCPA specification originally required that an endorsement key can be generated on the TPM that holds that particular key. This restriction was later relaxed, however, because of the potentially high costs involved.

So the TCPA specification permits manufacturers to generate an asymmetric key outside a TPM and inject the key into the TPM, instead of generating the key inside the TPM. Such a process is standard in the smart card marketplace and should not be a cause for concern. The TCPA specification mandates that injected key must be as secure and as private as those generated inside the TPM. This means that the injection must be done in a secure environement and that the key injection equipement must forget the keys after it has injected them.

Da "Trusted Computing Platforms – TCPA Technology in context"
edited by Siani Pearson
HP Professional Books, Prentice-Hall, 2002
ISBN 0-13-009220-7
Pagina 124

A questo punto, la domanda dovrebbe essere ovvia: "Che succede se la casa produttrice del TPM, o del PC che noi acquistiamo, od un loro dipendente, si tiene abusivamente una copia delle nostre chiavi?"

Come è prevedibile, possono succedere diverse cose, tutte molto sgradevoli:

1. Qualcun'altro può usare la identità digitale del nostro TPM per spacciarsi per la nostra macchina e quindi per noi. Se considerate che uno degli usi caratteristici delle Trusted Platform sarà la protezione dei traffici finanziari, questo vuol dire che qualcuno potrebbe acquistare l'auto a nostro nome, tenersi l'auto e lasciare a noi il debito.
2. Qualcun'altro può usare la nostra identità digitale per decifrare i messaggi riservati a noi diretti o per accedere ad un canale di comunicazione che dovrebbe essere a noi riservato. Un caso interessante è il canale cifrato SSL3.0 che usiamo noi tutti per accedere ai servizi di home banking.
3. Qualcuno potrebbe prendere possesso del nostro sistema (e di quelli che dipendono da esso) ed estrometterci. Se questo sistema dovesse essere quello che controlla il lancio di un missile, il problema non sarebbe solo nostro.

Di conseguenza, è abbastanza ovvio che la coppia di chiavi crittografiche con cui ci è stata consegnata la macchina deve essere sostituita con un'altra, nota solamente a noi, il prima possibile.

D'accordo, ma come si fa?

Diciamo subito che non sempre questo è possibile. Il produttore infatti ha la possibilità tecnica di inserire nel TPM delle chiavi di tipo "non revocabile". In questo caso, non è proprio possibile sostituire le vecchie chiavi con le nuove.

Anche nei casi in cui le chiavi sono di tipo revocabile ("sotituibile"), non è affatto detto che la loro sostituzione sia semplice. La sezione 14 delle specifiche del TCG che riguardano i comandi del TPM è illuminante a questo proposito:

14. TPM_CreateRevocableEK

Start of informative comment:

This command creates the TPM endorsement key. It returns a failure code if an endorsement key already exists. The TPM vendor may have a separate mechanism to create the EK and "squirt" the value into the TPM.

The input parameters specify whether the EK is capable of being reset, whether the AuthData value to reset the EK will be generated by the TPM, and the new AuthData value itself if it is not to be generated by the TPM. The output parameter is the new AuthData value that must be used when resetting the EK (if it is capable of being reset). The command TPM_RevokeTrust must be used to reset an EK (if it is capable of being reset).

Owner authorisation is unsuitable for authorizing resetting of an EK: someone with Physical Presence can remove a genuine Owner, install a new Owner, and revoke the EK. The genuine Owner can reinstall, but the platform will have lost its original attestation and may not be trusted by challengers.

Therefore if a password is to be used to revoke an EK, it must be a separate password, given to the genuine Owner.

In v1.2 an OEM has extra choices when creating EKs.

a) An OEM could manufacture all of its TPMs with enableRevokeEK==TRUE.

If the OEM has tracked the EKreset passwords for these TPMs, the OEM can give the passwords to customers. The customers can use the passwords as supplied, change the passwords, or clear the EKs and create new EKs with new passwords. If EKreset passwords are random values, the OEM can discard those values and not give them to customers. There is then a low probability (statistically zero) chance of a local DOS attack to reset the EK by guessing the password. The chance of a remote DOS attack is zero because Physical Presence must also be asserted to use TPM_RevokeTrust.

b) An OEM could manufacture some of its TPMs with enableRevokeEK==FALSE. Then the EK can never be revoked, and the chance of even a local DOS attack on the EK is eliminated.

End of informative comment.

This is an optional command

Da: TCG TPM Specification Version 1.2 Revision 94

In altri termini, è necessaria una password fornita dal costruttore per effettuare questa operazione. Inoltre, i dettagli della procedura sono lasciati alla discrezione del produttore per cui possono essere diversi da produttore a produttore. In linea di principio, questa procedura potrebbe anche richiedere che il cliente contatti l'azienda produttrice (ad esempio per telefono) per richiedere questa password. Non è obbligatorio che l'azienda la fornisca. Non è nemmeno obbligatorio che la l'azienda la fornisca gratuitamente. Infine, non è detto che questa procedura debba essere semplice da eseguire. L'azienda produttrice potrebbe decidere di renderla volutamente complessa per motivi di sicurezza.

Per quanto mi è dato di sapere, in questo momento (Settembre 2006), nessuna azienda che produce PC dotati di TPM e di funzionalità Trusted Computing fornisce all'utente nè la password per la revoca delle EK esistenti, nè le necessarie informazioni su questo problema, nè una documentazione che gli permetta di eseguire correttamente questa delicata procedura. In realtà, non si può nemmeno dare per scontato che la piattaforma come tale disponga effettivamente degli strumenti software (a livello del BIOS o del Sistema Operativo) necessari per eseguire questa operazione e previsti dalle specifiche TCG.

Anche quando sono disponibili gli strumenti necessari e la procedura è opportunamente documentata, non è ugualmente detto che sia possibile eseguire la sostituzione delle chiavi. Tecnicamente, infatti, non è sufficiente cancellare le chiavi esistenti e rimpiazzarle con altre. Per essere accettate dagli interlocutori, le chiavi del TPM devono essere certificate da un ente esterno, cioè una "Certification Authority" analoga a quella che rilascia i certificati digitali usati dai server web SSL (quelli usati abitualmente dalle banche per i servizi di home banking, per capirci).

Questa procedura di certificazione viene usata per separare la chiave dalla identità della macchina. La Trusted Platform che vuole certificare la nuova chiave contatta la Certification Authority e le invia un messaggio (un testo qualunque) firmato con la sua nuova chiave privata. La Certification Authority fa i controlli che ritiene più opportuno fare e, se è soddisfatta del risultato, rilascia un certificato digitale che asserisce che i messaggi firmati con quella chiave provengono da un TPM "fidato". In tutte le successive transazioni, il TPM presenta solo questo certificato, in modo da non rivelare mai la sua identità. I suoi interlocutori si fideranno del TPM se e quanto si fidano della Certification Authority. Di conseguenza, per generare una nuova coppia di chiavi ci vuole una Certification Authority. Per una grossa azienda questo non è un problema ma può esserlo per un privato cittadino.

In buona sostanza, l'acquirente di una Trusted Computing Platform deve tenersi l'identità che gli è stata assegnata dal costruttore della macchina, anche se, come abbiamo visto, questo rappresenta un serio rischio per la sua sicurezza.

C'è da preoccuparsi?

Direi proprio di si. Da un lato, diverse aziende coinvolte nella progettazione, produzione distribuzione di TPM e di Trusted Computing Platforms sono note per avere già abusato pesantemente della fiducia dei loro clienti in passato. Mi limiterò a citare qui alcuni casi eclatanti:

1. Intel è la stessa azienda che ha cercato di infilare un "Serial Number" nelle sue CPU senza dare troppo nell'occhio, in modo che fosse possibile identificare con certezza ogni singola CPU. La reazione indignata del pianeta intero ha costretto Intel ad abbandonare questa pratica con le CPU successive.
2. Sony, che fa parte del TCG, è la stessa azienda che è stata recentemente condannata e multata per avere abusivamente installato un rootkit sui PC degli utenti che avevano acquistato alcuni suoi titoli musicali su CD (Sony produce computer e vende CD musicali.
3. Microsoft... beh, è sempre Microsoft. È la stessa azienda che ha anni fa cercato di impadronirsi delle informazioni personali degli utenti con il Progetto "Passport". È la stessa azienda che ha inventato l'odioso sistema di "Product Activation"e di Windows XP. Solo qualche mese fa Microsoft ha tentato di installare silenziosamente sui PC degli utenti un programma (Genuine Windows Advantage) che sarebbe servito a rilevare eventuali copie abusive dei suoi programmi. Non sono in molti a fidarsi di questa azienda, ormai.

Dall'altro, la posta in gioco è molto alta: se, come previsto, le Trusted Platform si diffonderanno anche in ambiti militari, di governo, di intelligence, di polizia e nel mondo dei servizi (banche, centrali elettriche, etc.), la CIA o la NSA potrebbero ottenere un potere immenso se riuscissero a convincere le aziende produttrici dei TPM (quasi tutte americane) a consegnare loro una copia delle Endorsement Key dei TPM prodotti. 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. Potrebbero impersonare qualunque PC, estromettere i legittimi proprietari dalle macchine esistenti e prenderne il controllo. Per distruggere l'odiata Cina, sarebbe sufficiente sfruttare questa possibilità per prendere possesso dei loro sistemi di controllo e lanciare i loro stessi missili contro le loro città.

Con una posta così alta in gioco, e degli attori così poco affidabili, è solo questione di tempo prima che qualche azienda cominci a vendere al migliore offerente le chiavi RSA dei TPM che produce.

Se queste considerazioni non sono sufficienti a farvi preoccupare, beh, non so proprio cos'altro potrebbe riuscirci.

Links:

La Spina nel Fianco

No1984

Trusted Computing Group