UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍADEPARTAMENTO DE ELECTRÓNICA

" Repositorio Electrónico para Certificados Digitales "

Memoria presentada por: Sr. Ricardo Palumbo B.como requisito parcial para optar al título de

Ingeniero Civil en ElectrónicaMención Computadores

Profesor Guía: Sr. Leopoldo Silva B.

Agosto de 2005

RESUMEN

Se diseña e implementa un dispositivo electrónico que permita mantener certificados digitales, garantizando su uso solo por el verdadero dueño. Se estudia los certificados digitales, los principios teóricos que sustentan su empleo para asegurar las comunicaciones, y el modo en que son empleados por las aplicaciones. Teniendo en cuenta los medios modernos para conectar periféricos a los computadores personales - además de las ventajas para el usuario, se estudia la interfaz denominada Bus Serie Universal (USB). Se estudian criterios para la selección de un microcontrolador que soporte el diseño lógico del repositorio. Se estudia el funcionamiento de los sensores biométricos de huellas dactilares, para su incorporación en el diseño, y obtener el máximo grado de seguridad física que requiere el almacenamiento de certificados. Por último, se implementa el repositorio, se prueba el cumplimento del estándar USB, y se prueba su uso en aplicaciones de correo electrónico y navegadores.

2

ÍNDICE DE CONTENIDO

—1—

1. INTRODUCCIÓN..........................................................................................................................................7

—2—

2. LOS CERTIFICADOS DIGITALES...........................................................................................................82.1 Historia..........................................................................................................................................................82.2 Criptografía de Llave Pública (Llave Asimétrica)....................................................................................92.2.1 Funciones de Ida........................................................................................................................................92.2.2 Algoritmos de Llave Pública.....................................................................................................................92.2.3 RSA...........................................................................................................................................................102.2.4 Intercambio de llaves de Diffie-Hellman...............................................................................................102.2.5 EL Gamal.................................................................................................................................................112.3 Firmas Digitales..........................................................................................................................................122.4 Certificados Digitales.................................................................................................................................122.5 Infraestructura de Llave Pública (PKI)...................................................................................................132.6 El estándar X.509........................................................................................................................................142.7 Notación Sintáctica Abstracta Uno...........................................................................................................14

—3—

3. 1 Definición de requerimientos del producto.............................................................................................153. DISEÑO DEL SISTEMA.............................................................................................................................153.1. 2 Definición de requerimientos funcionales............................................................................................163.1. 3 Selección de procesador.........................................................................................................................163.1. 4 Plataforma de desarrollo.......................................................................................................................163.1. 5 Requerimientos de hardware y firmware............................................................................................163.2 Diseño del hardware...................................................................................................................................163.2. 1 Diseño simple o multi chip.....................................................................................................................163.2. 2 La memoria.............................................................................................................................................163.2. 3 La memoria RAM...................................................................................................................................163.2. 4 Entrada y salida......................................................................................................................................163.2. 5 Periféricos (biometría)...........................................................................................................................163.2. 6 Carga del bus de datos...........................................................................................................................163.2. 7 Memoria no volátil.................................................................................................................................163.2. 8 El bus I2C.................................................................................................................................................163.2. 9 Programación en circuito.......................................................................................................................163.2.10 Periféricos internos................................................................................................................................163.2.11 Simplificaciones del diseño...................................................................................................................163.2.12 Protección contra estática.....................................................................................................................163.2.13 Relojes para el procesador....................................................................................................................163.3 Diseño del firmware...................................................................................................................................173.3. 1 Diagrama de flujo de datos....................................................................................................................173.3. 2 Diagrama de estado................................................................................................................................173.3. 3 Pseudocódigo...........................................................................................................................................173.3. 4 Arquitectura del firmware.....................................................................................................................173.3. 5 Lenguaje y herramienta de desarrollo.................................................................................................173.3. 6 Hardware del microprocesador............................................................................................................173.7 Integración..................................................................................................................................................173.8 Verificación.................................................................................................................................................17

3

—4—

4. LA IMPLEMENTACIÓN...........................................................................................................................18

—5—

5. PRUEBAS Y MEDICIONES......................................................................................................................18

—6—

6. RESULTADOS Y CONCLUSIONES........................................................................................................19

—A—

A. El Bus Serie Universal................................................................................................................................20A. 1. Introducción.............................................................................................................................................20A. 2. Los Conectores.........................................................................................................................................23A. 3. Especificación Eléctrica..........................................................................................................................24A. 4. Identificación de la Velocidad................................................................................................................24A. 5. Alimentación (Vbus)..................................................................................................................................26A. 6. Intensidad de Suspensión........................................................................................................................26A. 7. Ingreso al Modo Suspendido..................................................................................................................27A. 8. Tasas de Señalización de Datos..............................................................................................................27A. 9. Protocolos USB........................................................................................................................................28A.10. Campos Comunes de un paquete USB.................................................................................................28A.11. Tipos de Paquetes USB...........................................................................................................................29A.12. Las Funciones del bus USB....................................................................................................................31A.13. Endpoints.................................................................................................................................................32A.14. Tuberías...................................................................................................................................................32A.15. Transferencias de Control.....................................................................................................................32A.16. Transferencias de Interrupción.............................................................................................................36A.17. Transferencias Isócronas.......................................................................................................................37A.18. Transferencias Masivas..........................................................................................................................38A.19. Administración del Ancho de Banda....................................................................................................40A.20. Los Descriptores USB.............................................................................................................................40A.21. Estructura de Descriptores USB...........................................................................................................42A.22. Descriptores de Dispositivo....................................................................................................................42A.23. Descriptores de Configuración..............................................................................................................43A.24. Descriptores de Interfaz.........................................................................................................................45A.25. Descriptores de Endpoint.......................................................................................................................46A.26. Descriptores de Strings..........................................................................................................................47A.27. Paquetes de Ajuste..................................................................................................................................47A.28. Requerimientos Estándar......................................................................................................................49A.29. Requerimientos Estándar de Dispositivo.............................................................................................49A.30. Requerimientos Estándar de Interfaz...................................................................................................50A.31. Requerimientos Estándar de Endpoint................................................................................................51A.32. Proceso de Enumeración........................................................................................................................51

—B—

B. Sensores Biométricos..................................................................................................................................53B. 1 Introducción..............................................................................................................................................53B. 2 Rendimiento de los sistemas biométricos................................................................................................55B. 3 Biometría versus Contraseña...................................................................................................................56B. 4 Las huellas dactilares................................................................................................................................56B. 5 Anatomía de la huella dactilar.................................................................................................................57B. 6 Enrolado y verificación............................................................................................................................58

—C—

C. El Modelo de Controladores de Windows................................................................................................60

4

—D—

D. Proveedor de Servicio Criptográfico de Windows..................................................................................61

5

ÍNDICE DE FIGURAS

6

1. INTRODUCCIÓN

Los avances en las redes de comunicaciones que permiten, incluso, la conexión de computadores personales, o equipos de menor tamaño como asistentes personales, en forma inalámbrica a la red Internet, los mensajes de correo que se envían principalmente a través de estas redes, actualmente se comunican imágenes y sonidos. Todos estos desarrollos muestran que el mundo tiende al uso de la tecnología digital para funcionar más eficientemente.Una parte importante de nuestro mundo de papel son las transacciones comerciales, y éstas rápidamente se están integrando al mundo digital, sin embargo esto no es posible sin tener en cuenta los resguardos que existen en el mundo de papel, por suerte se han identificado los conceptos básicos que permiten que esta integración sea segura, desde el punto de vista de la información, y se ha constituido una colección de servicios conocidos como “Infraestructura de Clave Pública (o PKI)”, que, por ejemplo, permite a un contribuyente realizar su declaración, y pago, de impuestos desde la comodidad de su hogar sin que un intruso pueda alterar sus datos.Un elemento importante de estas PKI, y que el usuario debe mantener bien resguardado, es el certificado digital que otorga la autoridad certificadora.Este trabajo, entonces, trata del diseño e implementación de un dispositivo electrónico que permita mantener certificados digitales, garantizando su uso solo por el verdadero dueño.

7

2. LOS CERTIFICADOS DIGITALES

2.1 Historia

La criptografía es una ciencia muy antigua, data de la época de los egipcios por el año 3000 A.C., sin embargo el ejemplo más conocido es de cerca de los años 50 A.C. Julio Cesar, el emperador de Roma, usó uno cifrado de sustitución para enviar mensajes a Cícero. En este cifrado, las letras del alfabeto son substituidas por otras letras del mismo alfabeto. Como se emplea solo un alfabeto, este cifrado es una substitución mono-alfabética. Este particular cifrado consistió en desplazar el alfabeto tres lugares a la izquierda y luego sustituir las letras del mensaje. En general se describe como:

Zi = Cn (Pi)

Donde Zi son los caracteres del texto cifrado, Cn es una substitución mono-alfabética, n es el número de letras desplazadas, y Pi son los caracteres del texto plano.

Así, el mensaje ATACAR AL AMANECER, quedaría cifrado en C3 como:

DWDFDQ DO DPDQHFHQ

Criptografía deriva de las palabras griegas kryptos, que significa esconder, y graphein, que significa escribir, es decir, escritura escondida. La criptografía se ha usada a través de los años para mandar mensajes confidenciales cuyo propósito es que lo puedan entender sólo las personas autorizadas.

Desde sus inicios, la criptografía ha sido una herramienta muy usada en el ambiente militar, en la segunda gran guerra tuvo un papel determinante, una de las máquinas de cifrado que tuvo gran popularidad se llamó ENIGMA. Al terminar la guerra las agencias de seguridad de las grandes potencias invirtieron muchos recursos para su investigación. La criptografía como se conoce hoy surgió con la invención de la computadora.

La criptografía actual se inicia en la segunda mitad de la década de los años 70. Pero es hasta la invención del sistema DES (Data Encryption Standard) en 1976 que se da a conocer más ampliamente, principalmente en el mundo industrial y comercial. Luego con el sistema RSA (Rivest, Shamir, Adleman) en 1978, se abre el comienzo de la criptografía a muchas aplicaciones: en transmisiones militares, en transacciones financieras, en comunicaciones satelitales, en redes de computadores, en líneas telefónicas, en transmisiones de televisión, etc.

La criptografía se divide en dos grandes ramas, la criptografía de llave privada, o simétrica, y la criptografía de llave pública, o asimétrica. DES pertenece al primer grupo y RSA al segundo [1]. Los aspectos más importantes que resuelve la criptografía actual son: la privacidad, la integridad, la autenticidad y el no repudio.

La privacidad, se refiere a que la información sólo pueda ser leída por personas autorizadas, para se emplea criptografía simétrica.

La integridad, se refiere a que la información no pueda ser alterada en el transcurso de ser enviada, para esto se emplean técnicas de hashing.

La autenticidad, se refiere a poder confirmar que el mensaje recibido haya sido mandado por quien dice lo mandó, la técnica empleada es la firma digital.

8

El no repudio, se refiere a que no se pueda negar la autoría de un mensaje enviado, para esto se complementa lo anterior con un buen manejo de las claves y la legislación adecuada.

2.2 Criptografía de Llave Pública (Llave Asimétrica)

A diferencia de los sistemas de llave secreta, los sistemas de llave pública emplean dos llaves, la llave pública y la llave privada. La llave pública se entrega a cualquiera que desee cifrar y enviar un mensaje. La llave privada es usada para descifrar el mensaje. Así, la necesidad de intercambiar llaves secretas es eliminada. Es importante notar los siguientes aspectos:

. La llave pública no puede descifrar el mensaje que cifra.

. Idealmente, la llave privada no puede ser derivada a partir de la llave pública.

. Un mensaje que es cifrado con una de las llaves puede ser descifrado con la otra.

. La llave privada es mantenida privada.

Si Kp es la llave pública y Ks es la llave privada, el proceso es:

C = Kp(P) yP = Ks(C)

Donde C es el texto cifrado y P es el texto plano. También, en el proceso inverso se cumple que:

C = Ks(P) yP = Kp(C)

2.2.1 Funciones de Ida

La criptografía de llave pública es posible por medio de la aplicación de una función de ida. Una función de ida es una función que es fácil de computar en una dirección, pero es difícil de computar en la dirección opuesta. Es decir, si y = f(x), resulta fácil computar y dado x, pero resulta muy difícil computar x dado y.

En el contexto de la criptografía de llave pública, es muy difícil calcular la llave privada a partir de la llave pública, a menos que se conozca una trampa.

2.2.2 Algoritmos de Llave Pública

Varios algoritmos de llave pública han sido desarrollados. Algunos de éstos son aplicables a firmas digitales, encriptación, o ambos. Dado que hay más cálculo asociado con la criptografía de llave pública, resultan unas 1.000 a 10.000 veces más lentos que los de criptografía de llave secreta. Esto ha evolucionado hacia los sistemas híbridos, donde se emplea la criptografía de clave pública para distribuir con seguridad las llaves secretas usadas en los sistemas de llave simétrica.

Algunos de los más importantes algoritmos de llave pública que se han desarrollado incluyen el protocolo de intercambio de llaves de Diffie-Hellman, RSA, El Gamal, y Curva Elíptica.

9

2.2.3 RSA

