Técnicas de protección de software basadas en hardware (página 2)

2 Técnicas de
protección basadas en hardware

En los últimos años, ante el incremento de la
piratería de software, ha surgido una gran variedad en
cuanto a los métodos que tratan de
reducir al mínimo este problema. Dicha variedad va desde la
combinación de métodos existentes hasta la
creación de nuevas e interesantes soluciones, todas con el
objetivo de buscar una
solución que sea lo menos vulnerable posible.

Además existe otro denominador común entre los
métodos, y es que se ha logrado identificar que la
solución deseada está en el campo de las protecciones
basadas en hardware. Esto se debe a que sus predecesores y no
olvidados métodos basados en software, son vulnerables a los
ataques; debido, en gran medida, al hecho de que son ejecutados
en ambientes inseguros (arquitecturas actuales de las computadoras personales). Se
dice que estas arquitecturas son inseguras porque un atacante
potencial, utilizando herramientas de
depuración, puede llevar a cabo un análisis de las
instrucciones que ejecuta el microprocesador, así como de
los datos escritos y leídos
desde y hacia la memoria; y de esta manera
determinar cómo está protegida la aplicación.
Dando como resultado la violación de las protecciones. Por
lo que con las nuevas soluciones se trata de buscar un entorno
seguro, donde sean ejecutadas
la aplicaciones, porqué no, con algún método basado en software.
Entorno seguro que se caracteriza principalmente por no estar
incluido dentro de la arquitectura original de la
computadora y por permitir, en
ocasiones, la ejecución de código sin tener la
preocupación que pueda ser analizado utilizando alguna
herramienta de depuración. [10-12, 14-16]

Debido a la gran variedad de soluciones (comerciales o
en proceso de investigación) y la gran
variedad de mecanismos usados en cada una de ellas, establecer
una categorización formal de estas sería muy engorroso.
Aunque, con el objetivo de hacer de forma más ordenada su
descripción serán
divididas en las que basan su funcionamiento en el método de
pregunta/respuesta y en las que ejecutan piezas de código
dentro del dispositivo de hardware.

En la técnica de pregunta/respuesta la
aplicación es ejecutada en la computadora y realiza
chequeos periódicos al hardware, este método es el que
usan algunas soluciones comerciales con las llamadas "Llaves de
Hardware", "Hardware Token" o simplemente "Dongle". Producto de vulnerabilidades
de esta técnica, es que surgen las técnicas que
ejecutan piezas de software pertenecientes a la aplicación
dentro de la arquitectura de hardware, siendo estas de corte
más investigativo y menos comercial.

2.1 Método pregunta/respuesta

Existen diversos procedimientos para llevar a cabo
la protección de software mediante este método. El
funcionamiento general del método consiste en que la
aplicación haga algún tipo de consulta al dispositivo y
en dependencia del resultado de esta, la aplicación
seguirá o no su funcionamiento.

El procedimiento más sencillo
consiste sólo en chequear que el dispositivo está
conectado a la computadora. Lo sencillo de esta solución
posibilita que un atacante pueda violar fácilmente el
mecanismo de protección con sólo acceder al código
de la aplicación y quitar o ignorar la comprobación
[17].

Con el propósito de contrarrestar la deficiencia
anterior, los desarrolladores han incluido la utilización de
criptografía en sus
soluciones [10, 18]. En este caso el método para llevar a
cabo esta variante es que el desarrollador cifre el código
de la aplicación, donde la clave para poder descifrarlo se encuentra
almacenada de forma segura dentro del dongle. De esta forma, en
el momento en que se vaya a ejecutar el programa, se invoca un componente
de software que es el encargado de comunicarse con el dongle y
obtener la clave, luego se procede a descifrar el código de
la aplicación y por último se ejecuta [17]. Esta
variante a pesar de incluir elementos criptográficos no da
solución al problema de la copia de software; ya que, una
vez que el código descifrado se encuentre en la memoria de la computadora puede
ser copiado por el atacante y generar una nueva aplicación
con el código descifrado.

Existen otras variantes de solución, a partir de la
utilización de la criptografía, que intentan elevar la
seguridad aunque con resultados
discretos. Por ejemplo se podría dividir la aplicación
en pequeñas piezas, cada una cifrada con una clave
diferente, en este caso el dispositivo actuaría como
repositorio seguro de las claves; de esta forma en la memoria
sólo existirá, descifrada, la porción de
código que se está ejecutando y el resto se
descifraría en el momento de su ejecución solicitando
la clave correspondiente al repositorio [17].

En la actualidad las principales soluciones emplean el
dispositivo de hardware complementado con un mecanismo de
protección basado en software, con el fin de disminuir las
vulnerabilidades; a pesar que estos mecanismos se ejecutan dentro
de las fronteras de la computadora y no dentro del dispositivo de
hardware. Desde el punto de vista del dispositivo de hardware,
este es usado como motor criptográfico que
utiliza generalmente, como algoritmo, el AES2 [10,
18-20]. Dicho motor es utilizado para establecer un canal de
comunicación seguro entre la
aplicación y el dongle, se puede decir que entre las
bondades que brinda el algoritmo se encuentra la rapidez de su
ejecución, no siendo así con un algoritmo de clave
pública como el RSA; por otra parte desde el punto de vista
de fortaleza es superior también, siempre y cuando la clave
se mantenga como un secreto. Este último requisito es
bastante difícil de lograr del lado de la aplicación,
producto de que la clave se almacenaría dentro de la
computadora, pudiendo ser recuperada por un atacante.
También este dispositivo de hardware es usado
implícitamente como dispositivo externo de almacenamiento seguro,
independiente de la computadora, permite almacenar licencias,
contraseñas e información necesaria para
la aplicación en memoria protegida, ya sea de lectura/escritura o ROM
[21].

