jump to navigation

Il Database delle Chiavi RSA dei Fritz Chip February 28, 2006

Posted by laspinanelfianco in Trusted Computing.
7 comments

Come noto, ogni TPM (Fritz Chip) è identificato univocamente da una coppia di chiavi crittografiche RSA a 2048 Bit. Non sono io a dirlo ma David Safford, il ricercatore IBM autore dell’unico documento (peraltro solo semi-ufficiale) che sia stato scritto a difesa del Trusted Computing, il famoso “rebuttal“. Ecco come Safford descrive questo identificatore in un suo articolo apparso su Linux Journal:

The TPM stores three important keys in non-volatile memory. The endorsement key is a 2,048-bit RSA public and private key pair, which is created randomly on the chip at manufacture time and cannot be changed. The private key never leaves the chip, while the public key is used for attestation and for encryption of sensitive data sent to the chip, as occurs during the TPM_TakeOwnership command. Because this key is sensitive from a privacy perspective, its use can be disabled completely by the TPM owner.

Si tratta quindi di una coppia di chiavi RSA a 2048 Bit. La chiave privata non lascia mai il chip e viene usata per testarne l’identità. La chiave pubblica viene usata per cifrare i dati inviati al chip e per altre funzioni. Secondo le specifiche, la chiave pubblica può essere “disabilitata” in modo da preservare la privacy degli utenti.

Per capire come sia possibile conoscere con certezza l’identita del chip bisogna capire come funziona un sistema crittografico a chiave pubblica. Vi consiglio di leggere qualcosa su questo argomento a Wikipedia, ad esempio questo articolo sulla Public Key Cryptography o questo articolo su RSA. In poche parole, l’identificazione del chip è possibile grazie al fatto che un documento cifrato con la chiave pubblica (di cui disponiamo) può essere decifrato solo dalla corrispondente chiave privata (mantenuta segreta all’inteno del chip). La procedura di identificazione del chip è quindi simile alla seguente (in realtà è diversa ed un po’ più complessa, ma per i nostri scopi basta questa rappresentazione).

  1. Ci si procura la chiave pubblica del chip che si vuole identificare (da un database pubblico o da un archivio creato in occasione di un precedente contatto con il chip in questione).
  2. Si cifra un documento qualunque con questa chiave e lo si invia al chip da “certificare”.
  3. Se il chip riesce a decifrare il documento e ad inviarcene la copia in chiaro, allora è il chip “giusto”.

Per questo motivo, se si disabilita la chiave pubblica diventa impossibile verificare l’identità del Fritz chip.

Prima di procedere, vi prego di notare alcuni punti.

  1. La coppia di chiavi viene generata, sempre e comunque, in fase di produzione del Fritz Chip cioè “in fabbrica”, fuori dal controllo dell’utente finale.
  2. Disabilitare la chiave pubblica vuol dire rinunciare ad accedere ai documenti cifrati da sistemi Trusted Computing, in particolare quelli usati dai sistemi DRM e ERM. In pratica, vuol dire tagliarsi fuori dal mondo con le proprie mani.

A questo punto dovrebbe essere ben chiara l’importanza di queste chiavi RSA per la privacy dell’utente e per la sua possibilità di accedere all’universo digitale che si va creando grazie al Trusted Computing (tra cui Internet).

Ora poniamoci una domanda cruciale: “Per identificare con certezza un Fritz Chip (e quindi il dispositivo su cui è installato e con esso il suo utente o proprietario), ho bisogno di conoscere la sua chiave RSA pubblica. Dove posso trovare questa chiave?”

La risposta a questa domanda è la seguente. In uno di questi due posti:

  1. Un archivio di chiavi di mia proprietà (“privato”) nel quale ho memorizzato questa chiave in occasione di un precedente incontro con questo Fritz Chip.
  2. Un archivio “pubblico” di chiavi RSA corrispondenti ad un certo insieme di Fritz Chip, ad esempio il database in cui il produttore di Fritz Chip ha memorizzato le chiavi pubbliche dei chip da essa prodotti.

La prima tecnica è quella tipica di un sistema DRM usato per proteggere dei contenuti multimediali. Quando vi collegate ad un sito web per acquistare qualcosa, il server chiede la chiave pubblica del vostro Fritz Chip e la memorizza, in modo da essere in grado di riconoscere lo stesso Fritz Chip quando vi collegherete di nuovo in futuro. In questo caso, la chiave pubblica viene usata più o meno come un cookie di sessione. Il server remoto non è in grado di dire chi siete ma solo di dire se siete la stessa persona che ha acquistato un certo servizio in precedenza. (La situazione in realtà è molto più complessa ma non possiamo spiegarla in dettaglio in questa sede senza farvi addormentare).

