Tutto parte da questo articolo apparso su Ars Technica qualche giorno fa. In esso si racconta di come un professore di liceo abbia cercato di riprodurre il film Hellboy 2 sul proiettore della scuola, collegando il suo nuovo MacBook, e che, invece di mostrare il film sullo schermo, il MacBook gli abbia risposto con un messaggio di errore (lo vedete nella figura all’inizio dell’articolo) che tradotto suona così: Non è possibile riprodurre questo film perché è stata rilevata la presenza di un monitor non autorizzato a riprodurre filmati protetti. Provare a scollegare i monitor che non possiedono autorizzazione HDCP.

Il professore ha acquistato quel film su iTunes, e il proiettore Sanyo era collegato al MacBook attraverso un adattatore DisplayPort-VGA. L’uscita era quindi analogica, e la protezione del contenuto digitale. La conseguenza — ovvia, se ci si riflette un istante — non poteva essere differente.

Questa notizia si è diffusa rapidamente, con il classico, frenetico tam-tam del Web, e altrettanto rapidamente si è cominciato a dire di tutto. E spesso, come accade in questi casi, dicendo sciocchezze o quantomeno diffondendo informazioni imprecise.

La prima grossa sciocchezza è affermare che Apple abbia abbracciato finalmente il Trusted Computing, mossa annunciata nel 2006 con l’introduzione dei primi Macintosh basati su processore Intel che contenevano un chip TPM. Ci casca anche Paolo Attivissimo, che nel suo articolo sull’argomento esordisce così:

No, non siamo tornati nel 2006. Apple, però, crede di sì, a quanto pare: perché così come allora aveva infilato nei suoi computer i controversi chip TPM/Palladium con le loro funzioni anticopia, suscitando insurrezioni e boicottaggi, oggi riprova a menomare i diritti dei suoi utenti introducendo sistemi anticopia direttamente a livello hardware nei suoi nuovi portatili. Bella mossa, complimenti.

Credevo che in due anni le cose si fossero chiarite, invece pare che il mito del Trusted Computing nei computer Apple e in Mac OS X sia duro a morire. Voglio citare una fonte che mi pare abbastanza autorevole: Amit Singh, autore di un librone di 1680 pagine sull’architettura di Mac OS X: Mac OS X Internals: A System Approach. È un volume fenomenale per chi sia interessato a esplorare Mac OS X davvero ‘sotto il cofano’; io lo sto leggendo e mi sa che dovrò rinnovare il prestito alla biblioteca del Politecnico di Valencia, data la vastità e la densità degli argomenti (Singh scrive in maniera chiara e leggibile, e questo è sicuramente un bonus). Il libro è aggiornato a Mac OS X Tiger, ma Singh gli ha dedicato un sito Web, Mac OS X Internals: The Book ricco di aggiornamenti e contenuti aggiuntivi. Chi non conosce questo autore o ne dubita l’autorevolezza, dia un’occhiata al suo curriculum. Mi sembra di poter dire che Singh conosca bene sia il Trusted Computing che Mac OS X.

E infatti ha scritto due pezzi che riguardano proprio il Trusted Computing e Mac OS X. Il primo, Trusted Computing for Mac OS X (Trusted Computing per Mac OS X) è dell’ottobre 2006; il secondo, “TPM DRM” In Mac OS X: A Myth That Won’t Die (Il “DRM TPM” in Mac OS X: un mito duro a morire) del gennaio 2008.

Nel primo, Singh scrive (traduzione mia):

I TPM sono malvagi?

Spesso si associa il TCG (prima chiamato TCPA) con il famigerato Progetto Palladium di Microsoft. E altrettanto spesso si utilizza il TCG (Trusted Computing Group) come sinonimo di DRM. Certo, è possibile impiegare un TPM (Trusted Platform Module) per svolgere un compito all’interno di uno schema di DRM, ma da un punto di vista di “craccabilità” non cambia nulla a meno che non vengano messe in atto molte altre contromisure (e il potenziale utilizzo di tali contromisure, questo sì, è motivo di preoccupazione). Si crede anche che un TPM possa in qualche modo prevenire o controllare l’esecuzione di programmi: non può. Un TPM non può partecipare in decisioni riguardanti l’esecuzione — è sempre il software che deve prendere tali decisioni. Il TPM inoltre non conosce e non può conoscere eventuali liste bianche o nere di numeri seriali di computer. Con questo non intendo dire che non vi siano giustificabili preoccupazioni o problematiche per la privacy legate all’utilizzo del Trusted Computing. Uno scenario estremo ed esagerato avverrebbe se un produttore abusasse del TPM: per esempio un produttore che impedisse al cliente di disabilitare il TPM o cambiarne i permessi: questa è una cosa negativa. Tuttavia, così facendo, il produttore dovrebbe andare contro le specifiche [del TPM] […]