En lo relacionado con los mecanismos de protección
basados en software existen dos variantes que para nada son
excluyentes, al contrario de utilizar ambas la aplicación
ganaría en seguridad. La primera forma consiste en la
utilización de un conjunto de bibliotecas que se enlazan con la
aplicación, esto implica que el desarrollador debe conocer
que mecanismo de seguridad quiere o necesita aplicar, e
introducir en el código fuente las llamadas a las funciones presentes en la
biblioteca.

El segundo mecanismo es denominado "Envoltura"
(Envelope), que no es más que una herramienta de
protección automática desplegada en el fichero que se
desea proteger, pudiendo ser este de tipo ejecutable o no. En
este método no es necesario tener conocimiento del código
fuente de la aplicación, ya que esta "Envoltura" se adiciona
al fichero como tal y no al código fuente [ref alddin y
safenet]. Una posible vulnerabilidad en este mecanismo de
"Envoltura", consiste en la unión entre el fichero de la
aplicación y el código de protección adicionado.
Esto viene dado porque una vez que sea anulado se perderá el
vínculo entre la llave de hardware y la aplicación,
pudiendo ocurrir que la aplicación sea ejecutada sin
necesidad que esté presente el dispositivo. En la figura 1
se muestra la ubicación de la
"Envoltura" con respecto al fichero de la
aplicación.

Con el objetivo de asegurar la permanencia de la
envoltura se pueden encontrar implementaciones de diversos
mecanismos, tales como [10, 18-20]:

– Dividir el código de protección en
diferentes capas, organizadas cada una de forma aleatoria en
cada sesión de protección. Esto garantiza que para un
mismo fichero la cantidad de capas y la disposición de
estas sea distinta. Además de esto, las capas son cifradas
de forma diferente y cada una de ella es la encargada, durante
la ejecución de la aplicación, de descifrar la
próxima en la secuencia usando una clave aleatoria. Ver
Figura 1.

– El código en cada capa es ofuscado insertando
código "tonto" entre las instrucciones válidas para
impedir la aplicación de técnicas de ingeniería
inversa.

– Utilización de mecanismos de detección de
depuración, que están basados en el hecho de que el
sistema operativo y un
depurador ejecutan aplicaciones de forma diferente. Estos
mecanismos están constantemente a la espera de depuradores
activos, cuando es
encontrado uno activo envía comandos confusos y basura para desviar la
atención del depurador.
El resultado de la aplicación de este mecanismo es que los
depuradores activos son descubiertos y manipulados por la
Envoltura.

Fig. 1. Ubicación de la
"Envoltura" con respecto al fichero de la
aplicación.

Hay que destacar que también son usados mecanismos
de protección de memoria para lectura y escritura, lo que
implica que la aplicación externa sólo puede acceder a
la zona de memoria que le corresponde; de esta manera podrá
existir una zona que sea nada más para uso exclusivo del
dispositivo.

Lo expresado anteriormente no constituye un patrón
a usar de forma obligatoria. De hecho existen soluciones
comerciales en la actualidad que sólo implementan ciertos y
determinados mecanismos. Como es lógico pensar la cantidad
de mecanismos implementados podría ser directamente
proporcional a la seguridad que gana la aplicación. A pesar
de que esto pueda ser cierto no se puede dejar atrás el tema
del rendimiento, ya que se corre el riesgo de afectar
considerablemente el mismo si se hace un uso indiscriminado de
estos mecanismos de protección.

Como se puede apreciar existe una gran diversidad en las
soluciones dadas al método de pregunta/respuesta, todas
enfocadas a mejorar mucho más la seguridad de la
aplicación; desafortunadamente, podría decirse que, el
principal inconveniente que tiene este método es que, si un
atacante analizaría las vulnerabilidades podría simular
el dispositivo de hardware y de esta forma no sería
necesario la presencia del dispositivo físico. Este tema
podrá ser visto con mayor detalle en la Sección
3.

2.2 Ejecución de componentes de software dentro
del dispositivo de hardware

Si se dotara al dispositivo de hardware con un motor
criptográfico, además de la clave de cifrado, entonces
este podría recibir los bloques de código cifrado,
descifrarlos y devolverlos en este estado para que el
microprocesador de la computadora pueda ejecutar las
instrucciones. Esta podría ser una solución al problema
de exponer las claves de cifrado a un ambiente hostil, aunque si se
expondría al código en texto claro a este ambiente.
Al hacer esto el atacante en lugar de capturar las claves y
emular el dongle, tendría que obtener de la memoria los
fragmentos de código [17]. Esta variante de solución
podría ser, la menos segura con respecto a las variantes que
serán analizadas dentro de este método.

Una solución posiblemente más eficaz
podría ser que dentro del dispositivo se continúen
almacenando además de las claves, porciones de código
que se encuentren cifradas y que estén involucradas en
alguna lógica de negocio
importante para la aplicación. De esta forma el atacante
tendría que saber que funcionalidad está implementada
para poder emular el dispositivo. Un posible inconveniente puede
ser la capacidad de almacenamiento [17], aunque en la actualidad
esto no constituye un freno.

Con el propósito de describir con un mayor grado de
detalle este método a continuación se describirá
cada variante de solución.

Utilización de coprocesadores seguros como variante de
solución

En [13, 22] se describe el desarrollo de un dispositivo
de hardware para lograr establecer un ambiente seguro y así
poder ejecutar las aplicaciones fuera de los ambientes
tradicionales. Vale aclarar que este trabajo cubre casi todas las
aristas tanto del problema a resolver así como para obtener
la solución más segura posible.

Como se expresó en el inicio de este acápite,
este trabajo está relacionado con la ejecución de
código en un ambiente seguro; pero se puede decir que esta
ejecución es complementada con diversas tecnologías de
protección del hardware propiamente dicho.