La seconda tecnica, secondo le specifiche del Trusted Computing Group non dovrebbe essere mai attuabile nella pratica perchè le aziende produttrici non dovrebbero tenere traccia dei TPM prodotti. Ecco, qui di seguito, come spiega questo concetto David Safford nel suo Rebuttal.

“Both [integrity protection and trusted storage] use trusted root certificates as this basis [of their security guarantees.]” This is a misunderstanding of the TCPA specification. There is no requirement for certificates at all, to use any TCPA chip function. There doesn’t even exist such a root authority for TCPA in general, or for IBM’s currently shipping chips. You can generate private keys, use them to sign, and decrypt, and seal/unseal data under PCR’s, all without any certificates. The only time a certificate is needed is if you want to be able to prove to a third party that you have an approved TCPA chip. Most applications do not have this need, and this certification is not currently supported with IBM’s chips. If you want to do an application that needs such a certificate, the TCPA has an endorsement key that can be used to get a suitable certificate. The only way this can work is if someone, like the manufacturer, has recorded a given TCPA chip’s public endorsement key, and can use this knowledge to certify identity keys from
the given TCPA chip. This is not required, and software access to the endorsement key can be disabled. There is certainly a privacy aspect of access to the endorsement key, as it uniquely identifies the platform, and the TCPA specification goes to great lengths to allow for anonymous certification. The best defense for privacy conscious users is simply to turn off the endorsement key.

(Da Clarifying Misinformation about TCPA di David Safford, pagina 4 di 7. Il corsivo è mio.)

Come potete vedere, David Safford si premura di spiegare come le specifiche del TCG si spingano molto avanti nell’imporre ai produttori la creazione di un meccanismo di “identità virtuali” che proteggano la reale identità dell’utente. Queste specifiche si spingono molto avanti anche nello sforzo di rendere non necessarie e, se possibile, non desiderabili le procedure di identificazione del Fritz Chip. Tuttavia, nelle due frasi in corsivo, Safford è costretto ad ammettere due cose importantissime:

  1. L’unico modo di identificare in modo certo un Fritz Chip è quello di ricorrere alla sua chiave RSA pubblica
  2. L’unico modo di sapere se un certo Fritz Chip è un vero Fritz Chip (e non un emulatore) e se appartiene ad una certa “classe” di TPM (Ad esempio quelli che sono stati montati sui MacIntel) è quello di confrontare la sua chiave privata con quelle memorizzate dal produttore (o chi per lui).

A questo punto, ci dobbiamo domandare: “Che garanzie esistono che questo database di chiavi RSA pubbliche non venga mai realizzato dai produttori? Che garanzie esistono che la nostra privacy venga rispettata?”

La risposta è: nessuna.

Non sono io a dirlo ma il Trusted Computing Group stesso all’interno del più importante dei suoi documenti ufficiali: proprio quelle Best Practices che dovrebbero rappresentare la “Bibbia” e la “Legge” per i produttori di sistemi Trusted Computing. Come ha fatto notare Bruce Schneier in un suo famoso articolo sul suo Blog, queste Best Practices non vincolano in nessun modo i produttori. Sono semplici “buoni propositi” dell’ente di standardizzazione (il TCG). Come se non bastasse, all’interno di questo documento, che rimane comunque l’unico documento in cui il TCG prende una posizione etica sull’uso di questa tecnologia, il TCG stesso è costretto a riconoscere il suo fallimento nell’imporre regole chiare per il rispetto della privacy. Lo fa nei due punti seguenti.

However, preventing potentially coercive and anticompetitive behavior is outside the scope of TCG. (Pagina 11)

Computing and the Internet have fundamentally changed the value and importance of information. TCG technology, when properly implemented, has the capability to greatly improve the security of platforms on the Internet. At the same time, as with most security technologies, TCG technology could also be used inappropriately to undermine basic human rights of privacy and platform owner/user control. In light of this possibility for misuse of TCG technology, the TCG has worked very hard to specify building blocks for a security system that favors platform owner/user control, user privacy, interoperability, and data portability. The TCG realizes that market forces, coercive behavior, and poor implementations can do much to weaken these principles and that there is little the TCG organization can do to prevent a manufacturer or system designer from subverting the goals of privacy and control, if they are determined to do so. What TCG can do, however, is to say that such implementations fit neither the spirit of the TCG organization nor the letter of the TCG Principles. (Conclusioni a pagina 13)

