Por su interés público, reproducimos el artículo, con el consentimiento de su autor. Simplemente se ha editado ligeramente, para facilitar su lectura.

Análisis técnico de TCPA y Palladium

------------------------------------
por Wintermute
--------------
QUITAESTO_wintrmute@retemail.es

     Llave PGP: http://wintermute.homelinux.org/winter.asc

     Artículo: http://wintermute.homelinux.org/miscelanea/Seguridad%20en%20TCPA.txt



v1.05 (29/11/2002)


Este artículo pretende ser un análisis técnico objetivo sobre el
sistema hardware TCPA y el sistema operativo Palladium. Tras
encontrar la noticia hace tiempo en Barrapunto, vi que tan sólo
se encontraba acerca de TCPA y Palladium varios FAQs que parecían
tener un exceso de subjetividad (uniendo, por ejemplo, TCPA a
Palladium, cuando son sistemas independientes), y por otro lado
una tonelada de frías especificaciones a descifrar indicando los
entresijos técnicos de TCPA, y notas de prensa acerca de Palladium
por parte de Microsoft.

Es por esto que me dio la curiosidad y empecé a escribir este
artículo, intentando que ante todo fuera objetivo, de modo que cada
uno pueda leer que es lo que nos deparan tanto TCPA como Palladium y
decida por sí mismo, en lugar de mediante suposiciones y textos
encendidos contra o a favor de todo esto. Mi visión personal, es
la de que TCPA tiene puntos muy negativos - en particular las
Certification Authorities y la identificación posible de forma
unívoca de los usuarios en las ocasiones en que corresponda a
estas CAs -, pero que si ya es malo, es aún peor gracias a las
ideas que Microsoft ha mostrado sobre Palladium; advirtiendo el
lector los inevitables sesgos que de allí puedan surgir en los
matices de mis palabras, intento así que el lector pueda entender
qué es TCPA y qué es Palladium de la forma más objetiva posible,
y que desarrolle su propia opinión.

Aun así, este artículo no cubre complétamente todos los aspectos
de TCPA, como podría ser el método de autenticación del usuario
y su apropiación de la plataforma de forma única, así como el detalle
de las operaciones que se encuentran descritas en la especificación
de TCPA. En cualquier caso, son detalles que considero sobrecargarían
este artículo y que no son necesarios para comprender qué es todo
esto y en qué puede afectarnos.

Esto es el producto de algunos meses leyendo especificaciones,
algunos mails, y unos cuantos quebraderos de cabeza; no obstante,
siempre es posible que haya algún dato equivocado, con lo que
agradecería muchísimo que cualquiera que encuentre un error me
lo comunique a wintrmute@retemail.es para corregir el artículo.



