UNIVERSIDAD AUTÓNOMA METROPOLITANA U n i d a d A z c a p o t z a l c o

UN MÉTODO PARA AUMENTAR LA SEGURIDAD DE LA INFORMACIÓN

EN LAS REDES TCP/IP, USANDO TARJETAS INTELIGENTES

TESIS PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACION

PRESENTA

ING. ENRIQUE RODRÍGUEZ DE LA COLINA

Asesor: Dr. ROSSEN PETROV POPNIKOLOV

Jurado: Dr. GUILLERMO MORALES LUNA Dr. ROSSEN PETROV POPNIKOLOV

Jurado Externo: Dr. JUAN CARLOS SANCHEZ GARCÍA

CIUDAD DE MÉXICO, MARZO DEL 2003.

2

AGRADECIMIENTOS

RESUMEN Como medio para aumentar la seguridad de la información en las redes de datos de TCP/IP y más específicamente en Internet, se aplican las funciones de Tarjetas Inteligentes (TI). La Internet, red que trabaja sobre los protocolos de comunicación TCP/IP, ofrece una gama de servicios, en los cuales es necesario contar con mecanismos para garantizar la autenticidad, la autorización de acceso, la integridad y la confidencialidad de la información. La TI por su capacidad de procesamiento y almacenamiento de información, es la herramienta ideal para lograr la seguridad requerida. La norma IS0-7816 clasifica dichas tarjetas en tres grupos: Tarjetas de Memoria (TM), Tarjetas Lógicas (TL) y Tarjetas Inteligentes (TI). Los tres tipos tienen un Circuito Integrado (CI) incrustado con memoria EPROM1. Las Tarjetas Inteligentes (TI), contienen además un microcontrolador programable y memoria operativa RAM. Las primeras aplicaciones con TI surgen como una necesidad de manejar el dinero electrónicamente y reducir el fraude en pequeñas transacciones. De ahí se parte con aplicaciones desarrolladas con tarjetas de memoria y que más tarde motivarían a los diseñadores para crear mejores aplicaciones con tarjetas más poderosas. La tecnología de las TI está desarrollándose muy rápidamente en la actualidad y en distintas aplicaciones. Para poder hacer uso de la tarjeta inteligente como un sistema de seguridad fue necesario desarrollar distintas fases: Fase 1: Resolver la forma en la que la TI se acopla como un dispositivo externo a una PC. Se investigó sobre los distintos lectores de TI y se estudió la forma de conectarlos. Finalmente se utilizó un tipo de lector portátil que se conecta al puerto serie, se desarrolló un programa para mandar datos al lector y que éste a su vez los interpretara. 1 EPROM Memoria programable borrable de las siglas "Electrically Eraseble Programmable Read Only Memory"

4

Para conectar el lector seleccionado a la PC, fue necesario el uso de controladores que el mismo fabricante ha desarrollado. Fase 2: Estudio de la TI para poder programarla y saber cómo usarla, para esto se debe entender a la TI como un sistema mínimo de cómputo que cuenta con un microprocesador, memoria RAM, memoria ROM y un sistema operativo propietario. Antes de su utilización las TI se encuentran en un estado virgen el cual debe ser configurado con los parámetros de inicio. Una vez configurada la TI se desarrolla una aplicación dentro de la tarjeta que consiste básicamente en crear directorios adecuados a la información que se va a manejar. Fase 3: Se inicia con la creación de un programa en lenguaje C que usa las DLL (Dynamically Linked Library) tanto del lector como de las TI y que son propietarias del fabricante. En esta etapa del desarrollo del software, surgió la necesidad de crear una plataforma más general por lo tanto se convirtieron las DLL que están compiladas en el lenguaje de programación VisualTM C++ y se pasaron al lenguaje desarrollado por Borland, BuilderTM C++. Fase 4: La cuarta fase del desarrollo contiene dentro del programa de C el código con el cual se envían los comandos al lector para que éste los transmita a la tarjeta. Dichos comandos corresponden a las instrucciones que las TI debe ejecutar y están basados en el estándar de ISO2 que corresponde a la parte de comunicación. Fase 5: El programa de interfaz combina el desarrollo y uso de los comandos de control de la tarjeta, el lector y las pantallas de interacción con el usuario. La aplicación programada en la PC en conjunto con la programación de la TI son la base para desarrollar un método en el cual se combinan dos algoritmos de encriptamiento (RSA3 y DES4), hardware y software. Esto es significativamente más seguro con respecto a un método que sólo se haya desarrollado con software y que utiliza un solo algoritmo de encriptamiento. Como nota del presente trabajo debe quedar claro que se intenta promover el uso de las TI como una opción de nuevas tecnologías y no hacer pública la información confidencial y registrada con derechos de autor del fabricante. El lector y las TI utilizadas son parte del objetivo general de la tesis sin embargo el utilizar diferentes marcas o modelos de lectores y TI, no afecta en esencia el resultado. Este trabajo tiene por objetivo el demostrar que se puede incrementar la seguridad de la información transmitida combinando varios métodos y que está abierto para continuar en esta rama de investigación proponiendo como herramienta las TI o el uso de hardware que permita aislar parte de la información del sistema que la esté generando. También es posible complementar este trabajo combinando nuevos métodos de encriptamiento que demuestren ser más seguros.

2 (International Standars Organization)

3 RSA (Rivest, Shamir y Adleman),

4 Encriptamiento de Datos Estándar (Data Encryption Standard)

CONTENIDO RESUMEN iv ÍNDICE DE ILUSTRACIONES vi ABREVIATURAS Y ACRÓNIMOS vii

1. ANTECEDENTES 8 1.1. INTRODUCCIÓN 10 1.2. PLANTEAMIENTO 11 1.3. OBJETIVO PRINCIPAL 12

2. BASES TEÓRICAS DEL DESARROLLO 13 2.1. DESCRIPCIÓN DE TARJETAS INTELIGENTES 13 2.2. CRIPTOGRAFÍA 18 2.3. TCP/IP 31 2.4. CONCLUSIONES DEL CAPÍTULO 40

3. TRABAJO DESARROLLADO 42 3.1. COMPONENTES Y EQUIPO PARA EL DESARROLLO 44 3.2. PROGRAMACIÓN DE LA APLICACIÓN 63 3.3. DESCRIPCIÓN DE LA APLICACIÓN 69 3.4. RESULTADOS Y COMENTARIOS 76 3.5. CONCLUSIONES DEL CAPÍTULO 77

4. CONCLUSIONES 78

5. BIBLIOGRAFÍA 79

ANEXO A. DESARROLLO DE SOCKETS 82

ANEXO B. EJEMPLO DE APLICACIÓN CON TI 101

ANEXO C. CÓDIGO DE LA PANTALLA DEL MENÚ 109

ÍNDICE DE ILUSTRACIONES Fig. 2.1: Elementos contenidos en la Tarjeta Inteligente 14 Fig. 2.2: Encriptamiento y desencriptamiento, sistema de llaves secretas, simétrico 19 Fig. 2.3: Sistema de llaves privadas y públicas propuesto 20 Fig. 2.4: Integridad de los datos por medio de funciones de dispersión "Hashing" 21 Fig. 2.5: Envío de llave secreta encriptada con RSA y archivo con DES 22 Fig. 2.6: Diagrama de flujo simplificado del Algoritmo RSA 26 Fig. 2.7: Forma de los paquetes UDP 36 Fig. 2.8: Forma de los paquetes TCP 36 Fig. 2.9: Cabecera IP 37 Fig. 2.10: Cabecera TCP 37 Fig. 3.1: Niveles de directorios dentro de la TI 43 Fig. 3.2: Diagrama de conexión, lector de TI a la PC. 44 Fig. 3.3: Lector Reflex 72 45 Fig. 3.4: Descripción de la TI, Cryptoflex 50 Fig. 3.5: Personalización de la TI 52 Fig. 3.6: Archivos de la TI antes de personalización 52 Fig. 3.7: Archivos de la TI después de la personalización 53 Fig. 3.8: Formato de los comandos de entrada y salida de las TI 54 Fig. 3.9: Niveles de software que controlan a las TI 55 Fig. 3.10: Dos llaves secretas por sesión para aplicar 3DES y posteriormente encriptadas con RSA 65 Fig. 3.11: Diagrama a bloques de como se relacionan las partes programadas 66 Fig. 3.12: Diagrama de flujo de la aplicación 67 Fig. 3.13: Pantalla de C++, con las formas que integran una de las pantallas de la aplicación 68 Fig. 3.14: Etapas que describen el proceso de la aplicación desarrollada 69 Fig. 3.15: Pantalla de inserción de TI en el lector 69 Fig. 3.16: Acceso Negado por error en NIP o por no detectar una TI 70 Fig. 3.17: Pantalla de solicitud para teclear el NIP 70 Fig. 3.18: Selección de archivo a ser encriptado 71 Fig. 3.19: Pantalla del proceso de encriptamiento 72 Fig. 3.20: Fragmento de 16 líneas del encriptamiento del número 1 visto en Winword 72 Fig. 3.21: Se observa archivo plano a la izquierda y archivo encriptado a la derecha 73 Fig. 3.22: Pantalla del menú de encriptamiento y desencriptamiento 73 Fig. 3.23: Archivo plano observado con analizador de protocolos al ser enviado 74 Fig. 3.24: Pantalla que muestra el archivo encriptado con la ayuda de un analizador de protocolos 75

7

ABREVIATURAS Y ACRÓNIMOS 3DES (Triple DES) DES, aplicado 3 veces ver cap. 2 página 25

API Application Program Interface

CBC Encadenamiento de Bloques Encriptados (Cipher Block Chainig)

CI Circuito Integrado. Dispositivo electrónico de integración a gran escala de

componentes “Chip” DES Encriptamiento de Datos Estándar (Data Encryption Standard)

DLL Ligas a librerías dinámicas (Dynamically Linked Library)

DNS Servicio de Nombres de Dominio (Domain Name Service)

EPROM Memoria ROM programable borrable de las siglas (Electrically Eraseble

Programmable Read Only Memory) FTP Protocolo de Transferencia de Archivos (File Transfer Protocol)

ICMP Protocolo de Control de Mensaje de Internet (Internet Control Message

Protocol) IP Protocolo de Internet (Internet Protocol)

ISO Organización Internacional para la Estandarización (International Organization

for Standarization) MAC Código de Autenticidad del Mensaje (Message Authenticity Code)

NAT Traducción de Direcciones de Red (Network Address Translation)

RAM Memoria de Acceso Aleatorio (Read Access Memory)

ROM Memoria de sólo lectura (Read Only Memory)

RSA Rivest, Shamir y Adleman

SHA-1 Algoritmo de funciones de dispersión "Hash" Seguro 1 (Secure Hash

Algorithm-1)

TCP/IP Transport Control Protocol / Internet Protocol, veáse página 31

UDP Protocolo de Datagrama de Usuario (User Datagram Protocol)

8

1. ANTECEDENTES

Las primeras aplicaciones con TI surgen como una necesidad de manejar el dinero electrónicamente y reducir el fraude en pequeñas transacciones realizadas por miles de personas, estas transacciones al acumularse durante el día representan grandes cantidades de dinero, un ejemplo real de esta necesidad se tuvo en Francia con los teléfonos públicos en los años 80’s. De ahí se parte con aplicaciones desarrolladas con tarjetas de memoria; estas más tarde motivarían a los diseñadores para crear mejores aplicaciones con tarjetas más poderosas que contaban con los primeros microprocesadores encapsulados en un “chip”. Podemos decir que las Tarjetas Inteligentes o “smartcards” del idioma inglés, son realmente pequeñas computadoras en tamaño, pero no en capacidad de almacenamiento y procesamiento. Al demostrarse la utilidad de éstas, se creó un nivel sin precedente de uso mundial y se establecieron estándares con respecto a la tarjeta misma, a los equipos con los que opera y al ambiente en el que se utiliza. Posteriormente las TI se estandarizaron en el ISO (International Standars Organization), el IEC (International Electrotechnical Commission) y en el ANSI (American National Standars Institute). Cuando surgieron las primeras TI se utilizaron como monederos electrónicos que proporcionaron beneficios adicionales como el control de fraude en operaciones de crédito y débito, el acceso controlado o restringido a instalaciones como fábricas o edificios, el almacenamiento de información médica importante, aplicaciones para el uso controlado de canales satelitales o por cable y pases para transporte en trenes, autobuses y aviones, entre otros. En este trabajo se plantean las TI como una herramienta de encriptamiento y seguridad en redes ya que permiten el almacenaje de llaves de encriptamiento y códigos de acceso sin la necesidad de recordarlos o inclusive conocerlos. Entre otras funciones importantes, las TI permiten aplicar distintos algoritmos de encriptamiento o llaves de encriptamiento, generar y reconocer “Números de Identificación Personal” (NIP), accesos a sistemas con un nombre de usuario conocido como “Login” y contraseña de entrada “password”. De este modo se transmiten datos de forma más segura a través de las redes de computadoras en general y específicamente en las redes basadas en los protocolos de TCP/IP5. Después de ser enviada la información cifrada o encriptada, el nodo-receptor puede desencriptar la información, 5 TCP/IP : (Transport Control Protocol / Internet Protocol), veáse sección 2.3

9

haciendo uso de otra tarjeta inteligente que contenga las llaves y algoritmos correspondientes para desencriptar dicha información. La plataforma de operación para el proyecto es el conjunto de protocolos TCP/IP, utilizado en Internet. Internet representa la interconexión de la mayoría de las redes de computadoras utilizando equipos ruteadores, que cuentan con un sistema de direccionamiento común y un conjunto de protocolos de comunicación común. Como es sabido, los protocolos son reglas que controlan el comportamiento de los equipos y de los programas en las redes de computadoras y que rigen la Internet, Intranets y Extranets. Las cuatro capas utilizadas en TCP/IP son:

• Interfaz con la Red • De Red • Transporte • Aplicación

Los protocolos de todas y cada una de estas capas trabajan en conjunto para poder transmitir la información hasta el lado opuesto. Los protocolos más comunes en TCP/IP son: el IP, "Internet Protocol" que trabaja en la capa de red, transportando la información entre redes; el TCP (Protocolo de Control de la Transmisión) que trabaja sobre la capa de transporte y es el encargado de mover la información entre puntos finales6; el UDP (Protocolo de Datagramas del Usuario) que trabaja sobre la capa de transporte, lleva información entre los puntos finales de la comunicación. Otro protocolo es el ICMP (Protocolo de Control de los Mensajes de Internet), el cual transporta los mensajes de los errores en la red y se usa para notificar condiciones anormales. Dentro de las redes que trabajan con TCP/IP se encuentra la Internet, una red de alcance mundial y con libre acceso que actualmente carece (casi por completo) de las funciones de seguridad en la transmisión de la información. Algunos puntos importantes relacionados con el tema de la seguridad de la información que deben ser considerados son:

- La protección de la integridad de la información. - La protección de la disponibilidad de la red. - La protección de la confidencialidad de la información.

Al proponer una solución a estos problemas entramos al amplio tema del encriptamiento, de la autenticidad y de hacer privada la información por medio de TI. Tener una forma de asegurar la integridad de la información en la red es de suma importancia tanto para los usuarios, como para los diseñadores de programas. De no existir la protección necesaria, la información estaría expuesta ante cualquier usuario con intenciones de indagar, alterar o borrar cualquier dato transmitido, lo que representa un alto riesgo, pérdida de tiempo y dinero.

6 Entiéndase por puntos finales, (los nodos en comunicación).

10

1.1. INTRODUCCIÓN Una Tarjeta Inteligente (TI) es una tarjeta de plástico, que tiene las dimensiones de una tarjeta bancaria según los estándares internacionales. Contiene un Circuito Integrado (CI) que es un microprocesador incrustado. Este microprocesador hace la diferencia entre la Tarjeta Inteligente y las demás tarjetas con Circuitos Integrados, también conocidas como "tarjetas chip" que sólo cuentan con memoria. La norma IS0-7816 clasifica dichas tarjetas en tres grupos: Tarjetas de Memoria (TM), Tarjetas Lógicas (TL) y Tarjetas Inteligentes (TI). Los tres tipos tienen un CI incrustado con memoria EPROM7. Las TI, contienen además un microcontrolador programable y cierta cantidad de memoria operativa RAM. En el caso de las TI, el microprocesador puede procesar diferentes tipos de información y por consiguiente diversas industrias están interesadas en su versátil uso. Inicialmente el sistema operativo, el lenguaje ensamblador y el software de aplicación de las TI, eran un secreto y solamente se utilizaban para fines militares, pero hoy en día están presentes en los estándares de la ISO8 y ANSI9 y son desarrollados por empresas como Bull CP8, Gemplus-DataCard, SCS, ORGA Giesecke&Devrient, Schlumberger entre otras. Compañías importantes, tales como: Microsoft, IBM, HP, Siemens, están desarrollando tecnología propia para integrar las TI en sus productos de redes más novedosos, por lo que se espera que sean un modelo a seguir dentro de la gama de aplicaciones que ofrecen. Hay múltiples aplicaciones que involucran una TI como almacenamiento de dinero para realizar pagos de servicios; por ejemplo: en estacionamientos, gasolineras, lavanderías, teléfonos públicos, transporte, teléfonos celulares, compras en Internet, control de accesos. Por todas estas aplicaciones y muchas más, están consideradas como una herramienta indispensable en el futuro del comercio electrónico.

Las TI pueden comunicarse a través de un lector con una gran variedad de dispositivos como: terminales punto de venta, cajeros automáticos, computadoras personales10, teléfonos celulares, teléfonos públicos, dispositivos de acceso a edificios, etc. y pueden ejecutar transacciones seguras a través de Internet. Actualmente se están desarrollando programas para controlar planes de pago con la tarjeta inteligente en diferentes países del mundo y proyectos con TI que integran aplicaciones como el registro de personas, hospedajes, control de comidas, accesos a eventos, reservaciones, compra de productos en máquinas automáticas, etc. 7 EPROM Memoria programable borrable de las siglas "Electrically Eraseble Programmable Read Only Memory"

8 ISO (International Standars Organization)

9 ANSI (American National Standars Institute).

10 Computadoras Personales, “Personal Computers” (PC)

11

En algunos países la tarjeta se utiliza en servicios para los estudiantes en las universidades incluyendo: acceso al campus, identificación para inscripciones, pago de fotocopias, cafetería, gimnasios, almacenamiento de datos como horarios, calificaciones, etc. También otros países han optado por ofrecer el pago de servicios con el uso de TI a través de cajeros electrónicos o vía Internet. En fin, existe una gran variedad de transacciones que se realizan con el uso de TI, en México se ha instalado un monedero electrónico para realizar compras desde los teléfonos públicos o cualquier equipo de cómputo conectado en red. Como se puede observar las TI representan un sin número de aplicaciones que algunos países ya están desarrollando rápidamente dando pie a la creatividad de los fabricantes de hardware y software para las necesidades del futuro, como son el almacenamiento más rápido y eficiente o nuevas aplicaciones de seguridad que es el tema de esta tesis. Seguridad con Tarjetas Inteligentes Las TI pueden ofrecer altos niveles de seguridad, por ejemplo: en la transmisión de información y en las transacciones electrónicas que operan en ambientes tan abiertos como la Internet, Intranets y redes bancarias. En las TI se tiene la facilidad de implementar algoritmos como el DES, 3DES y RSA (1024 bits) que pueden usarse para proteger los datos transmitidos y que incluyen procesos de autenticidad, manejo de códigos secretos y firmas electrónicas. Como ya se había mencionado anteriormente, las TI cuentan con toda la potencia de un microprocesador integrado que puede almacenar llaves criptográficas y certificados electrónicos, esto representa una forma más segura de almacenamiento con respecto a un disco duro, el cual pudiera llegar a fallar, ser dañado con virus o sufrir pérdida de información por errores humanos. Otro factor a favor en las TI es la facilidad de portar consigo una identificación electrónica lista para ser utilizada en cualquier sistema que se le requiera o para agilizar la marcación de números telefónicos remotos, el acceso a direcciones de red o almacenamiento de información importante. 1.2. PLANTEAMIENTO La idea principal del proyecto es: utilizar Tarjetas Inteligentes y sus lectores correspondientes para mejorar la seguridad en las redes TCP/IP. Se usaron TI, con funciones criptográficas. El lector se conecta a cualquier PC, por medio de su puerto serial, sirviendo de interfaz entre la Tarjeta Inteligente y la computadora (PC). Una vez instalado el lector, se puede hacer uso de la TI, para la transportación de información encriptada que viaja por la red de forma más segura. La Internet, ofrece una gama de servicios, en los que es necesario garantizar la seguridad de la información ya que se desarrolló para un ambiente abierto completamente. La TI, por su capacidad de procesamiento y almacenamiento de información independiente del hardware de la red, nos brinda la herramienta ideal para lograr la seguridad requerida y el almacenaje de llaves de encriptamiento.

12

Las partes desarrolladas son: la instalación del lector en la PC, el desarrollo de un programa con interfaz para el usuario final que controle las funciones de la tarjeta inteligente y las funciones del lector de tarjetas en las aplicaciones de encriptamiento y desencriptamiento. En este proyecto están involucradas varias áreas de las ciencias de la computación, como son: el conocimiento de redes de computadoras, el conocimiento de TCP/IP, la arquitectura de computadoras como son los puertos serie y la arquitectura del sistema mínimo de computadora que representa la TI, el diseño de programas de uso específico en lenguaje propietario de la TI y en C, la lógica digital, la electrónica en general y la criptografía. 1.3. OBJETIVO PRINCIPAL Diseñar y desarrollar un programa de aplicación para el encriptamiento, utilizando Tarjetas Inteligentes (hardware), con un enfoque para lograr mayor seguridad en la transmisión de información, en las redes TCP/IP.

1.3.1. OBJETIVOS PARTICULARES • Analizar los algoritmos de seguridad en la transmisión de datos, para ser desarrollados con las

herramientas que la TI y el software de programación desarrollado proporcionan, con un enfoque hacia el encriptamiento, la confidencialidad y la autenticidad de la información.

• Crear y ejecutar los algoritmos necesarios, a fin de generar una aplicación para mejorar la

seguridad en la transmisión de información en las redes TCP/IP.

1.3.2. ALCANCE En este proyecto se desarrolló un programa para una aplicación con TI, enfocado a la seguridad de la información transmitida en redes TCP/IP encriptándola. No existe programa similar en nuestro país, por lo que representa una aportación al uso de las TI en la transmisión segura de datos. El criptoprocesador que tiene la TI aprovecha las ventajas de los algoritmos RSA y triple DES que al combinarlos, proporcionan la seguridad que se requiere en una red mundial como la Internet. Este método al combinar dos algoritmos de encriptamiento y utilizar software y hardware representa una innovación a nivel Nacional. De acuerdo a la investigación realizada hasta el momento no hay un procedimiento fidedigno que asegure su invulnerabilidad con recursos y tiempo limitado.

13

2. BASES TEÓRICAS DEL DESARROLLO

2.1. DESCRIPCIÓN DE TARJETAS INTELIGENTES La función básica de las Tarjetas Inteligentes, es la de almacenar la información de forma visual, tangible y electrónica, que identifique a su portador y que pueda sustentar las transacciones que sean posibles y válidas. La información visual sobre la TI, puede presentarse por medio de gráficos, fotografías, hologramas o códigos de barras. Es tangible por medio de realzado y electrónica, a través de mecanismos como: bandas magnéticas, que se siguen usando en las tarjetas de crédito o bien por medio de un Circuito Integrado (CI) incrustado, el cual es su principal característica. La TI es la transición de una tarjeta de identificación a una “ficha de identificación” capaz de protegerse a sí misma al intentar ser falsificada, en caso de robo o pérdida. Tiene diversas ventajas sobre las tarjetas de banda magnética, es más resistente a variables externas, como campos magnéticos, además de que tiene la capacidad de alcanzar mejor desempeño que las tarjetas de crédito convencionales. El ISO/IEC 7810, define las características físicas de las tarjetas de identificación, las dimensiones generales y forma establecidas para las “Tarjetas de Crédito” y para las Tarjetas Inteligentes. Existen estándares para el uso de TI en aplicaciones específicas como salud, transportación, en la banca, comercio electrónico e identidad. También existen estándares para nuevos tipos de TI, lo cual nos confirma que el ISO 7816 no es el único. El ISO 7816 define las características de la Tarjeta Inteligente como son:

• Características físicas, dimensiones y posición de los contactos • Señales electrónicas • Protocolos de transmisión • Comandos de instalación • Sistema numérico y procedimiento de registro

14

La TI, es una tarjeta plástica de alto desempeño, es rectangular de 85.6 mm de ancho por 53.98 mm de alto y 0.76 mm de espesor. Contiene un circuito integrado incrustado en el frente que debe medir 2 mm de ancho por 1.7 mm de alto. En cuanto a la comunicación entre la Tarjeta Inteligente y el lector, a la TI se le denomina como esclavo y al lector como maestro. Esto se refiere a que la comunicación es regida por el lector y que la tarjeta debe responder de acuerdo a éste. El canal de comunicación es de un sólo conducto, una vez que el lector envía un comando a la tarjeta inteligente, ésta se bloquea hasta que recibe una respuesta de que los contactos están correctamente alineados, previendo un serio daño. Cuando el lector detecta que los contactos ya están alineados la energía es enviada a la TI.

2.1.1. CARACTERÍSTICAS FÍSICAS DE UNA TARJETA INTELIGENTE Las TI, también llamadas tarjetas de seguridad inteligentes del inglés –“intelligent secure card”, “chip card” o “smart card”, presentan una gran variedad de facetas, dependiendo principalmente del tipo de circuito integrado "chip" incrustado en la parte plástica y de los tipos de mecanismos de conexión entre la tarjeta y el lector de tarjetas. Una necesidad de crear las TI fue la de poder almacenar información de forma segura y práctica para realizar ciertas actividades. Estas características se desarrollaron con base a los principales elementos contenidos en cualquier sistema de cómputo, como se muestra en la figura 2.1.

Fig. 2.1: Elementos contenidos en la Tarjeta Inteligente

Específicamente todos los componentes básicos de un sistema de cómputo están incorporados dentro de un Circuito Integrado. Las conexiones físicas entre los componentes del CI están cubiertas con una estructura monolítica de silicio.

15

