IMPLEMENTACIÓN EN HARDWARE DEL ALGORITMO RIJNDAEL

Transcripción

1 IMPLEMENTACIÓN EN HARDWARE DEL ALGORITMO RIJNDAEL Germán Jácome-Calderón, Jaime Velasco-Medina, Julio López-Hernández* Grupo de Bioelectrónica y Nanoelectrónica, Escuela EIEE *Escuela EISC, Universidad del Valle,A.A , Cali, Colombia gecalder73@tutopia.com, jvelasco@univalle.edu.co, jlopez@eisc.univalle.edu.co ABSTRACT This article presents the design of two hardware architectures for the Rijndael algorithm, using programmable logic devices and VHDL description language. The Iterative and Pipeline architectures were designed by considering the hardware implementation advantages for some transformations of Rijndael algorithm over software implementations. Additionally, different designs were taken in account for implementing the multiplication of the MixColumn transformation, evaluating speed and area parameters. The architectures were compiled and simulated using Quartus II tool of Altera, and the simulation results are good and these are compared with different results presented in the literature. RESUMEN Este artículo presenta el diseño de dos arquitecturas en hardware para el algoritmo Rijndael, usando dispositivos lógicos programables y el lenguaje de descripción VHDL. Las arquitecturas Iterativa y Pipeline fueron diseñadas considerando las ventajas que presenta la implementación de algunas transformaciónes del algoritmo Rijndael en hardware con respecto a las implementaciones en software. Adicionalmente, para la implementación de las arquitecturas se consideraron diferentes diseños para la multiplicación en la transformación MixColumn evaluando los parámetros de velocidad y área respectivamente. Las arquitecturas fueron compiladas y simuladas usando la herramienta Quartus II de Altera, y los resultados de simulación son altamente satisfactorios y son comparados con los presentados en la literatura.

