Sunteți pe pagina 1din 115

UNIVERSIDAD AUTNOMA METROPOLITANA

Unidad Azcapotzalco

UN MTODO PARA AUMENTAR LA SEGURIDAD DE LA INFORMACIN EN LAS REDES TCP/IP, USANDO TARJETAS INTELIGENTES

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

ING. ENRIQUE RODRGUEZ DE LA COLINA

Asesor: Jurado:

Dr. ROSSEN PETROV POPNIKOLOV Dr. GUILLERMO MORALES LUNA Dr. ROSSEN PETROV POPNIKOLOV Dr. JUAN CARLOS SANCHEZ GARCA

Jurado Externo:

CIUDAD DE MXICO, MARZO DEL 2003.

AGRADECIMIENTOS

RESUMEN
Como medio para aumentar la seguridad de la informacin en las redes de datos de TCP/IP y ms especficamente en Internet, se aplican las funciones de Tarjetas Inteligentes (TI). La Internet, red que trabaja sobre los protocolos de comunicacin TCP/IP, ofrece una gama de servicios, en los cuales es necesario contar con mecanismos para garantizar la autenticidad, la autorizacin de acceso, la integridad y la confidencialidad de la informacin. La TI por su capacidad de procesamiento y almacenamiento de informacin, es la herramienta ideal para lograr la seguridad requerida. La norma IS0-7816 clasifica dichas tarjetas en tres grupos: Tarjetas de Memoria (TM), Tarjetas Lgicas (TL) y Tarjetas Inteligentes (TI). Los tres tipos tienen un Circuito Integrado (CI) incrustado con memoria EPROM1. Las Tarjetas Inteligentes (TI), contienen adems un microcontrolador programable y memoria operativa RAM. Las primeras aplicaciones con TI surgen como una necesidad de manejar el dinero electrnicamente y reducir el fraude en pequeas transacciones. De ah se parte con aplicaciones desarrolladas con tarjetas de memoria y que ms tarde motivaran a los diseadores para crear mejores aplicaciones con tarjetas ms poderosas. La tecnologa de las TI est desarrollndose muy rpidamente 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 porttil 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 cmo usarla, para esto se debe entender a la TI como un sistema mnimo de cmputo que cuenta con un microprocesador, memoria RAM, memoria ROM y un sistema operativo propietario. Antes de su utilizacin las TI se encuentran en un estado virgen el cual debe ser configurado con los parmetros de inicio. Una vez configurada la TI se desarrolla una aplicacin dentro de la tarjeta que consiste bsicamente en crear directorios adecuados a la informacin que se va a manejar. Fase 3: Se inicia con la creacin 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 ms general por lo tanto se convirtieron las DLL que estn compiladas en el lenguaje de programacin 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 cdigo con el cual se envan los comandos al lector para que ste los transmita a la tarjeta. Dichos comandos corresponden a las instrucciones que las TI debe ejecutar y estn basados en el estndar de ISO2 que corresponde a la parte de comunicacin. 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 interaccin con el usuario. La aplicacin programada en la PC en conjunto con la programacin de la TI son la base para desarrollar un mtodo en el cual se combinan dos algoritmos de encriptamiento (RSA3 y DES4), hardware y software. Esto es significativamente ms seguro con respecto a un mtodo que slo 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 opcin de nuevas tecnologas y no hacer pblica la informacin 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 informacin transmitida combinando varios mtodos y que est abierto para continuar en esta rama de investigacin proponiendo como herramienta las TI o el uso de hardware que permita aislar parte de la informacin del sistema que la est generando. Tambin es posible complementar este trabajo combinando nuevos mtodos de encriptamiento que demuestren ser ms seguros.

(International Standars Organization) RSA (Rivest, Shamir y Adleman), Encriptamiento de Datos Estndar (Data Encryption Standard)

CONTENIDO

RESUMEN NDICE DE ILUSTRACIONES ABREVIATURAS Y ACRNIMOS

iv vi vii

1.

ANTECEDENTES
1.1. 1.2. 1.3.

INTRODUCCIN 10 PLANTEAMIENTO 11 OBJETIVO PRINCIPAL 12

2.

BASES TERICAS DEL DESARROLLO


2.1. 2.2. 2.3. 2.4. DESCRIPCIN DE TARJETAS INTELIGENTES CRIPTOGRAFA 18 TCP/IP 31 CONCLUSIONES DEL CAPTULO 40

13
13

3.

TRABAJO DESARROLLADO
3.1. 3.2. 3.3. 3.4. 3.5.

42
44

COMPONENTES Y EQUIPO PARA EL DESARROLLO PROGRAMACIN DE LA APLICACIN 63 DESCRIPCIN DE LA APLICACIN 69 RESULTADOS Y COMENTARIOS 76 CONCLUSIONES DEL CAPTULO 77

4. 5.

CONCLUSIONES 78 BIBLIOGRAFA 79
82 101 109

ANEXO A. DESARROLLO DE SOCKETS

ANEXO B. EJEMPLO DE APLICACIN CON TI

ANEXO C. CDIGO DE LA PANTALLA DEL MEN

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

ABREVIATURAS Y ACRNIMOS
3DES API CBC CI DES DLL DNS EPROM FTP ICMP IP ISO MAC NAT RAM ROM RSA SHA-1 TCP/IP UDP (Triple DES) DES, aplicado 3 veces ver cap. 2 pgina 25 Application Program Interface Encadenamiento de Bloques Encriptados (Cipher Block Chainig) Circuito Integrado. Dispositivo electrnico de integracin a gran escala de componentes Chip Encriptamiento de Datos Estndar (Data Encryption Standard) Ligas a libreras dinmicas (Dynamically Linked Library) Servicio de Nombres de Dominio (Domain Name Service) Memoria ROM programable borrable de las siglas (Electrically Eraseble Programmable Read Only Memory) Protocolo de Transferencia de Archivos (File Transfer Protocol) Protocolo de Control de Mensaje de Internet (Internet Control Message Protocol) Protocolo de Internet (Internet Protocol) Organizacin Internacional para la Estandarizacin (International Organization for Standarization) Cdigo de Autenticidad del Mensaje (Message Authenticity Code) Traduccin de Direcciones de Red (Network Address Translation) Memoria de Acceso Aleatorio (Read Access Memory) Memoria de slo lectura (Read Only Memory) Rivest, Shamir y Adleman Algoritmo de funciones de dispersin "Hash" Seguro 1 (Secure Hash Algorithm-1) Transport Control Protocol / Internet Protocol, vese pgina 31 Protocolo de Datagrama de Usuario (User Datagram Protocol)

1. ANTECEDENTES
Las primeras aplicaciones con TI surgen como una necesidad de manejar el dinero electrnicamente y reducir el fraude en pequeas transacciones realizadas por miles de personas, estas transacciones al acumularse durante el da representan grandes cantidades de dinero, un ejemplo real de esta necesidad se tuvo en Francia con los telfonos pblicos en los aos 80s. De ah se parte con aplicaciones desarrolladas con tarjetas de memoria; estas ms tarde motivaran a los diseadores para crear mejores aplicaciones con tarjetas ms poderosas que contaban con los primeros microprocesadores encapsulados en un chip. Podemos decir que las Tarjetas Inteligentes o smartcards del idioma ingls, son realmente pequeas computadoras en tamao, 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 estndares 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 electrnicos que proporcionaron beneficios adicionales como el control de fraude en operaciones de crdito y dbito, el acceso controlado o restringido a instalaciones como fbricas o edificios, el almacenamiento de informacin mdica 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 cdigos 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 Nmeros de Identificacin Personal (NIP), accesos a sistemas con un nombre de usuario conocido como Login y contrasea de entrada password. De este modo se transmiten datos de forma ms segura a travs de las redes de computadoras en general y especficamente en las redes basadas en los protocolos de TCP/IP5. Despus de ser enviada la informacin cifrada o encriptada, el nodo-receptor puede desencriptar la informacin,
5

TCP/IP : (Transport Control Protocol / Internet Protocol), vese seccin 2.3

9 haciendo uso de otra tarjeta inteligente que contenga las llaves y algoritmos correspondientes para desencriptar dicha informacin. La plataforma de operacin para el proyecto es el conjunto de protocolos TCP/IP, utilizado en Internet. Internet representa la interconexin de la mayora de las redes de computadoras utilizando equipos ruteadores, que cuentan con un sistema de direccionamiento comn y un conjunto de protocolos de comunicacin comn. 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 Aplicacin

Los protocolos de todas y cada una de estas capas trabajan en conjunto para poder transmitir la informacin hasta el lado opuesto. Los protocolos ms comunes en TCP/IP son: el IP, "Internet Protocol" que trabaja en la capa de red, transportando la informacin entre redes; el TCP (Protocolo de Control de la Transmisin) que trabaja sobre la capa de transporte y es el encargado de mover la informacin entre puntos finales6; el UDP (Protocolo de Datagramas del Usuario) que trabaja sobre la capa de transporte, lleva informacin entre los puntos finales de la comunicacin. 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 transmisin de la informacin. Algunos puntos importantes relacionados con el tema de la seguridad de la informacin que deben ser considerados son: La proteccin de la integridad de la informacin. La proteccin de la disponibilidad de la red. La proteccin de la confidencialidad de la informacin.

Al proponer una solucin a estos problemas entramos al amplio tema del encriptamiento, de la autenticidad y de hacer privada la informacin por medio de TI. Tener una forma de asegurar la integridad de la informacin en la red es de suma importancia tanto para los usuarios, como para los diseadores de programas. De no existir la proteccin necesaria, la informacin estara expuesta ante cualquier usuario con intenciones de indagar, alterar o borrar cualquier dato transmitido, lo que representa un alto riesgo, prdida de tiempo y dinero.
6

Entindase por puntos finales, (los nodos en comunicacin).

10

1.1.

INTRODUCCIN

Una Tarjeta Inteligente (TI) es una tarjeta de plstico, que tiene las dimensiones de una tarjeta bancaria segn los estndares internacionales. Contiene un Circuito Integrado (CI) que es un microprocesador incrustado. Este microprocesador hace la diferencia entre la Tarjeta Inteligente y las dems tarjetas con Circuitos Integrados, tambin conocidas como "tarjetas chip" que slo cuentan con memoria. La norma IS0-7816 clasifica dichas tarjetas en tres grupos: Tarjetas de Memoria (TM), Tarjetas Lgicas (TL) y Tarjetas Inteligentes (TI). Los tres tipos tienen un CI incrustado con memoria EPROM7. Las TI, contienen adems un microcontrolador programable y cierta cantidad de memoria operativa RAM. En el caso de las TI, el microprocesador puede procesar diferentes tipos de informacin y por consiguiente diversas industrias estn interesadas en su verstil uso. Inicialmente el sistema operativo, el lenguaje ensamblador y el software de aplicacin de las TI, eran un secreto y solamente se utilizaban para fines militares, pero hoy en da estn presentes en los estndares de la ISO8 y ANSI9 y son desarrollados por empresas como Bull CP8, GemplusDataCard, SCS, ORGA Giesecke&Devrient, Schlumberger entre otras. Compaas importantes, tales como: Microsoft, IBM, HP, Siemens, estn desarrollando tecnologa propia para integrar las TI en sus productos de redes ms novedosos, por lo que se espera que sean un modelo a seguir dentro de la gama de aplicaciones que ofrecen. Hay mltiples aplicaciones que involucran una TI como almacenamiento de dinero para realizar pagos de servicios; por ejemplo: en estacionamientos, gasolineras, lavanderas, telfonos pblicos, transporte, telfonos celulares, compras en Internet, control de accesos. Por todas estas aplicaciones y muchas ms, estn consideradas como una herramienta indispensable en el futuro del comercio electrnico. Las TI pueden comunicarse a travs de un lector con una gran variedad de dispositivos como: terminales punto de venta, cajeros automticos, computadoras personales10, telfonos celulares, telfonos pblicos, dispositivos de acceso a edificios, etc. y pueden ejecutar transacciones seguras a travs de Internet. Actualmente se estn desarrollando programas para controlar planes de pago con la tarjeta inteligente en diferentes pases 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 mquinas automticas, etc.
7

EPROM Memoria programable borrable de las siglas "Electrically Eraseble Programmable Read Only Memory" ISO (International Standars Organization) ANSI (American National Standars Institute). Computadoras Personales, Personal Computers (PC)

10

11 En algunos pases la tarjeta se utiliza en servicios para los estudiantes en las universidades incluyendo: acceso al campus, identificacin para inscripciones, pago de fotocopias, cafetera, gimnasios, almacenamiento de datos como horarios, calificaciones, etc. Tambin otros pases han optado por ofrecer el pago de servicios con el uso de TI a travs de cajeros electrnicos o va Internet. En fin, existe una gran variedad de transacciones que se realizan con el uso de TI, en Mxico se ha instalado un monedero electrnico para realizar compras desde los telfonos pblicos o cualquier equipo de cmputo conectado en red. Como se puede observar las TI representan un sin nmero de aplicaciones que algunos pases ya estn desarrollando rpidamente dando pie a la creatividad de los fabricantes de hardware y software para las necesidades del futuro, como son el almacenamiento ms rpido 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 transmisin de informacin y en las transacciones electrnicas 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 cdigos secretos y firmas electrnicas. Como ya se haba mencionado anteriormente, las TI cuentan con toda la potencia de un microprocesador integrado que puede almacenar llaves criptogrficas y certificados electrnicos, esto representa una forma ms segura de almacenamiento con respecto a un disco duro, el cual pudiera llegar a fallar, ser daado con virus o sufrir prdida de informacin por errores humanos. Otro factor a favor en las TI es la facilidad de portar consigo una identificacin electrnica lista para ser utilizada en cualquier sistema que se le requiera o para agilizar la marcacin de nmeros telefnicos remotos, el acceso a direcciones de red o almacenamiento de informacin 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 criptogrficas. 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 transportacin de informacin encriptada que viaja por la red de forma ms segura. La Internet, ofrece una gama de servicios, en los que es necesario garantizar la seguridad de la informacin ya que se desarroll para un ambiente abierto completamente. La TI, por su capacidad de procesamiento y almacenamiento de informacin 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 instalacin 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 estn involucradas varias reas de las ciencias de la computacin, 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 mnimo de computadora que representa la TI, el diseo de programas de uso especfico en lenguaje propietario de la TI y en C, la lgica digital, la electrnica en general y la criptografa.

1.3.

OBJETIVO PRINCIPAL

Disear y desarrollar un programa de aplicacin para el encriptamiento, utilizando Tarjetas Inteligentes (hardware), con un enfoque para lograr mayor seguridad en la transmisin de informacin, en las redes TCP/IP. 1.3.1. OBJETIVOS PARTICULARES

Analizar los algoritmos de seguridad en la transmisin de datos, para ser desarrollados con las herramientas que la TI y el software de programacin desarrollado proporcionan, con un enfoque hacia el encriptamiento, la confidencialidad y la autenticidad de la informacin. Crear y ejecutar los algoritmos necesarios, a fin de generar una aplicacin para mejorar la seguridad en la transmisin de informacin en las redes TCP/IP. ALCANCE

1.3.2.

En este proyecto se desarroll un programa para una aplicacin con TI, enfocado a la seguridad de la informacin transmitida en redes TCP/IP encriptndola. No existe programa similar en nuestro pas, por lo que representa una aportacin al uso de las TI en la transmisin 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 mtodo al combinar dos algoritmos de encriptamiento y utilizar software y hardware representa una innovacin a nivel Nacional. De acuerdo a la investigacin realizada hasta el momento no hay un procedimiento fidedigno que asegure su invulnerabilidad con recursos y tiempo limitado.