Dopo che persino il TCG ha abdicato in questo modo al suo ruolo di garante, possiamo dire, senza timore di smentita, che l’utente rimane con una foglia davanti ed una di dietro, secondo la migliore tradizione del “customer care” nel mondo capitalistico.

In conclusione:

  1. Le chiavi RSA vengono generate sempre e comunque dal produttore.
  2. L’utente non può rinunciare a queste chiavi senza rinunciare anche ad accedere all’universo di documenti e servizi che sono (o saranno presto) protetti da tecnologie Trusted Computing.
  3. Il produttore non ha nessun obbligo riguardo alla eventuale memorizzazione di queste chiavi, nè obblighi di legge, nà obblighi contrattuali con il TCG.
  4. Ovviamente, un database di chiavi RSA di questo tipo ha un valore commerciale notevole perchè permetterebbe, ad esempio, ad Apple di stabilire in modo certo se il suo MacOS X viene installato su un MacIntel o su un comune PC. Nello stesso modo, permetterebbe alla RIAA ed alla MPAA di sapere esattamente chi ha acquistato un brano musicale od un film in rete. La tentazione di creare e vendere questo database di chiavi è quindi molto forte.
  5. Non c’è nessuna legge, nè USA, nè UE, nè italiana che ci possa mettere al riparo da questa evenienza. I nostri legislatori sono ancora strenuamente impegnati a decidere se sia più opportuno impiantare 2 o piuttosto 3 embrioni in quei casi di fecondazione artificiale che riguardano lo 0,0000000001 per mille della popolazione. Non hanno tempo per queste sciocchezze tecnologiche da geek brufolosi e segaioli.

Se avete commenti, c’è lo spazio apposito qui sotto.

The Deadlock of Noosphere February 26, 2006

Posted by laspinanelfianco in Copyright.
3 comments

Nel 2000, Eric S. Raymond descriveva con notevole lucidità il processo di “colonizzazione dello spazio delle idee” in un famoso articolo intitolato, per l’appunto, “homesteading the noosphere“. In quell’articolo, Raymond raccontava come gli hacker di tutto il mondo stessero lentamente colonizzando lo spazio delle idee (noosfera) con i loro prodotti e come, con grande lungimiranza, questi stessi hacker si curassero di mantenere lo spazio delle idee libero da vincoli che avrebbero potuto creare una situazione di stallo (deadlock).

Ora, a distanza di pochi anni, noi tutti possiamo assistere ad una vera corsa delle aziende alla stessa colonizzazione della noosfera attraverso l’uso di strumenti legali quali i brevetti, il copyright ed i trademark. A differenza degli hacker, le aziende si premurano di creare tutti i vincoli possibili con questi strumenti, in modo da recintare il proprio “territorio intellettuale” e da creare il maggior numero possibile di problemi, possibilmente insormontabili, ai loro concorrenti.

In Italia, patria del Made in Italy, questa politica di brevettazione selvaggia viene salutata come l’unica arma di salvezza nei confronti della concorrenza cinese e viene sostenuta in tutti i modi possibili dal nostro governo e dalla opposizione. Lo stesso avviene, in maniera addirittura più aggressiva a livello di Comunità Europea. In tutto l’emisfero Nord del pianeta non c’è una sola voce “istituzionale” (governo, uomo politico o simili) che si opponga a questa politica e si chieda: “come mai siamo finiti in questa fossa a litigarci il nostro amaro boccone quotidiano coi cinesi, gli indiani ed i brasiliani?”

Possiamo quindi dare per certo che questa politica continuerà ad essere attuata e sostenuta legalmente da tutti i governi che contano e, attraverso i potenti strumenti di ricatto del WTO, verrà imposta anche ai restanti paesi del mondo.

A questo punto, possiamo chiederci: “quanto tempo ci resta prima che sia impossibile anche solo concepire qualcosa senza incappare in un brevetto, un copyright od un trademark? Quanto tempo manca al deadlock della noosfera?”

