Implementación de SSH sobre un Sistema Auto-Reconfigurable

Implementación de SSH sobre un Sistema Auto-Reconfigurable

Iván González, Francisco J. Gómez-Arribas y Sergio López-Buedo

Escuela Politécnica Superior Universidad Autónoma de Madrid

28049 Madrid

{Ivan.Gonzalez, Francisco.Gomez, Sergio.Lopez-Buedo}@uam.es

Resumen

.

1. Introducción

La aceleración hardware de aplicaciones software es una metodología comúnmente empleada en computación de alto rendimiento, y permite que el rendimiento del sistema pueda ser mejorado considerablemente. La implementación de esta aceleración en hardware reconfigurable permite mejorar la flexibilidad del sistema: del mismo modo que un procesador puede cambiar entre diferentes tareas, varios bitstream pueden ser cargados en la FPGA. Además, desde la llegada de la familia Virtex, todas las FPGAs de Xilinx son parcialmente reconfigurables en tiempo de ejecución, lo que permite que el sistema pueda adaptarse completa y rápidamente a las necesidades del usuario.

Los dispositivos FPGA se han usado ampliamente para la aceleración de algoritmos de cifrado en diferentes aplicaciones de seguridad.

Sin embargo, los beneficios de emplear FPGAs no están únicamente limitados a la mejora del rendimiento [1], ya que la posibilidad de cambiar rápidamente los algoritmos de cifrado o los

parámetros empleados en el transcurso de la comunicación (como la clave de cifrado) es también importante.

Los protocolos de seguridad actuales separan la elección del algoritmo de cifrado del diseño del protocolo, por lo que los modernos sistemas de cifrado deben ser capaces de soportar varios algoritmos. Por ejemplo, IPSec (el estándar de seguridad en Internet) permite emplear diferentes algoritmos de cifrado. Los dispositivos CSoC (Configurable System-on-a-Chip) son candidatos adecuados para la implementación de sistemas de cifrado [2], porque combinan la velocidad del hardware con la flexibilidad del software ejecutado en procesadores de propósito general.

Además, proveen mejor seguridad que las soluciones software. Por otro lado, la reconfiguración parcial puede ser muy útil para estas aplicaciones. Por ejemplo, si un sistema tiene que soportar varios estándares de cifrado, y se emplea reconfiguración parcial en tiempo de ejecución, solo el coprocesador para el algoritmo seleccionado tendría que ser cargado en la FPGA.

Posteriormente, si ya no es necesario, podría ser eliminado del dispositivo y dejar espacio para el siguiente algoritmo.

En este trabajo se evalúan las posibilidades de los CSoCs para mejorar las aplicaciones de seguridad. El protocolo SSH se ha empleado como caso de estudio y ha sido acelerado empleando coprocesadores de cifrado específicos:

posteriormente a la fase de negociación, el coprocesador seleccionado es cargado empleando reconfiguración. El uso de reconfiguración parcial permite que no sea necesario implementar todos los algoritmos de cifrado en el dispositivo.

Este paper se encuentra organizado de la siguiente manera: la sección 2 describe los conocimientos sobre criptografía necesarios para entender este trabajo. La sección 3 presenta el

sistema MicroBlaze-uCLinux auto-reconfigurable.

La sección 4 discute la implementación de SSH y muestra los resultados obtenidos. Finalmente, las conclusiones se muestran en la sección 5.

2. Secure Shell (SSH)

SSH [3] permite conectarse a otras máquinas o trasmitir ficheros de forma segura a través de Internet u otros medios no seguros. Los algoritmos de cifrado se emplean para autentificar ambos lados de la conexión, cifrar todos los datos y proteger la integridad de los mismos.

Existen actualmente dos protocolos SSH:

SSH1 y SSH2. El protocolo SSH2 es una completa re-implementación del protocolo SSH1, cifrando diferentes partes del paquete, empleando diferentes algoritmos de intercambio de claves, etc., de modo que es considerado más seguro, y evita algunas conocidas vulnerabilidades de las implementaciones de SSH1.

El protocolo SSH se divide en tres partes principales: la negociación del algoritmo, la autentificación y el cifrado de los datos. La negociación del algoritmo es la responsable principal de determinar los algoritmos de cifrado, los algoritmos de compresión y los métodos de autentificación soportados y empleados entre el cliente y el servidor. La autentificación además, se encuentra dividida en dos partes: el intercambio de claves y la autentificación del usuario. El propósito del intercambio de claves es doble.