El alto nivel de integración de los componentes del CI de la tarjeta dificulta que las señales que pasan a través de los componentes del CI sean interceptadas. Por lo tanto, la interconexión obtenida resulta ser más segura que un sistema de cómputo con conexiones físicas macroscópicas entre los componentes. En adición al seguro intercambio de información entre los módulos que componen el sistema del CI, las pequeñas dimensiones de éste permiten montar el CI en una tarjeta plástica de dimensiones similares a la de una de crédito bancario. Cuando se inserta el CI en una tarjeta bancaria, el portador somete a la tarjeta a diferentes esfuerzos físicos, transportándola de un lado a otro, por ejemplo: en un bolsillo del pantalón; este tipo de fuerzas afectan a un sistema de cómputo convencional que tiene la unión de sus partes con alambrado o pistas de conducción macroscópicas. Sin embargo, a un diseño microscópico, no le afectan este tipo de fuerzas por tener todos sus componentes integrados. Para lograr el menor tamaño del CI, es necesario tomar en consideración la resolución de la tecnología utilizada para crear el chip, la cual se caracteriza por lo siguiente: • La llamada "medida característica", (por ejemplo; el tamaño de un sólo transistor integrado

dentro del CI) unidad en micrones. • El ancho del "bus" interno del procesador, es decir, si es de 8 bits, 16 bits, 32 bits o 64 bits. • El tipo de memoria utilizado; por ejemplo: RAM, ROM, EPROM. • Elementos auxiliares tales como: filtros de voltaje, potencia, frecuencia de alimentación y los

registros en el mapa de memoria.

2.1.2. SEGURIDAD OFRECIDA POR LA TARJETA INTELIGENTE Ante todo una Tarjeta Inteligente es esencialmente una plataforma de computación segura, esto es un lugar a salvo para información valiosa tal como llaves privadas, números de cuenta, contraseñas “passwords”, o el historial médico. También es una plataforma de procesamiento segura, es decir, es el lugar adecuado para realizar el procesamiento de la información sin exponerla al mundo externo. Ejemplos de ello serían procesamiento de llaves criptográficas públicas y privadas. Así es como se puede afirmar que las TI proporcionan el más seguro acceso a redes de computadoras utilizando sistemas con tecnología de llaves públicas. Uso de la Tarjeta Inteligente a través de la infraestructura de la red La tarjeta genera y almacena el par de llaves privada y pública, puede procesar el encriptamiento y desencriptamiento de los datos, además puede almacenar certificados electrónicos, aplicaciones específicas y/o datos adicionales.

16

2.1.3. SOFTWARE DE LAS TARJETAS INTELIGENTES Existen fundamentalmente dos tipos de software en las TI: El primero, es el software en el servidor, el cual consta de una serie de programas que corren en una computadora conectada a una Tarjeta Inteligente y que también se conoce como el software del lado del lector de tarjetas. La mayor parte de las tarjetas trabajan con el software en el servidor, éste se escribe en una computadora o en estaciones de trabajo "workstations", incorporando a la TI dentro de su sistema. El software del servidor normalmente es una aplicación para el usuario final quien tiene interacción con los diferentes niveles de acceso de los lectores de la Tarjeta Inteligente, en resumen el software en el servidor incluye todo el soporte de la infraestructura administrativa de la tarjeta. El software en el servidor se escribe en lenguajes de programación de alto nivel que se encuentran en las estaciones de trabajo, por ejemplo: lenguaje C, C++, Java, BASIC, COBOL, PASCAL, o FORTRAN y están mezclados con librerías y dispositivos de entrada/salida para el manejo de accesos e interconexión de los lectores de TI. El segundo, es el software de la tarjeta, el cual como su nombre lo indica corre la aplicación sobre la tarjeta misma, por lo que es denominado también como “software del lado de la tarjeta”. Este software está catalogado como "las funciones y el software de aplicación del sistema operativo de la tarjeta". Para muchas aplicaciones es suficiente el software incluido en la tarjeta pero en ocasiones es requerida una aplicación específica la cual puede ser desarrollada en lenguaje ensamblador o lenguaje de alto nivel. El software de aplicación utiliza la capacidad de cómputo y almacenamiento de datos que tiene la tarjeta, haciéndolos relativamente independientes de la integridad de otra máquina, lo que aumenta la seguridad. El software del servidor sustituye a la tarjeta para un desarrollo alternativo de la misma aplicación. Por ejemplo, cuando un historial médico es guardado fuera de la tarjeta en un lugar como un disco duro o base de datos en un servidor central. Para integrar el software de la Tarjeta Inteligente desde "el lado del servidor", con el software del "lado de la tarjeta", se tiene que tomar en cuenta en la programación, que el software del lado de la tarjeta pone más atención en el tipo o modelo de tarjeta utilizada. El software de "lado de la tarjeta", provee servicios de cómputo para aplicaciones que tienen acceso a la información y protege este contenido de otras aplicaciones que pueden, de forma indebida intentar el acceso a la información. El software creado del "lado de la tarjeta" está pensado para operar con diferentes tipos y versiones de TI, así como también con varios tipos de lectores. Cuando se desarrolla el software del lado de la tarjeta se adoptan las propiedades de seguridad y las reglas de una tarjeta en particular. Por ejemplo, el programa que se encuentra en ejecución no muestra la información almacenada en la tarjeta, a menos que se presente un código de

17

identificación personal (PIN). Otro ejemplo es un programa que se ejecuta en la tarjeta y que puede calcular una firma electrónica utilizando una llave privada almacenada en la misma Tarjeta Inteligente. El software ejecutándose sobre la TI provee seguridad, autorizando el acceso a los datos almacenados en ella. Esto es determinado por el tipo de TI y por las entidades del sistema como por ejemplo: las personas, computadoras, terminales, vídeo juegos, etc. El software del lado del servidor conecta a la Tarjeta Inteligente y al usuario con el sistema. Por ejemplo, un programa ejecutándose en una terminal tipo ATM, del inglés (Automatic Teller Machine) puede solicitar la inserción de una TI, para identificar a un cliente y así darle acceso a los servicios que se tienen en el servidor. Software de Seguridad Las llaves están almacenadas en la tarjeta, los algoritmos y los protocolos están desarrollados en el software del lado de la tarjeta. La criptografía principalmente se utiliza para autentificar las entidades del sistema, tales como usuarios, tarjetas, terminales y para encriptar la comunicación entre la tarjeta y el mundo exterior. Las funciones criptográficas se crean dentro de la tarjeta para su propia seguridad o también pueden ser desarrolladas para proporcionar seguridad en sistemas externos. La protección brindada por la propia seguridad de la tarjeta garantiza la seguridad en las aplicaciones externas. Antes de que la tarjeta permita el acceso a los recursos, ésta debe determinar quien intenta hacer uso de los mismos. Similarmente antes de que ésta sea aceptada por otras entidades del sistema, la tarjeta debe ser capaz de probar quien es ella y si es auténtica, entonces una de las primeras actividades que debe realizar la tarjeta cuando es activada es autentificar las entidades del sistema, primero la persona que insertó la tarjeta, después la terminal donde fue insertada, ella misma y algunas o todas las entidades del sistema. Un simple procedimiento para autentificar, es la posesión de un código de acceso como un PIN de 4 dígitos o puede ser más complicado mediante la codificación de un mensaje llamado reto o "challenge" con una llave o algoritmo en particular. Si en alguna parte del proceso de autenticidad alguna entidad demuestra que no es quien dice ser, toda comunicación con la entidad es bloqueada. Un historial de las fallas puede ser almacenado en la Tarjeta Inteligente y después de cierto número de intentos fallidos, la tarjeta puede dejarse bloqueada para cualquier tipo de acceso posterior o inclusive puede destruirse su información. El encriptamiento puede ser aplicado a todos los mensajes que van desde la Tarjeta Inteligente o hacia ella o sólo puede ser aplicada sobre algunos de los mensajes. Si una TI se está comunicando con dos aplicaciones simultaneas, estas pueden ser tratadas con diferentes llaves de encriptamiento. Los programadores de TI normalmente no tienen que diseñar nuevos programas de encriptamiento o autenticidad ya que utilizan las características construidas en la tarjeta. Estas características vienen probadas y garantizan un razonable nivel de confianza.

18

A continuación se muestran algunos algoritmos de encriptamiento, utilizados en diferentes tipos de tarjetas.

Algoritmo Usos en tarjetas DES y 3DES Canales de comunicación A3 y A8 Telefonía celular móvil GSM Curvas elípticas Firmas electrónicas TSA7 Historial médico RSA Firmas electrónicas

2.2. CRIPTOGRAFÍA La criptografía es una operación matemática aplicada a los datos haciéndolos ilegibles durante la transmisión entre dos puntos. El archivo normal es convertido al archivo encriptado por medio de llaves que deben ser iguales o relacionadas en ambos lados. La criptología del griego "criptos" (oculto) y "logos" (tratado) es el nombre genérico con el que se designan dos disciplinas opuestas y a la vez complementarias: la Criptografía y el Criptoanálisis. La Criptografía se ocupa del diseño para encriptar o enmascarar una cierta información de carácter confidencial. El Criptoanálisis, por su parte, se ocupa de romper esos procedimientos de cifrado o encriptamiento para así recuperar la información original y hacerla entendible nuevamente. Es obvio pensar que las dos disciplinas se han desarrollado de forma paralela, ya que toda información cifrada o encriptada lleva siempre implícito el método para su criptoanálisis o desencriptamiento. En realidad, el arte de la Criptografía como medio para proteger la información es tan antiguo como la propia escritura. Este arte permaneció durante siglos ligado solamente a los círculos militares y diplomáticos pero en la actualidad las necesidades son diferentes popularizándose rápidamente para mantener la transmisión de la información por Internet de una manera íntegra.

19

Véase la figura 2.2, el método de llave secreta en donde ambos usan la misma llave para encriptar y desencriptar. Encriptamiento Desencriptamiento

Fig. 2.2: Encriptamiento y desencriptamiento, sistema de llaves secretas, simétrico

Existen dos tipos generales de esquemas de seguridad, el de llaves secretas y el de llaves públicas: En un sistema de llaves secretas, el que envía y el que recibe el mensaje deben usar la misma llave para encriptar y para desencriptar los datos como se observa en la anterior figura 2.2. El manejo de llaves secretas es un procedimiento en el cual todas las partes deben poseer la misma llave y que nadie externo debe obtener acceso a las llaves ya que se vería comprometido el sistema completo. En un sistema de llaves públicas existen de igual forma dos llaves, pero una es secreta, llamada la llave privada y la otra llave es la pública. Las llaves no son las mismas pero están relacionadas matemáticamente. La llave privada, es guardada en secreto por el propietario y no puede ser determinada con la llave pública, esta es libremente distribuida hacia los destinatarios elegidos para la comunicación. La tecnología para criptografía con llaves públicas y privadas, utilizada para la seguridad en redes fue desarrollada por la compañía RSA Data Security. Sin embargo, el uso de la tecnología de llaves secretas está restringido en algunos países. La tecnología de llaves públicas implica complicados cálculos matemáticos y esto significa que el proceso de encriptamiento y desencriptamiento puede llevarse mucho tiempo como para lograr transacciones eficientes a gran velocidad.

Llave secreta

Llave secreta

20

Los cálculos de las llaves secretas utilizando el algoritmo DES son mucho más rápidos que los cálculos de las llaves usando el algoritmo RSA debido a que DES utiliza llaves de 64 bits en esta aplicación y RSA, llaves de 1024 bits. Una forma de solucionar este problema es combinando las tecnologías DES y RSA. En lugar de almacenar llaves secretas en la TI, es mejor utilizar la función del generador de llaves utilizándola como una llave secreta por sesión. La llave de encriptamiento que se genera por sesión con la función de la TI, se utiliza para encriptar el mensaje original con el algoritmo DES, siendo a su vez encriptada la llave de sesión con la llave pública utilizando el algoritmo RSA. El archivo encriptado y la llave encriptada viajan por la red hacia su destino de forma independiente. La llave de sesión es desencriptada utilizando la llave privada que tiene el receptor con el algoritmo RSA y con la llave de sesión recuperada, se aplica el inverso del algoritmo DES al mensaje que llegó encriptado para obtener el mensaje original en el destino. Véase en la figura 2.3, el sistema de llaves privadas y públicas propuesto.

Fig. 2.3: Sistema de llaves privadas y públicas propuesto

21

Al final de la recepción, la llave de sesión es desencriptada por la tarjeta y utilizada para el desencriptamiento. Una vez que se termina de utilizar la llave de sesión ésta es destruida. Integridad de los datos, por medio de TI El uso de firmas digitales es el método más común para mantener la integridad de los datos. Un algoritmo de funciones de dispersión "hashing" es aplicado al mensaje original para producir un compendio "digest" del mensaje. La operación de las funciones de dispersión "hashing" puede ser realizada en la PC o en la TI. La llave pública de quien envía, es utilizada para encriptar el compendio "digest" que a su vez se utiliza para crear la firma digital. Véase en la figura 2.4, integridad de los datos por medio de las funciones de dispersión "hashing".

Fig. 2.4: Integridad de los datos por medio de funciones de dispersión "Hashing"

Una firma digital es una combinación del mensaje original y de la llave privada enviada. La llave privada de quien envía es usada para encriptar el compendio "digest" del mensaje. El compendio "digest" se crea corriendo el mensaje a través de lo que se llama un "algoritmo de funciones de dispersión "hashing", el cual reduce los mensajes a un único y compacto paquete de datos. La firma digital es llamada una firma de dispersión "hash". A través de este proceso la firma digital es única para el que envía.

22

Diferente al pensamiento de la mayoría, de que la firma digital es la imagen digitalizada de una firma, la firma digital es un procedimiento matemático que se ejecuta para lograr un paquete de datos único y que conste que fue emitido por la parte transmisora. Véase en la figura 2.5, el paso de la llave secreta encriptada con RSA y el archivo con DES que se asemeja a la transmisión de una firma electrónica.

Fig. 2.5: Envío de llave secreta encriptada con RSA y archivo con DES

El archivo original es enviado separado de la firma. El receptor desencripta la firma con la llave pública del transmisor y obtiene el compendio "digest" del mensaje. El recipiente también somete el archivo original a la misma operación con el algoritmo de las funciones de dispersión "hashing" que el transmisor realizó y compara el resultado con el del compendio "digest". Si son iguales, el mensaje original fue recibido sin alteración. La firma digital también se utiliza para la autenticidad y el no repudio. Por ejemplo, el receptor está seguro de que el mensaje llegó del transmisor y sólo del transmisor porque es sólo con la llave pública del transmisor con la que se puede desencriptar el compendio "digest" y el archivo encriptado.

23

2.2.1. DES "Data Encryption Standard" DES (norma de encriptamiento de datos), es un algoritmo de encriptamiento para la protección de datos durante su transmisión y almacenaje. El chip DES es un producto estratégico en E.U.A. y no está permitida su exportación sin un permiso especial. El ANSI (American National Standards Institute) adoptó el DES con el nombre de Data Encryption Algorithm (DEA). "Encriptamiento en bloque" se le denomina a aquel mensaje encriptado en grupos (bloques) de dos o más componentes. El encriptamiento en bloque se compone de cuatro elementos:

• Transformación inicial • Una función criptográficamente débil iterada r veces • Transformación final • Algoritmo de expansión de llave

DES es un algoritmo de encriptamiento en bloque; la longitud del bloque es de 64 bits y la longitud de la llave es de 56 bits, lo que equivale a que existan:

2 56= 7,2 x 10 16 llaves diferentes. La norma contempla que DES pueda ser implementado mediante un circuito integrado electrónico y su descripción completa se puede conseguir en forma de FIPS, (Federal Information Processing Standars). DES trabaja alternativamente sobre las dos mitades del bloque a encriptar de la siguiente forma y secuencia: 1. Se hace una permutación inicial fija y por tanto, sin valor criptográfico. 2. Se divide el bloque en dos mitades, derecha e izquierda. 3. Se realiza una operación modular que se repite 16 veces; esta operación consiste en sumar módulo 2 a la parte izquierda con una transformación g (k1) de la parte derecha, que a su vez está gobernada por una llave k1. 4. Se intercambian las partes derecha e izquierda. 5. Se omite el intercambio en la vuelta número 16, pero se remata el algoritmo con una permutación final que es la inversa de la inicial. Para desencriptar el DES basta con repetir la operación modular, que es una involución, es decir, su aplicación repetida dos veces conduce a los datos originales. No es preciso invertir la transformación g (k1) sino repetirla, esto permite que dicha transformación sea una función de un sólo sentido, empleando operaciones no lineales. Las propiedades fundamentales de DES son:

• Dependencia entre símbolos; cada bit del archivo encriptado es una función compleja de todos los bits de la llave y de todos los bits del archivo original dividido en bloques. • Cambio de los bits de entrada; un cambio de un bit en el mensaje original produce el cambio aproximadamente del 50% de los bits del bloque encriptado.

24

• Cambio de los bits de la llave; un cambio en un bit de la llave produce aproximadamente, el cambio de la mitad de los bits del bloque encriptado.

Criptografía Simétrica La criptografía simétrica se refiere al conjunto de métodos que permiten tener comunicación segura entre las partes siempre y cuando anteriormente se hayan intercambiado la llave correspondiente que llamaremos llave simétrica. La simetría se refiere a que las partes tienen la misma llave tanto para encriptar como para desencriptar. Este tipo de criptografía se conoce también como criptografía de llave privada. Existe una clasificación de este tipo de criptografía en tres familias, la criptografía simétrica de bloques ("block cipher"), la criptografía simétrica de lluvia ("stream cipher") y la criptografía simétrica de dispersión (“hash functions”). Con ligeras modificaciones, un sistema de criptografía simétrica de bloques puede modificarse para convertirse en alguna de las otras dos formas. Sin embargo se usan en diferentes aplicaciones. La criptografía simétrica ha sido la más usada en toda la historia, ésta ha podido ser empleada en diferentes dispositivos: manuales, mecánicos, eléctricos y hasta con algoritmos actuales que son programables en cualquier computadora. La idea general es aplicar diferentes funciones al mensaje que se quiere encriptar de tal modo que sólo conociendo una llave pueda aplicarse de forma inversa para poder así desencriptar. DES es un sistema criptográfico, que toma como entrada un bloque de 64 bits del mensaje y éste se somete a 16 interacciones con una llave de 56 bits. En la práctica el bloque de la llave tiene 64 bits, ya que a cada conjunto de 7 bits se le agrega un bit que puede ser usado como de paridad. Dependiendo de la naturaleza de la aplicación, DES tiene cuatro modos de operación para poder implementarse: ECB (Electronic Codebook Mode) para mensajes cortos, de menos de 64 bits, CBC (Cipher Block Chaining Mode) para mensajes largos, CFB (Cipher Block Feedback) para encriptar bit por bit ó byte por byte y el OFB (Output Feedback Mode) el mismo uso pero evitando la propagación de error. En la actualidad no se ha podido romper el sistema DES desde la perspectiva de poder deducir la llave simétrica a partir de la información interceptada, sin embargo con un método a fuerza bruta, es decir probando alrededor de 256 posibles llaves, se pudo romper DES en Enero de 1999. Lo anterior quiere decir que, es posible obtener la llave del sistema DES en un tiempo relativamente corto, por lo que lo hace inseguro para propósitos de alta seguridad. La opción que se ha tomado para poder suplantar a DES ha sido usar lo que se conoce como encriptado múltiple, es decir aplicar varias veces el mismo algoritmo para fortalecer la longitud de la llave, esto ha tomado la forma de un nuevo sistema de encriptamiento que se conoce actualmente como triple-DES o 3DES.

25

2.2.2. 3DES El funcionamiento de 3DES consiste en aplicar tres veces DES de la siguiente manera: la primera vez se usa una llave K1 junto con el bloque B0, de forma ordinaria E (de encriptamiento), obteniendo el bloque B1. La segunda vez se toma a B1 con la llave K2, diferente a K1 de forma inversa, llamada D (de desencriptamiento) y la tercera vez a B2 con una llave K3 diferente a K1 y K2, de forma ordinaria E (de encriptamiento), es decir, aplicando de la interacción 1 a la 16 a B0 con la llave K1, después se aplica de la 16 a la 1, a B1 con la llave K2, finalmente se aplica una vez más de la 1 a la 16 a B2 usando la llave K3, obteniendo finalmente a B3. Este sistema 3DES usa entonces una llave de 168 bits, aunque se ha podido mostrar que los ataques actualmente pueden romper a 3DES con una complejidad de 2112 operaciones, es decir efectuar al menos 2112 operaciones para obtener la llave a fuerza bruta, además de la memoria requerida. Se optó por 3DES ya que se aplica de forma similar al DES pero proporciona mayor seguridad. En los últimos 20 años se han diseñado una gran cantidad de sistemas criptográficos simétricos, entre ellos están: RC-5, IDEA, FEAL, LOKI'91, DESX, Blowfish, CAST, GOST, etcétera. Sin embargo, no han tenido el alcance de DES, a pesar de que algunos de ellos tienen mejores propiedades. Podemos afirmar que el estádo actual de la criptografía simétrica es la búsqueda continua de nuevos algoritmos como por ejemplo el AES/Rinjdael que es una combinación de AES (Advanced Encryption Standard) y del algoritmo desarrollado por Joan Daemen y por Vincent Rijmen (Rijndael) que pasó a ser un estándar en Noviembre del 2001 ante el National Institute for security Technologies (NIST) que se encuentra en U.S.A. AES/Rinjdael es un algoritmo que al igual que DES, trabaja con llaves simétricas y es de encriptamiento por bloques, sin embargo el tamaño de los bloques es de 128 bits y las llaves de encriptamiento van desde tamaños de 128 bits hasta 256 bits.

2.2.3. RSA El Criptosistema RSA, fue inventado en 1978 por R.L. Rivest, A. Shamir y L. Adleman en el MIT (Massachusetts Institute of Technology). Para poner en práctica el RSA necesitamos dos números primos grandes p y q. Después para encriptar un mensaje haciendo uso del RSA usamos n = p q, por lo tanto debemos conocer p y q para el desencriptamiento. La seguridad de RSA depende de lo difícil que es factorizar n ya que hay que encontrar a los números primos p, q y estos son números muy grandes. La llave pública usada por el criptosistema RSA es un número muy grande. Los números primos p y q, deben de mantenerse secretos y el entero n formado parte de la “llave pública”.

26

En aplicaciones prácticas este número tiene más de 200 dígitos. Para trabajar con un número tan largo necesitamos una computadora potente si se quieren realizar las operaciones necesarias en un tiempo razonable. RSA (Rivest, Shamir y Adleman), los apellidos antes mencionados se refieren a los creadores del RSA basados en el modelo, Diffie-Hellman que resuelve 3 deficiencias de los modelos de llave secreta anteriormente propuestos y son:

1. La distribución de las llaves en el sistema 2. El manejo del número de llaves n(n-1)/2 3. No tienen firma digital

El algoritmo de llave pública RSA puede ser formado por distintas longitudes de llaves, con las siguientes características: • Contra más larga sea la llave más difícil es descubrir el mensaje. • Las llaves más complejas son de 2048 bits y las estándar son de 1024 bits. • Está basado en dos números primos cada número > 200 dígitos. Véase figura 2.6 que muestra un diagrama de flujo simplificado del algoritmo RSA.

Fig. 2.6: Diagrama de flujo simplificado del Algoritmo RSA

En el caso de RSA, el problema matemático es el de factorizar un número entero "n" de tamaño grande (1024 bits), este número entero se sabe es producto de dos números primos p, q de la misma longitud, entonces la llave pública es el número n y la privada es p, q. El razonamiento del funcionamiento de RSA es el siguiente:

27

a. A cada usuario se le asigna un número entero n, que funciona como su llave pública.

b. Sólo el usuario respectivo conoce la factorización de n (o sea p, q), que mantiene en

secreto y es la llave privada. c. Existe un directorio de llaves públicas.

d. Si alguien quiere mandar un mensaje m entonces elige la llave pública e y se aplica la

operación c=memod n y se crea el mensaje encriptado c, (que sólo podrá desencriptar el usuario con la llave correspondiente).

e. Una vez que se realizaron los pasos anteriores el mensaje c puede viajar sin problema por

cualquier canal inseguro.

f. Cuando la información encriptada llega a su destino el receptor procede a desencriptar el mensaje con la siguiente fórmula: m= cd mod n.

g. Estas formulas son inversas y por lo tanto dan el resultado deseado donde d, es tal que (d,

e) mod z = 1 y z= (p-1) (q-1). En términos muy generales es así como funciona el sistema RSA. Sin embargo en la realidad existen dos formas que son las más comunes, estas formas dependen de la aplicación y se llaman el esquema de firma y el esquema de encriptamiento, a continuación se describe el esquema de encriptamiento. Esquema de encriptamiento Uso: este esquema se usa principalmente para encriptar llaves de sistemas simétricos (llaves de 128 bits aproximadamente)

1. Se toma el mensaje M (por ejemplo con una llave simétrica de 128 bits), como en la práctica actual es recomendable usar bloques de longitud de 1024 bits los complementa, esos 128 bits con una serie de técnicas para obtener uno de 1024 bits, después se aplica un proceso de codificación para que la computadora entienda el mensaje como un número entero m.

2. Se le aplica la fórmula de encriptamiento de RSA al entero m.

3. Se envía el número entero c.

4. Al recibir este número se aplica la fórmula de desencriptamiento al entero c para obtener

el entero m.

5. Se decodifica m para obtener el mensaje M.

28

Factorización y logaritmos discretos Curiosamente, la inmensa mayoría de los algoritmos asimétricos que se usan en la actualidad se apoyan en problemas como el de la factorización o el de los logaritmos discretos. En realidad existen otros algoritmos que se basan en teorías diferentes, pero hoy por hoy no están suficientemente estudiados como para ser considerados seguros de forma general, por lo que no se suelen emplear en la práctica. Sistemas como RSA, Diffie-Hellman, e incluso la criptografía de curvas elípticas depositan su seguridad en estos dos problemas. Todos ellos descansan en la supuesta imposibilidad de resolverlos de forma algorítmicamente eficiente y se dice "supuesta" porque nadie ha demostrado que no pueda existir un algoritmo capaz de hacerlo de forma satisfactoria. Complejidad algorítmica Alguien podría decir que un algoritmo "eficiente" es cuando haya computadoras más y más rápidas, problemas que ahora son difíciles se podrán resolver y eso es radicalmente falso. En Teoría de Algoritmos, se define el orden de complejidad de un algoritmo como una función "Ø(n)" de la entrada "n". Esta medida nos dice cómo crece el tiempo de computación a medida que aumenta el tamaño de la entrada. Por ejemplo, si un algoritmo fuera cuadrático, es decir, Ø(n^2), se tiene que el tiempo de ejecución es proporcional al cuadrado de la entrada. Eso quiere decir que si sobre la entrada 2 tarda 4 minutos, sobre la entrada 10 debe tardar 100 y sobre 1000, 1,000,000 de minutos. Según esto, si se desea factorizar un número, se puede tratar de dividirlo por todos los números menores que él, uno por uno. Suponiendo que la prueba de divisibilidad se ejecutara en un tiempo constante x - simplificación que en realidad no es cierta -, el algoritmo necesitaría aproximadamente n pasos para tratar el número n. Eso quiere decir que el programa puede factorizar sin problemas números pequeños pero si al ejecutarlo sobre un número de 1024 bits, se precisan llevar a cabo una cantidad de pasos elementales enorme. Por desgracia, actualmente es imposible construir una máquina capaz de llevar a cabo semejante computación. [22] Si por el contrario se pudiera encontrar un algoritmo capaz de resolver el problema anterior en un número de pasos proporcional, por ejemplo, al logaritmo de n, se podría factorizar un número de 1024 bits con cien veces más pasos que los que necesitaríamos para hacerlo con un número de tan sólo 10 bits. No se trata de tener máquinas más rápidas, que por supuesto ayudan, sino de investigar algoritmos con orden de complejidad menor, capaces de resolver los mismos problemas en menos pasos. Tiempo de factorización en la práctica al aplicar RSA Hoy en día, parece ser que en el problema de la factorización se ha avanzado enormemente, este gran impulso lo ha provocado en gran parte la criptografía y más concretamente el sistema RSA. Aunque se muestre que un algoritmo corre a tiempo subexponencial o más aún a tiempo polinomial, el tiempo de calendario (tiempo real en meses, días o minutos) puede variar mucho dependiendo de la entrada del algoritmo y del equipo de cómputo con que se cuenta. Existe una