Dipende. Dipende dalla velocità con cui questo spazio viene colonizzato e dalla sua estensione. In alcune aree, tecnologicamente abbastanza mature, il deadlock si è già verificato. Provate a produrre un qualunque dispositivo elettronico integrato senza dover fare i conti con i brevetti di Texas Instruments, Intel, Motorola, Siemens ed IBM. Provate a produrre una borsa da signora senza incappare nei trademark dei designer italiani e stranieri. In queste aree, lo scambio di brevetti tra aziende è all’ordine del giorno ed è indispensabile per la sopravvivenza. Chi non ha brevetti o trademark da scambiare, semplicemente chiude i battenti.

Nel settore del software le cose vanno appena meglio grazie al fatto che in Europa non si può (ancora) brevettare un algoritmo (una idea) ma solo la sua specifica implementazione in codice. Comunque, come ben sappiamo, le lobby americane stanno lavorando duramente sui nostri uomini politici e questa finestra di libertà verrà sicuramente chiusa in breve tempo. L’estate scorsa ci siamo salvati dalla approvazione surrettizia di una norma sulla brevettabilità del software, avanzata presso la Commissione Caccia e Pesca (si, proprio “caccia e pesca”!) del Parlamento Europeo solo grazie all’intervento dei polacchi! Questa volta ci è andata bene, ma potete stare tranquilli che i lobbisti (profumatamente pagati dalle aziende americane) insisteranno e, alla fine, vinceranno.

Dopodichè?

Dopodichè, ci toccherà cambiare mestiere. Provate a creare un programma qualunque senza inciampare nei brevetti (legali negli USA) di Xerox, Apple, IBM, Microsoft, Sun e via dicendo.

Privati della possibilità di concepire e produrre qualcosa di innovativo (tranne rari casi provenienti dalla ricerca di base), potremo finalmente dedicarci alla attività nella quale ci riconosciamo maggiormente: fare concorrenza ai cinesi sul piano dei costi, come già stiamo facendo da tempo.

A questo punto, forse ci verrà utile questo interessante farmaco (naturalmente brevettato dai francesi e poi acquistato dagli americani): Modafinil o Provigil.

In un mondo che combatte le sue guerre commerciali solo sul piano della produttività (abbassamento dei costi, aumento delle ore lavorate, etc.) invece che sulla innovazione, il sonno sarà un lusso per pochi.

Trusted Computing e DRM February 25, 2006

Posted by laspinanelfianco in DRM, Trusted Computing.
3 comments

In un suo commento al mio articolo “Nei Mac pulsa il TPM” su Punto Informatico, Enzo4510 dice:

La mia obiezione è questa: ma qualcuno ha mai provato a pensare come sarebbe un computer in grado di usare il fritz chip per realizzare il DRM, sia sul software che sui contenuti multimediali?

Con “usare il fritz chip” intendo proprio un sistema la cui sicurezza si basa sull’ impossibilità da parte di un utente normale di recuperare le chiavi segrete memorizzate all’ interno del fritz chip, altrimenti parliamo di classici sistemi di protezione anticopia simili a quelli esistenti, craccabilissimi e realizzabili anche senza fritz chip.

Qui di seguito trovate una descrizione del funzionamento dei sistemi DRM di II generazione, cioè quelli basati su Trusted Computing. Non sto più a creare i links ai siti che spiegano i termini usati. Fate riferimento a Wikipedia (in inglese) per ogni dubbio.

Il Fritz Chip come strumento crittografico “General Purpose”

Il Fritz Chip (TPM) è un “semplice” processore crittografico dedicato. Da un punto di vista concettuale non è molto diverso da programmi crittografici come GPG e PGP. Il suo ruolo è semplicemente quello di cifrare e decifrare al volo documenti e flussi di dati. Oltre a questo, il TPM si occupa di generare certificati digitali con cui “fotografare” lo stato di programmi e documenti in modo che sia possibile, in seguito, verificarne l’autenticità e l’integrità. In modo analogo, il TPM è in grado di apporre delle apposite firme digitali sui documenti per certificare la loro provenienza e la loro integrità.

Di conseguenza, il Fritz chip non deve essere visto come un soldatino che resta attivamente a guardia di ciò che fa l’utente ed interviene per far rispettare le regole. Il TPM deve essere considerato una funzionalità della piattaforma, esattamente come il masterizzatore ed il suo driver. Senza questa funzionalità, non è possibile decifrare i dati che sono stati protetti con questa tecnologia, esattamente come senza masterizzatore non si può creare un CD.

DRM e Crittografia