13

2. BASES TERICAS DEL DESARROLLO


2.1. DESCRIPCIN DE TARJETAS INTELIGENTES

La funcin bsica de las Tarjetas Inteligentes, es la de almacenar la informacin de forma visual, tangible y electrnica, que identifique a su portador y que pueda sustentar las transacciones que sean posibles y vlidas. La informacin visual sobre la TI, puede presentarse por medio de grficos, fotografas, hologramas o cdigos de barras. Es tangible por medio de realzado y electrnica, a travs de mecanismos como: bandas magnticas, que se siguen usando en las tarjetas de crdito o bien por medio de un Circuito Integrado (CI) incrustado, el cual es su principal caracterstica. La TI es la transicin de una tarjeta de identificacin a una ficha de identificacin capaz de protegerse a s misma al intentar ser falsificada, en caso de robo o prdida. Tiene diversas ventajas sobre las tarjetas de banda magntica, es ms resistente a variables externas, como campos magnticos, adems de que tiene la capacidad de alcanzar mejor desempeo que las tarjetas de crdito convencionales. El ISO/IEC 7810, define las caractersticas fsicas de las tarjetas de identificacin, las dimensiones generales y forma establecidas para las Tarjetas de Crdito y para las Tarjetas Inteligentes. Existen estndares para el uso de TI en aplicaciones especficas como salud, transportacin, en la banca, comercio electrnico e identidad. Tambin existen estndares para nuevos tipos de TI, lo cual nos confirma que el ISO 7816 no es el nico. El ISO 7816 define las caractersticas de la Tarjeta Inteligente como son: Caractersticas fsicas, dimensiones y posicin de los contactos Seales electrnicas Protocolos de transmisin Comandos de instalacin Sistema numrico y procedimiento de registro

14 La TI, es una tarjeta plstica de alto desempeo, 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 comunicacin 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 comunicacin es regida por el lector y que la tarjeta debe responder de acuerdo a ste. El canal de comunicacin es de un slo conducto, una vez que el lector enva un comando a la tarjeta inteligente, sta se bloquea hasta que recibe una respuesta de que los contactos estn correctamente alineados, previendo un serio dao. Cuando el lector detecta que los contactos ya estn alineados la energa es enviada a la TI. 2.1.1. CARACTERSTICAS FSICAS DE UNA TARJETA INTELIGENTE

Las TI, tambin llamadas tarjetas de seguridad inteligentes del ingls 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 plstica y de los tipos de mecanismos de conexin entre la tarjeta y el lector de tarjetas. Una necesidad de crear las TI fue la de poder almacenar informacin de forma segura y prctica para realizar ciertas actividades. Estas caractersticas se desarrollaron con base a los principales elementos contenidos en cualquier sistema de cmputo, como se muestra en la figura 2.1.

Fig. 2.1: Elementos contenidos en la Tarjeta Inteligente

Especficamente todos los componentes bsicos de un sistema de cmputo estn incorporados dentro de un Circuito Integrado. Las conexiones fsicas entre los componentes del CI estn cubiertas con una estructura monoltica de silicio.

15