De manera general la tecnología propuesta en este
método consiste en una arquitectura de hardware que maximiza
la potencia computacional, está
basada en un CPU y en aceleradores
criptográficos (CPU 486 a 66 MHz y aceleradores para el
algoritmo DES, matemática modular (por lo
tanto permite RSA y DSA) y un generador de números
aleatorios). Además incluye una memoria RAM dinámica (DRAM) y en
menor medida una memoria RAM respaldada por batería
(BBRAM), esta última será usada como memoria segura no
volátil. Todo esto es ensamblado en un circuito con
tecnología que permite censar activamente intentos de
manoseo y cuando ocurra esto limpiar de forma instantánea
los secretos contenidos en la BBRAM. Esta arquitectura se muestra
en la figura 2.

Fig. 2. Arquitectura de hardware
propuesta

Como puede verse en esta figura, la arquitectura
está diseñada para una tarjeta PCI, aunque los autores
expresan que este diseño puede ser
utilizado con otro tipo de tecnología más
pequeña.

Por otra parte proponen una arquitectura de software de
varias capas, donde en la capa inicial incluyen un programa que
se encargará de administrar la seguridad y la
configuración; parte de este programa reside en la ROM y
parte en la memoria FLASH. Más arriba está
presente un sistema operativo para la administración de
recursos computacionales, tanto
de almacenamiento como criptográficos y por último la
capa de aplicación. Vale aclarar en este punto que todas
estas aplicaciones no necesariamente tienen que provenir del
mismo fabricante. La disposición anterior puede verse en la
siguiente figura.

Fig. 3. Arquitectura de software
propuesta.

La solución presentada cumple con diversos
requisitos agrupados en dos categorías: de seguridad y
comerciales. Dentro de estas categorías se pueden resaltar
los requisitos relacionados con la actualización de las
aplicaciones que se encuentran dentro del dispositivo, así
como de la ejecución segura y autenticada de estas
aplicaciones.

Para cumplir con los requisitos, se emplearon diversas
técnicas relacionadas con la protección de los secretos
presentes dentro de la memoria del dispositivo; figura 4. A
continuación se expondrán brevemente los métodos y
técnicas utilizadas en cada grupo.

Dentro del grupo de Protección de secretos se
utilizaron las siguientes:

– Eliminar los secretos que se encuentran almacenados
en la memoria utilizando una combinación de
circuitería y protocolos para detectar
cuando son manipulados los datos. Destacar que esta
técnica se aplica utilizando métodos de
detección y respuesta de y ante manipulación. El
primer método tiene como elemento básico una red de conductores monitoreados por
circuitos que detectan
cualquier variación en las propiedades de los conductores;
variaciones estas que son resultado del intento del atacante de
violar esta protección. El segundo método se basa en
limpiar la memoria BBRAM cuando es detectado un intento de
manipulación. Decir además que toda la
circuitería relacionada con estos métodos está
activa en todo momento, aunque el coprocesador no esté
energizado, gracias a que es usada la misma batería que
mantiene la BBRAM. Por otra parte son incluidos un conjunto de
sensores para prevenir ataques
basados en la manipulación de las condiciones de
operación. Por ejemplo temperatura, voltaje,
señales de
reloj.

Fig. 4. Técnicas empleadas para
llevar a cabo la protección de secretos dentro del
dispositivo.

– Protocolos para la inicialización,
regeneración y recertificación. Mediante estos
protocolos se garantiza el establecimiento de los secretos
desde el primer momento, momento este en que se puede decir que
el dispositivo es real y no ha sufrido ninguna
modificación. Esto es posible afirmarlo con un cierto
grado de certeza ya que la inicialización es hecha como un
paso más del proceso de fabricación.

Es aquí donde son generadas dos claves que
servirán para autenticar el dispositivo. En este proceso
interviene el generador de números aleatorios que trae
incorporado la arquitectura, el cual es el encargado de generar
la semilla que se utilizará para fabricar las claves.
Luego ambas llaves son almacenadas en la BBRAM, mientras que la
clave pública es además exportada a una Autoridad de
Certificación (AC), la cual se encargará de generar
un certificado que será almacenado también en el
dispositivo.

Por otra parte el dispositivo tiene la habilidad de
generar un nuevo par de llaves, de forma tal que el dispositivo
no esté atado por siempre a las llaves que fueron
generadas en un principio. Este proceso tiene la ventaja de
ejecutarse de forma atómica, o sea, que siempre
ocurrirá a pesar que exista una falla o interrupción.
De la misma forma la AC tiene la posibilidad también de
emitir un nuevo certificado para el dispositivo o hacer
válido el certificado de transición generado por el
dispositivo.

– Defensa ante ataques de software, con esto se
logrará que ante alguna vulnerabilidad de algunas de las
aplicaciones que son ejecutadas dentro del dispositivo se
logren aislar los secretos, de forma tal que no se comprometa
nada; por ejemplo de existir una falla en el OS cualquier
aplicación podría lograr privilegios no otorgados y
así acceder a los secretos dentro del dispositivo. Para
darle solución a este problema utilizan los cerrojos de
hardware o hardware locks.

Los hardware locks son una circuitería
independiente que restringe las actividades del código que
se está ejecutando en el CPU. Este circuito
interactúa con el CPU a la vez que controla el acceso a la
memoria FLASH y a la BBRAM. Además existe otro problema,
relacionado este con la identificación por parte del
circuito entre un código bueno y uno malo. Para esto la
solución se basa en la ejecución de bloques de
código los cuales tienen determinada confiabilidad, de
forma tal que al pasar de un bloque a otro aumenta el nivel de
seguridad y disminuyen los privilegios (Figura 5). A medida que
va creciendo el nivel de seguridad se hace imposible
disminuirlo, o lo que es lo mismo ganar privilegios en el
sistema. En el caso que se detecte una dirección de memoria no
válida, el mecanismo obliga al CPU del dispositivo a
comenzar la ejecución desde una dirección en la ROM
conocida y segura y a partir de un código
permanente.

Fig. 5. Mecanismo de
protección para evitar ataques de software