2 IMPLEMENTACIÓN EN HARDWARE DEL ALGORITMO RIJNDAEL Germán Jácome-Calderón, Jaime Velasco-Medina, Julio López-Hernández* Grupo de Bioelectrónica y Nanoelectrónica, Escuela EIEE *Escuela EISC, Universidad del Valle,A.A , Cali, Colombia gecalder73@tutopia.com, jvelasco@univalle.edu.co, jlopez@eisc.univalle.edu.co RESUMEN Este artículo presenta el diseño de dos arquitecturas en hardware para el algoritmo Rijndael, usando dispositivos lógicos programables y el lenguaje de descripción VHDL. Las arquitecturas Iterativa y Pipeline fueron diseñadas considerando las ventajas que presenta la implementación de algunas transformaciónes del algoritmo Rijndael en hardware con respecto a las implementaciones en software. Adicionalmente, para la implementación de las arquitecturas se consideraron diferentes diseños para la multiplicación en la transformación MixColumn evaluando los parámetros de velocidad y área respectivamente. Las arquitecturas fueron compiladas y simuladas usando la herramienta Quartus II de Altera, y los resultados de simulación son satisfactorios y son comparados con los presentados en la literatura. 1. INTRODUCCION La transmisión de información entre sistemas electrónicos requiere cada vez más del uso de técnicas criptográficas, es decir, se requieren sistemas que sean capaces de realizar el proceso de encriptación y desencriptación en el menor tiempo posible debido al alto volumen de información que se procesa, entonces es aquí donde el hardware presenta mayores ventajas sobre el software. Las implementaciones en hardware presentan un mejor desempeño para los requerimientos de alta velocidad en las comunicaciones, seguridad física y bajo costo. Los algoritmos criptográficos implementados en hardware son físicamente más seguros debido a que éstos no pueden ser fácilmente modificados por un atacante externo [1]. Para alcanzar seguridad en la información, existen en el mercado varios algoritmos y sistemas criptográficos, algunos de los cuales ya han quedado obsoletos puesto que han sido atacados exitosamente. Por lo tanto existe la necesidad de crear nuevos algoritmos criptográficos que resistan los ataques basados en el uso de los computadores de alto desempeño. Teniendo en cuenta las consideraciones anteriores, el NIST (National Institute of Standards and Technology) llevó a cabo el proceso de coordinación para reemplazar al sistema criptográfico DES (Data Encryption Standard). En este contexto, los algoritmos seleccionados por el NIST como finalistas para el AES (Advanced Encryption Standard) fueron: MARS, RC6, RIJNDAEL, SERPENT y TWOFISH [2]. NIST anunció el 2 de 0ctubre del 2000, que el algoritmo Rijndael fue seleccionado como el algoritmo AES (Advanced Encryption Standard), debido a su seguridad, desempeño, eficiencia, flexibilidad y facilidad de implementación [3]. En este contexto, en la literatura se encuentran algunas implementaciones en hardware del algoritmo Rijndael, las cuales son presentadas en [1], [7], [8], [9], [10] y [11], sin embargo estos diseños son realizados usando herramientas y dispositivos que no presentan buen desempeño. Entonces este trabajo es orientado a presentar diseños eficientes para implementaciones en hardware del algoritmo Rijndael usando la herramienta Quartus II de Altera, la cual realiza un excelente proceso de síntesis sobre dispositivos FPGAs. Este trabajo esta organizado de la siguiente manera, en la sección 2 se presenta una descripción detallada del algoritmo Rijndael, en la sección 3 se describe el diseño y la implementación en hardware del algoritmo Rijndael, en la sección 4 se presentan los resultados de las simulaciones para las dos arquitecturas hardware diseñadas para el algoritmo Rijndael, y finalmente en la sección 5 se presentan algunas conclusiones y trabajo futuro. 2. EL ALGORITMO RIJNDAEL Todas las operaciones usadas en el algoritmo Rijndael son operaciones de cambio de posición de los bytes y operaciones sobre el cuerpo finito GF(2 8 ). El tamaño de las entradas para el algoritmo Rijndael, tanto para el texto como para la clave varían entre 128 y 256 bits considerando un incremento de 32 bits. NIST solo estandarizó la versión con un tamaño de texto de 128 bits y un tamaño de clave de 128, 192 y 256 bits. El algoritmo Rijndael ha sido diseñado considerando un conjunto amplio de estrategias, las cuales presentan resistencia contra el criptoanálisis lineal y diferencial [9]. Dentro de las estrategias, el algoritmo emplea algunas iteraciones llamadas vueltas que están divididas en diferentes transformaciones, cada una con su propia funcionalidad. Se define el estado de un bloque de código como el resultado intermedio del proceso de encriptación. El estado es representado por un arreglo rectangular de bytes el cual siempre contiene 4 filas. El número de columnas es determinado por el tamaño del bloque: si el tamaño del bloque es N, el número de columnas N b es igual a N/32. El estado es inicializado considerando un texto plano en el orden a 0,0, a 1,0, a 2,0, a 3,0, a 0,1, a 0,2. Las vueltas son realizadas considerando transformaciones que operan sobre el estado. Por último, al final de las operaciones de encriptación, la salida o el texto encriptado es extraído del estado tomando los bytes del estado en el mismo orden. La clave usada en el algoritmo es similarmente mostrada como un arreglo rectangular de bytes con 4 filas, el número de columnas de la clave está determinado por N K y es igual al tamaño de la clave dividido por 32. Algunas veces la clave es presentada como un arreglo lineal de palabras de 4 bytes. En este caso, las palabras están distribuidas dentro de cada columna. El número de vueltas está descrito por N r y depende de