Le parti in grassetto non fanno parte dell’enfasi data da Singh nel suo scritto (quella è in corsivo), ma sono aspetti che ho voluto sottolineare io e che riguardano l’argomento del mio post.

Che cos’è una Trusted Platform? Singh:

Una Trusted Platform è una piattaforma di calcolo dotata di un componente “fidato” (trusted): per esempio un componente hardware anti-manomissione incorporato. Solitamente la resistenza in questione riguarda attacchi esterni, e non un attacco da parte del proprietario. Nel caso della piattaforma del Trusted Computing, il TPM è quella parte fidata, che consiste in un componente hardware piuttosto complesso. Si può considerare il TPM come il nucleo di un sottosistema fidato. I suoi costituenti logici comprendono unità funzionali e memoria. Esempi di unità funzionali comprendono un acceleratore hardware SHA‑1 e un generatore di veri numeri casuali. Fra gli esempi di tipi di memoria citiamo la memoria funzionante, attiva, la memoria di archiviazione non volatile, e la EEPROM. La specifica del TPM richiede certe caratteristiche, e in alcuni casi un minimo di risorse specifiche. Nella prossima sezione vedremo l’insieme delle caratteristiche dello specifico TPM utilizzato da Apple.

Più oltre, nella sezione dedicata al chip Infineon TPM1.2 che Apple impiegava (ricordo che questo pezzo risale al 2006), è interessante citare questa parte:

Forse la cosa più importante da notare nella specifica implementazione del TPM di Apple è che il firmware Apple non è TCG-aware, nel senso che non vi sono provvedimenti incorporati da Apple per stabilire una ‘presenza fisica’. Alcune operazioni sensibili del TPM (come lo ‘svuotamento’ del TPM, che lega il TPM a un nuovo proprietario e fa perdere ogni informazione o legame con proprietari precedenti) necessitano di presenza umana per venire stabilite. […] Un altro modo di considerare la ‘non-consapevolezza’ del TCG da parte del firmware, è quello di notare l’assenza di un driver TPM a livello di firmware [nel caso delle macchine Apple].

E ancora:

Le “chiavi del TPM di Apple”

È da molto tempo ormai che i media stanno discutendo sull’ ”Utilizzo del TPM da parte di Apple”. Si sono letti numerosi resoconti di aggressori che hanno aggirato “la protezione TPM di Apple” e che hanno trovato “le chiavi del TPM di Apple”. In ogni caso è importante tener presente che Apple non si serve del TPM. Se siete in possesso di un computer Macintosh dotato di TPM, voi potete sfruttare il TPM per le funzioni per cui è stato progettato, senza alcun effetto collaterale sul normale funzionamento di Mac OS X. Ovviamente per usare il TPM sotto Mac OS X è prima necessario un driver per comandare il dispositivo.

E ancora:

Al momento in cui scriviamo (ottobre 2006), nei modelli di computer Apple più recenti […] non è presente un chip TPM Infineon sulla scheda madre. […]

Nel secondo pezzo, “Il ‘DRM TPM’ in Mac OS X: un mito duro a morire”, Singh riassume:

Apple ha introdotto i primi Macintosh basati su architettura x86 agli inizi del 2006. Anche prima, in molti avevano notato la presenza di un TPM (Trusted Platform Module) nelle macchine del Developer Transition Kit. Dopodiché si sono susseguite molte discussioni e grande scalpore nei confronti del “DRM” che il TPM avrebbe dovuto imporre a livello dell’intero sistema. Tuttavia, il TPM contenuto nei Macintosh basati su architettura x86 commercializzati all’epoca non veniva utilizzato per niente né per fare alcunché.