Por otra parte las técnicas de protección del
código están dirigidas a garantizar la integridad de
este y a llevar a cabo un proceso de carga y actualización
seguro. Para lograr esto, al igual que con el grupo anterior,
diseñaron un conjunto de métodos. Desde el punto de
vista criptográfico, el Miniboot 1, que se encuentra en la
FLASH, contiene el código para soportar criptografía de
clave pública y funciones de hash y es el encargado de
llevar a cabo la instalación del código primario y
actualizar las tareas. Además el Miniboot 0, que se
encuentra en la ROM, contiene las primitivas para ejecutar el DES
usando el soporte de hardware. Otros de los mecanismos empleados
tiene que ver con la salva de información cuando se ejecuta
un proceso de borrado de una capa de código para volver a
escribir en ella; si en ese momento ocurre cualquier falla y no
se tiene salvado el estado anterior, se corre
el riesgo de que queden borrados datos de importancia para la
ejecución segura del dispositivo. Se tienen presente
además errores que pueden ocurrir de forma aleatoria en el
hardware, o sea que los bits en la memoria FLASH pueden cambiar
sin ser vueltos a escribir de forma normal. Para esto le asocian
un MAC a cada capa de código, este MAC está basado en
el DES de 64 bits, de forma tal que antes de transferir el
control a una capa la anterior la
chequee.

Por último para llevar a cabo un proceso de carga y
actualización de código seguro, en la solución se
concibieron mecanismos internos, de forma tal que la tarjeta
pueda:

– Determinar cual es la autoridad encargada de
instalar y cambiar el código.

– Cómo autenticar a dicha autoridad.

– Cómo una tarjeta, aparentemente vacía, en
un ambiente hostil puede conocer quién está a cargo
de sus capas de código.

– Cómo la autoridad apropiada puede autorizar la
instalación y actualización de código

Rockey6 Smart de Feitian

Esta solución se describe en [11, 23-25], la misma
utiliza, para proteger las aplicaciones, la combinación de
dos tecnologías conocidas, una de ellas es el conjunto de
tecnologías básicas empleadas por el resto de los
dongles (entre ellas se puede decir que está una variante
del método pregunta/respuesta) y por otra parte utiliza las
tecnologías de las smart cards. Su estructura interna está
compuesta por un controlador de entrada/salida, un sistema
operativo específico para el dispositivo, una memoria EEPROM
y una RAM y el procesador de 32 bits. Ver figura
2. [11, 23-25]

Para el intercambio de mensajes con la aplicación
utiliza algoritmos de cifrado
simétrico y asimétrico. Como algoritmo simétrico
tiene embebido el DES de 8 bytes y 3DES de 16 bytes y como
algoritmo asimétrico soporta el RSA con longitudes de claves
de 512 y 1024 bits. Para ejecutar el cifrado y/o descifrado
simétrico, es necesario que las llaves estén en un
fichero dentro del dongle. En el momento de crear este fichero de
claves, cada llave se escribe utilizando un formato
específico; esto es, el primer byte es el identificador de
la clave, el segundo es la longitud de la clave (8 bytes para DES
y 16 para 3DES) y por último se encuentra la clave como tal.
En el caso del cifrado asimétrico, con RSA, antes de
ejecutarlo es necesario generar el par de claves
primero.

En el dongle pueden ser almacenados ficheros ejecutables
y de datos. Los primeros son los que se descargan en el dongle y
son ejecutados por el sistema operativo del dispositivo. Para los
segundos establece dos subtipos, ficheros normales e internos;
los normales pueden ser accedidos desde la aplicación
externa a través de las API, a partir de la
verificación de la contraseña, o bien por el
código que está escrito dentro del dongle. Por otra
parte los ficheros de datos internos sólo pueden ser
accedidos por el fichero ejecutable que fue introducido en el
dispositivo. La única forma en que la aplicación
externa podría acceder a los ficheros de datos internos es
utilizando el fichero ejecutable.

El sistema operativo es el RockeyCOS, el cual es un
Sistema Operativo de Chip3, permite que la smart card dentro del
dongle se comporte como una computadora independiente y segura.
Esto lo lleva a cabo garantizando la ejecución de los
ficheros según su nivel de seguridad y el del sistema. Ambas
propiedades establecen la forma en que pueden ser accedidos los
ficheros de datos y los ejecutables, así como el nivel de
visibilidad.

Además este dongle tiene embebido la Maquina
Virtual C51 y el compilador Keil, lo que permite compilar
código escrito en C para ser ejecutado en el
microcontrolador 8051. [26, 27]

La estrategia para proteger un
fichero consiste en identificar un fragmento del programa a
proteger y pasarlo al dongle, este fragmento debe ser una
porción importante, algún procedimiento clave de la
aplicación en cuestión. De forma tal que este se
ejecute en una arquitectura de smart card, o sea será
ejecutada en una arquitectura que es bastante difícil de
duplicar y la información no puede ser accedida sin la
correcta autorización. [11, 23-25]

Técnicas de ofuscación acopladas a un
soporte de hardware reconfigurable.

Este mecanismo de protección se expone en [12, 28].
El mismo está basado en los métodos de Infraestructura
de Clave Pública (PKI) y de ofuscación a partir de la
mutilación de código, con el objetivo de hacerlo menos
comprensible.

El método propuesto se basa en la suplantación
del procesador estándar por una Unidad de Validación de
Integridad basada en una FPGA, que se ubica entre el nivel
más alto de la memoria cache y la memoria principal, ver
figura 3. Esta unidad es capaz de ejecutar con rapidez el
descifrado de código de forma similar a los esquemas de
aceleración criptográfica basada en hardware;
además de tener la habilidad de reconocer y certificar
mensajes binarios ocultos dentro de una instrucción regular
sin cifrar.

El funcionamiento de este método es el siguiente.
En el ejecutable existen diferentes porciones que se encuentran
cifradas y que serán descifradas dentro de la FPGA mediante
algún algoritmo de clave privada.

Fig. 3. Vista conceptual del
modelo propuesto.