Este documento se distrubuye bajo la GNU Free Documentation License
(http://www.gnu.org/copyleft/fdl.html)

-=-=-=[ Cambios ]=-=-=-=-=-=-=-=-=-=-=-

v1.05

He añadido notas a pie de página a lo largo del artículo. De este modo,
pueden verificarse los datos y el análisis.


v1.04

Ligeros cambios en el análisis de Palladium, puesto que algunas cosas
empiezan a cuadrar con Intel hablando sobre su proyecto LaGrande, aún
sin dar prácticamente ninguna información pero hablando de "ejecución,
memoria y almacenamiento" protegidos por hardware, lo cual podría
cuadrar con algunas características anunciadas para Palladium (hacia
quien parece enfocarse LaGrande). Intel, lo relaciona con Palladium,
lo cual podría traernos un nuevo capítulo en WinTel... (¿hará que
Intel posea cierta ventaja sobre el resto cuando se empiecen a realizar
hardware basado en TCPA ganando el juego junto con Microsoft? sólo
puede especularse por el momento)


v1.03

Respecto al original, tan sólo ligeros cambios en las referencias
a Palladium gracias al abstract de la charla dada por Microsoft en
el MIT. Aporta pocas cosas nuevas, aunque destaca la extraña idea
de protección entre procesos que Microsoft parece apoyar: el espacio
de memoria estaría protegido entre procesos pero de tal modo que
ningún otro proceso, ni siquiera el sistema operativo (y por lo
tanto el administrador) podrá acceder a otros procesos de usuario.

-=-=-=[ Indice ]=-=-=-=-=-=-=-=-=-=-=-=-

1.- Introducción a TCPA

     1.1.- Origen de TCPA
     1.2.- Implicaciones de TCPA

2.- Análisis sobre TCPA

     2.1.- ¿Qué componentes de la arquitectura cambian?
     2.2.- CRTM (Core Root of Trust)
     2.3.- TPM (Trusted Platform Module)
          2.3.1.- Valores de métrica del sistema
          2.3.2.- Algoritmos criptográficos
          2.3.3.- Autenticación usuario-TPM
     2.4.- Logs de PCR
          2.4.1.- Detalle de los registros PCR
          2.4.2.- Detección de cambios en PCR
     2.5.- Secuencia de arranque
     2.6.- Funciones de la TPM
          2.6.1.- Distintos tipos de drivers
          2.6.2.- Funciones en el driver primario (BIOS)
          2.6.3.- Memory Present Driver
          2.6.4.- Protected Storage
          2.6.5.- Nuevas identidades y la TTP

3.- Análisis sobre Palladium

     3.1.- Introducción a Palladium
     3.2.- Palladium a nivel kernel
     3.3.- Los "TOR" externos
     3.4.- Digital Rights Management

4.- Conclusiones

5.- Notas al pie

6.- Apéndice A: Bibliografía

7.- Apéndice B: Agradecimientos

-=-=-=[ 1.- Introducción a TCPA ]=-=-=-=-=-

======[ 1.1.- Origen de TCPA ]==========================

Existe una gran controversia y desinformación respecto a todo el tema
TCPA y Palladium, empujado por la ignorancia de medios de comunicación
a quienes se da credibilidad por un lado, y por otra por el propio
marketing de Microsoft; Newsweek y después MSNBC reproduciendo un
artículo original de Newsweek, hablaban de lo que ahora parece ser
la única verdad sobre todo este tema, que existe un chip llamado
"Fritz" de Microsoft en el que se basa su sistema operativo Palladium,
y que saldrá en breve siendo una especie de caja negra que decide que
programas podemos usar pegado a nuestra placa. Nada más lejos de la
realidad, y aunque la verdad sigue siendo muy preocupante, no es tal y
como se ha pintado; la contribución de Microsoft al lío consiste en
adjudicarse méritos que no le pertenecen, esto es, características
que no son de su sistema Palladium sino del chip TCPA e intentando
aprovechar esta tesitura para intentar crear en la mente del
consumidor que ambos son indisolubles. De hecho Microsoft es capaz
de mentir de forma flagrante cuando en su propio site web que
Palladium (que es un producto sin empezar) ofrece gracias a este
hardware la seguridad que no ofrece ningún sistema operativo ahora,
basando esta afirmación no en su producto sino en un hardware que
no le pertenece.

TCPA es la unión entre varias de las empresas más importantes del sector
de la informática con el objetivo de crear unas especificaciones comunes
destinadas al "aumento de la confianza para sus clientes", dada la
necesidad de una mayor seguridad en la información (siendo esta la visión
"oficial", pues con un Sistema Operativo como Palladium tendríamos otras
consecuencias de aspecto mucho menos positivo, y lo mismo sucede con
algunas de las características de TCPA). Se trata TCPA de un standard
cuyas especificaciones son públicas, un cambio a nivel arquitectural del
PC instalando dos nuevos componentes de tipo "pasivo", es decir, que no
tendrían control sobre las acciones del ordenador en su uso normal,
sino que lo proveerán de diversas funcionalidades; el problema, en
gran medida, estará en la forma en que se utilicen...

Esta alianza tiene como fundadores a Compaq, HP, IBM, Intel y Microsoft,
aunque posteriormente se han unido gran cantidad de compañías como, por
listar algunas, Adobe, American Express, American Megatrends, AMD, Dell,
Fujitsu, Motorola, National Semiconductor, NEC, Novell, Philips, Samsung,
Siemens, SMSC, Toshiba, Tripwire, Verisign y muchas otras (curiosamente,
esta lista ha desaparecido alrededor de septiembre del 2002 de la página
web de trustedcomputing).

Como es fácil deducir ante esta inmensa amalgama de compañías - entre
las que se encuentran los principales productores de semiconductores
del mundo -, TCPA no es algo que deba ser tomado a broma. Al contrario,
se trata de un serio esfuerzo que une a un amplio espectro de compañías
relacionadas con las telecomunicaciones y la computación de cara a
cambiar radicalmente la arquitectura de los equipos informáticos, para
bien o para mal, y por tanto hemos de estar al tanto de qué está
sucediendo antes de que sea demasiado tarde.


======[ 1.2.- Implicaciones de TCPA ]=====================

Este nuevo sistema no es tan eficiente ni tan seguro como sus defensores
intentan asegurarnos; tiene algunos aspectos que efectivamente podrían
mejorar la seguridad en nuestros PCs, pero sin duda no es cierto todo lo
que ellos dicen.

Según su propio FAQ, "con esto se puede negar el acceso a datos si
un programa malicioso como un virus es introducido en una plataforma,
puesto que necesariamente esta penetración cambia el estado del
software de dicha plataforma". Como se podrá ver y deducir más adelante
a través del análisis técnico de esta plataforma, esto no es cierto,
pudiendo afirmarse que TCPA no cumple, tal y como anuncia, la
característica de "confianza"; esto es, el que (según su propia
definición) "pueda confiarse en que el entorno software de la
plataforma está operando según lo esperado".

Sí es cierta sin embargo la continuación de este mismo párrafo en el
FAQ, donde se nos dice que este sistema podría mejorar la confiabilidad
en sistemas de llave pública y privada, dado que la llave privada que
va a identificar al usuario posee una protección hardware, y que tan
sólo podría romperse por software mediante fuerza bruta.

En el lado negativo, tenemos las Certification Authorities; esto es,
que las identidades generadas por TCPA (no-unívocas respecto a la
plataforma) han de ser certificadas por terceros en los que confiamos,
lo cual permite que, dado que para esta certificación se envían datos
únicos del sistema, un sistema vaya a requerir ser él mismo quien
certifica la identidad siendo por tanto capaz de identificar un PC
de forma única (tal y como ya se intentó con los números de serie en
los Intel). Este método, descrito más adelante, es algo más indirecto
pero igualmente peligroso.

-=-=-=[ 2.- Análisis de TCPA en PC ]=-=-=-=-

Este apartado se dirige al análisis completo acerca del funcionamiento
del sistema TCPA en sistemas PC y compatibles, de acuerdo con las
especificaciones presentes en www.trustedpc.org acerca de este mismo
sistema, y las especificaciones externas complementarias utilizadas
respecto a los standards indicados por esta misma documentación.

Dada la cantidad de compañías dispuestas a confiar en TCPA y utilizar
su standard, esta especificación es muy completa y en pocos lugares
deja espacio a la confusión; no obstante presuponen referencias a mucha
otra documentación y sistemas que no se encuentran allí descritos, al
tiempo que se encuentran escritas en un lenguaje propio de una
especificación de standards: es decir, que realmente hay que "descifrar"
sus contenidos para poder llegar a una comprensión razonable del
funcionamiento real del sistema - y de paso sumergirse en otras
especificaciones de cosas de las que TCPA depende -, especificación que
por otro lado queda constreñida por muchas variables de modo que su
implementación real no será muy diferente de lo aquí indicado; dado que
todas estas empresas empezarán a fabricar componentes hardware y
software adecuados a esta documentación, podemos saber ya con un grado
relativamente alto de fiabilidad cómo será el funcionamiento de estas
máquinas.


==[ 2.1.- ¿Qué componentes de la arquitectura cambian? ]=========

La organización actual de un PC, siguiendo el tipo de nomenclatura dado
por la propia TCPA, sería la siguiente[1] (tomando el nivel superior como
mas externo, y el inferior como más interno):

|--------------------|
| Sistema | <- Periféricos, drivers, aplicaciones
|--------------------|
| Plataforma | <- Unidades de disco, tarjetas, fuente
|--------------------|
| Placa base | <- CPU, memoria, interfaces de conexión
|--------------------|
| Microprocesador |
|--------------------|

Según el nuevo modelo propuesto por la TCPA - que peca un poco de
prepotente dado lo que luego en realidad es -, tendríamos algunos cambios
en esta arquitectura:

|--------------------|
| Sistema | <- Sin cambios
|--------------------|
| Plataforma | <- Se añade el "Subsistema TCPA"
|--------------------|
| Placa base | <- Sin cambios
|--------------------|
| Microprocesador |
|--------------------|
| TBB | <- Compuesto por TPM y CRTM
|--------------------|

Según TCPA, los cambios realizados sobre la arquitectura genérica del
PC son entonces a dos niveles; por un lado situando un subsistema TCPA en
el nivel de plataforma, y por otro añadiendo un bloque llamado TBB
(Trusted Building Block) a nivel más bajo que el del propio
microprocesador, bloque que va a ser considerado la única parte
fiable de todo el sistema.

El TBB o Trusted Building Block va a estar compuesto por dos partes,
CRTM o Core Root of Trust, y TPM o Trusted Platform Module. Cuando los
veamos ahora en detalle, podremos darnos cuenta de que esta clasificación
no es del todo correcta. Dado que la CRTM es una especie de "BIOS
confiable", sólo la podríamos considerar como primaria en el sentido
de que el PC arranca desde ella. La TPM, que también veremos ahora en
detalle, podría ser considerado un periférico integrado (lo cual
tampoco cuadra en esta forma en que nos presentan TCPA como un cambio
arquitectural completo) que realiza unas determinadas funciones. El
subsistema TCPA serían, eso sí, los mecanismos que unen estos elementos
de forma casi indisoluble - aunque puede anularse - a la arquitectura
del PC.



==[ 2.2.- CRTM (Core Root of Trust) ]=======================

Este es el lugar que al arrancar el sistema va a ejecutarse en primer
lugar[2], con lo que TCPA considera absolutamente imprescindible
que pueda asegurarse su integridad; dado que se trata del código de
inicio no debe ser alterado de ninguna forma para que el sistema
pueda seguir considerándose seguro, y todo reset debe hacer al procesador
comenzar a ejecutar en algún punto del CRTM. Este, es el equivalente a
la vieja BIOS en nuestros PCs, y como tal será actualizable - en teoría,
tan sólo por el fabricante de esta. Una de las cosas más curiosas aquí,
es que se dice que el fabricante debe controlar los updates y el
mantenimiento del código de este componente, desentendiéndose de los
mecanismos que se utilicen para su actualización pero al tiempo
mostrándose la necesidad de que estos existan; en definitiva, escurriendo
el bulto de la seguridad en este particular.

Al comenzar la ejecución en la CRTM, se encargará de comprobar su propia
fiabilidad, la de los componentes del sistema, las Extended ROM de los
periféricos, y el código al cual vaya a ceder el control, extendiendo así
lo que se denomina "cadena de confianza"[3].



==[ 2.3.- TPM (Trusted Platform Module) ]====================

Este componente - el más importante - debe estar unido a la placa base
de forma que pueda establecerse una confianza en este método, con dos
posibles métodos[4]:

- La TPM un chip soldado a la plataforma.

- Mediante una SmartCard situada en un bus común (como podría ser
el USB). La forma de unir la TPM a la plataforma sería mediante algún
tipo de método criptográfico como pudiera ser un secreto compartido entre
la Plataforma y la SmartCard, pero de modo que tan sólo pudiera haber una
TPM para una plataforma en particular.

Se utilice uno u otro sistema, la TPM va a funcionar de forma lógica como
un tipo muy particular de SmartCard; va a dar funciones para intentar
asegurar la integridad del sistema con una memoria reescribible y tendrá
microprogramados varios algoritmos criptográficos[5].

Describo a continuación los componentes de la TPM:


2.3.1.- Valores de métrica del sistema
--------------------------------------

Para asegurar la fiabilidad de los componentes del sistema, la TPM va a
almacenar en ocho registros de 32 bits llamados PCR[0] a PCR[7] ocho
valores que no van a hacer referencia a partes individuales del sistema
sino a grupos de ellas, los cuales serán descritos más adelante.

El dilema en el diseño consistía en que mientras que evidentemente ocho
registros dedicados a hacer mediciones sobre un sistema son pocos si
quiere evaluarse la fiabilidad de toda la plataforma al detalle, un
número excesivo resultaría en un alto coste. Un sistema circular
resultaría inseguro por la posibilidad de sobreescribir datos por falta
de espacio, y uno que fuera llenando una pila con los valores medidos
podría llegar a acabarse y generar inconsistencias.

Por tanto, la perspectiva que adopta el TPM a este respecto es la de que
una vez inicializada una secuencia con un valor conocido por la tarjeta
(la primera inicialización del registro), cada vez que se necesite añadir
un nuevo elemento a la secuencia y usar así estos registros del control
del sistema, se realizará un algoritmo tipo hash sobre la concatenación
de la secuencia con el nuevo valor[6]. Es decir:

* El registro PCR[x] está inicializado por la propia TPM a un valor
que sólo ella conoce, y queremos añadir una medida del sistema (por
ejemplo, un hash de la tabla de particiones del disco duro):

|-------------------------------| |---------------------|
| Registro PCR | + | Nuevo valor |
|-------------------------------| |---------------------|

* Para ello, concatenamos los 32 bits del registro PCR a los 32 bits
del hash realizado, generando una secuencia concatenada de 64 bits:

|----------------------------------------------------|
| Secuencia concatenada con la del dispositivo nuevo |
|----------------------------------------------------|

* Ahora, cogemos esta secuencia concatenada y hacemos un nuevo hash
sobre ella, de modo que nos quedan 32 bits que son los almacenados en
el PCR[x] al que queríamos añadir la nueva medición:

|-------------------------------|
| Secuencia "hasheada" | <- Nuevo valor del registro PCR
|-------------------------------|


Estos valores van a ser la base de la confianza que el sistema va a
poner en los dispositivos que dependen de él. La comunicación de estos
valores cuando le sean solicitados a la TPM, se realiza firmándolos
mediante una clave privada que posee la TPM en la parte de memoria
no accesible desde el exterior (y que sólo va a servir para realizar
estas firmas), de tal modo que el TPM pueda autenticarse como autor
de la información remitida y que quien la solicite pueda estar seguro
de que es fidedigna[7].

Del mismo modo, esta comunicación se encuentra protegida contra
ataques de replicación; esto es, en cada petición que se haga a la
TPM se le enviará un valor aleatorio de modo que la respuesta firmará
además de sobre su respuesta, sobre ese valor, demostrando así que la
TPM está funcionando en ese momento y respondiendo exáctamente a esa
petición del sistema.

Ahora bien, lógicamente aquí hay un "problema", pues para poder
asegurar que nada ha cambiado en las mediciones realizadas, las
operaciones han de realizarse de nuevo de principio a fin y en el mismo
órden en el que fueron realizadas por primera vez. Es decir, si en un
PCR[x] hemos analizado tres componentes concatenando cadenas y con el
hash del componente y el posterior, para llegar de nuevo al mismo
resultado que hay almacenado en el PCR hemos de realizar un análisis
en el mismo órden de todos los componentes. Para ello, se utilizarán
unos "logs" de actividad, que se encuentran detallados en la sección
2.4


2.3.2.- Algoritmos criptográficos
---------------------------------

Encontramos una serie de algoritmos de encriptación microprogramados
dentro de la propia TPM de modo que resulten fiables (sin tener que
recurrir a una entidad externa). Estos son[8]:

* SHA-1: Para las operaciones de hash sobre los valores de métrica
almacenados por el sistema.

* RSA: Tiene varios usos; la llave privada puede firmar datos
emitidos por la TPM. También se utiliza para firmar datos que necesiten
verificar la identidad de la TPM, y encriptar/desencriptar datos y las
llaves en niveles inferiores del árbol. Sólo hay una llave principal,
pero pueden crearse varias identidades de firmado (detallado en otras
secciones).

* RNG: Generación de números semi-aleatorios de cara a verificar el
que el sistema esté "vivo", que intenta asegurar la aleatoriedad a
través del uso de una función de hash sobre datos semi-aleatorios.
Las ideas acerca del origen de la semilla semi-aleatoria pretenden
ser baratas y pueden ser un punto débil dada la necesidad de un bajo
coste; se propone la utilización de mediciones de temperatura o
pulsaciones de teclas como semilla a partir de la cual generar los
valores aleatorios (que por ejemplo servirían para este evitar los
ataques por replicación indicado en el anterior apartado, pues la
secuencia aleatoria sería generada por la propia TCPA).

* 3DES: El uso de triple DES no se encuentra especificado, y no se
considera necesaria la inclusión de sistemas simétricos de cifrado.
Se sugiere no incluir este sistema por el coste añadido y escasa
funcionalidad, aunque podría servir para aquellas configuraciones en
los que la TPM estuviera en una SmartCard externa, para la comunicación
respecto a un secreto compartido con la plataforma y autenticación de
la TPM.


2.3.3.- Autenticación usuario-TPM
---------------------------------

La confirmación de que el usuario correcto está utilizando la TPM sigue
una lógica en la que el sistema tiene cuatro estados posibles[9]:

- Permanente/Inactiva: Este es el estado en el cual el usuario ha
decidido que su información se grabe de forma permanente - momento en que
la tarjeta le "pertenece", de tal modo que tan sólo él pueda utilizar la
tarjeta; el que la tarjeta se encuentre inactiva, implica que el usuario
aún no se ha autenticado.

- No Permanente/Inactiva: En este estado, la TPM no guarda la información
de su propietario y se encuentra sin activar; digamos, que es el estado de
fábrica o el posterior a su desactivación si no hemos decidido que nuestra
información sea permanente.

- Activa (independientemente de la permanencia): Esta sería la forma
habitual en que operaría la TPM, momento en que se dejaría operar a la
plataforma, que no funcionaría sin la existencia de la TPM por motivos de
seguridad. Esto no evitaría que se pudiera anular posteriormente la TPM
a través de software, pero sí haría al menos que el usuario tuviera que
identificarse para poder usar el sistema.

En cualquier caso, parece ser que la configuración Activa/No Permanente
se pretende evitar, puesto que cada TPM sólo debe tener un dueño; una TPM
sin dueño sólo podría realizar operaciones muy básicas como informar de
que existe, pero no dejar que la plataforma opere normalmente :).

