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