Por otra parte, dentro del código se encuentra una
porción de este que utiliza técnicas de asignación
de registros, la cual se encarga
de asignar registros a cada instrucción. De esta forma se
leen estas instrucciones dentro de la FPGA y se extrae la
secuencia de registros, luego esta secuencia se codifica y se le
aplica cierta función. Por otra parte, a
una determinada distancia de haber capturado esta secuencia, se
captura una función de la cual se obtiene su código de
operación (OpCode), luego se compara este código con el
resultado de la función que se aplicó a la secuencia de
registros. Si ambos códigos se corresponden entonces se
continua con la ejecución, en caso contrario se
detiene.

Las instrucciones luego de ser validadas son entregadas
a la cache para que sean ejecutadas por el procesador. El ejemplo
antes descrito puede ser visto en la siguiente figura.

Fig. 4. Ejemplo del funcionamiento
del método.

Mediante esta técnica se garantiza de cierta forma
la integridad de la aplicación, o sea que la aplicación
no sea manipulada y modificada; en caso positivo se vería
imposibilitada la ejecución de la aplicación. Lo que si
no llega a evitar totalmente esta técnica es que sea el
microprocesador de la computadora el que ejecute la
instrucción. Esto introduce un riesgo, a partir del hecho de
que cualquier arquitectura convencional es un medio inseguro para
ejecutar cualquier aplicación, ya que el atacante
podría interceptar las instrucciones cuando sean entregadas
para su ejecución al microprocesador.

Este problema se vería solucionado si las
instrucciones importantes se ejecutaran dentro de la FPGA y esta
devolvería el resultado de dicha operación. Los
mecanismos de protección planteados en esta técnica
serían válidos también ya que brindarían un
mecanismo de chequeo para saber si la instrucción fue
manipulada o no.

Por otra parte el problema de distribución y
actualización de la aplicación que protege la FPGA no
es tratado. Esto es catalogado como un problema ya que, ¿de
qué forma será distribuida la aplicación y el
hardware sin que sean modificados por un atacante?, o en caso de
que la aplicación protegida se modifique ¿cómo le
llegaría la aplicación modificada al usuario final? y
¿cómo se actualizaría el hardware? Esta
última interrogante puede ser respondida, ya que se
usaría un fichero de descripción para reconfigurar el
hardware. Pero desafortunadamente esto genera otros problemas como son: el medio
por el que viaja el fichero y la nueva aplicación parte del
hecho que no es seguro, por tanto el flujo puede ser interceptado
por un atacante para tratar de obtener provecho.

Mecanismo de hardware basado en componentes
estándares que permita ejecutar código
cifrado

En [14, 29], proponen un mecanismo de hardware que
permite que código especialmente cifrado sea ejecutado de
forma segura sobre una modificación al hardware
estándar. La idea básica es descifrar un flujo de
instrucciones cifradas, de una forma que no revele el flujo
descifrado a un observador. El mecanismo se llama XOM
(eXecuteOnly Memory), dado que un bloque de instrucciones cifrado
puede ser ejecutado pero no puede ser manipulado de ninguna forma
debido al cifrado. El objetivo en el diseño de XOM ha sido
identificar la primitiva a nivel de máquina más simple
posible que permita que una variedad de mecanismos de
protección de software sea programada. Una de las
aplicaciones pretendidas para esta arquitectura es que el
vendedor de la aplicación pueda cifrar el código antes
de enviarla por Internet al propietario de la máquina
XOM. El dueño de la máquina no conocería la clave
para descifrar. Sin embargo, esta clave estaría embebida en
el chip XOM y esto permitiría que instrucciones cifradas
puedan ser ejecutadas. Debido a que cada chip tiene una clave
diferente a los demás, las aplicaciones sólo
podrán ser ejecutadas en un único chip.

Para evitar penalizar el rendimiento cuando un
código ordinario es ejecutado, el descifrado es ejecutado a
lo largo de un camino de carga de instrucciones separadas que
operan sólo cuando el chip está en modo XOM. Este
camino de carga también verifica la integridad del
código cifrado, de esta manera si alguien modifica una
secuencia de instrucciones, esta sea rechazada. Finalmente, las
interrupciones son deshabilitadas durante la ejecución de
XOM y los registros que se encuentran en el chip son limpiados
cuando se sale del modo XOM para preservar los secretos de las
operaciones.

Además de tratar de suministrar el mismo grado de
seguridad de otras soluciones, esta solución trata de
minimizar el impacto global sobre el rendimiento y diseño
del procesador.

En la propuesta se utiliza criptografía de clave
pública, en un inicio se podría suponer que sería
utilizada para cifrar el código usando la clave pública
mientras que la privada asociada se almacenaría dentro del
chip. De esta forma se logra que el código sea ejecutado en
un único chip. Una desventaja de criptografía de clave
pública es que es computacionalmente cara y difícil de
implementar en hardware porque requiere la exponenciación de
grandes números. Es por eso que en la solución
adoptaron la utilización de un mecanismo híbrido, este
consiste en utilizar el algoritmo de clave pública con el
cual se cifraría una clave que se emplearía para
ejecutar un proceso de descifrado mediante un algoritmo de clave
privada o simétrico. Este mecanismo está fundamentado
por el hecho de que los algoritmos simétricos basan su
funcionamiento en permutaciones y sustituciones de bits, mientras
que los asimétricos en la realización de operaciones de
exponenciación de grandes números.

De esta manera en el encabezado del bloque estaría
la clave del algoritmo simétrico cifrada con la clave
pública correspondiente a la privada que se encuentra
almacenada dentro del hardware. Por tanto en el momento de
procesar un bloque la máquina pasaría a descifrar el
encabezado y lo que se obtiene como resultado utilizarlo para
descifrar el resto del bloque de código.