RSA es derivado de los nombres de sus inventores, Rivest, Shamir y Addleman [*2]. Este algoritmo se basa en la dificultad de factorizar un número, N, que es el resultado de multiplicar dos números primos grandes. Estos números primos pueden ser de 200 dígitos cada uno. Así, el problema de obtener la llave privada a partir de la llave pública es una difícil función de ida, equivalente a encontrar los factores primos de N.

En RSA, las llaves pública y privada son generadas de la siguiente manera:

1. Escoger dos números primos grandes x, y. Computar N = xy.2. Escoger p tal que el mcd de p y (x-)(y-1) es 1, es decir p es primo a (x-1)(y-1).3. Encontrar s tal que ps = 1 (módulo (x-1)(y-1)).

Entonces, la llave privada es (s,N) y la llave pública es (p,N). El texto plano, M, es cifrado como:

C = Mp módulo N

y es descifrado, para recuperar el texto plano, como:

M = Cs módulo N.

Ejemplo:

1. x = 5, y = 7, entonces N = 35.2. (x-1)(y-1) = 4 x 6 = 24, se escoge p = 5.3. s = 5, ya que ps = 25 = 1 (módulo 24).

Aplicando este ejemplo al cifrado del mensaje 4, tenemos:

Ep(4) = 45 (módulo 35)= 9

Ds(9) = 95 (módulo 35)= 4

Normalmente, el texto plano es dividido en bloques de igual largo, pero con menos dígitos que N, y cada bloque es cifrado y descifrado como se mostró.

RSA puede ser usado para cifrado, intercambio de llaves, y firma digital.

2.2.4 Intercambio de llaves de Diffie-Hellman

El intercambio de llaves de Diffie-Hellman es un método donde los sujetos intercambian llaves secretas por un medio no seguro sin exponerlas. Este método se encuentra discutido en [*3]. El método permite a dos usuarios intercambiar llaves secretas por un medio inseguro sin tener una llave de sesión adicional. Tiene dos parámetros de sistema, p y g. Ambos parámetros son públicos y pueden ser usados por todos los usuarios del sistema. El parámetro p es un número primo y el parámetro g (llamado el generador) es un entero menor que p, que tiene la siguiente propiedad: Para cada n entre 1 y p-1 inclusive, existe una potencia k de g tal que n = gk mod p.

10

Por ejemplo, dados los siguientes parámetros públicos:p = número primo.g = número generador.

y = gx mod p, función de generación.

Para establecer una llave secreta común, el usuario A escoge un número aleatorio x(A) en [0, p-1], y el usuario B escoge un número aleatorio x(B) en [0, p-1]. El usuario A calcula:

YA = gx(A) mod p

y el usuario B calcula:

YB = gx(B) mod p

Ahora el usuario A puede enviar YA al usuario B, y el usuario B puede enviar YB a al usuario A. Conociendo su valor privado x(A), el usuario A calcula:

KA = (YB) x(A) = g x(B)*x(A) mod p

Igualmente, conociendo su valor privado, el usuario B calcula:

KB = (YA) x(B) = g x(A)*x(B) mod p

Y, dado que KA = KB, los usuarios A y B han, con seguridad, intercambiado una llave secreta.

2.2.5 EL Gamal

El concepto Diffie-Hellman fue extendido por el Dr. T. EL Gamal para que sea usado en cifrado y firma digital [*4].

El sistema El Gamal es un sistema de llave pública no patentado que se basa en logaritmos discretos. El siguiente ejemplo ilustra el cifrado con El Gamal:

Dado un número primo, p, y un entero, g, usuario A emplea su llave privada, a, para calcular su llave pública como:

ya = ga mod p

Para que usuario B envíe un mensaje M a usuario A, procede de la siguiente forma:

. Usuario B genera un número aleatorio b < p

. Usuario B calcula: Yb = gb mod p, yYm = M xor Yab = M xor gab mod p.

. Usuario B envía: Yb, Ym

. Usuario A calcula: Yba = gab mod p

Por lo tanto, M = Yba xor Ym = gab mod p xor M xor gab mod p.

11

2.3 Firmas Digitales

El propósito de la firma digital es detectar modificaciones no autorizadas de los datos, autentificar la identidad del firmante, y no permitir el repudio. Estas funciones son logradas por medio de la generación de un bloque de datos que es usualmente menor que el tamaño de los datos originales. Este bloque de datos de menor tamaño está limitado al bloque de datos original y a la identidad del emisor.

Para generar una firma digital, se pasa el mensaje por una función hash de ida. Esta función hash genera una salida de tamaño fijo a partir de una entrada de tamaño variable. La salida de la función hash es llamada recopilación del mensaje. La recopilación del mensaje es derivada únicamente a partir del archivo de entrada y, si el algoritmo de hash es fuerte, esta recopilación tiene las siguientes características:

. La función hash es considerada de ida porque el mensaje original no puede ser creado a partir de la recopilación.. Dos mensajes no tienen la misma recopilación.. Dado un mensaje y su correspondiente recopilación, no es posible encontrar otro mensaje con la misma recopilación. La recopilación del mensaje es calculada utilizando todo su contenido.

Después que la recopilación del mensaje es calculada, es cifrada con la llave privada del emisor. Esta recopilación cifrada es, entonces, anexada al mensaje original y es enviado al receptor. El receptor, descifra la recopilación usando la llave pública del emisor. Si esta llave pública abre la recopilación del mensaje y es la verdadera llave pública del emisor, se verifica el emisor. La verificación ocurre porque la llave pública del emisor es la única que puede descifrar la recopilación cifrada con la llave privada del emisor. Entonces, el receptor puede computar la recopilación del mensaje recibido usando la misma función que el emisor. Si esta recopilación calculada es idéntica a la enviada junto con en el mensaje como parte de la firma, el mensaje no ha sido modificado.

Una de las funciones mas conocidas es MD5, este algoritmo fue desarrollado por Ronald Rives en 1991. MD5 toma un mensaje de largo arbitrario y genera recopilaciones de 128 bits. En MD5, el mensaje es procesado en bloques de 512 bits en cuatro diferentes rotaciones.

2.4 Certificados Digitales

Una situación que puede comprometer un sistema de llave pública es cuando un individuo A envía una llave pública bajo el nombre de otro individuo B. En este escenario, las personas que están usando esta llave pública para cifrar mensajes para el individuo B estarán, en realidad, enviando mensaje para el individuo A. Ya que el individuo A tiene la llave privada que corresponde a la llave pública distribuida, el individuo A puede descifrar todos los mensaje que van dirigidos al individuo B.

Para evitar este tipo de ataque, se emplea un proceso de certificación para ligar a los individuos con sus llaves públicas. Una Autoridad Certificadora (CA) actúa como notario verificando la identidad de la personas y emitiendo un certificado que garantiza la llave pública del individuo nombrado. Este agente certificador firma el certificado con su propia llave privada. Por lo tanto, el individuo es verificado como en emisor si su clave

12

pública abre los datos. El certificado contiene el nombre del sujeto, la llave pública del sujeto, el nombre de la autoridad certificadora, y el período de validez del certificado. Para verificar la firma del CA, su llave pública debe tener certificación cruzada con otro CA. El estándar X.509 define el formato para los certificados de llave pública. Este certificado es, entonces, enviado a un repositorio, que mantiene los certificados, y las listas de revocación de certificados (CRLs) que denuncian los certificados revocados. La Figura 2.N. ilustra el uso de los certificados digitales en una transacción entre la entidad subscriptora y una parte transadora.

Figura 2.1. Una transacción con certificados digitales.

2.5 Infraestructura de Llave Pública (PKI)

La integración de firmas digitales y certificados, y los demás servicios requeridos para el comercio electrónico son llamados Infraestructura de Llave Pública. Estos servicios proveen integridad, control de acceso, confidencialidad, autentificación, y no repudio en las transacciones electrónicas. Las PKI incluyen los siguientes elementos:

. Certificados Digitales

. Autoridad Certificadora

. Políticas y Procedimientos

. Revocación de Certificados

. Soporte de No Repudio

. Estampado de Tiempo

. Protocolo LDAP (Lightweight Directory Access Protocol)

. Aplicaciones habilitadas para seguridad

. Certificación cruzada

El protocolo LDAP provee un formato estándar para acceder a los directorios de certificados. Estos directorios son almacenados en servidores LDAP en redes, y los servidores en estas redes proveen, a las organizaciones, con llaves públicas y los correspondientes certificados X.509. Un directorio contiene información tal como el nombre del individuo, dirección, números telefónicos, y certificados de llave pública. LDAP permite a un usuario explorar estos directorios por Internet. Una serie de estándares bajo la designación X.500 define los protocolos y modelos de información

13

para estos servicios de directorio que son independientes de plataformas y otras entidades relacionadas.

El principal interés relativo a los servidores LDAP son la disponibilidad y la integridad. Por ejemplo, ataques para denegación de servicio en un servidor LDAP puede prevenir el acceso a las listas de revocación de certificados, permitiendo, así, el uso de certificados revocados.

2.6 El estándar X.509

La primera versión apareció el año 1988 y se publicó como el formato X.509v1, siendo la propuesta más antigua para infraestructura de clave pública a nivel mundial. Esto, junto con su estandarización ISO/ITU, han hecho de X.509 el PKI más ampliamente utilizado.

Más tarde se amplió, en 1993 por la versión 2, en dos campos que identifican en forma única al emisor y al propietario. La versión 3 [rfc2459] amplió, nuevamente, la funcionalidad del estándar X.509 permitiendo a los generadores de certificados incluir sus propias extensiones para contener información específica a un entorno de operación. El formato del certificado X.509 versión 3 se ilustra en la siguiente figura.

Figura 2.2. Estructura del certificado X.509v3.

2.7 Notación Sintáctica Abstracta Uno

Uno de los problemas que enfrentan los usuarios que se comunican desde sistemas heterogéneos es la transferencia eficiente de los datos de forma tal que los datos recibidos sean los mismos que los transmitidos. En el modelo OSI, la representación de los tipos de datos y estructuras para facilitar esta transferencia es una función del nivel de Aplicación, mientras que la codificación de los datos en una secuencia específica de bits a ser transferidos se atribuye al nivel de Presentación.

Esta separación de funciones permite al nivel de Aplicación tratar solamente con el contenido y estructura de los datos, dejando la representación al nivel de Presentación. Consistente con esta separación se ha introducido una notación abstracta para valores de datos y estructuras, esta notación es llamada ASN.1 (Abstract Syntax Notation One).

14

Por lo extensa de esta notación solo se menciona el propósito que tiene, ya que las estructuras de certificados, entre otros elementos definidos en los estándares, se acompañan de un módulo ASN que lo describe.

15

3. DISEÑO DEL SISTEMA

El proceso de diseñar un sistema embebido, con microcontroladores, comienza con un objetivo: la definición del producto. La definición del producto describe ¿qué es? y ¿qué hará? el sistema.

El proceso de diseño embebido generalmente sigue los siguientes pasos:

. Definición de requerimientos del producto

. Definición de requerimientos funcionales

. Selección del procesador

. Especificación del hardware y software

. Evaluación del sistema

. Diseño del firmware

. Integración

. Verificación (prueba)

Aunque estos pasos no necesariamente son consecutivos. Por ejemplo, si hay equipos separados de hardware y software, el diseño de éstos puede proceder en paralelo. El proceso tampoco es siempre lineal, la evaluación del sistema puede revelar un problema con el procesador seleccionado, lo que significa que ese paso debe ser repetido. Por último, el proceso no siempre puede estar bien dividido. La definición de requerimientos y la descripción funcional, por ejemplo, se puede unir dentro de la especificación del producto. En las secciones que vienen se diseña el repositorio electrónico siguiendo el orden descrito en forma consecutiva.

3.1.1 Definición de requerimientos del producto

El sistema que se diseña es un dispositivo que guarda información y realiza funciones criptográficas, se conecta a un computador personal para almacenar y utilizar certificados digitales.

Posee capacidad de almacenamiento de memoria no volátil suficiente para varios certificados.

Implementa el algoritmo de criptografía asimétrica RSA con un largo de llave de 512 bits.

Se conecta al computador personal por medio de la interfaz bus serie universal, USB [2] [3] [4].

Se alimenta por la misma interfaz de comunicación USB con 5V, no usa fuente de alimentación separada.

Posee sensor biométrico de huella dactilar, que incluye algoritmos de generación de plantilla y verificación, se comunica por medio de una interfaz serie asíncrona de hasta 115 kbps.

Un LED indica la condición de activo, y suspendido o con error. Otro LED indica estados autentificando, y lectura o escritura.

Provee de controlador de dispositivos para el sistema operativo Windows XP y 2000.

Provee interfaz API estándar pkcs#11 para las aplicaciones de usuario.

16

3.1.2 Definición de requerimientos funcionales

En este diseño toda la funcionalidad se obtiene por medio de su API, el que dispone de funciones para manejo de manejo de sesiones, manejo de objetos, cifrado, descifrado, recopilación de mensajes (message digesting), firma, verificación de firma, manejo de llaves, generación de números aleatorios, manejo de funciones paralelas, y retro llamadas.

El usuario puede crear, o almacenar, un certificado registrando un PIN o una huella dactilar, si emplea la huella debe presentarla tres veces para quedar enrolada.

El usuario puede hacer uso de un certificado almacenado presentando un PIN, si fue almacenado con PIN, o presentando la huella dactilar.

3.1.3 Selección de procesador

3.1.4 Plataforma de desarrollo

3.1.5 Requerimientos de hardware y firmware

