Trusted Platform Module

Il Trusted Platform Module (lett. "modulo per una piattaforma fidata", spesso abbreviato come TPM) è il nome con cui vengono indicate sia le specifiche per la costruzione di un microchip deputato alla sicurezza informatica, pubblicate dal Trusted Computing Group, sia il chip stesso. Tale microchip viene generalmente implementato come modulo aggiuntivo per la scheda madre di un computer, ma si può trovare anche in palmari e in altri dispositivi elettronici.

Tale chip era noto in precedenza come Chip Fritz, nome che deriva dal senatore statunitense Ernest "Fritz" Hollings, forte sostenitore di questo progetto. Lo scopo del TPM è l'aumento della sicurezza informatica: ogni chip è dotato di una coppia di chiavi crittografiche uniche, che lo rendono univocamente identificabile, e di un motore per la crittografia asimmetrica per la criptazione dei dati.

Il Trusted Platform Module è progettato per essere disponibile su qualsiasi sistema operativo o piattaforma^[1]. Tali chip sono diffusi tra i portatili destinati all'utenza business e diversi produttori di schede madri e computer desktop forniscono il supporto opzionale a questa tecnologia. Secondo la International Data Corporation, entro il 2010 tutti i portatili e praticamente quasi tutti i PC avrebbero dovuto esser dotati di TPM^[2]. Nonostante tale previsione, il chip TPM non si è diffuso in tutte le architetture. Quando Apple passò ai processori Intel nel 2006, inserì il TPM in alcune, ma non tutte, le schede madri Mac^[3], per poi eliminarlo completamente nel 2009. A luglio del 2013, al rilascio delle specifiche di Windows 8.1 Pro, la Microsoft lo ha incluso tra i requisiti obbligatori a partire dal 1º gennaio 2015^[4].

Le specifiche pubblicate dal Trusted Computing Group^[5] definiscono quale dev'essere l'architettura del processore e quali funzionalità minime esso deve offrire.

Ogni TPM deve offrire determinate minime funzioni^[6], ovvero:

• generazione di numeri pseudo-casuali;
• generazione e memorizzazione di chiavi crittografiche (RSA);
• cifratura e decifratura di informazioni con RSA;
• generazione e verifica di hash SHA1.

A tale scopo, ogni Trusted Platform Module deve essere dotato di specifiche componenti, connesse tra loro attraverso un bus interno e capaci di interagire con il resto del calcolatore con un bus esterno. Tali componenti devono essere i seguenti:

Il componente di I/O deve essere in grado di gestire le comunicazioni sui bus interni ed esterni, crittografando e decodificando le informazioni quando necessario. Deve garantire l'accesso al dispositivo in associazione col dispositivo Opt-In.

Ogni dispositivo deve essere dotato di un processore in grado di eseguire le seguenti operazioni:

• Generazione asimmetrica di chiavi
• Crittazione e decrittazione asimmetrica
• Generazione di numeri casuali
• Hashing SHA-1

Tale processore può utilizzare anche la crittografia asimmetrica per comunicazioni interne al modulo, ma non deve esporre dati generati con algoritmi simmetrici all'esterno dello stesso. Per l'emissione di firme digitali, viene utilizzato l'algoritmo asimmetrico RSA con chiave di dimensione di 2048 bytes, sebbene il modulo debba supportare anche chiavi da 512 e 1024 byte. Tali chiavi possono essere note solo al modulo o in congiunzione tra un'entità esterna e il modulo stesso.

Il generatore di chiavi deve essere in grado di generare coppie di chiavi asimmetriche e chiavi simmetriche. Non è posta alcuna limitazione sul tempo di creazione delle chiavi.

Lo stesso argomento in dettaglio: HMAC.

Il motore HMAC deve essere in grado di fornire due importanti funzioni:

• Provare la correttezza dei dati di identificazione
• Provare che i dati in ingresso nel modulo sono autorizzati e non hanno subito modifiche durante la trasmissione.

A tale scopo viene utilizzato l'algoritmo crittografico HMAC con una dimensione di chiave di 20 bytes e una dimensione di blocco dati di 64 bytes. Le peculiarità dell'algoritmo lo rendono adatto a tali scopi: HMAC utilizza infatti una combinazione del messaggio originale e della chiave segreta per la crittografia dei dati, garantendo la massima sicurezza.