En XOM, para lograr todo este mecanismo híbrido, se
utilizan el algoritmo RSA en combinación con el DESX. Para
garantizar la integridad de los bloques de código cifrados
usan MAC en cada unidad de código, mientras que para
mantener la integridad del segmento de código completo
cifrado de encadenamieno de bloques o CBC.

Por otra parte, para garantizar un conjunto de
requerimientos, se insertan nuevas instrucciones al conjunto de
instrucciones básicas. Estas serán instrucciones que
indicarán que se va a entrar a un conjunto de instrucciones
XOM y de forma análoga para salir, además de
instrucciones para cargar y almacenar información en la
memoria. A grandes rasgos se puede decir que la instrucción
para entrar pone el procesador en modo XOM, esto es de forma
análoga al modo usuario y supervisor que tienen los sistemas operativos. Mediante la
clave pública descifra la clave privada con que fueron
cifrados los bloques de código. Luego la unidad que
está encargada de mover las instrucciones desde la memoria
al CPU (Instruction fetch), pasa estas instrucciones a
través de la Unidad de Descifrado de Instrucciones donde,
como su nombre lo indica, las instrucciones son descifradas y
verificada su autenticidad.

La instrucción de salida es suministrada cuando
finaliza la ejecución de instrucciones XOM y así el
procesador podrá volver a su modo normal. Esta
instrucción provoca que el estado de la arquitectura sea
asegurado y los procesos de escritura
pendientes sean completados. Por último, el modo XOM es
cambiado al normal y el proceso que está encargado de mover
las instrucciones desde la memoria al CPU vuelve a su modo
normal.

Además es utilizada una memoria llamada XRAM para
almacenar valores temporales. Esta
memoria, luego de salir del modo XOM, es limpiada de forma tal
que los datos no puedan ser leídos. Este espacio es accedido
a través de las instrucciones de carga y almacenamiento
incorporadas.

Desde el punto de vista de la implementación de
este método, se modificaron algunas unidades funcionales de
un procesador clásico. En la figura 5 se muestra la
arquitectura propuesta, donde las unidades modificadas se
encuentran resaltadas. A continuación se describen
brevemente cada una de estas modificaciones:

– Una de las modificaciones consiste en adicionar un
bit más en el registro de estado, con el
objetivo de indicar si el procesador se encuentra en modo XOM.
Este bit será modificado sólo en el mecanismo de
entrada y salida al modo XOM. En el momento que el procesador
salga del modo XOM es necesario que los registros y la
caché sean ilegibles por cualquier código que se
ejecute después; ya que un atacante podría esperar
hasta que se salga de este modo para examinar el estado de los
registros y de esta manera obtener información de
cómo trabaja el procesador en modo XOM. Este proceso si lo
hiciera el propio código sería muy costoso y
además requeriría de otras consideraciones. Por lo
que en este trabajo proponen un mecanismo mediante el cual el
procesador es quien provee esta funcionalidad.

El mecanismo consiste en adicionar dos etiquetas a
todos los datos potencialmente sensibles. La primera de ellas
es una etiqueta de validez que indica si el dato almacenado en
la localización está actualizado. La otra es una
etiqueta que indica si la última vez que fue escrito el
objeto fue en modo XOM o no. Cuando se ejecuta una salida del
modo todos los datos que tengan esta etiqueta son marcados como
no válidos.

– Otra de las modificaciones fue aplicada a la unidad
encargada de mover las instrucciones desde la memoria al CPU,
la cual será la encargada de descifrar las instrucciones;
ya que las instrucciones ejecutadas en modo XOM están
cifradas, lo que implica que deben ser descifradas cuando pasen
a la lógica común de decodificación de
instrucciones presente en el procesador.

– Unidad de descifrado de la clave de sesión.
Esta unidad es la encargada de descifrar, mediante un algoritmo
asimétrico (en este caso RSA), la clave del algoritmo
simétrico. Utilizando esta clave es que se podrá
ejecutar el descifrado del código.

– Unidad de descifrado de instrucciones. Es la
encargada de descifrar las instrucciones a partir de la clave
del algoritmo simétrico. El algoritmo usado en este caso
es el DESX, el cual es una variante fortalecida del algoritmo
DES.

Fig. 5. Arquitectura de la
máquina XOM.

Además entre las ventajas que provee la
máquina está la de suministrar almacenamiento dividido
en compartimientos. Este método se apoya en las etiquetas
anteriormente descritas, la cual se denomina identificador XOM.
Este identificador es tomado a partir de la clave de sesión
y usado como índice en una tabla de claves de sesión,
la cual relaciona el identificador XOM con la correspondiente
clave de sesión. En el caso de que el código no
esté cifrado será ejecutado en un compartimiento no
protegido, o sea que no tiene asociada una clave.

Cuando una aplicación genera datos la máquina
le coloca como etiqueta el identificador de la aplicación
que está activa. De la misma forma, cuando una
aplicación lee los datos se compara el identificador activo
con la etiqueta del dato, causando una excepción si no son
iguales. De esta manera se garantiza que una aplicación no
acceda a los datos de otra.

De forma, la máquina garantiza que una
aplicación no pueda acceder a la zona de memoria de otra
aplicación. Al tener en cuenta esto logran establecer un
ambiente de ejecución seguro.

3
Principales vulnerabilidades

La intención de esta sección es exponer de
forma clara las vulnerabilidades que presentan estos métodos
y/o soluciones. Aunque en el transcurso de este trabajo a medida
que se iban describiendo fueron puntualizados algunos
detalles.

Primeramente decir que ambos métodos son
vulnerables a ataques mecánicos producidos por la
manipulación de su envoltura física o de sus propios componentes.
Además de ser objetivo de ataques eléctricos y de
variación de las condiciones de operación (temperatura,
voltaje, nivel de radiación permisible, etc.)
[13, 30-32].

Por otra parte se puede decir que de manera general las
soluciones que utilizan la técnica de pregunta respuesta
pueden ser emuladas con un mayor o menor grado de dificultad.
Ello se evidencia en la existencia de sitios en Internet que
ofrecen este tipo de "servicio" [2, 3].