3 los valores de N b y N K. 2.1 Proceso de Encriptación El algoritmo de encriptación de Rijndael está compuesto por: Una transformación AddRoundKey N r -1 vueltas Una vuelta final Cada vuelta consta de 4 transformaciones, las cuales son: SubByte, ShiftRow, MixColumn y AddRoundKey. La vuelta final del algoritmo es ligeramente diferente, en ésta, la transformación MixColumn ha sido eliminada. La transformación SubByte es una sustitución no lineal de bytes, que opera sobre cada uno de los bytes del estado independientemente usando una tabla de sustitución o S- box. La transformación usa la misma S-box para todos los bytes [3]. En la transformación ShiftRow, la primera fila se mantiene constante mientras que las 3 ultimas filas del estado son rotadas dependiendo del número de columnas (N b ) que tenga el estado (4, 6, 8). La fila 2 es rotada a la izquierda una vez para cualquier número de columnas del estado; la fila 3 es rotada 2 veces a la izquierda para un estado de 4 y 6 columnas, y es rotada 3 veces a la izquierda para un estado de 8 columnas; y la fila 4 es rotada 3 veces a la izquierda para un estado de 4 y 6 columnas y es rotada 4 veces a la izquierda para un estado de 8 columnas. En la transformación MixColumn, las columnas N b del estado son transformadas por medio de una multiplicación usando una matriz fija. Las operaciones son llevadas a cabo dentro del cuerpo finito GF(2 8 ). En este caso la adición es realizada usando una simple XOR y la multiplicación no corresponde a la multiplicación estándar de enteros. En conjunto con la transformación ShiftRow, esta transformación asegura que después de unas pocas vueltas, todos los bits de salida dependen únicamente de los bits de entrada. La transformación final es la transformación AddRoundKey, en la cual se realiza una simple operación XOR entre la clave o subclaves y el último estado de cada vuelta. Este último estado es el estado siguiente después de haber realizado la transformación MixColumn excepto en la primera vuelta en la cual se realiza con el texto original. Cada una de las vueltas contiene N b palabras que son derivadas de la clave inicial por medio del cronograma de claves [3]. 2.2 Generación de las Subclaves La expansión de la clave es un arreglo lineal de palabras de 4 bytes, donde el número total de palabras generadas (44,52,60) esta determinado por la relación N b (N r +1). Las primeras N k (N k =4,6,8) palabras contienen la clave inicial, es decir los primeros 128, 192 y 256 bits. Todas las palabras siguientes son generadas recursivamente en términos de las palabras anteriores. Cuando las palabras de la clave inicial han sido usadas, todas las palabras siguientes W[i] se generan con la XOR de la palabra anterior W[i-1] y la palabra en la posición W[i-N k ]. Además, la generación de las palabras de las subclaves depende del valor de N k. Para palabras en posiciones que son un múltiplo de N k, se le aplica una transformación a W[i-1] antes de realizar la XOR con W[i-N k ]. Esta transformación está compuesta por: a) Una transformación llamada RotWord para la rotación de los bytes de la palabra. b) Una transformación SubWord, la cual aplica la S-box a todos los 4 bytes de la palabra, la transformación SubWord usa los mismos valores de la S-box que usa la transformación SubByte. c) Una transformación llamada Rcon, la cual es una XOR entre la palabra y algunos valores que depende de las palabras que se encuentran en posiciones que son múltiplo de N k. 2.3 Proceso de Desencriptación El algoritmo de desencriptación consiste en la aplicación de las transformaciones del algoritmo de encriptación en orden inverso para obtener el texto plano. Las transformaciones usadas para desencriptar son: InvShiftRow, InvSubByte, InvMixColumn y AddRoundKey. La vuelta final del algoritmo es ligeramente diferente por que se ha eliminado la transformación InvMixColum. La transformación InvAddRoundKey es la misma transformación AddRoundKey que fue descrita en el proceso de encriptación, ya que ésta solo involucra una aplicación de la operación XOR. La transformación InvMixColumn es la inversa de la transformación MixColumn. En la transformación InvMixColumn, las columnas N b del estado son transformadas por medio de una multiplicación usando una matriz fija. La transformación InvShiftRow es la inversa de la transformación ShiftRow. En la transformación InvShiftRow, la primera fila se mantiene constante mientras que las 3 ultimas filas del estado son rotadas dependiendo del número de columnas (N b ) que tenga el estado (4, 6, 8). La fila 2 es rotada a la derecha una vez para cualquier número de columnas del estado; la fila 3 es rotada 2 veces a la derecha para un estado de 4 y 6 columnas, y es rotada a la derecha 3 veces para un estado de 8 columnas; y la fila 4 es rotada 3 veces a la derecha para un estado de 4 y 6 columnas y es rotada a la derecha 4 veces para un estado de 8 columnas. La transformación InvSubByte es la inversa de la transformación SubByte. La transformación InvSubByte es una sustitución no lineal de bytes que opera sobre cada uno de los bytes del estado independientemente. La transformación InvSubByte usa la S-box inversa de la SubByte [3]. 3. ARQUITECTURAS HARDWARE PARA RIJNDAEL El algoritmo Rijndael puede ser implementado en hardware considerando diferentes arquitecturas tales como: Iterativa, Pipeline, SubPipeline y Loop unrolled [1][5]. En este trabajo son implementadas las arquitecturas Iterativa y Pipeline. En la Figura 1 se muestra un diagrama general de las arquitecturas Iterativa y Pipeline. Las otras dos arquitecturas no son presentadas en este trabajo, sin embargo, se puede mencionar que la arquitectura SubPipeline no es eficiente para implementar en hardware el algoritmo Rijndael debido a que cada una de las transformaciones realizadas en las vueltas toman diferentes tiempos, y de otro lado la arquitectura Loop Unroled comparada con la arquitectura Iterativa, no presenta un considerable incremento en el Throughput, sin embargo, el área que se requiere para esta implementación es casi 10 veces mayor que el área para la arquitectura Iterativa.