29

forma de medir el potencial de cómputo y de esta forma determinar cuál sería el tiempo en calendario que llevaría factorizar un número entero ”grande”. La notación “mips” significa millones de instrucciones por segundo y es tomada como medida estándar para registrar la potencia de cómputo con que se cuenta. Un mips tiene como origen la potencia de cómputo que realizaba una DEC VAX 11/780. Un "mipsy" significa el número de operaciones que se pueden realizar en un año con un poder de cómputo de un mips, es decir 31 536 x 109 instrucciones. Seguridad en la red a. Autenticidad La autenticidad de las entidades (personas, computadoras-servidores o computadoras-clientes) que se encuentran en la red es; indicando que son los que realmente dicen ser, normalmente esta etapa se asegura con números de identificación personal NIP ó PIN (del inglés), datos biométricos como serían las firmas, la huella digital, intercambios de preguntas y respuestas o firmas electrónicas. b. Autorización Para tener acceso a la información o servicios dentro de la red usualmente se utilizan contraseñas (passwords) y números de cuenta para prevenir que extraños vean la información con sólo pasar las firmas digitales. c. Confidencialidad La confidencialidad de las transacciones entre entidades de la red utilizando técnicas criptográficas, es el evitar que extraños conozcan el contenido de la información almacenada. d. Integridad de la información La integridad de la información que fluye a través de la red (que en algunos casos se considera dentro de la autenticidad), se asegura por medio de varios niveles de acceso a la red mediante técnicas criptográficas y firmas digitales. e. Confirmación de la transacción La confirmación de la transacción entre dos entidades de la red; significa que el autor de los datos no debe recibir reclamación por parte de los usuarios, para esto pueden utilizarse firmas electrónicas. Como una manera de mantener alejados a los intrusos de la red se debe encriptar la información que fluye a través de ella y como un método auxiliar se debe usar secuencias de reconocimiento de respuesta. Por ejemplo:

30

Primero, la autenticidad del usuario de la tarjeta por medio de un PIN o huella digital, estos datos se teclean o introducen a un dispositivo de lectura y se comparan con la información que tiene la tarjeta grabada en su interior. Como segundo paso la autenticidad de la tarjeta con el servidor, aquí el servidor genera un número aleatorio como “recibo” y lo envía a la tarjeta. El “recibo” es encriptado por la tarjeta utilizando una llave privada que está almacenada dentro de ella y posteriormente lo regresa al servidor. El servidor lo desencripta y verifica que el “recibo” corresponda al original. Clasificación de seguridad según la vulnerabilidad de los algoritmos Seguridad incondicional (teórica): El sistema es seguro frente a un atacante con tiempo y recursos computacionales ilimitados. Seguridad computacional (práctica): El sistema es seguro frente a un atacante con tiempo y recursos computacionales limitados. Seguridad probable: No se puede demostrar su integridad, pero el sistema no ha sido violado. Seguridad condicional: Todos los sistemas están seguros mientras que el enemigo carece de medios para atacarlos.

31

2.3. TCP/IP La pila de protocolos TCP/IP, es de los protocolos más usados en todo el mundo y por esta razón se eligieron como medio para la comunicación e implementarle un método seguro de transmisión de la información. En el caso de TCP/IP es mejor utilizar OSI sólo como modelo de referencia teórica y estudiar con detenimiento el verdadero modelo TCP/IP como se hace a continuación.

2.3.1. DIRECCIONES IP El principal beneficio de IP es que es capaz de convertir un conjunto de redes físicamente distintas en una sola red aparentemente homogénea. Una red Internet, es una red IP aparentemente homogénea. La Internet es la red de redes. En realidad sólo es una interconexión de redes (inter-red) muy grande y que se extiende por todo el planeta. La característica de cualquier internet es que cada uno de los nodos tiene una dirección IP única y distinta a la de cualquier otro nodo. Las direcciones IP son cadenas de treinta y dos bits, organizadas como una secuencia de cuatro bytes. Todas las tramas11 IP llevan una dirección de origen (donde se originó la trama) y una dirección destino (a donde se dirige la misma). Estas direcciones tienen una representación con cuatro números enteros separados por puntos y en notación decimal. Las direcciones representan la interfaz de conexión de un equipo con la red. Así, un anfitrión "host12" que está conectado a varias redes como regla general, no tendrá una única dirección de red, sino varias (normalmente una por cada red a la que está conectado). Pero internamente, esto es parcialmente cierto. Las direcciones IP se dividen en dos partes (cada una con un cierto número de bits), cuyo significado tiene que ver con el sistema de ruteo de tramas. La primera parte (cuya longitud no es fija y depende de una serie de factores) representa la red y debe ser igual para todos los anfitriones "hosts" que estén conectados a una misma red física. La segunda parte representa el "host" y debe ser diferente para todos los anfitriones "hosts" que están conectados a la misma red física. El mecanismo de toma de decisión de IP, que hace que todas las tramas lleguen a su destino, es el siguiente: Cuando la dirección origen y la dirección destino, están ambas en la misma red (esto se sabe porque su dirección de red es igual en ambas, la dirección de red será la consecuencia de sustituir

11 Trama "frame" , Unidad de datos en las capas física y de enlace de datos del modelo OSI. Una trama es el medio por el cual se transportan paquetes

o segmentos de datos.

12 Host significa anfitrión. Computadora o servidor que tiene una dirección de hardware y reside en una red.

32

por ceros toda la parte del anfitrión "host" en la dirección considerada) IP, supone que existe un mecanismo de nivel inferior (en este caso Ethernet, Token Ring, etc.) que se encarga de hacer llegar la trama hasta el anfitrión "host" destino. Cuando la dirección de red origen y la de destino no coinciden, entonces hay que rutear. Para rutear, se dispone de una tabla que contiene entradas para cada una de las redes a las que se quieren hacer llegar tramas que no sean locales a este anfitrión "host". Un anfitrión "host", en general, está conectado a varias redes, de las que hace de “gateway” (compuerta), si la dirección destino de la trama tiene una dirección de red que coincide con alguna de las direcciones de red propias, las que resultan de sustituir por ceros la parte del anfitrión "host" en cada una de las interfaces, entonces no hace falta rutear. Esta tabla tiene más o menos entradas, en función de la complejidad de la inter-red y la dirección del siguiente anfitrión "host" en el camino hasta la red de destino.

2.3.2. CLASES DE REDES Existen 5 clases de direcciones IP. A cada tipo se le asigna una letra, así, existen direcciones de clases A, B, C, D, E. Las direcciones pertenecen a estas clases en función de los cuatro bits más significativos del primer byte.

Tabla 2.1. La n representa la parte de red de la dirección y h, la parte de anfitrión "host", la x tiene otro tratamiento.

33

Las clases D y E no participan en el sistema de ruteo IP y no las comentaremos (las direcciones de clase D se usan en difusión o "multicasting" y las direcciones de clase E están reservadas, por ello no deben usarse para configurar anfitriones "hosts" en internet). Por otro lado, las redes de clase A tienen el primer byte como parte de red y los tres restantes como parte del anfitrión "hosts", las redes de clase B tienen los dos primeros bytes como parte de red y los dos últimos como parte del anfitrión "hosts" y las redes de clase C, tienen como parte de red los tres primeros bytes y como parte del anfitrión "hosts" el último. Así, puesto en notación con puntos, las redes de las distintas clases cubren los siguientes rangos de direcciones:

clase A

de la 1.0.0.0

--> 127.255.255.255

clase B de la 128.0.0.0 --> 191.255.255.255 clase C de la 192.0.0.0 --> 223.255.255.255

2.3.3. MÁSCARAS DE RED La máscara de red no es más que una dirección IP, donde se han sustituido todos los bits de la parte de red de la dirección por unos y los bits correspondientes a la parte de anfitrión "host" por ceros. Así, la máscara por defecto de red de una red de clase A será 255.0.0.0, la de una red de clase B será 255.255.0.0 y la de una clase C será 255.255.255.0. Se ha comprobado que a veces el sistema de clases no es apropiado por lo tanto, se usa la máscara de red a pesar de que ésta, está implícita en el tipo de dirección, si se asigna una clase C de red completa y se quiere dividir en cuatro redes diferentes, no se utilizan cuatro redes clase C, lo que se hace es utilizar la máscara de red para separarla. En este caso la máscara de subred se extiende dos bits más allá de la frontera impuesta por el tipo de la dirección adquirida y se considera como si tuviera cuatro redes (en este caso la parte de red serían los primeros tres bytes y dos bits del cuarto y la parte de los anfitriones restantes). Dentro de una misma red, se puede extender el mecanismo de ruteo, considerando que la parte de anfitrión "host" son los bits cero y la parte de red, son los bits uno de la máscara y asociando a cada dirección IP una máscara en el momento de configurarla, por supuesto, los valores por defecto serán los de la clase de la red, aunque se podrán añadir y solamente añadir, bits uno a la máscara, con el fin de dividirla en subredes. Tablas de ruteo Para indicar la ruta a tomar para cada destino se usan las tablas de ruteo y para construirlas formaremos para cada máquina, una tabla con la forma de dirigir las tramas hacia las redes que no vemos directamente, con la ventaja adicional de que como la dirección 0.0.0.0 representa obviamente la red local podemos usar esta dirección especial para indicar la ruta por defecto (es decir, la dirección local a la que se deben enviar las tramas que no tienen ruta y que necesariamente hay que rutear).

34

Troncal, “Backbone” Literalmente, “backbone” significa columna vertebral. Las tramas se canalizan hacia el “backbone” y éste al final debe decidir donde van a parar. Como conclusión de esta última frase se desprende que el backbone es la red de nivel jerárquico superior donde no hay ninguna red más importante. Por ejemplo, el backbone de Internet, o la red principal de una empresa que no tiene conexiones con el exterior; los “gateways” que forman el backbone deben tener rutas a todas las redes y no aparecer una ruta por defecto en sus tablas de ruteo, mientras que para el resto de las redes, la ruta por defecto (y para los anfitriones "hosts") será siempre la que lleve hacia el backbone.

2.3.4. CRITERIOS PARA DIVIDIR LA RED EN SUBREDES Los criterios que se toman en cuenta a la hora de decidir subdividir una gran red en varias más pequeñas serán analizados. Subdividir una red no sirve únicamente a criterios topológicos relacionados con la instalación física de la red. Está claro que las redes de topología distinta o que usen diferentes protocolos de transmisión, deberían tener direcciones distintas para no mezclar artificialmente cosas distintas pero también se puede dividir una gran red en varias redes por otros motivos. Por ejemplo para facilitar la administración de la red, delegando a cada administrador la gestión de direcciones de una subred. Quizás la estructura de una empresa aconseje separar redes distintas para distintos departamentos. Es decir las subredes pueden facilitar la adaptación de la red a la estructura de una organización. También pueden servir para aislar redes con tráfico interno abundante y facilitar el diagnóstico de problemas en la red. En teoría se puede dividir una sola red física en varias redes lógicas pero si la separación física fuera posible, conviene hacerla uniéndolas con un “gateway”13 porque aumentaremos el ancho de banda total en la red. Hay que tener en cuenta que una red ethernet es un bus con acceso CSMA/CD14 y por lo tanto en un instante de tiempo dado, varios puestos pueden escuchar simultáneamente pero nunca pueden hablar dos usando el mismo bus15 a la vez porque se origina una colisión de los paquetes y estos deberán ser reenviados de forma no simultánea. Los términos Compuertas “Gateways”, Ruteadores “Routers” y Puentes “Bridges” se refieren a una serie de dispositivos para la interconexión de redes Muchas veces estos dispositivos son una PC con un par de tarjetas de comunicaciones para conectarse simultáneamente a dos redes funcionando con un software apropiado. Un puente conecta dos redes parecidas (por ejemplo pueden ser distintas en su velocidad), sin cambiar la estructura de los mensajes que circulan por ellas. Un ruteador conecta dos redes que son iguales (o parecidas). No hay traducción de un protocolo a otro pero sí traducción de direcciones. Una compuerta puede conectar redes distintas (por ejemplo una ethernet y una token ring) realizando la conversión de protocolos y la traducción de

13 “Gateway”: compuerta

14 CSMA/CD: (Carrier Sense Multiple Access with Collision Detection) / Acceso multiple por detección de portadora con detección de colisiones

15 Bus : grupo de conductores en paralelo que conectan los registros de desplazamiento o alimentación

35

direcciones. Si recordamos el modelo TCP/IP, sabemos que los distintos dispositivos mencionados actuaran a distinto nivel del modelo de comunicaciones. Un ruteador incluye la función de puente y la compuerta engloba las funciones de ruteador y de puente. Cuando todos los nodos de una red deben alcanzar todos los nodos de otra red, se provoca una sobrecarga de la red debido a los protocolos de ruteo. En este caso y cuando ambas redes utilicen el mismo protocolo de red, la mejor solución es un puente, que es más rápido y más económico. Para determinar una ruta como la más idónea, el protocolo de información de ruteo (RIP) es un protocolo que está basado únicamente en el costo. A cada ruta se le asocia un costo en función del rendimiento de la red y del tipo de la línea. Esto permite determinar de entre varias rutas posibles cuál es la de menor costo. Cada ruteador de una red envía y recibe información de ruteo, permitiendo actualizar las tablas de ruteo cada 30 segundos. Cuando el costo de una ruta supera el valor 16, el sistema se considera fuera de alcance. La caída de un nodo de la red, suele provocar la pérdida de algunos mensajes hasta que las tablas de ruteo de todos los ruteadores se reajustan. Existe otro tipo de dispositivo que sirve para conectar dos redes y que se llama “firewall”. Se trata de un dispositivo lógico que sirve para conectar de forma segura la parte privada de una red con la parte pública. Estos dispositivos pueden establecer una política de restricciones a la información que circula por ellos. Servidores de Nombres Las direcciones IP son muy adecuadas para las máquinas pero son difíciles de recordar. Por esta razón se usan nombres de dominios. Además usando sólo una dirección IP sin nombre, tendríamos que cambiar de dirección cada vez que nos alojemos en un servidor distinto. Si asimilamos una dirección a un nombre, podemos mantener nuestra presencia en Internet cambiando de servidor sin que se note el cambio. En la práctica, el cambio no sucede instantáneamente porque tiene que propagarse la información del cambio de nombre en gran parte de la red. Para una red pequeña nos bastaría usar un archivo que sea común a todos los nodos de la red. Si la red es más grande, cada cambio debe de ser propagado a los demás lo antes posible y controlar que la información se mantenga coherente o usar un sistema de base de datos compartido. A pesar de ello, estos cambios resultan insuficientes cuando hablamos de redes muy grandes. El archivo sería enorme así que, lo que se ha implementado para que en Internet exista un servicio de nombres, es el protocolo llamado DNS que permite tener esta información distribuida adecuadamente, mediante un sistema de dominios que se reparten la carga de gestionar estos nombres organizados de forma jerárquica generalmente hasta tres niveles de los cuales el primero suele indicar el tipo de actividad. Por ejemplo:

• com: empresas comerciales. • org: organizaciones no comerciales. • edu: universidades y centros de investigación. • net: compuertas y nodos administrativos de la red.

36

Con el fin de aumentar la eficiencia y la tolerancia a fallos, cada zona tiene un servidor de nombres autorizado o maestro y cada uno de estos tienen varios servidores secundarios. Las zonas se definen como conjuntos de redes IP redondeadas a un nivel de un octeto.

2.3.5. ESTRUCTURA DE LOS PAQUETES Los paquetes o tramas son secuencias de bits que contienen no sólo los datos con información del usuario, sino datos de cabecera y de cola que se estructuran en forma que los niveles superiores de transmisión de datos son un encapsulado de los niveles inferiores. Para formar un paquete UDP habría que envolverlo de la manera siguiente como muestra la figura 2.7: Datos N bytes UDP 20 bytes

Datos N bytes

IP 20 bytes

UDP 20 bytes

Datos N bytes

Ethernet 14 bytes

IP 20 bytes

UDP 20 bytes

Datos N bytes

Ethernet4 bytes

Fig. 2.7: Forma de los paquetes UDP

La parte que representamos a la izquierda de los datos son datos de cabecera y los de la derecha son datos de finalización del paquete. Unicamente el nivel de Interfaz Ethernet tiene parte de finalización y todos los niveles tienen datos de cabecera. Para el caso de TCP, la estructura será similar y se muestra en la figura 2.8. Datos N bytes TCP 20 bytes

Datos N bytes

IP 20 bytes

TCP 20 bytes

Datos N bytes

Ethernet 14 bytes

IP 20 bytes

TCP 20 bytes

Datos N bytes

Ethernet4 bytes

Fig. 2.8: Forma de los paquetes TCP

37

La sección de datos puede tener distinto tamaño, según los casos, pero generalmente no será mucho mayor de 1 KByte. A continuación se muestran a manera de ejemplo, un par de cabeceras y para ello usaremos la estructura de una cabecera IP ver la figura 2.9 y la de una cabecera TCP figura 2.10. Ambas son estructuras de 20 Bytes.

Cabecera IP (20 bytes) Versión IHL Tipo de Sevicio Tamaño Total

Identificación Flags Desplazamiento del Fragmento

Tiempo de Vida Protocolo Checksum de Cabecera Dirección de Origen Dirección de Destino

Fig. 2.9: Cabecera IP

Simplemente nos conformaremos con resaltar que la cabecera IP, tiene datos de identificación y dirección y la cabecera TCP, contiene información de los puertos así como indicadores de control, número de secuencia de los paquetes, etcétera, esto para detectar la pérdida de paquetes o su deterioro a fin de gestionar el reenvío de paquetes en caso necesario.

Cabecera TCP (20 bytes) Puerto de Origen Puerto destino Número de secuencia Número de Confirmación

Desplz.de los datos

Reservados

U R G

A C K

P S H

R S I

S Y N

F I N

Ventana

Checksum Puntero de Urgencia

Fig. 2.10: Cabecera TCP

En Internet, un destino y un origen no implica una ruta fija entre ellos. Los mensajes buscan su ruta pasando a través de varios nodos y dicha ruta puede variar incluso dentro de una misma sesión o de una misma transferencia de archivos. Por ejemplo, la caída en una ruta supondría la pérdida de algunos paquetes pero no afectaría a la transmisión ya que esta, continuaría rápidamente por otra ruta sin que apenas podamos percibirlo. Recordemos que Internet proviene en sus orígenes de diseños con objetivos militares. Si se ejecuta el comando "ping" a una máquina remota, se recibirá una información útil para

38

diagnosticar la calidad de la conexión con ese servidor. Se trata de un servicio muy sencillo orientado a datagramas. Primero se mostrarán una serie de líneas, donde se podrá comprobar el tiempo de respuesta expresado en milisegundos. Si su ejecución es interrumpida, mostrará unas estadísticas en las que se podrá ver, entre otras cosas, el porcentaje de paquetes perdidos. Un repetidor sólo amplifica y retoca la señal a nivel puramente eléctrico, por lo tanto ignora cualquier cosa sobre la información transmitida. PUENTE “BRIDGE” Un puente actúa controlando la circulación de paquetes en nivel de interfaz de red. En nuestro caso es la capa ethernet. Ambas redes deberán ser muy parecidas ya que cualquier diferencia en los protocolos superiores haría imposible la conexión de ambas redes. En la práctica se puede permitir conectar redes con diferentes velocidades pero ambas redes físicas se comportarían como una misma red lógica. RUTEADOR “ROUTER” Un ruteador actúa traduciendo o controlando la circulación de paquetes en nivel de red. Un ruteador puede actuar a un nivel de Interfaz de red (en nuestro caso Ethernet) y en nivel de red (en nuestro caso capa IP). COMPUERTA “GATEWAY” Una compuerta actúa en el nivel de transporte, que en nuestro caso puede ser TCP o UDP. También engloba los niveles inferiores. CORTAFUEGOS “FIREWALL” Un cortafuegos actúa permitiendo o denegando el paso de paquetes considerándolos en su totalidad, permitiendo el más amplio control posible. Uno de los usos más comunes, es el de proteger una intranet de accesos no deseados en ambos sentidos con el exterior, especificando unas políticas restrictivas en puertos, servicios, direcciones IP, o cualquier otro dispositivo. Los conceptos de los equipos antes mencionados son generales y se pueden profundizar ampliamente en cada uno de estos temas, sin embargo la intención principal es mencionarlos con la finalidad de entender el entorno en el cual se está trabajando, teniendo presente que es un sistema abierto completamente a la intromisión de personas no deseadas.

39

A pesar de contar con equipos como los cortafuegos, estos equipos son susceptibles a los ataques de “hackers”16, por lo que deben contar con llaves de seguridad encriptadas y que pueden como en nuestro caso ser independientes del sistema a utilizar ya que se encuentran en un hardware independiente como sería la TI haciendo al sistema más robusto y por lo tanto con mayor seguridad.

2.3.6. INTERFAZ DE SOCKETS Una Interfaz de Programa de Aplicación API, “Application Program Interfaz” es, simplemente, un grupo de funciones que se utilizan a fin de desarrollar programas de aplicación para un ambiente de cómputo específico. Por ejemplo: a los programadores de software que desean crear aplicaciones para Windows, Microsoft proporciona una extensa colección de rutinas de programación: la API de Windows. En la década de los ochenta, en Estados Unidos, fueron proporcionados fondos para implementar los protocolos TCP/IP bajo el sistema operativo UNIX. Durante este proyecto, un grupo de investigadores desarrolló una API de comunicaciones en redes TCP/IP llamada API Interfaz de sockets. La Interfaz de sockets, es una API para redes TCP/IP es decir, define una variedad de funciones que permiten a los programadores desarrollar aplicaciones para utilizarlas en redes TCP/IP. Actualmente esta interfaz es la más popular de las API para redes TCP/IP.

16 Hackers: también conocidos como Ciberpiratas, son generalmente programadores de alto nivel que intentan violar los sitemas y/o redes de

cómputo.

40

2.4. CONCLUSIONES DEL CAPÍTULO Existen dos tipos de software en las TI: El primero, es el software en el servidor, el cual consta de una serie de programas que corren en una computadora conectada a una TI y que también se conoce como el software del lado del lector de tarjetas. El software en el servidor se escribe en lenguajes de programación de alto nivel que se encuentran en las estaciones de trabajo. El segundo es el software de la tarjeta, el cual como su nombre lo indica corre la aplicación sobre la tarjeta misma, por lo que es denominado también como “software del lado de la tarjeta”. Las funciones y el software de aplicación del sistema operativo de la tarjeta, son parte del desarrollo del “lado de la tarjeta”. La necesidad de tener la información de forma segura y poder transmitirla de igual forma y sin que nadie que no sea el destinatario pueda interpretarla, es tan antigua como la propia escritura. La criptología (del griego criptos = oculto y logos = tratado), es el nombre genérico con el que se designan dos disciplinas opuestas y a la vez complementarias. El manejo de llaves es el proceso que asegura que todas las partes tengan la misma llave y que nadie externo pueda obtener acceso a las llaves sin comprometer al sistema completo. En el método simétrico de criptografía, la llave de encriptamiento coincide con la llave de desencriptamiento, mientras que en el método asimétrico, la llave de encriptamiento es diferente a la llave de desencriptamiento. "Data Encryption Standard" DES (norma de encriptamiento de datos), es un algoritmo de encriptamiento en bloque para la protección de datos durante su transmisión y almacenaje. La longitud del bloque es de 64 bits y la longitud de la llave es de 56 bits, lo que equivale a que existan: 2 56= 7,2 x 10 16 llaves diferentes. El 3DES consiste en aplicar tres veces DES de la siguiente manera: la primera vez se usa una llave K1 junto con el bloque B0, de forma ordinaria E (de encriptamiento), obteniendo el bloque B1. La segunda vez se toma a B1 con la llave K2, diferente a K1 de forma inversa, llamada D (de desencriptamiento) y la tercera vez a B2 con una llave K3 diferente a K1 y K2 E (de encriptamiento). El Criptosistema RSA, fue inventado por R.L. Rivest, A. Shamir y L. Adleman. Para poner en práctica el RSA necesitamos dos números primos grandes p y q. Para encriptar un mensaje haciendo uso del RSA usamos n = p q, para desencriptar un cryptograma RSA, debemos conocer p y q. La seguridad de RSA depende del hecho que es difícil de factorizar n y de encontrar p y q, que son números muy grandes. Para decir que un sistema cumple con normas de seguridad se cuidan: la autorización para tener acceso a la información, la confidencialidad de las transacciones entre las entidades de la red utilizando técnicas criptográficas, la integridad de la información, que se asegura por medio de varios niveles de acceso a la red y por último la confirmación de la transacción.

41

La pila de protocolos TCP/IP son los protocolos más ampliamente usados en todo el mundo y por esta razón se eligieron como medio para la comunicación y desarrollo de un método seguro de transmisión de la información. Una Interfaz de Programa de Aplicación API, “Application Program Interfaz” es, simplemente, un grupo de funciones que se utilizan a fin de desarrollar programas de aplicación para un ambiente de cómputo específico.

42

3. TRABAJO DESARROLLADO