Nell’ottobre 2006 scrissi in merito al TPM e al suo “utilizzo” in Mac OS X. Dato che Apple non fornì alcun software o driver firmware per il TPM, mi occupai di scrivere e rilasciare un driver TPM open source per Mac OS X. 

A questo punto Singh cita la parte del suo articolo dell’ottobre 2006 che io ho riportato poco sopra, il frammento intitolato “Le ‘chiavi del TPM di Apple’ ”, e continua:

Molti hanno faticato a credere quanto scrissi. Dopotutto Apple stava legando Mac OS X al proprio hardware in qualche maniera; e i primi Mac con architettura x86 incorporavano dei chip TPM. Alcuni hanno — scorrettamente — concluso che il TPM doveva per forza essere coinvolto in tutto questo. Come spesso accade in Internet, tali conclusioni si sono trasformate in miti infallibili. Io a mia volta faticavo a credere a tutte quelle idiozie: avevo creduto che il mio driver TPM open source avesse dissipato i vari miti. Il driver e il software associato permettevano all’utente di fare “qualsiasi cosa” con il TPM: attivarlo, utilizzarlo per i propri obiettivi, perfino disattivarlo — il tutto senza compromettere il funzionamento di Mac OS X. Inoltre il TPM era una componente hardware piuttosto diffusa nei computer moderni e molto spesso giaceva inutilizzato nei computer di molti produttori. Nell’estate del 2006, con l’introduzione del Mac Pro, il chip TPM scomparve del tutto dai Mac con architettura x86. Eppure anche in quel caso i teorici del complotto si inventarono qualche spiegazione, e arrivarono ad affermare che in qualche modo il TPM era stato incorporato nella CPU.

Più o meno nello stesso periodo del 2006, scrissi in merito alla protezione binaria in Mac OS X a livello di Kernel. Come viene spiegato in quell’articolo è in realtà la protezione binaria che lega Mac OS X a una specifica tipologia di hardware. [enfasi mia]

Lo so, il discorso è lungo e intricato, ma il succo è presto riassunto: Apple, pur inserendo nei suoi computer un chip TPM per un breve periodo, non ha mai implementato attivamente alcuna misura restrittiva legata al Trusted Computing né tantomeno ha esercitato alcuna forma di DRM con quel chip. Attivissimo (ma non è il solo) sbaglia quindi 1) nell’associare Palladium al chip TPM, 2) nel parlare di ‘funzioni anticopia’ (mai implementate da Apple nel chip TPM) e 3) nel dire che Apple “menoma i diritti dei suoi utenti introducendo sistemi anticopia direttamente a livello hardware nei suoi nuovi portatili”.

Il perché la 1) e la 2) sono affermazioni imprecise mi pare di averlo spiegato attraverso le informazioni attinte da Singh. Cerco di affrontare adesso l’imprecisione della 3).

Prima che apparisse questa storia su Ars Technica, avevo sentito nominare la famigerata HDCP un paio di volte en passant. Visto il polverone sollevato dall’articolo, sono andato sul sito Digital Content Protection a informarmi un po’. C’è moltissimo materiale lì, e così tanta carne al fuoco da far venire un bel mal di testa. Segnalo però almeno due risorse (in inglese) scritte con uno stile meno protocollare e più divulgativo:

1. White Paper: “HDCP Deciphered” [Lo HCDP decifrato] — DCP, 8/7/2008 (File PDF)
2. “HDCP: What It Is and How To Use It” [HCDP: Che cos’è e come utilizzarlo] — EDN, 18/4/2002. Scritto da Jim Lyle di Silicon Image (File PDF)

Entrambi gli scritti mettono in chiaro una cosa, che lo HDCP non è DRM. Nel primo si legge:

È importante sottolineare una differenza basilare fra HDCP e altre tecnologie di protezione dei contenuti o della gestione dei diritti digitali. I fornitori di contenuti si servono tipicamente di un sistema DRM (Digital Rights Management) per proteggere i loro contenuti. Tali sistemi DRM sono progettati per impedire usi non autorizzati dei contenuti e consentire altri impieghi o imporre altre restrizioni su tali contenuti. Per esempio, un consumatore può scaricare un file audio o video e passarlo a un riproduttore digitale. Quel file è protetto da un DRM che controlla ciò che l’utente può fare con i contenuti del file. Per esempio il DRM potrebbe stabilire se l’utente può effettuare copie del file o riprodurre il contenuto su altri tipi di dispositivi. HDCP non è un DRM. HDCP svolge un ruolo molto specifico: criptare e proteggere i contenuti mentre vengono trasmessi come flusso di informazioni digitali per essere visualizzati.