4 Implementación de la Transformación ShiftRow La transformación ShiftRow, realiza una serie de rotaciones de los bytes dentro de cada fila del estado. Su implementación en hardware consiste en la interconexión directa de las salidas de la transformación SubByte hasta las entradas de la transformación MixColumn. Esta transformación fue realizada directamente en la transformación SubByte mediante la asignación de señales, es decir asignando a cada byte de salida de la transformación SubByte el byte correspondiente de la rotación Implementación de la Transformación MixColumn Figura 1: Arquitecturas a) Iterativa b) Pipeline 3.1 Arquitectura Iterativa La arquitectura Iterativa implementada en hardware para el proceso de encriptación está conformada por los siguientes bloques funcionales [12]: Bloque AddRoundKey Bloque Round Bloque SubKey Bloque de la Unidad de Control Esta arquitectura recibe como entrada 128 bits de texto plano y 128 bits de clave, los cuales entran al primer bloque llamado AddRoundKey, el cual realiza una operación XOR entre el texto plano y la clave inicial. El segundo bloque se llama Round, el cual realiza la función de implementar las 10 vueltas del algoritmo de encriptación, donde la última vuelta (10) es ligeramente diferente de las primeras 9 vueltas debido a que no realiza la transformación MixColumn. El tercer bloque se llama SubKey, el cual se encarga de la generación de las subclaves que serán usadas en cada una de las vueltas del proceso de encriptación. El último bloque es la Unidad de Control, el cual se encarga de sincronizar y controlar las operaciones de todos los bloques anteriores Implementación del Bloque Round Para implementar el bloque Round se realizaron 2 diseños. El primer diseño permite trabajar como una vuelta regular del algoritmo (1 a 9), o como la última vuelta del algoritmo (10), la cual no realiza la transformación MixColumn. En este caso, se utilizó un multiplexor, el cual nos permite seleccionar entre la vuelta regular del algoritmo o la última vuelta del algoritmo. Para el segundo diseño, los datos que salen de la transformación SubByte y ShiftRow pasan directamente a la transformación MixColumn Implementación de la Transformación SubByte La implementación de la transformación SubByte se realizó usando 16 memorias ROMs de 256*8 bits, las cuales contienen el vector de inicialización con los valores de la S- box que son utilizadas en cada una de las vueltas del algoritmo para lograr la sustitución de los 128 bits en un solo ciclo. Para la transformación MixColumn se realizaron dos diseños, seleccionándose finalmente el mas optimo de acuerdo a la velocidad de encriptación. Para la primera implementación se diseñó un multiplicador llamado X2-X3. Este multiplicador realiza la multiplicación de un byte por 2 y por 3 dentro del cuerpo finito GF(2 8 ). En este caso, para la implementación de la transformación Mixcolumn se requieren 16 multiplicaciones por 2 y 16 multiplicaciones por 3, así como también 48 operaciones XOR. El circuito para realizar la transformación MixColumn para 16 bytes emplea 4 módulos de la transformación MixColumn para 4 bytes. Para la segunda implementación de la transformación MixColumn, se realizó un multiplicador diferente, el cual solo realiza la multiplicación por 2 dentro del cuerpo finito GF(2 8 ), este multiplicador fue llamado Xtime [3]. En este caso para la implementación de la transformación Mixcolumn, se requieren 16 multiplicaciones por 2, así como tamb ién 60 operaciones XOR. La transformación MixColumn es solamente para 4 bytes por lo tanto el circuito para realizar la transformación MixColumn para 16 bytes emplea 4 de estos módulos Implementación del Bloque Subkey: Generación de las SubClaves La generación de las subclaves se lleva a cabo en el bloque SubKey. El bloque SubKey está conformado por la secuencia de las siguientes transformaciones: Transformación SubWord Transformación RotWord Transformación Rcon Implementación de la Transformación SubWord Para la implementación de la transformación SubWord se utilizan 4 memorias ROMs como las utilizadas en la transformación SubByte. La diferencia entre estas dos transformaciones es que la transformación SubWord solo utiliza 4 memorias ROMs mientras que la transformación SubByte utiliza 16 memorias ROMs Implementación de la Transformación RotWord La implementación de la transformación RotWord se realizó de manera similar a la implementación de la transformación ShiftRow en el proceso de encriptación, con la diferencia que la transformación RotWord solo actúa sobre 4 bytes y no sobre 16 bytes como en la transformación ShiftRow.