Un método para aumentar la seguridad de la información en las redes TCP/IP usando tarjetas inteligentes. La idea principal del proyecto es incrementar la seguridad de la transmisión de información en redes de TCP/IP y para esto se utilizó un lector de TI. Estas TI cuentan con un criptoprocesador facilitando las funciones de encriptamiento y desencriptamiento realizadas. Para programar la aplicación fue necesario analizar diferentes sistemas operativos y su interacción con sistemas criptográficos. Encontramos que la mayoría de los sistemas de seguridad residían como software dentro del mismo sistema que generaba la información, por lo tanto surgió la idea de aprovechar las cualidades de las TI ya que tenían la ventaja de que el hardware donde se almacenan las llaves de seguridad o encriptamiento, se encuentra en un sistema aislado del equipo que genera la información a transmitir. El hecho de que la Tarjeta Inteligente trabaje independientemente del sistema generador de la información a transmitir mejora la seguridad, ya que contrarresta los ataques de “hackers” que intentan violar la integridad de un sistema utilizando los métodos por falla. Estos métodos, provocan una caída del sistema, con el fin de que cuando se está restableciendo sea posible conocer los comandos, que se intercambian entre un punto de la comunicación y otro. La TI al ser un dispositivo independiente de los dos puntos de conexión, está aislada de los ataques del exterior. Además al ser portátil no está expuesta a la intromisión de alguien que pueda usar la PC en donde se genera la información encriptada, como sucedería en caso de utilizar solamente un método de encriptamiento por software dentro de la PC. En un principio, la propuesta fue utilizar ANSI C para la programación de la aplicación del “lado de la PC”. Esto, porque ANSI C es un estándar y cumpliría con una gama más amplia de computadoras. En la decisión final, se tomó en cuenta que la plataforma de desarrollo debe ser más congruente con la idea de Internet y con una interfaz humana que proporcione facilidad de uso. Por lo expuesto anteriormente y debido a que un gran número de PC conectadas a Internet, operan con el sistema operativo Windows en sus distintas versiones, se optó por hacer uso de un lenguaje que maneje el concepto de Windows, dirigido a la programación de las DLL que controlan las funciones del lector y las funciones de la TI. Se tomó en cuenta otro concepto que

43

es el de crear una aplicación modular que pueda adaptarse o crecer de acuerdo a nuevas necesidades. Una pregunta obligada es ¿por qué no programar en Java, si se utiliza Internet?. La respuesta es que en el caso de hacer un desarrollo en Java con TI, existen tarjetas creadas especialmente para manejar API de Java, sin embargo no cuentan con el poder de los algoritmos de encriptamiento. Además se consideró que el C++ es un lenguaje que permite manejar mejor el caso general. Después de investigar, la Tarjeta Inteligente seleccionada (Cryptoflex) cumple con el objetivo ya que cuenta con un "criptoprocesador", el cual facilita las operaciones necesarias para crear llaves de encriptamiento y certificados digitales haciendo que la aplicación resida en la tarjeta y no en la PC, esto fortalece al sistema para combatir un ataque. Entendiendo como trabaja la tarjeta Cryptoflex sabemos que cumple con la norma ISO7816-4 la cual especifica que la TI debe contener 3 niveles de directorios, además de direcciones lógicas y una creación dinámica de archivos como se muestra en la figura 3.1.

Fig. 3.1: Niveles de directorios dentro de la TI

44

3.1. COMPONENTES Y EQUIPO PARA EL DESARROLLO El equipo utilizado es principalmente: la TI “Cryptoflex”, el lector de tarjetas “REFLEX 72” marca Schlumberger y los demás dispositivos en general como por ejemplo la PC donde residen la aplicación y el compilador de Builder C++ de Borland. La descripción de los componentes es solamente una perspectiva general de sus características y uso ya que no se pretende hacer un análisis de los mismos, sino utilizarlos como herramientas para brindar seguridad en la transmisión de datos a través de Internet. Además se intenta promover el uso de las TI como una opción de nuevas tecnologías y no hacer pública la información confidencial y registrada con derechos de autor del fabricante. La figura 3.2 nos muestra en bloques la arquitectura que utilizan las TI para su conexión en los sistemas de cómputo.

Fig. 3.2: Diagrama de conexión, lector de TI a la PC.

45

3.1.1. LECTOR DE TARJETAS “REFLEX 72” Este lector de TI trabaja con el puerto serial RS-232 de la computadora y es la interfaz entre el equipo de cómputo que puede ser una PC o una “estación de trabajo” y los diferentes tipos de TI.

Algunas de las características del lector REFLEX 72 son:

• Software residente de 32 Kbytes. • RAM de 32 Kbytes • Tiene una interfaz serial que cumple con RS-232, TTL o RS-485.

Fig. 3.3: Lector Reflex 72

Para poder utilizar este lector, es necesario utilizar el software controlador “driver” o DLL “Dynamically Linked Library” para el manejo de las entradas y salidas de datos (interfaz de la tarjeta con la interfaz RS232). Estos controladores para el lector vienen integrados en el paquete SLBreader y que para cada marca o modelo de lector existe un controlador diferente. El REFLEX 72 es compatible con la FCC17 y los estándares americanos para radiación electromagnética y además cumple con el estándar AFNOR 98020. La interfaz de la TI cumple con los requerimientos de la norma ISO7816-3.

El lector de tarjetas está diseñado con un Microprocesador 80C31 con los controladores de software instalados en una memoria externa EPROM de 32 Kbytes. Además, la configuración puede cambiar de 8 Kbytes a 32 Kbytes. El lector de tarjetas REFLEX 72 cuenta con un LED, “Ligth Emision Diode”, que enciende intermitentemente durante las instrucciones de inserción y retiro de tarjeta, la frecuencia de parpadeo es diferente para las dos instrucciones, lo que ayuda para distinguir entre una petición de retiro de tarjeta o una de inserción. Especificaciones de la comunicación serial:

• Velocidad: 9600 bps • Formato: 1 bit de comienzo, 8 bits de datos, 1 bit de paro • Paridad: igual a cero si la suma de los 8 datos es un número impar y 1 si es par • Niveles: RS232

La interfaz física está limitada a 3 señales que son:

• Recepción • Transmisión • Tierra

17 FCC : siglas de (Federal Communication Comission)

46

Existen dos protocolos de comunicación para el lector, cualquier lector de tarjetas que tenga el protocolo 3.1 o superior no tiene problemas para trabajar con lectores de un protocolo inferior pero si la versión es menor a 3.1 ese lector no podrá utilizar los programas que se crearon con versiones más actuales. Para la selección del lector se tuvieron que tomar en cuenta varios factores como son: • El tipo de alimentación eléctrica requerida • Cómo se conecta a la PC (interfaz física) • Qué facilidad hay para encontrar las DLL requeridas y que nivel de desarrollo tienen Otro de los aspectos a tomar en cuenta, son las dimensiones del lector de tarjetas que debe ser reducido para que sea práctico su uso además de que debe de cumplir con los estándares establecidos para las TI que se encuentran bajo las normas de ISO. El lector utilizado ha cumplido con las condiciones de operación mencionadas. Actualmente algunas marcas fabricantes de software se preocupan por la integración de lectores en las PC, por lo que las versiones de los sistemas operativos actuales cuentan con algunos controladores para lectores de TI, convirtiéndolos en dispositivos que se instalan bajo el concepto “Plug and Play” término del idioma inglés que se refiere a la instalación del dispositivo de forma automática gracias a que la PC reconocerá su conexión por tener el software necesario previamente instalado. El lector se conecta a cualquier PC que cuente con un puerto serial, sirviendo de interfaz entre la tarjeta inteligente y la computadora con la ayuda del software de aplicación desarrollado. Las partes desarrolladas son: la conexión entre el lector y la PC que es a lo que se hace referencia como la instalación del "Lector de Tarjetas" en el puerto serie de una PC, para esto se requirió de un programa desarrollado en Builder C++ que manipula las DLL de “Windows” (sistema operativo utilizado) creadas especialmente para el lector. Las funciones de DLL utilizadas en el lector son las siguientes y son de los tipos; de regreso de valor como por ejemplo: SLBAPI SYSTEM_ERROR, SLBAPI_UNVAILABLE, SLBAPI_CARDABSENT, LBAPI_CARDSWALLOWED, SLBAPI_POWERED, SLBAPI_CARDUNKNOWN, SLBAPI_NEGOTIABLEMODE, SLBAPI_SPECIFICMODE, SLBAPI_PROTOCOLERROR, también existen las de estado de ejecución que regresan un código de error, las cuales se mencionan a continuación: SLBAPI_OK, SLBAPI_ERROR, SLBAPI_TIMEOUT, las DLL del tipo de protocolo: SLBAPI_PROTOCOLT0,SLBAPI_PROTOCOLT1, SLBAPI_PROTOCOLUNDEFINED, SLBAPI_PROTOCOLROW, SLBAPI_CARDSYNCRHONOUS y las que definen el tipo de lector, que para este proyecto se utiliza sólo SLBAPI_RT_SERIAL pero existe una para trabajar con tarjetas de PCMCIA que es la DLL SLBAPI_RT_PCMCIA.

47

El lector está censando y espera el momento en que se introduce la TI de donde lee los directorios de la misma utilizando las siguientes funciones para poderla reconocer. Unas de las funciones principales son las de comunicación: SLBAPIAllocate, SLBAPIState, SLBAPIMonitor, SLBAPICancel, SLBAPIPowerUp, SLBAPIDown, SLBAPIReset, SLBAPISendIsoInT0, SLBAPISendIsoOutT0, SLBAPISendT1, SLBAPIFree, SLBAPIGetAllocateReader y funciones de manejo del lector como son: SLBAPIAllocateComManager, SLBAPIFreeComManager, SLBAPIGetNbrReaders, SLBAPIGetReaderName, SLBAPIGetFreePort Una vez que se tuvo idea de cómo manipular las DLL que programarían la comunicación con el lector, fue necesario hacer una adaptación de dichas DLL ya que fueron creadas en Visual C++. (Véase: Utilización de DLL de Visual C++ en un proyecto de Builder C++). Una vez instalado el lector, se puede hacer uso de la TI con sus herramientas de creación de llaves públicas y privadas para la transportación de información en la red de forma más segura. Este control de la tarjeta se realiza también, a través del software de aplicación desarrollado en este trabajo.

48

3.1.2. TARJETA INTELIGENTE "CRYPTOFLEX" Los principales usos de la tarjeta Criptoflex se pueden clasificar como: • Primera opción, correo electrónico y acceso a redes • Segunda opción, comercio electrónico y aplicaciones de consumo a través de WWW (World

Wide Web) Las características de la tarjeta se clasifican en 4 partes:

1: Características físicas 2: Dimensiones y localización de los contactos 3: Señales electrónicas y protocolos de transmisión 4: Comandos de intercambio industrial Interfaz Externa de la Cryptoflex Características eléctricas:

• La tarjeta Cryptoflex es capaz de soportar hasta ocho contactos, pero sólo seis de ellos son utilizados. Sus características cumplen con las establecidas en la norma ISO/DIS 7816-2. • El voltaje de alimentación para el contacto “Vcc” es de 5Volts c.c. +/- 0.5Vcc. • Máximo consumo de corriente: 5 mA a 5 Mhz.

Interfaz de comunicación La interfaz mantiene comunicación entre el lector y la tarjeta. La comunicación se basa en el estándar ISO protocolo T=0. Se transmite a 372 Baudios y el formato de la trama de transmisión es sin bit de paridad. La tarjeta Cryptoflex es compatible con los estándares ISO7816 en la identificación de tarjetas de circuitos integrados y de contactos. Sistema operativo de la tarjeta inteligente El sistema operativo de las TI, en esencia no es un sistema operativo como los programadores de software conocen. Este sistema operativo no tiene la funcionalidad que Windows, UNIX o MSDOS pueden ofrecer, el sistema operativo en la tarjeta contiene una colección de comandos que permiten a la tarjeta responder a instrucciones que provienen del exterior.

49

La relación básica entre la TI y una terminal, es como en una computadora en donde la tarjeta es insertada en un dispositivo que trabaja como maestro - esclavo. La terminal envía un comando a la tarjeta inteligente, la tarjeta ejecuta el comando y regresa un resultado hacia la terminal, en caso de no esperar otro. La máscara de la tarjeta o distribución del software interno está compuesta por cuatro capas que partiendo del núcleo son: 1. Funciones del sistema operativo básico:

• Direccionamiento • Parámetros de entrada/salida • Parámetros locales • Descriptores de los elementos

2. Sistema operativo avanzado: realiza el manejo de los recursos.

• Uso de la memoria • Memorias internas de la Unidad de Proceso Central • Funciones de seguridad

3. Comandos de concepto extendido:

• Carga software adicional en la memoria EEPROM18 y modifica comandos del sistema operativo avanzado.

4. Control para criptografía (hardware):

• Son todas las capas anteriores intercomunicadas por la capa S.C.O.S (Schlumberger Customer Oriented System), es el sistema que permite al programador descargar el código específico de la aplicación dentro de la memoria EEPROM 8 Kbytes ó 32 Kbytes como en el caso de la tarjeta utilizada.

La Tarjeta Inteligente Cryptoflex, es capaz de generar y almacenar llaves públicas y privadas que se utilizan en el encriptamiento y desencriptamiento de la información. Como se muestra en la figura 3.4, la TI cuenta con memoria RAM19, ROM, un sistema operativo que reside en un

18 EEPROM : (Electrically Erasable Programmable Read Only Memory) memoria de solo lectura programable y borrable electricamente.

19 RAM : Read Access Memory

50

microprocesador con funciones criptográficas y un árbol de directorios que tienen un directorio raíz, “root” y se extienden hasta 3 niveles más.

Fig. 3.4: Descripción de la TI, Cryptoflex

Las funciones encontradas en la TI seleccionada son similares a las manufacturadas por otros proveedores, tomando en cuenta que éstas deben de cumplir con la norma de ISO, “International Standars Organization”.

51

PREPARACIÓN E INICIACIÓN DE PARÁMETROS DE LA TI En la personalización se debe tener en cuenta que hay que configurar a la TI, configurándola con comandos básicos, hay que crear los directorios de archivos y de llaves, los cuales tienen que formarse en una tarjeta virgen. A continuación se presentan algunas líneas de código de personalización que pueden hacerse con la ayuda de comandos ISO o con algunos programas especialmente creados para personalización de TI. This Perso Script file was generated by GePeTo Version 1.34 ' Mask Model File : C:\Gepeto_V1\Mmf\Payfx_P5_V1.mmf ' Project : C:\GePeTo_V1\Projects\UserCinepolis_Rev25\UserCinepolis_Rev25.ppf '' ' File : \\3F00 Type : MF Action : EXISTING_DEFAULT_ACTION RST (W009/001/004) ' ' File : \\3F00\01 Type : V_K Action : PRESENT_EXT_KEYS IN(1 00 20 0000 08 I017/016 ) ' ' File : \\3F00\02 Type : V_APDU Action : PERFORM_APDU IN(1 00 24 0000 10 I017/016 I033/016 S/9000/ ) ' ' File : \\3F00\0011 Type : PVK Action : UPDATE_KEYS 'IN(1 00 24 0000 1039EA5C26587FA825 I033/016 ) 'IN(1 00 20 0000 08 I033/016 ) ' ' File : \\3F00\0020 Type : KEY Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 000A002012F02F000F0A00) IN(1 00 A4 0000 02 0020) IN(1 00 D2 0002 0A 00 I049/016 01) ' ' File : \\3F00\0000 Type : CHV Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 0014000022F02000000A00) IN(1 00 A4 0000 02 0000) IN(1 00 D2 0002 0A 03 I065/016 03) IN(1 00 D2 0002 0A 03 I081/016 03) IN(1 00 20 0010 08 I065/016 ) ' ' File : \\3F00\0030 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 0008003002022F000F0800) IN(1 00 A4 0000 02 0030) IN(1 00 D2 0002 08 FFFFFFFFFFFFFFFF) ' ' File : \\3F00\0040 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 0008004002022F000F0800) IN(1 00 A4 0000 02 0040) IN(1 00 D2 0002 08 FFFFFFFFFFFFFFFF) ' ' File : \\3F00\0060 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 0028006002022F000F1400) IN(1 00 A4 0000 02 0060) IN(1 00 D2 0002 14 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) IN(1 00 D2 0002 14 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) ' ' File : \\3F00\0070 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 000C007002022F000F0600)

IN(1 00 A4 0000 02 0070) IN(1 00 D2 0002 06 FFFFFFFFFFFF) IN(1 00 D2 0002 06 FFFFFFFFFFFF) ' ' File : \\3F00\0050 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 0002005002022F000F0200) IN(1 00 A4 0000 02 0050) IN(1 00 D2 0002 02 0000) ' ' File : \\3F00\0080 Type : EF Action : CREATE_STANDARD IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 0B 003C008002022F000F1400) IN(1 00 A4 0000 02 0080) IN(1 00 D2 0002 14 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) IN(1 00 D2 0002 14 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) IN(1 00 D2 0002 14 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF) ' ' File : \\3F00\1000 Type : DF Action : CREATE_MIN_SIZE IN(1 00 A4 0000 02 3F00) IN(1 00 E0 0000 09 03D210003822220000) IN(1 00 A4 0000 02 1000) ' ' File : \\3F00\1000\01 Type : V_K Action : PRESENT_EXT_KEYS IN(1 00 20 0000 08 I033/016 ) ' ' File : \\3F00\1000\0011 Type : PVK Action : CREATE_STANDARD IN(1 00 A4 0000 02 1000) IN(1 00 E0 0000 0B 001E001132F02200000A00) IN(1 00 A4 0000 02 0011) IN(1 00 D2 0002 0A 03 I097/016 03) IN(1 00 D2 0002 0A 03 I113/016 03) IN(1 00 D2 0002 0A 03 I129/016 03) '

52

Es necesario realizar otro proceso de personalización que consiste en cargar la llave de transporte que es propietaria de cada número de serie de tarjeta. Véase figura 3.5.

Fig. 3.5: Personalización de la TI

Una vez configurada la TI con los parámetros de inicio ya no requiere de este proceso para poder ser utilizada. Cuando se recibe la TI, esta se encuentra en un estado virgen donde se observan los siguientes archivos: • Un directorio maestro o raíz "root", que se identifica como (3F00), el cual contiene una llave

externa llamada el archivo de llave (0011), este archivo almacena la llave de transporte para desbloquear la tarjeta.

• El archivo (0002) que contiene el número de serie del circuito integrado de la TI como se muestra en la figura 3.6.

Fig. 3.6: Archivos de la TI antes de personalización

Llaves externas0011

Raíz3F00

Número Serie0002

53

Después de la personalización el sistema de archivos de la tarjeta queda como se indica en la figura 3.7.

Fig. 3.7: Archivos de la TI después de la personalización

En este punto se han creando directorios nuevos para el almacenado de llaves públicas y privadas que se utilizan en el encriptamiento y desencriptamiento de información dentro de la aplicación desarrollada.

3.1.3. INSTRUCCIONES DE LAS TI Formato para enviar los comandos a la tarjeta Cryptoflex El estándar de ISO 7816-3 define los formatos para la carga de comandos dentro de la tarjeta y estos comandos son dos: • Comandos de entrada, la tarjeta recibe datos desde el lector • Comandos de salida, el lector recibe datos de la tarjeta

El formato se define con los siguientes campos: Clase:: el tipo de instrucción Identificador (Ins): identificador de la instrucción P1, P2, P3: parámetros Datos: información a ser procesada SW1, SW2: estado de la tarjeta

La figura 3.8 muestra la trama de los comandos enviados por el lector o terminal a la TI y la respuesta de la TI al comando enviado. De esta forma son enviadas las instrucciones que permiten hacer uso de las funciones de la tarjeta.

Llaves externas0011

No. Serie0002

CHV0000

3F11 0005

Raiz 3F00

___________

54

Fig. 3.8: Formato de los comandos de entrada y salida de las TI

3.1.4. SOFTWARE PARA EL DESARROLLO DE LA APLICACIÓN No es necesario tener en el equipo de cómputo hardware muy sofisticado, basta que cuente con espacio suficiente en memoria para almacenar las aplicaciones y las componentes DLL que controlan al lector además de tener puerto serial instalado como ya se había comentado anteriormente. Las características que exigen mayores recursos son las requeridas por el sistema de desarrollo y programación utilizado en Windows, que para este proyecto es el Builder C++ el cual recomienda una PC con sistema operativo Windows 98 o superior con 64 MB en memoria RAM y espacio en disco duro de 2 GB. Además del software para desarrollar la aplicación, se requiere de las API, “Application Program Interface” y las DLL “Dynamically Linked Library” que utiliza el lector de TI para conectarse a la PC, estas librerías varían del tipo de lector y tarjetas a utilizar. El SmartCard DLL o CardDLL son DLL que permiten utilizar y crear el desarrollo de software de las aplicaciones con las TI y los lectores de TI utilizados. Actualmente existen más ventajas al usar las DLL en C++, a menos que sé esté utilizando una versión 1.0 que sólo contiene funciones de C para el acceso a la tarjeta.

55

Las versiones más actuales contienen objetos de TI que pueden ser integrados por los programadores en un ambiente orientado a objetos, haciendo la plataforma más amigable y general. En la versión 2.0 del CardDLL se tiene una integración de dos DLL, las de la TI, API DLL y del lector Schlumberger API DLL. CardDLL versión 2 puede ser utilizado para cualquier aplicación soportada por el estándar DLL de Windows, sin embargo existen algunos problemas de incompatibilidad entre las versiones de Borland C++ y Microsoft Visual C++. Por lo que la mejor opción es utilizar el paquete de DLL SLBreader. A continuación se muestra un diagrama de cómo están distribuidos los niveles del software y las DLL. Véase figura 3.9.

Fig. 3.9: Niveles de software que controlan a las TI

3.1.5. CAMBIO DE LAS DLL Se cambiaron DLL de Visual C++ para que pudieran ser utilizadas en un proyecto de Builder C++. El motivo de utilizar las DLL con Borland C++ fue para hacer más general el desarrollo y no cerrarlo a una sola plataforma o sistema operativo, de esta forma, se logra que el software pueda adaptarse más fácilmente a otros sistemas operativos. A continuación se describe como se realizan los cambios. Para llamar las DLL de Visual C++ en un proyecto de Builder C++ se deben tomar en cuenta 3 factores: el primero es el llamar a la DLL por sí misma en el archivo de cabecera “header”, que contiene las funciones prototipo así como el importar las librerías que soportan dichas funciones. Para llamar a la función DLL desde Builder hay que abrir el menú que tiene la opción Project/ Add to Project. Después hay que insertar una sentencia #include para que en el archivo de

56

“header” dentro del archivo en C++ pueda llamar a una de las DLL. Por último se agrega el código que llama a la función de la DLL. Se muestran a continuación dos códigos: el A y el B los cuales sirven como ejemplo de DLL. Tomando en cuenta que el código contiene dos convenciones de llamada: (_stdcall y _cdecl). Cuando se intenta compilar una DLL que fue compilada con Visual C++, la mayoría de los problemas resulta de los desacuerdos en las convenciones para la llamada de dichas DLL. También hay que tomar en cuenta que una función no necesariamente contiene la convención de llamada que ella utiliza. Esta función desconocida actuará como una etiqueta para las funciones de las DLL que no contienen su convención de llamada. //------------------------------------------ // Listado A: DLL.H #ifdef __cplusplus extern "C" { #endif #ifdef _BUILD_DLL_ #define FUNCTION __declspec(dllexport) #else #define FUNCTION __declspec(dllimport) #endif FUNCTION int __stdcall StdCallFunction(int Value); FUNCTION int __cdecl CdeclFunction (int Value); FUNCTION int UnknownFunction(int Value); #ifdef __cplusplus } #endif //------------------------------------------ //Listado B: DLL.C #define _BUILD_DLL_ #include "dll.h" FUNCTION int __stdcall StdCallFunction(int Value) { return Value + 1; } FUNCTION int __cdecl CdeclFunction(int Value) { return Value + 2; }

57

FUNCTION int UnknownFunction(int Value) { return Value; } Para crear una DLL de prueba a partir de los listados A y B, hay que abrir un proyecto de Builder C++ y traer el “Object Repository”, seleccionando en el menú la opción “File/New”. Se selecciona el icono de la DLL y se presiona el botón que indica OK. Builder creará un nuevo proyecto con un sólo archivo origen. Este archivo contendrá una función de entrada de la DLL y algunas oraciones que corresponden a los #include. Después se selecciona en el menú de “File/New Unit” y se salva una unidad como DLL.CPP. Se inserta el archivo de prueba dentro del archivo de header DLL.H. Luego se copia el código del listado B y se inserta dentro de DLL.CPP. Hay que asegurarse que la sentencia #define de BUILD_DLL_ se coloque antes de la sentencia del “include” para la DLL.H. Se salva el proyecto como BCDLL.BPR y después se compila, Builder generará la DLL y una librería de importación con extensión LIB. En este punto se tienen tres partes fundamentales para crear un proyecto que incluye una DLL en C++ Builder que son: • La DLL por ella misma • Un archivo de cabecera por función prototipo • Una librería de importación a la cual ligarse Ahora se necesita un proyecto de Builder que intente llamar a las funciones de las DLL creando un nuevo proyecto en C++ Builder y salvándolo en el disco duro. Se copia la DLL, la librería de importación y el archivo de cabecera DLL.H en el nuevo proyecto creado, se selecciona la opción “Project| Add To Project” y se agrega el archivo LIB. Después hay que agregar la oración de #include en la unidad principal que incluye a la DLL.H. Finalmente se agrega el código que llama a las funciones de la DLL. //------------------------------------------ // Listado C: MAINFORM.CPP – Programa de prueba para DLL #include <vcl\vcl.h> #pragma hdrstop #include "MAINFORM.h" #include "dll.h" //--------------------------------------------------------- #pragma resource "*.dfm" TForm1 *Form1; //--------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner)

58