3.2 Diseño del hardware

3.2.1 Diseño simple o multi chip

3.2.2 La memoria

3.2.3 La memoria RAM

3.2.4 Entrada y salida

3.2.5 Periféricos (biometría)

3.2.6 Carga del bus de datos

3.2.7 Memoria no volátil

3.2.8 El bus I2C

3.2.9 Programación en circuito

3.2.10 Periféricos internos

3.2.11 Simplificaciones del diseño

3.2.12 Protección contra estática

17

3.2.13 Relojes para el procesador

3.3 Diseño del firmware

3.3.1 Diagrama de flujo de datos

3.3.2 Diagrama de estado

3.3.3 Pseudocódigo

3.3.4 Arquitectura del firmware

3.3.5 Lenguaje y herramienta de desarrollo

3.3.6 Hardware del microprocesador

3.4 Integración

3.5 Verificación

18

4. LA IMPLEMENTACIÓN

19

5. PRUEBAS Y MEDICIONES

20

6. RESULTADOS Y CONCLUSIONES

21

A. El Bus Serie Universal

A.1. Introducción

La versión 1.1 del estándar USB soportaba dos velocidades, un modo full speed de 12 Mbits/s y un modo low speed de 1.5 Mbits/s. El modo 1.5 Mbits/s es lento pero menos susceptible a emisiones electromagnéticas, esto permite reducir los costos en ferritas y componentes de calidad. Por ejemplo, los cristales pueden ser reemplazados por resonadores. La versión 2.0 [2], todavía en vigencia, ha llegado a 480 Mbits/s. Esta velocidad se conoce como el modo high speed y compite con el bus serie IEEE-1394.

RENDIMIENTO APLICACIONES ATRIBUTOSLOW-SPEED Teclado, Mouse

Periféricos para JuegosPeriféricos para Realidad Virtual

Bajo costoFácil usoConexión dinámicaMúltiples periféricos

● Dispositivos Interactivos● 10 – 100 kb/s

FULL-SPEED MicrófonosAudioBanda ancha

Bajo costoFácil usoConexión dinámicaPeriféricos múltiplesAncho de banda garantizadoLatencia garantizada

● Audio, Video Comprimido● 500 kb/s – 10 Mb/s

HIGH-SPEED VideoAlmacenamientoImágenesBanda ancha

Bajo costoFácil usoConexión dinámicaPeriféricos múltiplesAncho de banda garantizadoLatencia garantizadaAncho de banda amplio

● Video, Almacenamiento● 25 – 400 Mb/s

Figura A-1. Velocidades del bus USB y aplicaciones.

El bus USB es controlado por el host, esto significa que sólo puede existir un host por bus. La especificación no soporta cualquier arreglo multimaster. Sin embargo la especificación On-The-Go, que complementa el estándar USB 2.0, introduce un protocolo de negociación de host que permite a dos dispositivos negociar el rol de host. Este nuevo protocolo está pensado sólo para conexiones punto a punto, tales como teléfonos móviles y organizadores personales, y no multi hub, o configuraciones multi dispositivo. El host USB es responsable de tratar todas las transacciones y repartir el ancho de banda. Los datos pueden ser enviados por varios métodos de transacción usando un protocolo basado en tokens.

Una de las intenciones originales del bus USB fue reducir la cantidad de cables detrás del PC, y algunos computadores conectan teclado y mouse en cadena para emplear solo un cable, pero USB usa una topología en estrella escalonada, similar a la Ethernet 10BaseT. Esta impone el uso de un hub en algún lugar, lo que agrega costos, más cajas y más cables. Sin embargo, esto no es tan malo ya que algunos dispositivos tienen hubs integrados dentro de ellos. Por ejemplo, algunos teclados pueden contener un hub que es conectado al PC, y el mouse puede ser enchufado al teclado.

22

Figura A-2. Topología estrella escalonada.

Esta topología en estrella escalonada, en lugar de simplemente encadenar dispositivos, presenta algunos beneficios. En primer lugar, la alimentación de los dispositivos puede ser monitoreada, e incluso desconectada en caso de que ocurra alguna condición de sobrecarga sin afectar a otros dispositivos USB. El hub puede soportar dispositivos de low, full, y high speed, ya que filtra las transacciones de full y high speed de forma que los dispositivos de low speed no las reciben.

Es posible conectar hasta 127 dispositivos a cualquier bus USB en cualquier momento. Si se requieren más dispositivos, simplemente se agrega otra controlador host. Aunque los primeros host USB tenían sólo dos puertas, los fabricantes vieron que era una limitación y comenzaron a introducir tarjetas con 4 ó 6 puertas, dejando algunas internas para discos duros y otros. Los primeros PC tuvieron solo un controlador USB y compartían el mismo ancho de banda. A medida que esta demanda creció fueron apareciendo tarjetas con dos o más controladores permitiendo canales individuales.

El controlador host USB tiene su propia especificación. Para la versión USB 1.1, existieron dos especificaciones de interfaz de controlador: UHCI (Universal Host Controller Interface) desarrollada por Intel, que pone el mayor peso en el software, y que permite controladores más económicos, y OHCI (Open Host Controller Interface)

23

desarrollada por Compaq, Microsoft y Nacional Semiconductors que pone más peso en el hardware y hace más simple el software.

Con la introducción de la versión USB 2.0 se necesitó una nueva especificación de la interfaz de controlador, que describe detalles a nivel de registro. Nace EHCI ( Enhanced Host Controller Interface), desarrollado, entre muchos otras empresas, por Intel, Compaq, NEC, Lucent y Microsoft.

Como lo sugiere su nombre, USB es un bus serial. Usa un cable de 4 hebras blindado, de los cuales dos son de alimentación (+5V y GND). Las otras dos hebras son un par trenzado que lleva una señal de datos diferencial. Usa el esquema de codificación NRZI para enviar los datos junto con un campo SYNC para sincronizar los relojes del controlador host y del receptor.

Figura A-3. Detalle de conexiones del cable USB.

El bus USB soporta plug and play con carga y descarga dinámica de los controladores de sistema operativo. El usuario simplemente conecta el dispositivo en bus, el host detecta la adición del dispositivo, lo interroga y carga el controlador de sistema operativo apropiado, todo en un tiempo imperceptible, asumiendo que el controlador del sistema operativo se encuentra cargado. El usuario final no necesita preocuparse por términos como IRQ’s, o direcciones de puertas, o por reiniciar el computador. Una vez que el usuario finaliza, puede simplemente desconectar el dispositivo y el host detectará su ausencia y descargará automáticamente el controlador del sistema operativo.

La carga del controlador de sistema operativo apropiado se hace usando la combinación PID/VID (Product ID / Vendor ID). El VID es entregado por el USB Implementor’s Forum por una tarifa que dura un tiempo definido. Sin embargo, otras organizaciones proveen VID extras para actividades no comerciales como educación, investigación o hobby. En algunos casos, también, es posible emplear el asignado al fabricante del chip USB. En otros casos, el fabricante del chip USB puede, también, vender un PID para usar con su propio VID.

Otra característica notable del bus USB es sus modos de transferencia. El bus USB soporta transferencias de Control, de Interrupción, en Volumen e Isócronas. Las transferencias isócronas permiten a un dispositivo reservar un ancho de banda definido con latencia garantizada. Esto es ideal para aplicaciones de audio y video donde la congestión puede causar pérdida de datos o de cuadros. Cada modo de transferencia

24

tiene compromisos en áreas tales como detección y recuperación de errores, garantía de ancho de banda y latencia.

A.2. Los Conectores

Todos los dispositivos tienen una conexión corriente arriba hacia el host, y todos los host tienen una conexión corriente abajo hacia los dispositivos, que no son intercambiables, eliminando la posibilidad de una conexión ilegal en lazo cerrado entre puertas para corriente arriba o corriente abajo. Existen dos tipos de conectores, llamados Tipo A y Tipo B que se muestran en la figura A-3.

Figura A-3. Conectores USB.

Los enchufes Tipo A indican siempre la corriente arriba. Los soquetes Tipo A se encuentran siempre en las tarjetas madre de los PCs y hubs. Los enchufes Tipo B son siempre conectados hacia la corriente abajo, en consecuencia los soquetes Tipo B se encuentran en los dispositivos.

Sin embargo, existen cables y accesorios que contradicen la especificación, como cables directos Tipo A a Tipo A, otros cables prohibidos son los que tienen un enchufe en uno de los extremos (Tipo A o Tipo B) y un soquete en el otro. Estos cables violan los requerimientos de largo del cable USB.

La especificación USB 2.0 [2] incluyó una modificación que introduce los conectores mini-USB B. La razón para estos conectores es la aparición de dispositivos electrónicos miniatura como teléfonos móviles y organizadores personales.

Recientemente se ha liberado la especificación On-The-Go, que agrega funcionalidad punto a punto al bus USB. Esta incorpora los host dentro de los dispositivos, y así ha incluido una especificación para enchufes mini-A, receptáculos mini-A, y receptáculos mini-AB.

25

Número de pin

Color de Cable

Función

1 Rojo VBUS (5 Volts)2 Blanco D-3 Verde D+4 Negro GND

Tabla A-1. Función de los pines USB y colores de hebras.

También, en el interior de los cables USB se emplea una norma de colores, facilitando la identificación de las hebras entre los fabricantes. Esta se muestra en la tabla A-1, pero se encuentra el detalle completo en el capítulo 6 de la especificación USB 2.0 [2].

A.3. Especificación Eléctrica

Como se dijo, el bus USB usa para los datos un par diferencial. La corriente de datos es codificada usando NRZI y tiene relleno de bits (bit stuffing) para asegurar la adecuada transmisión. En los dispositivos de Low y Full speed, se transmite un ‘1’ diferencial levantando D+ por sobre 2.8V con un resistor de 15K puesto a tierra y D- es puesto bajo 0.3V con un resistor de 1.5K puesto a 3.6V. En el otro caso, para un ‘0’ diferencial D- es levantado sobre 2.8V y D+ es puesto bajo 0.3V con el mismo resistor.

El receptor define un ‘1’ diferencial como D+ - D- > 200mV un ‘0’ diferencial como D+ - D- < 200mV. La polaridad de la señal es invertida dependiendo de la velocidad del bus.

Los retransmisores USB tienen salidas simples y diferenciales. Ciertos estados del bus son indicados por señales de salida simple en D+, D- o ambas. Por ejemplo, un cero en salida simple puede ser usado para significar reposición del dispositivo si se mantiene por más de 10mS. Es importante tener esto en cuenta si se está usando retransmisores y FPGA como dispositivo USB.

La impedancia característica del bus en low o full speed es de 90 ohms +/- 15%. Por lo tanto, es importante observar las hojas de especificaciones cuando se intenta calzar la impedancia con resistores serie para D+ y D-.

El modo High Speed (480 Mbits/s) usa un corriente constante de 17.78mA como señalización para reducir el ruido.

A.4. Identificación de la Velocidad

Un dispositivo USB debe indicar su velocidad levantando D+ o D- hasta 3.3V. Un dispositivo full speed, mostrado en la figura, usa un resistor conectado a D+ para especificar que es un dispositivo full speed. Este resistor conectado en el extremo del dispositivo también es usado por el host, o hub, para detectar la presencia de un dispositivo conectado a este puerto. Sin este resistor se asume que no hay dispositivo conectado al bus. Algunos dispositivos tienen este resistor integrado, y puede ser activado o desactivado bajo control de software, y otros requieren un resistor externo.

26

Figura A-4. Dispositivo con resistor conectado a D+.

Figura A-5. Dispositivo con resistor conectado a D-.

Los dispositivos high speed comienzan la conexión en full speed, y una vez que han sido asignados, efectúan un chirrido durante la reposición y establecen una conexión en modo high speed, si el hub la soporta. Si el dispositivo opera en modo high speed, entonces el resistor es removido para balancear la línea.

Un dispositivo conforme USB 2.0 no está obligado a soportar el modo high speed. Esto permite la producción de dispositivos económicos si la velocidad no es un factor crítico. También es el caso de los dispositivos USB 1.1, no están obligados a soportar el modo full speed.

Sin embargo, un dispositivo high speed no debe soportar el modo low speed. Este debe soportar el modo full speed para la primera conexión, y si negocia exitosamente pasa al modo high speed. Un dispositivo de corriente de bajada conforme USB 2.0 (hub o host) debe soportar los tres modos high, full y low speed.

27

A.5. Alimentación (VBUS)

Una de las bondades de USB es la capacidad de alimentar dispositivos a través del mismo bus, y que no requieren de una fuente externa ni cables adicionales.

Un dispositivo USB especifica su consumo de poder expresado en unidades de 2mA en el descriptor de configuración, que será examinado mas tarde. Un dispositivo no puede consumir más poder que el especificado durante la enumeración, aún si pierde el poder externo. Existen tres clases de funciones USB:

. Funciones alimentadas por bus de bajo poder

. Funciones alimentadas por bus de alto poder

. Funciones auto alimentadas

Las funciones alimentadas por bus de bajo poder, sacan todo su poder desde Vbus y no pueden obtener más que solo una unidad de carga. La especificación USB define la unidad de carga como 100mA. Las funciones alimentadas por bus de bajo poder deben ser diseñadas para trabajar entre 4.40V y 5.25V, medidos en el enchufe corriente arriba del dispositivo.