5 Implementación de la Transformación Rcon La transformación Rcon utiliza una memoria ROM de 10x8 bits. Cada vez que se va a generar una nueva subclave, la transformación Rcon accesa a la memoria ROM y toma el dato indicado de acuerdo a la vuelta que se esta ejecutando y realiza la operación XOR con el resultado de la transformación RotWord Implementación de la Unidad de Control La Unidad de Control se realizó diseñando una máquina de estados FSM, la cual se encarga de controlar cada uno de los bloques que conforman el algoritmo Rijndael, asignando en cada ciclo de reloj el dato adecuado para la transformación Rcon del bloque SubKey y seleccionando la vuelta que se debe realizar. En la Tabla 1 se muestra la tabla de estados de la FSM. En este caso, en cada estado la FSM controla la transferencia de las entradas correspondientes para cada bloque. En el estado S0 se controlan las entradas a la transformación AddRoundKey (el texto plano y la clave) y la entrada para la generación de las subclaves en el bloque SubKey (clave inicial); en el estado S1, las salidas de los dos bloques anteriores son conectadas a la entrada del bloque Round. Desde el estado S2 hasta el estado S10 se realiza la realimentación del bloque Round y el bloque SubKey, variando únicamente las señales AS, las cuales son los datos de la transformación Rcon; y en el estado S10 se activa la señal SELR, la cual permite seleccionar la última vuelta del algoritmo. Estado Señales Estado Señales S0 AS=0000 S6 AS=0110 S1 AS=0001 S7 AS=0111 S2 AS=0010 S8 AS=1000 S3 AS=0011 S9 AS=1001 S4 AS=0100 S10 SELR=1 S5 AS=0101 S11 READY=1 Tabla 1: Tabla de Estados de la FSM para la Arquitectura Iterativa de Encriptación 3.2 Arquitectura Pipeline La arquitectura Pipeline implementada en hardware para el proceso de encriptación está conformada por los siguientes bloques funcionales [12]: Bloque AddRoundKey Bloque Registro Bloque Round (1-9) Bloque Round Final (10) Bloque SubKey Bloque de la Unidad de Control Esta arquitectura recibe un bloque de 128 bits de texto plano y 128 bits de clave, los cuales entran al primer bloque llamado AddRoundKey, el cual realiza una operación XOR entre el texto plano y la clave inicial. El segundo bloque es un Registro, el cual se encarga de almacenar el dato de salida del bloque AddRoundKey para ser posteriormente capturado por el bloque Round. El tercer bloque se llama Round, en el cual se implementan las primeras 9 vueltas del algoritmo. El cuarto bloque se llama Round Final el cual realiza la vuelta final del algoritmo. El quinto bloque se llama SubKey, en el cual se generan las subclaves que serán usadas en cada una de las vueltas del proceso de encriptación. El último bloque es la Unidad de Control, el cual se encarga de sincronizar y controlar las operaciones de todos los bloques anteriores Implementación del Bloque Round El bloque Round, está conformado por los siguientes bloques funcionales, los cuales realizan la misma función que en la Arquitectura Iterativa y por lo tanto no se explicarán en esta sección: Bloque SubByte y ShiftRow Bloque MixColumn Bloque AddRoundKey Implementación del Bloque Round Final El bloque Round Final, está conformado por los siguientes bloques funcionales, los cuales realizan la misma función que en la Arquitectura Iterativa y por lo tanto no se explicarán en esta sección: Bloque SubByte y ShiftRow Bloque AddRoundKey Implementación de la Unidad de Control La Unidad de Control se realizó diseñando una máquina de estados FSM, la cual genera señales hacia todos los bloques, de tal forma que en cada estado estas señales son asignadas como las entradas para los 10 bloques Round, 10 bloques SubKey y para los 11 Registros. En la Tabla 2 se muestra la tabla de estados de la FSM. La forma de implementar el comportamiento Pipeline es detectando el cambio de las señales de entrada de los registros o el cambio en las señales de salida de los bloques Round. Cada vez que se detecta un cambio en la señal de entrada de los registros es por que hay un dato nuevo para el siguiente bloque combinatorio Round, éste captura el nuevo dato de entrada y genera el resultado, en ese instante se detecta un dato nuevo en la salida del bloque combinatorio lo que genera el almacenamiento de un nuevo dato en el siguiente registro y esto funciona como una cadena desde el primer estado hasta el décimo estado, el cual genera el dato encriptado. Debido a que en la entrada del sistema existe un dato nuevo para cada ciclo de reloj, entonces es posible procesar un dato en cada ciclo de reloj, una vez el primer dato de entrada ha llegado a la salida del sistema; esta operación marca la diferencia con la arquitectura Iterativa que para procesar cada uno de los datos se requerían 10 ciclos de reloj, mientras que en la arquitectura Pipeline el primer dato se va a demorar 10 ciclos de reloj, sin embargo los siguientes datos son procesados en cada ciclo. De esta forma se logra un Throughput 10 veces mayor que el Throughput para la Arquitectura Iterativa.