Además existen vulnerabilidades relacionadas con la
forma que se ha utilizado para ganar en seguridad, el uso de la
criptografía simétrica. El uso de esta requiere que la
aplicación tenga conocimiento de la clave privada con la
cual se cifrará la información para enviarla al dongle.
La vulnerabilidad aparece cuando la aplicación va a
almacenar la clave, ya que esta estaría almacenada dentro
del código de la misma; posibilitando esto, que un atacante
empleando herramientas de depuración identifique la llamada
a la API y de esta forma obtener los datos que sean
intercambiados. Otra forma sería utilizando un programa que
establezca un monitoreo del tráfico entre el dispositivo y
la aplicación para poder obtener las claves de cifrado.
Aunque hay que destacar que algunas soluciones han tenido esto en
cuenta y han incluido técnicas de detección de
depuradores [10, 19, 21].

En el caso de los métodos que ejecutan piezas de
código dentro del dispositivo, ofrecen un mejor nivel de
seguridad. Sus autores han ido cubriendo todo un amplio rango de
consideraciones que de no tenerse en cuenta echaría por
tierra hasta la mejor idea.
Algunas de estas consideraciones están relacionadas con los
temas de actualización y distribución de la
aplicación y el dispositivo respectivamente. Desde el punto
de vista de las actualizaciones es necesario que cuando se
diseñe un sistema como estos se considere si las
aplicaciones que se ejecutarán dentro del mismo (Sistemas Operativos, aplicaciones
de propósito específico, etc) podrán ser
actualizadas o no; partiendo del hecho de que la mayoría de
las aplicaciones pueden ser suministradas por terceros. En caso
de existir habría que tener en cuenta la forma en que se
hace llegar la actualización al dispositivo, ya que
podría existir alguien o algo en el medio del canal de
comunicación que intercepte dicho flujo y logre determinar
algún indicio de cómo es que funciona la
aplicación o en el peor de los casos logre hacer
modificaciones al código, de forma tal que cuando se ejecute
un determinado segmento de código dentro del dispositivo
este recuperar información secreta y sea enviada al
atacante. Lo mismo pudiera suceder con la distribución del
dispositivo físico, un atacante podría interceptarlo en
medio del canal y ejecutar una serie de acciones contra la integridad
del mismo con el fin de obtener información sensible. En
resumen es necesario tener en cuenta que en cuestiones de
actualización y/o distribución existen riesgos [22].

Otra vulnerabilidad es la relacionada con el acceso a la
memoria del dispositivo por parte de las aplicaciones, en caso de
que en el mismo se permita la ejecución simultánea de
varias aplicaciones. Para darle solución a esta
vulnerabilidad es necesario tener en cuenta un esquema de
administración de memoria
y procesos para impedir accesos a memoria no válidos [13,
14, 22, 29]. Además es necesario tener en cuenta la
posibilidad, aunque remota, de posibles modificaciones a las
aplicaciones que están dentro del dispositivo, para lograr
que esta ejecute algún código que de al traste Un
vistazo al estado del arte de las técnicas de
protección de software basadas en hardware con los secretos
almacenados en el dispositivo.

4
Conclusiones

Al término de este trabajo se puede concluir
que:

– Los diseñadores software tomen la seguridad de
sus sistemas como algo serio e
importante.

– Cuando se vaya a diseñar un método es
necesario tener en cuenta un amplio espectro de requisitos si
se quiere lograr una solución lo suficientemente
segura.

– El método de pregunta/respuesta sólo
garantiza un determinado nivel de seguridad.

– Por su parte, el método de ejecución de
código en hardware asistente sí garantiza un nivel
bastante bueno de seguridad.

5 Trabajo
futuro

Las intenciones futuras con este trabajo son:

– Continuar profundizando en el estado del arte de las
soluciones existentes basadas en hardware, para así
obtener sus principales ventajas y deficiencias.

– Hacer un análisis de los componentes de
hardware utilizados en estas soluciones, con el propósito
de seleccionar los idóneos para ser utilizados.

– Realizar una propuesta de arquitectura, basada en
las tareas anteriores, que logre brindar un marco seguro para
ejecutar las aplicaciones.

– Probar la arquitectura propuesta utilizando
herramientas simuladoras y así determinar eficiencia.

– Analizar los diferentes métodos de
protección basados en software.

Referencias

1. Global Software Piracy Study [On line], 2006.
Business Software Alliance. <
, [Noviembre 2006]

2. Soft store [On line], mayo 2007.
<http://www.prosoftstore.com/> ,
[mayo 2007]

3. SoftKey, SoftKey Solutions [On line], mayo
2007. <http://www.software-key.org/> ,
[mayo 2007]

4. Aucsmith, D., Tamper Resistant Software: An
Implementation, paper presented at the Proceedings of the
First International Workshop on Information Hiding, 1996, pp.
317-333.

5. Chow, S., Eisen, P.A., Johnson, H., Oorschot, P.C.v.,
A White-Box DES Implementation for DRM Applications, paper
presented at the Proceedings of ACM Workshop on Digital Rights
Management (DRM2002), Washington DC, USA, 2002, pp.
1-15.

6. Chow, S., Eisen, P.A., Johnson, H., Oorschot, P.C.v.,
White-Box Cryptography and an AES Implementation, paper
presented at the Proceedings of the Ninth Workshop on Selected
Areas in Cryptography (SAC 2002), London, UK, 2002, pp.
250-270.

7. Collberg, C., Thomborson, C., Watermarking,
Tamper-Proofing, and Obfuscation – Tools for Software
Protection, in Transactions on Software Engineering.
(IEEE, 2002), vol. 28, pp. 735-746.

8. Collberg, C., Thomborson, C., Low, D., A taxonomy
of Obfuscating Transformations [On line], July 1997.
Technical Report 148, Department of Computer Science, University
of Auckland. <http://citeseer.nj.nec.com/collberg97taxonomy.html>
, [January 2007]