Uno de los grandes problemas que los propios fabricantes reconocen, es
la radical política sobre la desactivación de la TPM. Además de su
desactivación mediante el apagado del PC, la TPM se desactiva si recibe
un mensaje sin autenticar - e incluso mediante un comando que puede
ser remoto y que no necesita de autenticación, siempre que pueda
accederse a la llamada a la TPM -, sometiéndose a un reset completo
todo el sistema. Esto deja la puerta abierta - y esto se encuentra
reconocido por los propios desarrolladores - a una innumerable cantidad
de ataques DoS[10] contra cualquier plataforma basada en TPM, que debería ser
reseteada a continuación.



==[ 2.4.- Logs de PCR ]================================


Todo esto es muy bonito, pero aquí hay un problema; aunque la TPM en su
parte oculta contenga los valores iniciales de los PCR, ¿cómo distingue
si su hash es correcto, cómo opera cuando hay varios dispositivos que
han ido concatenándose a la secuencia y han sido hasheados? Para esto
van a almacenarse una serie de "logs" acerca de los dispositivos que
han ido añadiéndose a la secuencia inicial del registro PCR. Estos
logs, guardarán una descripción de la entidad que ha sido medida, y
la propia medición, acortando el camino para poder asegurar la integridad
de los registros PCR de la TPM con la operación sobre los valores de
hashing almacenados en estos logs.

Sin embargo aquí vamos a encontrar una de las partes más interesantes
del TCPA; aunque se nos vende la idea de la máxima seguridad en el TPM
al no contener más que ocho registros de una longitud fija, si estos a
su vez necesitan de unos logs para reconstruir el camino en que se
llevó a cabo esta operación con una longitud variable de elementos
hay algo que tiene poca lógica; lo único que han hecho para
solucionarlo, ha sido "desplazar" el problema fuera de la TPM. El
objetivo es hacer segura la TPM, pero al coste de delegar la variabilidad
de tamaño y el acceso aleatorio hacia otro dispositivo.

Este va a ser el propio firmware del sistema, dotado de un standard
conocido como ACPI (Advanced Configuration and Power Interface),
que fue desarrollado por la unión de las empresas Compaq, Intel,
Microsoft, Phoenix y Toshiba, y que ahora felizmente podrán implantar
como standard inevitable; esto es una "trampa" monopolística, dado que
todo sistema que implemente TCPA tanto desde el punto de vista del
sistema operativo como del firmware deberá tener una especificación ACPI
aprobada, lo cual depende de las empresas anteriores.

La especificación en sí, pretende afectar a la relación entre una placa
base y sus dispositivos con un sistema operativo implantando una
especificación de código en la BIOS y la forma de relacionar un sistema
operativo con él (API del sistema), con el objetivo de obtener sistemas
Plug&Play más robustos y un control mayor de estos dispositivos, tanto
para su configuración como para funciones de ahorro de energía y demás.

En este caso, la implementación ACPI va a utilizarse como parte del
firmware del sistema, en particular su sistema de tablas; por un lado
varía la forma de implementación en la POST-BIOS, aunque de forma
"lógica", una vez el sistema se encuentre en ejecución, estas tablas
serán mapeadas en la memoria de kernel del sistema operativo para
proveerle de un acceso directo a ellas[11].

El principio de estas tablas puede localizarse en memoria en las
plataformas i386 mediante el puntero RSDP (Root System Description
Pointer) que apunta hacia la RSDPS. Una vez tenemos el puntero RSDP
hacia la tabla RDSPS[12], encontraremos en ella esta estructura:

|----------------------------------------------------------------------|
| Puntero RDSP -> Tabla RDSPS en memoria de kernel |
|---------|------------|-----------------------------------------------|
| Offset | Longitud | Descripción |
|---------|------------|-----------------------------------------------|
| 0 | 8 | Cadena de texto identificativa "RDS PTR" |
| 8 | 1 | Checksum |
| 9 | 6 | Identificador OEM |
| 15 | 1 | Numero de version |
| 16 | 4 | Direccion FISICA de la RSDT |
| 20 | 4 | Longitud de la tabla en bytes |
| 24 | 8 | Direccion de 64 bits de la XDST |
| 32 | 1 | Checksum extendido |
| 33 | 3 | Reservado |
|---------|------------|-----------------------------------------------|

En principio lo que nos va a interesar aquí es el puntero a la tabla
RSDT (Root System Description Table) que es digamos el núcleo de todo lo
que esta especificación ACPI va a implicar en TCPA. Aquí, encontraremos
una diferencia sustancial respecto a la especificación "típica" de ACPI
puesto que se añadirá un nuevo puntero a tabla que hará referencia a la
"tabla TCPA".

La forma de localizar estas subtablas es sencilla; a 36 bytes de
desplazamiento respecto al comienzo de la RSDT tenemos un array de
punteros de 32 bits que podemos recorrer recursivamente hasta encontrar
la tabla adecuada, cuyo primer campo será un identificador del tipo de
tabla (por ejemplo en la misma RSDT los 4 primeros bytes son esta
palabra, "RDST").

Normalmente, esta RSDT apuntará entonces a dos lugares importantes:

- Tabla FACP o Fixed ACPI Description Table: Esta es la de menor
importancia; posee información acerca de los dispositivos del sistema y
parámetros para la configuración de sus características Plug&Play, así
como punteros a su vez a otras tablas como la DSDT (una tabla extendida
indicando características del hardware de automedición de temperatura y
todas aquellas que no cupieran en la FACP) o a la tabla FACS (dedicada a
sincronización y control). En cualquier caso, los únicos campos que
podrían revestir importancia (en la FACS, los que identifican la
configuración de hardware) son dejados de lado al existir las nuevas
estructuras TCPA.

|---------| |--------| |--------|
| RSDPS | -------> | RSST | -------> | *TCPA* |
|---------| |--------| |--------|
|
| |--------|
\----> | FACP | --> ... DSDT y FACS ...
|--------|


- Tabla TCPA: Aquí es donde ya entramos en el meollo de la cuestión,
la nueva tabla añadida por TCPA a la especificación ACPI, que es
precisamente donde se van a almacenar los logs que buscamos. Esta
tabla se almacena específicamente, dentro de la información relacionada
con BIOS y de modo que sea mapeada también dentro de la memoria
reservada para estos asuntos, y tiene una estructura de tamaño variable
en la que tras una serie de valores de longitud, del propio fabricante
y demás, tenemos una serie de entradas que corresponden a los logs
realizados, accesibles por el sistema operativo:

* Entrada TCPA:

|------|--------|--------------------------------------------------|
|Offset|Longitud| Datos almacenados |
|------|--------|--------------------------------------------------|
| 0 | 4 | Cadena de texto 'TCPA' |
| 4 | 4 | Longitud completa de la tabla TCPA |
| 8 | 1 | Numero de revision de la tabla |
| 9 | 1 | Checksum |
| 0Ah | 6 | Identificador del fabricante (texto) |
| 10h | 8 | Identificador del modelo del fabricante |
| 18h | 4 | Revision de la tabla TCPA para este modelo |
| 1Ch | 4 | Identificador del fabricante de la tabla |
| 20h | 4 | Numero de serie respecto al apartado anterior |
| 22h | 2 | Reservado (puesto a 0000h) |
| 24h | 4 | Longitud maxima en bytes de la zona de logs en |
| | |el sistema antes del boot |
| 28h | 8 | Indicación de la dirección física (64 bytes) en |
| | |que se encuentra almacenado el area de log de |
| | |eventos del sistema |
|------|--------|--------------------------------------------------|

La lista en sí va a residir en el propio firmware ACPI, y va a
mapearse en memoria en una dirección reservada de BIOS de modo que
pueda ser leído desde el sistema operativo. La tabla TCPA se diferencia
sin embargo del resto de tablas ACPI en el sentido de que es
non-reclaimable, en el sentido en que "reclaimable" significa que una
vez se ha acabado de utilizar, el propio SO puede reclamar su espacio
para utilizarlo con otras aplicaciones. El sentido de que resida en una
zona "non-reclaimable", es el de que al haber una hibernación por parte
del sistema operativo, no pueda suceder que al realizarse un reset esta
zona de memoria estuviera mapeada hacia otro lugar, con lo que no
pudieran realizarse las comprobaciones pertinentes.

El área de log de eventos del sistema, está compuesto por una
estructura de datos de tamaño variable llamada TCPA_PCR_EVENT, cada
una de cuyas entradas tienen esta forma[13]:

|------|--------|--------------------------------------------------|
|Offset|Longitud| Datos |
|------|--------|--------------------------------------------------|
| 0 | 4 | Identificador del evento (EventID) |
| 4 | 4 | Longitud de los datos almacenados en EventData |
| 8 | ? | EventData |
|------|--------|--------------------------------------------------|

El valor contenido en EventID es el que nos va a indicar algunos
detalles acerca de qué va a contener la estructura EventData. Por
ejemplo, mientras que para las cadenas de la POST-BIOS se utilizará un
EventID=3h y los datos son sus valores hasheados, para la CMOS se
usará un EventID=4h y sin embargo el EventData serán los valores sin
hashear de la CMOS.


La forma de acceder a estas tablas son las standard en la especificación
ACPI y los drivers de este que proporcionan acceso a la API ACPI, de
forma centralizada con la INT 15h que ya es utilizada en estos sistemas
para poder leer las tablas ACPI. Mediante la función 0E820h de la Int15h,
el sistema operativo al arrancar va a poder obtener el inicio de estas
tablas[14]:

* Llamadas a 0E820h:

EAX = 0E820h
EBX = "Continuation value", 0 la primera vez y el valor devuelto por la
llamada previa en las subsiguientes
ES:DI = Buffer donde la BIOS va a escribir los datos
ECX = Tamaño del buffer (mínimo 20 bytes)
EDX = 'SMAP'

Devolverá el valor siguiente para EBX en EBX :), en ECX el número de
bytes escritos, y activará CF si hubo error.

La estructura del buffer es la siguiente en lectura:

|----------------------------------------------------------------------|
| Buffer |
|---------|------------|-----------------------------------------------|
| Offset | Longitud | Descripción |
|---------|------------|-----------------------------------------------|
| 0 | 4 | 32 bits inferiores (base address) |
| 4 | 4 | 32 bits superiores (base address) |
| 8 | 8 | Longitud |
| 10h | 4 | Tipo del bloque de memoria |
|---------|------------|-----------------------------------------------|

Es en el tipo de bloque de memoria entonces donde vamos a tener que
fijarnos si queremos localizar estas tablas; el tipo 1 pertenece a
memoria normal, el 2 a memoria tipo "reserved", el tercero a memoria
de tablas ACPI, y el cuarto a memoria NVS de sistemas ACPI. Sin embargo
meter la tabla TCPA en una tipo 3 la haría de tipo reclaimable con lo
que no va a residir en un bloque de este estilo sino, por lógica en
un tipo Reserved (como ellos indican, "reserved non-reclaimable");
la forma cómoda de acceder a ello no será sin embargo así, sino desde
las propias tablas ACPI a partir del sistema de punteros descrito con
anterioridad mediante el puntero RSDT.



2.4.1.- Detalle de los registros PCR
------------------------------------

Cada uno de los ocho registros PCR está destinado a la métrica de una
determinada parte del sistema[15]. Así, tenemos:

PCR[0]: Loggea todo código ejecutable que pertenezca a la CRTM (como
autocomprobación) y firmware del sistema

PCR[1]: Updates de microcódigo para la CPU, configuración de periféricos
en la plataforma, la CMOS y la ESCD (Extended System Configuration Data)
si existe, y SMBIOS (System Management BIOS, saca información sobre
periféricos y sus números de serie, información de la BIOS, memoria
física y caché, slots, etc)

PCR[2]: Código de la Option ROM, esto es, memoria ejecutable de sólo
lectura de periféricos no-arrancables como pueda ser una tarjeta
gráfica. En caso de que se trate de un periférico arrancable, este
código se hashearía como IPL y no como Option ROM.

PCR[3]: Configuración y datos de la Option ROM.

PCR[4]: Código del IPL, es decir, el código de arranque; en el caso
de un HD, el código de la MBR sería este IPL.

PCR[5]: Configuración y datos del IPL, es decir, lo que en un disco
duro sería la tabla de particiones

PCR[6]: Transición de estados (para eventos de ACPI, como dormir o
despertar el PC, etc)