6 Estado Señales Estado Señales S0 S1 S2 S3 S4 S5 AS0=0000 AS1=0001 AS2=0010 AS3=0011 AS4=0100 AS5=0101 AS6=0110 AS7=0111 AS8=1000 AS9=1001 S6 S7 S8 S9 S10 S11 AS0=0000 AS1=0001 AS2=0010 AS3=0011 AS4=0100 AS5=0101 AS6=0110 AS7=0111 AS8=1000 AS9=1001 READY=1 Tabla 2: Tabla de Estados de la FSM para la Arquitectura Pipeline 4. RESULTADOS DE SIMULACION PARA EL ALGORITMO RIJNDAEL En esta sección se presentan los resultados de simulación para las arquitecturas Iterativa y Pipeline, así como también se presenta una comparación entre los resultados obtenidos en este trabajo y los encontrados en la literatura. 4.1 Resultados de Simulación para la Arquitectura Iterativa Simulaciones para el Proceso de Encriptación En la Figura 2 se muestra el texto encriptado ( d02dc09fbdc a0b32) para un texto plano de 128 bits (3243f6a8885a308d313198a2e ) usando la clave de 128 bits (2b7e151628aed2a6abf cf4f3c). En este caso, la arquitectura usa el multiplexor MuxDato en el bloque Round y para la compilación se considera el parámetro de velocidad. Los resultados de simulación para la encriptación de la arquitectura iterativa del algoritmo Rijndael son presentados en la Tabla 3: Desde la Tabla 3 podemos observar que el mayor Throughput y la menor Área se obtuvieron para la arquitectura implementada con MuxDato optimizada para velocidad y para área respectivamente. Celdas Lógicas I/O Pines Velocidad Con Sin MuxDato MuxDato (15%) (18%) (81%) (81%) Área Con Sin MuxDato MuxDato (13%) (15%) (81%) (81%) EABs 21 (87%) 21 (87%) 21 (87%) 21 (87%) Bits de Memoria (41%) (41%) (41%) (41%) Fmáx Clk 16.6 ns 16.8 ns 19.8 ns 17 ns Ciclos End time ns ns ns ns Throughput Tabla 3: Resultados de Simulación de la Encriptación para la Arquitectura Iterativa Simulaciones para el Proceso de Desencriptación En la Figura 3 se muestra el texto desencriptado (3243f6a8885a308d313198a2e ) para un texto encriptado de 128 bits ( d02dc09fbdc a0b32) usando la clave de 128 bits (2b7e151628aed2a6abf cf4f3c). En este caso, la arquitectura usa el multiplexor MuxDato en el bloque InvRound y para la compilación se considera el parámetro de velocidad. Figura 2: Resultado de Simulación de la Encriptación para la Arquitectura Iterativa

7 Figura 3: Resultado de Simulación de la Desencriptación para la Arquitectura Iterativa Los resultados de simulación para la desencriptación de la arquitectura iterativa del algoritmo Rijndael son presentados en la Tabla 4: Celdas Lógicas I/O Pines 386 (81%) Velocidad Con Sin MuxDato MuxDato (25%) (30%) 386 (81%) Área Con Sin MuxDato MuxDato (18%) (27%) 386 (81%) 386 (81%) EABs 21 (87%) 21 (87%) 21 (87%) 21 (87%) Bits de Memoria Fmáx (41%) (41%) (41%) (41%) Clk 21.5 ns 22 ns 23.9 ns 22.4 ns Ciclos End time ns ns ns 267 ns Throughput Desde la Tabla 4 podemos observar que el mayor Throughput y la menor Área se obtuvieron para la arquitectura implementada con MuxDato optimizada para velocidad y para área respectivamente. 4.2 Resultados de Simulación para la Arquitectura Pipeline Simulaciones para el Proceso de Encriptación En la Figura 4 se muestra el primer texto encriptado ( d02dc09fbdc a0b32) para un texto plano de 128 bits (3243f6a8885a308d313198a2e ) usando la clave de 128 bits (2b7e151628aed2a6abf cf4f3c). En este caso, solo se muestra el primer texto encriptado debido a que la ventana de simulación no permite mostrar los 10 textos encriptados. Los resultados de simulación para la encriptación de la arquitectura Pipeline del algoritmo Rijndael son presentados en la Tabla 5: Tabla 4: Resultados de Simulación de la Desencriptación para la Arquitectura Iterativa Figura 4: Resultado de Simulación de la Encriptación para la Arquitectura Pipeline