Nel secondo, Jim Lyle scrive:

HDCP è protezione dei contenuti, non è un sistema di protezione anti-copia (o più esattamente di restrizione della copia). La differenza è sottile, ma estremamente importante. HDCP non è progettato per impedire la copia o la registrazione, né abolisce la registrazione differita (registrazione di programmi TV per poter successivamente mettere in pausa l’immagine o per poterli visionare in un secondo momento). 

In soldoni HDCP è un sistema che garantisce la trasmissione sicura di dati video digitali dal dispositivo A al dispositivo B, e lo fa attraverso un sistema crittografico con scambio di chiavi fra la parte trasmittente e la parte ricevente. (Un po’ come quando ci si collega con un altro Mac via SSH). Se il flusso segue un percorso più complesso, con presenza di un ripetitore, il ripetitore riceve i dati criptati dal trasmittente, li decodifica, li ricodifica e li invia al ricevente. In genere il trasmettitore può essere un computer o un lettore Blu-Ray e il ricevente un monitor, un televisore o un proiettore. Le due parti devono ovviamente poter dialogare attraverso un’interfaccia abilitata alla cifratura attuata da HDCP. Le interfacce sono: HDMI, DVI, DisplayPort, GVIF, UDI, e sono tutte, appunto, digitali.

Tornando allo sfortunato professore, lui si è trovato con un film comprato su iTunes Store e protetto dalla tecnologia HDCP. Inviando i contenuti del film attraverso un percorso impossibile da proteggere da parte di HDCP — che, rilevando la connessione VGA del proiettore, ha impedito la trasmissione perché il proiettore non avrebbe potuto decodificare i contenuti criptati — il professore si è ritrovato quel messaggio di errore.

Una situazione sgradevole, che non piace neanche a me. È irritante aver acquistato un film e non poterlo vedere indiscriminatamente su qualsiasi schermo uno voglia. Ma che Apple abbia implementato la protezione HDCP non è una novità e, seppure non sia certo strombazzato ai quattro venti, la pagina delle specifiche di AppleTV menziona HDCP (Nota 7 a “Porte e Interfacce”: Richiede HDMI con video HDCP o component). HDCP è espressamente nominato nei Termini del Servizio di iTunes Store. Nella sezione 10-xvi, Purchase or Rental of Apple Content si legge:

(xvi) HDMI. An HDCP connection is required in order to view movies (purchased or rented) and TV shows transmitted over HDMI.

Ossia: È richiesta una connessione HDCP per poter guardare film (acquistati o noleggiati) e spettacoli TV trasmessi via HDMI.

Questa parte è assente dai Termini del Servizio di iTunes Store italiano (e spagnolo e di tutti i paesi non-USA) perché fuori dagli Stati Uniti non è possibile acquistare o noleggiare film mediante iTunes Store.

La fruizione di contenuti digitali ad alta definizione sta andando incontro a uno scenario con un numero sempre maggiore di compromessi e lascia l’amaro in bocca il fatto che la decisione su come fruire di tali contenuti sia sempre meno nelle mani dell’utente, specie dell’utente onesto che ha pagato regolarmente il film e che di fatto non può disporne in totale libertà. Però in questo contesto è cruciale, a mio avviso, diffondere informazioni il più possibile corrette e ‘neutrali’, per evitare di prendere fischi per fiaschi e, come si dice in inglese, abbaiare sotto l’albero sbagliato.

Presumo che i disagi come quello vissuto dal professore dell’articolo di Ars Tecnica siano transitori e legati al fatto che ci troviamo in una fase di passaggio fra dispositivi contenenti nuove tecnologie digitali e dispositivi analogici o privi delle componenti necessarie a garantire la visione normale di contenuti protetti. È auspicabile che con il progressivo svecchiamento dei dispositivi, episodi del genere siano sempre meno frequenti.