: TForm(Owner) { } //--------------------------------------------------------- void __fastcall TForm1::Button1Click(TObject *Sender) { int Value = StrToInt(Edit1->Text); int Result= StdCallFunction(Value); ResultLabel->Caption = IntToStr(Result); } //--------------------------------------------------------- void __fastcall TForm1::Button2Click(TObject *Sender) { int Value = StrToInt(Edit1->Text); int Result= CdeclFunction(Value); ResultLabel->Caption = IntToStr(Result); } //--------------------------------------------------------- void __fastcall TForm1::Button3Click(TObject *Sender) { int Value = StrToInt(Edit1->Text); int Result= UnknownFunction(Value); ResultLabel->Caption = IntToStr(Result);} El problema con las DLL de Visual C++ en condiciones ideales es que al llamar a una DLL de Visual C++ no debería de tener mayor dificultad que llamarla de la misma forma que una DLL creada en Builder C++, desafortunadamente Borland y Microsoft son incompatibles en varios puntos. Por ejemplo, están en desacuerdo en los formatos de los archivos OBJ y en las librerías de importación. Es posible agregar una librería de importación de Microsoft para utilizarla en un proyecto de Builder C++. Gracias a la librería de Borland C++ IMPLIB las diferencias en los formatos de los archivos se pueden superar. Cada función en una DLL u OBJ tiene un nombre que la liga. El compilador busca las ligas de las funciones para resolver funciones que se utilizan durante el tiempo de ejecución. El compilador indicará un error externo en caso de que no pueda encontrar una función solicitada a través de nombre de liga y que se entiende utiliza el programa. Los dos productos también tienen diferencias en la forma en la que llaman a las funciones, por ejemplo las principales son: Visual C++ en algunas ocasiones nombra a las funciones de exportación con _stdcall, mientras que Builder C++ espera que las funciones de exportación sean nombradas como _cdecl. Entonces esto produce una inconsistencia en la convención para llamar a a_stdcall. Si se crea una DLL con Visual C++ que contenga una llamada _stdcall a una función nombrada como MiFuncion(), Visual C++ le dará un nombre de liga de función similar a _MiFuncion@4. Cuando el compilador de Borland intente hacer la liga a la función, no encontrará el nombre que espera para MiFuncion, entonces la librería de importación para la DLL de Visual C++ no

59

contiene ninguna llamada a función con el nombre MiFuncion y ésto provocará en el compilador de Builder un reporte de error externo. La forma en la que se resuelve este problema depende de como esté compilada la DLL de Visual C++ y se puede describir en 4 pasos: Paso 1. Identificar las convenciones para llamada a función de la DLL creada en Visual C++, Primero hay que investigar en el archivo de “header” para esa DLL, que normalmente será como se muestra a continuación: _declspec(dllimport) void CALLING_CONVENTION MiFuncion(int Nang); La función CALLING_CONVENTION podría ser _stdcall o _cdecl (como se muestra en el listado A). En muchos casos las convenciones para llamar a las funciones no se especifican, en estos casos la llamada por defecto será _cdecl. Paso 2. Examinar los nombres de liga incluidos en las DLL: Si en el paso 1 se observa que las DLL utilizan la convención de llamada de _stdcall, entonces hay la necesidad de examinar la DLL para determinar las convenciones para llamada que Visual C++ sigue cuando se crea la DLL. Visual C++ nombra las funciones con _stdcall, pero al programarse se puede prohibir el uso de este tipo de convención de llamada adicionando un archivo DEF en el proyecto. Si el proveedor de la DLL no utiliza el archivo DEF al momento de programarla, el proceso de la conversión de llamada es más tardado. La línea de comandos TDUMP permite examinar los nombres de liga de las funciones exportadas por la DLL. El siguiente comando llama a TDUMP en una DLL. TDUMP --ee MIDLL.DLL > MIDLL.LST TDUMP puede reportar mucha información sobre la DLL, sin embargo sólo hay que observar las funciones exportadas por la DLL. El comando --ee en la instrucción TDUMP muestra sólo la información de exportación. Si la DLL es larga, lo más recomendable es redireccionar la salida de la información de TDUMP a un archivo, para después verlo utilizando un procesador de palabras. La salida de la instrucción TDUMP para el ejemplo del listado A y B se muestra a continuación: Turbo Dump Versión 5.0.16.4 Copyright (c) 1988, 1998 (Borland International Display of File DLL.DLL) EXPORT ord:0000= 'CdeclFunction' EXPORT ord:0002= 'UnknownFunction' EXPORT ord:0001= '_StdCallFunction@4 ' Note que existe un guión bajo y la terminación @4 en la función _stdcall. La función _cedcl y la función desconocida no contiene convención de llamada adicional. Si la DLL de Visual C++ ha sido compilada con un archivo DEF las convenciones de llamada extras no deberían aparecer en la función _stdcall.

60

Paso 3. Generar una librería de importación para una DLL de Visual C++: Debido a las diferencias de formato entre las librerías de Borland C++ y Visual C++, no es posible agregar una librería de importación creada con Visual C++ en un proyecto de Builder C++. Se debe de crear una librería de importación OMF usando las líneas de comando de Builder C++. Dependiendo de que se encontró en los pasos anteriores 1 y 2 el proceso de conversión varía pudiendo ser muy sencillo o uno que tome más tiempo realizarlo como el caso encontrado en este trabajo. Dependiendo de las diferencias en la convención para llamar a las funciones dentro de las DLL se debe de seguir la tabla que se muestra a continuación como guía para la conversión. Convenciones de llamada para funciones en Visual C++ y C++ Builder Convención de llamada nombre VC++ VC++ (usando DEF) C++ Builder ----------------------------------------------------------------------- __stdcall _MiFuncion@4 MiFuncion MiFuncion __cdecl MiFuncion MiFuncion _MiFuncion Tabla 3.1. Los nombres de las funciones listadas en la columna correspondiente a Builder C++ es lo que el compilador de Borland ve. La primera columna del proyecto de Visual C++ no utiliza un archivo DEF. La segunda columna de Visual C++ contiene los nombres de liga que Visual C++ crea cuando un archivo DEF es usado. El nombre de las funciones de Builder C++ debe ir de acuerdo con las los nombres asignados en Visual C++. Con la finalidad de simplificar el proceso de conversión. En adelante es necesario crear una librería de importación que haga la equivalencia de los nombres creados para Visual C++ haciéndolos compatibles con los nombres que se asignan en Builder C++. Como se mostró en la tabla 3.1., existen varias combinaciones que hay que tomar en cuenta cuando se crea una librería de importación. Caso 1: Cuando la DLL sólo contiene funciones __stdcall y el creador de la DLL utiliza un archivo DEF. La tabla 3.1., muestra que Visual C++ y Builder C++ son compatibles cuando se utilizan funciones __stdcall. Sin embargo, las DLL deben ser compiladas con un archivo DEF para prevenir que Visual C++ haya agregado la convención de llamada de las librerías. El archivo de encabezado indica si la convención de llamada de __stdcall fue utilizada o no (paso1) y la función TDUM indica si la función contiene la convención de llamada adicional de Visual C++. (paso 2). Si la DLL contiene la función __stdcall y no incluye el complemento de llamada de Visual C++ entonces Builder C++ y Visual C++ son compatibles en como deben ser nombradas las funciones. Si es posible crear una librería de importación aplicando la librería IMPLIB sobre la DLL entonces no se necesita poner un sobrenombre a las funciones.

61

IMPLIB trabaja de la siguiente forma: IMPLIB (destination lib name) (source dll) Por ejemplo: IMPLIB midll.lib midll.dll Estos pasos crean la librería de importación la cual se puede agregar al proyecto como se indica mas adelante, en el paso 4. Caso 2: Cuando las DLL contienen funciones __cdecl o con la función __stdcall con suplemento de Visual C++ Si el proveedor de las DLL es inflexible cuando se trata de crear DLL que están compiladas de forma independiente, es muy probable que se caiga en el caso numero 1. Desdichadamente lo más probable es que se caiga en el caso 1 por diferentes razones: • La primera es, si la convención de llamada por defecto es __cdecl y el programador de la

DLL omite una convención de llamada con funciones prototipo, esto forzaría a caer en el caso 2.

• La segunda razón es que si se ha utilizado la convención de llamada del tipo __stdcall no se incluya un archivo DEF para quitar los complementos de llamada agregados por Visual C++.

Sin embargo, si éste es el caso estaríamos hablando de que se cae nuevamente en el caso 2 con un nombre de función que no es compatible con Builder C++. La única forma de salir de este problema, es creando una librería de importación que renombre las funciones de Visual C++ dentro de un formato compatible con Borland C++. Esto se logra utilizando la línea de comandos de herramientas "tools" siguiendo como primer paso la creación de un archivo DEF a partir de la DLL de Visual C++, para esto se usa el programa IMPDEF que viene con el paquete de Builder C++. IMPDEF crea un archivo DEF que enumera todas las funciones exportadas por la DLL. Se utiliza IMPDEF llamando como se muestra a continuación: IMPDEF (destination DEF file) (source DLL file). Por ejemplo: IMPDEF midll.def midll.dll Después de correr el programa de IMPDEF, se puede observar abriéndolo con un editor de archivo. Cuando se compilan los listados A y B incluidos anteriormente compilados por Visual C++ el archivo DEF creado por IMPDEF se observa de la siguiente forma. LIBRARY DLL.DLL EXPORTS CdeclFunction @1 UnknownFunction @3 _StdCallFunction@4 =_StdCallFunction @2

62

El siguiente paso es el alterar el archivo DEF con los sobrenombres de las funciones tal y como Builder los pueda interpretar. Puede ser renombrada una función escribiendo el nombre de compatibilidad con Builder C++ seguido por el nombre original en Visual C++. Para el ejemplo de los listados A y B el renombre en DEF es como se muestra a continuación. EXPORTS ; use this type of aliasing ; (Borland name) = (Name exported by Visual C++) _CdeclFunction = CdeclFunction _UnknownFunction = UnknownFunction StdCallFunction = _StdCallFunction@4 Notar que los nombres de las funciones mostradas del lado izquierdo son compatibles con los nombres de la tabla 3.1. Los nombres de las funciones a la derecha son los nombres de las funciones dentro de la DLL de Visual C++. El último paso para crear una librería de importación a partir del archivo DEF renombrado, es utilizar una vez mas la librería IMPLIB, con la excepción de que se corre IMPLIB en el archivo renombrado DEF como archivo origen, en lugar del archivo original de la DLL. El formato es: IMPLIB (dest lib file) (source def file) Por ejemplo: IMPLIB midll.lib midll.def Para crear la librería de importación hay que ir al paso 4 pero antes hay que examinar la librería de importación creada para asegurar que cada función de la DLL aparece nombrada con el formato que Builder C++ utiliza. Para inspeccionar la librería de importación se utiliza el programa TLIB. TLIB midll.lib, midll.lst El primer archivo de muestra se ve así: Publics by module StdCallFunction size = 0 StdCallFunction _CdeclFunction size = 0 _CdeclFunction _UnknownFunction size = 0 _UnknownFunction

63

Paso 4: Agregar la librería de importación al proyecto Una vez creada la librería de importación para la DLL de Visual C++ se puede agregar la librería de importación al proyecto de Builder C++ utilizando la opción del menú “Project | Add to Project”. Hay que utilizar la librería de importación sin tomar en cuenta el hecho de que contenga sobrenombres o no. Después de agregar la librería de importación al proyecto, hay que construir el proyecto y compilarlo para ver si se hace correctamente la liga correspondiente. Una vez resuelto el problema de las DLL, se estudiaron las funciones de entrada y salida de la tarjeta inteligente “Cryptoflex”. Primero fue necesario configurar la tarjeta con los parámetros de inicio, para esto se utilizó un programa de personalización que el fabricante de la tarjeta proporciona con la misma, veamos algunos de los comandos que inician el conjunto de directorios dentro de la Tarjeta Inteligente. La llave maestra conocida como la llave de transporte es la que se proporciona de fábrica. Cuando una tarjeta es totalmente virgen es necesario cargar la llave para poder hacer uso de la tarjeta Inteligente creando subdirectorios y habilitando sus funciones. 3.2. PROGRAMACIÓN DE LA APLICACIÓN Como ya se explicó anteriormente la aplicación consiste en la elaboración de un programa en C++ para controlar los comandos que la TI Cryptoflex tiene. Estos comandos permiten ejecutar algoritmos de encriptamiento y desencriptamiento así como controlar accesos a la red mediante la autenticidad del usuario. El primer paso fue la conexión del lector de tarjetas, para esto, se hizo una comunicación con el puerto serial de la PC, de esta forma se comprobó la interacción del lector y la tarjeta (ya configurada) por una parte y el lector con la PC por la otra. Básicamente se programó la UART y el puerto serie de la PC, sin embargo hasta este punto no se han incorporado las funciones de las DLL del lector de tarjetas. El fragmento de código del Anexo B, muestra una de las primeras versiones de la programación desarrollada incluyendo algunos de los comandos del lector de tarjetas y las funciones de las DLL que se utilizan para que el lector envíe instrucciones a la TI. Para que el programa serial funcione correctamente se deben de considerar los segmentos de código *.h que se incluyen con las instrucciones #includes, de la aplicación.

64

3.2.1. MÓDULO PRINCIPAL El programa se divide en módulos, los cuales son independientes unos de otros pero a su vez controlados por un menú principal, al cual no es posible tener acceso si no se tienen el número de identificación de la tarjeta y el NIP tecleado por el usuario. Los módulos del programa son: El módulo principal es el de encriptamiento y desencriptamiento que contempla los siguientes aspectos, los llamados de llave secreta y los de llave pública, esquemas generalmente utilizados para la seguridad en redes de datos. También aquí el programa ejecuta automáticamente la instrucción para que la TI genere la llave de sesión. En los sistemas de llave secreta simétrica, tanto el receptor como el transmisor utilizan la misma llave para encriptar y desencriptar la información como se mencionó en capítulos anteriores. El buen manejo de las llaves en este método es el que garantiza que todas las partes involucradas tienen la llave y que nadie externo al sistema tiene esa llave. En un sistema de llave pública asimétrico siguen existiendo dos llaves pero una es secreta llamada la llave privada y la otra es la llave pública, las llaves no son las mismas pero están relacionadas matemáticamente entre sí. La llave privada que es guardada en secreto por el propietario, no puede ser determinada utilizando la llave pública, esta última es distribuida a las partes con las que se desea establecer comunicación segura. La solución de seguridad más apropiada con TI es utilizar una combinación de las técnicas de llave pública y llave secreta. Los cálculos de la llave secreta utilizando el algoritmo DES son mucho más rápidos debido a la longitud de la llave utilizada (64 bits), que los cálculos de la llave pública utilizando el algoritmo del RSA de (1024 bits). Para incrementar la seguridad del sistema se utiliza una función que tienen las TI para generar llaves secretas a partir de la llave secreta principal, la cual está relacionada con el número de serie de la tarjeta y con una llave secreta única asignada por el fabricante (también conocida como llave de transporte) al momento de su creación. Cuando se hace uso del generador de llaves de la TI lo que sucede es que se crea una nueva llave aleatoria que es función de la llave secreta original nombrada como llave de sesión ya que se utiliza sólo una vez por sesión. La llave de sesión es una llave secreta desconocida para el usuario y se utiliza para encriptar el archivo plano utilizando el algoritmo de DES cada vez que se envía un mensaje. Esta misma llave secreta de sesión es encriptada utilizando la llave pública que corresponde al algoritmo de RSA. Esto quiere decir que la llave con la que se encriptó el archivo plano viaja posteriormente por la red encriptada con RSA utilizando la llave pública. El desencriptamiento consiste en tomar la llave que viene del transmisor desencriptándola con la llave privada y el algoritmo RSA. En este momento la llave de sesión es revelada al lado receptor y con ella se puede aplicar la desencripción del mensaje original que estáencriptado con DES. La figura 2.5 ilustra el proceso antes descrito. Resumiendo, con la llave secreta o de transporte de la TI se genera una llave que sólo se utiliza en esa sesión en particular y que ésta a su vez se reemplaza por la siguiente llave de sesión. Con

65

la llave de sesión encripta el archivo plano con DES y se encripta esta misma llave a su vez con RSA utilizando la llave pública. Para el caso de la aplicación desarrollada, se tiene el mismo procedimiento de la generación de llave de sesión descrito en el párrafo anterior con la adaptación de que se generan 2 llaves de sesión (S1) y (S2) para poder aplicar el algoritmo del 3DES en el archivo plano en lugar de utilizar DES. La figura 3.10 describe este proceso que a su vez será explicado con más detalle en la descripción de la aplicación sección “3.3.”.

Fig. 3.10: Dos llaves secretas por sesión para aplicar 3DES y posteriormente encriptadas con RSA

66

La idea global del módulo principal es el integrar los archivos que contienen la información dentro de la tarjeta, procesarla y comunicar esta información encriptada hacia la PC, posteriormente para ser reenviada a la aplicación que trabaja dentro de la PC y viceversa. Véase la figura 3.11.

Fig. 3.11: Diagrama a bloques de como se relacionan las partes programadas

67

INICIO

IDOK?

Salida E:01No

Yes

CAPTURAR NIPTECLEAR

(4 DIGITOS)

NIPOK?

Yes No CONT_NIP+1;

CONT_NIP=3?

No

*AUTENTIFICACION

Salida E:02

Yes

MENU DE ENTRADA

OPCIONES

ENCRIPTAMIENTO

LEER (ID)DE LA

TARJETA (TI)

DESENCRIPTAMIENTO

MANEJO DEARCHIVOS

3.2.2. DIAGRAMA DE FLUJO GENERAL DE LA APLICACIÓN En la figura 3.12, se muestra el diagrama de flujo descriptivo de la aplicación desarrollada. Con este diagrama de flujo se ilustra en términos generales como fue diseñada la aplicación. Para la entrada del módulo principal se tiene una pantalla que solicita la introducción de la tarjeta inteligente, una vez registrado el ingreso de ésta se pide que se teclee el NIP para poder tener acceso. En este diagrama se mezclan las aplicaciones del lado de la TI y las aplicaciones del lado del servidor, (PC). Los subprogramas de encriptamiento y desencriptamiento son desarrollos que dependen de las funciones de la TI y que al interconectarse con la PC muestran una interfaz gráfica al usuario.

Fig. 3.12: Diagrama de flujo de la aplicación

68

Creación de los menús para el manejo de archivos y edición de ventanas de Windows para poder integrarlos a la aplicación.

Fig. 3.13: Pantalla de C++, con las formas que integran una de las pantallas de la aplicación

En el Anexo C se muestra un fragmento de los códigos para el desarrollo de las pantallas del menú principal de la aplicación.

69

3.3. DESCRIPCIÓN DE LA APLICACIÓN Para analizar el desarrollo paso a paso de cómo funciona la aplicación para la seguridad de la información que se transmite en redes de TCP/IP utilizando TI, se dividirá su estudio en bloques. Los bloques deben ser observados como un flujo de la información que va desde una computadora conectada a un punto de una red TCP/IP a otro extremo con otro sistema de cómputo conectado. Véase la figura 3.14.

Fig. 3.14: Etapas que describen el proceso de la aplicación desarrollada

Etapa 1 En esta etapa, se parte del hecho de que se cuenta con un archivo plano, es decir un archivo tal y como fue creado sin haberle aplicado algún procedimiento de encriptamiento. Este archivo plano se tiene almacenado en una unidad lógica de una PC y que para fines prácticos se considera que el archivo se encuentra almacenado en el disco duro de la PC. Antes de enviarlo a otro punto de la red entiéndase como otro punto, otra computadora conectada a la red, se aplicarán dos algoritmos de encriptamiento de la siguiente forma. Etapa 1.1 Como ya se explicó en capítulos anteriores se cuenta con un lector de TI conectado al puerto serial de la PC origen, el cual se conecta con DLL previamente diseñadas y que cuyo control se encuentra dentro del módulo principal programado. En dicho lector hay que introducir la TI al momento que la aplicación ha iniciado el proceso y lo solicita a través de la interfaz gráfica construida con ventanas de Windows. La pantalla que se muestra en la figura. 3.15 corresponde a la solicitud de inserción de la TI en el lector.

Fig. 3.15: Pantalla de inserción de TI en el lector

Encriptamiento del archivo

plano

Transmisióndel archivo ya

encriptado

Recepcióndel archivoencriptado

Proceso dedesencriptamiento

Archivooriginal

de formasegura

Archivoplano

Etapa 1 Etapa 2 Etapa 3

70

En caso de que no se inserte la tarjeta el programa mandará un mensaje de error donde se niega el acceso, aparecerá este mensaje de igual forma si se comete un error al teclear el PIN de acceso. En la figura 3.16, se muestra la pantalla de la aplicación que indica cuando hubo un error en el tecleo del NIP o en la inserción de la TI.

Fig. 3.16: Acceso Negado por error en NIP o por no detectar una TI

Como ya se ha mencionado antes, las DLL de TI permiten desarrollar aplicaciones utilizando códigos que contienen los parámetros para las funciones requeridas. Donde hay que poner énfasis es en el manejo de la memoria interna de la tarjeta con la finalidad de evitar fallos generales del sistema por un mal uso de las librerías. Recientemente las librerías de los distintos fabricantes de tarjetas están siendo diseñadas para trabajar en ambientes de C++ orientados a objetos a diferencia de los primeros desarrollos que sólo eran programados en C. En las interfaces de software de tarjetas para trabajar en Windows es necesario considerar problemas de compatibilidad entre Visual C++ y Borland C++ Builder. Véase la sección para la conversión de una DLL de Visual C++ a Borland C++. Al momento de teclear el PIN en el teclado de la PC se ejecuta una rutina que permite identificar si se tiene el acceso a la aplicación o no. Hasta este momento se ha explicado como se utiliza la tarjeta para poder entrar a la aplicación. La pantalla que se muestra en la figura 3.17 solicita que se teclee el número de 4 dígitos que permite la entrada a la aplicación.

Fig. 3.17: Pantalla de solicitud para teclear el NIP

71

Cuando se solicita el acceso a la aplicación se tiene que insertar la TI y teclear el código de seguridad de 4 dígitos y en caso de que no se inserte la tarjeta o se teclee mal el PIN se ejecuta el siguiente código que muestra al usuario que el acceso ha sido negado. Véase el Anexo C. Etapa 1.2 En esta etapa ya se tiene el acceso a la interfaz gráfica para poder aplicar los algoritmos de encriptamiento y por lo tanto, ya se garantizó la autenticidad de la persona que va a utilizar la aplicación. Etapa 1.3 En esta etapa 1.3 el primer paso es seleccionar el archivo a encriptar a través de los menús de la aplicación, es decir es el momento en donde se selecciona el archivo plano dentro de la PC para posteriormente aplicarle el procedimiento de encriptamiento. La figura 3.18 muestra la pantalla de la aplicación donde se selecciona el archivo a ser encriptado.

Fig. 3.18: Selección de archivo a ser encriptado

72

Una vez que se seleccionó el archivo a encriptar se debe de presionar el botón de ´Encriptar´. Cuando se activa el botón ´Encriptar´ del menú principal se realizan los procesos de encriptamiento y se despliega la pantalla que a continuación se muestra en la figura 3.19.

Fig. 3.19: Pantalla del proceso de encriptamiento