Il motore di numeri casuali è la sorgente della casualità all'interno del modulo. Le specifiche prevedono l'utilizzo di un algoritmo generatore di numeri pseudo-casuali per la creazione di chiavi e per la firma digitale. Il generatore di numeri casuali deve essere costituito da un componente in grado di accettare e mescolare dati imprevedibili da un coprocessore per restituire tali dati come risultato di una funzione non invertibile, come l'algoritmo SHA-1. A ogni chiamata deve essere in grado di generare 32 bytes di dati casuali.

Il componente per la creazione di numeri casuali deve essere inizializzato durante la lavorazione con dati casuali, generati per esempio attraverso il disturbo termico del segnale o attraverso software appositi; dopo tale inizializzazione, nessuna entità, nemmeno il produttore stesso, deve essere in grado di controllare lo stato di tale generatore. Durante l'utilizzo, tale componente continuerà a usare casualità hardware o software per generare i dati casuali, come per esempio il controllo casuale di combinazioni di tasti premuti o combinando i movimenti del mouse. La funzione utilizzata come output deve necessariamente ricevere un minore numero di bit in input rispetto a quelli restituiti in output, per garantire l'impossibilità di risalire allo stato del generatore di numeri.

Il modulo deve integrare un dispositivo in grado di gestire hash SHA-1 di 160 bits di dimensione. Tali hash vengono utilizzati per la firma digitale dei file.

Il Trusted Platform Module deve essere fornito di un componente in grado di gestire l'alimentazione del modulo e di informare il modulo stesso sullo stato di alimentazione dei dispositivi disponibili sulla macchina in cui è installato. Queste informazioni vengono utilizzate dal modulo per rilevare la presenza fisica di utilizzatori della macchina per fare in modo, per esempio, che alcune specifiche operazioni sul modulo siano eseguibili solo attraverso l'autorizzazione o, in caso di gestione remota, della presenza di un operatore.

Il componente Opt-In deve essere in grado di fornire i meccanismi e le protezioni necessarie per accendere, spegnere, attivare o disattivare il TPM. È inoltre il componente deputato al controllo della presenza fisica di operatori sulla macchina su cui è installato il Trusted Platform Module. Il componente Opt-In deve garantire che il modulo possa essere acceso, spento, attivato o disattivato solo da utenti che detengono il controllo del TPM, definiti come TPM Owner, o, nel caso di Owner remoto, se vi sono operatori presenti sulla macchina.

Il motore di esecuzione esegue il codice esterno, ottenuto dal modulo di Input/Output, per utilizzare le funzionalità del Trusted Platform Module. Deve essere in grado di garantire la trasparenza delle operazioni e la protezione dei dati sensibili.

Il modulo deve essere dotato di memoria non volatile, deputata al mantenimento di informazioni quali l'identità del Trusted Platform Module. Tale memoria deve essere accessibile al proprietario del modulo, o da entità autorizzate dallo stesso, per la conservazione sicura di dati. Il modulo, a causa della limitata vita dei componenti di memoria non volatile, deve accedere a tali componenti in modo da non rendere loro e, quindi, il modulo stesso, prematuramente inutilizzabili.

Lo stesso argomento in dettaglio: Trusted Computing § Applicazioni del Trusted Computing.

Per essere utilizzato, ogni Trusted Platform Module richiede l'utilizzo di uno specifico Trusted Software Stack, anch'esso determinato dalle specifiche del Trusted Computing Group. Se usato insieme a tale software, il TPM può:

• attestare l'identità e lo stato fidato della piattaforma di cui fa parte (attestazione remota);
• cifrare le informazioni che vengono inviate sui bus del sistema o salvate sulla memoria di massa (data sealing, lett. "sigillatura dei dati", e data binding, lett. "collegamento dei dati" al TPM);

La tecnica di sealing dei dati corrisponde al salvataggio dei dati cifrati usando una chiave che dipende dallo stato del sistema, ossia una combinazione dell'hardware e del software in esecuzione. La decifratura degli stessi dati sarà possibile soltanto per mezzo della stessa chiave, cioè utilizzando la stessa configurazione del sistema all'atto del salvataggio (lo stesso hardware e lo stesso software in esecuzione).