Las funciones alimentadas por bus de alto poder sacan todo su poder del bus y no pueden obtener más que 1 unidad de carga hasta que han sido configurados, después pueden sacar hasta 5 unidades de carga, siempre que sea especificado en su descriptor. Las funciones de alto poder deben ser capaces de ser detectadas a un mínimo de 4.40V. Durante la operación en carga completa se debe considerar un Vbus mínimo de 4.75V y un máximo de 5.25V. Como antes, estas mediciones son tomadas en el enchufe corriente arriba.

Las funciones auto alimentadas pueden sacar hasta 1 unidad de carga desde el bus y obtener el resto desde una fuente externa. Si la fuente externa falla no debe sacar mas de 1 unidad de carga desde el bus. Esta unidad de carga permite la detección y la enumeración del dispositivo sin la aplicación de la fuente principal.

Ningún dispositivo USB, alimentado por bus o auto alimentado, pueden controlar el Vbus en su puerta corriente arriba. Si se pierde el Vbus, el dispositivo tiene 10mS para remover la alimentación desde el resistor conectado a D+/D- usado para identificar la velocidad.

Otra consideración es que la corriente de fluencia inicial hacia el dispositivo debe ser limitada. Esto está descrito en el párrafo 7.2.4.1 de la especificación y debe ser observado. La corriente de fluencia de entrada es debida a la capacitancia del dispositivo entre Vbus y tierra. La especificación permite un valor máximo del capacitor de desacoplo en la entrada de 10uF. También, cuando se desconecta el dispositivo, después que la corriente está fluyendo a través del cable inductivo, puede producirse un voltaje de retroceso en el extremo abierto del cable. Para prevenir esto, la especificación obliga a usar un capacitor de desacoplo de un valor mínimo de 1uF entre Vbus y tierra.

A.6. Intensidad de Suspensión

En todos los dispositivos es obligatorio el modo suspendido. Durante la suspensión aparecen obligaciones adicionales. La corriente de suspensión es proporcional a las unidades de carga. Para 1 unidad de carga (valor por omisión) la máxima corriente de

28

suspensión es 500uA. Incluyendo la corriente de los resistores de polarización del bus. En el hub, D+ y D- tienen resistores de 15K ohms a tierra y el dispositivo tiene uno de 1.5K ohms sometido a un voltaje típico de 3.3V, produce un consumo, incluso antes de que el dispositivo entre en función, de 200uA.

Una consideración para muchos dispositivos es el regulador de 3.3V. Muchos funcionan con 3.3V, por ejemplo el PDIUSBD11. Los reguladores lineales por lo general bastante ineficientes con corrientes promedio de inactividad del orden de 600uA, lo que obliga a usar reguladores más costosos. En la mayoría de los casos, también se requiere frenar o detener los relojes de los microcontroladores para caer dentro del límite de los 500uA.

Aunque muchos hosts o hubs no tienen la habilidad para detectar una sobrecarga de esta magnitud, si el consumo es de 5mA, o incluso 10mA, no sucede nada, teniendo presente que no se cumple con la especificación USB. Sin embargo, si en operación normal se intenta exceder los 100mA, o la carga permisible designada, entonces es esperable que el host, o el hub, detecte la sobrecarga y desconecte el dispositivo, con el fin de proteger la integridad del bus.

Por supuesto, estas consideraciones de diseño se pueden evitar si se escoge el diseño auto alimentado.

A.7. Ingreso al Modo Suspendido

Un dispositivo USB ingresa al modo suspendido cuando no hay actividad en el bus por más de 3ms. Este, entonces, tiene un tiempo adicional de 7ms para apagar el dispositivo y consumir no más que la corriente de suspensión designada, y debe mantener este consumo por 10ms después que la actividad del bus ha cesado. Con el fin de permanecer conectado a un hub, o host, el dispositivo debe mantener la alimentación del resistor selector de velocidad durante el estado suspendido.

También son enviados periódicamente paquetes de inicio de cuadro, como señal de vida. Esto previene que el bus ingrese al modo suspendido en ausencia de datos.

. Un bus high speed envía micro cuadros cada 125.0 us ±62.5 ns.

. Un bus full speed envía un cuadro cada 1.0 ms ±500 ns.

. Un bus low speed envía un EOP (fin de paquete) cada 1 ms, solo en ausencia de datos.

El dispositivo resume la operación normal cuando recibe cualquier señalización no ociosa. Si un dispositivo tiene habilitado el despertar remoto, entonces, puede señalar al host resumir desde suspendido.

A.8. Tasas de Señalización de Datos

Otra área que es a menudo observada es la tolerancia de los relojes del bus. Estas se definen en la especificación del bus USB y son:

. El bus high speed usa un reloj de 480.00 Mb/s con una tolerancia de ±500ppm.

. El bus full speed usa un reloj de 12.00 Mb/s con una tolerancia de ±0.25% o 2500ppm.

. El bus low speed usa un reloj de 1.50 Mb/s con una tolerancia de ±1.5% o 15000ppm.

29

Esto permite el uso de resonadores para reducir costos en dispositivos low speed, pero deja fuera de regla a los full y high speed.

A.9. Protocolos USB

A diferencia del protocolo RS-232, o similar, donde el formato de los datos enviados no está definido, en el bus USB existen varias capas de protocolos, lo que parece complicado, pero en realidad lo que más interesa es la capa superior. De hecho, muchos controladores USB manejan la capa inferior, dejándola casi invisible al diseñador final.

Cada transacción USB consiste de

. Un paquete de Token (o encabezamiento que define lo que sigue).

. Un paquete opcional de datos (conteniendo la carga de información).

. Y un paquete de estado (usado para reconocer transacciones y proveer un medio para corregir errores)

Como se mencionó USB es un bus centrado en un host. El host inicia las transacciones. El primer paquete, también llamado token, es generado por el host para describir que datos siguen, si es una lectura o una escritura, cual es la dirección del dispositivo y cual es el endpoint. El siguiente paquete, es generalmente un paquete de datos portando la carga de información, y es seguido por un paquete de handshaking, que reporta si los datos o el token fueron recibidos correctamente, o si el endpoint está atascado o no está disponible para recibir datos.

A.10. Campos Comunes de un paquete USB

Los datos en el bus USB son transmitidos partiendo por el byte menos significativo (orden litle indian). Los paquetes USB consisten de los siguientes campos:

. SYNCTodos los paquetes comienzan con un campo SYNC. Este campo tiene 8 bits de largo, y es usado para sincronizar el reloj del receptor con el del transmisor. Los dos últimos bits indican el inicio del campo PID.

. PIDPID significa Packet ID. Este campo es usado para identificar el tipo de paquete que será enviado. La tabla siguiente muestra los posibles valores:

Grupo Valor de PID

Indentificador de Paquete

Token 0001 OUT1001 IN0101 SOF1101 SETUP

Data 0011 DATA01011 DATA10111 DATA21111 MDATA

Handshake

0010 ACK

30

1010 NAK1110 STALL0110 NYET

Especial 1100 PREámbulo1100 ERR1000 Split0100 Ping

Hay 4 bits para el PID, sin embargo, para asegurar que éste es recibido correctamente, los 4 bits son complementados y repetidos, haciendo un total de 8 bits. El formato resultante es el siguiente:

PID0 PID1 PID2 PID3 ~PID0

~PID1

~PID2

~PID3

. ADDREl campo dirección indica el dispositivo designado para recibir el paquete. Con 7 bits de largo permite soportar hasta 127 dispositivos. La dirección 0 no es válida, ya que cualquier dispositivo que no tiene una dirección asignada debe responder a los paquetes enviados a esta dirección.

. ENDPEl campo endpoint se compone de 4 bits, permitiendo 16 posibles endpoints. Sin embargo, los dispositivos low speed pueden tener solo hasta 4 endpoints.

. CRCDentro de los paquetes de datos se agregan códigos de redundancia cíclicos, todos los paquetes Token usan un CRC de 5 bits mientras que los paquetes de datos usan un CRC de 16 bits.

. EOPFin de paquete. Señalado por un cero simple de aproximadamente 2 bits de duración seguido por un estado J de 1 bit de duración.

A.11. Tipos de Paquetes USB

El bus USB tiene cuatro tipos diferentes de paquetes. Los paquetes token indican el tipo de transacción, los paquetes dato contienen la carga de datos, los paquetes hanshake para reconocer los datos o reportar errores, y los paquetes de inicio de cuadro para indicar el inicio de un nuevo cuadro.

. Paquetes Token

Hay tres tipos de Token

. In Informa al dispositivo USB que el host desea leer información. . Out Informa al dispositivo USB que el host desea enviar información. . Setup Usado para comenzar transferencias de control.

Los paquetes Token tienen el siguiente formato:

SYNC PID ADDR ENDP CRC5 EOP

. Paquetes de Datos

31

Hay dos tipos de paquetes de datos, cada uno es capaz de transmitir de 0 a 1023 bytes de datos.

. Data0 . Data1

Los paquetes de datos tienen el siguiente formato:

SYNC PID Datos CRC16 EOP

. Paquetes de Handshake

Hay tres tipos de paquetes de handshake que consisten simplemente del PID

. ACK Reconoce que el paquete se ha recibido exitosamente. . NAK Reporta que el dispositivo no puede enviar o recibir datos.

También es usado durante transacciones de interrupción para informar al host que no hay datos por enviar.

. STALL El dispositivo se encuentra en un estado que requiere intervención del host.

Los paquetes handshake tienen el siguiente formato

SYNC PID EOP

. Paquetes de Inicio de Cuadro

Estos paquetes de inicio de cuadro (SOF), consistentes de un número de cuadro de 11 bits, son enviados por el host cada 1mS ±500nS.Tienen el siguiente formato

SYNC PID Numero de Cuadro CRC5 EOP

32

A.12. Las Funciones del bus USB

Cuando se piensa en dispositivos USB, se cree que es el periférico, pero un dispositivo USB puede ser un retransmisor USB usado en el host o el periférico, un hub USB o un controlador host, o un dispositivo periférico USB. Por lo tando, el estándar habla de funciones USB que pueden ser vistas como dispositivos USB que proveen una capacidad o función, tal como una impresora, un escáner, un módem u otro periférico.

Figura A-6. Funciones USB.

Muchas de las funciones USB manejan los protocolos de bajo nivel hasta la capa de transacción en el controlador de silicio. Tienen una serie de buffers, típicamente de 8 bytes de largo. Cada buffer pertenece a un endpoint – EP0 IN, EP0 OUT, etc. Por ejemplo, si el host envía un requerimiento de descriptor de dispositivo, el hardware de la función lee el paquete de setup y determina, usando el campo ADDR, si es para él, si lo es copia los datos, que vienen en el siguiente paquete de datos, en el buffer del endpoint indicado por el campo endpoint del token setup. Luego envía un paquete handshake para reconocer la recepción del requerimiento y genera una interrupción interna dentro del controlador para el endpoint apropiado, señalando que éste ha recibido un paquete. Todo esto es normalmente hecho por el hardware.

Ahora el software recibe una interrupción, y debe leer el contenido del buffer del endpoint e interpretar el descriptor de requerimiento del dispositivo.

33

A.13. Endpoints

Los endpoints pueden ser descritos como fuentes o destinos de datos. Como el bus está centrado en un host, los endpoint están al final del canal de comunicaciones, en la función USB. A nivel de software, el controlador puede enviar un paquete al EP1 del dispositivo, por ejemplo. Los datos que salen del host terminan en el buffer EP1 OUT. El firmware, entonces, lee cuando le convenga los datos desde éste buffer. Si desea devolver datos, la función no puede simplemente escribirlos en el bus, ya que es controlado por el host. Por lo tanto, éste escribe los datos en el buffer EP1 IN, y los deja allí, hasta que el host le envía un paquete IN, requiriendo los datos. Los endpoints pueden también ser vistos como una interfaz entre el hardware de la función y el firmware que corre en la función.

Todos los dispositivos deben soportar el endpoint cero. Este recibe todos los requerimientos de control y estado durante la enumeración y mientras el dispositivo se encuentre operacional en el bus.

A.14. Tuberías

Mientras el dispositivo envía y recibe datos en una serie de endpoints, el software cliente transfiere datos a través de tuberías. Una tubería es una conexión lógica entre el host y los endpoints. Las tuberías, también, tienen asociadas un conjunto de parámetros tales como ancho de banda asignado, tipo de transferencia que usa (control, masiva, isocrónico o interrupción), una dirección de flujo de datos y tamaños máximos de paquetes y buffer. Por ejemplo la tubería por omisión es bi-direccional compuesta por EP0 IN y EP0 OUT con transferencia tipo control.

La especificación USB define dos tipos de tuberías

. Tubería de Corriente: no tiene formato USB definido, esto es, se puede enviar cualquier tipo de datos corriente abajo y el otro extremo puede recuperar los datos. Estos fluyen secuenciales y tienen una dirección predefinida, entrada o salida. Las tuberías de corriente soportan tipos de transferencia masivos, isócronas o interrupción. También, estas tuberías, pueden ser controladas por el host o el dispositivo.

. Tuberías de Mensajes: tienen un formato USB definido. Son controlados por el host, y son iniciados por un requerimiento enviado por el host. Los datos son transferidos en la dirección deseada, dictada por el requerimiento. Por lo tanto, las tuberías de mensajes permiten flujo de datos en ambas direcciones pero solo soportan transferencias de control.