Primero, permite la autentificación del servidor por el cliente. Segundo, establece una clave compartida que es empleada como clave de sesión para el cifrado de todos los datos a transmitir entre las dos máquinas, empleando algoritmos de clave simétrica. Además, se genera un hash para la comprobación de la integridad de los datos.

2.1. Métodos de cifrado en SSH

SSH intenta proveer una fuerte seguridad, empleando métodos de criptografía, de forma transparente al usuario.

SSH1 ofrece cuatro algoritmos de cifrado [4, 5]: DES, 3DES, IDEA y Blowfish. SSH2 elimina el soporte para DES (algoritmo roto) e IDEA (problemas de patentes), y añade tres nuevos algoritmos: AES (Rinjdael), Twofish y CAST.

SSH1 emplea el algoritmo de autentificación

RSA, mientras que SSH2 lo ha cambiado por DSA. Estos cambios fueron realizados para eliminar los problemas de patentes, IDEA y RSA, e incrementar el nivel de seguridad en SSH2 empleando algoritmos más fuertes. Además, los algoritmos de hash MD5 y SHA se emplean para asegurar la integridad de los datos, en vez del tradicional CRC empleado por SSH1.

2.2. OpenSSH y OpenSSL

SSH1 está disponible de forma gratuita para los usuarios a pesar de contener tecnologías patentadas. Con la llegada de SSH2, la licencia fue restringida y ya no se distribuye de forma gratuita. La comunidad open source no contenta con este cambio de licencia, desarrolló su propia alternativa, OpenSSH [6].

OpenSSH es una versión gratuita del protocolo SSH que ofrece la misma funcionalidad que SSH2 pero sin restricciones derivadas de patentes. OpenSSH versión 2 y superiores soportan los dos protocolos de SSH, lo que permite a OpenSSH crear conexiones desde y hacia clientes que soporten uno o ambos protocolos.

OpenSSH hace uso de OpenSSL [7], que es un conjunto de herramientas para implementar los protocolos de red Secure Sockets Layer (SSL v2/v3), Transport Layer Security (TLS v1) [5] y otros estándares de criptografía requeridos por ambos.

3. Sistema Auto-Reconfigurable basado en MicroBlaze

MicroBlaze [8] es un procesador soft-core especialmente desarrollado para los dispositivos FPGA de Xilinx. Presenta un clásico diseño RISC (32 GPRs, Harvard, arquitectura LOAD/STORE, etc) y opera a una velocidad moderada (~100 Dhrystone MIPS). Se trata de un core parametrizable: la unidad barrel shifter, la unidad de división y las caches de datos e instrucciones son opcionales.

3.1. Coprocesadores en MicroBlaze

Existen dos alternativa para integrar cores IP a medida en un sistema MicroBlaze. El primero de ellos es el On-Chip Peripheral Bus (OPB), que forma parte del estándar de bus IBM Core Connect. La otra posibilidad es el Fast Simplex Link (FSL), usado para el envío y recepción de datos desde/hacia los registros a altas velocidades [9].

3.2. Auto-Reconfiguración en Spartan-3

Tradicionalmente, las herramientas de diseño automático carecen de soporte para reconfiguración en los flujos de diseño estándar.

Sin embargo, Xilinx ofrece una alternativa para soportar reconfiguración parcial: Modular Design junto con el modo RECONFIG de la restricción AREA_GROUP [10]. Además, se dispone de un componente llamado bus macro [10] para la interconexión entre los diferentes módulos del diseño. Desafortunadamente, este componente necesita de los buffers tri-estado, y no puede ser empleado en diseños sobre Spartan-3. Sin embargo, el concepto de bus macro puede ser extendido a otros componentes de la FPGA, como se indica en [11], siendo posible desarrollar bus macros usando LUTs [12].

CE_B CLK DATA

CONFIG.

FLASH

MODULO COPROCESSOR

BUS MACROS

GPIO RECONFIG.

SELECTMAP

MODULO MICROBLAZE

SPARTAN-3 FPGA

Figura 1. Plataforma auto-reconfigurable basada en Spartan-3

El sistema desarrollado incluye dos módulos (figura 1): el primero está compuesto por MicroBlaze y sus periféricos, y se encuentra localizado en la parte izquierda de la FPGA. El segundo modulo es el coprocesador, colocado en la parte derecha del dispositivo.