8 Velocidad Área Celdas Lógicas 4205 (6%) 4100 (6%) I/O Pines 385 (71%) 385 (71%) ESBs 105 (%) 105 (%) Bits de Memoria (35%) (35%) Fmáx Clk ns ns Ciclos End time ns ns Throughput 9.27 Gbps 8.39 Gbps Tabla 5: Resultados de Simulación de la Encriptación para la Arquitectura Pipeline Desde la Tabla 5 podemos observar que el Throughput es del orden de Gigabits y que este valor es muy superior al obtenido para la arquitectura Iterativa. El mayor Throughput se obtuvo para la implementación que considera el parámetro de velocidad Simulaciones para el Proceso de Desencriptación En la Figura 5 se muestra el primer texto desencriptado (3243f6a8885a308d313198a2e ) para un texto encriptado de 128 bits ( d02dc09fbdc a0b32) usando la clave de 128 bits (2b7e151628aed2a6abf cf4f3c). En este caso la clave mostrada (d014f9a8c9ee2589e13f0cc8b6630ca6) es la última subclave generada en el proceso de encriptación con la cual se inicia el proceso de desencriptación. En este caso, solo se muestra el primer texto desencriptado debido a que la ventana de simulación no permite mostrar los 10 textos desencriptados. Los resultados de simulación para la desencriptación de la arquitectura Pipeline del algoritmo Rijndael son presentados en la Tabla 6: Velocidad Área Celdas Lógicas 8243 (12%) 7660 (11%) I/O Pines 385 (71%) 385 (71%) ESBs 105 (%) 105 (%) Bits de Memoria (35%) (35%) Fmáx Clk ns ns Ciclos End time ns ns Throughput 5.57 Gbps 5.53 Gbps Tabla 6: Resultado de Simulación de la Desencriptación para la Arquitectura Pipeline Desde la Tabla 6 podemos observar que el mayor Throughput se obtuvo para la implementación que considera el parámetro de velocidad y que éste tiene una variación muy pequeña comparado con el del parámetro de área, lo mismo ocurre con las celdas lógicas. 4.3 Comparación de Resultados Con el propósito de comparar los diferentes resultados obtenidos en este trabajo y los resultados presentados por otros investigadores, en la Tabla 7 se muestran en detalle los resultados presentados en diferentes plataformas de hardware y software. Desde la Tabla 7 podemos observar que las implementaciones realizadas en hardware presentan una ventaja significativa en el Throughput con respecto a los resultados obtenidos en las implementaciones realizadas en software. También se observa que la arquitectura Pipeline presenta un mayor Throughput que la arquitectura Iterativa. Con respecto a los resultados obtenidos en este trabajo se puede decir que son altamente satisfactorios, tanto para la arquitectura Iterativa como para la Pipeline. En realidad estos resultados son mejores debido a que usamos ciertas ventajas que presentan algunas transformaciones del algoritmo Rijndael para implementarlas en hardware, así como tambien hemos usado una mejor herramienta de síntesis y simulación (Quartus II de Altera) para dispositivos FPGAs. Figura 5: Resultado de Simulación de la Desencriptación para la Arquitectura Pipeline