A.15. Transferencias de Control

Las transferencias de control son usadas típicamente para operaciones de comando y lecturas de estado. Son esenciales para ajustar un dispositivo USB durante el proceso de enumeración. El tamaño de paquete de una transferencia de control en un dispositivo low speed debe ser de 8 bytes, los dispositivos high speed permiten paquetes de 8, 16, 32 ó 64 bytes y los de full speed deben tener un tamaño de 64 bytes.Una transferencia de control puede tener hasta tres etapas.

34

. Etapa de Ajuste: es donde el requerimiento es enviado. Consiste de tres paquetes. Primero es enviado el token de ajuste que contiene la dirección y el número del endpoint. Luego es enviado el paquete de datos el cual siempre tiene un PID tipo DATA0 e incluye un paquete de ajuste que detalla el tipo de requerimiento. Los paquetes de ajuste se detallan más adelante. El último paquete es un handshake usado para reconocer la recepción exitosa o para indicar la ocurrencia de un error. Si la función recibe exitosamente, los datos de ajuste, responde con ACK. En caso contrario, ignora los datos y no envía el paquete de handshake. Las funciones no pueden emitir un paquete STALL o NAK en respuesta a un paquete de ajuste.

Figura A-7. Proceso Etapa de Ajuste del Dispositivo.

. Etapa de Datos, opcional: consiste de una o más transferencias IN o OUT. El requerimiento de ajuste indica la cantidad de datos a ser transferidos en esta etapa. Si excede el tamaño máximo del paquete, los datos son enviados en varias transferencias del tamaño máximo, excepto la última.

La etapa de datos tiene dos diferentes escenarios dependiendo de la dirección de la transferencia.

. IN: Cuando el host está listo para recibir datos de control éste emite un token IN. Si la función recibe un token IN con un error, p.e. el PID no calza los bits invertidos, entonces, ignora el paquete. Si el token es recibido correctamente, el dispositivo puede responder con un paquete DATA conteniendo los datos de control a ser enviados, un paquete STALL para indicar que el endpoint ha tenido un error, o paquete NAK para indicar al host que el endpoint está trabajando, pero temporalmente no tiene datos para enviar.

35

Figura A-8. Proceso Etapa de Datos del Dispositivo.

. OUT: Cuando el host necesita enviar al dispositivo un paquete de datos, éste emite un token OUT seguido por un paquete de datos conteniendo los datos de control como carga de información. Si cualquier parte del token OUT o del paquete de datos está corrupto, entonces, la función ignora el paquete. Si el buffer del endpoint de la función se encuentra vacío cuando recibe los datos éste emite un ACK informando al host que los ha recibido exitosamente. Si el buffer del endpoint no se encuentra vacío, por que se encuentra procesando el paquete anterior, entonces, la función retorna un NAK. Sin embargo, si el endpoint ha tenido un error, éste retorna un STALL.

. Etapa de Estado: reporta el estado sobre un requerimiento y, nuevamente, varía según la dirección de la transferencia. El reporte de estado siempre es realizado por la función.

36

. IN: Si el host envía tokens IN durante la etapa de datos, entonces, el host debe reconocer la recepción exitosa de los datos. Esto lo realiza el host enviando un token OUT seguido por un paquete de datos de largo cero. La función ahora puede reportar su estado en la etapa de handshaking. Un ACK indica que la función ha completado el comando y está lista para aceptar otro. Si ocurre un error durante el procesamiento del comando, entonces, la función emite un STALL. Sin embargo, si la función se encuentra aún procesando el comando, retorna un NAK para indicar al host que debe repetir la etapa de estado mas tarde.

Figura A-9. Etapa de Estado con IN.

.OUT: Si el host envía tokens OUT durante la etapa de datos, la función reconoce la recepción exitosa de los datos enviando un paquete de largo cero en respuesta a un token IN. Sin embargo, si ocurre un error ésta debe emitir un token STALL, o si aún se encuentra ocupada procesando datos, debe emitir un NAK pidiendo al host que reintente la fase de estado más tarde.

Figura A-10. Etapa de Estado con OUT.

37

A.16. Transferencias de Interrupción

Cualquiera que ha tenido experiencia con requerimientos de interrupción en microcontroladores sabe que las interrupciones son generadas por el dispositivo. Sin embargo bajo USB si un dispositivo requiere la atención del host, éste debe esperar hasta que host lo interroga antes de que pueda reportar que necesita atención urgente.

Las transferencias de interrupción son típicamente no-periódicas, algunos dispositivos inician la comunicación requiriendo períodos de latencia acotados. Un requerimiento de interrupción es encolado por el dispositivo hasta que el host los interroga.

La carga de información máxima para los dispositivos low speed es de 8 bytes. Para los dispositivos full speed es de 64 bytes. Y para los high speed es de 1024 bytes.

Figura A-11. Formato de las transferencias de interrupción, IN y OUT.

38

. IN: El host periódicamente interroga el endpoint de interrupción. La tasa de interrogación es especificada en el descriptor del endpoint. En cada ciclo de interrogación el host envía un token IN. Si el token IN está corrupto, la función ignora el paquete y continúa monitoreando el bus por nuevos tokens.

Si una interrupción ha sido encolada por el dispositivo, la función envía un paquete de datos conteniendo información relevante para la interrupción cuando recibe un token IN. Cuando el host lo recibe exitosamente devuelve un ACK. Sin embargo, si los datos están corruptos, el host no devuelve ningún reconocimiento.

Si, por otra parte, existía una condición de interrupción cuando el host interroga el ebdpoint interruptor con un token IN, entonces la función señala este estado enviando un NAK. Si, en este punto, existía una condición de error la función envía un STALL en respuesta al token IN.

. OUT: Cuando el host desea enviar al dispositivo datos sobre la interrupción, éste emite un token OUT seguido de un paquete de datos conteniendo los datos de la interrupción. Si cualquier parte del token OUT o del paquete de datos está corrupto entonces la función ignora el paquete. Si el buffer del endpoint de la función estaba vacío, y se depositan los datos en éste, emite un ACK informado al host que ha recibido los datos correctamente. Si el buffer del endpoint no estaba vacío, debido al procesamiento del paquete anterior, entonces la función retorna un NAK. Sin embargo, si ocurre algún error en el endpoint, y no se ha ajustado el bit de alto, éste retorna un STALL.

A.17. Transferencias Isócronas

La transferencias isócronas ocurren continua y periódicamente. Típicamente contienen información sensible al tiempo, tales como corrientes de audio o video. Si existen retardos o reintentos en una corriente de audio, es esperable una reproducción errática conteniendo glitches. El ritmo no estará en sincronía. Sin embargo, si se pierde un paquete, o cuadro, es menos probable que lo note el oyente.

Las transferencias isócronas:

. Proveen ancho de banda garantizado.

. Proveen latencia limitada.

. Tienen corriente de datos unidireccional.

. Tienen detección de errores vía CRC, pero sin reintento.

. Sólo en modos full y high speed.

. No tienen intercambio de datos.

La carga de información máxima es especificada en el descriptor del endpoint isócrono. Este puede tener un valor tope de 1023 para dispositivos full speed, y 1024 para los high speed. A medida que la carga máxima de información llegue a afectar el requerimiento de ancho de banda el bus, es aconsejable especificar un tamaño de carga de información conservador. Si se usa una gran carga de información, resulta conveniente especificar una serie de interfaces alternativas con varios tamaños de carga de información. Si durante la enumeración, el host no puede habilitar el endpoint isócrono preferido, debido a restricciones de ancho de banda, tiene donde caer en lugar de simplemente fallar. Los datos enviados al endpoint isócrono pueden ser de menor tamaño que el prenegociado y pueden variar en largo de transacción en transacción.

39

Figura A-12. Formato de las transferencias isócronas. IN y OUT.

Las transacciones isócronas no tienen etapa de handshaking y no pueden reportar errores o condiciones de STALL, o HALT.

A.18. Transferencias Masivas

Las transferencias masivas se emplean para grandes volúmenes de datos. Tales como, por ejemplo, trabajos de impresión. Las transferencias masivas proveen corrección de errores por medio de un campo CRC-16 en la carga de datos, y mecanismos de retransmisión para asegurar que los datos son trasmitidos y recibidos sin error.

Las transferencias masivas usan ancho de banda sobrante no asignado en el bus después que todos las otras transacciones son asignadas. Si el bus está ocupado con transferencias isócronas y/o interrupción, entonces, la transferencia masiva puede escurrir lentamente por el bus. Por lo tanto, las transferencias masivas solo pueden ser usadas para comunicaciones insensibles de tiempo ya que no tienen latencia garantizada.

Las transferencias masivas

. Usadas para transferir grandes volúmenes de datos.

. Tienen detección de errores con CRC, y despacho garantizado.

. No tienen ancho de banda garantizado, o latencia mínima.

. Corriente de datos unidireccional.

. Solo en modos full y high speed.

Las transferencias masivas solo son soportadas por dispositivos full y high speed. Para los endpoints full speed el máximo tamaño de paquete puede ser de 8, 16, 32, o 64 bytes de largo. Para los endpoint high speed, el máximo tamaño de paquete pude ser hasta 512 bytes de largo. Si la carga de datos queda pequeña en el tamaño máximo de paquete no se necesita rellenar con ceros. Una transferencia masiva se considera completa cuando se ha transferido la cantidad exacta de datos requerida, cuando se ha transferido un paquete menor al del tamaño máximo del endpoint, o se ha transferido un paquete de largo cero.

40

Figura A-13. Formato de las transferencias masivas, IN y OUT.

La figura anterior muestra el formato de las transferencias masivas de IN y OUT, las que se explican como sigue.

. IN: Cuando el host está listo para recibir datos masivos emite un token IN. Si la función recibe un token IN con error ignora el paquete. Si el token es recibido correctamente, la función puede responder con un paquete DATA conteniendo los datos masivos, o un paquete STALL indicando que endpoint ha tenido un error o un paquete NAK indicando al host que el endpoint está trabajando, pero temporalmente no tiene datos para enviar.

. OUT: Cuando el host quiere enviar a la función un paquete de datos masivos, emite un token OUT seguido por un paquete de datos conteniendo los datos masivos. Si cualquier parte del token OUT o el paquete de datos está corrupto entonces la función ignora el paquete. Si buffer del endpoint de la función

41

estaba vacío y ha recibido los datos emite un ACK informando al host que ha recibido los datos exitosamente. Si el buffer del endpoint no está vacío, debido a que está procesando el paquete anterior, entonces la función retorna un NAK. Sin embargo, si el endpoint ha tenido algún error, y no se ha ajustado el bit de alto, retorna un STALL.

A.19. Administración del Ancho de Banda

El responsable por la administración del ancho de banda del bus es el host. Es realizada al momento de la enumeración cuando se configuran los endpoints isócronos y de interrupción, y a través de la operación. La especificación pone límites en el bus, permitiendo asignar no más del 90% para transacciones periódicas (isócronas y de interrupción) en un bus full speed. En los buses high speed este límite es menor permitiendo asignar no más del 80% a transacciones periódicas.

Entonces, se puede ver que si el bus está saturado con transacciones periódicas, el restante 10% es dejado para las transferencias de control y una vez que se han asignado, las transacciones masivas toman el resto.

A.20. Los Descriptores USB

Todos los dispositivos USB tienen una jerarquía de descriptores que entregan al host información tal como que dispositivo es, que hace, que versión de USB soporta, de cuantas maneras puede ser configurado, el número de endpoints y sus tipos, etc.

Los descriptores USB más comunes son

. Descriptor de Dispositivo

. Descriptor de Configuración

. Descriptor de Interfaz

. Descriptor de Endpoint

. Descriptor de String

Los dispositivos USB sólo pueden tener un descriptor de dispositivo. El descriptor de dispositivo incluye información tal como revisión de la especificación USB que cumple, identificación del vendedor VendorID, y del producto ProductID, usados para cargar el controlador apropiado, y el número de posibles configuraciones que el dispositivo puede tener. El número de configuraciones indican cuantos descriptores de configuración siguen.

El descriptor de configuración especifica valores tales como la cantidad de poder que esta configuración particular usa, si el dispositivo es alimentado por bus o es auto alimentado, y el número de interfaces que tiene. Cuando un dispositivo es enumerado, el host lee los descriptores del dispositivo y decide que configuración habilitar. Este puede habilitar solo una configuración cada vez.

Por ejemplo, es posible tener una configuración alimentación por bus y otra con auto alimentada. Si el dispositivo es enchufado en un host con fuente principal, el controlador del dispositivo puede escoger la configuración que indica alimentación por bus, pero si es conectado a un organizador personal puede habilitar la configuración que indica auto alimentación, requiriendo que el usuario conecte el dispositivo a su fuente de poder.

42

Las configuraciones no están limitadas a las diferencias de poder. Cada configuración puede ser alimentada en la misma forma y drenar la misma corriente, aún teniendo diferentes combinaciones de interfaces o endpoints. Sin embargo, para cambiar la configuración requiere detener la actividad en cada endpoint. Mientras el bus USB ofrece esta flexibilidad, muy pocos dispositivos tinen mas de 1 configuración.

Figura A-14. Árbol de Descriptores.