Modular Design se ha empleado para todos los pasos, pero la última fase, Final Assembly, no ha podido ser completada debido a diferentes problemas encontrados en las herramientas de

Xilinx. Como solución a este inconveniente, se ha desarrollado un script en Perl que trabaja sobre los ficheros XDL de los diferentes módulos implementados [12]. Finalmente, para disponer de un sistema auto-reconfigurable fue necesario emplear un circuito externo, que conecta un GPIO del procesador MicroBlaze al puerto de configuración. Un diagrama simplificado de este circuito se muestra en la figura 1.

3.3. uCLinux en MicroBlaze

uCLinux [13] es una adaptación de Linux para procesadores que carecen de unidad de manejo de memoria (MMU - Memory Management Unit). La principal implicación de la ausencia de MMU es que no existe protección de memoria (los procesos pueden escribir en cualquier posición de memoria) y que no existe memoria virtual (swapping, etc).

Sin embargo, para la mayoría de aplicaciones de usuario la única limitación es que la llamada del sistema fork() no se encuentra disponible, y es necesario emplear vfork().

Existen varias adaptaciones de uCLinux para procesadores sin MMU, incluidos los procesadores ColdFire, NEC v850, y el procesador MicroBlaze empleado en este trabajo.

La versión actual se basa en el kernel de Linux 2.4.20, pero ya existen trabajos activos para adaptar los kernels 2.5/2.6.

4. Implementación de SSH

La implementación open source de SSH disponible en la distribución uCLinux, OpenSSH, ha sido empleada como base para este trabajo.

Sobre ella, se han realizado modificaciones para permitir que los diferentes algoritmos de cifrado puedan hacer uso de los coprocesadores hardware a través de la interfaz FSL. Inicialmente, se han seleccionado dos algoritmos simétricos para ser ejecutados en hardware: el algoritmo por defecto AES128-CBC y el algoritmo alternativo 3DES- CBC. En cualquier caso, los mismos cambios se pueden realizar para el resto de los algoritmos, incluidos los algoritmos de hash usados para la integridad de datos y los algoritmos asimétricos para el intercambio de claves.

Para finalizar, una última modificación en OpenSSH permite a la aplicación reconfigurar la

FPGA con el coprocesador del algoritmo seleccionado durante la etapa de negociación.

4.1. Plataforma de referencia

El sistema MicroBlaze ha sido implementado sobre la plataforma Spartan-3 Development Board de Avnet. La única modificación realizada sobre esta plataforma ha sido añadir la conexión externa para auto-reconfiguración. El sistema MicroBlaze incluye una caché de datos y otra de instrucciones de 8 KB, un controlador SDRAM, una MAC Ethernet, un timer, un controlador de interrupciones, una UART como consola de E/S y tres GPIOs: uno para el manejo de los leds y switches disponibles en la placa, otro para la auto- reconfiguración, y un tercero para resetear el coprocesador. El último GPIO es necesario para resetear la nueva lógica insertada, ya que la señal global de set/reset (GSR) no puede ser empleada porque se inicializaría el procesador MicroBlaze que está ejecutando la aplicación. Esta señal se activa cuando comienza el proceso de reconfiguración, y se mantiene hasta que el proceso termina, asegurando que la lógica se inicia en un estado conocido.

El sistema final fue implementado en un dispositivo XC3S2000FG676-4C operando a 65 MHz. La tabla 1 muestra los recursos lógicos empleados por los diferentes diseños: el sistema MicroBlaze y los diferentes coprocesadores de cifrado (figura 2).

FPGA

Slices LUTs FF / Latches

18x18 Mult BRAM Sistema

MicroBlaze 4198 4809 3618 3 20 Coproc.

AES 4326 4632 1802 0 0 Coproc.

3DES 5424 4493 5825 0 0 Tabla 1. Uso de recursos lógicos por los diferentes

módulos.

Cada coprocesador ha sido implementado con la misma interfaz: un link FSL maestro para recibir las claves (SSH2 emplea diferentes claves para cada operación), y dos pares de links FSL maestro/esclavo para el envío y recepción de los datos. Para seleccionar el modo de operación (cifrado o descifrado) se ha empleado el bit de control del link FSL. Todos los links FSL

presentan 32 bits de ancho y una FIFO de 16 palabras.

Figura 2. Sistemas MicroBlaze con diferente coprocesador.