Tutti (ma proprio tutti) i sistemi DRM esistenti e concepibili fanno uso di qualche forma di crittografia per proteggere i propri dati. Se i dati da proteggere (musica o film in formato digitale) venissero lasciati “in chiaro” non ci sarebbe nessun modo di proteggerli da copie ed abusi di vario tipo.

Per diversi anni, i sistemi esistenti hanno fatto uso di sistemi crittografici (più o meno proprietari e più o meno robusti) implementati in software (come GPG e PGP).

Alcuni di questi sistemi si sono dimostrati più robusti di altri ma tutti, indistintamente, si sono dimostrati vulnerabili a qualche tipo di attacco via software. Il motivo è abbastanza ovvio: la tecnologia attuale permette di guardare dentro il programma (usando un debugger od altre tecniche) e di metterlo alla prova fino a trovare un punto debole. Ad esempio, è possibile usare questa tecnica per identificare e copiare le chiavi di cifra memorizzate all’interno del programma. Inoltre, il programma vive in un mondo virtuale (quello creato dalla piattaforma) che può essere emulato in modo da convincere il sistema DRM a svolgere le sue funzioni di decifrazione anche quando dovrebbe rifiutarsi di farlo. Ad esempio, è una tecnica comune quella di intercettare le chiamate a certi tipi di chiavi hardware e sostituire la chiave hardware con un programma che fornisce sempre e comunque le autorizzazioni necessarie ad usare un certo prodotto.

Per questo motivo tutti (ma dico proprio tutti) gli studiosi che si occupano di DRM concordano sul fatto che non sia possibile creare dei sistemi DRM realmente inviolabili senza un adeguato supporto hardware. Il supporto hardware a cui si riferiscono è un dipositivo come il TPM od una Smart Card. Una Smart Card può essere vista come un TPM removibile.

L’importanza delle chiavi di cifra

Uno dei più famosi assiomi della crittografia è che la robustezza di un sistema di cifra deve risiedere solo (dico proprio solo) nelle sue chiavi. In altri termini deve (dico deve) essere possibile rendere pubblico l’algoritmo e la sua implementazione (il codice) senza che questo renda più semplice decifrare abusivamente (o “decrittare”, per usare la terminologia corretta) i dati che sono stati protetti con il sistema di cifra.

Nel rispetto di questo importante assioma, i più grandi ed i più diffusi sistemi di cifra sono sempre “open”: il loro algoritmo è ampiamente descritto in apposito documenti ed il codice che lo implementa è spesso “open source”. Questo è vero per DES e per quasi tutti gli algoritmi che lo hanno succeduto (quasi tutti descritti in dettaglio nel famosissimo libro “Applied Cryptography” di Bruce Schneier) ed è vero per molti programmi crittografici open source come GPG di GNU.

Tutta la sicurezza di questi sistemi (usati anche dai militari) risiede nella segretezza delle chiavi.

A questo punto, dovrebbe essere chiaro per quale motivo i progettisti di sistemi come il Trusted Computing ed i sistemi DRM ritengono di importanza fondamentale poter memorizzare le loro chiavi di cifra all’interno del TPM, invece che sul disco rigido del PC o su un altro supporto passivo.

Il TPM è un componente “attivo” in questo senso: non si può semplicemente leggere e scrivere dati al suo interno come se fosse un floppy. Il TPM si comporta come un server remoto su Internet. Prima di poter ottenere dal TPM delle informazioni (le chiavi di cifra) dovete stabilire una conversazione con il TPM stesso e dimostrare di avere diritto a quella informazione. In pratica, dovete dimostrare la vostra identità e dovete dimostrare che il software che state usando è conforme a determinate regole (stabilite dal proprietario dei dati).

Quando è necessario un database delle chiavi

Normalmente, un sistema DRM non si preoccupa di legare il consumo di un certo prodotto ad un certo, specifico dispositivo (PC o altro). Il sistema DRM si limita a “gestire” in modo opportuno la copia da un dispositivo all’altro (di solito, impedendola del tutto). Per questa sua applicazione di base, che è la tipica applicazione dei DRM che noi tutti conosciamo, il sistema DRM non ha bisogno di conoscere l’esatta identità del device utilizzato. Gli basta sapere se è quello “giusto” (quello “autorizzato”). Il sistema DRM può ottenere questa certezza grazie a dei certificati digitali che identificano la macchina, qualunque essa sia.