El descriptor de interfaz puede ser visto como la cabecera, o agrupamiento, de endpoints en un grupo funcional para implementar una funcionalidad simple del dispositivo. Por ejemplo, en el caso de un equipo multifunción fax/scanner/impresora. El primer descriptor de interfaz puede describir los endpoints de la función fax, el segundo descriptor de interfaz puede describir la función scanner, y el tercer descriptor de interfaz la función impresora. Al contrario del descriptor de configuración, no tiene la limitación de ser solo uno a la vez. Un dispositivo puede tener más de un descriptor de interfaz habilitado a la vez.

El descriptor de interfaz tiene un campo bInterfaceNumber para especificar el número de la interfaz y un campo bAlternativeSetting que permite a una interfaz cambiar ajustes al vuelo. Por ejemplo, un dispositivo con dos interfaces, interfaz uno y dos. La interfaz uno tiene bInterfaceNumber puesta a 0 indicando que es el primer descriptor de interfaz y un bAlternativeSetting de 0.

La interfaz dos puede tener bInterfaceNumber puesto a 1 indicando que es la segunda interfaz y un bAlternativeSetting de 0. Al pasar a otro descriptor, también con bInterfaceNumber puesto a 1 indicando que es la segunda interfaz, pero esta vez bAlternativeSetting es 1, indicando que este descriptor de interfaz puede ser un ajuste alternativo al anterior para la interfaz dos.

Cuando esta configuración es habilitada, se usan los dos primeros descriptores de interfaz bAlternativeSetting igual a 0. Sin embargo, durante la operación el host puede enviar un requerimiento SetInterface dirigido a la interfaz 1, con ajuste alternativo 1, para habilitar el otro descriptor de interfaz.

Tener dos configuraciones permite una ventaja extra, mientras se transmite datos a la interfaz cero es posible cambiar los ajustes del endpoint asociado con la interfaz uno sin afectar a la interfaz cero.

Cada descriptor de endpoint es usado para especificar un tipo de transferencia, dirección, intervalo de interrogación y un tamaño máximo de paquete para cada

43

endpoint. El endpoint cero, el endpoint de control por omisión, siempre se asume que es de control y por ende nunca tiene un descriptor.

A.21. Estructura de Descriptores USB

Todos los descriptores tienen un formato común. El primer byte especifica el largo del descriptor, mientras que el segundo byte indica el tipo de descriptor. Si el largo del descriptor es menor al definido por la especificación, entonces, el hest debe ignorarlo. Sin embargo, si el largo es mayor que el especificado el host debe ignorar los byes extra y encontrar el siguiente descriptor al final del largo actual indicado.

Offset

Campo Tamaño

Valor Descripción

0 bLength 1 Número Largo del descriptor en bytes1 bDescriptorTyp

e1 Constant

eTipo de descriptor

2 bcdUSB 2 BCD Parámetros USB para el descriptor

A.22. Descriptores de Dispositivo

Los descriptores de dispositivos USB representan al dispositivo completo. Por consiguiente, un dispositivo USB puede tener solo un descriptor de dispositivo. Este especifica información básica, pero importante, acerca del dispositivo tal como la versión de la especificación USB soportada, máximo tamaño de paquete, identificadores de vendedor y producto, y el número de posibles configuraciones que el dispositivo puede tener. El formato del descriptor de dispositivo es el siguiente.

Offset

Campo Tamaño

Valor Descripción

0 bLength 1 Número Largo del descriptor (12 bytes)1 bDescriptorType 1 Constant

eDescriptor de dispositivo (0x01)

2 bcdUSB 2 BCD Número de especificación USB.4 bDeviceClass 1 Clase Código de clase

Si es 0x00, cada interfaz especificasu propio código.Si es 0xFF, el código es especificadopor el vendedor.En otro caso, es un código de claseválido.

5 bDeviceSubClass 1 Subclase Código de subclase (asignado por usb.org)

6 bDeviceProtocol 1 Protocolo Código de protocolo (asignado por usb.org)

7 bMaxPacketSize 1 Número Máximo tamaño de paquete para el endpoint cero. Válidos son: 8, 16, 32, 64

8 idVendor 2 ID ID de vendedor (asignado por

44

org.usb)10 idProduct 2 ID ID de producto (asignado por el

fabricante)12 bcdDevice 2 BCD Número de release del dispositivo14 iManufacturer 1 Índice Índice del descriptor de string

para el fabricante15 iProduct 1 Índice Índice del descriptor de string

para el producto16 iSerialNumber 1 Índice Índice del descriptor de string

para el número de serie17 bNumConfiguration

s1 Entero Número de posibles de

configuraciones

. El campo bcdUSB informa la versión de especificación que soporta el dispositivo. El valor es un decimal codificado en binario con el formato 0xJJMN, donde JJ es el número mayor, M es el número menor de la versión y N es el sub menor. Por ejemplo, USB 2.0 es informado como 0x0200, USB 1.1 como 0x0110 y USB 1.0 como 0x0100.

. Los campos bDeviceClass, bDeviceSubClass y bDeviceProtocol son usados por el sistema operativo para encontrar el controlador de la clase para el dispositivo. Normalmente sólo es ajustado bDeviceClass a nivel del dispositivo. En muchos casos se usa identificar la clase a nivel de interfaz, para lo cual se ajusta bDeviceClass a 0x00. Esto permite a un dispositivo soportar múltiples clases.

. El campo bMaxPacketSize informa el tamaño máximo de un paquete para el endpoint cero. Todos los dispositivos deben soportar el endpoint cero.

. Los campos idVendor y idProduct son usados por el sistema operativo para hallar el controlador para el dispositivo. EL identificador de vendedor es asignado por el USB-IF.

. El campo bcdDevice tiene el mismo formato que el campo bcdUSB y es usado para proveer un número de versión del dispositivo. Este valor los asigna el desarrollador.

. Existen tres descriptores de string para proveer detalles del fabricante, producto y número de serie. No hay requerimientos para tener descriptores de string. Si no hay, se debe usar un índice cero.

. El campo bNumConfigurations define el número de configuraciones que el dispositivo soporta en la velocidad actual.

A.23. Descriptores de Configuración

Un dispositivo USB puede tener varias configuraciones diferentes, aunque la mayoría de los dispositivos son simples y tienen solo una. Los descriptores de configuración especifican como el dispositivo es alimentado, cual es el consumo de poder máximo, el número de interfaces que tiene. Por ejemplo, es posible tener configuraciones para cuando el dispositivo esté alimentado por el bus y para cuando el dispositivo se alimentado por su fuente principal.

Una vez que el host ha examinado todas las configuraciones, éste envía una comando SetConfiguration con un valor distinto de cero que iguala al campo bConfigurationValue de una de las configuraciones. Esto se hace para seleccionar la configuración deseada.

45

Offset

Campo Tamaño

Valor Descripción

0 bLength 1 Númerico Tamaño del descriptor en bytes1 bDescriptorType 1 Constant

eDescriptor de Configuración (0x02)

2 wTotalLength 2 Numérico Largo total de la configuración4 bNumInterfaces 1 Numérico Número de interfaces5 bConfigurationValu

e1 Numérico Valor que identifica la

configuración6 iConfiguration 1 Índice Índice del descriptor de string que

describe a esta configuración7 bmAttributes 1 Bitmap D7 - Alimentado por bus

D6 - Alimentación propiaD5 - Wakwup remotoD4..0 - Reservados

8 bMaxPower 1 mA Consumo máximo de poder

Cuando un descriptor de configuración es leído retorna la jerarquía completa, que incluye todos los descriptores de interfaz y de endpoints. El campo wTotalLength refleja el número de bytes en la jerarquía.

Figura A-15. Jerarquía de una configuración.

. El campo bNumInterfaces especifica el número de interfaces presentes en la configuración.

46

. El campo bConfigurationValue es usado por el comando SetConfiguration para seleccionar esta configuración.

. El campo iConfiguration es un índice de descriptor de string la configuración en formato legible por el ser humano.

. El campo bmAttributes especifica parámetros de alimentación de poder para la configuración. Si un dispositivo es alimentado por una fuente propia, ajusta D6. El bit D7 es usado en USB 1.0 para indicar que es una configuración alimentada por el bus, pero ahora es indicado por el campo bMaxPower. Si un dispositivo se alimenta desde el bus, aunque tenga fuente propia, debe informar su consumo de poder en bMaxPower. Los dispositivos también pueden soportar wakeup remoto, que permite a un dispositivo despertar al host cuando éste esta suspendido.

. El campo bMaxPower define la máxima corriente que el dispositivo drenará desde el bus. Se mide en unidades de 2 mA, así sólo se puede especificar un máximo de 500 mA. La especificación permite, a un dispositivo de alto consumo alimentado por bus, drenar no más de 500 mA desde Vbus. Si un pierde la alimentación externa, entonces, no debe drenar más del indicado en bMaxPower. Debe retornar respuesta de falla en cualquier operación que no pueda realizar sin fuente externa.

A.24. Descriptores de Interfaz

El descriptor de interfaz pude ser interpretado como un encabezamiento, o agrupación, de endpoints dentro de un grupo funcional que entrega una característica simple de un dispositivo. El descriptor de interfaz tiene el siguiente formato,

Offset

Campo Tamaño

Valor Descripción

0 bLength 1 Numérico Tamaño del descriptor en bytes1 bDescriptorType 1 Constant

eDescriptor de Interfaz (0x04)

2 bInterfaceNumber 1 Numérico Número de Interfaz3 bAlternateSetting 1 Numérico Valor usado para seleccionar ajuste

alternativo4 bNumEndPoints 1 Numérico Número de endpoints usados por

esta interfaz5 bInterfaceClass 1 Clase Código de clase6 bInterfaceSubClas

s1 Subclase Código de subclase

7 bInterfaceProtocol 1 Protocolo Código de protocolo8 iInterface 1 Índice Índice de descriptor de string que

describe esta interfaz

. El campo bInterfaceNumber indica el índice del descriptor de interfaz. Parte desde cero y se incrementa en uno por cada nuevo descriptor.

. El campo bAlternativeSetting puede ser usado para especificar una interfaz alternativa. Estas interfaces alternativas pueden ser seleccionadas con el comando SetInterface.

. El campo bNumEndpoints indica el número de endpoints usados por la interfaz. Este valor debe excluir el endpoint cero, también sirve para indicar el número de descriptores de endpoints que siguen.

47

. Los campos bInterfaceClass, bInterfaceSubClass y bInterfaceProtocol pueden ser usados para especificar las clases soportadas (por ejemplo: HID, comunicaciones, almacenamiento masivo, etc.). Esto permite a muchos dispositivos usar controladores de clase, previniendo la necesidad de escribir controladores específicos.

. El campo iInterface permite utilizar descripciones literales de la interfaz.

A.25. Descriptores de Endpoint

Los descriptores de endpoint son usados para los endpoints adicionales al cero. El endpoint cero siempre es usado como endpoint de control y es configurado incluso antes que se requiera cualquier descriptor. El host usa la información devuelta en estos descriptores para determinar el requerimiento de ancho de banda del bus.

Offset

Campo Tamaño

Valor Descripción

0 bLength 1 Numérico Tamaño del descriptor en bytes (7 bytes)

1 bDescriptorType 1 Constante

Descriptor de Endpoint (0x05)

2 bEndpointAddress

1 Constante

Dirección del endpoint, codificado como sigue:0..3 Número de Endpoint.4..6 Reservado.7 Dirección (ignorado para control) 0 = de salida, 1 = de entrada.

3 bmAttributes 1 Bitmap Bits 1..0 Tipo de transferencia 00 = Control 01 = Isócrono 10 = Masiva 11 = Interrupción

Bits 7..2 están reservados.En caso de ser endpoint isócrono,Bits 3..2 Tipo de sincronización 00 = sin sincronismo 01 = asincrónico 10 = adaptivo 11 = sincrónicoBits 5..4 Tipo de uso 00 = Endpoint de datos 01 = Endpoint de realimentación 10 = realim. explícita de datos 11 = Reservado

4 wMaxPacketSize 2 Numérico Máximo tamaño de paquete que el endpoint es capaz de enviar o recibir

6 bInterval 1 Numérico Intervalo de interrogación del endpoint para transferencias de datos. Valor en frames. Ignorado

48

para endpoints de control y masivos. Isócronos deben usar 1. Rango de 1 a 255 para endpoints de interrupción.

. El campo bEndpointAddress indica el numero de endpoint que este descriptor está describiendo.

. El campo bmAttributes especifica el tipo de transferencia. Este puede ser control, interrupción, isócrono o masiva. Si especifica un endpoint isócrono indica atributos adicionales como sincronización y tipo de uso.

. El campo wMaxPacketSize indica el tamaño máximo, de la carga de datos, para este endpoint.

. El campo bInterval es usado para especificar el intervalo de interrogación de ciertas transferencias. Las unidades se expresan en cuadros, así equivalen a 1ms para dispositivos de low y full speed y 125us para dispositivos high speed.

A.26. Descriptores de Strings

Los descriptores de string proveen información legible por el ser humano y son opcionales. Si no son usados, los campos índices de descriptores de string deben ser puestos a cero para indicar que no hay descriptor de string disponible.

Los string son codificados en formato Unicode y se pueden soportar múltiples idiomas. El string índice cero debe devolver una lista de los idiomas soportados.

Offset

Campo Tamaño

Valor Descriptor

0 bLength 1 Numérico Tamaño del descriptor en bytes1 bDescriptorTyp

e1 Constant

eDescriptor de string (0x03)