PCR[7]: Reservado




2.4.2.- Detección de cambios en PCR
-----------------------------------

Uno de los detalles que quedan al aire tras esta explicación es el
siguiente: ¿cómo reacciona el equipo ante un cambio en la
configuración, en los registros PCR? Dado que es la propia TPM quien
tan sólo da funciones que permiten comprobar la existencia de cambios
en la configuración, esto queda sin especificar dentro del propio
TCPA. La reacción del sistema, explicada por ellos mismos en respuesta
a un mail que envié, sería la siguiente, traducido literalmente de un
mail de consulta al grupo de desarrollo, donde debemos entender
"consumidor" como sistema operativo, BIOS, etc, y no el usuario:

"La forma en que un consumidor utiliza los contenidos del PCR
(aplicación, sistema operativo, etcétera), dependen de ese mismo
consumidor. [...]
La notificacion de cambio en un registro PCR tambien es opcional
para el consumidor del PCR. La aplicacion que lo utiliza puede
ocultar el hecho de que el valor ha sido cambiado y hacer un
upgrade, o puede hacer que el usuario de la plataforma participe
en ese upgrade; de nuevo todas estas opciones dependen de quien
programa las aplicaciones."

Es decir, que la seguridad en el fondo está delegándose también en
las medidas que el usuario desee realizar; por un lado es de utilidad
cuando sin ningún motivo advertimos un cambio arquitectural o de
tipo software que no hemos realizado, pero por otro puede permitir
engañar al usuario para instalar código malicioso que por tanto
salte la seguridad del sistema completo.




==[ 2.5.- Secuencia de arranque ]=========================