9 Autor [1] Encriptación Desencriptación Throughput () CLs Throughput Plataforma () CLs Código VHDL sobre una FPGA Xilinx virtex XCV1000BG * [4] Código VHDL sobre una FPGA Altera EPF10K250AGC599-1 [5] Código VHDL sobre una FPGA Xilinx virtex XCV1000BG560-6 [6] * Código VHDL sobre un asic 0.5µm [7] Código VHDL sobre una FPGA Altera EPF10K250AGC599-1 [8] Código VHDL sobre una FPGA Altera EPF10K130EQC240-1 [10] Código C, trabajando en un Pentium Pro 200 [11] Código C, trabajando en un Celeron 850 ** Código VHDL sobre una FPGA Altera EPF10K250SBC * * 8243 Código VHDL sobre una FPGA Altera EP2A70B724C7 *Resultados obtenidos en arquitecturas Pipeline. **Resultados obtenidos en este trabajo. Tabla 7: Comparación de Resultados para Diferentes Implementaciones en Software y Hardware 5. CONCLUSIONES Y TRABAJO FUTURO Este trabajo presenta una descripción detallada del diseño de dos arquitecturas hardware para el algoritmo de encriptación Rijndael, las cuales fueron diseñadas usando dispositivos lógicos programables y el lenguaje VHDL. Las arquitecturas Iterativa y Pipeline fueron compiladas sobre los dispositivos EPF10K200SBC600-1 y EP2A70B724C7 respectivamente. En este caso, se debe tener en cuenta que las arquitecturas implementadas han sido realizadas en modo no realimentado, es decir, que solo se encripta un bloque de texto de 128 bits usando una clave de 128 bits. Es importante resaltar que diferentes resultados fueron obtenidos, los cuales son presentados en las siguientes conclusiones: Las implementaciones en hardware presentan una ventaja significativa en el Throughput con respecto a los resultados obtenidos en las implementaciones en software. La arquitectura Pipeline presenta un mayor Throughput que la arquitectura Iterativa debido a que la arquitectura Pipeline permite procesar bloques de texto plano en paralelo. Sin embargo, no es posible utilizar una arquitectura Pipeline para modos de operación realimentados, debido a que para el modo de operación realimentado no es posible comenzar a encriptar el siguiente bloque de texto hasta que la encriptación del bloque anterior se haya terminado. Estos modos de operación realimentados están siendo utilizados actualmente debido a que permiten alcanzar una mayor seguridad, pero si tenemos en cuenta la gran seguridad que ofrece el algoritmo Rijndael, no es tan necesario usar el modo realimentado. Existe una gran diferencia para los valores de los parámetros Throughput y Área en los procesos de encriptación y desencriptación para la arquitectura Pipeline. El proceso de desencriptación utiliza casi el doble de celdas lógicas que el proceso de encriptación, por esta razón el parámetro Throughput presenta una diferencia del 39% entre los dos procesos. Para la arquitectura Iterativa esta diferencia es del 21%. Los resultados obtenidos para el Throughput en las arquitecturas Iterativa y Pipeline superan a los presentados en la literatura. El área utilizada para la implementación de la arquitectura Pipeline es realmente poca si comparamos ésta con respecto al área obtenida por la arquitectura Iterativa. Con respecto al trabajo futuro, las principales tareas a realizar son: Realizar los diseños presentados usando la combinación de captura esquemática y VHDL, con lo cual se podrían alcanzar mejores resultados que los obtenidos usando solo el lenguaje VHDL. Extender el tamaño del bloque de clave a 192 y 256 bits. Sin embargo se debe tener en cuenta que para el caso de tamaños de clave de 256 bits el proceso es un poco mas complicado, ya que el algoritmo Rijndael realiza un proceso mas complejo en la generación de las subclaves, pero este cambio sería únicamente en el bloque SubKey (Generación de las Subclaves). Diseñar el hardware necesario para realizar el proceso de encriptación y desencriptación de un texto completo. Es decir, realizar la máquina de estados que permita coordinar y controlar la adquisición de los bloques de 128 bits del texto completo. Realizar una implementacion en hardware del algoritmo Rijndael para el modo realimentado, en este caso, se debe realizar una máquina de estados que permita realizar la operación XOR entre el texto encriptado y el nuevo texto plano. Finalmente, la principal tarea para el futuro es diseñar un criptoprocesador de alto desempeño para el algoritmo Rijndael.

10 6. BIBLIOGRAFÍA [1] A. Elbirt, W. Yip, B. Chetwynd, C. Paar, "An FPGA-Based Performance Evaluation of the AES Block Cipher Candidate Algorithm Finalists", cuments/aelbirtpaarieeetranvls.pdf [2] NIST. AES Round 2 Information, hms [3] NIST. FIPS-197, [4] P. Mroczkowski, Implementation of the block cipher Rijndael using Altera FPGA, ments/ pmroczkowski.pdf [5] K. Gaj y P. Chodowiec, Comparison of the hardware performance of the AES candidates using reconfigurable hardware, 3/papers/22-kgaj.pdf [6] NSA, Hardware Performance Simulations of Round 2 Advanced Encryption Standard Algorithms, A-AESfinalreport.pdf [7] M. Barcelos, A. Panato y R. Reis, Um IP Criptografia padrao Rijndael para projetos em FPGA, [8] V. Fisher, Realization of the Round 2 Candidates using Altera FPGA, nf3/papers/24-vfischer.pdf [9] lockciphers.html [10] B. Gladman,, AES Algorithm Efficiency, ology/aes [11] W. Dai, Speed Comparation of Popular CryptoAlgorithms, ml [12] G. Jácome-Calderón, Implementación en Hardware del Algoritmo Rijndael, Tesis de Pregrado, Escuela EIEE, Universidad del Valle, Cali, Colombia, 2003.