Esistono però dei casi in cui il sistema DRM deve essere in grado di stabilire se un certo device (PC) appartiene ad una certa classe od addirittura se il device è un certo specifico dispositivo tra milioni che sono stati prodotti. Un caso di questo tipo si è verificato con i MacIntosh basati su architettura Intel: Apple ha bisogno di spaere se l’utente sta cercando di installare il suo prezioso MacOS X su un vero MacIntel o su un comune PC Intel. Nel caso specifico, Apple ha deciso di non spingere i controlli fin dove il sistema di Trusted Computing poteva arrivare. Infatti, MacOS X può essere installato su semplici PC.

In casi come questo, per essere sicuri che il device appartiene ad una certa classe di prodotti (i MacIntel) o che si tratta di uno specifico device (il PC di un certo, specifico utente), è necessario confrontare l’identificatore univoco del TPM con un database di identificatori esterno al sistema stesso, ad esempio conservato su un server di rete. L’identificatore univoco del TPM è una chiave pubblica RSA a 2048 bit che viene generata dal TPM stesso al momento della sua produzione.

Senza questo controllo non si può essere sicuri che il TPM sia un vero TPM. Potrebbe trattarsi di un emulatore software o di un TPM prodotto in modo artigianale (FPGA) a scopi illegali. Senza questo controllo, diventa possibile installare MacOS X su qualunque cosa che contenga un TPM, vero od emulato. Senza questo controllo, qualunque dispositivo dotato di TPM, vero od emulato, è uguale a qualunque altro.

Questo non vuole assolutamente dire che senza questo controllo di identità sia possibile decifrare abusivamente i dati protetti da sistema TC. Vuol solo dire che è possibile decifrarli dovunque (se si è in grado di rispettare le condizioni di sicurezza imposte dal proprietario dei dati). La sicurezza dei dati non viene messa in discussione.

Gli altri elementi “pro-DRM” del Trusted Computing

Nell’ambito di questo discorso è necessario anche ricordare che il solo TPM non è tutto il Trusted Computing. I sistemi Trusted Computing che vedremo realmente sul mercato PC nei prossimi anni sono qualcosa di molto più ampio e complesso. Si tratta di sistemi che usano il TPM per le loro esigenze crittografiche ma che aggiungono allo schema iniziale delle risorse come la curtained memory ed il protected I/O che sembrano essere (e forse sono) stati concepiti appositamente come strumenti DRM ausiliari.

Un ipotetico sistema DRM di II generazione per la protezione dei contenuti

A questo punto, dovrebbe essere chiaro come saranno fatti i sistemi DRM di II generazione. Si tratterà di sistemi DRM assolutamente identici a quelli esistenti con due sole importantissime differenze:

  1. le operazioni crittografiche verranno delegate al TPM, molto più potente, sicuro e veloce di qualunque programma. Il TPM verrà usato anche per soddisfare le esigenze crittografiche dell’utente (non ci sarà più bisogno di GPG, quindi).
  2. le chiavi di cifra verranno conservate al sicuro dentro il TPM. Non ci sarà mai bisogno di estrarle dalla loro sede, visto che è il TPM stesso ad eseguire le operazioni crittografiche.

Queste due caratteristiche sono sufficienti a far fare un salto in avanti impressionante ai sistemi DRM. Se sfruttati per quello che possono offrire (e non alla maniera di Apple) i sistemi DRM basati su Trusted computing possono essere inviolabili sia dal punto di vista pratico che da quello teorico.

Un (mica tanto) ipotetico sistema di protezione del software basato su TC

Nello stesso modo, è abbastanza ovvio come saranno fatti i sistemi di protezione anticopia del software della prossima generazione. Questi sistemi saranno molto, molto simili a quello usato da Windows XP (il famoso sistema di “certificazione” della macchina) con una sola differenza importantissima: non sarà più il programma di installazione a creare il “certificato” sulla base del quale verrà emessa la licenza d’uso del software, sarà il TPM a generare questi certificati.

Nel caso che fosse necessario restingere l’uso di qualcosa (sistema operativo, programma, contenuti multimediali o servizi di rete) ad una specifica classe di macchine (solo i MacIntel) o ad una specifica macchina, sarà necessario creare un apposito database delle chiavi RSA che identificano i TPM. Diversamente, come abbiamo detto, si potrebbe sempre emulare il TPM e spostare tutto il sistema su una piattaforma diversa da quella prevista (come è appunto già avvenuto con MacOS X).

Spero di avere chiarito qualche dubbio su questi punti. Se avete qualcosa da dire, o da chiedere, ricordatevi dello spazio “commenti” qui sotto.