Nada más encender nuestro ordenador, se cederá el control a la CRTM,
equivalente como dije a la BIOS actual, que se encargará de comprobar si
se ha realizado alguna modificación sobre sí misma (en PCR[1]), sobre
la plataforma (en PCR[2]), o las Option ROM (PCRs 3 y 4), para hacerlo
(o que lo hagan las propias Option ROM autoarrancables) sobre la
POST-BIOS (considerando POST-BIOS el sistema de arranque, por ejemplo
la tabla de particiones del disco duro, en PCR[5]. Realizadas estas
operaciones, quedará el IPL con el control del sistema.

Este IPL (el código de arranque) a su vez leerá la propia tabla de
particiones hasheándola en PCR[5], y tras una nueva comprobación
hasheando el inicio del sistema operativo y así extendiendo la
"cadena de confianza" hasta este, se irá considerando el sistema
como seguro.[16]




==[ 2.6.- Funciones de la TPM ]===========================


2.6.1.- Distintos tipos de drivers
----------------------------------

La TPM va a proporcionar varios drivers para sus llamadas.

El primero de ellos es a través de la INT 01Ah como interfaz a través
del cual se pueda llamar a sus funciones, y sólo estará disponible para
la BIOS (que deberá desactivarlo posteriormente). Del mismo modo,
implementará un driver en la ACPI en memoria non-reclaimable llamado
"Memory Present Driver", que será el utilizado posteriormente por el
sistema operativo.

Las funciones tunneleables, serán las dedicadas a la creación de
llaves para el protected storage, autenticación del usuario,
hashing y generación de eventos, y certificación, que han sido
descritas de forma genérica en anteriores apartados, y se detallan
respecto a protected storage y certificación más adelante en las
subsecciones 2.6.4 y 2.6.5


2.6.2.- Funciones en el driver primario (BIOS)
----------------------------------------------

Las funciones, detalladas respecto a la convención usada para llamarlas
en la especificación TCPA/PC, son las siguientes en BIOS (aunque pueden
"tunnelearse" otras hacia la TPM, pero estos dos tipos son las dos
específicas que quedan implementadas como funciones de la int 01Ah)[17]:

* StatusCheck: Petición para que la TCPA responda indicando si
existe y su número de versión, devolviendo como dato interesante en
ESI un puntero al log de eventos en memoria (lo cual evita tener
que recorrer las tablas ACPI).

* HashLogExtendEvent: Realiza un hash sobre la porción de espacio
indicada, almacenando en el registro PCR indicado y generando los
logs necesarios.

* Apagado de sí mismo: Mediante la opción AL=03h, desactiva este
driver dando la oportunidad de ejecutar el sistema acabando con
la presencia del subsistema TCPA.


2.6.3.- Memory Present driver
-----------------------------

Para el MPDriver y sus llamadas[18], tendremos una estructura de
cuatro bloques de 32 bits (la forma de pasarlos es a discrección
de quien fabrique el driver en la ACPI) que han de ser los
siguientes:

- pbInBuf: DD ? ; Puntero a los datos de entrada
- pbInLen: DD ? ; Longitud máxima de los datos de entrada
- pbOutBuf: DD ? ; Puntero al buffer para la respuesta
- pbOutLen: DD ? ; Longitud máxima de este buffer y en la
;respuesta, nº de datos leídos.

- AL: Indicará un selector de función.

Este driver implementará tres funciones específicas, siendo el
resto de TCPA "tunneleables":

* Un StatusCheck al estilo del de la BIOS, comprobando que la TPM
funciona correctamente

* Una función de inicialización (MPInitTPM, AL=01h), inicializando el
driver y estableciendo un canal de comunicación con la TPM

* Una función MPCloseTPM para acabar con la comunicación con la TPM
(AL=02h)




2.6.4.- Protected Storage
-------------------------

TCPA provee no sólo de uno, sino de varios pares de llave pública y
privada. Además, aquellas llaves utilizadas para firmar no pueden
usarse para cifrar o descifrar.

La TPM básicamente contiene una llave pública/privada RSA que es
llamada la "Storage Root Key", generada dentro de la TPM y que no
puede extraerse de ninguna forma (protección hardware) de esta. De
este modo y a través de sub-llaves, TPM actúa como un intermediario
también para asegurar datos contenidos fuera de ésta, que deberían
en último término ser protegidas por el cliente externo, pero que
sólo serían accesibles a través de funcionalidades de la TPM. De
la Storage Root Key colgarán entonces dos árboles, uno no-migrable
compuesto por llaves generadas por la propia TPM, y otro migrable
que sólo puede poseer llaves que no hayan sido generadas de forma
interna[19].

Uno de los tipos de datos que pueden almacenarse externamente a
la TPM son efectivamente otras llaves de par privado/público,
formando un árbol cuya raiz será el SRK, cuyos nodos o ramas
serán llaves dedicadas únicamente a encriptar y desencriptar,
y cuyas hojas son llaves de firma, de la forma siguiente:

|-------------------| |-------------------| |----------|
| Llave no migrable | | Llaves de cifrado | | Llaves |
| dentro de la TPM | ----> | y descifrado | ----> | de firma |
|-------------------| |-------------------| |----------|

La idea tras esto, es que la llave SRK protege las de
cifrado/descifrado; descifradas estas llaves intermedias,estas
descifrarían los datos que quieren protegerse (que habrían sido
cifrados a través de funcionalidades de la TPM añadiéndo un hash
firmado), y la llave de firma, descifrada por la llave de
cifrado/descifrado de la que depende, comprobaría este hash
firmado haciendo la operación inversa. Finalmente, la TPM provee
de mecanismos para que estos datos encriptados a través de las
ramas y hojas del árbol sean migradas y compartidas con otros
sistemas.

Un ejemplo del uso de este sistema, es el de la autenticación
en un sistema multiusuario; las llaves de cada usuario se
almacenarían en un nodo, y estos podrían activarlas bajo el
sistema que tuviera la TPM y autenticarse mediante ellas,
utilizando sus llaves de cifrado/descifrado y firma para
sus actividades (de nuevo, una característica que puede ser
positiva/negativa dependiendo de la implementación del
sistema operativo). Con funciones internas, puede decidirse
que una parte de este árbol sea migrado, exportado, hacia
otro sistema (conociendo claves de un privilegio superior,
es decir, de las que cuelgue aquello que se quiere migrar).



2.6.5.- Nuevas identidades y la TTP
-----------------------------------

La TPM parte de un identificador único respecto de sí misma para poder
asegurar su identidad ante otros; sin embargo, esta identidad nunca es
utilizada diréctamente sino a través de una Autoridad de Certificación
(CA), también llamada Trusted Third Party (TTP). Estas identidades
certificadas por la TTP, intentan asegurar que quien hizo el request
de una identidad realmente es una TPM.

La idea es similar a la del Protected Storage, con un par llave
pública/privada dedicada a la firma para autenticación, una
certificación de una autoridad externa que asegure esta pertenencia
a una TPM. Pero más allá, la TPM sólo lo utilizará como identidad a
través de su función TPM_MakeIdentity[20], que requiere de esta
certificación. Pueden en una TPM coexistir varias identidades, con
la condición de que cada una de ellas sea validada por una (y sólo
una) CA.

Aquí, tenemos una de las brechas más serias en la privacidad que
contiene el sistema TCPA, pues los pasos a seguir son los
siguientes[21]:

* La TPM crea una firma de forma interna, la que será una nueva
identidad.

* Envía pruebas sobre que la TPM sea una TPM genuina así como datos
de la plataforma (firmados por esta nueva llave dedicada para firmar)
y la llave pública a la Certification Authority, quien la valida
haciendo la operación inversa (invirtiendo la operación de firmado
para asegurar que proviene de la clave que lo ha firmado). Entre los
datos enviados firmados, está también la llave pública de la CA, de
modo que pueda asegurarse que esta petición se dirige a esa CA y no
a otra. En definitiva, la CA comprueba que los datos de la plataforma
enviada corresponden a una TPM genuina.

* La CA encripta con la llave pública de la TPM solicitante los datos
de certificación y los envía de vuelta, indicando a la TPM a qué
identidad está dirigida su confirmación (aquella sobre la que se ha
pedido certificación).

Es decir, que la idea pretende que se pueda certificar una llave de
modo que no se pueda identificar a qué TPM en particular pertenece,
pero sí de forma que pueda asegurarse que pertenece a una TPM (por
parte del certificador). Así, cuando se utilice esta identidad, no
podría ser una identificación unívoca con el dueño del PC.

Ahora bien, se nos plantean dos cuestiones por las cuales esto, que
es asegurado también en el FAQ de TCPA escrito por esta alianza (es
decir, el que no hay una identificación unívoca del propietario), es
falso:

- En primer lugar, que la identificación si bien no se hace respecto
a la llave principal (SRK) que va a encriptar a su vez el juego de
llaves que constituirán la nueva identidad, sí puede hacerse una
identificación mediante otros métodos. Por ejemplo, si esta operación
se realiza respecto a una entidad certificadora a través de la red,
la IP de nuestro origen sirve para identificar con facilidad al
poseedor de la identidad. Si jugamos en un caso en el que nuestra
conexión a Internet sea también "asegurada" plenamente para que sólo
nosotros podamos acceder, ya está todo hecho y se puede hacer una
identificación unívoca del poseedor de esta identidad.

- Los datos enviados hacia la Certification Authority sobre nuestra
plataforma se conocen internamente como TCPA_IDENTITY_PROOF, con una
estructura basada en que se incluyan credenciales referentes a la
plataforma y a la TPM. Para hacer estos certificados, se utiliza un
sistema que actúa de modo que el identificador o número de serie
enviado no es único para cada sistema sino que varía respecto a la
versión y modelo utilizados. Aun así, la especificación de TCPA es
especialmente oscura en este punto, de modo que por un lado se nos
dice que se utiliza un identificador único para esta certificación,
y por otro se contradice indicando que estos números enviados en la
TCPA_IDENTITY_PROOF no son únicos.

Entre estos datos enviados, tenemos como destacables tres certificados
sobre nuestro sistema, que son:

* TPM Endorsement Credential (endorsementCred)
* TPM Platform Credential (platformCred)
* TPM Conformance Credential (conformanceCred)

Y en la estructura de la credencial de endorsement, ya se va a utilizar
y enviar una llave pública única a la plataforma (la TPM public
endorsement key), la cual puede identificar la TPM. Incluso, se
especifica que las credenciales Platform y Conformance se ignorarán
cuando se realice este tipo de comprobación, dado que la especificación
de TCPA da libertad en este aspecto al fabricante.[PC SPECIFIC, 5.3, METHOD OF VERIFICATION]


En definitiva, que la TPM puede ser identificada por la Certification
Authority al dar un certificado para una de las identidades nuesvas que
genere una TPM, aunque siendo esta una identidad no diréctamente
relacionada excepto por cifrado en la propia plataforma respecto a la
SRK, no identificaría de forma unívoca al usuario al identificarse; la
identificación sí es posible sin embargo por la CA, quien puede almacenar
la relación entre esta identidad y la TPM que la ha generado. En nuestro
día a día no habría una identificación directa (dado que la identidad
generada no se relaciona diréctamente), pero sí existe la posibilidad
de conocer a quién pertenece dado que la CA puede hacerlo.

-=-=-=[ 3.- Análisis de Palladium ]=-=-=-=-=

==[ 3.1.- Introducción a Palladium ]=======================

Mostradas las características de TCPA, pasamos a Palladium[22].

Comenzaba el artículo indicando que Microsoft se había adjudicado en
sus textos y comunicados de prensa características de TCPA como si
fueran propias en otra de las tantas jugadas de marketing de esta
empresa.

De hecho, si vemos los comunicados de prensa de Microsoft, las
"grandes ventajas" que describen sobre su sistema operativo que está
sin realizar son tan sólo características de TCPA, esto es, la
posibilidad de seguridad respecto a los propios archivos (mediante
el sistema llave pública/privada que TCPA incorpora y al que va
dedicado este artículo) y la búsqueda de confiabilidad de los
componentes hardware y software (también propios de TCPA).

Hay otras cosas que llaman realmente la atención, y que resultan
más que dudosas. Por ejemplo, que "el código confiable se ejecuta
en una memoria físicamente aislada, protegida e inaccesible al resto
del sistema, haciéndolo resistente de forma inherente a virus,
spyware u otros ataques software" refiriéndose al código de su
kernel. En TCPA no se ha hablado de que exista una memoria
físicamente aislada - una posibilidad es que Microsoft esté mintiendo
de nuevo -, otra es que el nuevo proyecto LaGrande de Intel (posible
implementación de TCPA) sea el punto en que se basa esta afirmación
(lo que de nuevo nos haría pensar que Microsoft se está apropiando
de características de otros para venderlas como suyas). Más preocupante,
es la posibilidad de que Intel y Microsoft se alíen de forma que
Microsoft e Intel comiencen con una fuerte ventaja - e interdependencia -
el juego de vender TCPA.



==[ 3.2.- Palladium a nivel kernel ]=========================

Básicamente a nivel kernel, que es la mejor forma de que sepamos de
lo que están hablando, Microsoft nos muestra dos componentes:

- TOR: Es el componente que, según MS, controlaría las llamadas a
sistema de los programas que funcionasen bajo Palladium y del
almacenamiento de datos críticos de los programas que funcionasen
bajo Palladium. Es quien protegería la zona de memoria donde reside
el kernel y los datos encriptados allí almacenados de información
del propio usuario. Es decir, este "Trusted Operating Root" (que
esto significan las iniciales) es sencillamente una parte de kernel
del sistema operativo.

- Trusted Agents: Programas que se ejecutan en modo usuario en lo
que MS llama el "espacio confiable" (trusted space). Utilizarían
funciones de la TOR para encriptar datos y almacenarlos en el kernel,
que sólo podrían ser obtenidos por esos mismos agentes; la
comprobación de integridad del componente (del trusted agent) se
llevaría a cabo con el "hashing" sobre la aplicación, de modo que
pudiera el TOR determinarla como aquella que guardó los datos; se
supone que esto afecta también a sistemas como el de manejo de
memoria y cualquier función crítica del sistema, es decir, que
una llamada a una API del kernel es producida por un Trusted Agent.

Hasta ahora he utilizado el lenguaje Microsoft para referirme a
esto. Ahora usaré lenguaje habitual: El TOR sería un kernel como
otro cualquiera, que evidentemente reside en memoria protegida
respecto a los procesos de usuario, pero no estaría separada de
forma física de la memoria normal, sino mediante una protección
software. Podría ser sin embargo que me equivocara, puesto que
el proyecto LaGrande de Intel habla de "memoria, almacenamiento
y ejecución" protegidos por hardware (poca más información
existe acerca de este proyecto, sobre el cual Intel es de
momento bastante oscura).

Acerca de los "Trusted Agents", son un montón de palabrería que
tan sólo quiere decir: "parte de un programa que al llamar a
una función de kernel, y que es hasheada desde el kernel para
indicar que no ha variado". Sigue siendo una estructuración de
su sistema operativo mediante paso de mensajes al viejo estilo
Minix del cual han derivado los Windows NT y similares, donde
habría cierto escalamiento de privilegios en las llamadas
de estos "Trusted Agents" a las funciones de kernel.