Il binding si riferisce alla cifratura dei dati usando una chiave di approvazione detta Endorsement Key, ovvero una chiave RSA che identifica univocamente il TPM stesso inserita nel chip durante la sua fabbricazione garantendo così che tali dati siano decifrabili soltanto dallo stesso modulo che li ha criptati.

L'attestazione remota viene effettuata per mezzo di apposite chiavi di cifratura, dette AIK (Attestation Identity Key), generate all'occorrenza dal TPM .In alternativa dalla versione 1.2 delle specifiche TCG per autenticarsi su rete è possibile utilizzare il protocollo di Direct Anonymous Attestation^[7][8], che consente l'autenticazione remota della macchina preservando la riservatezza del sistema autenticato.

Il chip, in sostanza, ha una funzione di controllo passivo sull'hardware ed il software installato sulla macchina su cui è presente. Per mezzo di speciali registri al suo interno, detti PCR (Platform Configuration Register), il TPM tiene traccia dell'evoluzione dello stato del sistema, misurandolo (si tratta praticamente dell'elaborazione di un hash delle informazioni prelevate dai dispositivi e del software in esecuzione) secondo la seguente formula

${\displaystyle \mathrm {PCR} [i]_{t_{1}}=\mathrm {SHA1} (\mathrm {PCR} [i]_{t_{0}}+\mathrm {informazioni\ prelevate} _{t_{1}})}$

ovvero, il contenuto dell'i-esimo PCR viene aggiornato (al tempo ${\displaystyle t_{1}}$) con l'hash SHA1 (US Secure Hash Algorithm 1, RFC 3174) calcolato sul contenuto precedente dello stesso registro (al tempo ${\displaystyle t_{0}}$) e sulle informazioni prelevate attualmente (al tempo ${\displaystyle t_{1}}$) dal sistema (all'avvio del sistema, il contenuto dei PCR è impostato a 0).

Il software (il boot loader, il sistema operativo, i programmi applicativi), realizzato opportunamente per interfacciarsi con il TPM, potrà quindi decidere, in base alle informazioni correntemente contenute nei PCR ed in base alla propria logica programmata, quali operazioni intraprendere. Per ovvie ragioni di sicurezza il TPM potrebbe impedire l'avvio del sistema da qualsiasi unità che non sia quella dove è installato, anche se sull'Uefi fosse impostata una sequenza di avvio diversa oppure si forzasse l'avvio da un'altra unità. Questa funzione o è predefinita o è configurabile. Anche l'avvio di un'unità di ripristino o un ambiente live potrebbe essere legittimamente impedito. Questa situazione obbliga l'utente a prestare estrema attenzione nel conoscere esattamente dove la chiave di cifratura è memorizzata e a conservare altrove la password di ripristino.

Solitamente le macchine dotate di chip TPM hanno nell'interfaccia Uefi un comando firmware per abilitare o disabilitare lo strumento. Solo abilitando il TPM dall'Uefi permette al sistema operativo di rilevarlo e quindi attivarlo per la successiva amministrazione. Pertanto, anche se lo si disattiva dal sistema operativo, il TPM rimane abilitato nel firmware (fino a quando non lo si disabilita qui).

Sia la chiave di autenticazione che l'eventuale password di ripristino sono solitamente immagazzinate in una cache specifica. A meno che sia stato anche creato un dispositivo hardware di sblocco (unità USB), se si dovesse pulire la cache su un archivio criptato si potrebbe non più accedere alle informazioni conservate. Ad esempio, questo è quello che succede con la cancellazione della cache TPM di BitLocker.

Un altro problema può nascere quando la batteria tampone della scheda madre si scarica completamente: in questo caso l'UEFI perde la sincronizzazione con la data e l'ora esatta e quindi il dispositivo TPM potrebbe andare in protezione, non accettando più né la chiave di autenticazione né la password di recupero. In questi casi occorre o sostituire la batteria tampone (o comunque averla sufficientemente caricata, con la data/ora corretta, almeno sino al login) oppure avviare l'unita criptata su altro computer compatibile (dopo averla staccata dal primo, chiaramente).

Lo stesso argomento in dettaglio: Trusted computing § Critiche.

Molte opposizioni all'adozione di questo tipo di chip si sono levate dall'ambito del software libero e dei sostenitori del fair use. I detrattori sostengono che tale sistema possa essere usato non solo per rendere più sicura una macchina, anche se rimane da chiarire chi è che stabilisce le regole in base alle quali ritenere sicuro un determinato stato del sistema, ma anche per decidere quali programmi possano accedere a certi dati, creando o amplificando una sorta di monopolio da parte dei sostenitori del Trusted Computing. Il microchip, secondo le specifiche pubblicate dal Trusted Computing Group, ha però solo un controllo passivo sul software, ovvero non è in grado di decidere ciò che un utente può utilizzare; al contrario, però, un software basato sul Trusted Platform Module potrebbe decidere di non eseguire operazioni considerate non sicure come, per esempio, la connessione a una rete considerata non affidabile.

Critiche si sono sollevate contro il sistema di attestazione remota^[9], mentre taluni ritengono che il sealing abbia come funzione essenziale la creazione di nuovi e più efficaci sistemi di Digital Rights Management, piuttosto che una protezione delle informazioni in sé.

Nell'ottobre 2007 è stata scoperta una falla di sicurezza basata sul buffer overflow nei servizi forniti dal modulo TPM installati sui Notebook IBM ThinkPad che permetterebbe l'esecuzione di codice arbitrario attraverso pacchetti HTTP^[10]. IBM ha consegnato tutti i dati relativi alla falla a Lenovo^[11] per la risoluzione del problema. A dicembre 2007 non sono disponibili ulteriori informazioni al riguardo.

Il Trusted Software Stack è una API standard per l'utilizzo del Trusted Platform Module, le cui specifiche sono pubblicate dal Trusted Computing Group^[12].

Il Trusted Software Stack è progettato per l'interoperabilità su tutti i sistemi operativi. Con la versione 1.2 delle specifiche è stato aggiornato per garantire il supporto al protocollo di Direct Anonymous Attestation e la creazione di chiavi di attestazione AIK^[13].

Quelle che seguono sono solo alcune delle funzionalità che il trusted software stack fornisce. In pratica, qualsiasi applicazione che sfrutti le funzionalità offerte dal trusted computing deve usare un trusted software stack per accedere alle funzioni offerte dal TPM. Le funzionalità elencate di seguito vanno quindi considerate come delle funzionalità che potrebbero essere offerte da applicazioni funzionanti su una trusted platform che sfruttino le API fornite dal Trusted software stack. Le funzionalità di dette applicazioni infatti non sono state standardizzate dal TCG.

Implementazione di tutte le politiche di sicurezza che vengono imposte dai programmi all'utente o ai programmi dall'utente.

Difesa dell'utente dagli abusi del TC (nessun software deve ad esempio fare il sealing dei dati o inviare la parte pubblica dell'Endorsement Key a terze parti senza il consenso del proprietario del TPM).

Garantisce la protezione dei dati considerati sensibili dalle applicazioni che sfruttano il TSS sia in input che in output.

Gestisce le partizioni di esecuzione; alcune applicazioni possono essere avviate in una partizione di esecuzione protetta che sfrutta le funzionalità offerte dal trusted computing per garantire l'integrità dell'applicazione e la privacy dei dati da essa elaborati.

• (EN) Specifiche del Trusted Platform Module, versione 1.2, revisione 103

• Trusted computing
• Trusted Computing Group
• Hengzhi chip

• Wikimedia Commons contiene immagini o altri file sul Trusted Platform Module

• (EN) Specifiche del Trusted Software Stack (PDF), su trustedcomputinggroup.org.
• (EN) FAQ di Trousers, un TSS open source
• (EN) Architettura di una "trusted platform", su perseus-os.org. URL consultato il 28 gennaio 2013 (archiviato dall'url originale il 9 febbraio 2012).
• (EN) Introduzione al trusted software stack, su perseus-os.org. URL consultato il 28 gennaio 2013 (archiviato dall'url originale il 9 febbraio 2012).
• (EN) Presentazione dell'architettura del trusted computing , sezione 4.5.3 (PDF), su trustedcomputinggroup.org.

Portale Sicurezza informatica: accedi alle voci di Wikipedia che trattano di Sicurezza informatica