El primer proceso consiste en tomar la llave privada de sesión (S1) generada por la TI y encriptar el archivo seleccionado con DES el resultado es el archivo (AE), después se genera la llave de sesión (S2) para aplicar DES-1 al archivo (AE) y el resultado es (AE2), por último se utiliza la llave de sesión (S1), para aplicar el DES a (AE2) y el resultado es el 3DES aplicado al archivo que resulta ser (AE2) y éste se envía por la red. Posteriormente se encriptan las llaves de sesión (S1) y (S2) con la llave pública correspondiente al algoritmo RSA y se envían por la red al destinatario. Etapa 1.4 El encriptar el número 1 que se encuentra dentro de un archivo de WinWord con la combinación de ambas llaves (S1, S2), nos dará como resultado aproximadamente un archivo de 542 líneas de caracteres irreconocibles, si los visualizáramos en cualquier analizador de archivos o procesador de palabras se vería un fragmento como se muestra en la figura 3.20. C756194618175C5C92034C134D42090999EB6C9A0FECB68DA9942D36FB2BE57A8185B8558A75F46F7E6F57246A43726EA6BA22AD871CDCAFE86527628C85A93D1F636EECEC427711F9C0E2513EBB5797EF4F71CC640D380F9A325D85692288D1EC79B488870EEC316FAA16CEDC6EB1982FE43492861560BDCC2F10A95E50F7D765BB35D384CE2BC9A5593E7C23F710BD FILENAME 1.DOC/GENDATE 09|12|02-10:06:05/INTEGRITY 27B8487356DDFDC5AC619F193667B4BE4FAC1D5571227456/SOFTVERSION 2.3.1/CARDVERSION 1001/CARDMANUFCODE 0711/MOREINFO FILEORDATE=09|12|2002-10:05:38 FILEORSIZE=19456 _L__®B?@‰–jøt ¼'P'H_0³îÓl‚¥> Šm¶:6æ´®º’Gen>ä½Q…_ÄMÔ_è{”_/å¨-P¾-(_-ÕÕF! _,�„†>µË{uºP_Âm_šü0˜�å¨ðLƒ_ wÚþòænï�ûC _²ŒA"•-ƒ¯åÿÇ”¥înÒ%"¼ŠS^DÛ«_xwÑ[â/œÊö»¶ÆÔb’/[x__q0tÒÖ3Éîktó-è__usxpkSWü÷ïGI�±ZišR_ø�êqÑTÜÄ�%_òíìèíÀÍÈ›_¤ŠS_áØkq)‡�- šø¸�_¼>×9fȨIÙó_��¾qŒk�Y5ô.ü½^_wZBE'™h™ 8˜�ëÒ?uXÍ-!«x ÷( ä£)˜__O«þ_ýé�øå^ …–—´íÓ;»_T] f_¤__|ïµ� ‡�{íUþ_ê±_`)bn°°Šš\ZTB·^±˜_ÀÖGµ#?ƒ|-ì첯¥W'æ½Èµ³’SA³i__²Ñ:lp_á•›} ci_ xC}ˆ8_1Y__°u‰,´ �ª¨xœ‘8 ÇÆ_�ø–lh�*ãË�åÍ�Ñò‹_Ð_[ÄŸæ__$’ïÏIÀ;o_MxSüHÎÀwÀj�!T ú/X��) ¢>Ç_W�_äS|¹:_$hAò¯¾·__vlë‰Ò‹_x}_'�ú_5YüªËA¸¬(,j}rk“ãoùÝI«tCS¼×H_’k —¤“4âÏ}þ좗6_ú�šßM_�»_ƒ_Æ+¢qõ..............................

Fig. 3.20: Fragmento de 16 líneas del encriptamiento del número 1 visto en Winword

73

La 3.21, muestra dos ventanas que corresponden a la edición y lectura del archivo a encriptar en un procesador de palabras. La pantalla de la izquierda muestra el archivo con el archivo plano que dice "Éste es un archivo plano de prueba, el cual será encriptado" y la pantalla de la derecha nos muestra el Archivo después de haberle aplicado el encriptamiento con 3DES que a su vez tiene encriptada la llave con el algoritmo de RSA. Como se puede observar, si alguien intenta abrir el archivo utilizando un procesador de palabras éste sería completamente ilegible.

Fig. 3.21: Se observa archivo plano a la izquierda y archivo encriptado a la derecha

Etapa 2 El archivo encriptado Una vez que el archivo o mensaje plano a pasado por el proceso de encriptamiento se visualiza en la aplicación con una extensión *.SPDX este archivo ya no es recuperable, a menos que se cuente con la llave para poderlo desencriptar utilizando los métodos ya estudiados. Véase la figura 3.22.

Fig. 3.22: Pantalla del menú de encriptamiento y desencriptamiento

74

Para la transmisión del mensaje encriptado es necesario presionar el botón de Enviar. Este botón activa una rutina con DLL de Winsock de TCP/IP para Windows. La transferencia del archivo encriptado se capturó por un analizador de protocolos en modo promiscuo, para poder comprobar que el mensaje enviado es ilegible aún analizándolo a los niveles básicos como sería del análisis de bit a bit. Ya que el propósito de este trabajo es hablar de un método seguro para transmitir en una red de TCP/IP se estudiaron redes de datos que utilizan estos protocolos para poder transferir archivos de una computadora a otra. Dentro del desarrollo del presente trabajo, ha sido necesaria la creación de interfaces para poder aprovechar los beneficios de una comunicación segura utilizando TI. Para poder entender el cómo se han desarrollado las interfaces necesarias para transmitir los archivos encriptados utilizando las TI, considero importante el tema de los sockets el cual se detalla en el Anexo A. Etapa 2.2 Se observó el archivo plano que fue enviado a través de una red TCP/IP de área local utilizando un analizador de protocolos en el modo promiscuo. La pantalla de la figura 3.23 a continuación nos muestra las tramas enviadas y el contenido del archivo de muestra que es “archivoprueba.doc” el cual viajó primero por la red sin ser encriptado para que después pudiera ser comparado con el archivo que se envió encriptado. En la parte inferior derecha, hay un círculo que nos muestra el contenido del archivo plano a través del analizador de protocolos.

Fig. 3.23: Archivo plano observado con analizador de protocolos al ser enviado

A continuación se muestra el mismo mensaje encriptado con la aplicación desarrollada el cual no podrá ser desencriptado a menos que se apliquen los algoritmos inversos correspondientes y para

75

hacer esto, se deben conocer las llaves para desencriptarlo tal y como se explicó en la sección de criptografía. Se utilizó de igual forma un analizador de protocolos para poder ver lo que viaja por la red de TCP/IP de área local y en esta ocasión se envía el archivo ya encriptado el cual viaja de forma segura a través de la red. La figura 3.24 ilustra lo que la pantalla del analizador de protocolos capta en el momento en que está viajando el archivo encriptado. En la parte inferior derecha se encuentra el contenido del archivo que se transmitió de forma segura.

Fig. 3.24: Pantalla que muestra el archivo encriptado con la ayuda de un analizador de

protocolos

Finalmente, para concluir la explicación del funcionamiento de la aplicación es necesario considerar que el archivo una vez encriptado y estando en el otro extremo de la transmisión, (nodo remoto), requiere de los procesos de desencriptamiento para poder ser utilizado como era originalmente. La aplicación hace uso del mismo menú principal para activar las funciones de desencriptamiento cuando se presiona el botón "Des_encriptar".

76

3.4. RESULTADOS Y COMENTARIOS Una de las partes críticas del proyecto es el tener la selección adecuada del equipo a utilizar, ya que cada lector de TI o cada tipo de tarjeta cuentan con diferentes comandos o controladores que pueden determinar la aplicación o modificar la forma en la que se desarrolle la aplicación. En el caso de la tarjeta Cryptoflex se tiene una distribución particular de directorios o archivos que se dirigen desde el archivo maestro o “master file” (MF) y de ahí se derivan una serie de archivos que pueden ser los “dedicated files” (DF) o “elementary files” (EF), esta forma de organizar los archivos internos de la tarjeta es a su vez controlada por una estructura de los datos o instrucciones que se pretenden manejar en la aplicación, por ejemplo; si se quiere hacer una instrucción de escritura se tiene el descriptor para dicho comando que implica un bit de clase, uno más de la instrucción en sí, 3 bits de parámetros y de datos. De acuerdo a la norma ISO7816 se tiene definida una comunicación serial entre el lector y la tarjeta de forma asíncrona para una TI y una síncrona para el manejo de las tarjetas de memoria (sin microprocesador). En nuestro caso es el asíncrono y se utilizan bloques de información que son transmitidos en una comunicación serial sin la necesidad de tener un control de tiempo. Al ser asíncrona la comunicación de las diversas aplicaciones creadas en la TI, son más independientes. Como se analizó en los capítulos anteriores es un proyecto de integración e involucra diversos conocimientos y dispositivos, como son: las TI que incluyen un criptoprocesador (lo que exige el conocimiento de sus registros y archivos internos para ser programados), los lectores de tarjetas en los cuales hay que programar las interfaces al puerto serie, sistemas de cómputo PC, tipos de software como es el sistema operativo de la PC, Windows, el lenguaje de programación de ANSI C y Builder C++ para crear la aplicación, las librerías de control DLL del lector y de las TI, conocimientos de cómo aplicar el encriptamiento de datos utilizando DES, 3DES, RSA y transmisión de datos a través de redes de computadoras utilizando los protocolos de TCP/IP. Finalmente utilizando un analizador de protocolos se hizo la observación de los resultados de las tramas encriptadas enviadas por una red comparándolas con tramas planas es decir sin encriptamiento. Para lograr el objetivo se utilizó un método compuesto por software y hardware como lo es la solución con TI. Este método se complementó con la combinación de dos algoritmos de encriptamiento RSA y 3DES. En la programación de la tarjeta hay que considerar su configuración inicial, programación de la aplicación interna y su uso, adaptándola a la interfaz gráfica de la PC.

77

3.5. CONCLUSIONES DEL CAPÍTULO En el presente trabajo se utilizan métodos criptográficos como parte de las herramientas que las TI contienen previamente programadas. Las TI en sí, son otras herramientas que a su vez proporcionan una gran flexibilidad de uso, ya que pueden ser analizadas como un sistema mínimo de computadora el cual puede ser programado para alguna aplicación específica y deja en la creatividad del programador su utilidad práctica. El hecho de que la TI trabaje independientemente del sistema generador de la información a transmitir, mejora la seguridad ya que contrarresta los ataques de intrusos que intentan violar la integridad y confidencialidad de un sistema utilizando los métodos por falla. Entendiendo como trabaja la tarjeta Cryptoflex sabemos que cumple con la norma ISO7816-4 la cual especifica que la TI debe contener 3 niveles de directorios, además de direcciones lógicas y una creación dinámica de archivos. El lector de TI trabaja con el puerto serial RS-232 de la computadora y es la interfaz entre el equipo de cómputo y la TI. Otro punto digno de mención es el hecho de buscar una plataforma que no pierda generalidad y pueda emigrar fácilmente de un sistema a otro, por este detalle se tuvo la necesidad de hacer algunas modificaciones al código de tal forma que pudieran trabajar en un ambiente no propietario de MicrosoftTM. Se utilizaron las DLL creadas para Borland C++ para hacer más general el desarrollo y no cerrarlo a una sola plataforma o sistema operativo. En la personalización de las TI se configura inicialmente con comandos básicos que crean los directorios de archivos y de llaves. Estos directorios y archivos no existen en una tarjeta virgen y son necesarios para programar la aplicación del "lado de la tarjeta". Como ya se explicó anteriormente la aplicación del "lado del servidor" consiste en la elaboración de un programa en C para controlar los comandos que la TI Cryptoflex tiene. Estos comandos permiten ejecutar algoritmos de encriptamiento y desencriptamiento así como controlar accesos a la red mediante la autenticidad del usuario. El programa se divide en módulos, los cuales son independientes unos de otros pero a su vez controlados por un menú principal, al cual no es posible tener acceso si no se tienen el número de identificación de la tarjeta y el NIP tecleado por el usuario.

78

4. CONCLUSIONES

El proyecto, puede llegar a desarrollarse partiendo de una base práctica y posteriormente ir incrementando el grado de seguridad adquirido con la ayuda de algoritmos de encriptamiento más complejos. El incremento en la seguridad consiste en utilizar dos métodos criptográficos combinados y el uso de la TI como auxiliar externo al sistema. La TI representa una ventaja fundamental en cuanto a seguridad por hardware se refiere, ya que es portátil y de uso personal. Según la clasificación de seguridad que se presentó anteriormente, la aplicación desarrollada no puede demostrar su integridad teóricamente por ser una combinación de métodos o algoritmos de encriptamiento pero este tipo de sistemas en la práctica son extremadamente seguros y según la información investigada no han sido violados. Veáse: Seguridad probable y seguridad computacional, página 30, la cual nos dice que un sistema podría ser vulnerado pero en tiempos que no permitirían al intruso obtener provecho de la información transmitida. Por otra parte, el utilizar una tecnología de gran uso como sería las redes de TCP/IP implica el uso de nuevas tecnologías como las TI, creadas exclusivamente para aplicaciones de seguridad gracias a que su criptoprocesador es capaz de almacenar y generar llaves públicas, privadas y cuenta con funciones de encriptamiento. Un punto fundamental en el planteamiento de la seguridad es que se aportan dos conceptos innovadores y que ya se mencionaron pero vale la pena repetir: el primero de ellos es el hecho de mezclar varios métodos de encriptamiento haciendo la plataforma mucho más robusta, el segundo es el apoyarse en hardware externo a la plataforma utilizada, esto evita el acceso al sistema por métodos de falla. Sin duda los métodos utilizados pudieran ser mejorados en un futuro próximo ya que los sistemas de TI y su acoplamiento a las redes de datos se están desarrollando rápidamente, sin embargo por el momento podemos afirmar que lo que se presenta en este trabajo es un método que ofrece la gran seguridad en redes TCP/IP. En la tesis se plantea un sistema que utiliza una de tantas TI que existen, sin embargo los temas se tratan con la generalidad suficiente como para poder emigrar esta aplicación a otros ambientes de trabajo utilizando otro diseño o tipo de lector o TI.

79

5. BIBLIOGRAFÍA

[1] WILLIAM STALINGS, Network Security Essencials: Aplications And StandaHall, UK 2000

[2] S. C. COUTINHO, The Mathematics of Ciphers A K Peters Natick, Massachusetts 1999

[3] DORASWAMY N., HARKINS D, The New Security Standard for the Internet, Intranets, and Virtual Private Networks , Prentice Hall, USA 1999

[4] KENT REISDORPH, Aprendiendo Borland C++ Builder, Prentice Hall Hispanoamericana, España, 1999

[5] JOSÉ A. CARBALLAR, El libro de las comunicaciones del PC, Alfaomega, México 1997

[6] SCHNEIER B, Applied cryptography: protocols, algorithms, and source code in C, John Wiley & Sons. USA 1996

[7] JOSÉ ANTAO BELTRAO MOURA, Redes Locales de Computadoras, McGraw-Hill, España 1991

[8] SCHNEIER B, How to evaluate security technology, Computer Security Journal, USA, 1999

[9] COMER D., Redes Globales de Información con Internet y TCP/IP, Prentice Hall, Hispanoamericana, México, 1998

[10] HENRY DREIFUS & TOMAS MONK, Smart Cards, John Wiley & Sons, Inc, Cánada, 1998.

[11] AMAPRO FÚSTER SABATER, Técnicas criptograficas de protección de datos, Alfaomega, México 1998

[12] COTT B. GUTHERY & TIMOTHY M. JURGENSEN, Smart Card Developer's, Macmillian Technical Publishing, USA 1998

80

[13] WILLIAM STALINGS, Comunicaciones y redes de computadores, Prentice

Hall, 5° Edición, México, 1997

[14] KRIS JAMSA, KEN COPE, Programación en Internet, McGraw-Hill., México, 1996

[15] SCHNEIER, B. WILEY, Cryptography: Protocols, Algorithms, and Source Code Applied in C, Circa printing, 1995

[16] BARRY B. BREY, Los microprocesadores lntel, Prentice Hall, México, 1995.

[17] KEVIN STOLTZ, Todo acerca de redes de computación, Prentice Hall, México, 1995

[18] ANDREW S. TANENBAUM, Redes de Computadoras, Pentice Hall 2ª. Edición, México, 1991

[19] LATHI, Sistemas de comunicación, Interamericano, México 1989

[20] CRISTIAN METAIRIE, Redes Locales "Teoria y Programación de las redes IBM", Paraninfo, Madrid,1989

[21] STREMLER, Sistemas de comunicación, Alfaomega, EUA, 1989

[22] Cryptoflex Card Reference Manual, Schlumberger, January 1997

[23] Card DLL Reference manual, Smart Reader Desing Specification, Microsoft corporation, December 1997

[24] S. KAWAMURA, M. KOIKE, F. SANO, AND A. SHIMBO. Cox-rower archi-tecture for fast parallel montgomery multiplication. In Advances in Cryptology - EUROCRYPT 2000 (LNCS 1807), pages 523–538, May 2000.

[25] J.-J. QUISQUATER AND C. COUVREUR. Fast decipherment algorithm for RSA public-key cryptosystem. IEE Electronics Letters, 18(21):905–907, October 1982

[26] R. RIVEST, A. SHAMIR, AND L. ADLEMAN. A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 21(2):120–126], February 1978

81

Referencias de Internet

[27] R. RIVEST, A. SHAMIR, L. ADLEMAN, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, Vol. 21, No. 2, pp. 120-126, Feb. 1978. http://theory.lcs.mit.edu/~rivest/publications.html

[28] PETER HAMILTON-SCOTT, "The bits.." "the C++ Builder Information & Tutorial Site" http://www.cbuilder.dthomas.co.uk

[29] "Using Visual C++ DLLs in a C++Builder Project" http://bcbdev.com/articles/vcdll.htm

[30] LAWRIE BROWN, "Introduction to Number Theory" 24 April 1996 http://www1.shore.net/Security-Notes/lectures/publickey.html

[31] D. COPPERSMITH, M.K. FRANKLIN, J. PATARIN, M.K. REITER, "Low-Exponent RSA with Related Messages," Advances in Cryptology - EUROCRYPT '96 Proceedings, pp. 1-9, Springer-Verlag, 1996. http://www.bell-labs.com/user/reiter/#Lowexp

[32] M. BELLARE, P. ROGAWAY, "Optimal Asymmetric Encryption -- How to Encrypt with RSA", Advances in Cryptology - EUROCRYPT '94 Proceedings, pp. 92 - 111, Springer-Verlag, 1994. http://www-cse.ucsd.edu/users/mihir/papers/oaep.html

[33] P. ZIMMERMANN, The ECMNET Project: Elliptic Curve Method for Factoring http://www.loria.fr/~zimmerma/records/ecmnet.html

[34] J-S. CORON, F. KOEUNE, D. NACCACHE, "From Fixed-Length to Arbitrary-Length RSA Padding Shcemes", Advances in Cryptology - ASIACRYPT '00 Proceedings, pp. 90-96, Springer Verlag, 2000. http://www.di.ens.fr/~pnguyen/pub.html#DuNg00

[35] Signal Guard, Rijndael/AES Algorithm http://www.signalguard.com/encryption/aes-rijndael.html

[36] J. ORLIN GRABBE, "The DES Algorithm Ilustrated" http://www.aci.net/Kalliste/des.htm

82

ANEXO A. DESARROLLO DE SOCKETS

Los diseñadores de la interfaz de sockets originalmente la construyeron dentro del sistema operativo UNIX, pero otros ambientes, como Microsoft Windows, la implementan como bibliotecas de programación. En ambientes diferentes a UNIX podemos llamar a una rutina de la biblioteca de sockets para comunicarse en una red TCP/IP. Entrada/Salida de red y Entrada/Salida de archivos Los diseñadores desarrollaron la interfaz de sockets durante el proyecto para llevar la TCP/IP al sistema operativo UNIX. Como resultado modelaron la interfaz de sockets a partir de las llamadas del sistema UNIX ya existentes. En UNIX utilizamos las mismas llamadas al sistema para acceder a impresoras, unidades de cinta y archivos del sistema. Para abrir un archivo o para acceder a un dispositivo, se llaman a las mismas funciones del sistema. En respuesta a tales llamadas la función devuelve un apuntador, el cual se llama, en UNIX, archivo descriptor, que apunta a un registro en una tabla que describe el archivo o al dispositivo. Para un archivo, el registro del archivo descriptor en la tabla contiene información como el nombre, el tamaño y la fecha del archivo. Un archivo descriptor de UNIX puede apuntar a un archivo, a un dispositivo de hardware o cualquier otro equipo que cumpla funciones del sistema de E/S. Para comunicarse con una red TCP/IP, el programa primero abre una conexión con la red, después lee y escribe datos a través de ella y por último, cierra la conexión. Desde una perspectiva UNIX, este enfoque de diseño hace una comunicación en red como cualquier otra función del sistema de E/S, es más fácil de integrar al sistema operativo UNIX. Socket como Concepto: Podemos pensar en un socket como en una punta o un extremo de la comunicación por red. Esta involucra dos computadoras o dos procesos que se pasan datos entre sí a través de la red. Cada lado de la comunicación en red lo llamamos extremo “endpoint”. Cuando el programa utiliza la Interfaz de sockets para una comunicación en red, el socket es una representación abstracta del extremo en el proceso de comunicación. Para que haya comunicación

83

en una red, el programa necesita un socket en cada lado que conversa. La conexión puede ser orientada a conexión o sin conexión. El modelo de la interfaz de sockets para la comunicación en red aún emplea al proceso básico abrir-leer-escribir-cerrar. Cuando necesitamos un socket para una comunicación en red, definimos sus características y utilizamos una API para solicitar al software de red, un identificador que reconozca al socket especificado. No obstante, un identificador de socket difiere en forma sutil pero significativa de un identificador de archivo. Identificador de Archivos e Identificador de Sockets: Los pasos a seguir para obtener un identificador de sockets o de archivo son muy similares. Sin embargo, los registros de la tabla a la que apuntan estos identificadores varía de modo significativo. (Mientras un especificador de archivo apunta a un archivo específico que ya existe o lo hemos creado) o a un dispositivo, un identificador de socket no representa un extremo específico o una dirección destino. Esta es la diferencia con la mayoría de los sistemas de E/S de archivos. En casi todos los sistemas operativos, un identificador de archivo válido debe apuntar a un archivo específico en el disco duro pero, los programas basados en Sockets crean un socket y entonces, lo conectan al extremo destino. La E/S de archivo tiene un proceso similar: una aplicación debe obtener un identificador de archivo válido del sistema operativo y entonces, como paso aparte, específica la localización del archivo de disco. Consideremos los requerimientos de un programa de red TCP/IP que transmite un datagrama utilizando protocolos sin conexión. El programa especifica la dirección destino del datagrama pero no establece una conexión directa con el anfitrión, sino que transmite el datagrama a la dirección destino. El software de red (la capa IP, específicamente) maneja el proceso de entrega. Para integrar los protocolos TCP/IP al sistema operativo UNIX se tuvieron que agregar nuevas capacidades al sistema de E/S de UNIX. La API de una red TCP/IP necesitaba una forma de obtener un identificador de E/S válido sin crear una conexión directa con la dirección destino de E/S (el anfitrión de red). En vez de tratar de modificar las funciones de E/S existentes en UNIX, crearon una nueva función llamada socket. La función socket permite que un programa obtenga un identificador de socket sin especificar la dirección destino. Creación de un socket Cuando se crea un programa TCP/IP necesitamos las habilidades de los protocolos orientados a conexión y sin conexión. La interfaz de sockets permite a los programas emplear ambos tipos de protocolos a través de una conexión socket. Para crear un socket, el programa llama a la función socket. Esta devuelve un identificador similar al descriptor de archivo, sea que el identificador de socket reconoce un registro en la tabla de descriptores que proporciona información sobre el socket.

Socket_handle= socket (protocol_family, socket_type, protocol) Al crear un socket se deben especificar tres parámetros: la familia de protocolos (protocol_family), el tipo de socket (socket_type) y el protocolo (protocol). El parámetro familia

84

de protocolos identifica a una familia o´ colección de protocolos relacionados, como el conjunto de protocolos TCP/IP. El parámetro tipo de socket específica si el programa utilizará el socket para transmitir un datagrama20 o un flujo de bytes. El parámetro protocolo identifica al protocolo específico que quiere ocupar el programa en este caso, TCP.

Parámetros de la Función Socket Conforme se integraron los protocolos TCP/IP al sistema operativo UNIX, también desarrollaron una API de propósito general para múltiples redes, no sólo TCP/IP que ejecute UNIX. Aunque al principio se enfocaron a crear una interfaz para TCP/IP, trataron de diseñar una interfaz de sockets que pudiera usarse en otras redes. Para lograrlo usaron el concepto de familia de protocolos y direcciones. El primer parámetro de la función socket (que crea un socket) identifica a una familia de protocolos como el conjunto de protocolos TCP/IP. La función socket requiere que el programador identifique el protocolo que utilizan sus programas, la interfaz de sockets puede establecer comunicación con múltiples redes. La interfaz de sockets utiliza constantes simbólicas para identificar las familias de protocolos soportadas. Por ejemplo, la constante simbólica PF-INET identifica a la familia de protocolos de Internet (el conjunto de protocolos TCP/IP). Hay otras familias que también utilizan el prefijo PF-. PF-UNIX identifica a la familia de protocolos internos de UNIX y PF_NS identifica a la familia de protocolos XNS. Las familias de direcciones están muy relacionadas con las familias de protocolos, como sabemos el formato de direcciones de red varía de una red a otra. Los diseñadores de la interfaz de sockets reconocieron este hecho y utilizaron el concepto de familias de direcciones para generalizar el uso de esa interfaz en múltiples redes. Las familias de direcciones ocupan el prefijo AF_similar al de las familias de protocolos. Por ejemplo, la constante simbólica para la familia de direcciones de Internet TCP/IP es AF_INET. De modo similar, AF_NS identifica a la familia de direcciones XNS y AF_UNIX identifica al sistema de archivos de UNIX. La interfaz de sockets de una red TCP/IP define que PF_INET y AF_INET tienen el mismo valor. Como resultado, muchas otras referencias de programación indican que utilice cualquiera de esas constantes, pues las dos representan al mismo valor. No obstante, la distinción entre familias de protocolos y direcciones permite a los programadores utilizar protocolos de red que tengan múltiples representaciones de direcciones dentro de la misma familia de protocolos. La interfaz de sockets no limita a una familia de protocolos a que utilice un sólo formato de dirección. Tal flexibilidad no es de gran valor para los programadores de Internet, pues los protocolos TCP/IP emplean un sólo formato de dirección, pero el hecho de que exista demuestra el cuidado y la planeación que se tuvo en el diseño de la interfaz de sockets.

20 Datagrama : Agrupamiento lógico de información enviado como unidad de capa de red a través de un soporte de transmisión sin el establecimiento

previo de un circuito virtual.

85

Hoy día, el uso indistinto es la diferencia entre familias de protocolos y direcciones. El programador de Internet debe de usar PF_INET cuando sea necesario identificar una familia y AF_INET cuando necesite especificar una familia de direcciones. Así el código será más claro y más fácil de migrar cuando sea necesario. Especificación de Tipo de Comunicación TCP/IP permite a sus programas utilizar comunicaciones de red orientadas a conexión y sin conexión. En la comunicación de red orientada a conexión los datos viajan como una cadena de bytes (flujo de bytes) sencilla y serial sin registro y sin otro tipo de limitaciones. En la comunicación de red sin conexión los paquetes viajan en paquetes separados e individuales, llamados datagramas. El segundo parámetro requerido por la función socket especifica qué tipo de comunicación desea utilizar. La interfaz de sockets emplea la constante simbólica SOCK_DGRAM para datagramas y SOCK_STREAM para flujo de bytes. Dicha interfaz también define un tercer tipo de comunicación llamada socket básico “raw socket” SOCK_RAW. Este tipo de socket permite a un programa utilizar los mismos protocolos de nivel inferior que la red utiliza comúnmente. En general un programa de aplicación no utiliza ICMP, sino que deja a la red manejar todos los errores. Los protocolos de transporte de TCP/IP entregan cualquier mensaje de error enviado por el programa. Sin embargo, los programas pueden evitar la capa de transporte y comunicarse directamente con los módulos de software IP e ICMP. Para evitar la capa de transporte y utilizar los protocolos de nivel inferior, como IP e ICMP, el programa debe utilizar un socket básico. Selección de un Protocolo El conjunto de protocolos TCP/IP incluye algunos protocolos, como IP, ICMP, TCP y UDP. Asimismo otras familias de protocolos proporcionan múltiples protocolos que los programadores pueden utilizar. El tercer parámetro de la función socket permite especificar cuál protocolo se usará en el socket. Al igual que en los demás parámetros de la función socket, puede utilizar constantes simbólicas para especificar el protocolo. Para redes TCP/IP, las constantes simbólicas para los protocolos empiezan con el prefijo IPPROTO_. Por ejemplo, para especificar el protocolo TCP debe usar IPROTO_TCP como tercer parámetro del socket. La constante simbólica IPPROTO_UDP especifica el protocolo UDP. La siguiente instrucción muestra una llamada común a una función socket:

socket_handle = socket (PF_INET; SOCK_STREAM, IPPROTO_TCP);

Esta instrucción indica a la implementación del socket que el programa utiliza la familia de protocolos Internet (PF_INET). También le dice que utilizará el protocolo TCP(IPROTO_TCP) para comunicación por flujo de bytes (SOCK_STREAM) por el socket solicitado.

El Proceso Tenemos claro que un socket representa un extremo en la comunicación por red, al igual que un socket identifica a un registro en la tabla de descripción de forma similar a como un identificador

86

de archivo reconoce un registro en la tabla de archivos descriptores y comprendemos que sus programas llaman a la función socket para crear un socket. Se puede crear un socket sin especificar una dirección de red. Por ejemplo, la siguiente llamada a función socket especifica una familia de protocolos, un tipo de socket y un protocolo específico- no especifica una dirección de red: socket _ handle = socket ( protocol_family, socket_type, protocol); Un socket puede ser un extremo de la comunicación en red aunque no incluya una dirección. Descriptor de Socket Cuando llamamos a la función socket, la implementación del socket lo crea y devuelve un identificador de socket (o descriptor) que, en realidad, identifica a un registro en la tabla de descripción. La implementación del socket maneja esta tabla por sí mismo. Como programador de aplicaciones, el único acceso a la tabla de descripción es a través del descriptor de sockets. De hecho, “crear un socket” significa reservar espacio de almacenamiento para la estructura del socket. La figura A1 muestra la estructura de datos de un socket simplificada.