Los diferentes algoritmos implementados en hardware usan la configuración bloque/clave definida por el estándar. En particular, AES fue implementado como AES128, emplea una clave de 128 bits para el cifrado de un bloque de datos de 128 bits, y 3DES cifra un bloque de 64 bits con una clave de 192 bits.

4.2. Librería OpenSSL en hardware

Para adaptar OpenSSH para el uso de los coprocesadores de cifrado fue necesario modificar la librería OpenSSL, de modo que las nuevas funciones de cifrado operasen sobre el hardware.

Los cambios sobre la librería OpenSSL se encuentran relacionados con las diferentes implementaciones de los algoritmos, de modo que los algoritmos AES y 3DES incluyen ahora funciones hardware para el cifrado, descifrado y manejo de las claves empleando la interfaz FSL.

Este manejo ha sido añadido en las funciones adecuadas de la librería, reemplazando de forma transparente al cifrado y descifrado software.

4.3. Reconfiguración en OpenSSH

Después de los cambios sobre las funciones de los diferentes algoritmos, es necesario añadir las modificaciones que permitan la reconfiguración del coprocesador en función del algoritmo seleccionado.

OpenSSH incluye una interfaz con la librería OpenSSL donde se inicializan los algoritmos negociados previamente, y que serán empleados durante la comunicación segura. Esta interfaz ha sido modificada para realizar una llamada a la función que realiza la reconfiguración parcial del coprocesador. En particular, esta función lee el bitstream parcial del sistema de ficheros y lo envía a través del GPIO conectado a la interfaz de configuración.

El código añadido chequea si el algoritmo seleccionado se encuentra disponible como coprocesador hardware, y posteriormente, reconfigura la FPGA con el coprocesador adecuado. Es importante comprobar que se emplea el mismo algoritmo para cifrado y descifrado, ya que SSH2 podría emplear un algoritmo diferente para cada operación.

4.4. Transferencia de ficheros

Posteriormente a las modificaciones presentadas con anterioridad, fue posible conectar con el servidor SSH e iniciar una sesión remota. Este primer paso permite comprobar que la funcionalidad de la aplicación no ha sido modificada tras los cambios.

Para evaluar la mejora debido al uso de coprocesadores hardware, se propone medir la velocidad de transferencia al copiar un conjunto de ficheros a través de un canal seguro. La aplicación scp (Secure Copy) se ha seleccionado para este experimento. Secure Copy permite la copia de ficheros entre sistemas mediante la transferencia segura de los datos, usando el protocolo SSH. Esta aplicación es adecuada para estos experimentos porque durante el proceso de copia se muestra el tiempo empleado y el rendimiento final para cada fichero. El experimento se llevó a cabo conectando el sistema

MicroBlaze a una red LAN interna de 10 Mbps con un número reducido de maquinas, incluido el servidor SSH, con el objetivo de minimizar el impacto del tráfico en la red.

La tabla 2 muestra los resultados obtenidos para las diferentes implementaciones de SSH (SW y HW) y los algoritmos empleados. Estos resultados prueban que el algoritmo AES es más eficiente que el algoritmo 3DES cuando ambos se ejecutan en software. En cambio, si se emplean los coprocesadores hardware, se obtiene un rendimiento similar para ambos algoritmos.

Además, la mejora es dos veces superior en el mejor de los casos (3DES). Sin embargo, el rendimiento obtenido en la transferencia de ficheros mediante SSH es peor que el protocolo de transferencia de ficheros tradicional (FTP). Esto se debe principalmente a la sobrecarga que supone el algoritmo de hash, en este caso el algoritmo MD5, que se ejecuta en software. Es importante tener en cuenta que en este trabajo únicamente se han acelerado los algoritmos de cifrado, lo que supone una pequeña parte de la complejidad del protocolo SSH.

Protocolo Cripto.

Alg.

Fich. 1 0,3 KB

Fich. 2 2,4 KB

Fich. 3 8,2 KB AES 27,8 48,1 52,7 SSH

Software 3DES 16,7 26,6 30,3 AES 33,2 60,4 66,4 SSH

Hardware 3DES 32,0 60,3 67,7 FTP None 877,3 696,1 683,2 Tabla 2. Velocidad de transferencia en Kbytes/seg.

4.5. Ventajas de la reconfiguración parcial en SSH

La reconfiguración parcial de coprocesadores hardware permite reducir el área necesaria, ya que no es necesario disponer de todos los algoritmos de cifrado, y contribuye con otras interesantes ventajas [14] como el cambio en tiempo de ejecución del algoritmo, la posibilidad de actualizar el hardware y la capacidad de modificar el algoritmo sin re-implementar el diseño.