2 wLANGID[0] 2 Numérico Código de idioma soportado 0 (ejemplo: 0x0409 Inglés – Estados Unidos)

3 wLANGID[1] 2 Numérico Código de idioma soportado 1 (ejemplo: 0x0c09 Inglés – Australia)

5 wLANGID[2] 2 Numérico Código de idioma soportado 2 (ejemplo: 0x0407 Alemán – Estándar)

El descriptor de string anterior muestra el formato del descriptor cero. El host debe leer este descriptor para determinar los idiomas disponibles. Si un idioma está soportado, éste puede ser referenciado enviando el identificador del idioma en el campo wIndex de un comando GetDescriptor.

Todos los demás strings toman el formato siguiente,

Offset

Campo Tamaño

Valor Descriptor

0 bLength 1 Numérico Tamaño del descriptor en bytes

1 bDescriptorTyp 1 Constant Descriptor de string (0x03)

49

e e2 bString N Unicode String codificado en unicode

A.27. Paquetes de Ajuste

Cada dispositivo USB debe responder a los paquetes de ajuste enviados a través del conducto por omisión. Éstos son usados para detectar y configurar el dispositivo y llevar a cabo las funciones comunes tales como el ajuste de la dirección de los dispositivos USB, requerir un descriptor, o chequear el estado de un endpoint.

Un host USB conforme con el estándar espera que todos los requerimientos sean completados en un período máximo de 5 segundos. También, especifica un temporizado estricto para requerimientos específicos:

. Los requerimientos estándar sin etapa de datos deben ser completados en 50ms.

. Los requerimientos estándar con etapa de datos deben comenzar a devolver datos 500ms después del requerimiento.

. Cada paquete de datos debe ser enviado dentro de los 500ms desde la transmisión exitosa del paquete anterior.

. La etapa de estado debe ser completada dentro de los 50ms posteriores a la transmisión del último paquete de datos.

. El comando SetAddress (que contiene una fase de datos) debe procesar el comando y devolver un estado dentro de 50ms. El dispositivo entonces tiene

2ms para cambiar la dirección antes de que el siguiente requerimiento sea enviado.

Estos períodos de tiempo son bastante aceptables aún para los dispositivos más lentos, pero pueden imponer una restricción durante la depuración. Unos 50ms no son suficientes para enviar caracteres de depuración por una puerta serial asincrónica a 9600bps o para realizar un paso simple en depurador en circuito, o emulador, o quebrar la ejecución para examinar los registros internos. Como consecuencia, USB requiere algunas técnicas de depuración un tanto diferentes a las de otros microcontroladores.

Cada requerimiento comienza con un paquete de ajuste de 8 bytes, que tiene el siguiente formato,

Offset

Campo Tamaño

Valor Descripción

0 bmRequestType

1 Bitmap

D7 Dirección de Transferencia0 = Host a Dispositivo1 = Dispositivo a Host

D6..5 Tipo0 = Estándar1 = Clase2 = Vendedor3 = Reservado

D4..0 Recipiente0 = Dispositivo1 = Interfaz

50

2 = Endpoint3 = Other4..31 = Reservado

1 bRequest 1 Valor Requerimiento2 wValue 2 Valor Valor4 wIndex 2 Índice Índice6 wLength 2 Cuent

aNúmero de bytes a transferir, si hay fase de datos

. El campo bmRequestType determina la dirección del requerimiento, tipo de requerimiento y recipiente designado.

. El campo bmRequestType normalmente es analizado y el control se desvía a varias rutinas de manejo tales como: requerimiento estándar de dispositivo, requerimiento estándar de interfaz, requerimiento estándar de endpoint, requerimiento estándar de clase, etc.

. El campo bRequest determina el requerimiento a realizar. Otra manera de analizar el paquete de ajuste es primero analizar éste campo y luego analizar el tipo y el recipiente.

Los requerimientos estándar son comunes a todos los dispositivos USB, se describen en la sección siguiente. Los requerimientos de clase son comunes a clases de dispositivos. Por ejemplo, todos los dispositivos conforme con la clase HID tienen un conjunto común de requerimientos específicos de la clase, y son diferentes a los de un dispositivo conforme a la clase comunicaciones y diferentes a los dispositivos de la clase almacenamiento masivo.

Al final quedan los requerimientos específicos definidos por el fabricante. Estos son requerimientos que un diseñador de dispositivos USB puede asignar. Normalmente, son diferentes de dispositivo en dispositivo, se dejan a criterio de la implementación y la imaginación.

Un requerimiento común puede ser dirigido a diferentes recipientes y basado en el recipiente realizar una función diferente. Por ejemplo el requerimiento estándar GetStatus, puede ser dirigido al dispositivo, interfaz o endpoint. Cuando es dirigido al dispositivo devuelve flags indicando el estado indicando si es auto alimentado y si tiene wakeup remoto. Sin embargo, si el mismo requerimiento es dirigido a la interfaz siempre devuelve cero, y si es dirigido al endpoint devolverá el flag halt para el endpoint.

. Los campos wValue y wIndex permiten traspasar parámetros en el requerimiento. Y wLength es usado para especificar el número de bytes a ser transferidos en la fase de datos.

A.28. Requerimientos Estándar

La sección 9.4 de la especificación USB detalla los requerimientos de un dispositivo estándar que debe implementar cada dispositivo USB. El estándar provee una tabla que agrupa los ítems por requerimiento. Sin embargo, considerando que muchos firmware analizan los paquetes de ajuste por recipiente se reordenan, a continuación, basados en el recipiente.

51

A.29. Requerimientos Estándar de Dispositivo

Actualmente existen ocho requerimientos estándar de dispositivo, los que se detallan en la tabla siguiente.

bmRequestType

bRequest wValue wIndex wLength

Datos

1000 0000b GET_STATUS(0x00) Cero Cero Dos Estado0000 0000b CLEAR_FEATURE(0x01) Característic

aCero Cero No

0000 0000b SET_FEATURE(0x03) Característica

Cero Cero No

0000 0000b SET_ADDRESS(0x5) Dirección Cero Cero No1000 0000b GET_DESCRIPTOR(0x06) Tipo e Índice ID

lenguajeLargo Descripto

r0000 0000b SET_DESCRIPTOR(0x07) Tipo e Índice ID

lenguajeLargo Descripto

r1000 0000b GET_CONFIGURATION(0x08) Cero Cero 1 Valor0000 0000b SET_CONFIGURATION(0x09) Valor Cero Cero No

. El requerimiento GET_STATUS dirigido al dispositivo devuelve dos bytes durante la etapa de datos con el siguiente formato

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0Reservados Wakeu

premoto

Autoalimentado

Si D0 está puesto a 1 indica que el dispositivo es auto alimentado. Si es 0, está alimentado por el bus. Si D1 está puesto a 1, el dispositivo tiene habilitado wakeup remoto y puede despertar al host durante el estado de suspensión. Éste bit puede ser ajustado por los requerimientos SET_FEATURE y CLEAR_FEATURE con un selector de DEVICE_REMOTE_WAKEUP (0x01).

. Los requerimientos CLEAR_FEATURE y SET_FEATURE pueden ser usados para ajustar características booleanas. En el caso de dispositivos las únicas características disponibles son DEVICE_REMOTE_WAKEUP y TEST_MODE. El modo prueba permite al dispositivo exhibir varias condiciones, descritas en la sección 7.1.20 de la especificación USB.

. El requerimiento SET_ADDRESS es usado durante la enumeración para asignar una dirección única al dispositivo USB. La dirección es especificada en wValue y puede ser como máximo 127. Este requerimiento es único en el sentido que el dispositivo no ajusta su dirección hasta completar la etapa de estado. Todos los demás requerimientos se deben completar antes de la etapa de estado.

. Los requerimientos SET_DESCRIPTOR y GET_DESCRIPTOR son usados para devolver un descriptor específico en wValue. Un requerimiento por descriptor de configuración devuelve el descriptor del dispositivo y todos los descriptores de interfaz y endpoint en este requerimiento.

Los requerimientos GET_CONFIGURATION y SET_CONFIGURATION son usados para requerir o ajustar la configuración actual del dispositivo. En el caso de un requerimiento GET_CONFIGURATION, se devuelve un byte, en la etapa de datos, indicando el estado del dispositivo. Un valor cero significa que el dispositivo no está configurado y un valor diferente de cero indica que el dispositivo está configurado. SET_CONFIGURATION es usado para habilitar un dispositivo. Éste debe contener el

52

valor de bConfigurationValue del descriptor de configuración deseado en el byte menos significativo de wValue para seleccionar la configuración que se quiere habilitar.

A.30. Requerimientos Estándar de Interfaz

La especificación USB actual define cinco requerimientos estándar de interfaz que se detallan en la tabla siguiente.

bmRequestTye

bRequest wValue wIndex

wLength

Dato

1000 0001b GET_STATUS (0x00) Cero Interfaz

Dos Estado

0000 0001b CREAL_FEATURE (0x01) Característica

Interfaz

Cero No

0000 0001b SET_FEATURE (0x03) Característica

Interfaz

Cero No

1000 0001b GET_INTERFACE (0x0A) Cero Interfaz

Uno Alternativa

0000 0001b SET_INTERFACE (0x11) Alternativa Interfaz

Cero No

El campo wIndex es normalmente usado para especificar el número de la interfaz que afecta el requerimiento, cuando es un requerimiento dirigido a interfaz. Su formato es el siguiente

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0Reservados Número de Interfaz

. El requerimiento GET_STATUS es usado para devolver el estado de una interfaz. Este requerimiento debe devolver dos bytes 0x00, ambos están reservados para uso futuro.

. Los requerimientos CLEAR_FEATURE y SET_FEATURE son usados para ajustar características booleanas. Sin embargo, cuando el recipiente designado es la interfaz, la especificación USB 2.0 no define características.

. Los requerimientos GET_INTERFACE y SET_INTERFACE definen ajustes alternativos de la interfaz.

A.31. Requerimientos Estándar de Endpoint

Los requerimientos estándar de endpoint vienen en cuatro variedades que se detallan en la tabla siguiente

bmRequestType

bRequest wValue wIndex wLength

Dato

1000 0010b GET_STATUS (0x00) Cero Endpoint Dos Estado0000 0010b CREAL_FEATURE (0x01) Característic

aEndpoint Cero No

0000 0010b SET_FEATURE (0x03) Característica

Endpoint Cero No

1000 0010b SYNCH_FRAME (0x12) Cero Endpoint Cero Num. Cuadro

El campo wIndex es normalmente usado para especificar el número y dirección del endpoint, en los requerimientos dirigidos a endpoints. Su formato es el siguiente

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0Reservados Dir Reservados Número de

Endpoint

53

. El requerimiento GET_STATUS devuelve dos bytes indicando el estado (detenido/atascado) del endpoint. El formato de los dos bytes es el siguiente

D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0Reservados Halt

. Los requerimientos CLEAR_FEATURE y SET_FEATURE son usados para ajustar características de endpoints. El estándar define actualmente solo un selector de característica de endpoint, ENDPOINT_HALT (0x00), que permite al host atascar y limpiar un endpoint. Esta funcionalidad no se recomienda para el endpoint por omisión.

. El requerimiento SYNCH_FRAME es usado para reportar un cuadro de sincronización del endpoint.

A.32. Proceso de Enumeración

Enumeración es el proceso de determinar que dispositivos han sido conectados al bus y que parámetros requiere tales consumo de poder, número y tipo de endpoints, clase de producto, etc. El host, entonces, le asignará una dirección habilitará una configuración permitiendo al dispositivo transferir datos por el bus. Un proceso de enumeración bastante genérico se detalla en la sección 9.12 de la especificación USB. Sin embargo, cuando se escribe firmware USB por primera vez, es conveniente saber exactamente como responde el host durante la enumeración.

Una enumeración común en Windows involucra los siguientes pasos

1. El host, o hub, detecta la conexión de un nuevo dispositivo mediante el resistor de pull-up en el par de hilos de datos. El host espera al menos 100ms para que el enchufe esté insertado completamente y se estabilice.

2. El host emite un reset colocando al dispositivo en su estado por omisión. El dispositivo puede ahora responder a la dirección cero.

3. El host Windows pregunta por los primeros 64 bytes del descriptor del dispositivo.

4. Después de recibir los primeros 8 bytes del descriptor de dispositivo, inmediatamente emite otro reset.

5. El host ahora emite un comando SET_ADDRESS, colocando al dispositivo en el estado direccionado.

6. El host pregunta por todos los 18 bytes del descriptor de dispositivo.

7. Luego pregunta por los primeros 9 bytes del descriptor de configuración para determinar su tamaño total.

8. El host pregunta por 255 bytes del descriptor de configuración.

9. El host pregunta por cualquier descriptor de string, si son especificados.

Después del paso 9, Windows preguntará por el controlador para el dispositivo. Es común ver que requiere todos los descriptores nuevamente antes de emitir un requerimiento SET_CONFIGURATION.

54

El anterior proceso de enumeración es común en Windows 2000, Windows XP y Windows 98 SE. El cuarto paso muchas veces confunde la primera vez que se escribe firmware USB. El host pregunta por los primeros 64 bytes del descriptor de dispositivo, cuando el host repone el dispositivo después de recibir los primeros 8 bytes, es natural pensar que hay algún error con el descriptor o la manera como se está manejando el requerimiento. Sin embargo, solo cuando se implementa el comando SET_ADDRESS es posible comprender por que luego pide los 18 bytes del descriptor.