Fig. A1: Estructura simple de datos del socket Como podemos ver en la figura A1, la estructura de datos del socket incluye elementos para almacenar valores de los parámetros de la función socket. Sin embargo, también contiene elementos para cuatro direcciones: IP local, IP remota; puerto local y puerto remoto. Cada vez que el programa llama a la función socket, la implementación del socket reserva memoria para una nueva estructura de datos y almacena la dirección de la familia, el tipo de socket y el protocolo. En la tabla de descripción de archivos la implementación del socket guarda un

87

apuntador para la estructura de datos. El identificador que recibe el programa de la función socket es un índice dentro de la tabla de descripción. La interfaz de sockets no específica cómo manejar las descripciones de los sockets. UNIX los maneja como archivos descriptores de la tabla de archivos descriptores, pero otras implementaciones son libres para manejar los descriptores de socket de forma diferente. En otras palabras, más allá de los descriptores de sockets, los detalles dependen de la implementación. Como programador de aplicaciones no es necesario preocuparse por detalles como tablas descriptoras, estructuras de datos internas y lo relacionado con la asignación de memoria. El propósito de explicar estos detalles es mostrar cómo un socket almacena las direcciones de red. La función socket crea la estructura de datos del socket pero deja vacíos los elementos para las direcciones. Para asociar un socket con direcciones de red específicas es necesario llamar a otras funciones dentro de la API de sockets Cómo usar el paradigma de sockets El paradigma (o modelo) de la interfaz de sockets para las comunicaciones de red se refiere a la comunicación entre computadoras anfitrión o procesos como extremos. Cada conversación en la red incluye dos extremos: el anfitrión local y el remoto (o destino). La interfaz de sockets denomina a cada extremo de la conversación en la red socket. También sabe que la mayoría de los programas utilizan el modelo cliente/servidor. Las comunicaciones de red en el modelo cliente/servidor también incluyen dos extremos. No obstante, el modelo cliente/servidor hace una distinción entre los extremos de la función que llevan a cabo. Por ejemplo, el modelo cliente/servidor llama al extremo que inicia o solicita un servicio de la red, proceso o programa cliente. Al extremo que responde a la solicitud del cliente lo denomina proceso o programa servidor. La capa IP utiliza una dirección Internet para identificar las computadoras anfitrión, por lo tanto cada anfitrión en Internet requiere de una dirección única en esa red. La capa de transporte utiliza puertos de protocolos para identificar aplicaciones específicas (procesos) en cada anfitrión. Así, cada proceso relacionado con la red en una computadora anfitrión emplea un puerto de protocolo (que es como un identificador de tareas) como dirección. Los programas de Internet deben utilizar el protocolo TCP/IP para transferir datos a esa red. En suma, una conexión de red entre dos programas incluye cinco elementos de información: • Un puerto de protocolo local que específica donde recibe mensajes o datagramas un programa

o proceso. • La dirección del anfitrión local, lo cual identifica al anfitrión que recibirá los paquetes de

datos. • Un puerto de protocolo remoto que identifica al programa o proceso destino. • La dirección del anfitrión remoto, que identifica al anfitrión destino. • Un protocolo, que define cómo los programas transfieren datos a través de la red. La estructura de datos del socket incluye todos los elementos de información que requiere un extremo para la comunicación en red. Cuando un programa quiere comunicarse con otro, el programa emisor transmite la información al socket y la API de sockets maneja la interfaz con la pila de protocolos TCP/IP. Sin embargo, antes de que el programa pueda enviar cualquier

88

información al socket, debe llamar a la función socket para crearlo y entonces utilizar otras funciones de la interfaz de sockets para configurarlo. Definición del uso de socket en el programa El programa debe configurar un socket antes de utilizarlo para comunicarse en la red. Pero lo más importante es que la estructura de datos interna del socket tenga las direcciones correctas. La estructura de datos interna del socket debe de contener el puerto de protocolo correcto y las direcciones IP para ambos: el programa del anfitrión local y del remoto. Por lo tanto, el término de las direcciones del socket se refiere no a la dirección del socket en sí, sino a las direcciones del puerto de protocolo y del anfitrión almacenadas en la estructura de datos interna. Cuando se crea un socket con la función socket, no se especifica la dirección del puerto de protocolo ni la del anfitrión, sino que utiliza diferentes funciones de la API para almacenar las direcciones del socket y otras opciones de configuración, dependiendo de cómo el programa intenta utilizar el socket. Por ejemplo, si el programa utiliza el socket como puerto servidor, llamará a la función que especifica el uso de protocolo local. A la inversa, si el programa actúa como cliente en la red, probablemente deje que la implementación del socket asigne cualquier puerto disponible para usarlo cuando de veras requiera utilizar el socket. En otras palabras, la función socket reserva espacio de almacenamiento para la estructura de datos del socket y devuelve un identificador que puede utilizar el programa para configurar el socket. Los parámetros que se especifican cuando se crea un socket dependen del propósito del programa, así como del tipo de servicio de entrega (datagrama o flujo de bytes) que éste utilizará: el tipo de servicio de entrega determina el protocolo (TCP o UDP) que especificará el programa. Las funciones de la API que usará el programa para almacenar las direcciones del anfitrión y del puerto del protocolo dependen de cómo el propio programa utilizará el socket: como servidor o como cliente. Configuración del Socket Por cada programa de red que se escriba, primero se debe crear un socket llamando a la función socket. Después debe utilizar otras funciones para configurarlo de acuerdo al uso que se le dará al programa. Por ejemplo, para transferir datos por el socket se puede utilizar flujo de bytes o datagramas. Asimismo, podemos utilizar un socket para hacer funciones de programa cliente servidor. La tabla nombra las funciones API de sockets que se emplean a fin de configurar un socket para comunicaciones en red. Una conexión de red requiere cinco elementos de información: un protocolo, una dirección IP local; una dirección IP remota; un puerto de protocolo para procesamiento local y un puerto de protocolo para procesamiento remoto.

Uso del socket información local Información remota

Cliente orientado a conexión Una llamada a la función conectada almacena la información Local y remota en la estructura de datos del socket.

Servidor orientado a conexión bind listen y accept Cliente sin conexión bind sendto Servidor sin conexión bind recvfrom Funciones de la API de sockets utilizadas para configurar un socket para comunicación en red. Tabla a

89

Conexión de un Socket Los sockets proporcionan una abstracción que se puede utilizar para representar y programar los extremos de una conversación en red. Un protocolo orientado a conexión establece un circuito virtual entre los extremos de la conexión, es decir, el enlace entre los dos extremos parece directo, punto a punto. En la capa de transporte de TCP/IP, el protocolo TCP (un protocolo orientado a conexión) establece un circuito virtual (mantiene la conexión abierta) intercambiando mensajes de confirmación entre los dos extremos. Como resultado, un programa cliente orientado a conexión en una red TCP/IP no se ocupa de la dirección local que utiliza el software de red para la transferencia de datos. En otras palabras, el programa cliente puede recibir datos en cualquier puerto de protocolo. Por lo tanto, en la mayoría de los casos un programa cliente orientado a conexión no especifica puerto de protocolo local. Un programa cliente orientado a conexión utiliza la función connect para configurar un socket de comunicación en red: La función connect almacena información en la estructura de datos del socket acerca de los extremos local y remoto. La función connect requiere que se especifique un identificador de socket acerca de los extremos local y remoto, una estructura de dirección que contenga información sobre el anfitrión remoto y la longitud de la estructura de dirección del socket. La siguiente instrucción muestra una llamada común a la función connect: result = connect (socket_handle, remote_socket_address, address_lenght;

Observe que el primer parámetro de la función connect, el identificador del Socket(socket_handle), es el valor del descriptor del socket que devolvió la función socket. Antes de que el programa pueda utilizar la función connect para conectar un socket se debe de llamar a la función socket. El identificador del socket indica la implementación del socket y en qué registro de la tabla de descripción se debe de usar. En otras palabras, el identificador del socket indica a la implementación de este donde almacenar la dirección del socket remoto. El segundo parámetro de la función socket, la dirección del socket remoto(remote_socket_address) es un apuntador especial a una estructura de la dirección del socket, esta almacena información peculiar de la dirección para una red específica: Como resultado, el contenido de la estructura depende de la red, el contenido de la estructura depende de la familia de protocolos que utiliza el programa. Es importante observar que para un socket, la estructura almacena una familia de direcciones, un puerto de protocolo y una dirección del anfitrión en la red. La función connect almacena esta información en un registro de la tabla de descripción del socket (el primer parámetro de la función connect) que reconoce el identificador del socket. Antes de que el programa llame a la función connect se debe de almacenar la información de la dirección del anfitrión remoto en la estructura de datos del socket, es decir, la función connect requiere la dirección IP del anfitrión y el puerto de protocolo. Sin embargo es necesario que se almacenen las direcciones IP locales. La implementación del socket lo hace de modo automático y selecciona un puerto de protocolo local. La API de sockets aseguran que la aplicación reciba los datos que entrega la capa de transporte al puerto de protocolo local. Dicho de otro modo, la

90

implementación del socket selecciona el puerto de protocolo por el programa y le notifica a éste la llegada de datos al puerto, el programa no necesita saber qué puerto utiliza la implementación. El tercer parámetro de la función connect. La longitud de la dirección (address_lenght), simplemente indica a la implementación del socket el tamaño, en bytes, de la estructura de datos de la dirección del socket remoto (el segundo parámetro). El contenido y tamaño de la estructura de la dirección del anfitrión remoto dependen de la red. El parámetro longitud de la dirección indica a la función connect cuán grande debe ser la estructura de datos que requiere el anfitrión remoto. Cuando la implementación del socket responde a la función connect, obtiene el número de bytes especificado por el parámetro longitud de división del buffer de datos apuntado por el parámetro remote_socket_adress (dirección del socket remoto). Especificación de una dirección local (puerto de protocolo) La función connect indica una conexión directa con el anfitrión remoto. El único momento en el que conectamos un socket al anfitrión remoto es cuando el programa utiliza el socket como un proceso cliente orientado a conexión. Un protocolo sin conexión nunca establece una conexión directa. Un protocolo sin conexión transmite datagramas por la red, tales protocolos nunca usan flujo de bytes. Asimismo un programa servidor nunca inicia una conexión. Aunque se pueden crear programas servidores que utilicen protocolos orientados a conexión, el programa esperará pasivamente en un puerto de protocolo la solicitud de un cliente, el cliente inicia la conexión, no el servidor. La similitud principal que hay que notar entre un programa que utiliza un protocolo sin conexión y un programa servidor que emplea un protocolo orientado a conexión es que ambos tienen que atender a un puerto de protocolo. Asimismo, puesto que un programa cliente sin conexión no establece una conexión directa con el anfitrión remoto, debe atender también por un puerto de protocolo para recibir un datagrama en repuesta a su solicitud de servicios de red. La función de asignación de nombres (bind) en la API de sockets permite a un programa asociar una dirección local (combinación de la dirección del anfitrión y puerto de protocolo) con un socket. La siguiente instrucción muestra una llamada común a la función bind: result = bind(socket_handle, local_socket_address, address_lenght); Cuando se crea un programa servidor se diseña para que atienda solicitudes de un cliente, la capa de transporte de TCP/IP se comunica con los programas de aplicación (digamos, servidores y clientes) a través de un puerto de protocolo. Para recibir la solicitud de un cliente al programa servidor debe de atender a la capa de transporte para que se le entregue en un puerto de protocolo específico. Cuando se emplea la interfaz de sockets para un programa servidor, el programa utiliza la función bind para registrar un puerto de protocolo con la implementación del socket, esto es, el programa indica a la implementación del socket qué puerto de protocolo debe usar para la entrega de datos. La implementación a su vez, indica a la capa de transporte que el puerto de protocolo especificado está en uso y que entregue todos los datos recibidos por él a los sockets de la API. Un cliente sin conexión debe atender a un puerto de protocolo, los programas que utilizan protocolos sin conexión no establecen conexión directa con el anfitrión remoto. Un programa

91

cliente sin conexión transmite una solicitud de servicio de red utilizando un datagrama, el cual no establece una conexión punto a punto. Así el cliente sin conexión debe atender por el puerto de protocolo para esperar el datagrama de respuesta. Al igual que los programas servidores, los programas cliente sin conexión utilizan la función bind para registrar el puerto de protocolo con la implementación del socket. Como un programa servidor, al cliente sin conexión indica a la implementación del socket qué puerto de protocolo debe usar para la entrega de datos. La implementación del socket maneja la interfaz entre el cliente y el módulo de software UDP en la capa de transporte. En secciones posteriores analizamos funciones de la API de sockets (como atender (listen), aceptar(accept), recibir desde(recvfrom) y recibir (recv)) que los programas pueden emplear para obtener datos del puerto de protocolo. Para configurar un socket para atender a un puerto de protocolo específico, el programa utiliza una función bind. Transmisión de Datos por el Socket Después de que el programa configura un socket puede utilizarlo para la comunicación en la red. El proceso de comunicación incluye enviar y recibir información. La interfaz de sockets incluye además funciones para hacer ambas tareas. La API de sockets proporciona cinco funciones para transmitir datos a través de un socket y las divide en dos grupos. Tres funciones requieren una dirección destino como parámetro; las otras dos, no. La diferencia principal entre los dos grupos es si la transmisión es sin conexión u orientada a conexión. Descripción de las cinco funciones de la API de sockets que los programas pueden utilizar para transmitir datos.

Función de la API de sockets Descripción

send transmite datos a través de un socket de conexión; puede utilizar banderas para controlar el comportamiento del socket.

write Transmite datos a través de un socket de conexión,

utilizando un búfer de datos simple. writev Transmite datos a través de un socket de conexión,

utilizando bloques de memoria no contiguos como búfer de datos.

sendto Transmite datos a través de un socket sin conexión,

utilizando un búfer de mensajes simple. Sendmsg Transmite datos a través de un socket sin conexión,

utilizando una estructura de mensajes flexible como búfer de mensajes.

92

Funciones de la API de sockets que pueden utilizar los programas para transmitir

Envío de datos por un socket de conexión Las comunicaciones orientadas a conexión utilizan circuitos virtuales- el enlace entre los extremos parece punto a punto, es decir, después de que el software de red establece la conexión, el programa puede intercambiar datos con el anfitrión remoto en flujo de bytes constantes. Las funciones de la API de sockets que hacen transmisiones de datos orientadas a conexión no requieren que el programa especifique una dirección destino como parámetro. El programa utiliza la función connect para configurar sockets orientados a conexión que incluyen datos de la dirección del anfitrión destino (puerto de protocolo y dirección IP). Durante toda la conversación en red, la implementación del socket mantiene los datos de la dirección y maneja la interfaz con la capa de transporte para el socket orientado a conexión. Las funciones send, write y writev sólo trabajan con sockets conectados, no permiten que el programa especifique una dirección destino. Estas tres funciones necesitan que el programa especifique un identificador de socket como primer parámetro en la llamada función. La siguiente instrucción muestra una llamada común de la función write:

result = write (socket_handle, message_buffer, buffer_lenght)

El primer parámetro de la función write es el familiar identificador de socket (socket_handle) que requieren muchas de las funciones de la API de sockets: El identificador de socket identifica un registro en la tabla de descripción que apunta a una estructura de datos interna del socket. El segundo parámetro es el buffer de mensajes (message_buffer), que apunta al buffer de datos que contiene la información que transmitirá el programa y que debe reservar memoria para ese buffer y llenarlo con los datos. El tercer parámetro de la función write, tamaño del buffer (buffer_lenght), simplemente especifica el tamaño del buffer de datos que el programa va a transmitir. La llamada a la función write v es muy similar a la de la función write. Sin embargo la función write no requiere que sus datos ocupen datos contiguos de memoria; la función write sí. En otras palabras, writev permite que el programa especifique una tabla de direcciones que contenga sus datos. La siguiente instrucción ilustra una llamada a la función writev:

result = write (socket_handle, io_vector, vector_lenght);

Al igual que write, la función writev también requiere un identificador de socket como primer parámetro (socket_handle); el segundo específica la dirección de una tabla que contiene una secuencia de apuntadores (io-vector). Supongamos que los datos que se desean transmitir están almacenados en diferentes localidades de memoria. Se debe asignar la dirección de cada buffer de datos a la tabla de apuntadores. Cuando la función writev transmita los datos, enviará la información contenida en cada localidad de memoria especificada por la tabla de apuntadores. La función writev transmite los datos en el mismo orden en que aparecen las direcciones de memoria en la tabla de apuntadores. El tercer parámetro de la función writev (vector_lenght) especifica el número de elementos de la tabla de apuntadores.

93

El segundo parámetro de la función writev especifica la dirección de una tabla que contiene una secuencia de apuntadores. Estos apuntadores indican los bloques de datos que forman el mensaje que transmitirá el programa. Con cada apuntador de la tabla, el socket asocia una longitud que especifica cuántos bytes existen en la dirección indicada. La siguiente figura A2 muestra un ejemplo de una tabla de apuntadores de datos.

0 32 bits 31 Posiciones del bit

Apuntador al bloque de datos 1 (dirección de memoria de 32 bits) Tamaño del bloque de datos 1 (entero de 32 bits)Apuntador al bloque de datos 2(dirección de memoria de 32 bits) Tamaño del bloque de datos 2 (entero de 32 bits)

Fig. A2: Formato de tabla a la que apunta la función writev.

Puesto que la función write fuerza al programa a utilizar buffers de datos contiguos, tiene un desempeño más rápido que la función writev, esta permite que usted especifique una secuencia de apuntadores de direcciones, ofrece mayor flexibilidad para mensajes complejos y para circunstancias bajo las cuales sea difícil obtener bloques de memoria contiguos. La función send es la única otra función de la interfaz de sockets que el programa se puede utilizar con sockets de conexión. La siguiente instrucción muestra una llamada común a la función send:

result = send (socket_ handle, message_buffer, buffer_lenght, special_flags);

La mayor ventaja de la función send es que usted puede especificar banderas opcionales que controlen la transmisión. Por ejemplo, TCP/IP da a los datos fuera de banda o datos urgentes una prioridad mayor que los demás. Una de las banderas opcionales que puede utilizar con la función send indica el proceso receptor que su mensaje contiene datos fuera de banda. Las tres funciones (write, writev y send) devuelven un valor entero. Si no ocurren errores, las funciones devuelven un valor igual al número de bytes transmitidos por el socket. Si hay un error, devuelven un valor de –1. La API Windows Socket (winsock) usa un mecanismo diferente para extraer y notificar errores. Envío de datos a través de un socket sin conexión Los programas pueden utilizar las tres funciones que vimos en las secciones anteriores para transmitir datos a través de un socket de conexión pero, esas funciones no permiten especificar la dirección destino. Para enviar datos a través de un socket sin conexión (un socket configurado para utilizar un protocolo sin conexión), los programas deben de utilizar una de las dos funciones (sendto y sednmesg) que proporciona la interfaz de sockets para ese propósito. La función sendto requiere seis parámetros. Los primeros cuatro son idénticos a la función send. El quinto identifica

94

la función destino (socket_address_structure). El sexto especifica al tamaño (o longitud) de la dirección destino en bytes (address_structure_lenght). La siguiente instrucción muestra una llamada común a la función sendto: result = sendto(socket_handle, message_buffer, buffer_lenght, special_flags, socket_address_structure, address_structure_lenght); La función sendmsg permite al programa utilizar, para transmisión, una estructura de mensaje en lugar de un simple buffer de datos. Según se muestra es la siguiente instrucción, la función sendmsg requiere como parámetros un identificador de socket (socket_handle), un apuntador a la estructura del mensaje (message_structure) y banderas (special_flags). result = sendmsg (socket_handle, message_structure, special_flags);

La estructura del mensaje permite a los programas almacenar convenientemente listas extensas de parámetros de mensajes en una simple estructura de datos. La función sendmsg requiere como parámetros un identificador de socket (socket_handle), un apuntador a la estructura del mensaje (message_structure) y banderas (special_flags).

result = sendmsg(socket_handle, message_structure, special_flags);

La estructura del mensaje permite a sus programas almacenar convenientemente, listas extensas de parámetros de mensajes en una simple estructura de datos. La función sendmsg se parece a la función writev en que los programas pueden formatear los datos en múltiples bloques de memoria. La estructura del mensaje contiene un apuntador a una tabla de direcciones de memoria. En la figura A3 se muestra un ejemplo del formato de la estructura del mensaje que emplea la función sendmsg.

0 32 bits 31 Posiciones del bit

Apuntador a la estructura de dirección del socketTamaño de la estructura de dirección del socket

Apuntador a la lista de vectores de E/S Extensión de la lista de vectores de E/S

Apuntador a la lista de derechos de acceso Extensión de la lista de derechos de acceso

Fig. A3: Formato de la estructura de mensaje que utiliza la función sendmsg. La interfaz de sockets incluye una función (recvmsg) que recibe datos en el mismo tipo de estructura del mensaje que utiliza la función sendmsg: También analizaremos otras funciones que sus programas pueden utilizar para recibir datos por un socket. Recepción de datos por un socket La interfaz de sockets incluye cinco funciones (read, readv, recv, recvfrom y recvmsg) que corresponden a las cinco funciones que usamos para transmitir datos. Por ejemplo, las funciones

95

recv y send emplean parámetros similares. Ocupamos la función recv para recibir datos y la función send para transmitirlos. De igual manera las funciones writev y readv, son similares. Utilizamos writev para transmitir datos y readv para recibirlos, ambas: writev y readv, permiten especificar una tabla de direcciones de memoria para los datos. Las funciones recvfrom y recvmsg corresponden a las funciones sendto y sendmsg, respectivamente. La siguiente tabla relaciona las funciones que se corresponden.

Funciones de transmisión Funciones correspondientes de recepción

send recv

write read

writev readv

sendto recvffrom

sendmsg recvmsg

Funciones correspondientes de recepción y transmisión de la API de sockets.

Aunque la interfaz de sockets incluye funciones de transmisión y recepción que se corresponden, no es necesario el uso de ambas. Si un anfitrión remoto utiliza la función send para enviar datos, para recibirlos no tiene que ocupar la función recv (la función correspondiente). Una vez que una función transmite a un socket, los datos, esencialmente, vienen en flujo de bytes. Por lo tanto, se pueden recibir con cualquiera de las funciones recv, resd o resdv.

La interfaz de sockets le permite utilizar la función que más se adapte a las necesidades. Para eliminar cualquier requerimiento de extremos de bloques contiguos de memoria, puede diseñar todos sus programas para que usen llamadas a la función readv. Algunos programadores pueden encontrar que el código de sus programas puede leerse mejor si se utiliza funciones como (write/read, send/recv y sendmsg/recvmsg).

96

Panorama del Proceso En la figura A4 que tenemos a continuación, se muestran las llamadas comunes del sistema de sockets que utilizan los programas con protocolos orientados a conexión. La parte de la izquierda muestra las llamadas a funciones del servidor; la de la derecha las llamadas a funciones del cliente. Las líneas y flechas entre los módulos servidor y cliente, muestran el flujo de la comunicación de la red entre dos programas. Como se puede ver el programa servidor crea un socket con la función socket. Siendo más precisos, el programa servidor solicita a la implementación del socket que le asigne una estructura de datos para el socket y que le devuelva un descriptor de sockets que pueda utilizar en las subsecuentes llamadas a funciones. Después, el servidor une el socket a un puerto de protocolo local como se muestra en la figura A4.

Servidor Cliente

Fig. A4: Uso de los sockets con un protocolo orientado a conexión.

97

La función listen indica al socket que “atienda” las conexiones entrantes y que confirme las solicitudes de conexión, es decir, la función listen pone al socket en modo de atención pasiva. Un socket envía a cada solicitante un mensaje de confirmación que indica que el anfitrión recibió su solicitud de conexión. No obstante un socket que atiende no acepta, en realidad, la solicitud de conexión. Para hacerlo y establecer la conexión con un solicitante de ingreso, el programa debe llamar a la función accept. Como podemos ver arriba en la figura, el programa cliente también crea un socket con la función socket. Sin embargo, el programa cliente que utiliza un protocolo orientado a conexión como TCP no se ocupa de cuál dirección local usa el protocolo. Por lo tanto, no necesita llamar a la función bind. En vez de hacer eso inicia la conversación en red llamando a la función connect. Después de que el cliente y servidor establecen la conexión, pueden ocurrir comunicaciones adicionales a través de las funciones write y read. Sin embargo, los programas cliente y servidor podrían fácilmente haber usado las funciones send y resv o cualquier otra función de la interfaz de sockets que trabajen con sockets de conexión. La figura A5 nos muestra las llamadas comunes del sistema de sockets que emplea un protocolo sin conexión.

Servidor Cliente

Fig. A5: Uso de los sockets con un protocolo sin conexión.

Más que el servidor orientado a conexión, el servidor sin conexión ver figura A5, usa las llamadas a las funciones socket y bind para crear y unir un socket. Pero, como el socket es sin conexión, el programa cliente utiliza la función recvfrom, en lugar de las funciones recv o read, para obtener los datos del socket. Es importante observar que el programa cliente llama a la función bind pero no a la connect, un protocolo sin conexión no establece una conexión punto a

98

punto entre ambos lados, en su lugar la función sendto requiere que el programa especifique la dirección destino como parámetro. La función recvfrom tampoco espera por la conexión sino que responde a cualquier dato que llegue al puerto de protocolo que tiene enlazado. Cuando la función recvfrom recibe un datagrama desde un socket, almacena la dirección de red del proceso que lo transmitió, así como el mismo datagrama. Los programas (servidor y cliente) utilizan las direcciones almacenadas para identificar la dirección del proceso (cliente) emisor. Entonces, el servidor envía el datagrama de respuesta (como se solicitó) a la dirección que obtuvo la función recvfrom. A continuación se muestra un ejemplo del uso de sockets para Windows // SockMan.CPP // Administrador de programas Winsock // Un modelo de programación e intérprete de comandos para programadores de sockets para Windows #include "..\winsock.h" // Header de Winsock #include "sockman1.h" // Prototipos y constantes // Variables globales de Sockman HWND hwndSockman; // Manejador de la ventana de Sockman HANDLE hInstanceSockman; // Manejador de la instancia de Sockman char szAppName[9]; // Nombre de la aplicación char szPrintBuffer[MAX_PRINT_BUFFER+1]; // Arreglo para el archivo int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) { MSG msg ; WNDCLASS wndclass ; hInstanceSockman = hInstance; lstrcpy(szAppName, "SockMan"); szPrintBuffer[0] = '\0'; if (!hPrevInstance) { wndclass.style = CS_HREDRAW | CS_VREDRAW; wndclass.lpfnWndProc = WndProc; wndclass.cbClsExtra = 0; wndclass.cbWndExtra = 0; wndclass.hInstance = hInstance; wndclass.hIcon = LoadIcon(hInstance, szAppName); wndclass.hCursor = LoadCursor(NULL, IDC_ARROW); wndclass.hbrBackground = GetStockObject(WHITE_BRUSH); wndclass.lpszMenuName = szAppName; wndclass.lpszClassName = szAppName; if (!RegisterClass(&wndclass)) return FALSE; } hwndSockman = CreateWindow ( szAppName, "Demostración SockMan ver. 1", WS_OVERLAPPEDWINDOW | WS_VSCROLL | WS_HSCROLL, CW_USEDEFAULT, CW_USEDEFAULT,

99

CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL ); if (!hwndSockman) return FALSE; ShowWindow(hwndSockman, nCmdShow); UpdateWindow(hwndSockman); if( StartWinsock()) { while(GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } } WSACleanup(); return(msg.wParam); } long FAR PASCAL _export WndProc(HWND hwnd, UINT iMessage, UINT wParam, LONG lParam) { switch (iMessage) { case WM_PAINT: PAINTSTRUCT ps; HDC hdc ; RECT rect ; hdc = BeginPaint( hwnd, &ps); GetClientRect(hwndSockman, &rect); DrawText(hdc, szPrintBuffer, -1, &rect, DT_EXPANDTABS|DT_WORDBREAK); EndPaint(hwnd, &ps); return(0); case WM_COMMAND: if (DoMenuCommand(hwnd, iMessage, wParam, lParam)) return(0); else break; case WM_DESTROY : PostQuitMessage(0); return(0) ; } return(DefWindowProc(hwnd, iMessage, wParam, lParam)); } long DoMenuCommand(HWND hwnd, UINT iMessage, UINT wParam, LONG lParam) { switch (wParam) { case IDM_FILE_CLEAR: szPrintBuffer[0]='\0'; InvalidateRect(hwndSockman, NULL, TRUE); UpdateWindow(hwndSockman); return(TRUE); case IDM_FILE_PRINT: case IDM_FILE_SAVEAS: PaintWindow((LPSTR) "Funciones de archivo no implementadas!"); MessageBeep(0); MessageBox(hwnd, "Funciones de archivo no implementadas!",

100

szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_FILE_EXIT: SendMessage(hwnd, WM_CLOSE, 0, 0L); return(TRUE); case IDM_HELP_HELP: MessageBeep(0); MessageBox(hwnd, "Ayuda no implementada!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_HELP_ABOUT: MessageBox(hwnd, "Un intérprete de comandos de programación para programadores de sockets para Windows.", "SockMan - Administrador de programas de Winsock ver. 1", MB_ICONINFORMATION | MB_OK); return(TRUE); default: return(DoWinsockProgram(hwnd, wParam, lParam)); } } long DoWinsockProgram(HWND hwnd, UINT wParam, LONG lParam) { switch (wParam) { case IDM_APP_MAIL: case IDM_APP_FTP: MessageBeep(0); MessageBox(hwnd, "No hay aplicaciones implementadas!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_LOOKUP_ASYNC: case IDM_LOOKUP_BLOCKING: MessageBeep(0); MessageBox(hwnd, "La herramienta buscar no está implementada!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_FINGER_ASYNC: case IDM_FINGER_BLOCKING: MessageBeep(0); MessageBox(hwnd, "La herramienta finger no está implementada!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_TIME_UTIL: MessageBeep(0); MessageBox(hwnd, "La herramienta servidor de hora no está implementada!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); case IDM_PING_UTIL: MessageBeep(0); MessageBox(hwnd, "La herramienta ping no está implementada!", szAppName, MB_ICONEXCLAMATION | MB_OK); return(TRUE); } return(FALSE); }

101

ANEXO B. EJEMPLO DE APLICACIÓN CON TI

Muestra de un fragmento del una aplicación que interactua entre la PC, el lector de TI y la TI Cryptoflex. #include <string.h> #include <stdio.h> #include <ctype.h> #include <stdlib.h> #include <io.h> #include <fcntl.h> #include "core_api.h" #include "core_par.h" #include "core_err.h" #include "access.h" #include "TextOutDLL.h" #define TRUE (0==0) #define FALSE !TRUE void main(ArgC, ArgV) int ArgC; char *ArgV[]; { CL_BYTE RC = CL_OK; CL_BYTE Com = 1; char Choice; RC = CL_Open( (CL_PSTC_CONTEXT) &Com ); if (RC != CL_OK) { CL_Close( (CL_PSTC_CONTEXT) &Com ); TextOut( "\nIntroducir el puerto COM: "); Choice = GetChar(); Com = Choice - '30'; RC = CL_Open( (CL_PSTC_CONTEXT) &Com ); } if (RC == CL_OK) { // // ejecutando el ciclo del menu principal // SOSL_MainMenue( (CL_PSTC_CONTEXT) &Com ); } else { TextOut( "\nERROR: no se puede acceder al lector\n\n" ); } CL_Close( (CL_PSTC_CONTEXT)&Com );

102

exit( 0 ); } // // MENU PRINCIPAL --------------------------------------------------------------- // void SOSL_MainMenue( CL_PSTC_CONTEXT Com ) { char Choice; CL_BYTE ResetType; CL_BOOL FileOpen = FALSE; int hFile = -1; // manejo de archivo do { TextOut( "\n\n=========== MENU PRINCIPAL =============\n" ); TextOut( "\n0 - reseteo de TI" ); TextOut( "\n1 - obtener parametro" ); TextOut( "\n2 - fijar parametro" ); TextOut( "\n3 - abrir archivo" ); TextOut( "\n4 - correr archivo paso a paso" ); TextOut( "\n5 - enviar comando" ); TextOut( "\nx - salir " ); TextOut( "\n\nSeleccionar" ); Choice = GetChar(); switch( Choice ) { case '0': TextOut( "\n\nSeleccionar el tipo de reseteo" ); TextOut( "\n0 - reseteo frio" ); TextOut( "\n1 - reseteo tibio " ); TextOut( "\n2 - quitar energia a la TI" ); TextOut( "\n\nSeleccionar " ); Choice = GetChar(); switch( Choice ) { case '0':

// reseteo frio ResetType = CL_RESET;

break; case '1': // tibio reseteo ResetType = CL_WARMRESET; break; case '2': // quitar energia a la TI ResetType = CL_DEACTIVATE; break; } SOSL_ResetICC( (CL_PSTC_CONTEXT) Com, ResetType ); break; case '1': SOSL_GetParameter( (CL_PSTC_CONTEXT) Com ); break; case '2': SOSL_SetParameter( (CL_PSTC_CONTEXT) Com ); break; case '3': FileOpen = SOSL_OpenFile( &hFile ); break; case '4':

103

if (FileOpen) SOSL_NextCommand( (CL_PSTC_CONTEXT) Com, &hFile ); else TextOut( "\nAbrir archivo de ecenario" ); FileOpen = FALSE; break; case '5': SOSL_SendCommand( (CL_PSTC_CONTEXT) Com ); break; case 'x': case 'q': case 0x1B: // ESC Choice = 0; break; default: TextOut( "\n(opcion invalida)" ); break; } if( Choice ) { TextOut( "\n\n(presione cualquier tecla para continuar)" ); GetChar(); } } while( Choice ); return; } // // reset card // CL_RCODE SOSL_ResetICC( CL_PSTC_CONTEXT Com, CL_BYTE ResetType ) { CL_BYTE pResponse[40]; CL_DATALEN Resp_size; CL_RCODE RC = CL_ERR_COMM; RC = CL_ReaderExchange ( (CL_PSTC_CONTEXT) Com, ResetType, (CL_STRING)NULL, (CL_DATALEN)NULL, (CL_STRING) pResponse, (CL_DATALEN *) &Resp_size ); switch (RC) { case CL_ERR_NOCARD: TextOut( "\nNo hay tarjeta" ); break; case CL_ERR_COMM: TextOut( "\nFalla de comando" ); break; case CL_OK: DataOut( pResponse, Resp_size ); break; default: TextOut( "\nERROR: no se puede resetear la tarjeta\n\n" ); break; } return( RC ); } // // obtener parametros // CL_RCODE

104

SOSL_GetParameter( CL_PSTC_CONTEXT Com ) { //CL_BYTE Input[10]; CL_PARAMID Param; CL_PARAMVAL pValue; CL_RCODE RC = CL_ERR_COMM; TextOut( "\n\nIntroducir parametros o 'FF' para todos los parametros: "); DataInX( &Param ); if( Param == 0xFF ) { for( Param = CLP_VERSION; Param <= CLP_COMSPEED; Param++ ) { RC = CL_GetParameter( (CL_PSTC_CONTEXT) Com, (CL_PARAMID) Param, (CL_PARAMVAL *) &pValue ); if( RC == CL_OK ) { TextOut( ParMsg[Param], Param, pValue ); } else { TextOut( "\nERROR: no se puede obtener parametro %x\n\n", Param ); break; } } } else { RC = CL_GetParameter( (CL_PSTC_CONTEXT) Com, (CL_PARAMID) Param, (CL_PARAMVAL *) &pValue ); if( RC == CL_OK ) { TextOut( ParMsg[Param], Param, pValue ); } else { TextOut( "\nERROR: no se puede obtener parametro\n\n" ); } } return( RC ); } // // fijar parametros //CL_RCODE SOSL_SetParameter( CL_PSTC_CONTEXT Com ) { CL_PARAMID Param; CL_PARAMVAL pValue; CL_RCODE RC = CL_ERR_COMM; TextOut( "\n\nIntroducir parametro: " ); DataInX( &Param ); TextOut( "Introducir valor: " ); DataInLX( &pValue ); pValue = 123; RC = CL_SetParameter( (CL_PSTC_CONTEXT) Com, (CL_PARAMID) Param, (CL_PARAMVAL ) pValue ); if (RC == CL_OK)

105

{ TextOut( ParMsg[Param], Param, pValue ); } else { TextOut( "\nERROR: No se puede fijar parametro\n\n" ); } return( RC ); } // // archivo de escenario abierto// CL_BOOL SOSL_OpenFile( int *hFile ) { CL_BYTE FileName[100]; CL_BOOL RC =TRUE; if( *hFile != -1 ) _close(*hFile); TextOut( "\n\nIntroducir el nombre de archivo: " ); DataInS( FileName ); *hFile = _open( FileName, _O_RDONLY ); if( *hFile == -1 ) { TextOut( "\nError: no se puede abrir el archivo de salida" ); RC = FALSE; } return( RC ); } CL_BOOL SOSL_NextCommand( CL_PSTC_CONTEXT Com, int *hFile ) { CL_BYTE Command[600]; CL_BYTE Response[600]; CL_DATALEN ResponseLen; CL_RCODE RC = CL_ERR_COMM; char *pLine; char *FileBuffer = NULL; long FileLen; char Choice; CL_BOOL SendCommand = FALSE; // Obtener la longitud del archivo // asignar el buffer if( (FileLen = _filelength( *hFile )) != -1) FileBuffer = (char *) malloc( (size_t) FileLen ); if( FileBuffer == NULL ) { TextOut( "\n\nError: Memoria insuficiente." ); } else if( _read( *hFile, (char *) FileBuffer, (unsigned int) FileLen ) <= 0 ) { TextOut( "\n\nError: no se puede leer." ); } else { // // obtener la siguiente linea // pLine = StringTok( FileBuffer, "\n\r" ); while( pLine != NULL ) { if( *pLine == '#' ) { if( *++pLine == ' ' ) pLine++; TextOut( "\n%s", pLine );

106

pLine = StringTok( NULL, "\n\r" ); continue; } // // linea de datos // else if( isxdigit( *pLine )) { if( StringStr( pLine, "2,1" )) { if( StringStr( pLine, "2010010100" )) { // reseteo en frio TextOut( "\nreseteo en frio" ); SOSL_ResetICC( (CL_PSTC_CONTEXT) Com, CL_RESET ); } } else { int Len = 0; char *pCmd; CL_BOOL ReadNext = TRUE; char *pToken; do { pCmd = pLine; if (StringStr(pLine, "2,")) { pToken = StringStr( pLine, " " ); pCmd = pToken+1; } while( ConvertVar( FALSE, pCmd, "%02X", &Command[Len]) == 1 ) { pCmd+=2; Len++; } if (!StringStr(pLine, "\\")) ReadNext = FALSE; else pLine = StringTok( NULL, "\n\r" ); } while (ReadNext); TextOut( "\nComando: " ); DataOut((CL_STRING) Command, (CL_DATALEN) Len); RC = CL_CardExchange ( (CL_PSTC_CONTEXT) Com, (CL_STRING) Command, (CL_DATALEN) Len, (CL_STRING) Response, (CL_DATALEN *) &ResponseLen ); switch (RC) { case CL_ERR_NOCARD: TextOut( "\nNo hay TI" ); break; case CL_ERR_COMM: TextOut( "\nFalla de Comando" ); break; case CL_OK: TextOut( "\nRespuesta: " ); DataOut( Response, ResponseLen );

107

SendCommand = TRUE; break; default: TextOut( "\nERROR: No se puede enviar comando\n\n" ); break; } } } pLine = StringTok( NULL, "\n\r" ); if ( pLine == NULL ) break; if( *pLine == '>' ) { unsigned int Len = 0; int i, StrLen; char *pCmd; CL_BOOL ReadNext = TRUE; char Buffer[3]; // comparar do { if (SendCommand) { pCmd = pLine+1; i = 0; StrLen = StringLen(pCmd); while (i < StrLen) { if ((*pCmd != 'X') || (*pCmd != 'x')) { if (Len >= ResponseLen) break; ConvertVar( TRUE, (char *) Buffer, "%.2X", &Response[Len++]); if ((*(pCmd) != Buffer[0]) || (*(pCmd+1) != Buffer[1])) { TextOut( "\nCompara error: de Posicion: %d %c%ch != %c%ch", Len, Buffer[0], Buffer[1], *pCmd, *(pCmd+1) ); SendCommand = FALSE; break; } } i += 2; pCmd += 2; } } if (!StringStr(pLine, "\\")) ReadNext = FALSE; else pLine = StringTok( NULL, "\n\r" ); } while (ReadNext); SendCommand = FALSE; pLine = StringTok( NULL, "\n\r" ); if ( pLine == NULL ) break; } TextOut( "\n\nPresionar cualquier tecla para continuar o 'x' para cancelar" ); Choice = GetChar(); if ((Choice == 'x') || (Choice == 'q') || (Choice == 0x1B)) break; } if ( pLine == NULL )

108

{ TextOut( "\nFinal de linea de comandos " ); } } _close(*hFile); *hFile = -1; return( TRUE ); } // // send command // CL_RCODE SOSL_SendCommand( CL_PSTC_CONTEXT Com) { CL_BYTE Input[100]; CL_BYTE Command[600]; CL_BYTE Response[600]; CL_DATALEN ResponseLen; CL_RCODE RC = CL_ERR_COMM; int Len = 0; char *pCmd; char *pToken; TextOut( "\n\nIntroducir comando: " ); DataInS( Input ); pCmd = Input; if (StringStr(Input, "2,")) { pToken = StringStr( Input, " " ); pCmd = pToken+1; } while( ConvertVar( FALSE, pCmd, "%02X", &Command[Len]) == 1 ) { pCmd+=2; Len++; } RC = CL_CardExchange( (CL_PSTC_CONTEXT) Com, (CL_STRING) Command, (CL_DATALEN) Len, (CL_STRING) Response, (CL_DATALEN *) &ResponseLen ); switch (RC) { case CL_ERR_NOCARD: TextOut( "\nNo hay TI" ); break; case CL_ERR_COMM: TextOut( "\nfalla de comando" ); break; case CL_OK: DataOut( Response, ResponseLen ); break; default: TextOut( "\nERROR: no se puede enviar comando\n\n" ); break; } return( RC ); }