En nuestro sistema auto-reconfigurable, los diferentes bitstream parciales se encuentran almacenados en un directorio de una computadora, que los comporte a través del protocolo de red NFS. El sistema MicroBlaze

monta ese directorio como parte de su sistema de ficheros, y obtiene los diferentes coprocesadores de él, usando una idea similar a [13]. Si se desarrolla una nueva versión de los coprocesadores, el sistema puede hacer uso de ellos sin necesidad de parar la ejecución, ya que el nuevo bitstream con las nuevas mejoras se encuentra disponible de forma transparente.

5. Conclusiones y trabajo futuro

Las plataformas CSoC que incluyen procesadores y lógica reconfigurable son buenas soluciones para acelerar la ejecución de aplicaciones, ya que permiten implementar las partes del código críticas como coprocesadores específicos. Un ejemplo de ello son las aplicaciones de criptografía. Estas aplicaciones se benefician del uso de aceleradores hardware, pero presentan un serio problema cuando se emplean varios algoritmos: la cantidad de recursos lógicos necesarios para disponer de todos los algoritmos.

En este trabajo se muestra que la auto- reconfiguración puede ser muy útil para cambiar el coprocesador que emplean las aplicaciones reales de seguridad, como SSH. Mientras que la aceleración hardware proporciona la mejora en el rendimiento, la capacidad de reconfiguración permite un ahorro de área y la posibilidad de actualización en tiempo de ejecución del coprocesador. Los resultados muestran que las plataformas auto-reconfigurables son muy apropiadas para la implementación de las actuales aplicaciones que emplean los modernos protocolos de seguridad con selección dinámica de algoritmos.

Como trabajo futuro se continuará con la aceleración de todos los algoritmos que intervienen en el protocolo SSH. Esto supondrá disponer de más coprocesadores reconfigurables para acelerar los algoritmos de integridad de datos y los algoritmos de clave pública. El objetivo es obtener un rendimiento similar al protocolo FTP.

Finalmente, la reconfiguración parcial será llevada a nivel de sistema operativo para dar soporte a múltiples tareas reconfigurables.

Referencias

[1] A. Dandalis and V. K. Prassana, “An adaptative Cryptographic Engine for IPSec

Architectures”, Proc. IEEE Symposium on FCCM, April 2000, pp. 132-141.

[2] Ray C.C. Cheung, Wayne Luk and Peter Y.K. Cheung, “Reconfigurable Elliptic Curve Cryptosystems on a Chip”, Proc. of DATE’05, 2005, pp. 24-29.

[3] T. Ylonen, "SSH -- Secure Login Connections over the Internet", Proc. 6th USENIX Security Symposium, 1996, pp. 37- 42.

[4] B. Schneier, Applied Cryptography, John Wiley & Sons, 1996, 2nd edition.

[5] William Stallings, Cryptography and Network Security: Principles and Practice, Prentice Hall, August 2002, 3rd edition.

[6] OpenSSH Project. Home page:

http://www.openssh.com/

[7] OpenSSL Project. Home page:

http://www.openssl.org/

[8] Xilinx Inc., “MicroBlaze Processor Reference Guide”, 2004.

[9] Xilinx Inc., "Connecting Customized IP to the MicroBlaze Soft Processor Using the Fast Simplex Link (FSL)", Application Note 529, 2004.

[10] Xilinx Inc., “Two Flows for Partial Reconfiguration: Module Based or Difference Based”, Application Note 290, 2004.

[11] M. Dyer, C. Plessl, and M. Platzner,

"Partially Reconfigurable Cores for Xilinx Virtex", LNCS 2438, pp. 292-301.

[12] I. Gonzalez, E. Aguayo y S. Lopez-Buedo,

“Sistemas Embebidos Auto-Reconfigurables sobre Spartan-3”, JCRA 2005, Granada, España, pp. 79-84.

[13] J. A. Williams and N. W. Bergmann,

“Embedded Linux as a platform for dynamically self-reconfiguring systems-on- chip”, in Proc. ERSA’04, Las Vegas, Nevada, 2004.

[14] T. Wollinger, J. Guajardo and C. Paar:

“Security on FPGAs: state of the art implementations and attacks”, ACM Trans.

Embedded Comput. Syst., 2004, 3, (3), pp.

3045–3048.