El alto nivel de integracin de los componentes del CI de la tarjeta dificulta que las seales que pasan a travs de los componentes del CI sean interceptadas. Por lo tanto, la interconexin obtenida resulta ser ms segura que un sistema de cmputo con conexiones fsicas macroscpicas entre los componentes. En adicin al seguro intercambio de informacin entre los mdulos que componen el sistema del CI, las pequeas dimensiones de ste permiten montar el CI en una tarjeta plstica de dimensiones similares a la de una de crdito bancario. Cuando se inserta el CI en una tarjeta bancaria, el portador somete a la tarjeta a diferentes esfuerzos fsicos, transportndola de un lado a otro, por ejemplo: en un bolsillo del pantaln; este tipo de fuerzas afectan a un sistema de cmputo convencional que tiene la unin de sus partes con alambrado o pistas de conduccin macroscpicas. Sin embargo, a un diseo microscpico, no le afectan este tipo de fuerzas por tener todos sus componentes integrados. Para lograr el menor tamao del CI, es necesario tomar en consideracin la resolucin de la tecnologa utilizada para crear el chip, la cual se caracteriza por lo siguiente: La llamada "medida caracterstica", (por ejemplo; el tamao de un slo 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 alimentacin y los registros en el mapa de memoria. SEGURIDAD OFRECIDA POR LA TARJETA INTELIGENTE

2.1.2.

Ante todo una Tarjeta Inteligente es esencialmente una plataforma de computacin segura, esto es un lugar a salvo para informacin valiosa tal como llaves privadas, nmeros de cuenta, contraseas passwords, o el historial mdico. Tambin es una plataforma de procesamiento segura, es decir, es el lugar adecuado para realizar el procesamiento de la informacin sin exponerla al mundo externo. Ejemplos de ello seran procesamiento de llaves criptogrficas pblicas y privadas. As es como se puede afirmar que las TI proporcionan el ms seguro acceso a redes de computadoras utilizando sistemas con tecnologa de llaves pblicas. Uso de la Tarjeta Inteligente a travs de la infraestructura de la red La tarjeta genera y almacena el par de llaves privada y pblica, puede procesar el encriptamiento y desencriptamiento de los datos, adems puede almacenar certificados electrnicos, aplicaciones especficas 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 tambin 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 aplicacin para el usuario final quien tiene interaccin 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 programacin de alto nivel que se encuentran en las estaciones de trabajo, por ejemplo: lenguaje C, C++, Java, BASIC, COBOL, PASCAL, o FORTRAN y estn mezclados con libreras y dispositivos de entrada/salida para el manejo de accesos e interconexin de los lectores de TI. El segundo, es el software de la tarjeta, el cual como su nombre lo indica corre la aplicacin sobre la tarjeta misma, por lo que es denominado tambin como software del lado de la tarjeta. Este software est catalogado como "las funciones y el software de aplicacin del sistema operativo de la tarjeta". Para muchas aplicaciones es suficiente el software incluido en la tarjeta pero en ocasiones es requerida una aplicacin especfica la cual puede ser desarrollada en lenguaje ensamblador o lenguaje de alto nivel. El software de aplicacin utiliza la capacidad de cmputo y almacenamiento de datos que tiene la tarjeta, hacindolos relativamente independientes de la integridad de otra mquina, lo que aumenta la seguridad. El software del servidor sustituye a la tarjeta para un desarrollo alternativo de la misma aplicacin. Por ejemplo, cuando un historial mdico 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 programacin, que el software del lado de la tarjeta pone ms atencin en el tipo o modelo de tarjeta utilizada. El software de "lado de la tarjeta", provee servicios de cmputo para aplicaciones que tienen acceso a la informacin y protege este contenido de otras aplicaciones que pueden, de forma indebida intentar el acceso a la informacin. El software creado del "lado de la tarjeta" est pensado para operar con diferentes tipos y versiones de TI, as como tambin 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 ejecucin no muestra la informacin almacenada en la tarjeta, a menos que se presente un cdigo de

17 identificacin personal (PIN). Otro ejemplo es un programa que se ejecuta en la tarjeta y que puede calcular una firma electrnica utilizando una llave privada almacenada en la misma Tarjeta Inteligente. El software ejecutndose 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, vdeo juegos, etc. El software del lado del servidor conecta a la Tarjeta Inteligente y al usuario con el sistema. Por ejemplo, un programa ejecutndose en una terminal tipo ATM, del ingls (Automatic Teller Machine) puede solicitar la insercin 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 estn almacenadas en la tarjeta, los algoritmos y los protocolos estn desarrollados en el software del lado de la tarjeta. La criptografa principalmente se utiliza para autentificar las entidades del sistema, tales como usuarios, tarjetas, terminales y para encriptar la comunicacin entre la tarjeta y el mundo exterior. Las funciones criptogrficas se crean dentro de la tarjeta para su propia seguridad o tambin pueden ser desarrolladas para proporcionar seguridad en sistemas externos. La proteccin 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 autntica, 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, despus la terminal donde fue insertada, ella misma y algunas o todas las entidades del sistema. Un simple procedimiento para autentificar, es la posesin de un cdigo de acceso como un PIN de 4 dgitos o puede ser ms complicado mediante la codificacin 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 comunicacin con la entidad es bloqueada. Un historial de las fallas puede ser almacenado en la Tarjeta Inteligente y despus de cierto nmero de intentos fallidos, la tarjeta puede dejarse bloqueada para cualquier tipo de acceso posterior o inclusive puede destruirse su informacin. El encriptamiento puede ser aplicado a todos los mensajes que van desde la Tarjeta Inteligente o hacia ella o slo 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 disear nuevos programas de encriptamiento o autenticidad ya que utilizan las caractersticas construidas en la tarjeta. Estas caractersticas vienen probadas y garantizan un razonable nivel de confianza.

18 A continuacin se muestran algunos algoritmos de encriptamiento, utilizados en diferentes tipos de tarjetas.

Algoritmo DES y 3DES A3 y A8 Curvas elpticas TSA7 RSA

Usos en tarjetas Canales de comunicacin Telefona celular mvil GSM Firmas electrnicas Historial mdico Firmas electrnicas

2.2.

CRIPTOGRAFA

La criptografa es una operacin matemtica aplicada a los datos hacindolos ilegibles durante la transmisin 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 criptologa del griego "criptos" (oculto) y "logos" (tratado) es el nombre genrico con el que se designan dos disciplinas opuestas y a la vez complementarias: la Criptografa y el Criptoanlisis. La Criptografa se ocupa del diseo para encriptar o enmascarar una cierta informacin de carcter confidencial. El Criptoanlisis, por su parte, se ocupa de romper esos procedimientos de cifrado o encriptamiento para as recuperar la informacin original y hacerla entendible nuevamente. Es obvio pensar que las dos disciplinas se han desarrollado de forma paralela, ya que toda informacin cifrada o encriptada lleva siempre implcito el mtodo para su criptoanlisis o desencriptamiento. En realidad, el arte de la Criptografa como medio para proteger la informacin es tan antiguo como la propia escritura. Este arte permaneci durante siglos ligado solamente a los crculos militares y diplomticos pero en la actualidad las necesidades son diferentes popularizndose rpidamente para mantener la transmisin de la informacin por Internet de una manera ntegra.

19 Vase la figura 2.2, el mtodo de llave secreta en donde ambos usan la misma llave para encriptar y desencriptar. Encriptamiento Desencriptamiento

Llave secreta

Llave secreta

Fig. 2.2: Encriptamiento y desencriptamiento, sistema de llaves secretas, simtrico

Existen dos tipos generales de esquemas de seguridad, el de llaves secretas y el de llaves pblicas: En un sistema de llaves secretas, el que enva 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 vera comprometido el sistema completo. En un sistema de llaves pblicas existen de igual forma dos llaves, pero una es secreta, llamada la llave privada y la otra llave es la pblica. Las llaves no son las mismas pero estn relacionadas matemticamente. La llave privada, es guardada en secreto por el propietario y no puede ser determinada con la llave pblica, esta es libremente distribuida hacia los destinatarios elegidos para la comunicacin. La tecnologa para criptografa con llaves pblicas y privadas, utilizada para la seguridad en redes fue desarrollada por la compaa RSA Data Security. Sin embargo, el uso de la tecnologa de llaves secretas est restringido en algunos pases. La tecnologa de llaves pblicas implica complicados clculos matemticos y esto significa que el proceso de encriptamiento y desencriptamiento puede llevarse mucho tiempo como para lograr transacciones eficientes a gran velocidad.

20 Los clculos de las llaves secretas utilizando el algoritmo DES son mucho ms rpidos que los clculos de las llaves usando el algoritmo RSA debido a que DES utiliza llaves de 64 bits en esta aplicacin y RSA, llaves de 1024 bits. Una forma de solucionar este problema es combinando las tecnologas DES y RSA. En lugar de almacenar llaves secretas en la TI, es mejor utilizar la funcin del generador de llaves utilizndola como una llave secreta por sesin. La llave de encriptamiento que se genera por sesin con la funcin de la TI, se utiliza para encriptar el mensaje original con el algoritmo DES, siendo a su vez encriptada la llave de sesin con la llave pblica utilizando el algoritmo RSA. El archivo encriptado y la llave encriptada viajan por la red hacia su destino de forma independiente. La llave de sesin es desencriptada utilizando la llave privada que tiene el receptor con el algoritmo RSA y con la llave de sesin recuperada, se aplica el inverso del algoritmo DES al mensaje que lleg encriptado para obtener el mensaje original en el destino. Vase en la figura 2.3, el sistema de llaves privadas y pblicas propuesto.

Fig. 2.3: Sistema de llaves privadas y pblicas propuesto

21 Al final de la recepcin, la llave de sesin es desencriptada por la tarjeta y utilizada para el desencriptamiento. Una vez que se termina de utilizar la llave de sesin sta es destruida. Integridad de los datos, por medio de TI El uso de firmas digitales es el mtodo ms comn para mantener la integridad de los datos. Un algoritmo de funciones de dispersin "hashing" es aplicado al mensaje original para producir un compendio "digest" del mensaje. La operacin de las funciones de dispersin "hashing" puede ser realizada en la PC o en la TI. La llave pblica de quien enva, es utilizada para encriptar el compendio "digest" que a su vez se utiliza para crear la firma digital. Vase en la figura 2.4, integridad de los datos por medio de las funciones de dispersin "hashing".

Fig. 2.4: Integridad de los datos por medio de funciones de dispersin "Hashing" Una firma digital es una combinacin del mensaje original y de la llave privada enviada. La llave privada de quien enva es usada para encriptar el compendio "digest" del mensaje. El compendio "digest" se crea corriendo el mensaje a travs de lo que se llama un "algoritmo de funciones de dispersin "hashing", el cual reduce los mensajes a un nico y compacto paquete de datos. La firma digital es llamada una firma de dispersin "hash". A travs de este proceso la firma digital es nica para el que enva.

22 Diferente al pensamiento de la mayora, de que la firma digital es la imagen digitalizada de una firma, la firma digital es un procedimiento matemtico que se ejecuta para lograr un paquete de datos nico y que conste que fue emitido por la parte transmisora. Vase en la figura 2.5, el paso de la llave secreta encriptada con RSA y el archivo con DES que se asemeja a la transmisin de una firma electrnica.

Fig. 2.5: Envo 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 pblica del transmisor y obtiene el compendio "digest" del mensaje. El recipiente tambin somete el archivo original a la misma operacin con el algoritmo de las funciones de dispersin "hashing" que el transmisor realiz y compara el resultado con el del compendio "digest". Si son iguales, el mensaje original fue recibido sin alteracin. La firma digital tambin se utiliza para la autenticidad y el no repudio. Por ejemplo, el receptor est seguro de que el mensaje lleg del transmisor y slo del transmisor porque es slo con la llave pblica 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 proteccin de datos durante su transmisin y almacenaje. El chip DES es un producto estratgico en E.U.A. y no est permitida su exportacin 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 ms componentes. El encriptamiento en bloque se compone de cuatro elementos: Transformacin inicial Una funcin criptogrficamente dbil iterada r veces Transformacin final Algoritmo de expansin 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 electrnico y su descripcin 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 permutacin inicial fija y por tanto, sin valor criptogrfico. 2. Se divide el bloque en dos mitades, derecha e izquierda. 3. Se realiza una operacin modular que se repite 16 veces; esta operacin consiste en sumar mdulo 2 a la parte izquierda con una transformacin 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 nmero 16, pero se remata el algoritmo con una permutacin final que es la inversa de la inicial. Para desencriptar el DES basta con repetir la operacin modular, que es una involucin, es decir, su aplicacin repetida dos veces conduce a los datos originales. No es preciso invertir la transformacin g (k1) sino repetirla, esto permite que dicha transformacin sea una funcin de un slo sentido, empleando operaciones no lineales. Las propiedades fundamentales de DES son: Dependencia entre smbolos; cada bit del archivo encriptado es una funcin 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.

Criptografa Simtrica La criptografa simtrica se refiere al conjunto de mtodos que permiten tener comunicacin segura entre las partes siempre y cuando anteriormente se hayan intercambiado la llave correspondiente que llamaremos llave simtrica. La simetra se refiere a que las partes tienen la misma llave tanto para encriptar como para desencriptar. Este tipo de criptografa se conoce tambin como criptografa de llave privada. Existe una clasificacin de este tipo de criptografa en tres familias, la criptografa simtrica de bloques ("block cipher"), la criptografa simtrica de lluvia ("stream cipher") y la criptografa simtrica de dispersin (hash functions). Con ligeras modificaciones, un sistema de criptografa simtrica de bloques puede modificarse para convertirse en alguna de las otras dos formas. Sin embargo se usan en diferentes aplicaciones. La criptografa simtrica ha sido la ms usada en toda la historia, sta ha podido ser empleada en diferentes dispositivos: manuales, mecnicos, elctricos 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 slo conociendo una llave pueda aplicarse de forma inversa para poder as desencriptar. DES es un sistema criptogrfico, 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 prctica 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 aplicacin, DES tiene cuatro modos de operacin 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 propagacin de error. En la actualidad no se ha podido romper el sistema DES desde la perspectiva de poder deducir la llave simtrica a partir de la informacin interceptada, sin embargo con un mtodo 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 propsitos de alta seguridad. La opcin que se ha tomado para poder suplantar a DES ha sido usar lo que se conoce como encriptado mltiple, 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 interaccin 1 a la 16 a B0 con la llave K1, despus se aplica de la 16 a la 1, a B1 con la llave K2, finalmente se aplica una vez ms 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, adems 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 aos se han diseado una gran cantidad de sistemas criptogrficos simtricos, entre ellos estn: RC-5, IDEA, FEAL, LOKI'91, DESX, Blowfish, CAST, GOST, etctera. Sin embargo, no han tenido el alcance de DES, a pesar de que algunos de ellos tienen mejores propiedades. Podemos afirmar que el estdo actual de la criptografa simtrica es la bsqueda continua de nuevos algoritmos como por ejemplo el AES/Rinjdael que es una combinacin de AES (Advanced Encryption Standard) y del algoritmo desarrollado por Joan Daemen y por Vincent Rijmen (Rijndael) que pas a ser un estndar 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 simtricas y es de encriptamiento por bloques, sin embargo el tamao de los bloques es de 128 bits y las llaves de encriptamiento van desde tamaos 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 prctica el RSA necesitamos dos nmeros primos grandes p y q. Despus 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 difcil que es factorizar n ya que hay que encontrar a los nmeros primos p, q y estos son nmeros muy grandes. La llave pblica usada por el criptosistema RSA es un nmero muy grande. Los nmeros primos p y q, deben de mantenerse secretos y el entero n formado parte de la llave pblica.

26 En aplicaciones prcticas este nmero tiene ms de 200 dgitos. Para trabajar con un nmero 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 distribucin de las llaves en el sistema 2. El manejo del nmero de llaves n(n-1)/2 3. No tienen firma digital El algoritmo de llave pblica RSA puede ser formado por distintas longitudes de llaves, con las siguientes caractersticas: Contra ms larga sea la llave ms difcil es descubrir el mensaje. Las llaves ms complejas son de 2048 bits y las estndar son de 1024 bits. Est basado en dos nmeros primos cada nmero > 200 dgitos.

Vase 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 matemtico es el de factorizar un nmero entero "n" de tamao grande (1024 bits), este nmero entero se sabe es producto de dos nmeros primos p, q de la misma longitud, entonces la llave pblica es el nmero 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 nmero entero n, que funciona como su llave pblica. b. Slo el usuario respectivo conoce la factorizacin de n (o sea p, q), que mantiene en secreto y es la llave privada. c. Existe un directorio de llaves pblicas. d. Si alguien quiere mandar un mensaje m entonces elige la llave pblica e y se aplica la operacin c=memod n y se crea el mensaje encriptado c, (que slo 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 informacin encriptada llega a su destino el receptor procede a desencriptar el mensaje con la siguiente frmula: 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 trminos muy generales es as como funciona el sistema RSA. Sin embargo en la realidad existen dos formas que son las ms comunes, estas formas dependen de la aplicacin y se llaman el esquema de firma y el esquema de encriptamiento, a continuacin se describe el esquema de encriptamiento. Esquema de encriptamiento Uso: este esquema se usa principalmente para encriptar llaves de sistemas simtricos (llaves de 128 bits aproximadamente) 1. Se toma el mensaje M (por ejemplo con una llave simtrica de 128 bits), como en la prctica actual es recomendable usar bloques de longitud de 1024 bits los complementa, esos 128 bits con una serie de tcnicas para obtener uno de 1024 bits, despus se aplica un proceso de codificacin para que la computadora entienda el mensaje como un nmero entero m. 2. Se le aplica la frmula de encriptamiento de RSA al entero m. 3. Se enva el nmero entero c. 4. Al recibir este nmero se aplica la frmula de desencriptamiento al entero c para obtener el entero m. 5. Se decodifica m para obtener el mensaje M.

28 Factorizacin y logaritmos discretos Curiosamente, la inmensa mayora de los algoritmos asimtricos que se usan en la actualidad se apoyan en problemas como el de la factorizacin o el de los logaritmos discretos. En realidad existen otros algoritmos que se basan en teoras diferentes, pero hoy por hoy no estn suficientemente estudiados como para ser considerados seguros de forma general, por lo que no se suelen emplear en la prctica. Sistemas como RSA, Diffie-Hellman, e incluso la criptografa de curvas elpticas depositan su seguridad en estos dos problemas. Todos ellos descansan en la supuesta imposibilidad de resolverlos de forma algortmicamente eficiente y se dice "supuesta" porque nadie ha demostrado que no pueda existir un algoritmo capaz de hacerlo de forma satisfactoria. Complejidad algortmica Alguien podra decir que un algoritmo "eficiente" es cuando haya computadoras ms y ms rpidas, problemas que ahora son difciles se podrn resolver y eso es radicalmente falso. En Teora de Algoritmos, se define el orden de complejidad de un algoritmo como una funcin "(n)" de la entrada "n". Esta medida nos dice cmo crece el tiempo de computacin a medida que aumenta el tamao de la entrada. Por ejemplo, si un algoritmo fuera cuadrtico, es decir, (n^2), se tiene que el tiempo de ejecucin 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. Segn esto, si se desea factorizar un nmero, se puede tratar de dividirlo por todos los nmeros menores que l, uno por uno. Suponiendo que la prueba de divisibilidad se ejecutara en un tiempo constante x - simplificacin que en realidad no es cierta -, el algoritmo necesitara aproximadamente n pasos para tratar el nmero n. Eso quiere decir que el programa puede factorizar sin problemas nmeros pequeos pero si al ejecutarlo sobre un nmero de 1024 bits, se precisan llevar a cabo una cantidad de pasos elementales enorme. Por desgracia, actualmente es imposible construir una mquina capaz de llevar a cabo semejante computacin. [22] Si por el contrario se pudiera encontrar un algoritmo capaz de resolver el problema anterior en un nmero de pasos proporcional, por ejemplo, al logaritmo de n, se podra factorizar un nmero de 1024 bits con cien veces ms pasos que los que necesitaramos para hacerlo con un nmero de tan slo 10 bits. No se trata de tener mquinas ms rpidas, que por supuesto ayudan, sino de investigar algoritmos con orden de complejidad menor, capaces de resolver los mismos problemas en menos pasos. Tiempo de factorizacin en la prctica al aplicar RSA Hoy en da, parece ser que en el problema de la factorizacin se ha avanzado enormemente, este gran impulso lo ha provocado en gran parte la criptografa y ms concretamente el sistema RSA. Aunque se muestre que un algoritmo corre a tiempo subexponencial o ms an a tiempo polinomial, el tiempo de calendario (tiempo real en meses, das o minutos) puede variar mucho dependiendo de la entrada del algoritmo y del equipo de cmputo con que se cuenta. Existe una

29 forma de medir el potencial de cmputo y de esta forma determinar cul sera el tiempo en calendario que llevara factorizar un nmero entero grande. La notacin mips significa millones de instrucciones por segundo y es tomada como medida estndar para registrar la potencia de cmputo con que se cuenta. Un mips tiene como origen la potencia de cmputo que realizaba una DEC VAX 11/780. Un "mipsy" significa el nmero de operaciones que se pueden realizar en un ao con un poder de cmputo 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 nmeros de identificacin personal NIP PIN (del ingls), datos biomtricos como seran las firmas, la huella digital, intercambios de preguntas y respuestas o firmas electrnicas. b. Autorizacin

Para tener acceso a la informacin o servicios dentro de la red usualmente se utilizan contraseas (passwords) y nmeros de cuenta para prevenir que extraos vean la informacin con slo pasar las firmas digitales. c. Confidencialidad

La confidencialidad de las transacciones entre entidades de la red utilizando tcnicas criptogrficas, es el evitar que extraos conozcan el contenido de la informacin almacenada. d. Integridad de la informacin

La integridad de la informacin que fluye a travs 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 tcnicas criptogrficas y firmas digitales. e. Confirmacin de la transaccin

La confirmacin de la transaccin entre dos entidades de la red; significa que el autor de los datos no debe recibir reclamacin por parte de los usuarios, para esto pueden utilizarse firmas electrnicas. Como una manera de mantener alejados a los intrusos de la red se debe encriptar la informacin que fluye a travs de ella y como un mtodo 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 informacin que tiene la tarjeta grabada en su interior. Como segundo paso la autenticidad de la tarjeta con el servidor, aqu el servidor genera un nmero aleatorio como recibo y lo enva 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. Clasificacin de seguridad segn la vulnerabilidad de los algoritmos Seguridad incondicional (terica): El sistema es seguro frente a un atacante con tiempo y recursos computacionales ilimitados. Seguridad computacional (prctica): 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 estn 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 ms usados en todo el mundo y por esta razn se eligieron como medio para la comunicacin e implementarle un mtodo seguro de transmisin de la informacin. En el caso de TCP/IP es mejor utilizar OSI slo como modelo de referencia terica y estudiar con detenimiento el verdadero modelo TCP/IP como se hace a continuacin.

2.3.1.

DIRECCIONES IP

El principal beneficio de IP es que es capaz de convertir un conjunto de redes fsicamente distintas en una sola red aparentemente homognea. Una red Internet, es una red IP aparentemente homognea. La Internet es la red de redes. En realidad slo es una interconexin de redes (inter-red) muy grande y que se extiende por todo el planeta. La caracterstica de cualquier internet es que cada uno de los nodos tiene una direccin 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 direccin de origen (donde se origin la trama) y una direccin destino (a donde se dirige la misma). Estas direcciones tienen una representacin con cuatro nmeros enteros separados por puntos y en notacin decimal. Las direcciones representan la interfaz de conexin de un equipo con la red. As, un anfitrin "host12" que est conectado a varias redes como regla general, no tendr una nica direccin 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 nmero 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 estn conectados a una misma red fsica. La segunda parte representa el "host" y debe ser diferente para todos los anfitriones "hosts" que estn conectados a la misma red fsica. El mecanismo de toma de decisin de IP, que hace que todas las tramas lleguen a su destino, es el siguiente: Cuando la direccin origen y la direccin destino, estn ambas en la misma red (esto se sabe porque su direccin de red es igual en ambas, la direccin de red ser la consecuencia de sustituir

11

Trama "frame" , Unidad de datos en las capas fsica 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 anfitrin. Computadora o servidor que tiene una direccin de hardware y reside en una red.

32 por ceros toda la parte del anfitrin "host" en la direccin 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 anfitrin "host" destino. Cuando la direccin 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 anfitrin "host". Un anfitrin "host", en general, est conectado a varias redes, de las que hace de gateway (compuerta), si la direccin destino de la trama tiene una direccin de red que coincide con alguna de las direcciones de red propias, las que resultan de sustituir por ceros la parte del anfitrin "host" en cada una de las interfaces, entonces no hace falta rutear. Esta tabla tiene ms o menos entradas, en funcin de la complejidad de la inter-red y la direccin del siguiente anfitrin "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 funcin de los cuatro bits ms significativos del primer byte.

Tabla 2.1. La n representa la parte de red de la direccin y h, la parte de anfitrin "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 difusin o "multicasting" y las direcciones de clase E estn 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 anfitrin "hosts", las redes de clase B tienen los dos primeros bytes como parte de red y los dos ltimos como parte del anfitrin "hosts" y las redes de clase C, tienen como parte de red los tres primeros bytes y como parte del anfitrin "hosts" el ltimo. As, puesto en notacin con puntos, las redes de las distintas clases cubren los siguientes rangos de direcciones: clase A clase B clase C 2.3.3. de la 1.0.0.0 de la 128.0.0.0 de la 192.0.0.0 --> 127.255.255.255 --> 191.255.255.255 --> 223.255.255.255

MSCARAS DE RED

La mscara de red no es ms que una direccin IP, donde se han sustituido todos los bits de la parte de red de la direccin por unos y los bits correspondientes a la parte de anfitrin "host" por ceros. As, la mscara 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 mscara de red a pesar de que sta, est implcita en el tipo de direccin, 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 mscara de red para separarla. En este caso la mscara de subred se extiende dos bits ms all de la frontera impuesta por el tipo de la direccin adquirida y se considera como si tuviera cuatro redes (en este caso la parte de red seran 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 anfitrin "host" son los bits cero y la parte de red, son los bits uno de la mscara y asociando a cada direccin IP una mscara en el momento de configurarla, por supuesto, los valores por defecto sern los de la clase de la red, aunque se podrn aadir y solamente aadir, bits uno a la mscara, 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 mquina, una tabla con la forma de dirigir las tramas hacia las redes que no vemos directamente, con la ventaja adicional de que como la direccin 0.0.0.0 representa obviamente la red local podemos usar esta direccin especial para indicar la ruta por defecto (es decir, la direccin 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 conclusin de esta ltima frase se desprende que el backbone es la red de nivel jerrquico superior donde no hay ninguna red ms 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 ms pequeas sern analizados. Subdividir una red no sirve nicamente a criterios topolgicos relacionados con la instalacin fsica de la red. Est claro que las redes de topologa distinta o que usen diferentes protocolos de transmisin, deberan tener direcciones distintas para no mezclar artificialmente cosas distintas pero tambin se puede dividir una gran red en varias redes por otros motivos. Por ejemplo para facilitar la administracin de la red, delegando a cada administrador la gestin de direcciones de una subred. Quizs la estructura de una empresa aconseje separar redes distintas para distintos departamentos. Es decir las subredes pueden facilitar la adaptacin de la red a la estructura de una organizacin. Tambin pueden servir para aislar redes con trfico interno abundante y facilitar el diagnstico de problemas en la red. En teora se puede dividir una sola red fsica en varias redes lgicas pero si la separacin fsica fuera posible, conviene hacerla unindolas con un gateway13 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 simultneamente pero nunca pueden hablar dos usando el mismo bus15 a la vez porque se origina una colisin de los paquetes y estos debern ser reenviados de forma no simultnea. Los trminos Compuertas Gateways, Ruteadores Routers y Puentes Bridges se refieren a una serie de dispositivos para la interconexin de redes Muchas veces estos dispositivos son una PC con un par de tarjetas de comunicaciones para conectarse simultneamente 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 traduccin de un protocolo a otro pero s traduccin de direcciones. Una compuerta puede conectar redes distintas (por ejemplo una ethernet y una token ring) realizando la conversin de protocolos y la traduccin de

13

Gateway: compuerta CSMA/CD: (Carrier Sense Multiple Access with Collision Detection) / Acceso multiple por deteccin de portadora con deteccin de colisiones Bus : grupo de conductores en paralelo que conectan los registros de desplazamiento o alimentacin

14

15

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 funcin 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 solucin es un puente, que es ms rpido y ms econmico. Para determinar una ruta como la ms idnea, el protocolo de informacin de ruteo (RIP) es un protocolo que est basado nicamente en el costo. A cada ruta se le asocia un costo en funcin del rendimiento de la red y del tipo de la lnea. Esto permite determinar de entre varias rutas posibles cul es la de menor costo. Cada ruteador de una red enva y recibe informacin 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 cada de un nodo de la red, suele provocar la prdida 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 lgico que sirve para conectar de forma segura la parte privada de una red con la parte pblica. Estos dispositivos pueden establecer una poltica de restricciones a la informacin que circula por ellos. Servidores de Nombres Las direcciones IP son muy adecuadas para las mquinas pero son difciles de recordar. Por esta razn se usan nombres de dominios. Adems usando slo una direccin IP sin nombre, tendramos que cambiar de direccin cada vez que nos alojemos en un servidor distinto. Si asimilamos una direccin a un nombre, podemos mantener nuestra presencia en Internet cambiando de servidor sin que se note el cambio. En la prctica, el cambio no sucede instantneamente porque tiene que propagarse la informacin del cambio de nombre en gran parte de la red. Para una red pequea nos bastara usar un archivo que sea comn a todos los nodos de la red. Si la red es ms grande, cada cambio debe de ser propagado a los dems lo antes posible y controlar que la informacin 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 sera 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 informacin distribuida adecuadamente, mediante un sistema de dominios que se reparten la carga de gestionar estos nombres organizados de forma jerrquica 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 investigacin. 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 slo los datos con informacin del usuario, sino datos de cabecera y de cola que se estructuran en forma que los niveles superiores de transmisin de datos son un encapsulado de los niveles inferiores. Para formar un paquete UDP habra que envolverlo de la manera siguiente como muestra la figura 2.7: Datos N bytes UDP 20 bytes IP 20 bytes Datos N bytes UDP 20 bytes Datos N bytes UDP 20 bytes Datos N bytes Ethernet 4 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 finalizacin del paquete. Unicamente el nivel de Interfaz Ethernet tiene parte de finalizacin 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 IP 20 bytes Datos N bytes TCP 20 bytes Datos N bytes TCP 20 bytes Datos N bytes Ethernet 4 bytes Fig. 2.8: Forma de los paquetes TCP

Ethernet IP 14 bytes 20 bytes

Ethernet IP 14 bytes 20 bytes

37 La seccin de datos puede tener distinto tamao, segn los casos, pero generalmente no ser mucho mayor de 1 KByte. A continuacin 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) Versin IHL Tipo de Sevicio Tamao Total Identificacin Tiempo de Vida Direccin de Origen Direccin de Destino Protocolo Desplazamiento Fragmento Checksum de Cabecera Flags del

Fig. 2.9: Cabecera IP Simplemente nos conformaremos con resaltar que la cabecera IP, tiene datos de identificacin y direccin y la cabecera TCP, contiene informacin de los puertos as como indicadores de control, nmero de secuencia de los paquetes, etctera, esto para detectar la prdida de paquetes o su deterioro a fin de gestionar el reenvo de paquetes en caso necesario.

Cabecera TCP (20 bytes) Puerto de Origen Nmero de secuencia Nmero de Confirmacin U A P Desplz.de Reserv R C S los datos ados G K H Checksum

Puerto destino

R S I

S Y N

F I N

Ventana 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 travs de varios nodos y dicha ruta puede variar incluso dentro de una misma sesin o de una misma transferencia de archivos. Por ejemplo, la cada en una ruta supondra la prdida de algunos paquetes pero no afectara a la transmisin ya que esta, continuara rpidamente por otra ruta sin que apenas podamos percibirlo. Recordemos que Internet proviene en sus orgenes de diseos con objetivos militares. Si se ejecuta el comando "ping" a una mquina remota, se recibir una informacin til para

38 diagnosticar la calidad de la conexin con ese servidor. Se trata de un servicio muy sencillo orientado a datagramas. Primero se mostrarn una serie de lneas, donde se podr comprobar el tiempo de respuesta expresado en milisegundos. Si su ejecucin es interrumpida, mostrar unas estadsticas en las que se podr ver, entre otras cosas, el porcentaje de paquetes perdidos. Un repetidor slo amplifica y retoca la seal a nivel puramente elctrico, por lo tanto ignora cualquier cosa sobre la informacin transmitida. PUENTE BRIDGE Un puente acta controlando la circulacin de paquetes en nivel de interfaz de red. En nuestro caso es la capa ethernet. Ambas redes debern ser muy parecidas ya que cualquier diferencia en los protocolos superiores hara imposible la conexin de ambas redes. En la prctica se puede permitir conectar redes con diferentes velocidades pero ambas redes fsicas se comportaran como una misma red lgica.

RUTEADOR ROUTER Un ruteador acta traduciendo o controlando la circulacin 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 acta en el nivel de transporte, que en nuestro caso puede ser TCP o UDP. Tambin engloba los niveles inferiores. CORTAFUEGOS FIREWALL Un cortafuegos acta permitiendo o denegando el paso de paquetes considerndolos en su totalidad, permitiendo el ms amplio control posible. Uno de los usos ms comunes, es el de proteger una intranet de accesos no deseados en ambos sentidos con el exterior, especificando unas polticas 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 intencin 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 intromisin de personas no deseadas.

39 A pesar de contar con equipos como los cortafuegos, estos equipos son susceptibles a los ataques de hackers16, 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 sera la TI haciendo al sistema ms robusto y por lo tanto con mayor seguridad.

2.3.6.

INTERFAZ DE SOCKETS

Una Interfaz de Programa de Aplicacin API, Application Program Interfaz es, simplemente, un grupo de funciones que se utilizan a fin de desarrollar programas de aplicacin para un ambiente de cmputo especfico. Por ejemplo: a los programadores de software que desean crear aplicaciones para Windows, Microsoft proporciona una extensa coleccin de rutinas de programacin: la API de Windows. En la dcada 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 ms popular de las API para redes TCP/IP.

16

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

cmputo.

40

2.4.

CONCLUSIONES DEL CAPTULO

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 tambin se conoce como el software del lado del lector de tarjetas. El software en el servidor se escribe en lenguajes de programacin 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 aplicacin sobre la tarjeta misma, por lo que es denominado tambin como software del lado de la tarjeta. Las funciones y el software de aplicacin del sistema operativo de la tarjeta, son parte del desarrollo del lado de la tarjeta. La necesidad de tener la informacin 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 criptologa (del griego criptos = oculto y logos = tratado), es el nombre genrico 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 mtodo simtrico de criptografa, la llave de encriptamiento coincide con la llave de desencriptamiento, mientras que en el mtodo asimtrico, 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 proteccin de datos durante su transmisin 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 prctica el RSA necesitamos dos nmeros 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 difcil de factorizar n y de encontrar p y q, que son nmeros muy grandes. Para decir que un sistema cumple con normas de seguridad se cuidan: la autorizacin para tener acceso a la informacin, la confidencialidad de las transacciones entre las entidades de la red utilizando tcnicas criptogrficas, la integridad de la informacin, que se asegura por medio de varios niveles de acceso a la red y por ltimo la confirmacin de la transaccin.

41 La pila de protocolos TCP/IP son los protocolos ms ampliamente usados en todo el mundo y por esta razn se eligieron como medio para la comunicacin y desarrollo de un mtodo seguro de transmisin de la informacin. Una Interfaz de Programa de Aplicacin API, Application Program Interfaz es, simplemente, un grupo de funciones que se utilizan a fin de desarrollar programas de aplicacin para un ambiente de cmputo especfico.

42

3. TRABAJO DESARROLLADO
Un mtodo para aumentar la seguridad de la informacin en las redes TCP/IP usando tarjetas inteligentes. La idea principal del proyecto es incrementar la seguridad de la transmisin de informacin 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 aplicacin fue necesario analizar diferentes sistemas operativos y su interaccin con sistemas criptogrficos. Encontramos que la mayora de los sistemas de seguridad residan como software dentro del mismo sistema que generaba la informacin, por lo tanto surgi la idea de aprovechar las cualidades de las TI ya que tenan 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 informacin a transmitir. El hecho de que la Tarjeta Inteligente trabaje independientemente del sistema generador de la informacin a transmitir mejora la seguridad, ya que contrarresta los ataques de hackers que intentan violar la integridad de un sistema utilizando los mtodos por falla. Estos mtodos, provocan una cada del sistema, con el fin de que cuando se est restableciendo sea posible conocer los comandos, que se intercambian entre un punto de la comunicacin y otro. La TI al ser un dispositivo independiente de los dos puntos de conexin, est aislada de los ataques del exterior. Adems al ser porttil no est expuesta a la intromisin de alguien que pueda usar la PC en donde se genera la informacin encriptada, como sucedera en caso de utilizar solamente un mtodo de encriptamiento por software dentro de la PC. En un principio, la propuesta fue utilizar ANSI C para la programacin de la aplicacin del lado de la PC. Esto, porque ANSI C es un estndar y cumplira con una gama ms amplia de computadoras. En la decisin final, se tom en cuenta que la plataforma de desarrollo debe ser ms 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 nmero 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 programacin 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 aplicacin 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. Adems se consider que el C++ es un lenguaje que permite manejar mejor el caso general. Despus 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 aplicacin 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, adems de direcciones lgicas y una creacin dinmica 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 dems dispositivos en general como por ejemplo la PC donde residen la aplicacin y el compilador de Builder C++ de Borland. La descripcin de los componentes es solamente una perspectiva general de sus caractersticas y uso ya que no se pretende hacer un anlisis de los mismos, sino utilizarlos como herramientas para brindar seguridad en la transmisin de datos a travs de Internet. Adems se intenta promover el uso de las TI como una opcin de nuevas tecnologas y no hacer pblica la informacin 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 conexin en los sistemas de cmputo.

Fig. 3.2: Diagrama de conexin, 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 cmputo que puede ser una PC o una estacin de trabajo y los diferentes tipos de TI. Algunas de las caractersticas 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 estndares americanos para radiacin electromagntica y adems cumple con el estndar AFNOR 98020. La interfaz de la TI cumple con los requerimientos de la norma ISO7816-3. El lector de tarjetas est diseado con un Microprocesador 80C31 con los controladores de software instalados en una memoria externa EPROM de 32 Kbytes. Adems, la configuracin 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 insercin y retiro de tarjeta, la frecuencia de parpadeo es diferente para las dos instrucciones, lo que ayuda para distinguir entre una peticin de retiro de tarjeta o una de insercin. Especificaciones de la comunicacin 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 nmero impar y 1 si es par Niveles: RS232

La interfaz fsica est limitada a 3 seales que son:


17

Recepcin Transmisin Tierra

FCC : siglas de (Federal Communication Comission)

46 Existen dos protocolos de comunicacin 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 versin es menor a 3.1 ese lector no podr utilizar los programas que se crearon con versiones ms actuales. Para la seleccin del lector se tuvieron que tomar en cuenta varios factores como son: El tipo de alimentacin elctrica requerida Cmo se conecta a la PC (interfaz fsica) 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 prctico su uso adems de que debe de cumplir con los estndares establecidos para las TI que se encuentran bajo las normas de ISO. El lector utilizado ha cumplido con las condiciones de operacin mencionadas. Actualmente algunas marcas fabricantes de software se preocupan por la integracin de lectores en las PC, por lo que las versiones de los sistemas operativos actuales cuentan con algunos controladores para lectores de TI, convirtindolos en dispositivos que se instalan bajo el concepto Plug and Play trmino del idioma ingls que se refiere a la instalacin del dispositivo de forma automtica gracias a que la PC reconocer su conexin 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 aplicacin desarrollado. Las partes desarrolladas son: la conexin entre el lector y la PC que es a lo que se hace referencia como la instalacin 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, tambin existen las de estado de ejecucin que regresan un cdigo de error, las cuales se mencionan a continuacin: 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 slo 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 comunicacin: 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 cmo manipular las DLL que programaran la comunicacin con el lector, fue necesario hacer una adaptacin de dichas DLL ya que fueron creadas en Visual C++. (Vase: Utilizacin 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 creacin de llaves pblicas y privadas para la transportacin de informacin en la red de forma ms segura. Este control de la tarjeta se realiza tambin, a travs del software de aplicacin desarrollado en este trabajo.

48

3.1.2.

TARJETA INTELIGENTE "CRYPTOFLEX"

Los principales usos de la tarjeta Criptoflex se pueden clasificar como:


Primera opcin, correo electrnico y acceso a redes Segunda opcin, comercio electrnico y aplicaciones de consumo a travs de WWW (World Wide Web)

Las caractersticas de la tarjeta se clasifican en 4 partes: 1: 2: 3: 4: Caractersticas fsicas Dimensiones y localizacin de los contactos Seales electrnicas y protocolos de transmisin Comandos de intercambio industrial

Interfaz Externa de la Cryptoflex Caractersticas elctricas: La tarjeta Cryptoflex es capaz de soportar hasta ocho contactos, pero slo seis de ellos son utilizados. Sus caractersticas cumplen con las establecidas en la norma ISO/DIS 7816-2. El voltaje de alimentacin para el contacto Vcc es de 5Volts c.c. +/- 0.5Vcc. Mximo consumo de corriente: 5 mA a 5 Mhz. Interfaz de comunicacin La interfaz mantiene comunicacin entre el lector y la tarjeta. La comunicacin se basa en el estndar ISO protocolo T=0. Se transmite a 372 Baudios y el formato de la trama de transmisin es sin bit de paridad. La tarjeta Cryptoflex es compatible con los estndares ISO7816 en la identificacin 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 coleccin de comandos que permiten a la tarjeta responder a instrucciones que provienen del exterior.

49 La relacin bsica 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 enva 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 mscara de la tarjeta o distribucin del software interno est compuesta por cuatro capas que partiendo del ncleo son: 1. Funciones del sistema operativo bsico: Direccionamiento Parmetros de entrada/salida Parmetros 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 criptografa (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 cdigo especfico de la aplicacin 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 pblicas y privadas que se utilizan en el encriptamiento y desencriptamiento de la informacin. 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. RAM : Read Access Memory

19

50 microprocesador con funciones criptogrficas y un rbol de directorios que tienen un directorio raz, root y se extienden hasta 3 niveles ms.

Fig. 3.4: Descripcin 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 PREPARACIN E INICIACIN DE PARMETROS DE LA TI En la personalizacin se debe tener en cuenta que hay que configurar a la TI, configurndola con comandos bsicos, hay que crear los directorios de archivos y de llaves, los cuales tienen que formarse en una tarjeta virgen. A continuacin se presentan algunas lneas de cdigo de personalizacin que pueden hacerse con la ayuda de comandos ISO o con algunos programas especialmente creados para personalizacin 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_Rev 25.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 personalizacin que consiste en cargar la llave de transporte que es propietaria de cada nmero de serie de tarjeta. Vase figura 3.5.

Fig. 3.5: Personalizacin de la TI Una vez configurada la TI con los parmetros 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 raz "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 nmero de serie del circuito integrado de la TI como se muestra en la figura 3.6.
Raz 3F00

Llaves externas 0011

Nmero Serie 0002

Fig. 3.6: Archivos de la TI antes de personalizacin

53 Despus de la personalizacin el sistema de archivos de la tarjeta queda como se indica en la figura 3.7.

Raiz 3F00 ___________

Llaves externas 0011

No. Serie 0002

CHV 0000

3F11

0005

Fig. 3.7: Archivos de la TI despus de la personalizacin

En este punto se han creando directorios nuevos para el almacenado de llaves pblicas y privadas que se utilizan en el encriptamiento y desencriptamiento de informacin dentro de la aplicacin desarrollada.

3.1.3.

INSTRUCCIONES DE LAS TI

Formato para enviar los comandos a la tarjeta Cryptoflex El estndar 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:: Identificador (Ins): P1, P2, P3: Datos: SW1, SW2: el tipo de instruccin identificador de la instruccin parmetros informacin a ser procesada 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.

54

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

3.1.4.

SOFTWARE PARA EL DESARROLLO DE LA APLICACIN

No es necesario tener en el equipo de cmputo hardware muy sofisticado, basta que cuente con espacio suficiente en memoria para almacenar las aplicaciones y las componentes DLL que controlan al lector adems de tener puerto serial instalado como ya se haba comentado anteriormente. Las caractersticas que exigen mayores recursos son las requeridas por el sistema de desarrollo y programacin 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. Adems del software para desarrollar la aplicacin, 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 libreras varan 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 ms ventajas al usar las DLL en C++, a menos que s est utilizando una versin 1.0 que slo contiene funciones de C para el acceso a la tarjeta.

55 Las versiones ms actuales contienen objetos de TI que pueden ser integrados por los programadores en un ambiente orientado a objetos, haciendo la plataforma ms amigable y general. En la versin 2.0 del CardDLL se tiene una integracin de dos DLL, las de la TI, API DLL y del lector Schlumberger API DLL. CardDLL versin 2 puede ser utilizado para cualquier aplicacin soportada por el estndar 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 opcin es utilizar el paquete de DLL SLBreader. A continuacin se muestra un diagrama de cmo estn distribuidos los niveles del software y las DLL. Vase 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 ms general el desarrollo y no cerrarlo a una sola plataforma o sistema operativo, de esta forma, se logra que el software pueda adaptarse ms fcilmente a otros sistemas operativos. A continuacin 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 libreras que soportan dichas funciones. Para llamar a la funcin DLL desde Builder hay que abrir el men que tiene la opcin Project/ Add to Project. Despus 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 cdigo que llama a la funcin de la DLL. Se muestran a continuacin dos cdigos: el A y el B los cuales sirven como ejemplo de DLL. Tomando en cuenta que el cdigo contiene dos convenciones de llamada: (_stdcall y _cdecl). Cuando se intenta compilar una DLL que fue compilada con Visual C++, la mayora de los problemas resulta de los desacuerdos en las convenciones para la llamada de dichas DLL. Tambin hay que tomar en cuenta que una funcin no necesariamente contiene la convencin de llamada que ella utiliza. Esta funcin desconocida actuar como una etiqueta para las funciones de las DLL que no contienen su convencin 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 opcin File/New. Se selecciona el icono de la DLL y se presiona el botn que indica OK. Builder crear un nuevo proyecto con un slo archivo origen. Este archivo contendr una funcin de entrada de la DLL y algunas oraciones que corresponden a los #include. Despus 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 cdigo 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 despus se compila, Builder generar la DLL y una librera de importacin con extensin 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 funcin prototipo Una librera de importacin 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 salvndolo en el disco duro. Se copia la DLL, la librera de importacin y el archivo de cabecera DLL.H en el nuevo proyecto creado, se selecciona la opcin Project| Add To Project y se agrega el archivo LIB. Despus hay que agregar la oracin de #include en la unidad principal que incluye a la DLL.H. Finalmente se agrega el cdigo 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 debera 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, estn en desacuerdo en los formatos de los archivos OBJ y en las libreras de importacin. Es posible agregar una librera de importacin de Microsoft para utilizarla en un proyecto de Builder C++. Gracias a la librera de Borland C++ IMPLIB las diferencias en los formatos de los archivos se pueden superar. Cada funcin 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 ejecucin. El compilador indicar un error externo en caso de que no pueda encontrar una funcin solicitada a travs de nombre de liga y que se entiende utiliza el programa. Los dos productos tambin 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 exportacin con _stdcall, mientras que Builder C++ espera que las funciones de exportacin sean nombradas como _cdecl. Entonces esto produce una inconsistencia en la convencin para llamar a a_stdcall. Si se crea una DLL con Visual C++ que contenga una llamada _stdcall a una funcin nombrada como MiFuncion(), Visual C++ le dar un nombre de liga de funcin similar a _MiFuncion@4. Cuando el compilador de Borland intente hacer la liga a la funcin, no encontrar el nombre que espera para MiFuncion, entonces la librera de importacin para la DLL de Visual C++ no

59 contiene ninguna llamada a funcin 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 funcin 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 continuacin: _declspec(dllimport) void CALLING_CONVENTION MiFuncion(int Nang); La funcin CALLING_CONVENTION podra 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 convencin 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 convencin 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 conversin de llamada es ms tardado. La lnea 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 informacin sobre la DLL, sin embargo slo hay que observar las funciones exportadas por la DLL. El comando --ee en la instruccin TDUMP muestra slo la informacin de exportacin. Si la DLL es larga, lo ms recomendable es redireccionar la salida de la informacin de TDUMP a un archivo, para despus verlo utilizando un procesador de palabras. La salida de la instruccin TDUMP para el ejemplo del listado A y B se muestra a continuacin: Turbo Dump Versin 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 guin bajo y la terminacin @4 en la funcin _stdcall. La funcin _cedcl y la funcin desconocida no contiene convencin de llamada adicional. Si la DLL de Visual C++ ha sido compilada con un archivo DEF las convenciones de llamada extras no deberan aparecer en la funcin _stdcall.

60 Paso 3. Generar una librera de importacin para una DLL de Visual C++: Debido a las diferencias de formato entre las libreras de Borland C++ y Visual C++, no es posible agregar una librera de importacin creada con Visual C++ en un proyecto de Builder C++. Se debe de crear una librera de importacin OMF usando las lneas de comando de Builder C++. Dependiendo de que se encontr en los pasos anteriores 1 y 2 el proceso de conversin vara pudiendo ser muy sencillo o uno que tome ms tiempo realizarlo como el caso encontrado en este trabajo. Dependiendo de las diferencias en la convencin para llamar a las funciones dentro de las DLL se debe de seguir la tabla que se muestra a continuacin como gua para la conversin.

Convenciones de llamada para funciones en Visual C++ y C++ Builder Convencin de llamada nombre VC++ VC++ (usando DEF) Builder ----------------------------------------------------------------------__stdcall _MiFuncion@4 MiFuncion MiFuncion __cdecl MiFuncion MiFuncion _MiFuncion Tabla 3.1.

C++

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 conversin. En adelante es necesario crear una librera de importacin que haga la equivalencia de los nombres creados para Visual C++ hacindolos 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 librera de importacin. Caso 1: Cuando la DLL slo 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 convencin de llamada de las libreras. El archivo de encabezado indica si la convencin de llamada de __stdcall fue utilizada o no (paso1) y la funcin TDUM indica si la funcin contiene la convencin de llamada adicional de Visual C++. (paso 2). Si la DLL contiene la funcin __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 librera de importacin aplicando la librera 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 librera de importacin 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 funcin __stdcall con suplemento de Visual C++ Si el proveedor de las DLL es inflexible cuando se trata de crear DLL que estn compiladas de forma independiente, es muy probable que se caiga en el caso numero 1. Desdichadamente lo ms probable es que se caiga en el caso 1 por diferentes razones:

La primera es, si la convencin de llamada por defecto es __cdecl y el programador de la DLL omite una convencin de llamada con funciones prototipo, esto forzara a caer en el caso 2. La segunda razn es que si se ha utilizado la convencin 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 estaramos hablando de que se cae nuevamente en el caso 2 con un nombre de funcin que no es compatible con Builder C++. La nica forma de salir de este problema, es creando una librera de importacin que renombre las funciones de Visual C++ dentro de un formato compatible con Borland C++. Esto se logra utilizando la lnea de comandos de herramientas "tools" siguiendo como primer paso la creacin 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 continuacin: IMPDEF (destination DEF file) (source DLL file). Por ejemplo: IMPDEF midll.def midll.dll Despus de correr el programa de IMPDEF, se puede observar abrindolo 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 funcin 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 continuacin. 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 librera de importacin a partir del archivo DEF renombrado, es utilizar una vez mas la librera IMPLIB, con la excepcin 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 librera de importacin hay que ir al paso 4 pero antes hay que examinar la librera de importacin creada para asegurar que cada funcin de la DLL aparece nombrada con el formato que Builder C++ utiliza. Para inspeccionar la librera de importacin 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 librera de importacin al proyecto Una vez creada la librera de importacin para la DLL de Visual C++ se puede agregar la librera de importacin al proyecto de Builder C++ utilizando la opcin del men Project | Add to Project. Hay que utilizar la librera de importacin sin tomar en cuenta el hecho de que contenga sobrenombres o no. Despus de agregar la librera de importacin 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 parmetros de inicio, para esto se utiliz un programa de personalizacin 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 fbrica. 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.

PROGRAMACIN DE LA APLICACIN

Como ya se explic anteriormente la aplicacin consiste en la elaboracin 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 conexin del lector de tarjetas, para esto, se hizo una comunicacin con el puerto serial de la PC, de esta forma se comprob la interaccin del lector y la tarjeta (ya configurada) por una parte y el lector con la PC por la otra. Bsicamente 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 cdigo del Anexo B, muestra una de las primeras versiones de la programacin desarrollada incluyendo algunos de los comandos del lector de tarjetas y las funciones de las DLL que se utilizan para que el lector enve instrucciones a la TI. Para que el programa serial funcione correctamente se deben de considerar los segmentos de cdigo *.h que se incluyen con las instrucciones #includes, de la aplicacin.

64 3.2.1. MDULO PRINCIPAL

El programa se divide en mdulos, 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 nmero de identificacin de la tarjeta y el NIP tecleado por el usuario. Los mdulos del programa son: El mdulo principal es el de encriptamiento y desencriptamiento que contempla los siguientes aspectos, los llamados de llave secreta y los de llave pblica, esquemas generalmente utilizados para la seguridad en redes de datos. Tambin aqu el programa ejecuta automticamente la instruccin para que la TI genere la llave de sesin. En los sistemas de llave secreta simtrica, tanto el receptor como el transmisor utilizan la misma llave para encriptar y desencriptar la informacin como se mencion en captulos anteriores. El buen manejo de las llaves en este mtodo 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 pblica asimtrico siguen existiendo dos llaves pero una es secreta llamada la llave privada y la otra es la llave pblica, las llaves no son las mismas pero estn relacionadas matemticamente entre s. La llave privada que es guardada en secreto por el propietario, no puede ser determinada utilizando la llave pblica, esta ltima es distribuida a las partes con las que se desea establecer comunicacin segura. La solucin de seguridad ms apropiada con TI es utilizar una combinacin de las tcnicas de llave pblica y llave secreta. Los clculos de la llave secreta utilizando el algoritmo DES son mucho ms rpidos debido a la longitud de la llave utilizada (64 bits), que los clculos de la llave pblica utilizando el algoritmo del RSA de (1024 bits). Para incrementar la seguridad del sistema se utiliza una funcin que tienen las TI para generar llaves secretas a partir de la llave secreta principal, la cual est relacionada con el nmero de serie de la tarjeta y con una llave secreta nica asignada por el fabricante (tambin conocida como llave de transporte) al momento de su creacin. Cuando se hace uso del generador de llaves de la TI lo que sucede es que se crea una nueva llave aleatoria que es funcin de la llave secreta original nombrada como llave de sesin ya que se utiliza slo una vez por sesin. La llave de sesin 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 enva un mensaje. Esta misma llave secreta de sesin es encriptada utilizando la llave pblica 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 pblica. El desencriptamiento consiste en tomar la llave que viene del transmisor desencriptndola con la llave privada y el algoritmo RSA. En este momento la llave de sesin es revelada al lado receptor y con ella se puede aplicar la desencripcin del mensaje original que estencriptado 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 slo se utiliza en esa sesin en particular y que sta a su vez se reemplaza por la siguiente llave de sesin. Con

65 la llave de sesin encripta el archivo plano con DES y se encripta esta misma llave a su vez con RSA utilizando la llave pblica. Para el caso de la aplicacin desarrollada, se tiene el mismo procedimiento de la generacin de llave de sesin descrito en el prrafo anterior con la adaptacin de que se generan 2 llaves de sesin (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 ms detalle en la descripcin de la aplicacin seccin 3.3..

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

66 La idea global del mdulo principal es el integrar los archivos que contienen la informacin dentro de la tarjeta, procesarla y comunicar esta informacin encriptada hacia la PC, posteriormente para ser reenviada a la aplicacin que trabaja dentro de la PC y viceversa. Vase la figura 3.11.

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

67 3.2.2. DIAGRAMA DE FLUJO GENERAL DE LA APLICACIN

En la figura 3.12, se muestra el diagrama de flujo descriptivo de la aplicacin desarrollada. Con este diagrama de flujo se ilustra en trminos generales como fue diseada la aplicacin. Para la entrada del mdulo principal se tiene una pantalla que solicita la introduccin 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 grfica al usuario.
INICIO

*AUTENTIFICACION

LEER (ID) DE LA TARJETA (TI)

ID OK?

No

Salida E:01

Yes

CAPTURAR NIP TECLEAR (4 DIG ITO S)

No

CONT_NIP =3?

Yes

Yes

NIP OK?

No

CONT_NIP+1;

MENU DE ENTRADA

Salida E:02
OPCIONES

ENC R IPT AM IEN T O

DESENC R IPT AMIEN T O

MANEJO DE ARCHIVOS

Fig. 3.12: Diagrama de flujo de la aplicacin

68

Creacin de los mens para el manejo de archivos y edicin de ventanas de Windows para poder integrarlos a la aplicacin.

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

En el Anexo C se muestra un fragmento de los cdigos para el desarrollo de las pantallas del men principal de la aplicacin.

69

3.3.

DESCRIPCIN DE LA APLICACIN

Para analizar el desarrollo paso a paso de cmo funciona la aplicacin para la seguridad de la informacin 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 informacin que va desde una computadora conectada a un punto de una red TCP/IP a otro extremo con otro sistema de cmputo conectado. Vase la figura 3.14.
Archivo original de forma segura

Archivo plano

Encriptamiento del archivo plano

T ransmisin del archivo ya encriptado

Recepcin del archivo encriptado

Proceso de
desencriptam iento

Etapa 1

Etapa 2

Etapa 3

Fig. 3.14: Etapas que describen el proceso de la aplicacin 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 algn procedimiento de encriptamiento. Este archivo plano se tiene almacenado en una unidad lgica de una PC y que para fines prcticos se considera que el archivo se encuentra almacenado en el disco duro de la PC. Antes de enviarlo a otro punto de la red entindase como otro punto, otra computadora conectada a la red, se aplicarn dos algoritmos de encriptamiento de la siguiente forma. Etapa 1.1 Como ya se explic en captulos anteriores se cuenta con un lector de TI conectado al puerto serial de la PC origen, el cual se conecta con DLL previamente diseadas y que cuyo control se encuentra dentro del mdulo principal programado. En dicho lector hay que introducir la TI al momento que la aplicacin ha iniciado el proceso y lo solicita a travs de la interfaz grfica construida con ventanas de Windows. La pantalla que se muestra en la figura. 3.15 corresponde a la solicitud de insercin de la TI en el lector.

Fig. 3.15: Pantalla de insercin de TI en el lector

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 aplicacin que indica cuando hubo un error en el tecleo del NIP o en la insercin 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 cdigos que contienen los parmetros 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 libreras. Recientemente las libreras de los distintos fabricantes de tarjetas estn siendo diseadas para trabajar en ambientes de C++ orientados a objetos a diferencia de los primeros desarrollos que slo 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. Vase la seccin para la conversin 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 aplicacin o no. Hasta este momento se ha explicado como se utiliza la tarjeta para poder entrar a la aplicacin. La pantalla que se muestra en la figura 3.17 solicita que se teclee el nmero de 4 dgitos que permite la entrada a la aplicacin.

Fig. 3.17: Pantalla de solicitud para teclear el NIP

71 Cuando se solicita el acceso a la aplicacin se tiene que insertar la TI y teclear el cdigo de seguridad de 4 dgitos y en caso de que no se inserte la tarjeta o se teclee mal el PIN se ejecuta el siguiente cdigo que muestra al usuario que el acceso ha sido negado. Vase el Anexo C.

Etapa 1.2 En esta etapa ya se tiene el acceso a la interfaz grfica para poder aplicar los algoritmos de encriptamiento y por lo tanto, ya se garantiz la autenticidad de la persona que va a utilizar la aplicacin.

Etapa 1.3 En esta etapa 1.3 el primer paso es seleccionar el archivo a encriptar a travs de los mens de la aplicacin, 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 aplicacin donde se selecciona el archivo a ser encriptado.

Fig. 3.18: Seleccin de archivo a ser encriptado

72 Una vez que se seleccion el archivo a encriptar se debe de presionar el botn de Encriptar. Cuando se activa el botn Encriptar del men principal se realizan los procesos de encriptamiento y se despliega la pantalla que a continuacin 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 sesin (S1) generada por la TI y encriptar el archivo seleccionado con DES el resultado es el archivo (AE), despus se genera la llave de sesin (S2) para aplicar DES-1 al archivo (AE) y el resultado es (AE2), por ltimo se utiliza la llave de sesin (S1), para aplicar el DES a (AE2) y el resultado es el 3DES aplicado al archivo que resulta ser (AE2) y ste se enva por la red. Posteriormente se encriptan las llaves de sesin (S1) y (S2) con la llave pblica correspondiente al algoritmo RSA y se envan por la red al destinatario. Etapa 1.4 El encriptar el nmero 1 que se encuentra dentro de un archivo de WinWord con la combinacin de ambas llaves (S1, S2), nos dar como resultado aproximadamente un archivo de 542 lneas de caracteres irreconocibles, si los visualizramos en cualquier analizador de archivos o procesador de palabras se vera un fragmento como se muestra en la figura 3.20.
C756194618175C5C92034C134D42090999EB6C9A0FECB68DA9942D36FB2BE57A8185B8558A75F46F7E6F57246A43726EA6BA 22AD871CDCAFE86527628C85A93D1F636EECEC427711F9C0E2513EBB5797EF4F71CC640D380F9A325D85692288D1EC79B48 8870EEC316FAA16CEDC6EB1982FE43492861560BDCC2F10A95E50F7D765BB35D384CE2BC9A5593E7C23F710BD 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?@jt 'P'H_0l> m:6Gen>Q_M_{_/-P-(_-F! _, >{uP_m_0 L_ wn C _A"-n%"S^D_xw[/b/[x__q0t3kt__usxpkSWGI ZiR_ qT %__S_kq) _>9fI_ qk Y5.^_wZBE'h 8 ?uX-!x ( )__O_ ^ ;_T] f___| {U__`)bn\ZTB^_G#?|-W'SAi__:lp_} ci_ xC}8_1Y__u, x8 _ lh * __[__$I;o_MxSHwj !T /X ) >_W _S|:_$hA__vl_x}_' _5YA(,j}rkoItCSH_k 4} 6_ M_ __+q..............................

Fig. 3.20: Fragmento de 16 lneas del encriptamiento del nmero 1 visto en Winword

73 La 3.21, muestra dos ventanas que corresponden a la edicin 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 despus 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 sera 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 aplicacin con una extensin *.SPDX este archivo ya no es recuperable, a menos que se cuente con la llave para poderlo desencriptar utilizando los mtodos ya estudiados. Vase la figura 3.22.

Fig. 3.22: Pantalla del men de encriptamiento y desencriptamiento

74 Para la transmisin del mensaje encriptado es necesario presionar el botn de Enviar. Este botn 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 an analizndolo a los niveles bsicos como sera del anlisis de bit a bit. Ya que el propsito de este trabajo es hablar de un mtodo 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 creacin de interfaces para poder aprovechar los beneficios de una comunicacin segura utilizando TI. Para poder entender el cmo 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 travs 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 continuacin 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 despus pudiera ser comparado con el archivo que se envi encriptado. En la parte inferior derecha, hay un crculo que nos muestra el contenido del archivo plano a travs del analizador de protocolos.

Fig. 3.23: Archivo plano observado con analizador de protocolos al ser enviado A continuacin se muestra el mismo mensaje encriptado con la aplicacin 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 seccin de criptografa. 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 ocasin se enva el archivo ya encriptado el cual viaja de forma segura a travs 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 explicacin del funcionamiento de la aplicacin es necesario considerar que el archivo una vez encriptado y estando en el otro extremo de la transmisin, (nodo remoto), requiere de los procesos de desencriptamiento para poder ser utilizado como era originalmente. La aplicacin hace uso del mismo men principal para activar las funciones de desencriptamiento cuando se presiona el botn "Des_encriptar".

76

3.4.

RESULTADOS Y COMENTARIOS

Una de las partes crticas del proyecto es el tener la seleccin 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 aplicacin o modificar la forma en la que se desarrolle la aplicacin. En el caso de la tarjeta Cryptoflex se tiene una distribucin 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 aplicacin, por ejemplo; si se quiere hacer una instruccin de escritura se tiene el descriptor para dicho comando que implica un bit de clase, uno ms de la instruccin en s, 3 bits de parmetros y de datos. De acuerdo a la norma ISO7816 se tiene definida una comunicacin serial entre el lector y la tarjeta de forma asncrona para una TI y una sncrona para el manejo de las tarjetas de memoria (sin microprocesador). En nuestro caso es el asncrono y se utilizan bloques de informacin que son transmitidos en una comunicacin serial sin la necesidad de tener un control de tiempo. Al ser asncrona la comunicacin de las diversas aplicaciones creadas en la TI, son ms independientes. Como se analiz en los captulos anteriores es un proyecto de integracin 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 cmputo PC, tipos de software como es el sistema operativo de la PC, Windows, el lenguaje de programacin de ANSI C y Builder C++ para crear la aplicacin, las libreras de control DLL del lector y de las TI, conocimientos de cmo aplicar el encriptamiento de datos utilizando DES, 3DES, RSA y transmisin de datos a travs de redes de computadoras utilizando los protocolos de TCP/IP. Finalmente utilizando un analizador de protocolos se hizo la observacin de los resultados de las tramas encriptadas enviadas por una red comparndolas con tramas planas es decir sin encriptamiento. Para lograr el objetivo se utiliz un mtodo compuesto por software y hardware como lo es la solucin con TI. Este mtodo se complement con la combinacin de dos algoritmos de encriptamiento RSA y 3DES. En la programacin de la tarjeta hay que considerar su configuracin inicial, programacin de la aplicacin interna y su uso, adaptndola a la interfaz grfica de la PC.

77

3.5.

CONCLUSIONES DEL CAPTULO

En el presente trabajo se utilizan mtodos criptogrficos 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 mnimo de computadora el cual puede ser programado para alguna aplicacin especfica y deja en la creatividad del programador su utilidad prctica. El hecho de que la TI trabaje independientemente del sistema generador de la informacin a transmitir, mejora la seguridad ya que contrarresta los ataques de intrusos que intentan violar la integridad y confidencialidad de un sistema utilizando los mtodos 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, adems de direcciones lgicas y una creacin dinmica de archivos. El lector de TI trabaja con el puerto serial RS-232 de la computadora y es la interfaz entre el equipo de cmputo y la TI. Otro punto digno de mencin es el hecho de buscar una plataforma que no pierda generalidad y pueda emigrar fcilmente de un sistema a otro, por este detalle se tuvo la necesidad de hacer algunas modificaciones al cdigo de tal forma que pudieran trabajar en un ambiente no propietario de MicrosoftTM. Se utilizaron las DLL creadas para Borland C++ para hacer ms general el desarrollo y no cerrarlo a una sola plataforma o sistema operativo. En la personalizacin de las TI se configura inicialmente con comandos bsicos 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 aplicacin del "lado de la tarjeta". Como ya se explic anteriormente la aplicacin del "lado del servidor" consiste en la elaboracin 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 mdulos, 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 nmero de identificacin de la tarjeta y el NIP tecleado por el usuario.

78

4. CONCLUSIONES
El proyecto, puede llegar a desarrollarse partiendo de una base prctica y posteriormente ir incrementando el grado de seguridad adquirido con la ayuda de algoritmos de encriptamiento ms complejos. El incremento en la seguridad consiste en utilizar dos mtodos criptogrficos 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 porttil y de uso personal. Segn la clasificacin de seguridad que se present anteriormente, la aplicacin desarrollada no puede demostrar su integridad tericamente por ser una combinacin de mtodos o algoritmos de encriptamiento pero este tipo de sistemas en la prctica son extremadamente seguros y segn la informacin investigada no han sido violados. Vese: Seguridad probable y seguridad computacional, pgina 30, la cual nos dice que un sistema podra ser vulnerado pero en tiempos que no permitiran al intruso obtener provecho de la informacin transmitida. Por otra parte, el utilizar una tecnologa de gran uso como sera las redes de TCP/IP implica el uso de nuevas tecnologas como las TI, creadas exclusivamente para aplicaciones de seguridad gracias a que su criptoprocesador es capaz de almacenar y generar llaves pblicas, 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 mtodos de encriptamiento haciendo la plataforma mucho ms robusta, el segundo es el apoyarse en hardware externo a la plataforma utilizada, esto evita el acceso al sistema por mtodos de falla. Sin duda los mtodos utilizados pudieran ser mejorados en un futuro prximo ya que los sistemas de TI y su acoplamiento a las redes de datos se estn desarrollando rpidamente, sin embargo por el momento podemos afirmar que lo que se presenta en este trabajo es un mtodo 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 aplicacin a otros ambientes de trabajo utilizando otro diseo o tipo de lector o TI.

79

5. BIBLIOGRAFA
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] WILLIAM STALINGS, Network Security Essencials: Aplications And Standa Hall, UK 2000 S. C. COUTINHO, The Mathematics of Ciphers A K Peters Natick, Massachusetts 1999 DORASWAMY N., HARKINS D, The New Security Standard for the Internet, Intranets, and Virtual Private Networks , Prentice Hall, USA 1999 KENT REISDORPH, Aprendiendo Borland C++ Builder, Prentice Hall Hispanoamericana, Espaa, 1999 JOS A. CARBALLAR, El libro de las comunicaciones del PC, Alfaomega, Mxico 1997 SCHNEIER B, Applied cryptography: protocols, algorithms, and source code in C, John Wiley & Sons. USA 1996 JOS ANTAO BELTRAO MOURA, Redes Locales de Computadoras, McGraw-Hill, Espaa 1991 SCHNEIER B, How to evaluate security technology, Computer Security Journal, USA, 1999 COMER D., Redes Globales de Informacin con Internet y TCP/IP, Prentice Hall, Hispanoamericana, Mxico, 1998 HENRY DREIFUS & TOMAS MONK, Smart Cards, John Wiley & Sons, Inc, Cnada, 1998. AMAPRO FSTER SABATER, Tcnicas criptograficas de proteccin de datos, Alfaomega, Mxico 1998 COTT B. GUTHERY & TIMOTHY M. JURGENSEN, Smart Card Developer's, Macmillian Technical Publishing, USA 1998

80 [13] [14] WILLIAM STALINGS, Comunicaciones y redes de computadores, Prentice Hall, 5 Edicin, Mxico, 1997 KRIS JAMSA, KEN COPE, Programacin en Internet, McGraw-Hill., Mxico, 1996 SCHNEIER, B. WILEY, Cryptography: Protocols, Algorithms, and Source Code Applied in C, Circa printing, 1995 BARRY B. BREY, Los microprocesadores lntel, Prentice Hall, Mxico, 1995. KEVIN STOLTZ, Todo acerca de redes de computacin, Prentice Hall, Mxico, 1995 ANDREW S. TANENBAUM, Redes de Computadoras, Pentice Hall 2. Edicin, Mxico, 1991 LATHI, Sistemas de comunicacin, Interamericano, Mxico 1989 CRISTIAN METAIRIE, Redes Locales "Teoria y Programacin de las redes IBM", Paraninfo, Madrid,1989 STREMLER, Sistemas de comunicacin, Alfaomega, EUA, 1989 Cryptoflex Card Reference Manual, Schlumberger, January 1997 Card DLL Reference manual, Smart Reader Desing Specification, Microsoft corporation, December 1997 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 523538, May 2000. J.-J. QUISQUATER AND C. COUVREUR. Fast decipherment algorithm for RSA public-key cryptosystem. IEE Electronics Letters, 18(21):905907, October 1982 R. RIVEST, A. SHAMIR, AND L. ADLEMAN. A method for obtaining digital signatures and public key cryptosystems. Communications of the ACM, 21(2):120126], February 1978

[15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

[25]

[26]

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 PETER HAMILTON-SCOTT, "The bits.." "the C++ Builder Information & Tutorial Site" http://www.cbuilder.dthomas.co.uk "Using Visual C++ DLLs in a C++Builder Project" http://bcbdev.com/articles/vcdll.htm LAWRIE BROWN, "Introduction to Number Theory" 24 April 1996 http://www1.shore.net/Security-Notes/lectures/publickey.html 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 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 P. ZIMMERMANN, The ECMNET Project: Elliptic Curve Method for Factoring http://www.loria.fr/~zimmerma/records/ecmnet.html 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 Signal Guard, Rijndael/AES Algorithm http://www.signalguard.com/encryption/aes-rijndael.html J. ORLIN GRABBE, "The DES Algorithm Ilustrated" http://www.aci.net/Kalliste/des.htm

[28]

[29] [30] [31]

[32]

[33]

[34]

[35] [36]

82

ANEXO A.

DESARROLLO DE SOCKETS

Los diseadores de la interfaz de sockets originalmente la construyeron dentro del sistema operativo UNIX, pero otros ambientes, como Microsoft Windows, la implementan como bibliotecas de programacin. 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 diseadores 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 funcin 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 informacin como el nombre, el tamao 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 conexin con la red, despus lee y escribe datos a travs de ella y por ltimo, cierra la conexin. Desde una perspectiva UNIX, este enfoque de diseo hace una comunicacin en red como cualquier otra funcin del sistema de E/S, es ms fcil de integrar al sistema operativo UNIX. Socket como Concepto: Podemos pensar en un socket como en una punta o un extremo de la comunicacin por red. Esta involucra dos computadoras o dos procesos que se pasan datos entre s a travs de la red. Cada lado de la comunicacin en red lo llamamos extremo endpoint. Cuando el programa utiliza la Interfaz de sockets para una comunicacin en red, el socket es una representacin abstracta del extremo en el proceso de comunicacin. Para que haya comunicacin

83 en una red, el programa necesita un socket en cada lado que conversa. La conexin puede ser orientada a conexin o sin conexin. El modelo de la interfaz de sockets para la comunicacin en red an emplea al proceso bsico abrir-leer-escribir-cerrar. Cuando necesitamos un socket para una comunicacin en red, definimos sus caractersticas 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 vara de modo significativo. (Mientras un especificador de archivo apunta a un archivo especfico que ya existe o lo hemos creado) o a un dispositivo, un identificador de socket no representa un extremo especfico o una direccin destino. Esta es la diferencia con la mayora de los sistemas de E/S de archivos. En casi todos los sistemas operativos, un identificador de archivo vlido debe apuntar a un archivo especfico 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 aplicacin debe obtener un identificador de archivo vlido del sistema operativo y entonces, como paso aparte, especfica la localizacin del archivo de disco. Consideremos los requerimientos de un programa de red TCP/IP que transmite un datagrama utilizando protocolos sin conexin. El programa especifica la direccin destino del datagrama pero no establece una conexin directa con el anfitrin, sino que transmite el datagrama a la direccin destino. El software de red (la capa IP, especficamente) 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 vlido sin crear una conexin directa con la direccin destino de E/S (el anfitrin de red). En vez de tratar de modificar las funciones de E/S existentes en UNIX, crearon una nueva funcin llamada socket. La funcin socket permite que un programa obtenga un identificador de socket sin especificar la direccin destino. Creacin de un socket Cuando se crea un programa TCP/IP necesitamos las habilidades de los protocolos orientados a conexin y sin conexin. La interfaz de sockets permite a los programas emplear ambos tipos de protocolos a travs de una conexin socket. Para crear un socket, el programa llama a la funcin 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 informacin sobre el socket. Socket_handle= socket (protocol_family, socket_type, protocol) Al crear un socket se deben especificar tres parmetros: la familia de protocolos (protocol_family), el tipo de socket (socket_type) y el protocolo (protocol). El parmetro familia

84 de protocolos identifica a una familia o coleccin de protocolos relacionados, como el conjunto de protocolos TCP/IP. El parmetro tipo de socket especfica si el programa utilizar el socket para transmitir un datagrama20 o un flujo de bytes. El parmetro protocolo identifica al protocolo especfico que quiere ocupar el programa en este caso, TCP. Parmetros de la Funcin Socket Conforme se integraron los protocolos TCP/IP al sistema operativo UNIX, tambin desarrollaron una API de propsito general para mltiples redes, no slo TCP/IP que ejecute UNIX. Aunque al principio se enfocaron a crear una interfaz para TCP/IP, trataron de disear una interfaz de sockets que pudiera usarse en otras redes. Para lograrlo usaron el concepto de familia de protocolos y direcciones. El primer parmetro de la funcin socket (que crea un socket) identifica a una familia de protocolos como el conjunto de protocolos TCP/IP. La funcin socket requiere que el programador identifique el protocolo que utilizan sus programas, la interfaz de sockets puede establecer comunicacin con mltiples redes. La interfaz de sockets utiliza constantes simblicas para identificar las familias de protocolos soportadas. Por ejemplo, la constante simblica PF-INET identifica a la familia de protocolos de Internet (el conjunto de protocolos TCP/IP). Hay otras familias que tambin 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 estn muy relacionadas con las familias de protocolos, como sabemos el formato de direcciones de red vara de una red a otra. Los diseadores de la interfaz de sockets reconocieron este hecho y utilizaron el concepto de familias de direcciones para generalizar el uso de esa interfaz en mltiples redes. Las familias de direcciones ocupan el prefijo AF_similar al de las familias de protocolos. Por ejemplo, la constante simblica 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 programacin indican que utilice cualquiera de esas constantes, pues las dos representan al mismo valor. No obstante, la distincin entre familias de protocolos y direcciones permite a los programadores utilizar protocolos de red que tengan mltiples 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 slo formato de direccin. Tal flexibilidad no es de gran valor para los programadores de Internet, pues los protocolos TCP/IP emplean un slo formato de direccin, pero el hecho de que exista demuestra el cuidado y la planeacin que se tuvo en el diseo de la interfaz de sockets.

20

Datagrama : Agrupamiento lgico de informacin enviado como unidad de capa de red a travs de un soporte de transmisin sin el establecimiento

previo de un circuito virtual.

85 Hoy da, 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 cdigo ser ms claro y ms fcil de migrar cuando sea necesario. Especificacin de Tipo de Comunicacin TCP/IP permite a sus programas utilizar comunicaciones de red orientadas a conexin y sin conexin. En la comunicacin de red orientada a conexin los datos viajan como una cadena de bytes (flujo de bytes) sencilla y serial sin registro y sin otro tipo de limitaciones. En la comunicacin de red sin conexin los paquetes viajan en paquetes separados e individuales, llamados datagramas. El segundo parmetro requerido por la funcin socket especifica qu tipo de comunicacin desea utilizar. La interfaz de sockets emplea la constante simblica SOCK_DGRAM para datagramas y SOCK_STREAM para flujo de bytes. Dicha interfaz tambin define un tercer tipo de comunicacin llamada socket bsico raw socket SOCK_RAW. Este tipo de socket permite a un programa utilizar los mismos protocolos de nivel inferior que la red utiliza comnmente. En general un programa de aplicacin 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 mdulos 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 bsico. Seleccin de un Protocolo El conjunto de protocolos TCP/IP incluye algunos protocolos, como IP, ICMP, TCP y UDP. Asimismo otras familias de protocolos proporcionan mltiples protocolos que los programadores pueden utilizar. El tercer parmetro de la funcin socket permite especificar cul protocolo se usar en el socket. Al igual que en los dems parmetros de la funcin socket, puede utilizar constantes simblicas para especificar el protocolo. Para redes TCP/IP, las constantes simblicas para los protocolos empiezan con el prefijo IPPROTO_. Por ejemplo, para especificar el protocolo TCP debe usar IPROTO_TCP como tercer parmetro del socket. La constante simblica IPPROTO_UDP especifica el protocolo UDP. La siguiente instruccin muestra una llamada comn a una funcin socket: socket_handle = socket (PF_INET; SOCK_STREAM, IPPROTO_TCP); Esta instruccin indica a la implementacin del socket que el programa utiliza la familia de protocolos Internet (PF_INET). Tambin le dice que utilizar el protocolo TCP(IPROTO_TCP) para comunicacin por flujo de bytes (SOCK_STREAM) por el socket solicitado. El Proceso Tenemos claro que un socket representa un extremo en la comunicacin por red, al igual que un socket identifica a un registro en la tabla de descripcin 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 funcin socket para crear un socket. Se puede crear un socket sin especificar una direccin de red. Por ejemplo, la siguiente llamada a funcin socket especifica una familia de protocolos, un tipo de socket y un protocolo especficono especifica una direccin de red: socket _ handle = socket ( protocol_family, socket_type, protocol); Un socket puede ser un extremo de la comunicacin en red aunque no incluya una direccin. Descriptor de Socket Cuando llamamos a la funcin socket, la implementacin del socket lo crea y devuelve un identificador de socket (o descriptor) que, en realidad, identifica a un registro en la tabla de descripcin. La implementacin del socket maneja esta tabla por s mismo. Como programador de aplicaciones, el nico acceso a la tabla de descripcin es a travs 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 parmetros de la funcin socket. Sin embargo, tambin contiene elementos para cuatro direcciones: IP local, IP remota; puerto local y puerto remoto. Cada vez que el programa llama a la funcin socket, la implementacin del socket reserva memoria para una nueva estructura de datos y almacena la direccin de la familia, el tipo de socket y el protocolo. En la tabla de descripcin de archivos la implementacin del socket guarda un

87 apuntador para la estructura de datos. El identificador que recibe el programa de la funcin socket es un ndice dentro de la tabla de descripcin. La interfaz de sockets no especfica cmo 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, ms all de los descriptores de sockets, los detalles dependen de la implementacin. Como programador de aplicaciones no es necesario preocuparse por detalles como tablas descriptoras, estructuras de datos internas y lo relacionado con la asignacin de memoria. El propsito de explicar estos detalles es mostrar cmo un socket almacena las direcciones de red. La funcin socket crea la estructura de datos del socket pero deja vacos los elementos para las direcciones. Para asociar un socket con direcciones de red especficas es necesario llamar a otras funciones dentro de la API de sockets Cmo usar el paradigma de sockets El paradigma (o modelo) de la interfaz de sockets para las comunicaciones de red se refiere a la comunicacin entre computadoras anfitrin o procesos como extremos. Cada conversacin en la red incluye dos extremos: el anfitrin local y el remoto (o destino). La interfaz de sockets denomina a cada extremo de la conversacin en la red socket. Tambin sabe que la mayora de los programas utilizan el modelo cliente/servidor. Las comunicaciones de red en el modelo cliente/servidor tambin incluyen dos extremos. No obstante, el modelo cliente/servidor hace una distincin entre los extremos de la funcin 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 direccin Internet para identificar las computadoras anfitrin, por lo tanto cada anfitrin en Internet requiere de una direccin nica en esa red. La capa de transporte utiliza puertos de protocolos para identificar aplicaciones especficas (procesos) en cada anfitrin. As, cada proceso relacionado con la red en una computadora anfitrin emplea un puerto de protocolo (que es como un identificador de tareas) como direccin. Los programas de Internet deben utilizar el protocolo TCP/IP para transferir datos a esa red. En suma, una conexin de red entre dos programas incluye cinco elementos de informacin: Un puerto de protocolo local que especfica donde recibe mensajes o datagramas un programa o proceso. La direccin del anfitrin local, lo cual identifica al anfitrin que recibir los paquetes de datos. Un puerto de protocolo remoto que identifica al programa o proceso destino. La direccin del anfitrin remoto, que identifica al anfitrin destino. Un protocolo, que define cmo los programas transfieren datos a travs de la red.

La estructura de datos del socket incluye todos los elementos de informacin que requiere un extremo para la comunicacin en red. Cuando un programa quiere comunicarse con otro, el programa emisor transmite la informacin 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 informacin al socket, debe llamar a la funcin socket para crearlo y entonces utilizar otras funciones de la interfaz de sockets para configurarlo. Definicin del uso de socket en el programa El programa debe configurar un socket antes de utilizarlo para comunicarse en la red. Pero lo ms 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 anfitrin local y del remoto. Por lo tanto, el trmino de las direcciones del socket se refiere no a la direccin del socket en s, sino a las direcciones del puerto de protocolo y del anfitrin almacenadas en la estructura de datos interna. Cuando se crea un socket con la funcin socket, no se especifica la direccin del puerto de protocolo ni la del anfitrin, sino que utiliza diferentes funciones de la API para almacenar las direcciones del socket y otras opciones de configuracin, dependiendo de cmo el programa intenta utilizar el socket. Por ejemplo, si el programa utiliza el socket como puerto servidor, llamar a la funcin que especifica el uso de protocolo local. A la inversa, si el programa acta como cliente en la red, probablemente deje que la implementacin del socket asigne cualquier puerto disponible para usarlo cuando de veras requiera utilizar el socket. En otras palabras, la funcin 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 parmetros que se especifican cuando se crea un socket dependen del propsito 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 anfitrin y del puerto del protocolo dependen de cmo el propio programa utilizar el socket: como servidor o como cliente. Configuracin del Socket Por cada programa de red que se escriba, primero se debe crear un socket llamando a la funcin socket. Despus 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 conexin de red requiere cinco elementos de informacin: un protocolo, una direccin IP local; una direccin IP remota; un puerto de protocolo para procesamiento local y un puerto de protocolo para procesamiento remoto.
Uso del socket Cliente orientado a conexin Servidor orientado a conexin Cliente sin conexin Servidor sin conexin informacin local Informacin remota

Una llamada a la funcin conectada almacena la informacin Local y remota en la estructura de datos del socket. bind bind bind listen y accept sendto recvfrom

Funciones de la API de sockets utilizadas para configurar un socket para comunicacin en red. Tabla a

89

Conexin de un Socket Los sockets proporcionan una abstraccin que se puede utilizar para representar y programar los extremos de una conversacin en red. Un protocolo orientado a conexin establece un circuito virtual entre los extremos de la conexin, 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 conexin) establece un circuito virtual (mantiene la conexin abierta) intercambiando mensajes de confirmacin entre los dos extremos. Como resultado, un programa cliente orientado a conexin en una red TCP/IP no se ocupa de la direccin 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 mayora de los casos un programa cliente orientado a conexin no especifica puerto de protocolo local. Un programa cliente orientado a conexin utiliza la funcin connect para configurar un socket de comunicacin en red: La funcin connect almacena informacin en la estructura de datos del socket acerca de los extremos local y remoto. La funcin connect requiere que se especifique un identificador de socket acerca de los extremos local y remoto, una estructura de direccin que contenga informacin sobre el anfitrin remoto y la longitud de la estructura de direccin del socket. La siguiente instruccin muestra una llamada comn a la funcin connect: result = connect (socket_handle, remote_socket_address, address_lenght; Observe que el primer parmetro de la funcin connect, el identificador del Socket(socket_handle), es el valor del descriptor del socket que devolvi la funcin socket. Antes de que el programa pueda utilizar la funcin connect para conectar un socket se debe de llamar a la funcin socket. El identificador del socket indica la implementacin del socket y en qu registro de la tabla de descripcin se debe de usar. En otras palabras, el identificador del socket indica a la implementacin de este donde almacenar la direccin del socket remoto. El segundo parmetro de la funcin socket, la direccin del socket remoto(remote_socket_address) es un apuntador especial a una estructura de la direccin del socket, esta almacena informacin peculiar de la direccin para una red especfica: 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 direccin del anfitrin en la red. La funcin connect almacena esta informacin en un registro de la tabla de descripcin del socket (el primer parmetro de la funcin connect) que reconoce el identificador del socket. Antes de que el programa llame a la funcin connect se debe de almacenar la informacin de la direccin del anfitrin remoto en la estructura de datos del socket, es decir, la funcin connect requiere la direccin IP del anfitrin y el puerto de protocolo. Sin embargo es necesario que se almacenen las direcciones IP locales. La implementacin del socket lo hace de modo automtico y selecciona un puerto de protocolo local. La API de sockets aseguran que la aplicacin reciba los datos que entrega la capa de transporte al puerto de protocolo local. Dicho de otro modo, la

90 implementacin 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 implementacin. El tercer parmetro de la funcin connect. La longitud de la direccin (address_lenght), simplemente indica a la implementacin del socket el tamao, en bytes, de la estructura de datos de la direccin del socket remoto (el segundo parmetro). El contenido y tamao de la estructura de la direccin del anfitrin remoto dependen de la red. El parmetro longitud de la direccin indica a la funcin connect cun grande debe ser la estructura de datos que requiere el anfitrin remoto. Cuando la implementacin del socket responde a la funcin connect, obtiene el nmero de bytes especificado por el parmetro longitud de divisin del buffer de datos apuntado por el parmetro remote_socket_adress (direccin del socket remoto). Especificacin de una direccin local (puerto de protocolo) La funcin connect indica una conexin directa con el anfitrin remoto. El nico momento en el que conectamos un socket al anfitrin remoto es cuando el programa utiliza el socket como un proceso cliente orientado a conexin. Un protocolo sin conexin nunca establece una conexin directa. Un protocolo sin conexin transmite datagramas por la red, tales protocolos nunca usan flujo de bytes. Asimismo un programa servidor nunca inicia una conexin. Aunque se pueden crear programas servidores que utilicen protocolos orientados a conexin, el programa esperar pasivamente en un puerto de protocolo la solicitud de un cliente, el cliente inicia la conexin, no el servidor. La similitud principal que hay que notar entre un programa que utiliza un protocolo sin conexin y un programa servidor que emplea un protocolo orientado a conexin es que ambos tienen que atender a un puerto de protocolo. Asimismo, puesto que un programa cliente sin conexin no establece una conexin directa con el anfitrin remoto, debe atender tambin por un puerto de protocolo para recibir un datagrama en repuesta a su solicitud de servicios de red. La funcin de asignacin de nombres (bind) en la API de sockets permite a un programa asociar una direccin local (combinacin de la direccin del anfitrin y puerto de protocolo) con un socket. La siguiente instruccin muestra una llamada comn a la funcin bind: result = bind(socket_handle, local_socket_address, address_lenght); Cuando se crea un programa servidor se disea para que atienda solicitudes de un cliente, la capa de transporte de TCP/IP se comunica con los programas de aplicacin (digamos, servidores y clientes) a travs 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 especfico. Cuando se emplea la interfaz de sockets para un programa servidor, el programa utiliza la funcin bind para registrar un puerto de protocolo con la implementacin del socket, esto es, el programa indica a la implementacin del socket qu puerto de protocolo debe usar para la entrega de datos. La implementacin 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 conexin debe atender a un puerto de protocolo, los programas que utilizan protocolos sin conexin no establecen conexin directa con el anfitrin remoto. Un programa

91 cliente sin conexin transmite una solicitud de servicio de red utilizando un datagrama, el cual no establece una conexin punto a punto. As el cliente sin conexin debe atender por el puerto de protocolo para esperar el datagrama de respuesta. Al igual que los programas servidores, los programas cliente sin conexin utilizan la funcin bind para registrar el puerto de protocolo con la implementacin del socket. Como un programa servidor, al cliente sin conexin indica a la implementacin del socket qu puerto de protocolo debe usar para la entrega de datos. La implementacin del socket maneja la interfaz entre el cliente y el mdulo 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 especfico, el programa utiliza una funcin bind. Transmisin de Datos por el Socket Despus de que el programa configura un socket puede utilizarlo para la comunicacin en la red. El proceso de comunicacin incluye enviar y recibir informacin. La interfaz de sockets incluye adems funciones para hacer ambas tareas. La API de sockets proporciona cinco funciones para transmitir datos a travs de un socket y las divide en dos grupos. Tres funciones requieren una direccin destino como parmetro; las otras dos, no. La diferencia principal entre los dos grupos es si la transmisin es sin conexin u orientada a conexin. Descripcin de las cinco funciones de la API de sockets que los programas pueden utilizar para transmitir datos. Funcin de la API de sockets send Descripcin

transmite datos a travs de un socket de conexin; puede utilizar banderas para controlar el comportamiento del socket. Transmite datos a travs de un socket de conexin, utilizando un bfer de datos simple. Transmite datos a travs de un socket de conexin, utilizando bloques de memoria no contiguos como bfer de datos. Transmite datos a travs de un socket sin conexin, utilizando un bfer de mensajes simple. Transmite datos a travs de un socket sin conexin, utilizando una estructura de mensajes flexible como bfer de mensajes.

write writev

sendto Sendmsg

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

Envo de datos por un socket de conexin Las comunicaciones orientadas a conexin utilizan circuitos virtuales- el enlace entre los extremos parece punto a punto, es decir, despus de que el software de red establece la conexin, el programa puede intercambiar datos con el anfitrin remoto en flujo de bytes constantes. Las funciones de la API de sockets que hacen transmisiones de datos orientadas a conexin no requieren que el programa especifique una direccin destino como parmetro. El programa utiliza la funcin connect para configurar sockets orientados a conexin que incluyen datos de la direccin del anfitrin destino (puerto de protocolo y direccin IP). Durante toda la conversacin en red, la implementacin del socket mantiene los datos de la direccin y maneja la interfaz con la capa de transporte para el socket orientado a conexin. Las funciones send, write y writev slo trabajan con sockets conectados, no permiten que el programa especifique una direccin destino. Estas tres funciones necesitan que el programa especifique un identificador de socket como primer parmetro en la llamada funcin. La siguiente instruccin muestra una llamada comn de la funcin write: result = write (socket_handle, message_buffer, buffer_lenght) El primer parmetro de la funcin 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 descripcin que apunta a una estructura de datos interna del socket. El segundo parmetro es el buffer de mensajes (message_buffer), que apunta al buffer de datos que contiene la informacin que transmitir el programa y que debe reservar memoria para ese buffer y llenarlo con los datos. El tercer parmetro de la funcin write, tamao del buffer (buffer_lenght), simplemente especifica el tamao del buffer de datos que el programa va a transmitir. La llamada a la funcin write v es muy similar a la de la funcin write. Sin embargo la funcin write no requiere que sus datos ocupen datos contiguos de memoria; la funcin write s. En otras palabras, writev permite que el programa especifique una tabla de direcciones que contenga sus datos. La siguiente instruccin ilustra una llamada a la funcin writev: result = write (socket_handle, io_vector, vector_lenght); Al igual que write, la funcin writev tambin requiere un identificador de socket como primer parmetro (socket_handle); el segundo especfica la direccin de una tabla que contiene una secuencia de apuntadores (io-vector). Supongamos que los datos que se desean transmitir estn almacenados en diferentes localidades de memoria. Se debe asignar la direccin de cada buffer de datos a la tabla de apuntadores. Cuando la funcin writev transmita los datos, enviar la informacin contenida en cada localidad de memoria especificada por la tabla de apuntadores. La funcin writev transmite los datos en el mismo orden en que aparecen las direcciones de memoria en la tabla de apuntadores. El tercer parmetro de la funcin writev (vector_lenght) especifica el nmero de elementos de la tabla de apuntadores.

93 El segundo parmetro de la funcin writev especifica la direccin 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 cuntos bytes existen en la direccin indicada. La siguiente figura A2 muestra un ejemplo de una tabla de apuntadores de datos. 0 Posiciones del bit Apuntador al bloque de datos 1 (direccin de memoria de 32 bits) Tamao del bloque de datos 1 (entero de 32 bits) Apuntador al bloque de datos 2(direccin de memoria de 32 bits) Tamao del bloque de datos 2 (entero de 32 bits) Fig. A2: Formato de tabla a la que apunta la funcin writev. Puesto que la funcin write fuerza al programa a utilizar buffers de datos contiguos, tiene un desempeo ms rpido que la funcin 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 difcil obtener bloques de memoria contiguos. La funcin send es la nica otra funcin de la interfaz de sockets que el programa se puede utilizar con sockets de conexin. La siguiente instruccin muestra una llamada comn a la funcin send: result = send (socket_ handle, message_buffer, buffer_lenght, special_flags); La mayor ventaja de la funcin send es que usted puede especificar banderas opcionales que controlen la transmisin. Por ejemplo, TCP/IP da a los datos fuera de banda o datos urgentes una prioridad mayor que los dems. Una de las banderas opcionales que puede utilizar con la funcin 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 nmero 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. Envo de datos a travs de un socket sin conexin Los programas pueden utilizar las tres funciones que vimos en las secciones anteriores para transmitir datos a travs de un socket de conexin pero, esas funciones no permiten especificar la direccin destino. Para enviar datos a travs de un socket sin conexin (un socket configurado para utilizar un protocolo sin conexin), los programas deben de utilizar una de las dos funciones (sendto y sednmesg) que proporciona la interfaz de sockets para ese propsito. La funcin sendto requiere seis parmetros. Los primeros cuatro son idnticos a la funcin send. El quinto identifica 32 bits 31

94 la funcin destino (socket_address_structure). El sexto especifica al tamao (o longitud) de la direccin destino en bytes (address_structure_lenght). La siguiente instruccin muestra una llamada comn a la funcin sendto: result = sendto(socket_handle, message_buffer, socket_address_structure, address_structure_lenght); buffer_lenght, special_flags,

La funcin sendmsg permite al programa utilizar, para transmisin, una estructura de mensaje en lugar de un simple buffer de datos. Segn se muestra es la siguiente instruccin, la funcin sendmsg requiere como parmetros 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 parmetros de mensajes en una simple estructura de datos. La funcin sendmsg requiere como parmetros 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 parmetros de mensajes en una simple estructura de datos. La funcin sendmsg se parece a la funcin writev en que los programas pueden formatear los datos en mltiples 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 funcin sendmsg. 0 Posiciones del bit Apuntador a la estructura de direccin del socket Tamao de la estructura de direccin del socket Apuntador a la lista de vectores de E/S Extensin de la lista de vectores de E/S Apuntador a la lista de derechos de acceso Extensin de la lista de derechos de acceso Fig. A3: Formato de la estructura de mensaje que utiliza la funcin sendmsg. La interfaz de sockets incluye una funcin (recvmsg) que recibe datos en el mismo tipo de estructura del mensaje que utiliza la funcin sendmsg: Tambin analizaremos otras funciones que sus programas pueden utilizar para recibir datos por un socket. Recepcin 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 32 bits 31

95 recv y send emplean parmetros similares. Ocupamos la funcin recv para recibir datos y la funcin 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 transmisin send write writev sendto sendmsg Funciones correspondientes de recepcin recv read readv recvffrom recvmsg

Funciones correspondientes de recepcin y transmisin de la API de sockets. Aunque la interfaz de sockets incluye funciones de transmisin y recepcin que se corresponden, no es necesario el uso de ambas. Si un anfitrin remoto utiliza la funcin send para enviar datos, para recibirlos no tiene que ocupar la funcin recv (la funcin correspondiente). Una vez que una funcin 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 funcin que ms se adapte a las necesidades. Para eliminar cualquier requerimiento de extremos de bloques contiguos de memoria, puede disear todos sus programas para que usen llamadas a la funcin readv. Algunos programadores pueden encontrar que el cdigo 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 continuacin, se muestran las llamadas comunes del sistema de sockets que utilizan los programas con protocolos orientados a conexin. La parte de la izquierda muestra las llamadas a funciones del servidor; la de la derecha las llamadas a funciones del cliente. Las lneas y flechas entre los mdulos servidor y cliente, muestran el flujo de la comunicacin de la red entre dos programas. Como se puede ver el programa servidor crea un socket con la funcin socket. Siendo ms precisos, el programa servidor solicita a la implementacin 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. Despus, 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 conexin.

97 La funcin listen indica al socket que atienda las conexiones entrantes y que confirme las solicitudes de conexin, es decir, la funcin listen pone al socket en modo de atencin pasiva. Un socket enva a cada solicitante un mensaje de confirmacin que indica que el anfitrin recibi su solicitud de conexin. No obstante un socket que atiende no acepta, en realidad, la solicitud de conexin. Para hacerlo y establecer la conexin con un solicitante de ingreso, el programa debe llamar a la funcin accept. Como podemos ver arriba en la figura, el programa cliente tambin crea un socket con la funcin socket. Sin embargo, el programa cliente que utiliza un protocolo orientado a conexin como TCP no se ocupa de cul direccin local usa el protocolo. Por lo tanto, no necesita llamar a la funcin bind. En vez de hacer eso inicia la conversacin en red llamando a la funcin connect. Despus de que el cliente y servidor establecen la conexin, pueden ocurrir comunicaciones adicionales a travs de las funciones write y read. Sin embargo, los programas cliente y servidor podran fcilmente haber usado las funciones send y resv o cualquier otra funcin de la interfaz de sockets que trabajen con sockets de conexin. La figura A5 nos muestra las llamadas comunes del sistema de sockets que emplea un protocolo sin conexin.

Servidor

Cliente

Fig. A5: Uso de los sockets con un protocolo sin conexin. Ms que el servidor orientado a conexin, el servidor sin conexin ver figura A5, usa las llamadas a las funciones socket y bind para crear y unir un socket. Pero, como el socket es sin conexin, el programa cliente utiliza la funcin 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 funcin bind pero no a la connect, un protocolo sin conexin no establece una conexin punto a

98 punto entre ambos lados, en su lugar la funcin sendto requiere que el programa especifique la direccin destino como parmetro. La funcin recvfrom tampoco espera por la conexin sino que responde a cualquier dato que llegue al puerto de protocolo que tiene enlazado. Cuando la funcin recvfrom recibe un datagrama desde un socket, almacena la direccin de red del proceso que lo transmiti, as como el mismo datagrama. Los programas (servidor y cliente) utilizan las direcciones almacenadas para identificar la direccin del proceso (cliente) emisor. Entonces, el servidor enva el datagrama de respuesta (como se solicit) a la direccin que obtuvo la funcin recvfrom. A continuacin se muestra un ejemplo del uso de sockets para Windows
// SockMan.CPP // Administrador de programas Winsock // Un modelo de programacin e intrprete 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 aplicacin 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_VREDRAW; wndclass.lpfnWndProc wndclass.cbClsExtra wndclass.cbWndExtra wndclass.hInstance wndclass.hIcon szAppName); wndclass.hCursor IDC_ARROW); wndclass.hbrBackground wndclass.lpszMenuName wndclass.lpszClassName if (!RegisterClass(&wndclass)) return FALSE; } hwndSockman = CreateWindow ( szAppName, "Demostracin SockMan ver. 1", WS_OVERLAPPEDWINDOW | WS_VSCROLL | WS_HSCROLL, CW_USEDEFAULT, CW_USEDEFAULT, = GetStockObject(WHITE_BRUSH); = szAppName; = szAppName; = LoadCursor(NULL, = WndProc; = 0; = 0; = hInstance; = LoadIcon(hInstance, = CS_HREDRAW |

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_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 intrprete de comandos de programacin 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_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); } MB_ICONEXCLAMATION | MB_ICONEXCLAMATION |

101

ANEXO B.

EJEMPLO DE APLICACIN CON TI

Muestra de un fragmento del una aplicacin 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 #define FALSE (0==0) !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: 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

// ESC Choice = 0; break;

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 CL_BOOL 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 CL_BYTE CL_DATALEN CL_RCODE char char long char CL_BOOL

FileName[100]; RC =TRUE;

Command[600]; Response[600]; ResponseLen; RC = CL_ERR_COMM; *pLine; *FileBuffer = NULL; FileLen; Choice; 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 CL_BYTE CL_BYTE CL_DATALEN CL_RCODE int char char

Input[100]; Command[600]; Response[600]; ResponseLen; RC = CL_ERR_COMM; Len = 0; *pCmd; *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. CDIGO DE LA PANTALLA DE MEN PRINCIPAL DE LA APLICACIN


Este es parte del cdigo 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 cdigo 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; // Instruccin 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 cdigo la funcin 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

Cdigo 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 ); } //---------------------------------------------------------------------------

S-ar putea să vă placă și