109

ANEXO C. CÓDIGO DE LA PANTALLA DE MENÚ PRINCIPAL DE LA APLICACIÓN

Este es parte del código del archivo fuente de C++, que abre la unidad del menu principal. El programa Cripto.cpp es un fragmento del archivo fuente de la pantalla para el menu principal. //--------------------------------------------------------------------------- #include <vcl.h> #pragma hdrstop USERES("Cripto.res"); USEFORM("Cripto.cpp", Form1); //--------------------------------------------------------------------------- WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { try { Application->Initialize(); Application->CreateForm(__classid(TForm1), &Form1); Application->Run(); } catch (Exception &exception) { Application->ShowException(&exception); } return 0; } //---------------------------------------------------------------------------

Archivo cripto.h que corresponde al código del archivo de encabezado de C++ que contiene las declaraciones de las clases. //--------------------------------------------------------------------------- #ifndef CriptoH #define CriptoH //--------------------------------------------------------------------------- #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> //--------------------------------------------------------------------------- class TForm1 : public TForm { __published: // IDE-managed Components TRichEdit *RichEdit1; TStatusBar *StatusBar1; TStatusBar *StatusBar2; TActionList *ActionList1; TImageList *ImageList1;

110

TAction *FileNew; TAction *FileOpen; TAction *FileSave; TAction *FileExit; TAction *AbrirArchivo; TAction *Action1; TAction *Action2; TAction *Action3; TAction *Action4; TMainMenu *MainMenu1; TMenuItem *Archivo1; TMenuItem *NuevoArchivo1; TMenuItem *Abrir1; TMenuItem *Salir1; TMenuItem *UbicacionArchivo1; TMenuItem *Encriptar1; TMenuItem *UbicacionArchivosEncriptados1; TMenuItem *Desencriptar1; TMenuItem *Enviar1; TButton *Button1; TButton *Button2; TButton *Button3; TButton *Button4; TGroupBox *GroupBox1; TGroupBox *GroupBox2; TComboBox *ComboBox1; TComboBox *ComboBox2; TMemo *Memo1; TMemo *Memo2; TMemo *Memo3; TMemo *Memo4; TEdit *Edit1; TEdit *Edit2; TLabel *Label1; TLabel *Label2; TLabel *Label3; TComboBox *ComboBox3; TComboBox *ComboBox4; TMainMenu *MainMenu1; TMenuItem *Archivo1; TMenuItem *UbicacionArchivoPlano1; TMenuItem *UbicacionArchivoEncriptado1; TImage *Image1; TImage *Image2; private: // User declarations public: // User declarations __fastcall TForm1(TComponent* Owner); }; void __fastcall FileNewExecute(TObject *Sender); void __fastcall Salir1Click(TObject *Sender); private: // User declarations public: // User declarations __fastcall TForm1(TComponent* Owner); }; //--------------------------------------------------------------------------- extern PACKAGE TForm1 *Form1; //--------------------------------------------------------------------------- #endif //--------------------------------------------------------------------------- #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; //--------------------------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { if( ! _SLBAPIAllocateComManager() ) return;

111

unsigned int NbrReaders = _SLBAPIGetNbrReaders(); if( NbrReaders == 0 ) { ShowMessage(" No hay lectores disponibles"); Close(); } NbrReaders = _SLBAPIGetNbrFreePorts(); if( NbrReaders == 0 ) { ShowMessage(" No hay lectores disponibles"); Close(); } unsigned char Tipo; char NombrePuerto [MAXLEN]; for( unsigned int k = 0; k < NbrReaders; k++ ) { memset( NombrePuerto, 0, sizeof (NombrePuerto)); if ( _SLBAPIGetFreePort( k, NombrePuerto, MAXLEN ,&Tipo ) && Tipo == SLBAPI_RT_SERIAL ) { ComboBox2->Items->Add( NombrePuerto ); if ( k == 0 ) ComboBox2->Text = NombrePuerto; } } _SLBAPIFreeComManager(); char * Lectores [] = { "SCR60", "REFLEX72", "REFLEX60", "REFLEX20", "SCR60_V310", "SCR_V200", "SCT", "UCRS", NULL }; char ** ptrLect; for ( ptrLect = Lectores ; *ptrLect != NULL ; ptrLect++ ) ComboBox1->Items->Add( *ptrLect ); ComboBox1->Text = Lectores[0]; Form1->statusAllocate = false; ComboBox1->ItemIndex = 0; ComboBox2->ItemIndex = 0; Edit1->Visible = false; Label1->Visible = false; } //--------------------------------------------------------------------------- void __fastcall TForm1::Button1Click(TObject *Sender) { unsigned char Sw1, Sw2, Nip[4], Atr[20], CmdIso [20]; unsigned long PwdProto, PwdNewState, PwdState; unsigned int AtrLen; int Respcmd; memset( Nip, 0, sizeof(Nip) ); memcpy( Nip, Edit1->Text.c_str(), sizeof( Nip ) ); // Se limpia el buffer de la trama de comando memset(CmdIso, 0, sizeof(CmdIso)); // Se arma la trama para presentar el PIN con el comando Verify Key CmdIso[0] = 0x00; // Clase CmdIso[1] = 0x20; // Instrucción CmdIso[2] = 0x00; // P1

112

CmdIso[3] = 0x10; // P2 CmdIso[4] = 0x08; // P3 = Longitud del NIP memcpy( CmdIso + 5, Nip, 4 ); // El NIP consta de 4 digistos memset( CmdIso + 9, 0xFF, 4 ); // Se rellenan con FF's // Enviar el comando Verify key Respcmd = _SLBAPISendIsoInT0( Form1->hReader, CmdIso, 13, &PwdState, &Sw1, &Sw2 ); // Se libera el puerto _SLBAPIFree( Form1->hReader, &PwdState ); Form1->statusAllocate = false; // Se checa el resultado del comando verify key if( Respcmd == SLBAPI_OK && Sw1 == 0x90 && Sw2 == 0x00 ) { Form1->Hide(); Form2->ShowModal(); } else { ShowMessage( "PIN incorrecto" ); Close(); } } //--------------------------------------------------------------------------- void __fastcall TForm1::Button2Click(TObject *Sender) { unsigned int AtrLen; int Respuesta; unsigned long PwdState, PwdProto, PwdNewState; unsigned char Atr[16]; // Asignacion del puerto if( !Form1->statusAllocate ) // Lector sin asignar { String TipoLector = ComboBox1->Items->Strings[ComboBox1->ItemIndex]; Form1->TipoLector = TipoLector.c_str(); String Puerto = ComboBox2->Items->Strings[ComboBox2->ItemIndex]; Form1->NumPuerto = Puerto.c_str(); if( _SLBAPIAllocate( Form1->TipoLector, Form1->NumPuerto, &Form1->hReader, &PwdState ) == SLBAPI_OK ) { Form1->statusAllocate = true; // Se prende bandera de asignacion de puerto Form1->ComboBox1->Enabled = false; // Eleccion de tipo de lector Form1->ComboBox2->Enabled = false; // Eleccion del puerto } else { ShowMessage( "Error en la asignacion del puerto" ); Form1->statusAllocate = false; Close(); } } // Se determina el estado actual del lector memset( Atr, 0, sizeof ( Atr ) ); if ( _SLBAPIState( Form1->hReader, &PwdState, &PwdProto, Atr, &AtrLen ) != SLBAPI_OK ) { ShowMessage( "Error en API de reader" ); Form1->Cerrar(); }

113

//Se verifica si hay una tarjeta insertada dentro del lector switch ( PwdState ) { case SLBAPI_CARDABSENT: if( _SLBAPIMonitor( Form1->hReader, PwdState, &PwdNewState ) != SLBAPI_OK ) { ShowMessage( "Programa terminado" ); Form1->Cerrar(); } if( _SLBAPIReset( Form1->hReader, &PwdState, Atr, &AtrLen ) != SLBAPI_OK ) { ShowMessage( "Error: No se pudo energizar la tarjeta" ); Form1->Cerrar(); } Form1->Button2->Enabled = false; Edit1->Visible = true; //Solicitud del PIN activada Label1->Visible = true; break; case SLBAPI_CARDSWALLOWED: if( _SLBAPIReset( Form1->hReader, &PwdState, Atr, &AtrLen ) != SLBAPI_OK ) { ShowMessage( "Error: No se pudo energizar la tarjeta" ); Form1->Cerrar(); } Form1->Button2->Enabled = false; //Se apaga el boton de insercion de tarjeta Edit1->Visible = true; //Solicitud del PIN activada Label1->Visible = true; break; default: ShowMessage( " Tarjeta no responde " ); Form1->Cerrar(); } } //--------------------------------------------------------------------------- void TForm1::Cerrar() { unsigned long Estado = 0; // Se verifica la bandera de la asignacion del puerto if( Form1->statusAllocate ) { _SLBAPIFree( Form1->hReader, &Estado ); // Se libera el puerto Form1->statusAllocate = false; // Se apaga la bandera de asignacion del puerto } Close(); } //--------------------------------------------------------------------------- void __fastcall TForm1::Button3Click(TObject *Sender) { Form1->Cerrar(); } //--------------------------------------------------------------------------- void __fastcall TForm1::FormCloseQuery(TObject *Sender, bool &CanClose) { unsigned long Estado = 0; // Se verifica la bandera de la asignacion del puerto

114

if( Form1->statusAllocate ) { _SLBAPIFree( Form1->hReader, &Estado ); // Se libera el puerto Form1->statusAllocate = false; // Se apaga la bandera de asignacion del puerto } CanClose = true;

Acceso negado código la función AccesoNegado.h #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> #include <ExtCtrls.hpp> //--------------------------------------------------------------------------- class TForm1 : public Tform { __published: // IDE-managed Components TButton *Button1; TPanel *Panel1; private: // User declarations public: // User declarations __fastcall TForm1(TComponent* Owner); }; //--------------------------------------------------------------------------- extern PACKAGE TForm1 *Form1; //--------------------------------------------------------------------------- #endif

Código de AccesoNegado.cpp #include <vcl.h> #pragma hdrstop #include "AccesoNegado.h" //--------------------------------------------------------------------------- #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; //--------------------------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { CL_BYTE RC = CL_OK; CL_BYTE Com = 1; char Choice; RC = CL_Open( (CL_PSTC_CONTEXT) &Com ); if (RC != CL_OK) { CL_Close( (CL_PSTC_CONTEXT) &Com ); TextOut( "\nIntroducir el puerto COM: "); Choice = GetChar(); Com = Choice - '30'; RC = CL_Open( (CL_PSTC_CONTEXT) &Com ); } if (RC == CL_OK) { // // ejecutando el ciclo del menu principal // SOSL_MainMenue( (CL_PSTC_CONTEXT) &Com ); }

115

else { TextOut( "\nERROR: no se puede acceder al lector\n\n" ); } CL_Close( (CL_PSTC_CONTEXT)&Com ); exit( 0 ); } switch (RC) { case CL_ERR_NOCARD: TextOut( "\nNo hay TI" ); break; case CL_ERR_COMM: TextOut( "\nfalla de comando" ); break; case CL_OK: DataOut( Response, ResponseLen ); break; default: TextOut( "\nERROR: no se puede enviar comando\n\n" ); break; } return( RC ); } //---------------------------------------------------------------------------