9. Nagra, J., Thomborson, C., Collberg, C., A
functional taxonomy for software watermarking, paper
presented at the Proceedings of the twenty-fifth Australasian
conference on Computer science – Volume 4, Melbourne, Victoria,
Australia, 2002, pp. 177-186.

10. Aladdin, HASP HL [On line].
<http://www.aladdin.com/HASP/HaspHL.asp>
, [Noviembre 2006]

11. Feitian, T., ROCKEY6 Smart [On line], 2007.
<http://www.rockey.com.my/prod_dongle_rockey6.php>
, [Noviembre 2006]

12. Joseph Zambreno, A.C., Rahul Simha, Bhagirath
Narahari, Flexible Software Protection Using Hardware/Software
Codesign Techniques [On line], 2004. IEEE Computer Society.
<http://www.seas.gwu.edu/~simha/research/DATEParis.pdf>
, [Enero 2007]

13. Smith, S.W., Weingart, S.: "Building a
high-performance, programmable secure coprocessor." Computer
Networks: The International Journal of Computer and
Telecommunications Networking, vol. 31, (April 23 1999),
831-860.

14. David Lie, C.T., Dan Boneh, John Mitchell, Mark
Horowitz, Architectural Support for Copy and Tamper Resistant
Software [On line], 2000. Computer Systems Laboratory
Stanford University. <http://www-vlsi.stanford.edu/papers/djl_asplos_2000_xom.pdf>
, [Enero 2007]

15. Sean W. Smith, S.W., Building a High-Performance,
Programmable Secure Coprocessor [On line], 16 October 1998.
<http://coblitz.codeen.org:3125/citeseer.ist.psu.edu/cache/papers/cs/25219/http:zSzzSzwww.research.ibm.comzSzsecure_systemszSzpaperszSzarch.pdf/smith98building.pdf>
, [Febrero 2007]

16. Tuomas Aura, D.G., Software License Management
with Smart Cards [On line], Mayo 1999. USENIX Workshop on
Smartcard Technology. <www.usenix.org/events/smartcard99/aura.html
>, [Enero 2007]

17. Eilam, E., Reversing, secrets of reverse
engineering. (Wiley Publishing, Inc., Indianapolis, Indiana,
2005), pp. 589.

18. SafeNet, Sentinel UltraPro [On line], 2007.
SafeNet, Inc. <http://www.safenet-inc.com/products/sentinel/ultraPro.asp>
, [Abril 2007]

19. Aladdin, Benefits of the HASP HL Automatic
Software Protection Tool. Technical Document for Software
Developers. [On line], Octubre 2004. Aladdin Knowledge
Systems, Ltd. <http://www.aladdin.com/HASP/HaspHL.asp>
, [Marzo 2007]

20. SafeNet, Sentinel™ UltraPro™ 1.0
Developer’s Guide [On line], 2004. SafeNet, Inc.
<www.pericosecurity.com/getfile.php/154209.809/Sentinel+UltraPro+Developer%5C's+Guide.pdf>
, [Abril 2007]

21. Aladdin, HASP HL Max [On line], 28/02/2007.
Aladdin Knowledge Systems, Ltd. <http://www.aladdin.com/HASP/HaspHL.asp>
, [Marzo 2007]

22. Smith, S.W., Palmer, E.R., Weingart, S., Using a
High-Performance, Programmable Secure Coprocessor, paper
presented at the Second International Conference on Financial
Cryptography, 1998.

23. Feitian, T., ROCKEY6 Smart Tutorial [On
line], 18/11/2005. Feitian Technologies Co. Ltd.
<http://www.rockey.com.my/dl_dongle_rockey6.php>
, [Abril 2007]

24. Feitian, T., ROCKEY6 Smart Developer Manual
[On line], 18/11/2005. Feitian Technologies Co. Ltd.
<http://www.rockey.com.my/dl_dongle_rockey6.php>
, [Abril 2007]

25. Feitian, T., ROCKEY6 User Manual [On line],
18/11/2005. FEITIAN Technologies Co., Ltd. <http://www.rockey.com.my/dl_dongle_rockey6.php>
, [Abril 2007]

26. Beach, M., C51 Primer [On line], 03/03/96.
<http://www.esacademy.com/automation/docs/c51primer/c51prim.htm#Contents>
, [Abril 2007]

27. Keil, a.A.C., Embedded Development Tools [On
line], 2007. <http://www.keil.com/> , [Abril
2007]

28. Joseph Zambreno, D.H., Alok Choudhary, Rahul Simha,
Bhagirath Narahari, High-Performance Software Protection Using
Reconfigurable Architectures [On line], Febrero 2006.
<http://www.seas.gwu.edu/~simha/research/IEEEProc.pdf.>
, [Enero 2007]

29. Dan Boneh, D.L., Pat Lincoln, John Mitchell, Mark
Mitchell: "Hardware Support for Tamper-Resistant and
Copy-Resistant Software." (November 14, 1999.

30. Grand, J., Advanced Hardware Hacking
Techniques [On line], 2005. Grand Idea Studio, Inc.
<http://www.grandideastudio.com/files/security/hardware/advanced_hardware_hacking_techniques_slides.pdf>
, [enero 2007]

31. Grand, J., Attacks on and Countermeasures for
USB Hardware Token
Devices, paper presented at the Proceedings of the Fifth
Nordic Workshop on Secure IT Systems, 2000.

32. Simon Moore, R.A.M.K., Improving Smartcard
Security Using Self-timed Circuit Technology [On line], 2000.
University of Cambridge, Computer Laboratory. <http://citeseer.ist.psu.edu/moore02improving.html>
, [Enero 2007]

Autor:

Ing. Humberto
Díaz Pando
Ing. Yulier Nuñez Musa
Dr. Roberto Sepúlveda Lima

Enviado por:
Ing. Belkis Grissel González
Rodríguez