Normalmente cuando algo anda mal con el descriptor, o como éste es enviado, el host intenta leerlo tres veces con pausas largas entre requerimiento. Después del tercer intento el host desiste reportando un error con el dispositivo.

55

B. Sensores Biométricos

B.1 Introducción

Biometría es la ciencia de la medición, y análisis estadístico, de información biológica. Los sistemas biométricos son sistemas automatizados para verificar o reconocer la identidad de una persona viva basado en alguna característica fisiológica, como una huella dactilar o patrón del rostro, o algunos aspectos del comportamiento, como la escritura a mano o patrones de tecleo. Un sistema biométrico basado en características fisiológicas resulta más confiable, ya que las características fisiológicas son únicas y permanentes, mientras que las conductuales son únicas pero variables.

Algunas de las características biométricas mas usadas se muestran en la siguiente tabla

Tipo Tecnologías CaracterísticasFisiológicas Huella dactilar

Geometría de la manoExploración de retina e irisReconocimiento facial

Única y permanente

Conductuales

Patrones de vozVerificación de la firmaPatrones de tecleo

Única pero variable

Cuando se realiza una transacción la única forma de garantizar la presencia del propietario es usando características biométricas. En particular los sistemas basados en huellas dactilares resultan bastante efectivos cuando se trata de proteger información, y recursos, en un amplio rango de aplicaciones.

Actualmente, la cantidad de aplicaciones que emplean sistemas biométricos para asegurar transacciones es bastante limitado. Por un lado, existen barreras por la falta de familiaridad, o aceptabilidad, de la gente, pero probablemente la razón más importante del bajo desarrollo de los sistemas biométricos en el pasado fueron los costos de hardware y software, y el rendimiento insuficiente.

Sin embargo, la tecnología actual ha permitido el diseño de sistemas de bajo costo cuyo rendimiento los hace más adecuados para un amplio rango de aplicaciones. Generalmente, en el campo de los sistemas biométricos, se resuelven dos diferentes problemas:

. Verificación de la Identidad (o simplemente verificación) requiere que una persona declare su identidad, por ejemplo usando un PIN (personal identification number); en sistema calza directamente (1:1) la característica biométrica actual de la persona con la previamente adquirida que es recuperada por medio del PIN.

56

Figura B-1. Verificación de Identidad.

Figura B-2. Identificación.

. Identificación requiere que el sistema explore un conjunto de candidatos, y decida si uno de ellos calza con la persona a ser identificada. Obviamente, éste es un trabajo más difícil ya que requiere un calce (1:N), el cual puede ser computacionalmente muy caro en grandes bases de datos.

Antes que un sistema biométrico pueda ser empleado para verificar o identificar, todos los usuarios deben enrolados. Enrolar implica que individuo debe entregar una muestra de característica biométrica, la que es usada por el sistema para generar un modelo compacto, o patrón, que resume las características discriminantes. Dependiendo de la aplicación específica, los modelos pueden ser almacenados en una base centralizada,

57

pueden ser distribuidos por una red o pueden ser almacenados en un distintivo (como por ejemplo una tarjeta) entregado al usuario. Cada vez que el individuo requiere verificación o identificación, provee una nueva muestra de la huella dactilar y el sistema calza la instancia actual con modelo almacenado.

B.2 Rendimiento de los sistemas biométricos

Debido a diferencias de posicionamiento en sensor, a cambios ambientales, a deformaciones y ruido, es imposible que dos muestras de la misma característica biométrica, adquiridas en diferentes sesiones, coincidan exactamente; por esta razón el calce es realizado por un algoritmo que calcula una calificación de semejanza y compara ésta con un umbral de aceptación; en caso de que la semejanza sea mayor que el umbral el sistema anuncia que las dos muestras coinciden. A diferencia del calce de contraseñas, algunas veces la salida del sistema biométrico puede ser incorrecta: los principales errores del sistema son usualmente medidos en términos de de los siguientes conceptos:

. FRR (False Rejection Rate) es la frecuencia de rechazo relativa a la persona debió ser correctamente verificada. Cuando un usuario autorizado es rechazado debe presentar nuevamente su característica biométrica al sistema. Un falso rechazo no necesariamente significa un error del sistema; por ejemplo, en el caso de los sistemas basados en huella dactilar, la posición incorrecta del dedo en el sensor o suciedad pueden producir un falso rechazo.

. FAR (False Aceptance Rate) es la frecuencia de acceso fraudulento de los impostores que claman una falsa identidad.

Generalmente, FAR y FRR dependen del umbral de aceptación t, que es usado para ajustar el nivel de seguridad deseado, y están estrictamente relacionados. Más específicamente, FRR(t) es una función creciente y FAR(t) es una función decreciente, por lo tanto, si el umbral es aumentado para dificultar el acceso a los impostores, algunas personas autorizadas encontrarán que es más difícil ganar acceso.

Figura B-3. Funciones de Aceptación y Rechazo.

58

Otros índices de rendimiento comúnmente usados para evaluar los sistemas biométricos son:

. ERR (Equal Error Rate) denota el error del sistema cuando FRR = FAR.

. ZeroFAR denota FRR cuando FAR = 0.

. ZeroFRR denota FAR cuando FRR = 0.

B.3 Biometría versus Contraseña

El método más común de autentificación de usuarios se basa en una contraseña, esto es una secuencia de caracteres alfanuméricos que deben ser escritos a través de un teclado; difundidos ampliamente en aplicaciones bancarias están también los PIN. Desafortunadamente, se ha comprobado que éstos no son un método efectivo de autentificación, porque:

1. Si el usuario escoge su propia contraseña o PIN, normalmente escoge algo fácil de adivinar como la fecha del cumple año. El uso de nombres de hijos, de mascotas, números de casa, o teléfono, entre otras elecciones obvias, existe un 90% de posibilidades de ganar acceso a un sistema.

2. Cuando una contraseña es suficientemente compleja el problema de recordarla es, algunas veces, resuelto anotándola. Esto, pos supuesto, desafía el punto de tener algo que solo el usuario debe conocer. Una de cada tres personas anota el PIN de su tarjeta bancaria. Los usuarios más hábiles anotan la contraseña en forma cifrada (usando caracteres extra, permutaciones, o simples cambios aritméticos), pero desafortunadamente mas tarde olvidan la regla de encriptación.

3. Una contraseña puede ser robada por un individuo que observa al propietario durante el ingreso al sistema.

4. Una contraseña puede ser deliberadamente prestada a un colega, o amigo, a quien el propietario desea otorgar un cierto privilegio.

El encapsular la contraseña o un PIN en una tarjeta de banda magnética, o tarjeta inteligente, no obliga al usuario a recordar pero no hay ninguna manera de saber si fue el portador autorizado o alguien más quien fraudulentamente ha obtenido la tarjeta del usuario. O sea, las tarjetas u otros tokens pueden superar los problemas descritos en los punto 1 y 2, pero son inefectivas con respecto a los problemas descritos por los punto 3 y 4.

La única forma de resolver todos los problemas anteriores es mediante el uso de sistema biométricos para la autentificación de los usuarios, y garantizar la presencia del usuario en el lugar donde la transacción es realizada. De hecho, las características biométricas son muy difíciles de falsificar, y no pueden ser prestadas u olvidadas.

B.4 Las huellas dactilares

Bien conocidos son la permanencia y singularidad de las huellas dactilares. Históricamente, fueron usadas para firmar documentos legales, luego se usaron para identificación, a fines del siglo 19.

El primer sistema de identificación automático de huellas dactilares (AFIS) se desarrolló en los años 50 por el FBI, en cooperación con otros. Los avances de la tecnología, por

59

los años 80, en el área de la computación personal y los exploradores ópticos permitió el desarrollo de métodos de reconocimiento de huellas dactilares.

El enorme interés despertado por el comercio electrónico en Internet y, más en general, por la necesidad de técnicas confiables para la autentificación de personas vivas en un amplio rango de aplicaciones ha intensificado enormemente los esfuerzos de investigación a favor del desarrollo de sistemas biométricos de bajo costo y tamaño pequeño. Los sensores actuales están usando principalmente tecnología de píxeles de capacidad activa en un proceso estándar CMOS de 0.7 micrones. Se construye un arreglo bidimensional de micro-celdas en un chip de silicio, el que es tocado directamente por el dedo; cada micro-celda es capaz de leer un píxel de la huella dactilar. El tamaño del área sensible del scanner coincide exactamente con el tamaño del área de silicio.

B.5 Anatomía de la huella dactilar

Una huella dactilar es la representación de la epidermis del dedo. A nivel macroscópico, una huella dactilar está compuesta de un conjunto de aristas que a menudo fluyen en paralelo pero algunas veces producen macro-singularidades locales.

Estas singularidades, llamadas minucias, son esencialmente determinadas por la terminación o la bifurcación de las aristas. Estas minucias juegan un rol primordial en el calce de las huellas dactilares, ya que muchos de los algoritmos se basan en la coincidencia de minucias para declarar si dos impresiones son del mismo dedo o no.

Figura B-1. Anatomía de la huella dactilar.

Calce de minucias, que es esencialmente problema de calce de patrones de puntos, constituye la base de muchos algoritmos para la comparación de huellas dactilares.

Estos puntos son obtenidos desde la imagen de la huella y almacenados en una plantilla. Estas plantillas son más seguras que la propia imagen y protegen la privacidad ya que la imagen no se puede obtener a partir de ellas. La plantilla resulta mucho más pequeña que la imagen, 250 bytes contra 120 Kbytes por imagen, y pueden ser eficientemente almacenadas en áreas reducidas de memoria.

60

B.6 Enrolado y verificación

Cada celda del sensor (píxel) contiene un circuito de realimentación de capacidad activa cuya capacidad de realimentación efectiva es modulada por la presencia de la piel viva cerca de la superficie del sensor. Esta percepción de acercamiento activo provee una mejor inmunidad frente a efectos parásitos. Esto asegura una relación señal ruido superior y gran capacidad de capturar un amplio rango de huellas dactilares que las tecnologías de sensores pasivos.

La figura siguiente, muestra el proceso de un típico sistema biométrico.

Figura B-2. Proceso típico de sistema biométrico.

El proceso de enrolado. Antes de la verificación de la identidad de un individuo por medio de huellas dactilares, es necesario capturar una o varias muestras de la huella. Este proceso se llama enrolado. Las muestras son denominadas plantillas de la huella dactilar y pueden ser almacenadas en un amplio rango de medios tales como PC´s, servidores, tarjetas inteligentes y la memoria de un sistema embebido.

El proceso de verificación. Este proceso requiere que los usuarios que verifican su identidad pongan su dedo en el lector de huella. La huella dactilar viva es comparada con la plantilla almacenada usando algoritmos de calce. Si se produce un calce, se otorga acceso al usuario.

La superficie de cada píxel está compuesta de dos láminas metálicas adyacentes, que son separadas de la piel, y del ambiente, por una cubierta protectora ultra dura. Estas láminas del sensor crean una pequeña capacidad entre ellas cuyas líneas de campo se extienden más allá de la superficie del silicio. Cuando la piel viva es aproximada a las láminas del sensor, interfiere con las líneas de campo entre dos láminas y cambia la capacidad efectiva entre ellas. Cuando la piel está en la superficie del sensor (lomo de la huella) la capacidad de realimentación es minimizada, mientras que en los lugares alejados de la piel (valles de la huella) la capacidad de la huella es maximizada.

61

Figura B-3. Superficie del sensor.

El arreglo bidimensional de celdas es usado para capturar la imagen completa de la huella dactilar. El arreglo es accedido en forma aleatoria a través de decodificadores de filas y columnas, permitiendo funciones avanzadas como el muestreo en ventanas. La salida del arreglo sensor es pasada por etapas de acondicionamiento análogo permitiendo el ajuste de la ganancia, y offset, del sensor antes de que la señal sea convertida, por un conversor análogo a digital, en una señal digital de 8 bits.

62

C. El Modelo de Controladores de Windows

63

D. El Proveedor de Servicio Criptográfico de Windows

64

BIBLIOGRAFÍA

[1] Bruce Schneier, “Applied Cryptography”, John Wiley & Sons, Inc. 1996.

[*2] R.L. Rivest, A. Shamir, and L.M. Addleman, “A Method of Obtainig Digital Signatures and Public Key Cryptosystems”, Communications of the ACM, vol. 21, n.2, Feb 1978, pp. 120-126.

[*3] Whitfield Diffie and Martin Hellman, “New Directions in Cryptography”, IEEE Transactions on Information Theory, vol. IT-22, Nov. 1976, pp, 644-654.

[*4] T. El Gamal, “A Public-Key Crypto System and a Signature Scheme Based on Discrete Logarithms”, Advances in Cryptography: Proceedings of CRYPTO 84, Springer-Verlag, 1985, pp 10-18.

[2] USB Implementers Forum, “Universal Serial Bus Specification revision 2.0”, Abril 27, 2000.

[3] USB Implementers Forum, “Device Class Definition for HID version 1.11”, Junio 27, 2001.

[4] John Hyde, “USB Design by Example, Second Edition”, Intel Press, 2001.

[5] Jan Axelson, “USB Complete, Second Edition”, Lakeview Research LLC, 2001.

[] http://www.rsasecurity.com/rsalabs[] http://www.usb.org

65