En fin, que Microsoft respecto a la seguridad no nos presenta
nada nuevo, y en Palladium seguirán habiendo virus; y cuando
alguien encuentre una vulnerabilidad y ponga el procesador en
ring0, será tan ring0 como con cualquiera de los que hay ahora
y de poco valdrá el TOR. El resto de referencias a la seguridad
en este sistema operativo, no es más que el decir que evidentemente
los procesos de espacio usuario no podrán acceder al TOR
porque está en memoria protegida ni a los datos que guarda
porque también residen allí y sólo puede sacarlos descifrados
una entidad certificada que poseería su propio espacio de
"datos introducidos" en el TOR. Vamos, que no hablan más
que de que va a haber una memoria de kernel y una memoria
de usuario y que desde la de usuario no va a poder accederse
a la de kernel, siendo este kernel y su "micronúcleo de
seguridad", el TOR, quien guarda la llave de los datos
privados del usuario. Lo más sorprendente se encuentra en el
"abstract" de la charla dada en el MIT por Microsoft, en la
que se dice que la "curtained memory", es decir, su método
de protección entre procesos, "impediría acceder a las páginas
de memoria principal de otras aplicaciones de modo que una
aplicación estaría segura de que no está siendo observada
por otra aplicación e incluso por el sistema operativo". Es
decir, que pretenden extender la protección entre procesos
de modo que ni siquiera el superusuario vaya a poder
controlar lo que está sucediendo en su sistema. Esto,
permitiría también que el propietario de un ordenador
no pudiera capturar video, audio o datos que esté reproduciendo.

En fin, que aparte de que vayan a utilizar el chip TCPA
para el hash que compruebe las aplicaciones que llaman
diréctamente a funciones de kernel y de que se guarde en
memoria de kernel para mayor seguridad los datos privados
del usuario que este quiera introducir y tal (que
evidentemente con acceso al kernel podrían ser igualmente
desvelados), Palladium no aporta nada demasiado nuevo por
sí mismo.

Esto, es la escasa innovación que Microsoft quiere ofrecer en
Palladium a nivel de seguridad, pero que vende como panacea.
Sin embargo, ahora viene la contrapartida, lo importante, y
es que lo poquito que ofrecen en seguridad no es más que
una excusa para obviar lo que pretenden destruir en privacidad.


==[ 3.3.- Los "TOR" externos ]============================

Con el objetivo de dar una en mi opinión "falsa seguridad" al
usuario, Palladium pretende utilizar TORs externos; esto es,
que habrían entidades externas a nuestro PC a las que podríamos
confiar el que autenticasen partes del sistema operativo para
asegurar que no habrían sido modificadas; se llevarían datos
del sistema operativo, hashearían estos datos y nos darían una
respuesta acerca de su integridad.

Ante esto hay dos posibilidades; una sería el que sólo una parte
muy específica pudiera ser enviada a todos ellos, lo cual podría
asegurarse si el código Microsoft fuera abierto en este sentido -
lo cual dudo mucho. Por otro lado, la siguiente opción consiste
en que la propia organización decida qué datos le son enviados;
es decir, que estaríamos mandando datos alojados en nuestro
ordenador sin saber exáctamente qué estamos mandando para que
estas entidades externas decidieran, para que ellas nos dieran
esta "seguridad distribuída".

Esto no se detiene aquí, pues no es el objetivo de Microsoft el
dar más seguridad al usuario sino aparentarlo; la verdadera
importancia de los "TOR" externos reside en lo que se ha
comentado como la parte realmente terrible de este sistema
operativo que podría dar lugar a cuentos como aquel del derecho
a leer de Richard Stallman. Aquí, es donde entra la aplicación
en Palladium del "DRM" o Digital Rights Management.


==[ 3.4.- Digital Rights Management ]=======================

Aquí llegamos a un sistema distinto que es el conocido como
"DRM", Digital Rights Management, que también pertenece a
Microsoft y que consiste en una serie de protocolos para que
un usuario sólo pueda ver una película, leer un libro, escuchar
una canción o leer un email si se autentica de forma correcta,
pudiendo establecerse límites de tiempo para que esto pueda ser
un "alquiler temporal", etcétera; es decir, un sistema cuyo objetivo
principal es el de la defensa de los sistemas de copyright. Sin embargo,
DRM no se queda aquí sino que también incluye protocolos para la
monitorización de los accesos al toda "propiedad intelectual" como
diréctamente la llaman.

De hecho, el propio DRM destaca que sus dos objetivos son, por un
lado el manejo de los permisos de reproducción de cualquier cosa
que implique propiedad electrónica, y por otro la gestión de la
monitorización de los usos que se hagan de esta propiedad (aunque
sean legítimos). Es decir, ellos mismos nos explican que en este
sistema la parte de "tracking" o monitorización se encargaría de
ver cuantas veces y cuando estamos reproduciendo un video para
el que tenemos permiso de reproducción durante 10 veces. Otro
ejemplo que Microsoft propone también es el de las "preview" y
versiones gratuítas, esto es, que por ejemplo también se
controlan y monitorizan las versiones gratuítas y previews con
ejemplos como el dejar leer las 15 primeras páginas de un libro
o ver los 5 primeros minutos de una película (reproducciones que
también serían registradas).

El ejemplo lo tenemos en el funcionamiento actual del Windows
Media Player, donde esta tecnología quiere empezar a ser funcional
aún sin Palladium; los ficheros están encriptados y Microsoft
es quien tiene la llave que puede abrirlos, con lo que el usuario
ha de solicitar la licencia, pagar, y entonces esta licencia
determina aspectos como cuantas veces puede reproducirse el
vídeo o de qué fecha a qué fecha.

La idea de Microsoft es que mientras que los protocolos DRM
se basan normalmente en llaves software, con Palladium podrían
reforzar este sistema de modo que al expedir licencias puedan
actuar como un TOR externo; aunque esto no está especificado con
exactitud es sencillo saber cómo sucedería esto, veamos un
ejemplo:

- Pepe solicita una película, así pues Pepe mediante su flamante
Palladium envía la llave pública que está almacenada en su TPM
junto con su solicitud (que estaría encriptada también en RSA al
contener sus datos bancarios), de modo que pueda reproducir
durante un día la película; su compra queda registrada en el
servidor que la empresa que distribuye el vídeo dedica al
Palladium Media Player, que manejará los derechos de autor
y transferirá la parte que corresponda a sus propietarios.

- Ahora Pepe quiere reproducir el vídeo que ha comprado. Por
lo tanto al ejecutar su Palladium Media Player, este tiene
dos opciones:

A) Busca la licencia que el TOR ha metido en la memoria de
kernel del SO (me pregunto cuanto ocupará el kernel de Palladium
tras un tiempo usándolo) y comprueba si le está permitido
reproducir este archivo, si no ha llegado a su límite de
tiempo o de veces que puede ser reproducido, etcétera.

B) Casi peor, el Palladium Media Player, dado que extiende
su confianza a TORs externos, se conecta con el lugar donde
lo ha comprado y dice que quiere visionarlo; la licencia es
comprobada allí y si es correcta se envía una llave al
Palladium Media Player que borrará una vez se haya acabado
de ver el vídeo, para desencriptarlo. El servidor que
contiene la licencia, por tanto, sabe cada vez que Pepe
intentó ver su película y si tenía o no la licencia en
órden (y quien dice películas dice libros o música).

Por tanto, no sólo está el tema de que Palladium pretenda dar
mayor seguridad como único objetivo al tema de la propiedad
intelectual (dado que los propósitos respecto al sistema
operativo son bastante mediocres), sino que se nos presentan
el gran problema de la brecha de privacidad que todo esto
va a implicar; tal y como ahora el usuario standard de Windows
utiliza Outlook e Internet Explorer porque vienen instalados
por defecto, el futuro usuario de Palladium se acogería a un
Palladium Media Player, a un reproductor de música o a programas
para leer documentos (como Word) standarizados y distribuídos con
el propio sistema operativo. Es decir, que si yo me voy a Amazon
y descargo una copia de un determinado libro que sólo me deje
leer 10 páginas, Amazon va a registrar que miré 10 páginas de ese
libro en particular (esto me hace preguntarme también si en el
futuro las bibliotecas públicas desaparecerán; ¿te alquilarán
un libro durante dos semanas y después no te dejarán hacerlo
otra vez?).

-=-=-=[ 4.- Conclusiones ]=-=-=-=-=-=-=-=

Entrando en consideraciones personales - aunque ya espero que el lector
haya formado la suya propia -, podría dar la impresión de que TCPA es
casi-inocente y de que el terrible es Palladium; TCPA en sí no está
diseñado para ningún sistema operativo en particular, es un standard
abierto, y no emite certificaciones para "aprobar como TCPA" dispositivos
de ninguna clase.

Tiene sin embargo TCPA la oculta y terrible cara de que presupone que
se ha de confiar en las Certification Authorities, que expedirían
certificados con los cuales dar salida a nuevas identidades no
únicas; con el problema de que estas CA pueden identificar a quien
ha realizado tal petición y finalmente hacer una relación indirecta
pero plausible entre las acciones de un usuario y su identidad de forma
unívoca.

Ese es probablemente el punto más negro en TCPA - ellos aseguran la
"necesidad" de estas certificaciones -, el que se supone que hay que
confiar en estas autoridades certificadoras que sí saben perféctamente
quienes somos, pero que llevadas por malas manos - y todos sabemos lo
sencillo que es eso - pueden llevar a terribles consecuencias. La lucha
contra TCPA en caso de que quieran seriamente seguir con este sistema
adelante, ha de ser contra las Certification Authorities. Las acciones
que puedan realizarse para luchar contra ello en caso de que se
impusiera, tendrían como punto interesante la creación de CAs autónomas
que rompieran el hilo de relación entre el usuario y su identificación
(aunque aun así tenemos el grave problema de que probablemente, una
aplicación por ejemplo de Microsoft requiriera un certificado que
únicamente fuera expedido por Microsoft, lo cual identificaría a sus
usuarios unívocamente ante él, impidiendo esta forma de "desobediencia"
ante las CAs). La única salida estaría en sistemas de código abierto
que se certificaran ante entidades que a su vez destruyeran toda
relación entre el usuario y su identificador.

¿Qué significa esto? Mi visión personal, es que el que no vayamos a
identificarnos de forma unívoca ante todo aquello que veamos (por
ejemplo, mientras navegamos), no sirve para salvaguardar nuestra
privacidad; precisamente, esa identificación que se quiere evitar
se produce sólo ante las Certification Authorities. Es decir, que
nos pueden identificar, pero "sólo unos pocos".

Más grave es aún el problema del SO Palladium, dado que es
bastante probable que la mayoría de las plataformas en caso de que
TCPA se extendiera, usaran el sistema operativo de Microsoft. Incluso,
si de hecho tal y como se dice en Intel, se trata de una "tecnología
de base de la que podrán aprovecharse cosas como el Palladium de
Microsoft para producir plataformas más estables", podríamos tener
una fortísima relación entre Intel y Microsoft.

Tendríamos entonces escenarios tan terribles como el uso indiscriminado
del DRM como ya ha sido explicado anteriormente y en los FAQs sobre
Palladium, e incluso el uso - en particular en sistemas operativos
programados bajo código propietario y por tanto inanalizable por el
usuario final - como el uso de protocolos en aplicaciones standard
que identificaran de forma unívoca al cliente. Esto es, podría hacerse
que para una determinada aplicación al enviarse un mensaje al servidor,
un campo de este mensaje fuera un hash del resto del mensaje, encriptado
mediante la llave de identificación; por un lado autenticaría al emisor,
por otro identificaría de forma unívoca sus acciones si se cuadrase
con los certificados emitidos por la CA, o por otros métodos que el
código cerrado de Palladium determinase.

-=-=-=[ 5.- Notas al pie ]=-=-=-=-=-=-=-=-

[1].- Gráfico: "TCPA PC Specific Specification", página 8

[2].- Una definición clara de la CRTM puede encontrarse en la "TCPA
PC Specific Specification", sección 1.3.4. La parte de responsabilidad
del fabricante puede encontrarse aquí.

[3].- Especificación de los pasos a seguir por una CRTM para evaluar
su estado y el de los siguientes componentes: "TCPA PC Specific
Specification", sección 2.2. Pueden encontrarse más detalles en la
sección 6.1 de esa misma especificación.

[4].- Las formas de asegurar una TPM a una plataforma son detalladas
en la "TCPA PC Specific Specification", sección 1.3.6.1.2

[5].- Puede encontrarse un listado de contenidos de la TPM en la
"TCPA Main Specification", sección 2.2.2.

[6].- Esta operación está detallada en la "TCPA PC Specific
Specification", sección 2.3.1 (Storage of Integrity Metrics)

[7].- La seguridad en la transmisión de datos de la TPM se encuentra
en la "TCPA Main Specification", sección 2.3.2 (Reporting of Integrity
Metrics".

[8].- Las operaciones criptográficas realizadas por la TPM se
encuentran en la "TCPA Main Specification", sección 2.5 (Cryptographic
Operations)

[9].- Las combinaciones y caminos para activar/desactivar una TPM
y su proceso de "ownership", se detallan en la "TCPA Main
Specification", sección 2.6.3 (Selected Operations)

[10].- Una nota (incompleta) sobre estos ataques puede encontrarse en
la sección 10.17 de la "TCPA Main Specification". La posibilidad de
ataques denial of service remotos se detalla en la sección 2.6.2
(Activating a TPM) de la misma especificación, donde se detallan los
métodos de desactivación.

[11].- El almacenamiento de estos logs se detalla en la "TCPA PC
Specific Specification", sección 7.2 (Measurement Event Log).

[12].- La estructura ACPI para TCPA es detallada en la "TCPA PC
Specific Specification", sección 7.1 (ACPI Table Usage). Se puede
encontrar una especificación detallada sobre las tablas standard
de ACPI en la "Advanced Configuration and Power Interface
Specification", sección 5.2 (ACPI System Description
Tables)

[13].- El formato del struct que guarda los logs puede encontrarse
en la "TCPA PC Specific Specification", sección 7.2.2.1 (Platform
Specific Event Log Structure). También hay una descripción de los
tipos de evento en la misma especificación, sección 7.2.3 (EV_ACTION
Event Types)

[14].- Puede encontrarse una descripción completa de la función 0e820h
(int15h) en http://www.uruk.org/orig-grub/mem64mb.html

[15].- Los registros PCR se detallan en la "TCPA PC Specific
Specification", sección 2.2 (PCR Usage). Se puede encontrar más
información sobre los PCRs 4 y 5 (relacionados con el IPL) en las
secciones 6.2.1 y 6.2.2 de la misma especificación.

[16].- Este proceso es explicado en la "TCPA PC Specific Specification",
sección 6.1 (Architecture and Definitions).

[17].- Más información en la "TCPA PC Specific Specification", sección
8.1 (Application Level Interface).

[18].- El MPDriver se detalla en la "TCPA PC Specific Specification",
sección 8.2.2 (Memory Present Driver).

[19].- Puede encontrarse más información en la "TCPA Main Specification",
sección 7 (Protected Storage)

[20].- El proceso de creación de una identidad se detalle en la "TCPA
Main Specification", sección 9.3 (Generating a Trusted Platform Module
Identity).

[21].- Se sugieren acciones a seguir por parte de la Certification
Authority en la "TCPA Main Specification", sección 9.3.3 (Contacting a
Privacy CA). El flujo de datos se detalla en la misma especificación
sección 9.4 (Instantiation of Data When Contacting a Privacy CA).

[22].- Toda la información acerca de Palladium puede encontrarse en
la sección de Bibliografía: la más interesante es la "Business
Overview" sobre Palladium. Microsoft no ha sacado especificaciones
o documentos técnicos sobre este SO.

-=-=-=[ 6.- Apendices ]=-=-=-=-=-=-=-=-=-

En esta sección encontramos algunas de las páginas web con más
información sobre TCPA y Palladium, tanto oficiales como no-oficiales,
habiendo en ambos casos que aplicar un criterio a la hora de analizar
sus palabras.

==[ Apéndice: Bibliografía ]============

Los materiales utilizados para la realización de este artículo pueden
encontrarse en las siguientes direcciones:

Standards TCPA
http://www.trustedpc.org

Standard ACPI
http://www.acpi.info/index.html

TCPA/Palladium FAQ by Ross Anderson
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

Charla de Paul Otellini mencionando LaGrande
http://www.intel.com/pressroom/archive/speeches/otellini20020909.htm


Y las más divertidas (es interesante eschar un ojo; sus notas a la
prensa, el FAQ y el Business Overview son contradictorios a menudo;
Microsoft se niega a dar más información acerca del sistema cerrado
Palladium, y mientras que en ocasiones actúan como si se fueran a
convertir también en fabricantes de hardware, otras sí reconocen
que realmente es la implementación TCPA, aunque esto suele ocultarse
por aquello de que TCPA suene a algo más grande. Otra de las cosas
que se me ocurren es que Microsoft quiere hacer su versión propietaria
de TCPA tal y como sugieren sus últimas modificaciones en el FAQ...
pero eso a lo que llevaría es a la mayor lucha entre compañías
relacionadas con la informática que jamás se ha visto).

A Business Overview (technical)
http://www.microsoft.com/PressPass/features/2002/jul02/0724palladiumwp.asp

Abstracto de la charla dada por Microsoft en el MIT
http://www.cryptome.org/palladium-mit.htm

Una nota de prensa divertida sobre Palladium
http://www.microsoft.com/presspass/Features/2002/Jul02/07-01palladium.asp

Palladium FAQ
http://www.microsoft.com/technet/security/news/PallFAQ2.asp?frame=true#g

-=-=[ 7.- Apéndice B: Agradecimientos ]=-=-

A los lectores de Kuro5hin, en particular a Randall Burns, quien
reescribió la intruducción en inglés :)


==[ copyleft (l), 2002 by wintermute. All rights reversed ]========

- Libertades Civiles -