documento del proyecto de grado - uniandes
TRANSCRIPT
IEL2-I-2003-19 IEL2-I-2003-22
1
APLICATIVO EN EL SECTOR SALUD PARA UN MANEJO EFICIENTE DE LA INFORMACIÓN DE BENEFICIARIOS, INTEGRANDO EL USO DE TARJETA
INTELIGENTE Y DISEÑO DE REDES
ROBERTO PATERNINA PATERNINA 199811937
JUAN CARLOS ROSAS MARTÍNEZ 199811234
BOGOTÁ
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DPTO. DE ELECTRICA Y ELECTRÓNICA 2003
IEL2-I-2003-19 IEL2-I-2003-22
2
APLICATIVO EN EL SECTOR SALUD PARA UN MANEJO EFICIENTE DE LA INFORMACIÓN DE BENEFICIARIOS, INTEGRANDO EL USO DE TARJETA
INTELIGENTE Y DISEÑO DE REDES
ROBERTO PATERNINA PATERNINA 199811937
JUAN CARLOS ROSAS MARTÍNEZ 199812234
Trabajo de Grado presentado como requisito
Parcial para optar al título de Ingeniero Electrónico Director: NESTOR PEÑA
BOGOTÁ
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DPTO. DE ELECTRICA Y ELECTRÓNICA 2003
IEL2-I-2003-19 IEL2-I-2003-22
3
PAGINA DE ACEPTACIÓN
Nota de Aceptación
____________________________________ ____________________________________ ____________________________________ ____________________________________
____________________________________ Presidente del Jurado
____________________________________ Jurado
____________________________________
Jurado
IEL2-I-2003-19 IEL2-I-2003-22
4
AGRADECIMENTOS
A NESTOR PEÑA, Profesor del Dpto. de Ing. Eléctrica y electrónica de la universidad de los andes, asesor y colaborador de este proyecto.
A CARLOS FELIPE ROSAS, Vicepresidente de Sistemas y Comunicaciones
de Credibanco – Visa Colombia y colaborador de este proyecto
A MÓNICA RAMÍREZ, Gerente de Marketing de Tarjetas Inteligentes de
Inteligensa y colaborador de este proyecto.
A HERNANDO CORTÉS, Coordinador de Investigación y desarrollo de
Inteligensa y colaborador de este proyecto
A FRANCISCO MAHECHA, Gerente de comunicaciones de HyperNet de
Colombia y colaborador de este proyecto
A El personal que nos colaboró en Hypercom.
A Todas aquellas personas que en una u otra forma colaboraron en la
realización del presente trabajo
IEL2-I-2003-19 IEL2-I-2003-22
5
TABLA DE CONTENIDO
PAG
INTRODUCCION
1. RESUMEN YOBJETIVOS DEL PROYECTO 16
1.1 DESCRIPCION DEL PROBLEMA 16
1.2 POSIBLE SOLUCION 17
1.3 ESTUDIOS REALIZADOS PARA DAR SOLUCION AL PROBLEMA 18
1.4 NUESTRA SOLUCION 20
2. DISEÑO DE LA RED DE COMUNICACIONES 23
2.1 CARACTERISTICAS DE UNA RED DE COMUNICACIONES
TRANSACCIONAL MÉDICA 24
2.2 DETERMINACION DE LOS PARAMETROS PARA EL
DISEÑO DE LA RED DEL SEGURO SOCIAL 25
2.2.1 Numero de cuotas recaudadas en periodos anteriores 26
2.2.2 Estimación del tamaño del mensaje 27
2.2.2.1 Estructura del mensaje ISO 8583 28
2.2.2.2 Tamaño estimado de los campos 29
2.3 DISEÑO DE LA JERARQUIA DEL SISTEMA 29
2.3.1 Red Transaccional Credibanco- Visa Colombia 30
2.3.1.1 Redes de entidades financiera asociadas de
Credibanco – Visa. 31
2.3.1.2 Red de oficinas regionales y seccionales 32
2.3.1.3 Red de comercios 33
2.3.2 Red de comunicaciones del proyecto SUS en Brasil 34
2.3.3 Red de comunicaciones propuesta para la solución en Colombia 36
2.4 PROPUESTAS USANDO LOS PROVEEDORES DE SERVICIOS 36
2.4.1 Propuesta usando los servicios de Telecom 37
2.4.1.1 Solución departamental usando los servicios de Telecom 39
IEL2-I-2003-19 IEL2-I-2003-22
6
2.4.1.1.1 Regionalización bajo esta primera propuesta
Telecom 40
2.4.1.1.2 Estimación del tráfico 41
2.4.1.1.3 Propuesta económica 42
2.4.1.1.4 Determinación del número de líneas
telefónicas primera propuesta 43
2.4.1.2 Solución regionalizada usando los servicios de Telecom 45
2.4.1.2.1 Regionalización bajo el esquema de la segunda
propuesta Telecom 45
2.4.1.2.2 Estimación del tráfico 47
2.4.1.2.3 Propuesta económica 47
2.4.1.3 Plan corporativo de larga distancia Telecom 49
2.4.1.4 Valores adicionales de la propuesta de Telecom 51
2.4.2 Propuesta utilizando los servicios de Orbitel 52
2.4.2.1 Jerarquía del sistema usando los servicios de Orbitel 53
2.4.2.2 Determinación del número de líneas telefónicas Orbitel 53
2.4.2.3 Propuesta económica de Orbitel 54
2.4.3 Determinación de la propuesta más viable 55
3. ESTUDIO TECNICO DE LA TI 57
3.1 TARJETAS CON CHIP Y MAGNETICAS 57
3.1.1 Concepto del Monedero Electrónico 57
3.1.2 Tarjeta Magnética 58
3.1.2.1 Características Técnicas 58
3.1.2.2 Almacenamiento Y Tipo De Información Guardada 59
3.1.2.3 Uso Como Forma De Pago 59
3.1.3 Dinero Electrónico 60
3.1.4 Tarjeta Inteligente VS Tarjetas Magnéticas 61
3.2 TIPOS DE TARJETA CON CIRCUITO INTEGRADO 62
3.2.1 Tarjetas De Memoria 63
3.2.2 Tarjetas De Memoria Con Circuitos De Seguridad 64
3.2.3 Tarjetas Inteligentes 64
3.2.3.1 Tarjeta con y sin contacto (Contact, Contact Less) 65
IEL2-I-2003-19 IEL2-I-2003-22
7
3.3 CARACTERISTICAS FISICAS Y ELECTRICAS DE LAS TI 67
3.3.1 Características Físicas 67
3.3.1.1 Formato De Las Tarjetas 67
3.3.1.2 Dimensiones De La Superficie De Contacto 69
3.3.2 Características Eléctricas 69
3.3.2.1 Características De Los Contactos Eléctricos 70
3.3.2.2 Tensión De Alimentación 71
3.3.2.3 Consumo De Corriente 71
3.3.2.4 Secuencia De Encendido Y Apagado De Una Tarjeta 71
3.4 COMUNICACIÓN ENTRE LA TARJETA Y LOS DISPOSITIVOS EXT. 72
3.4.1 Convenio Lógico Y Eléctrico 73
3.4.2 Protocolos De Transmisión 75
3.4.2.1 Protocolo De Transmisión T =0 76
3.5 SISTEMA OPERATIVO DE LAS TARJETAS 79
3.5.1 Principios Fundamentales 79
3.5.2 Principios De Diseño e Implementación 80
3.5.3 Estructura de la Memoria 81
3.5.4 Estructura de los Datos Almacenados en una Tarjeta Inteligente 83
3.5.4.1 Tipos de Ficheros 84
3.5.4.1.1 Fichero Maestro (MF) 84
3.5.4.1.2 Fichero Dedicado (DF) 84
3.5.4.1.3 Fichero Elemental (EF) 84
3.5.4.1.4 Fichero Interno del Sistema 85
3.5.4.2 Identificación de Ficheros 85
3.5.4.3 Direccionamiento de los Ficheros 85
3.5.4.4 Opciones de Selección de Ficheros 86
3.5.4.5 Tipos de Estructuras de Ficheros 86
3.5.4.5.1 Fichero Transparente o Binario (EF Binario) 87
3.5.4.5.2 EF Llave y EF Clave (EF KEY, EF CHV) 87
IEL2-I-2003-19 IEL2-I-2003-22
8
3.5.4.5.3 Fichero Lineal Fijo o de Registro (EF Registro) 87
3.5.4.5.4 Fichero Lineal Variable 88
3.5.4.5.5 Fichero Cíclico 88
3.5.4.5.6 Fichero Ejecutable 89
3.5.4.6 Tipos de Acceso a los Ficheros 89
3.5.4.7 Tributos de los Ficheros 90
3.5.4.8 “Diario” de Datos 90
3.5.4.9 Ficheros Alterados 91
3.6 JUEGO DE INSTRUCCIONES 91
3.6.1 Selección de Ficheros 92
3.6.2 Instrucciones de Lectura y Escritura 93
3.6.3 Instrucciones para la Administración de Ficheros 94
3.6.4 Instrucciones de Autenticación 94
3.6.5 Lista de Comandos con los que trabaja la Tarjeta implementada 95
3.6.6 Comandos y Ficheros 96
3.6.7 Palabras de Estado devueltas por la tarjeta (Status Word) 97
3.7 DESCRIPCION DE COMANDO IMPLEMENTADOS EN EL APLICATIVO 97
3.7.1 Comando SELECT FILE 98
3.7.2 Comando CREATE FILE 101
3.7.3 Comando DELETE FILE 102
3.7.4 Comando UPDATE RECORD 103
3.7.5 Comando READ RECORD 105
3.7.6 Comando GET CHALLENGE 105
3.7.7 Comando EXTERNAL AUTHENTICATION 106
3.7.8 Comando GET RESPONSE 107
3.8 MECANISMOS DE SEGURIDAD 107
3.8.1 Criptografía y Seguridad 107
3.8.1.1 DES (Data Encryption Standard) 107
3.8.1.2 Algoritmo Plano 109
3.8.1.3 Identificador de Algoritmos 109
3.8.1.4 Significado de CHV 110
3.8.2 Manejo de Llaves (Para Encripción) 110
IEL2-I-2003-19 IEL2-I-2003-22
9
3.8.2.1 Estructura de los Archivos de Llaves (EFKEY_MAN y
EFKEY_OP) 110
3.8.2.2 Estructura de Archivos CHV (EFCHV) 110
3.8.3 Comandos de Seguridad 111
3.8.3.1 Comandos Relacionados con CHV: VERIFY/CHANGE/
UNBLOCK CHV 111
3.8.3.2 Autenticaciones (EXTERNA/INTERNA) 111
3.8.3.3 Comandos de Entrada/Salida Cifrados 112
3.8.3.4 Modo PRO (Protección) 112
3.8.4 Condiciones de Acceso (AC) 113
4. IMPLEMENTACION REALIZADA EN LA TI HOST DE LA MARCA OBERT. 116
4.1 ESCOGENCIA DE TI Y LECTOR 116
4.2 DEFINICION DE LA INFORMACION A MANEJAR 118
4.3 DEFINICION DE QUIEN MANEJARA LA INFORMACION 119
4.4 DEFINICION DE CÓMO SE VA A MANEJAR LA INFORMACION DE
BENEFICIARIOS 121
4.4.1 Ficheros para el Manejo de la Información 121
4.4.1.1 Creación y Estructura de Ficheros 122
4.4.2 Seguridad para el Manejo de Datos 124
5 DISEÑO DEL APLICATIVO MEDICO CON TI “APMETI” 126
5.1 DEFINICION DE APMETI 126
5.2 ACCIONES QUE REALIZA APMETI 127
5.2.1 Creación y Eliminación de Beneficiarios de Servicios de Salud 128
5.2.1.1 Etapa de pre – personalización 128
5.2.1.2 Etapa de personalización 128
5.2.2 Creación y Eliminación de un Nuevo Operario 129
5.2.3 Manejo de Información según Cargo del Operario 129
5.2.3.1 Ventana Principal 130
5.2.3.2 Ventana de Trabajo para el Administrador 133
5.2.3.2.1 Ventana para la Información de Operarios 133
5.2.3.2.2 Ventana para Información de Beneficiarios 134
IEL2-I-2003-19 IEL2-I-2003-22
10
5.2.3.3 Ventana de Trabajo para el Coordinador 135
5.2.3.4 Ventana de Trabajo para el Medico 136
5.2.3.5 Ventada de Trabajo para el Cajero 137
5.2.3.6 Ventana de Trabajo para el Droguista 138
5.2.3.7 Ventana de Trabajo para Func. de Emergencia 139
5.2.3.8 Ventana de Inicio de Sesión 140
5.3 CÓMO SE CREO APMETI 141
5.3.1 Arquitectura De ApMeTI 142
5.3.2 Implementación en Visual Basic 6 (VB6) 143
5.3.2.1 Formularios 144
5.3.2.2 Módulos 145
5.2.1 Utilización de ACCESS 147
5.2.2 Librería de Control (DLL) del lector implementado (Delarue) 148
CONCLUSIONES 150
BIBLIOGRAFIA 151
IEL2-I-2003-19 IEL2-I-2003-22
11
LISTA DE FIGURAS
PAG FIGURA 1. Esquema del flujo de datos en el aplicativo 21
FIGURA 2. Regionalización de la Red 22
FIGURA 3. Jerarquía de la Red 22
FIGURA 4. Mensaje ISO 8583 28
FIGURA 5. Red de entidades asociadas Credibanco Visa – Colombia 32
FIGURA 6. Red de regionales y seccionales, Credibanco – Visa 33
FIGURA 7. Redes de comercios Credibanco – Visa. 34
FIGURA 8. Jerarquía de la red de SUS. 34
FIGURA 9. Jerarquía de la red propuesta usando los servicios de Telecom 38
FIGURA 10. Diagrama de conexión de los enlaces dedicados. 38
FIGURA 11. Diagrama de conexión de los puntos de atención con su
correspondiente nodo. 39
FIGURA 12. Regionalización por departamentos. 40
FIGURA 13, Regionalización por zonas. 46
FIGURA 14. Locación y tamaño de las bandas magnéticas. 58
FIGURA 15. Esquema de Bloques de la arquitectura de una Tarjeta de Memoria 64
FIGURA 16. Esquema de Bloques de la arquitectura de una Tarjeta de Memoria con
Circuito de Seguridad 64
FIGURA 17. Arquitectura de Tarjeta con Microprocesador 65
FIGURA 18. Tipos de Contactos de Tarjeta con Contacto 66
FIGURA 19. Tarjeta Sin Contacto 67
FIGURA 20. Formato ID-1 68
FIGURA 21. Separación de Contactos 69
FIGURA 22. Distribución de los contactos 70
FIGURA 23. Consumo de corriente en función de la frecuencia de reloj aplicado 71
FIGURA 24. Secuencia de Encendido y Apagado de una TI 72
FIGURA 25. Secuencia de Inicio y Transmisión de Datos entre TI y Lector 73
FIGURA 26. Estructura del paquete de datos transmitido 74
FIGURA 27. Esquema de recepción con y sin errores 77
FIGURA 28. Secuencia de intercambio de comandos durante escritura. 78
IEL2-I-2003-19 IEL2-I-2003-22
12
FIGURA 29. Secuencia de intercambio de comandos durante lectura. 79
FIGURA 30. Estructura General de un Fichero 83
FIGURA 31. Estructura en Árbol de los Ficheros de la memoria 84
FIGURA 32. Ejemplo de Selecciones autorizadas y no autorizadas 86
FIGURA 33. Fichero Transparente 87
FIGURA 34. Estructura de un fichero EF Lineal Fijo 88
FIGURA 35. Estructura de un fichero EF Lineal Variable 88
FIGURA 36. Estructura de un fichero EF Cíclico 89
FIGURA 37. Valor del campo Estado de Fichero 101
FIGURA 38. Estructura de ficheros dentro de la TI para la aplicación. 122
FIGURA 39. Esquema del Aplicativo 127
FIGURA 40. Etapa de Pre-personalización. 128
FIGURA 41. Etapa de Personalización. 129
FIGURA 42. Ventana de Información acerca del programa ApMeTI. 132
FIGURA 43. Ventana del Administrador para el manejo de datos de Operarios 134
FIGURA 44. Ventana del Administrador para datos de Beneficiarios 135
FIGURA 45. Ventana del Coordinador 136
FIGURA 46. Ventana de trabajo para Médico 137
FIGURA 47. Ventana del Cajero 138
FIGURA 48. Ventana del Droguista 139
FIGURA 49. Ventana del operario de Emergencia 140
FIGURA 50. Ventana de Inicio de Sesión 141
FIGURA 51. Ambiente de Visual Basic de la implementación hecha. 141
FIGURA 52. Ventana de prueba de la primera implementación con la TI HOST. 146
FIGURA 53. Base de Datos Inicial para Operarios 147
FIGURA 54. Parte de la Base de Datos de Pacientes 148
IEL2-I-2003-19 IEL2-I-2003-22
13
IEL2-I-2003-19 IEL2-I-2003-22
14
INTRODUCCION
Este proyecto de grado tiene como fin realizar una implementación con Tarjeta
Inteligente que involucre además el diseño de una Red Transaccional para la
consolidación de información y transacciones en bases de datos sectorizadas y a su
vez la creación de un aplicativo o software para el control de la información y los
dispositivos involucrados en el manejo de esta.
La idea fue utilizar el estudio de la implementación antes descrita para buscar una
solución a los problemas que sufren entidades como las prestadoras de salud en el
manejo inseguro e ineficiente que se le da a la información de los beneficiarios y a
los servicios prestados.
Se realizó un aplicativo piloto para el manejo de la información de beneficiarios de
servicios de salud en entidades prestadoras de estos, utilizando Tarjeta Inteligente
como herramienta para la prestación de dichos servicios, requiriéndose además
consolidar dichas prestaciones o transacciones en bases de datos sectorizadas
dentro del país, en donde se involucró el diseño de una red acorde a este fin.
Para lograr el objetivo de diseñar la red e implementar el piloto del aplicativo se
dividió este documento con el fin de abarcar todo el trabajo en forma resumida de la
siguiente forma:
IEL2-I-2003-19 IEL2-I-2003-22
15
• Estudio del problema y la solución.
• Diseño de la Red de Comunicaciones.
• Estudio de la Tarjeta Inteligente.
• Implementación de la Tarjeta Inteligente.
• Creación e implementación del piloto del Aplicativo (llamado ApMeTI).
IEL2-I-2003-19 IEL2-I-2003-22
16
1. RESUMEN Y OBJETIVOS DEL PROYECTO
1.1 DESCRIPCION DEL PROBLEMA
En la mayoría de Entidades Prestadoras de Servicios de Salud, tanto en Colombia
como en el resto mundo, la mayoría de transacciones, sea dinero, formulación
médica, solicitud de exámenes, historia clínica y toda información médica y básica
de pacientes se hace sobre papel y su manejo requiere muchos intermediarios. Por
tanto la no sistematización del manejo de la Información de pacientes hace que
todas estas entidades sufran perdidas económicas y presten además un servicio
ineficiente por el mal manejo de la información.
Muchos son los casos en Colombia, sean del Seguro Social o de empresas privadas
como Colsanitas, donde la compra de vales (o Cuotas Moderadoras) se convierten
en uno de los principales focos de corrupción, pues se hace reventa de dichos
volantes o se prestan servicios médicos sin cobrarlos.
Además del problema en el manejo de recaudo de vales o cuotas, existe el
inconveniente del manejo de la Información Médica de Pacientes. Muchas veces por
no poder identificar a un paciente, se le prestan servicios médicos a gente no
afiliada o se trata erróneamente a cierto paciente por tener otra información acerca
de él o peor aún por no tenerla. En seguidas ocasiones llegan a las salas de
urgencias heridos y no se tiene la menor idea del pasado médico de ellos sin saber
que medicación consume o que alergias sufre.
El manejo de la medicación no escapa de los problemas, muchas veces se
reclaman drogas en nombre de beneficiarios suscritos a la prestación del servicio
por personas ajenas a él (con lo que se pierde drogas y dinero por parte de la
entidad) y además se tiene el caso típico de la AUTOMEDICACION, donde la gente
compra drogas sin previa autorización médica exponiéndose a severos daños.
IEL2-I-2003-19 IEL2-I-2003-22
17
Es además difícil para un médico, tener acceso a la Historia Clínica de un paciente
nuevo, por lo que esta la tiene otro médico o peor aún se ha perdido. En todos estos
casos anteriores vemos que definitivamente, la mayoría de problemas en este tipo
de entidades de salud recae efectivamente sobre el manejo de la Información.
1.2 POSIBLE SOLUCION
Por tanto, la idea es brindar una SOLUCION que implique:
• La sistematización del manejo de la Información (Básica y Médica) de
beneficiarios.
• La consolidación de las transacciones.
• La identificación plena de beneficiarios.
• Control de todos los servicios prestados.
Para esto debe de alguna forma utilizarse un elemento en el cual se pueda guardar
cierta información del beneficiario, en forma segura y confidencial, que sirva además
para identificarlo en forma plena. De tal forma al momento de prestar un servicio
solo sería necesario leer la información allí contenida (sea nombre, número de
contrato, alergias, drogas, si ha pagado o no, etc.) y ver que se debe hacer
entonces.
Una vez se tenga un acceso seguro, confidencial y satisfactorio, es necesario
consolidar el servicio prestado o la información modificada en dicho elemento del
beneficiario para así tener un control total de lo que se hizo.
De tal forma, tanto el paciente como el prestador del servicio (u operario de salud) y
a su vez la entidad como tal, sabrán con plena seguridad todo lo que se ha hecho
sea en la prestación de un servicio o en la modificación de la información de un
paciente.
IEL2-I-2003-19 IEL2-I-2003-22
18
1.3 ESTUDIOS REALIZADOS PARA DAR SOLUCION AL PROBLEMA
Dado que lo que se quiere es manejar cierta información referente a la prestación de
servicios de salud en forma sistemática, fue necesario realizar un previo estudio de
que se ha hecho para dar solución a este tipo de problemas, en entidades que
prestan los mismos servicios. Además, como se quiere realizar un control en el
recaudo de volantes, lo cual no es propiamente un tema de salud, fue necesario
estudiar soluciones que fuesen útiles relacionadas con el pago virtual.
En primera medida fue necesario delimitar el campo de acción, para ello se definió
en que campos se iban a utilizar para la solución, por lo que se escogió como
prioritario:
• Identificación plena de beneficiarios.
• Control de la información médica de beneficiarios.
• Control del manejo de drogas.
• Control del recaudo de vales.
• Solución para casos de emergencia médica.
Una vez definidos los puntos a trabajar se recurrió al estudio de la solución en sí.
Para ello se investigó que tipo de proyectos en salud se han implementado en el
mundo, en cuanto al manejo de la información médica de beneficiarios en entidades
prestadoras de salud. De tal forma se estudiaron las soluciones presentadas por los
siguientes proyectos:
• Proyecto Sesame Vitale en Francia.
• Proyecto SUS (Sistema Único de Salud) en Brasil.
• Pasaporte en Salud en EEUU.
• Proyecto del Departamento Federal para la Seguridad Social BVK en
Alemania.
IEL2-I-2003-19 IEL2-I-2003-22
19
De estos proyectos se tuvieron en cuenta la solución presentada para la
consolidación de la información en una “central” y el manejo de la información
portable (muy básica) que puede tener un paciente utilizando un medio como las
tarjetas (sean de banda magnética o inteligentes) para su identificación o para el
acceso a cierta información médica.
Los proyectos anteriores dan una luz para la solución en cuanto a los temas de
salud, pero para temas como el de los vales nos apoyamos en proyectos
nacionales, relacionados con el pago virtual implementando Tarjeta Inteligente o TI,
como es denominada generalmente, la idea es que de alguna forma segura se haga
un pago y se cargue la tarjeta con “dinero” una vez cargada, con esta se pueden
hacer transacciones sin utilizar dinero real, solo es descargada electrónicamente y
de esta forma se emplea en forma sencilla, controlada y segura la transacción. Por
ello para la formulación y entrega de la medicación y para la compra y cobro de
volantes es útil este esquema de transacción electrónica. De esta forma analizamos
los proyectos implementados para el pago electrónico en empresas como:
• Conavi.
• Ferricar.
• Conaltrasa.
• Mobil.
• Coca-Cola.
De ellas se analizó el esquema de seguridad y control para la transacción
electrónica y el manejo en general de TI.
1.4 NUESTRA SOLUCION
Una vez definidos los problemas, una posible solución y analizado proyectos que
aportan soluciones similares, recurrimos a plantear nuestra solución. Esta implica:
IEL2-I-2003-19 IEL2-I-2003-22
20
• Utilización de la TI como medio para:
o Identificación del beneficiario.
o Almacenamiento seguro y el acceso restringido de información del
beneficiario.
o Carga y descarga electrónica de vales.
o Prescripción médica electrónica.
• Consolidación de toda transacción o servicio médico prestado en una
central.
• Manejo de Base de Datos sectorizadas para la consolidación y
almacenamiento de la información.
• Diseño de una red de comunicaciones adecuada para la consolidación y
acceso a la información de los beneficiarios en general (red transaccional).
• Creación de una interfaz o APLICATIVO entre operario y base de datos o TI
que brinde un manejo eficiente y seguro de la información.
La idea es que la SOLUCION completa para las entidades de salud este compuesta
por todos los puntos antes mencionados. El aplicativo hace referencia a un software
encargado del control de la información y de los dispositivos involucrados en el
manejo de esta.
El piloto del aplicativo fue realizado programando en Visual Basic y utilizando la
herramienta Access para el manejo de las Bases de Datos. Se utilizaron Tarjetas
Inteligentes HOST de la marca Oberthur y lectores Delarue 132. La red diseñada fue
de tipo transaccional, regionalizada con topología de tipo estrella. En ella se
involucra una jerarquización de bases de datos y concentradores en donde se
utilizan enlaces Dial para conexiones remotas y enlaces dedicados para conexiones
entre los nodos regionales y el central. A continuación se muestra el esquema de la
solución y el esquema de la red.
Acá vemos como es el esquema de flujo de la información sin detallar la red. La idea
es tener una base de datos local y una regional y una central. De tal forma todo
servicio prestado debe ser consolidado en las bases de datos.
IEL2-I-2003-19 IEL2-I-2003-22
21
FIGURA 1. Esquema del flujo de datos en el aplicativo
Ahora si se detalla la Red encontramos que es una red de topología estrella
repartida en zonas en el país de la siguiente forma:
FIGURA 2. Regionalización de la Red
Y además tenemos una jerarquía de la siguiente forma:
IEL2-I-2003-19 IEL2-I-2003-22
22
FIGURA 3. Jerarquía de la Red
IEL2-I-2003-19 IEL2-I-2003-22
23
2. DISEÑO DE LA RED DE COMUNICACIONES
Diferentes tipos de industrias, empresas u organizaciones, mantienen esquemas de
recaudo e identificación de beneficiarios de manera manual, este esquema ha sido
utilizado durante mucho tiempo sin embargo hoy en día es un sistema obsoleto ya
que no presenta ningún tipo de seguridad y no hay manera de tener un adecuado
control de la información.
Con el fin de lograr tener toda la información vital de la empresa actualizada y
concentrada, se debe tener un diseño de red adecuado el cual permita al menor
costo posible actualizar constantemente las base de datos y de esta manera tener
siempre disponible la información de sus beneficiarios.
Para el sector salud no es indispensable tener los datos en tiempo real sin embargo
si es muy importante tener la información actualizada en intervalo de tiempo fijo, en
el cual se deberá refrescar los datos y así mismo se podrá tener un control sobre los
operarios que han prestado sus servicios en dichos intervalos de tiempo.
Con el fin de lograr determinar los requerimientos de una red de comunicaciones
para el ámbito medico, decidimos utilizar los datos públicos de la institución del
Seguro Social, con el fin de poder tener un estimativo de los recaudos en cuanto a
número de pagos. Aunque tratamos únicamente una institución para este fin, esta
metodología y diseño se podrá realizar para cualquier otra empresa que preste
servicios de salud, la escogencia del Seguro Social se debe básicamente a que la
información se puede obtener fácilmente debido a su carácter gubernamental y
además coincidencialmente esta institución publico pliegos para la licitación del
recaudo físico de sus dineros en los primeros meses del presente año.
IEL2-I-2003-19 IEL2-I-2003-22
24
2.1 CARACTERISTICAS DE UNA RED DE COMUNICACIONES TRANSACCIONAL MÉDICA
La red que se desea diseñar le denominamos de tipo transaccional debido a que
esta tiene la propiedad básica de dichas redes, debe transportar tanto solicitudes
como consolidaciones de los datos que se desean manipular. Es decir, se necesita
transportar solicitudes como se hacen en el sector financiero, para autorizar la
adquisición de medicamentos especiales, servicios de operaciones o exámenes
especializados entre otros, así mismo se necesita realizar consolidación o cierres
como se le denomina en este mismo sector para mantener la base de datos
actualizada, con lo cual se puede asegurar la integridad de la información que la
entidad
Una red de comunicaciones de tipo transaccional sin importar el tipo de red
(financiero, medico, etc.) debe tener como primer requerimiento un alto grado de
confiabilidad y de seguridad, es decir es de suma importancia que los datos que
viajan a través de dicha red logren alcanzar su objetivo final y además que no sean
interceptados por un tercero, ya que la información que viaja a través de ella es
personal y confidencial. En Colombia existen dos grandes redes de este tipo
(transaccional) para el ámbito financiero, estas son Credibanco - Visa Colombia y
Redeban –Multicolor, las cuales son de gran ayuda como punto de referencia para
conocer los requerimientos básicos de estas redes.
La red de comunicaciones transaccional medica tiene muchas similitudes con la red
transaccional financiera, ambas tienen que prestar un servicio confiable y seguro
como se explico anteriormente. Adicionalmente la red debe transportar
transacciones, las cuales son de un tamaño pequeño, sin embargo aunque estas no
son de gran tamaño, estas se realizan varias simultáneamente y no se debe
presentar demora en la respuesta, ya que de así serlo el servicio al cliente se
degrada y la imagen de estas empresas quedaría entredicha.
IEL2-I-2003-19 IEL2-I-2003-22
25
Aunque una red tiene varias similitudes con las redes financieras, también tienen
varias diferencias debido al servicio que estas prestan, por ejemplo una red financiera
genera trafico cada vez que un tarjeta habiente realiza una compra, usa un cajero
electrónico, solicita un retiro en efectivo y demás posibles servicios que los bancos
prestan, en el ámbito medico se realiza este mismo procedimiento para las
autorizaciones sin embargo no es necesario realizar una consolidación cada vez que
un paciente usa algún servicio básico de las entidades prestadoras de salud.
Esto se debe a que desde un comienzo se desea implementar tarjeta inteligente, la
cual ayuda a evitar el fraude en cuanto a la identificación. Así mismo una red
financiera deberá autorizar cada una de las transacciones sin importar el tipo de
servicio que se este ejecutando, en el ámbito medico aunque existe la necesidad de
realizar transacciones en línea, no todos los servicios deberán realizarse en
consolidando en tiempo real, sino que se realizaran consolidaciones periódicas, lo cual
nos ayudara a mantener la base de datos actualizada sin que sea necesario realizar
una consolidación cada vez que un paciente desea usar los servicios de la entidad
prestadora de servicios de salud, en el sector financiero este tipo de consolidaciones
se realizan de una a tres veces por día, en el caso de las entidades prestadoras de
salud se deberá realizar consolidaciones mas a menudo, en principio se desea
consolidar cada una o dos horas, esto es solicitud explicita del seguro bajo la
Convocatoria Pública V.EPS No. 012-01 de 2002.1
2.2 DETERMINACION DE LOS PARAMETROS PARA EL DISEÑO DE LA RED DEL SEGURO SOCIAL
Para lograr determinar el trafico que genera el seguro social la cual es la entidad
prestadora de servicios de salud que usamos para el diseño de la red, usa como
medio de pago la cuota moderadora, la cual difiere dependiendo del nivel salarial del
afiliado, el valor de esta cuota es de:
1 www.iss.gov.co, Vicepresidencia de EPS, “expedición de comprobantes de pago, recaudo y transferencia de dineros provenientes de las cuotas moderadoras y de los copagos en el Instituto del Seguro Social. Dicembre 2002.
IEL2-I-2003-19 IEL2-I-2003-22
26
• $1000 para los afiliados que devengan entre 1 y 2 SMMV.
• $2400 para los afiliados que devengan entre 2 y 4 SMMV.
• $4800 para los afiliados que devengan entre 5 y en adelante SMMV.
El valor de dichas cuotas moderadoras se encuentran definidas por la ley 100 de
1993.2
Adicionalmente a la cuota moderadora, existe el copago el cual es una cuota de un
valor más alto, el cual define el valor según el servicio que se preste. Los copagos
no se manejan la misma cantidad que cuotas moderadoras, dada esta circunstancia,
podemos concluir que el diseño de la red dependerá en un alto porcentaje de la
cuota moderadora.
2.2.1 Número de cuotas recaudadas en periodos anteriores
En las visitas realizadas al Seguro Social, se logro obtener información sobre el
recaudo de los meses picos (Mayo, Junio y Julio) de las cuotas moderadoras sin
embargo el recaudo de los copagos no ha sido controlado, razón por la cual en este
momento la institución no posee la información, es por ello que en la convocatoria
Convocatoria publica V.EPS No. 012-01 de 2002 se le pide a los contratistas liquidar
tanto la cuota moderadora como los copagos.
La información suministrada por el Seguro Social consta de dos sectores, esto se
debe a que en la anterior convocatoria pública, la licitación fue repartida entre dos
empresas. Sisprocol tuvo a su cargo los departamentos de Amazonas, Antioquia,
Arauca, Atlántico, Bolívar, Caquetá, Casanare, Cesar, Córdoba, Guajira,
Magdalena, Norte de Santander, Nariño, Putumayo, San Andrés y Sucre mientras
que Simco tuvo a su cargo los departamentos de Boyacá, Caldas, Cauca,
Cundinamarca, Huila, Meta Quindío, Risaralda, Santander, Tolima y Valle del
Cauca.
2 http://anm.fepafem.org/proacad.htm, Pronuncionamiento de la Academia frente a la Ley 100 de 1993. Dr. José F. Patiño
IEL2-I-2003-19 IEL2-I-2003-22
27
Con los datos históricos obtenidos de estas compañías y con ayuda de los
ejecutivos de Credibanco – Visa quienes nos explicaron el funcionamiento de su red
de comunicaciones a nivel nacional, logramos realizar un cálculo estimado del
tráfico que seria transportado por la red de comunicaciones de dicha entidad.
2.2.2 Estimación del tamaño del mensaje
El sector financiero tiene desarrollado un estándar para los mensaje de lo POS
(Puntos de venta), este estándar es usado tanto en los datafonos, cajeros o
maquinas registradoras. Este mensaje definido ISO 8583, es muy versátil, ya que
cada comercio tiene sus propias necesidades las cuales difieren considerablemente
debido a las grandes diferencias de servicios que deben prestarse para los
diferentes comercios, por ejemplo las necesidades de un restaurante no son las
mismas que tiene una agencia de viajes o un hotel, es por ello que la base de
nuestros estimados se basan en este estándar, ya que este posee la capacidad de
adaptarse a diferentes necesidades sin tener que cambiar el mensaje, simplemente
se realiza la habilitación e incluso la posible redefinición de campos, en los cuales
se podrán suplir las necesidades de transporte de información dadas por Seguro
Social. Por otro lado es importante tener en cuenta que este tipo de mensajes
preferiblemente se deberá manejar con un estándar ya que de esta manera se
podrá prestar servicios de este mismo tipo a cualquier otra entidad prestadora de
Servicios de Salud y no existirá la necesidad de desarrollar otro formato privado ya
que seria algo costo y poco eficiente. Por ultimo este estándar es de bajo costo,
eficiente, seguro y permite el constante refinamiento de la norma.3
Para la realización de una autorización se formara un solo mensaje ISO 8583, el
cual llevara toda la información que se necesite para que se pueda aceptar o
rechazar la solicitud, por otro lado para la realización de la consolidación se
formaran múltiples mensajes ISO 8583, los cuales se enviaran como ráfagas y
llevaran la información a consolidar de cada paciente (Numero de volantes,
medicinas prescritas, enfermedades del paciente, etc.)
3 Carlos Felipe Rosas, Credibanco Visa.
IEL2-I-2003-19 IEL2-I-2003-22
28
2.2.2.1 Estructura del mensaje ISO 85834: La estructura del mensaje del terminal
al host y viceversa consiste en tres parte principales como cualquier tipo de
mensaje, el encabezado, el aplicativo de los datos y el CRC. El encabezado tiene
como función enrutar mientras que el CRC se encarga de la integridad de los datos,
en total se pueden transportar 249 bytes por mensaje. El esquema del mensaje es
el siguiente:
FIGURA 4. Mensaje ISO 8583
• Encabezado: El encabezado contiene tanto mensaje como información de
ruteo. Esta parte del mensaje esta constituido por tres partes importantes, la
primera es el ADR, La cual es una dirección de poleo, CB el cual es un byte
de control y por ultimo la TPDU (Transfer Protocol Data Unit), la cual consta
de una identificación y las direcciones de origen y destino.
• Aplicativo de los datos: Este segmento posee tres campos, el primero es el
tipo de transacción a realizar (En el ámbito financiero puede ser una
solicitud, un reverso, un cierre, etc.), un bit map, el cual tiene la función de
habilitar los campos de los elementos de los datos y por ultimo tenemos la
información, la cual esta pre determinada por el mapa de bits. Dado a la
versatilidad del mensaje por el mapa de bits, es sencillo enviar información
de cualquier tipo, es decir el formato del mensaje me permite habilitar ciertas
banderas para así poder definir ciertos campos de la información. Por
ejemplo si prendo el bit 1 y lo defino como el campo del nombre del paciente,
el host deberá estar en capacidad de decodificar este mensaje y deducir que
en el primer campo de información estará el nombre del paciente. En la
4 Hypercom Message Specification, Octubre 25 de 2002
IEL2-I-2003-19 IEL2-I-2003-22
29
grafica anterior se puede ver que el tamaño del mensaje máximo es de 256
bytes sin embargo el ISO 8583 extendido utiliza 1024 bytes.
• CRC: Es el código de redundancia cíclica, es una suma de chequeo el cual
determina si la integridad de los datos se mantuvo.
2.2.2.2 Tamaño estimado de los campos: En varias entrevistas que tuvimos con el
Seguro Social y teniendo de base el proyecto de SUS (Sistema Único de Salud) que
se implanto en Brasil, se definieron ciertos datos, los cuales son los mínimos
indispensables para el desarrollo del aplicativo. El tamaño de estos campos
determina tanto el tamaño del mensaje ISO 8583 como el tamaño de la base de
datos, lo cual hace indispensable tener un tamaño óptimo, el cual no desperdicie
recursos y a su vez permita almacenar toda la información. Los campos son los
siguientes (se encuentran en bytes):
Nombre del paciente: 50.
Numero de contrato: 20.
Tipo de contrato: 20.
Identificación del paciente: 12.
Valera: 8.
Como podemos ver un mensaje de cada paciente se logra enviar en un mensaje
ISO 8583 (ocupa con estos campos mínimos 110 bytes), lo cual no hace necesario
la partición del mensaje, sin embargo pensando en futuros campos para el uso de
diferentes servicios, se realizaran el estudio de la cantidad de trafico teniendo en
cuenta que se la trama tendrá una longitud promedia de 512 bytes (Tamaño de
mensaje promedio para aplicaciones de lealtad de Credibanco – Visa Colombia).
2.3 DISEÑO DE LA JERARQUIA DEL SISTEMA Para lograr una comunicación efectiva, es necesario tener muy claro la jerarquía del
sistema que se va a utilizar, conocer las ciudades que generan el mayor porcentaje
de trafico y los posibles servicios que ofrecen las empresas prestadoras de servicios
IEL2-I-2003-19 IEL2-I-2003-22
30
de comunicación, de esta manera se podrá dimensionar y diseñar la red de la mejor
manera posible, así como poder tener un estimado de costos adecuado.
Con el fin de poder tener un conocimiento de redes similares ya implementadas en
la actualidad y con base en ello poder tener un juicio mas apropiados para la
elección de los parámetros propios de la red, decidimos realizar el estudio de la red
transaccional financiera de Visa – Colombia como un ejemplo a nivel nacional y la
red de comunicaciones del proyecto SUS “Sistema único de Salud” en Brasil con el
fin de conocer implementaciones medicas ya desarrolladas e implementadas.
2.3.1 Red Transaccional Credibanco- Visa Colombia
En las redes nacionales como son Credibanco – Visa se usa una jerarquía de
cuatro niveles, la cual consta de un nodo central ubicado en la ciudad de Bogota,
nodos regionales los cuales se caracterizan por ser ciudades donde se concentran
un gran porcentaje del trafico transaccional, nodos seccionales los cuales son
ciudades capital de departamento pero cuyo flujo de transacciones es mucho menor
en comparación a las ciudades de los nodos regionales y por ultimo tenemos los
sitios de atención en los comercios. Cabe anotar que el nivel de la jerarquía de
regional a seccional se realiza para determinar la importancia del nodo y es
únicamente de carácter organizacional, ya que a nivel de comunicaciones la
seccional no deberá conectarse con la regional, sino por el contrario estará
conectada a Bogota (por medio de un enlace permanente dedicado de menor
capacidad).
Teniendo en cuenta esta jerarquía, Credibanco Visa tiene tres diferentes
distinciones a su red, la cuales se explicaran a continuación.
IEL2-I-2003-19 IEL2-I-2003-22
31
2.3.1.1 Redes de entidades financiera asociadas de Credibanco – Visa5: Visa es
un “switch” financiero es decir se encarga de determinar que banco deberá aprobar
la solicitud, por lo cual no es la empresa que determina si la transacción es
aceptada o rechazada (esta función es de cada uno de los bancos). Hoy en día
existen dos tipos de bancos, los primeros son los bancos fuera de línea, los cuales
se caracterizan por no tener un enlace dedicado con Credibanco – Visa permanente
sino que se hacen consolidaciones en un intervalo de tiempo determinado, para el
correcto funcionamiento de esta metodología el banco provee una lista negra la cual
se almacenara en el Tandem, la cual consta de los números de tarjetas que deberá
rechazar en caso que se realice una solicitud, es decir el Tandem autorizara la
transacción basándose en esta lista predefinida por cada uno de los bancos (off –
line).
Así mismo tenemos los bancos que se encuentran en línea (on – line) con
Credibanco - Visa, en este caso el Tandem recibe la transacción y con los primeros
seis dígitos de la tarjeta determina el banco al cual pertenece la tarjeta y realiza con
lo cual realiza el enrutamiento de la transacción al banco determinado, el cual dará
respuesta a la solicitud generada.
Por otro lado cada una de las entidades bancarias asociadas sin importar el tipo
cuenta con enlaces de back up con los cuales se garantiza que el numero de
transacciones no exitosas disminuya considerablemente.
5 Carlos Felipe Rosas, Credibanco – Visa. Topología de la red de Credibanco en Colombia, Junio 1998.
IEL2-I-2003-19 IEL2-I-2003-22
32
FIGURA 5. Red de entidades asociadas Credibanco Visa – Colombia
2.3.1.2 Red de oficinas regionales y seccionales: Credibanco – Visa tiene
presencia (oficinas) en las ciudades más importantes del país Con el fin de tener un
mayor control se tienen dos tipos de oficinas los cuales se definen dependiendo del
nivel de tráfico generado por la ciudad y por fines organizacionales (supervisión y
coordinación). Teniendo en cuenta estos parámetros, Credibanco – Visa cuenta con
una configuración en estrella de las diferentes ciudades, en donde las regionales
tienen una capacidad mayor en sus enlaces principales y dedicados.
IEL2-I-2003-19 IEL2-I-2003-22
33
FIGURA 6. Red de regionales y seccionales, Credibanco – Visa
El funcionamiento de esta metodología consiste en que los comercios ubicados en
cualquier parte del país cuentan con un nodo remoto (ya sea regional o seccional)
asociado con lo cual se garantiza en la gran mayoría de los casos tarifa de llamadas
locales o de no ser así la tarifa de larga distancia mas económica para el comercio,
una vez realizada la llamada al nodo remoto, la transacción viajara al nodo central
en Bogota por medio de los enlaces permanentes.
2.3.1.3 Red de comercios: Este tipo de red se utiliza donde existe una gran
concentración de terminales (POS), como almacenes de cadena (Éxito, Carrefour,
Cafam, Carulla, etc.) y centros comerciales (Unicentro, Atlantis, Andino, etc.). La
metodología para el funcionamiento de este tipo de redes consiste en conectar un
numero determinado de terminales en LAN (SDLC o ETHERNET), un concetrador el
cual se encargara del poleo de las terminales y adicionalmente tendrá una salida a
la WAN ya sea por un enlace de demanda o permanente.
IEL2-I-2003-19 IEL2-I-2003-22
34
FIGURA 7. Redes de comercios Credibanco – Visa.
2.3.2 Red de comunicaciones del proyecto SUS en Brasil6
El proyecto de SUS en Brasil utilizo cinco categorías para definir su jerarquía, el
nivel federal, estatal, concentrador, municipal y el centro de Asistencia, como se
puede ver en la siguiente figura:
FIGURA 8. Jerarquía de la red de SUS.
6 Hypercom Corporation. SUS Project in Brazil, 2000.
IEL2-I-2003-19 IEL2-I-2003-22
35
El nivel federal cumple la función de ser el consolidador central, en la actualidad el
proyecto de SUS cuenta únicamente con dos servidores Sun MicroSystems, uno de
ellos es el principal localizado en Brasilia y el otro es el back up localizado en Río de
Janeiro, el cual cumple las mismas funciones que el principal pero solo entra a
operar en circunstancias en donde el principal no opere. Para mantener la
actualización de estos datos, estos dos servidores están conectados por medio de
un E-1, lo que hace que la integridad de a información de ambas ciudades sea la
misma.
El nivel estatal realiza una sectorización de los estados que conforma políticamente
a Brasil (el total son 27 estados), esta sectorización se realiza principalmente para
mantener el flujo de datos correctamente, al igual para mantener separada la
información para fines presupuéstales y políticos. El nivel concentrador se utiliza con
el fin de tener una consolidación total de todos los datos individualizados de los
centros de atención de back up así como los datos totalizados de los municipios
Estos tres niveles operan por medio de enlaces permanentes de Frame Relay, se
escogió este protocolo por ser eficiente en la transmisión de datos y por el bajo
costo en el que se incurre.
El nivel de concentrador recibe las llamadas por parte de los municipios, estas
llamadas se pagan por demanda, razón por la cual los concentradores están
estratégicamente ubicados para que el flujo de datos sea adecuado y
adicionalmente se minimice los costos de las llamadas, así mismo se maneja el
nivel municipal con relación a los puntos de atención, el cual sirve como un
concentrador de llamadas que recibe 10000 de los puntos de atención instalados. El
nivel municipal es el encargado de realizar la totalización de los datos individuales,
mientras que el nivel de atención es donde se genera el servicio al cliente.
Debemos tener en cuenta que este proyecto pretende transportar tanto las
transacciones realizadas por medio de datafonos o puntos de venta como el
enrutamiento de los diferentes establecimientos que prestan servicios de salud,
IEL2-I-2003-19 IEL2-I-2003-22
36
razón por la cual se hace indispensable en pensar en una jerarquía de mas niveles
como de enlaces dedicados en tres de estas categorías.
2.3.3 Red de comunicaciones propuesta para la solución en Colombia
Para un proyecto de una red en la cual únicamente se ofrezca el transporte de
transacciones similares a las financieras usando el formato ISO 8583, es
recomendable usar una jerarquía de solamente tres niveles, el nodo central el cual
será Bogota en donde se realizara la administración, gestión y consolidación de
datos de la red, nodos regionales (según la oferta del proveedor) los cuales serán
unos concentradores de las transacciones de la zona que les corresponde y por
ultimo los centros de asistencia, que serán cada uno de los puntos de atención en
donde se presta el servicio (tanto CAA’s como clínicas).
Es importante tener en cuenta que debido al manejo de la TPDU, la red deberá ser
necesariamente jerárquica y el esquema de esta dependerá totalmente del
proveedor como se vera a continuación:
2.4 PROPUESTAS USANDO LOS PROVEEDORES DE SERVICIOS
Dada la gran magnitud del proyecto, se recurrió a dos proveedores de servicios de
comunicaciones o “carriers”. Estos proveedores están en la misma capacidad de
ofrecer el servicio de comunicación, ya que todos cuentan con una completa
cobertura nacional, el cual es el factor determinante para la ejecución del proyecto.
Las compañías que nos ayudaron presentándonos sus servicios para que nosotros
hiciéramos el diseño de las soluciones para la comunicación de los puntos de
atención con el nodo central fueron Telecom, la cual mostro dos propuestas y por
otro lado Orbitel.
IEL2-I-2003-19 IEL2-I-2003-22
37
2.4.1 Propuesta usando los servicios de Telecom
Telecom ofrece dos soluciones las cuales cubren al 100% los requerimientos de las
entidades prestadoras de salud integrando en cada uno de los puntos solicitados
para servicios de datos. La base de las dos propuestas son las mismas, sus
diferencias radican en el numero de enlaces que se instalarían ya que en la primera
se tendrá dividido al país en los departamentos mas importantes del país y en la
segunda se dividirá en cinco sectores los cuales tendrán a cargo los puntos de
atención propios de cada uno de estos departamentos así como otros
departamentos.
Telecom ofrece servicio Frame Relay el cual provee un mecanismo de transferencia
de datos entre puntos extremos y la red misma. La relación costo / beneficio de
estos canales es muy ventajosa y sus características y operación garantizan
conectividad y alta confiabilidad.
La característica básica de una red Frame Relay es la habilidad de soportar
múltiples enlaces lógicos sobre una sola interfaz física. Esta técnica de acceso a
una red digital de alta velocidad, que mediante el establecimiento de Circuitos
Virtuales Permanentes (CVP) permite realizar conexiones punto multipunto a
diversas tasas de información concertada (CIR). Se entiende como Circuito Virtual
Permanente el trayecto definido en la red para interconectar dos puntos de acceso.
Frame Relay permite manejar aplicaciones de texto e imágenes, que requieren
desempeños importantes en tasas efectivas de transmisión y bajos retardos de
tránsito de la red debido a las demandas impuestas por el crecimiento en las redes
de área local y el advenimiento de ambientes cliente / servidor, que requieren
tiempos de respuesta muy rápidos.
La jerarquía que propone Telecom para una primera fase es de tres niveles, nivel
central, el cual se ubicara en Bogota, nivel departamental/regional y nivel sitio de
atención. La conexión entre los dos primeros niveles se realizara por medio de
IEL2-I-2003-19 IEL2-I-2003-22
38
enlaces permanentes y entre el segundo y tercer nivel se usara una conexión por
demanda de dial entre los puntos de atención y los nodos regionales.
FIGURA 9. Jerarquía de la red propuesta usando los servicios de Telecom
El esquema de conexión para el nivel central con el departamental será de la
siguiente manera:
FIGURA 10. Diagrama de conexión de los enlaces dedicados.
IEL2-I-2003-19 IEL2-I-2003-22
39
Así mismo, la conexión para los niveles de jerarquía 2 y 3 serán por medio de vía
discada, el diagrama de conexión de estos nodos seria de la siguiente manera:
FIGURA 11. Diagrama de conexión de los puntos de atención con su correspondiente nodo.
2.4.1.1 Solución departamental usando los servicios de Telecom: La primera
solución para conectar el país teniendo a Bogotá como nodo central, es a través de
la red Frame Relay de canales virtuales permanentes (CVP) con puertos de acceso
de 38.4 Kbps y CIR de 19.2 Kbps, en cada una de las departamentos mas
relevantes del país. Para lo cual se instalaran (15) enlaces en total ubicados en los
departamentos de Atlántico, Bolívar, Cesar, Córdoba, Magdalena, Norte de
Santander, Nariño, Boyacá, Caldas, Cauca, Huila, Quindío, Risaralda, Santander,
Tolima, por otro lado con el fin de garantizar un buen servicio ofrecen enlaces de 64
Kbps con un CIR 38.4 Kbps en los departamentos de Antioquia y Valle del Cauca,
los cuales son departamentos de alto generamiento de trafico. Estos enlaces se
conectaran a la oficina central de Bogotá por medio de una conexión punto
multipunto la cual manejará todo el tráfico generado por dichos departamentos, para
ello se propone un canal de 512 Kbps con un CIR de 512 Kbps, es decir un canal de
100% de efectividad.
IEL2-I-2003-19 IEL2-I-2003-22
40
2.4.1.1.1 Regionalización bajo esta primera propuesta Telecom: Debido a
que el Seguro Social maneja (28) departamentos y solo habrá (17) nodos
departamentales, se hace indispensable asignarle a aquellos departamentos que no
son nodos su correspondiente nodo principal. La elección del nodo departamental
se basa en la menor longitud posible debido a que Telecom ofrece sus tarifas bajo
este esquema. Colombia quedaría con el siguiente esquema de comunicación:
FIGURA 12. Regionalización por departamentos.
IEL2-I-2003-19 IEL2-I-2003-22
41
La regionalización quedaría de la siguiente manera:
Nodo departamental Departamento a cargo
Antioquia ChocoAtlantico San AndresBolivarCesarCordoba SucreMagdalena GuajiraNorte de SantanderNariño PutumayoBoyaca CasanareCaldasCaucaHuila CaquetaQuindioRisaraldaSantander AraucaTolimaValle del CaucaCundinamarca Meta, Amazonas
TABLA 1. Regionalización por departamentos
2.4.1.1.2 Estimación del tráfico: Para determinar el tráfico en cada uno de los
nodos departamentales, tuvimos que calcular previamente el número de cuotas
moderadoras que cada uno de dichos nodos iba a transportar teniendo en cuenta
que habrían nodos en donde se deberían transportar el trafico de departamentos
cuyo trafico es menor. Con estos datos y teniendo en cuenta que las entidades
financieras para su diseño de estiman un mensaje de 512 bytes en promedio para
su diseño logramos tener un estimado de bits/hora, con este resultado y teniendo en
cuenta que Telecom no me ofrece canales de menor capacidad, se determino la
utilización promedio del enlace, el cual como se puede observar en la tabla es
sumamente bajo, razón por la cual esta propuesta de antemano podemos decir que
bajo este esquema existe una sub utilización total de la red a un costo mucho mas
alto de lo que seria la propuesta sectorizada (2.4.1.2) debido a que a simple vista no
se necesitaría toda esta cantidad de enlaces para ofrecer un grado de servicio
adecuado. A continuación podemos ver una tabla con el número histórico de cuotas
moderadoras recaudadas en los meses picos con sus respectivos estimados.
IEL2-I-2003-19 IEL2-I-2003-22
42
Nodo departamental Total cuotas
Total trafico por
horaCIR Enlace Utilizacion
Antioquia 715,9 2.932.265,7 38.400,0 0,02121141Atlantico 334,0 1.367.976,8 19.200,0 0,01979133Bolivar 159,0 651.085,7 19.200,0 0,00941964Cesar 74,9 306.744,9 19.200,0 0,00443786Cordoba 113,8 466.174,1 19.200,0 0,00674442Magdalena 165,4 677.436,7 19.200,0 0,00980088Norte de Santander 91,6 375.098,8 19.200,0 0,00542678Nariño 145,6 596.271,4 19.200,0 0,00862661Boyaca 180,4 738.827,4 19.200,0 0,01068905Caldas 204,1 836.099,8 19.200,0 0,01209635Cauca 119,4 489.013,1 19.200,0 0,00707484Huila 153,0 626.748,7 19.200,0 0,00906754Quindio 109,5 448.330,0 19.200,0 0,00648626Risaralda 180,2 738.023,3 19.200,0 0,01067742Santander 369,6 1.513.824,7 19.200,0 0,0219014Tolima 223,1 913.696,2 19.200,0 0,01321898Valle del Cauca 1.050,8 4.303.974,4 38.400,0 0,03113407Cundinamarca 1.878,0 7.692.458,7
0,01222382Promedio TABLA 2. Trafico generado con el esquema departamental.
2.4.1.1.3 Propuesta económica7: Telecom ofrece los siguientes precios de
enlaces, los cuales incluyen la instalación y mantenimiento mensual incluyendo la
ultima milla. Dado que la Convocatoria Pública V.EPS No. 012-01 de 20028,
estipula que se contratara el servicio durante un periodo de dos años prorrogable a
tres años, se realizara una negociación con Telecom durante este periodo, con los
siguientes precios:
7 Juan Ramón Sanchez, Propuesta canales nacionales Frame Relay, Vicepresidencia Comercial Telecom. Marzo 2003. 8 www.iss.gov.co, Vicepresidencia de EPS, “expedición de comprobantes de pago, recaudo y transferencia de dineros provenientes de las cuotas moderadoras y de los copagos en el Instituto del Seguro Social. Dicembre 2002.
IEL2-I-2003-19 IEL2-I-2003-22
43
RED NACIONAL Enlaces Frame Relay
MensualidadPUERTO CIR 2 AÑOS
Antioquia 64K 38.4K $ 885.000 $ 1.078.756Atlántico 38.4K 19.2K $ 885.000 $ 836.618Bolivar 38.4K 19.2K $ 885.000 $ 836.618Cesar 38.4K 19.2K $ 885.000 $ 836.618
Cordoba 38.4K 19.2K $ 885.000 $ 836.618Magdalena 38.4K 19.2K $ 885.000 $ 836.618
Norte de Santander 38.4K 19.2K $ 885.000 $ 836.618Nariño 38.4K 19.2K $ 885.000 $ 836.618Boyaca 38.4K 19.2K $ 885.000 $ 836.618Caldas 38.4K 19.2K $ 885.000 $ 836.618Cauca 38.4K 19.2K $ 885.000 $ 836.618Huila 38.4K 19.2K $ 885.000 $ 836.618
Quindío 38.4K 19.2K $ 885.000 $ 836.618Risalda 38.4K 19.2K $ 885.000 $ 836.618
Santander 38.4K 19.2K $ 885.000 $ 836.618Tolima 38.4K 19.2K $ 885.000 $ 836.618Valle 64K 38.4K $ 885.000 $ 1.078.756
Bogotá 512K $ 590.000 $ 1.953.516$ 15.635.000 $ 16.660.298
CARGOS
InstalaciónCiudad Canal Nacional
TABLA 3. Costos de enlaces para el esquema departamental.
Los precios de las llamadas de larga distancia se explicaran en detalle en el numeral
2.4.1.3.
2.4.1.1.4 Determinación del número de líneas telefónicas primera propuesta: Con el
fin de poder ofrecer un adecuado servicio en cuanto a las llamadas para realizar
autorizaciones o consolidaciones con el nodo remoto – central según sea el caso, se
tuvo que realizar un estudio sobre el número de líneas necesarias en cada uno de
los nodos para cierta probabilidad de bloqueo. Para poder determinar este
parámetro se tuvo que usar teoría de colas y se concluyo que:
IEL2-I-2003-19 IEL2-I-2003-22
44
TU = {[( TPD x t) / (8.64 x 104)] x NT } x PR
Donde: TU = Unidades de trafico
TPD = Transacciones por día por terminal.
t = Tiempo que se demora una transacción en transmitirse.
8.64 x 104 = Numero de segundos en un día.
NT = Numero de terminales.
PR = Relación del pico de trafico.
Esta formula es usada a nivel mundial en el sector financiero, una vez se tenga el
valor determinado de las unidades de tráfico9, se mira la tabla Erlang y se determina
el número de líneas necesarias para las diferentes probabilidades de bloqueo, a
continuación mostramos la tabla correspondiente a esta propuesta:
Nodo Departamental
Departamento a cargo
Unidades de trafico 0.2% 0,50% 1%
Antioquia Choco 1,67 7 7 6Atlantico San Andres 0,78 5 5 4Bolivar 0,37 4 4 3Cesar 0,17 3 3 3Cordoba Sucre 0,27 4 3 3Magdalena Guajira 0,39 4 4 3Norte de Santander 0,21 3 3 3Nariño Putumayo 0,34 4 3 3Boyaca Casanare 0,42 4 4 3Caldas 0,48 4 4 4Cauca 0,28 4 3 3Huila Caqueta 0,36 4 4 3Quindio 0,26 4 3 3Risaralda 0,42 4 4 3Santander Arauca 0,86 5 5 4Tolima 0,52 4 4 4Valle del Cauca 2,45 9 8 7Cundinamarca Meta, Amazonas 4,38 12 11 10
88 82 72
PRIMERA PROPUESTA
TOTALES
PROBABILIDAD DE BLOQUEO
TABLA 4. Determinación del numero de líneas telefónicas primera propuesta.
9 The Hypercom Networking Cookbook, Julio 20 de 1997.
IEL2-I-2003-19 IEL2-I-2003-22
45
La relación pico trafico es de 1,4 ya que para esta red tendrá consolidaciones
constantes, lo que hace que el pico no sea mucho mayor al de una hora normal. Por
otro lado tenemos que TPD x NT es el numero de cuotas por día, el cual lo
conocemos.
Como podemos ver se necesitan un número bastante apreciable de líneas
telefónicas, este número se pueden disminuir concentrando puestos de atención
para que llamen a un solo nodo, es decir que se realice algún tipo de zonificación.
Por otro lado es recomendable usar una probabilidad de bloque de 1% ya que para
este proyecto se podrían realizar programaciones, las cuales nos den un margen
para evitar el bloqueo de la línea, en otras palabras las llamadas no son tan
aleatorias.
2.4.1.2 Solución regionalizada usando los servicios de Telecom: La segunda
propuesta consiste en sectorizar el país en cinco regiones, las cuales tendrán a su
cargo los puestos de salud propios del departamento y adicionalmente serán
responsables de los departamentos de su sector. Para conectar el país teniendo a
Bogotá como nodo central (Zona 1) y siguiendo este concepto, Telecom ofrece que
se conecten a través de la red Frame Relay canales virtuales permanentes (CVP)
con puertos de acceso de 64 Kbps y CIR de 38.4 Kbps, en cada una de las
regionales ubicadas en Barranquilla (Zona 2) Medellín (zona 3), Cali (Zona 4) y
Bucaramanga (Zona 5). La conexión se realizara por medio de un enlace punto
multipunto con la oficina central de Bogotá la cual consolidara toda la información
del país, para cumplir este objetivo se propone un canal de 256 Kbps con CIR de
256 Kbps.
2.4.1.2.1 Regionalización bajo el esquema de la segunda propuesta Telecom: El
nodo central el cual se ubicara en Bogota (Zona 1), tendrá la función de recibir las
llamadas de los puntos de atención del sector asignado a este nodo y por otro lado
tendrá la función de recibir los enlaces de los demás nodos remotos. A su vez los
nodos remotos tendrán un sector predefinido (ver tabla 4), con esta asignación de
zonas cada establecimiento prestador de servicios de salud tendrá un nodo
asignado. Para conectarse al nodo asignado el establecimiento deberá realizar la
IEL2-I-2003-19 IEL2-I-2003-22
46
llamada por medio de la red pública telefónica conmutada al nodo asignado y este
se encargara de enlutarla a su destino final. La jerarquía se conserva con respecto
a la propuesta anterior.
Zona 1 Zona 2 Zona 3 Zona 4 Zona 5
Cundinamarca Guajira Antioquia Valle Santander
Bogota Atlántico Choco Cauca N. Santander
Tolima Bolívar Risaralda Nariño Arauca
Meta Magdalena Quindío Putumayo Cesar
Huila Sucre Caldas Caquetá Casanare
Boyacá San Andrés Córdoba Amazonas TABLA 5. Regionalización por Zonas
FIGURA 13, Regionalización por zonas.
IEL2-I-2003-19 IEL2-I-2003-22
47
2.4.1.2.2 Estimación del tráfico: Los datos que se lograron obtener para determinar
el estimado del trafico son el numero de cuotas moderadoras pagadas en los meses
picos. Para poder lograr el objetivo de determinar la cantidad de información que
viaja a través de la red con el esquema sectorizado, se tuvo que tener en cuenta el
tráfico de cada uno de los departamentos y adicionarlos a su zona correspondiente
para tener el estimado del nodo. La siguiente tabla muestra el tráfico total de la red
con los cuatro (4) enlaces propuestos, se debe tener en cuenta que al ser el
número de enlaces menor que en la propuesta anterior, Telecom solamente ofrece
una capacidad de 64K con un CIR de 38,4K.
Zona Cuotas dia Cuotas hora Trafico en bits/hora CIR Enlace Utilizacion
Zona 1 28.711,1 1.794,4 7.350.033,1Zona 2 8.327,0 520,4 2.131.720,5 38400 0,01542043Zona 3 15.454,4 965,9 3.956.323,6 38400 0,02861924Zona 4 16.128,5 1.008,0 4.128.896,0 38400 0,02986759Zona 5 6.596,0 412,2 1.688.564,6 38400 0,01221473
0,0215305Promedio TABLA 6. Trafico con el esquema zonificado
Como podemos apreciar en la tabla, la utilización de la red de comunicaciones es
mayor que en la propuesta anterior y al mismo tiempo sigue siendo muy baja
(promedio de 0,022) con lo cual podemos garantizar que no habrá congestión en la
red y que los costos son mucho menores a los de la propuesta departamental.
2.4.1.2.3 Propuesta económica10: Al igual que en la propuesta pasada, cotizamos
con Telecom los precios de enlaces, los cuales incluyen la instalación y
mantenimiento mensual incluyendo la ultima milla. Dado que el número de enlaces
es mucho menor que en la propuesta anterior Telecom solo ofrece enlaces de una
capacidad de 64 K con un CIR de 32K. A continuación presentamos los costos y las
condiciones comerciales para una posible negociación con la empresa.
10 Juan Ramón Sanchez, Propuesta canales nacionales Frame Relay, Vicepresidencia Comercial Telecom. Marzo 2003.
IEL2-I-2003-19 IEL2-I-2003-22
48
RED NACIONAL Enlaces Frame Relay
TABLA 7. Costos de enlaces esquema zonificado.
La propuesta económica se basa en los siguientes valores:
Valores fijos de instalación para los canales de acceso, últimos kilómetros y
equipos de último kilómetro.
Valores mensuales de arriendo para los canales de acceso, últimos
kilómetros y equipos de último kilómetro.
Valores mensuales para operación y mantenimiento
En los valores de últimos kilómetros están incluidos los equipos necesarios tales
como:
Par aislado Modems Banda Base en las ciudades de Medellín, Bucaramanga,
Barranquilla y Cali
Red digital F.O. / Modems en el sitio central en Bogotá
No se incluyen equipos de fuerza y regulación de alimentación tales como UPS,
generadores, mástil para antenas de radio enlace, obras civiles, viáticos, etc.
Todos los canales tienen como destino a Bogotá.
Instalación MensualidadPUERTO CIR 2 AÑOS
Medellín 64K 38.4K $2,045,088 $1,078,756Bucaramanga 64K 38.4K $2,045,088 $1,078,756Barranquilla 64K 38.4K $1,873,625 $1,185,940
Cali 64K 38.4K $2,045,088 $1,078,756Bogotá 256K $2,180,000 $1,953,516
$10,188,888 $6,375,724
Ciudad Canal NacionalTotal
IEL2-I-2003-19 IEL2-I-2003-22
49
2.4.1.2.4 Determinación del número de líneas telefónicas segunda propuesta: De la
misma manera que se determinaron las líneas telefónicas para la primera
propuesta, en este segundo esquema se realizo el mismo análisis para las tres
diferentes probabilidades de bloqueo dándonos como resultado la siguiente tabla:
Zona Unidades de trafico 0.2% 0,50% 1%
Zona 1 5,58 14 13 12Zona 2 1,62 7 6 6Zona 3 3,01 10 9 8Zona 4 3,14 10 9 8Zona 5 1,28 6 6 5
47 43 39
SEGUNDA PROPUESTA PROBABILIDAD DE BLOQUEO
TOTALES TABLA 8. Determinación de número de líneas telefónicas segunda propuesta
Como podemos ver comparando estas dos tablas, teniendo en cuenta esta segunda
alternativa se reduce notablemente el número de líneas telefónicas que se necesitan
para poder prestar el mismo servicio con los mismos puntos de atención. Este
fenómeno se debe a que a medida que aumentan los puntos de atención (se
sectorizan) y se tiene que llamar a un solo lugar se necesitara aumentar cada vez
en menor proporción el numero de líneas telefónicas.
2.4.1.3 Plan corporativo de larga distancia Telecom11: Telecom es el proveedor
de servicios de larga distancia más antiguo en el país. Sus tarifas están
estandarizadas con respecto a la Resolución 00100000-0408 en donde se
establecen los precios del minuto teniendo en cuenta las bandas (distancias entre
los lugares de conexión). Los siguientes son los precios que ofrece Telecom, bajos
su tarifa estándar:
11 Juan Ramón Sanchez, Propuesta canales nacionales Frame Relay, Vicepresidencia Comercial Telecom. Marzo 2003.
IEL2-I-2003-19 IEL2-I-2003-22
50
LARGA DISTANCIA NACIONAL - Resolución 00100000-0408 BANDAS DISTANCIA
Km. Valor Minuto Horario
Pleno de 8:01 AM a 8:00 PM. de Lunes a Viernes
Valor Minuto Horario Reducido de 8:01 PM a 8:00 AM de Lunes a Viernes, Sábados, Domingos y
Festivos 24 Horas A 0- 100 $280.oo $182.oo B 100-200 $452.oo $293.80 C Más de 200 $661.oo $429.65
TABLA 9. Larga distancia Nacional.
Sin embargo debido a que el requerimiento del Seguro Social es bastante exigente
en cuanto al número de consolidaciones se exige que por cada puesto de atención
se hagan entre 15 a 20 consolidaciones, es decir mas o menos una consolidación
por hora, lo cual nos da como resultado 250000 minutos al mes, lo cual seria
número suficiente para ofrecernos su solución de “PLAN DE LARGA DISTANCIA
CORPORATIVO”, la cual posee grandes ventajas estratégicas, que se verán como
valores agregados como:
Mayor Índice de Completación: Teniendo en cuenta la calidad, capacidad y
cobertura de la redes de Telecom, se podrá asegurar que se puede tener los
mayores índices en llamadas completadas.
Beneficios Económicos Exclusivos: De acuerdo a la información del promedio
de tráfico, el esquema económico propuesto se describe a continuación:
Rango de Facturación Minutos Descuento
Inferior o Igual a 200.000 55%
Superior a 200.000 60% TABLA 10. Rangos de facturación.
Sin embargo debido a que el proyecto es muy ambicioso y las distancias entre dos
lugares con el nodo ya sea departamental o remoto (propuesta 1 y propuesta 2),
Telecom se compromete a cobrar una tarifa única de $208 el minuto, sin importar la
distancia.
IEL2-I-2003-19 IEL2-I-2003-22
51
2.4.1.4 Valores adicionales de la propuesta de Telecom: En su búsqueda de ser
una compañía cada vez más competente, Telecom ofrece servicios como valores
agregados que ayudan a la ejecución de cualquier proyecto,
Centro de Gestión: Para la atención a fallas, Telecom ha desarrollado un
CRM que tiene:
Un “CALL CENTER” con atención toda la semana, todos los días de la semana
(7x24), en donde se podrá reportar cualquier falla o inconveniente en la
prestación del servicio. El número de dicho centro es el 018000-9-10909.
Este servicio de “CALL CENTER” está en línea con una herramienta de
“VANTIVE”, que posee una base de datos con información de todos los clientes,
servicios instalados y responsable por la atención a eventuales fallas. Dicho
sistema asigna un número de caso o TICKET NUMBER. Este número de caso
permite hacer seguimiento a su falla y así el “CALL CENTER” mantendrá
informado de los avances y desarrollos en la solución a la falla.
Este sistema de atención tiene sus propios niveles de escalamiento a fallas.
Desde el momento en que se genera una llamada, el caso es registrado en el
sistema, automáticamente éste envía copia del caso abierto a los directamente
responsables, será recibido inicialmente por un técnico de soporte de la red de
datos, quien integrará la solución de Ultimo kilómetro al problema para revisar si
es esta el origen de la misma, si en este nivel la falla no es detectada, se escala
después de 30 minutos automáticamente por el sistema o por el técnico a la
siguiente área involucrada, en donde harán las pruebas necesarias.
Durante todo el proceso de revisión y solución de fallas se podrá llamar al
número 0180009 antes mencionado y preguntar por el estado de evolución del
problema con el número de caso asignado. Como el sistema trabaja en línea, el
operador del “CALL CENTER” le podrá informar lo que los técnicos han
anotado sobre el respecto.
IEL2-I-2003-19 IEL2-I-2003-22
52
Facturación del tiempo real al aire: Telecom facturará el tiempo real al aire
de las llamadas cursadas por dicha red después del primer minuto. Esto es,
como mínimo se cobra un minuto, después del cual se factura proporcional
al tiempo real de la llamada.
Facturación Centralizada: Telecom tiene la posibilidad de llevar a cabo una
facturación centralizada en la ciudad donde se desee, esto le permite llevar
un control presupuestal por centro de costos.
Inclusión Servicios de Cobro Revertido 0180009s: Es posible incluir las
líneas 0180009s que se posea con Telecom dentro del Plan de larga
distancia corporativo.
Software de Gestión y Análisis: Si desea la modalidad de facturación
directa, Telecom instala en la oficina del cliente un software especializado el
cual a través de reportes gráficos, permite obtener información oportuna y
confiable para realizar la gestión del tráfico y del consumo en las
comunicaciones de larga distancia.
2.4.2 Propuesta utilizando los servicios de Orbitel
Esta compañía a diferencia de Telecom, sugiere disminuir la inversión inicial debido
a la compra de equipos de comunicaciones para la conexión de los enlaces, y
sugiere que se realice una única conexión a Bogota por medio de un E-1. Para
lograr este objetivo Orbitel ofrece un plan de más de 300000 minutos al mes a un
costo de 248 pesos. Este plan lo genera por medio de una línea 01800-05, la cual
es una solución en telecomunicaciones que facilita el contacto directo entre la
compañía y los clientes, incrementa la lealtad y ofrece una imagen más competitiva
de la empresa.
IEL2-I-2003-19 IEL2-I-2003-22
53
A través del 01800 los operadores, proveedores y distribuidores pueden llamar, sin
costo alguno, al nodo central para ordenar pedidos, presentar quejas y reclamos y
suministrar información, lo que contribuye a la reducción de costos a la hora de
hacer negocios. Así mismo, puede promocionar y vender productos, realizar
investigaciones de mercado, brindar atención al cliente y agilizar las comunicaciones
internas.
2.4.2.1 Jerarquía del sistema usando los servicios de Orbitel: Orbitel no presta
servicios de enlaces dedicados, razón por la cual se deberá utilizar una jerarquía de
dos niveles si se deseara contratar los servicios de la compañía, es decir tenemos
los puntos de atención por todo el país y cada vez que se desea realizar una
consolidación o cierre se deberá generar una llamada al nodo de Bogota el cual
tendrá disponible particiones de E-1. El siguiente es el esquema de conexión para
esta propuesta.
FFIIGGUURRAA 1144.. CCoonneexxiióónn OOrrbbiitteell
2.4.2.2 Determinación del número de líneas telefónicas Orbitel: Al igual que con
las propuestas realizadas con Telecom, se debe determinar el número de líneas
telefónicas para la adecuada prestación del servicios. En este caso el país completo
TCP/IP
Red PúblicaTeléfonica
ConmutadaNacional (PSTN)
Host Bogotá
Network Syst emsIntegrated Enterprise Network
CONEXIÓN E-1
Puntos de Atención
IEL2-I-2003-19 IEL2-I-2003-22
54
llamara a Bogota, razón por la cual se deberán sumar las unidades de tráfico
anteriormente halladas y con este resultado determinar el número de líneas
telefónicas con las cuales se deberá contar para la prestación de un adecuado
servicio.
Zona Unidades de trafico 0.2% 0,50% 1%
Colombia 14,63 27 25 24
PROPUESTA ORBITEL PROBABILIDAD DE BLOQUEO
TABLA 11 Determinación número de líneas telefónicas Orbitel
Con estos resultados nos podemos ver que una conexión a un E-1 es suficiente ya que esta cuenta con 30 canales. De esta manera se esta garantizando un adecuado servicio para una probabilidad de bloque menor a un 0.2%. 2.4.2.3 Propuesta económica de Orbitel12: Como habíamos mencionado anteriormente el costo del minuto nacional seria de 248 pesos. Adicionalmente debemos tener en cuenta los costos de mantener un E-1 y de su correspondiente instalación Conexión de E-1: 10`034.726. Mensualidad: 367.341. Impulso: 71.
En su búsqueda de la prestación de un excelente servicio, Orbitel ofrece los
siguientes servicios como valores agregados al contrato sin costo alguno.
TTrraannssffeerreenncciiaa oorrddiinnaarriiaa:: Las llamadas originadas a su línea 01800 son
desviadas al número telefónico que se desee.
EEnnrruuttaammiieennttoo ddee LLllaammaaddaass DDeeppeennddiieennddoo ddeell HHoorraarriioo:: Se puede escoger
en cual línea telefónica desea atender las llamadas dependiendo del día y
la hora en que son realizadas.
12 Juan Carlos Uribe Rodríguez, Propuesta Comercial servicio 01800 para datos, Marzo 2003
IEL2-I-2003-19 IEL2-I-2003-22
55
EEnnrruuttaammiieennttoo DDeeppeennddiieennddoo ddeell OOrriiggeenn:: Su empresa puede escoger hacia
que línea telefónica desviar las llamadas, dependiendo del lugar donde éstas
se originen.
DDiissttrriibbuucciióónn ddee LLllaammaaddaass:: Permite atender a sus clientes desde varias
líneas telefónicas, programando el número 01800 en el orden en que van a
entrar las llamadas a cada línea.
SSeelleecccciióónn ddee LLllaammaaddaass EEnnttrraanntteess ((lliissttaa bbllaannccaa,, lliissttaa nneeggrraa)):: Permite
habilitar o bloquear los destinos desde los cuales se quiere atender el
servicio.
AAuutteennttiiccaacciióónn:: Permite restringir el servicio de la línea 01800 solo a las
personas que digiten la cuenta y clave validas.
TTrraannssffeerreenncciiaa ddee llaa LLllaammaaddaa ccuuaannddoo llaa llíínneeaa eessttéé ooccuuppaaddaa:: Si el número
telefónico que atiende la línea 01800 se encuentra ocupado, es posible
habilitar un número adicional de atención al que se desviarán las llamadas
para prevenir que se pierdan.
2.4.3 Determinación de la propuesta más viable
Como se puede ver, cada una de sus propuestas tienen sus pros y sus contras, por
ejemplo la primera propuesta de Telecom seria adecuada para transportar no solo
transacciones sino además datos e inclusive voz empaquetizada, sin embargo para
iniciar el proyecto una red como la de la segunda propuesta es mas viable, ya que
necesita menor inversión inicial y sus costos de mantenimiento mensuales son
menores.
Para realizar un estimado del costo mensual, decidimos comparar los costos de
segunda propuesta usando los servicios de Telecom frente a los costos de
IEL2-I-2003-19 IEL2-I-2003-22
56
mantenimiento de la propuesta teniendo en cuenta los servicios que presta Orbitel.
Los resultados son los siguientes:
Propuesta con Orbitel Cantidad Costo
unitario Costo Total Cargo Básico E-1 1 367,341 367,341 Minutos locales 40,000 72 2,880,000 Minutos larga distancia 260,000 248 64,480,000
COSTO TOTAL ORBITEL 67,727,341
Segunda Propuesta Telecom Cantidad Costo
unitario Costo Total Costo de enlaces 1 6,375,724 6,375,724 Minutos locales 80,000 72 5,760,000 Minutos larga distancia 220,000 208 45,760,000 Cargo Básico líneas 43 10,800 464,400
COSTO TOTAL TELECOM 58,360,124
Como Podemos ver en las tablas, la propuesta de Telecom es mas económica por
una diferencia de cerca de 9,5 millones, adicionalmente con esta propuesta se
podría pensar en instalar servicios de valor agregado, lo cual hace que sea una
propuesta mas viable para el proyecto.
El número de minutos se dedujo teniendo en cuenta los puntos de atención
instalados en cada departamento, este resultado se deberá multiplicar por 20
(cierres y autorizaciones por día) y se deberá agrupar por grupos en llamadas
locales y larga distancia nacional.
IEL2-I-2003-19 IEL2-I-2003-22
57
3. ESTUDIO TECNICO DE LA TI
El objetivo fue realizar un estudio básico de la TI teniendo como puntos de
referencia:
• Estándar ISO/IEC 78161, 7816-2, 7816-3 y 7816-4
• Manual de la tarjeta HOST
• BIBLIOGRAFIA REFERENTE A TI
En base a las anteriores fuentes, realizamos una síntesis de la información básica
necesaria para enmarcar todo lo referente a la TI. Gracias a este estudio previó se
pudo realizar la aplicación implementando con éxito la TI.
3.1 TARJETAS CON CHIP Y MAGNETICAS13
3.1.1 Concepto del Monedero Electrónico Como se puede observar en la vida diaria, el pago con dinero en efectivo tiende a
desaparecer y cada vez es mas popular el uso de tarjetas para pagar (en su
mayoría tarjetas de banda magnética). Sin embargo con la aparición de las tarjetas
inteligentes, como garantes de seguridad, ha aparecido un nuevo esquema de
“monedero electrónico” y de “dinero electrónico o digital”.
Para explicar la aplicación de monedero electrónico, es necesario hacer una breve
reseña sobre la tarjeta de banda magnética.
3.1.2 Tarjeta Magnética 13 Tarjetas Inteligentes. Cap. 10.
IEL2-I-2003-19 IEL2-I-2003-22
58
3.1.2.1 Características Técnicas: Todas las características técnicas de este tipo de
tarjetas, tales como su peso, tamaño, partes, forma de lectura y escritura y demás
están especificadas en la norma ISO 7811. Poseen una banda magnética separada
del borde superior en 5.54 mm con un ancho de 10.28 mm. La banda a su vez esta
subdividida en tres sub-bandas con ancho de 2.54 mm cada una y separadas entre
si por 0.76 mm (vease la siguiente figura)
FIGURA 14. Locación y tamaño de las bandas magnéticas.
Cada sub-banda posee una función determinada:
• La primera, y mas cercana al borde superior, tiene una capacidad de 210 bpi
(bits por pulgada), y puede almacenar hasta 79 caracteres. Los primeros 18
caracteres se usan para almacenar el número de cuenta o identificación, los
siguientes 26 codifican el nombre del propietario y el resto se usa para datos
IEL2-I-2003-19 IEL2-I-2003-22
59
adicionales tales como fecha de expedición, restricciones, tipo de tarjeta, etc.
Esta sub-banda suele utilizarse en operaciones de ticket.
• La segunda sub-banda tiene una capacidad de 75 bpi, con lo que puede
almacenar hasta 40 caracteres. Los primeros 19 se utilizan para almacenar el
número de cuenta y el resto para datos adicionales. Esta sub-banda tiene
aplicaciones en campos como transacciones de carácter financiero tipo online.
• La tercera, y última sub-banda se utiliza en transacciones financieras
incorporando además mecanismos de seguridad claro esta. La información
como número de cuenta, identidad del usuario, unidad monetaria, cantidad
máxima retirable, etc. es cifrada (encriptada) con un PIN (Personal Identification
Number). Este es el número que se le pide al usuario para realizar las
operaciones. Esta sub-banda contiene un máximo de 107 caracteres teniendo
una capacidad total de 210 bpi. Es además la única banda que puede ser
alterada cada vez que se usa la tarjeta.
3.1.2.2 Almacenamiento y Tipo de Información Guardada: El procedimiento para
almacenar la información en una tarjeta de banda magnética es análogo al proceso
que se implementa en las cintas magnéticas, en el que lectores/escritores producen
campos magnéticos variables mediante bobinas con lo que se logran polarizar de
cierta forma las partículas magnetizadas de la tarjeta. Esto se hace bajo ciertas
condiciones y con ciertos equipos que trabajan en detalle por lo que la información
que se guarda en la tarjeta es de cierta forma segura
Como se tienen 3 sub-bandas a trabajar es obvio que la sub-banda a escoger
dependerá del uso específico que se le quiera dar a la tarjeta. Así cuando se
necesita para realizar pagos, la escogida será la tercera sub-banda.
3.1.2.3 Uso Como Forma De Pago: Las tarjetas de banda magnética como VISA,
MASTER CARD, AMERICAN EXPRESS, etc, utilizan la misma técnica para hacer
pagos. Estas tarjetas siempre tienen una cuenta bancaria asociada, en la cual se
encuentran los fondos reales o de crédito que se autorizan gastar al titular de la
cuenta. Analizando la forma en que ocurre la transacción vemos:
IEL2-I-2003-19 IEL2-I-2003-22
60
• Primero se leen los datos de la tarjeta en el momento en que se pasa por el
lector de banda magnética asociado a la entidad bancaria.
• Dichos datos al igual que algunos del establecimiento son enviados a la central
del banco, junto con los propios de la transacción.
• La central del banco certifica los datos y decide que acción seguir, si permitir o
no la transacción.
• Si la operación es aceptada se le informa al establecimiento la decisión.
3.1.3 Dinero Electrónico El dinero electrónico no es más que dinero trabajado de manera tal que no se
necesita de la moneda física o de papel para realizar la transacción, solo de poseer
una tarjeta y de consolidar datos de alguna forma. Además debe cumplir con las
siguientes características:
• Independencia: Debe tener la capacidad de poder usarse independientemente
del lugar.
• Privacidad: Debe protegerse la privacidad del usuario, su uso no debe portar
información que lo identifique.
• Pagos Off-line: El pago de cualquier producto o servicio no debe depender de
una red de comunicaciones que valide la transacción.
• Transferibilidad: El dinero debe poder ser transferido entre usuarios sin límite.
• Diversibilidad: Una pieza de dinero digital ha de poder dividirse en unidades
menores y también se ha de poder recombinar unidades pequeñas en otras
mayores.
Como es claro ciertas de estas propiedades no caracterizan al papel moneda o la
moneda corriente y hacen del dinero electrónico una herramienta más útil.
• Dinero On-line y dinero Off-line: Se refiere a que se hace la transacción con
conexión en línea o sin conexión con cierta base de datos (Bancos,
corporaciones crediticias, etc.) El dinero online necesita que el sitio donde se va
IEL2-I-2003-19 IEL2-I-2003-22
61
a hacer la transacción este conectado, por medio de algún tipo de red, a un
banco u oficina central que certifique la transacción. En cambio el dinero offline
no necesita de consolidar mediante una red, como el papel moneda, pues el
mismo es garante de su autenticidad (posee alguna forma de autocertificarse
frente a quien lo recibe).
Además el pago offline posee la ventaja de la privacidad pues al no requerir de
la consolidación con la central, esta no puede saber ni el sitio ni quien realizó la
transacción.
• Doble Gasto: Se refiere a que a diferencia del papel moneda, en el que se debe
gastar para la creación, seguridad y la autenticación de los billetes y monedas
(gastar cierto dinero para la creación de dinero), el dinero electrónico se puede
copiar tantas veces se quiera y solo se necesita de ciertas aplicaciones
electrónicas para brindar confiabilidad en él.
• Firma Digital: La firma digital se usa ampliamente en el dinero electrónico para
certificarlo; esta es proveída por los bancos emisores garantizando de esta
forma la autenticidad de la moneda.
3.1.4. Tarjeta Inteligente VS Tarjetas Magnéticas
Propiamente el monedero electrónico es la combinación de tarjeta inteligente y
moneda digital o electrónica. La tarjeta ofrece la garantía del acceso seguro a dicho
monedero y el manejo electrónico de este.
Las tarjetas magnéticas centran su seguridad en el PIN que posee la tarjeta y que
debe saber el usuario. El problema surge cuando se trata de hacer la transacción en
una entidad diferente a la del usuario, en este caso debe enviarse toda la
información al banco central para que sea autorizada y es aquí cuando se puede
quebrar la seguridad del sistema.
IEL2-I-2003-19 IEL2-I-2003-22
62
Otro problema que puede surgir es el que es conocido como “Caballo de Troya” o
Skimming en el que es uso de un terminal poco seguro puede llevar a la copia de la
información que se encuentra almacenada en la banda magnética y la información
del PIN en el momento de digitarse. De esta forma, si se logra tener toda esta
información, podría clonarse y utilizarse de manera fraudulenta.
El monedero electrónico posee todas las garantías de seguridad dadas por los
algoritmos criptográficos, las autenticaciones necesarias y la confidencialidad que
son características de las tarjetas inteligentes. De tal manera si por si algún motivo
se logra utilizar el dinero electrónico de una tarjeta robada, es posible invalidarlo
reportando previamente al banco del hecho y de esta forma la entidad lo único que
hace es invalidar el uso de dicho dinero (pues posee el número de serie del dinero).
3.2 TIPOS DE TARJETA CON CIRCUITO INTEGRADO14
Es común escuchar el término tarjeta inteligente para designar a todas las tarjetas
que poseen contactos dorados o plateados. Sin embargo la ISO (Internacional
Standard Organization) prefiere utilizar el término “Tarjeta de Circuito Integrado”
(Integrated Circuit Card o ICC). Este dispositivo tiene la capacidad de transmitir,
almacenar y procesar datos. La transferencia de datos puede realizarse a través de
los contactos metálicos que posee la tarjeta o sin contactos vía inducción
magnética. (Tarjetas con contacto y sin contacto).
Estas tarjetas poseen ventajas frente a las tarjetas de banda magnética:
• Son capaces de almacenar mayor información (hasta 60 Kbytes).
• Pueden proteger la información almacenada de posibles accesos no
autorizados.
• Poseen una mayor resistencia al deterioro de los datos almacenados.
14 Gráficas tomadas de: Tarjetas Inteligentes. Cap.1
IEL2-I-2003-19 IEL2-I-2003-22
63
Como el acceso a la información se realiza a través de un puerto serial y con
supervisión del sistema operativo de la tarjeta, es posible controlar las funciones de
lectura, escritura y modificación de datos vía software o hardware lo que permite
una mayor diversidad de mecanismos para la seguridad del manejo de la
información.
Como el chip, es el componente determinante en la utilidad de una tarjeta, estas
pueden ser clasificadas de la siguiente forma:
• Tarjetas de memoria.
• Tarjetas de memoria con circuitos de seguridad.
• Tarjetas con CPU o tarjetas inteligentes.
3.2.1 Tarjetas De Memoria
Los datos que se necesitan para aplicaciones con tarjeta de memoria son almacenados
en una EEPROM (Electrical Erasable Programable Read Only Memory). El acceso a
esta no es controlado y por tanto no hay protección ya sea para la escritura o la lectura
de datos en la memoria.
Las funciones que desempeñan estas tarjetas son muy simples por lo que no se
necesita de mecanismos complejos para su control. Una aplicación común de esta
tarjeta de memoria son las tarjetas de pago en cabinas telefónicas.
IEL2-I-2003-19 IEL2-I-2003-22
64
FIGURA 15. Esquema de Bloques de la arquitectura de una Tarjeta de Memoria
3.2.2 Tarjetas De Memoria Con Circuitos De Seguridad
El circuito de seguridad proporciona un sistema para el control del acceso a los
datos de la memoria con el fin de impedir que usuarios no autorizados acceden a la
información almacenada. El sistema funciona mediante el empleo de un código de
acceso que puede ser de 64 bits o incluso mayor.
FIGURA 16. Esquema de Bloques de la arquitectura de una Tarjeta de Memoria con Circuito de Seguridad
3.2.3 Tarjetas Inteligentes
Estas tarjetas poseen en el chip un microprocesador que además cuenta con
algunos elementos adicionales. Por tanto estas tarjetas poseen:
• Microprocesador
• ROM enmascarada
• EEPROM
• RAM
IEL2-I-2003-19 IEL2-I-2003-22
65
• Un puerto de Entrada/Salida
La ROM (Read Only Memory) contiene el sistema operativo de la tarjeta y se crea
durante el proceso de fabricación. La EEPROM es la memoria no volátil del
microprocesador y en ella se almacenan los datos así como el código de
instrucciones. La RAM (Read Access Memory) es la memoria de trabajo del
microprocesador por lo que es volátil. El puerto de Entrada/Salida es un buffer en el
que se acumulan los datos para ser transmitidos bit a bit.
Las tarjeta con microprocesador son las mas versátiles pues pueden realizar
diversas operaciones ya que lo único que se debe hacer es cargar ciertos
programas en la EEPROM en el proceso de prepersonalización y estos son
ejecutados por el sistema operativo de acuerdo a la aplicación que se quiera
realizar.
FIGURA 17. Arquitectura de Tarjeta con Microprocesador
3.2.3.1 Tarjeta con y sin contacto (Contact, Contact Less): Las tarjetas con chip
por lo general tienen unos contactos metálicos por los que se hace la transmisión de
datos y la alimentación de la tarjeta.
En la experiencia de los fabricantes se ha visto mejorado el desempeño de las
tarjetas con contacto con tasas de fallo inferiores al 0.001 %; sin embargo la mayor
causa de las fallas ocurre por el deterioro de los contactos metálicos por lo que se
ha venido implementando el uso de tarjetas sin contacto. Estas tarjetas además
poseen la ventaja de no tener que introducir las tarjetas en un lector, con lo que la
IEL2-I-2003-19 IEL2-I-2003-22
66
tarjeta puede ser leída aún si se encuentra en un bolsillo o guardada de alguna
manera. Estas transmiten los datos por medio de radiofrecuencias y según la
proximidad necesaria entre tarjeta y lector existen dos tipos:
• Tarjeta Cercana: Que debe estar a unos pocos milímetros del lector para que
haya comunicación.
• Tarjeta Lejana: La distancia necesaria esta entre centímetros y unos pocos
metros.
Estas tarjetas fueron desarrolladas por primera vez en el Instituto Arimura en 1978.
el grosor de dichas tarjetas varía entre 0.76 mm (Estándar de una tarjeta de crédito)
y 3 mm.
Si se analiza la forma de alimentación de estas tarjetas vemos que existen dos
tipos:
• Tarjetas Activas: Las cuales poseen alimentación dada por una batería interna.
• Tarjetas Pasivas: En las cuales por inducción magnética utilizando un campo de
intensidad variable se genera una corriente que alimenta el circuito con lo que se
ahorra la utilización de baterías.
Además de las anteriores clasificaciones existen otras relacionadas con la banda en
las que trabajan ya sean de bajas (LF) o altas frecuencias (HF). Dichas frecuencias
varían dependiendo de la normatividad que exista en cada país con el uso del
espectro electromagnético.
FIGURA 18. Tipos de Contactos de Tarjeta con Contacto
IEL2-I-2003-19 IEL2-I-2003-22
67
FIGURA 19. Tarjeta Sin Contacto
3.3 CARACTERISTICAS FISICAS Y ELECTRICAS DE LAS TI
3.3.1 Características Físicas15
Una de las características notables a primera vista es el área de contactos que tiene
la forma de un cuadrado dorado o plateado si la tarjeta es de contacto; si la tarjeta
no lo es no posee dicha área cuadrada.
Otras características no tan evidentes son la resistencia a doblarse, la
susceptibilidad a la temperatura y la resistencia a la humedad. Es claro que las
condiciones físicas que son necesarias para la buena operabilidad del chip son las
mismas que se necesitan para la tarjeta en general. De tal forma las condiciones a
cumplir deben ser consecuentes para todos los dispositivos que hay en la tarjeta
incluyendo la misma tarjeta.
3.3.1.1 Formato De Las Tarjetas: El formato mas conocido es el de 85.6 mm por
54 mm y 0.76 mm de grosor. Este tamaño ha sido el más usado y es el
15 Gráficas tomadas del Estándar ISO/IEC 7816
IEL2-I-2003-19 IEL2-I-2003-22
68
recomendado por el ISO 7810. Este formato es denominado ID-1 el cual
proporciona bastante comodidad ya que no es muy grande para ser guardado en
una cartera ni muy pequeño par ser perdido con facilidad.
Para la tecnología GSM se creo un nuevo formato, el ID-000 que es el mas pequeño
dada las necesidades de uso de estos equipos. Además existe un nuevo formato
que es intermedio entre los dos anteriores y fue denominado ID-00 pero su uso no
ha sido extendido.
El ancho y alto del formato ID-1 debe ser tal que sin tener en cuenta las esquinas
redondeadas de la tarjeta, esta encaje perfectamente dentro de dos rectángulos
concéntricos con las siguientes dimensiones:
• Rectángulo externo: Ancho 85.72 mm y alto 54.03 mm.
• Rectángulo interno: Ancho 85.46 mm y alto 53.92 mm.
El grosor ha de ser 0.76 mm con una tolerancia de ± 0.08 mm. En la siguiente figura
se representan las dimensiones de una tarjeta tipo ID-1.
FIGURA 20. Formato ID-1
IEL2-I-2003-19 IEL2-I-2003-22
69
3.3.1.2 Dimensiones De La Superficie De Contacto: Dado que las el
microprocesador requiere de unas vías por donde tomar la alimentación o para
llevar a cabo la transmisión de datos, es necesario una superficie física de contacto
que haga de enlace entre el lector y la tarjeta. Esta superficie consiste en 6 u 8
contactos que se encuentran en una cara de la tarjeta.
Para el formato ID-1, la posición de los contactos y sus dimensiones están
recogidas en el ISO 7816-2.
FIGURA 21. Separación de Contactos
3.3.2 Características Eléctricas
Las propiedades eléctricas dependen únicamente del microprocesador que
incorpora la tarjeta pues este junto con sus dispositivos anexos son los únicos que
consumen energía.
IEL2-I-2003-19 IEL2-I-2003-22
70
Dado que existen diversas tarjetas y lectores es importante que todos cumplan con
las mismas condiciones eléctricas. La aplicación mas representativa que determino
estas propiedades fue la telefonía móvil GSM con el estándar GSM 11.11 y el
ISO/IEC 7816-3.
3.3.2.1 Características De Los Contactos Eléctricos: La mayoría de las tarjetas
poseen superficies de 8 contactos. Todas las señales eléctricas circulan a través de
estos contactos, sin embargo el estándar ISO 7816-2 reserva para uso futuro
(vease la siguiente figura). Esta previsto que estos dos contactos serán utilizados
para el segundo canal de entrada y salida de tal manera que se pueda realizar la
comunicación en modo full duplex.
FIGURA 22. Distribución de los contactos
En base al la figura anterior tenemos que la función de cada contacto es:
• VCC: Entrada de la fuente de alimentación.
• RST: Contacto de Reset de la tarjeta.
• CLK: Entrada de la señal de Reloj.
• RFU: Reservado para uso futuro.
• GND: Tierra.
• VPP: Voltaje externo para la programación de la Tarjeta.
IEL2-I-2003-19 IEL2-I-2003-22
71
• I/O: Entrada y Salida de datos.
• RFU: Reservado para uso futuro.
3.3.2.2 Tensión De Alimentación: El voltaje estándar para todas las tarjetas es de
5 voltios con una tolerancia de ± 10%, que es utilizado en circuitos de lógica TTL.
Hoy en día en la telefonía móvil los equipos funcionan a 3 voltios, siendo la tarjeta la
única que trabaja a 5 voltios por lo que se necesita un conversor que aumenta los
costos del equipo. Por tanto esta previsto cambiar el voltaje con el que trabajan
actualmente las tarjetas.
3.3.2.3 Consumo De Corriente: De acuerdo con el estándar GSM 11.11 el
consumo de corriente no debe ser superior a 10 mA, sin embargo según las
recomendaciones de la ISO todavía se tiene un valor máximo de 200mA. Utilizando
valores de corriente y voltaje de 10mA y 5 V se tiene un consumo de potencia de 50
mW que resulta lo suficientemente bajo como para no calentar el chip de la tarjeta.
FIGURA 23. Consumo de corriente en función de la frecuencia de reloj aplicado
3.3.2.4 Secuencia De Encendido Y Apagado De Una Tarjeta: Los
microprocesadores de las tarjetas están protegidos frente a posibles descargas de
tensión sobre sus contactos. El estándar ISO 7816-3 define con precisión como ha
de ser la secuencia de encendido y apagado. Como se muestra en la figura antes
de conectar la alimentación debe tenerse conectada la tierra. Posteriormente debe
conectarse la señal de reloj y seguidamente darse el reset. La forma de apagarse es
en forma inversa al modo en que se debe encender.
IEL2-I-2003-19 IEL2-I-2003-22
72
FIGURA 24. Secuencia de Encendido y Apagado de una TI
3.4 COMUNICACIÓN ENTRE LA TARJETA Y LOS DISPOSITIVOS EXTERNOS16
Debido a la existencia de un único canal de comunicaciones entre la tarjeta y los
dispositivos externos, ambos deben turnarse para llevar a cabo la transmisión de
datos. A este proceso intermitente de recibir y enviar información se le denomina
“Half Duplex”. El modo Full Duplex será implementado como se dijo anteriormente
en aplicaciones futuras pues los contactos ya existen.
Toda comunicación que se realice con una tarjeta es iniciada siempre por el
dispositivo externo, esto quiere decir que la tarjeta nunca transmite información sin
que se haya producido antes una petición externa. Esto equivale a una relación
Maestro-Esclavo siendo el termina lector el maestro y la tarjeta el esclavo.
16 Gráficas tomadas de: Tarjetas Inteligentes. Cap.2
IEL2-I-2003-19 IEL2-I-2003-22
73
Cada vez que se inserta una tarjeta en un lector y sus contactos son energizados, la
tarjeta inicia un reset de encendido y envía una respuesta llamada ATR (Answer To
Reset) hacia el terminal. Esta respuesta contiene la información referente a como
debe ser la comunicación tarjeta – lector, estructura de los datos intercambiados,
protocolo de transmisión, etc. Una vez interpretado el ATR por el lector este procede
a enviar la primera instrucción. De esta forma la tarjeta procesa la respuesta a la
primera instrucción y sigue la comunicación hasta que la tarjeta es desactivada.
3.4.1 Convenio Lógico y Eléctrico
Todos los datos enviados por la línea de comunicación son digitales y usan valores
de 1 y 0 representados por valores de tensión de 5V y 0V. Parte del ATR posee la
información que especifica que valor lógico va a representar cada voltaje ya sea en
lógica directa o inversa. Siempre que no se este transmitiendo información la línea
debe estar en 5V.
FIGURA 25. Secuencia de Inicio y Transmisión de Datos entre TI y Lector
IEL2-I-2003-19 IEL2-I-2003-22
74
El método de comunicación que implementan las tarjetas es el de comunicación en
serie. Esto supone que los datos almacenados en forma de bytes deben ser
tratados para su intercambio como cadenas de bits. También debe ser tenido en
cuenta el orden de envió de los bits. En el convenio de lógica directa el primer bit
recibido después del bit de inicio es el de menor peso mientras que en lógica
inversa es el de mayor peso.
La transmisión de datos es “Asíncrona” lo que supone que cada byte enviado debe
estar previsto de algún mecanismo de sincronización. Toda comunicación comienza
siempre con un bit de inicio que indica el principio del byte de datos. Al final de este
byte se incluye un bit de paridad para detectar errores y seguido 1 o 2 bits de
parada. El bit de paridad será “1” cuando en número de “1” en el byte de datos sea
impar. El tiempo de espera para enviar otro dato es conocido como “tiempo de
espera”. Este tiempo posee el valor que indique la respuesta al reset.
FIGURA 26. Estructura del paquete de datos transmitido
La duración nominal de un bit se denomina como unidad elemental de tiempo o
ETU. Esta medida posee un valor inicial que depende de si la tarjeta posee reloj
interno o no. Si la tarjeta posee su propio reloj el valor de la ETU es de 1/9600 seg.
Esto produce una tasa de transmisión de datos de 9600 bps. Cuando la tarjeta
necesita de un reloj externo (Trasmitido en el contacto CLK por el lector) el valor del
ETU es:
ETU = 372 / fi seg
Donde fi es la frecuencia del reloj externo y su valor esta entre 1 y 5 MHz.
IEL2-I-2003-19 IEL2-I-2003-22
75
3.4.2 Protocolos De Transmisión
Una vez que la tarjeta ha enviado toda la respuesta al reset o ATR, espera a que el
terminal externo le proporcione la primera instrucción. Existen varias maneras de
estructurar la comunicación entre ambos dispositivos. Los protocolos de transmisión
especifican con precisión como han de ser las instrucciones, las respuestas a la
mismas y el procedimiento a seguir en caso de que se produzcan errores durante la
transmisión. Existen 15 protocolos distintos.
Protocolo de Transmisión
Significado
T=0 Transmisión byte a byte, asíncrona y half
duplex
T=1 Transmisión por bloques, asíncrona, half
duplex
T=2 Transmisión por bloques, asíncrona, full duplex
T=3 Transmisión full duplex
T=4 Expansión del T=0
T=5 hasta T=13 Sin especificar
T=14 Para funciones privadas no especificadas por
la ISO
T=15 Sin especificar TABLA 9. Protocolos de Transmisión para TI
Dos de estos protocolos son los mas usados en la actualidad. El primero es T=0 que
fue diseñado en 1989 (ISO 7816-3). El segundo es el T=1 introducido en 1992. El
T=2 esta aun en prueba y el T=14 es usado solo en Alemania para el pago en
cabinas telefónicas por la compañía DBP Telekom.
A cada unidad de datos que transporta un protocolo se le denomina TPDU
(Transport Protocol Data Unit). Estas unidades son las encargadas de llevar la
información entre la tarjeta y el terminal y viceversa.
IEL2-I-2003-19 IEL2-I-2003-22
76
Además de los protocolos antes mencionados existen otros aplicados únicamente a
las tarjetas de memoria y que son síncronos. La aplicación mas corriente es para el
pago en las cabinas telefónicas.
3.4.2.1 Protocolo De Transmisión T =0: Fue implementado por primera vez en
Francia durante la fase inicial del desarrollo de las tarjetas inteligentes y fue el
primero en incluirse en un estándar internacional. Es un protocolo orientado al uso
del byte (byte como unidad mínima de información).
La unidad de datos o TPDU consiste en una cabecera que incluye un byte para
especificar la clase de instrucción (CLA), otro para el código de la misma (INS) y
tres bytes que actúan como referencias (P1, P2, P3). Opcionalmente a la cabecera
le sigue una sección de Datos.
ENCABEZADO CAMPO DE DATOS
CLA INS P1 P2 P3 Solo comandos de entrada
Tamaño
(bytes)
1 1 1 1 1 P3
TABLA 10. Formato de un Comando APDU
El byte CLA es la clase de la instrucción. El valor 0xFF esta reservado para la
selección del tipo de protocolo o PTS. El byte INS especifica el código de la
instrucción. Este campo solo es válido si el bit menos significativo es distinto a 6 y 9.
P1 y P2 son referencias, por ejemplo una dirección que completa el código de la
instrucción. El byte P3 especifica el número de bytes que serán transmitidos en la
sección de datos (Si es escritura) o los bytes que se esperan leer (lectura). Cuando
P3 es igual a 0 y la orden es de lectura, la tarjeta envía una cadena de 256 bytes. El
campo de datos especifican los datos a ser enviados o a recibirse cuya longitud en
bytes es P3.
IEL2-I-2003-19 IEL2-I-2003-22
77
En caso de que se detecte un error en la transmisión de un byte se debe proceder al
reenvío del byte dañado. El único mecanismo de detección de errores es el del bit
de paridad. Cuando el receptor detecta un error después de recibir un bit de
paridad, debe poner la línea en nivel bajo al menos durante un ETU y como máximo
2. Esto sirve para que el dispositivo transmisor compruebe si los datos se recibieron
correctamente. Si la línea, después de transmitir los datos, esta en nivel alto, quiere
decir que la recepción fue correcta, en caso contrario se procede al reenvío del byte
erróneo después de finalizar la señal de error.
FIGURA 27. Esquema de recepción con y sin errores
El protocolo T=0 proporciona un mecanismo para activar o desactivar la tensión de
programación de la EEPROM. Esta tensión es suministrada a través del contacto
VPP. El mecanismo consiste en el envío por parte de la tarjeta de un byte de
procedimiento cada vez que recibe una instrucción, con este byte indica al terminal
lector qué es lo que debe hacer a continuación. Existen tres tipos de byte de
procedimiento:
• ACK: Indica al termina lector como controlar la tensión sobre VPP y como
transferir el resto de los datos. El valor de ACK esta relacionado con el código de
la instrucción.
• NULL: Tiene el valor 0x60 e indica que no se debe cambiar la tensión sobre
VPP. En ese caso el terminal lector espera por un nuevo byte de procedimiento.
IEL2-I-2003-19 IEL2-I-2003-22
78
• SW1: Tiene el valor 0x6X o 0x9X excepto 0x60. Cuando el terminal recibe este
byte de procedimiento debe desconectar la tensión sobre VPP y esperar por el
byte de procedimiento SW2
• SW2: Con este byte de procedimiento termina la ejecución de la instrucción en
curso y la tarjeta esta lista para recibir una nueva orden.
En las tarjetas modernas el valor de VPP puede obviarse pues este voltaje puede
ser obtenido a partir de VCC.
La secuencia de procesamiento de una orden es la siguiente: El terminal envía a la
tarjeta la cabecera de 5 bytes de la instrucción. Si no hubo errores, la tarjeta envía
un byte de procedimiento, si es NULL el terminal espera por otro byte. Si el byte
recibido es ACK, el terminal debe interpretarlo y realizar la acción requerida por la
tarjeta. Este mecanismo termina cuando todo el paquete de datos se ha enviado o
recibido. Entonces la tarjeta envía la pareja de bytes SW1 y SW2 que indican al
terminal si la orden se procesó con éxito o no. En caso de fallo, los bytes SW1 y
SW2 indican la razón del mismo. Cuando una orden se ha procesado con éxito la
secuencia final ha de ser 0x9000. La interpretación de los bytes SW1 y SW2
depende de la instrucción transmitida.
FIGURA 28. Secuencia de intercambio de comandos durante escritura.
IEL2-I-2003-19 IEL2-I-2003-22
79
FIGURA 29. Secuencia de intercambio de comandos durante lectura.
3.5 SISTEMA OPERATIVO DE LAS TARJETAS
Puede parecer exagerado referirse como sistema operativo a los pocos miles de
bytes de código de programa que posee el microprocesador de una tarjeta. Se
entiende por sistema operativo (OS) al interfaz existente entre el hardware de la
máquina y el software que se esté ejecutando en ella. Es importante no asociar este
concepto con el programa que poseen los ordenadores basados en DOS, Windows
o Unix. Desgraciadamente las características y el funcionamiento de las tarjetas aún
dependen de la filosofía del fabricante y esto hace que posean propiedades muy
diferenciadas entre ellas.
3.5.1 Principios Fundamentales
En contraste con los sistemas operativos conocidos, los sistemas basados en
tarjetas inteligentes no permiten al usuario el almacenamiento externo de
información, siendo las prioridades más importantes la ejecución segura de los
programas y el control de acceso a los datos.
Debido a la restricción de memoria, la cantidad de información que se puede
almacenar es bastante pequeña, estando entre 1 y 60 Kbytes. Los módulos de
programa se graban en la ROM, esto posee la desventaja de no permitir al usuario
IEL2-I-2003-19 IEL2-I-2003-22
80
programar el funcionamiento de la tarjeta según sus propios criterios (las JAVA
CARD si lo hacen), ya que una vez grabado el sistema operativo es imposible
realizar ningún cambio. Por eso dicho programa debe ser fiable y robusto.
Otra característica importante del sistema operativo es que no permite el uso de
“puertas traseras”, que son bastantes frecuentes en sistemas grandes. Esto quiere
decir que es imposible hacer una lectura desautorizada de los datos contenidos
usando el código propio de la tarjeta.
Existen otras funciones que desempeña el código almacenado en la ROM:
• Transmisión de Datos desde y hacia la tarjeta.
• Control de ejecución de los programas.
• Administración de datos.
• Manejo y administración de algoritmos criptográficos.
3.5.2 Principios De Diseño e Implementación
Por definición el sistema operativo de una tarjeta ha de ser bastante seguro pues
debe administrar y proteger datos confidenciales. Demás no deben permitirse las
modificaciones a dicho sistema operativo pues se incurrirían en fallos en el
funcionamiento de la tarjeta.
Si se compara a cualquier ordenador con la tarjeta vemos que existen grandes
diferencias en cuanto a la capacidad de memoria ya que en la tarjeta es bastante
restringida. Por tanto se tiene que todas las estructuras y funciones que se pueden
realizar no siempre caben en una sola tarjeta y por tanto se definen los “perfiles”
para tarjetas inteligentes que están comentados en la ISO/IEC 7816-4 y en la EN
726-3. Cada uno de estos perfiles definen un subconjunto de instrucciones y
estructuras de ficheros que pueden ser implementados bajo dicho perfil. De acuerdo
a lo anterior realizaran distintas funciones de acuerdo al perfil al que pertenecen.
IEL2-I-2003-19 IEL2-I-2003-22
81
TABLA 11. Resumen de los perfiles especificados por el ISO 7816-417
3.5.3 Estructura de la Memoria
Como se definió antes una tarjeta inteligente posee 3 memorias distintas, una ROM,
una RAM y una EEPROM que en ciertas ocasiones es utilizada como RAM con la
desventaja que los tiempos de lectura y escritura son grandes (cerca de 1ms por
byte), esto ocurre cuando por ejemplo se necesita implementar un buffer de
entrada/salida de 256 bytes. A continuación se muestra un esquema de cómo esta
estructurada una memoria RAM de 256 bytes.
17 Gráfica tomada de: Tarjetas Inteligentes. Cap.4
IEL2-I-2003-19 IEL2-I-2003-22
82
Registro
Pila
Variables Generales
Espacio para Algoritmos
Criptográficos
Buffer Entrada/Salida
10 bytes
26 bytes
50 bytes
70 bytes
100 bytes
TABLA 12. Estructura de la Memoria RAM de 256 bytes
Si se analiza la estructura de la EEPROM vemos que es más compleja que las de
las otras memorias. En los sistemas operativos modernos la división de esta es: en
primer lugar se encuentran almacenados algunos datos relacionados con la
producción del chip como números o valores fijos que son usados en operaciones
específicas. Estas zonas están por lo general protegidas frente a accesos no
autorizados por mecanismos de tipo hardware.
Seguida a esta zona, que generalmente no ocupa más de 32 bytes se encuentran
las tablas y los punteros del sistema. Estos se graban en la etapa de fabricación y
en conjunto con el programa de la ROM forman el sistema operativo. Para asegurar
que el sistema funcione bien esta región esta protegida mediante un checksum que
se calcula antes de entrar en esta zona.
Seguidamente se encuentra una zona que contiene códigos adicionales de los
programas de aplicación y algoritmos que no caben en la ROM por falta de espacio.
También se protege el acceso mediante un checksum.
La siguiente zona contiene toda la estructura de datos que es manejada por los
ficheros o archivos, esta zona no esta protegida directamente pero existen módulos
ya sean software o hardware que están orientados a la protección de estos datos.
Finalmente se encuentra una zona libre en la que se encuentran almacenados datos
básicos del usuario usualmente.
IEL2-I-2003-19 IEL2-I-2003-22
83
Datos de Producción
Sistema Operativo
Programas de Aplicación
Área de Ficheros
Zona de Datos del Usuario TABLA 13. División de la EEPROM
3.5.4 Estructura de los Datos Almacenados en una Tarjeta Inteligente18
Las tarjetas actuales poseen mecanismos de administración de ficheros que siguen
una estructura jerárquica y los programas que operan estos sistemas están bastante
minimizados con el fin de reducir el uso de memoria. Los sistema operativos están
orientados a trabajar con objetos, esto quiere decir que todos los datos referentes a
un fichero están contenidos en el mismo (véase la gráfica a continuación). A
consecuencia de esto para ser manipulada la información de un fichero debe haber
sido seleccionado este anteriormente.
Los ficheros están divididos en dos secciones distintas, una que se conoce como
cabecera en la que están almacenados los datos referentes a la estructura del
fichero y condiciones de acceso y la otra conocida como cuerpo en la que se tienen
ya los datos en si.
FIGURA 30. Estructura General de un Fichero
18 Gráficas tomadas del Estándar ISO/IEC 7816-4
IEL2-I-2003-19 IEL2-I-2003-22
84
3.5.4.1 Tipos de Ficheros: La estructura de ficheros, especificada en la ISO/IEC
7816-4, contenida en una tarjeta inteligente es similar a la sistemas DOS y UNIX.
Existen varios directorios que hacen las veces de carpetas que contienen ficheros o
archivos. De esta manera los tipos de ficheros con los que se trabajan son:
3.5.4.1.1 Fichero Maestro (MF): Es definido como el directorio raíz y es
seleccionado automáticamente después de iniciada la tarjeta. En el están
contenidos todos los directorios y archivos. Representa a toda la memoria disponible
de la tarjeta para el almacenamiento de datos.
3.5.4.1.2 Fichero Dedicado (DF): El DF trabaja como un directorio en el que se
pueden almacenar archivos o ficheros y otros DF. Inicialmente el nivel de
anidamiento podría ser infinito pero en la realidad esta limitado por los recursos de
memoria que se tengan.
3.5.4.1.3 Fichero Elemental (EF): Toda la información que se quiere guardar esta
almacenada en estos. Este tipo de ficheros pueden ser almacenados ya sea en un
DF o en el MF pero nunca un EF puede contener un EF, solo datos.
FIGURA 31. Estructura en Árbol de los Ficheros de la memoria
IEL2-I-2003-19 IEL2-I-2003-22
85
3.5.4.1.4 Fichero Interno del Sistema: Aparte de los EF se pueden almacenar cierto
tipo de ficheros propios del sistema operativo que ejecutan determinadas
aplicaciones o almacenan códigos secretos (Como llaves o Claves).
Existen dos maneras de integrar estos ficheros dentro de la memoria, el método ISO
consiste en ocultarlos dentro del fichero dedicado correspondiente a la aplicación y
por tanto no pueden ser seleccionados. Otro método propuesto por la ETSI
(European Telecomunication Standarisation Institute) consiste en asignar a estos
ficheros un nombre (ID) con l cual puedan ser seleccionados.
Es usual relacionar los datos de una misma aplicación con un mismo fichero. De
esta forma si la aplicación solo es una los dato podrían almacenarse directamente
en el MF.
3.5.4.2 Identificación de Ficheros: Todos los directorios poseen una identificación
(ID) de dos bytes de longitud que se usa para seleccionarlos. Por razones históricas
el MF posee el ID 0x3F00. Los valores de los IDs deben ser escogidos de tal
manera que dentro de un mismo DF no existan ficheros con el mismo ID ya sean
entre hijos o entre padre e hijo.
En el estándar GSM 11.11 el byte más significativo representa la posición dentro de
la estructura de ficheros. Si el fichero es un DF este byte siempre tiene el valor de
0x7F. Los EF que pertenezcan directamente al MF tienen el valor 0x2F como primer
byte del ID y todos los EF que pertenezcan a un mismo DF tiene el valor 0x6F en
esa posición. El byte menos significativo se numera de manera consecutiva a la
creación del fichero.
Los ficheros DF se utilizan como carpetas que almacenan EFs o DFs que
pertenecen a una misma aplicación.
3.5.4.3 Direccionamiento de los Ficheros: Debido a la estructura de objetos del
sistema operativo de las tarjetas inteligentes es necesario seleccionar los ficheros
IEL2-I-2003-19 IEL2-I-2003-22
86
antes de acceder a ellos. Esto sirve para indicarle al sistema con que fichero se
desea trabajar. Aquí se presenta el inconveniente que no se puede trabajar con más
de un objeto (fichero) a la vez. Para seleccionar el fichero es necesario invocar su
ID.
3.5.4.4 Opciones de Selección de Ficheros: Dado a que es imposible controlar
que no se repitan los identificadores de los ficheros dentro de la estructura de
memoria de la tarjeta, el acceso a dichos ficheros posee algunas restricciones con el
fin de evitar ambigüedades en la selección.
El MF puede ser seleccionado desde cualquier parte de la e4structura de ficheros
dado a que su ID es único. La selección de los DF que cuelgan del MF solo es
posible desde el MF o desde otros DF que se encuentren en el mismo nivel
jerárquico. A continuación se muestran posibles y no posibles selecciones de
ficheros.
FIGURA 32. Ejemplo de Selecciones autorizadas (izq.) y no autorizadas (derecha)
3.5.4.5 Tipos de Estructuras de Ficheros: Los ficheros de las tarjetas inteligentes
poseen una estructura interna, existiendo varios tipos que pueden aplicar libremente
a cualquier EF dependiendo del propósito del mismo.
IEL2-I-2003-19 IEL2-I-2003-22
87
3.5.4.5.1 Fichero Transparente o Binario (EF Binario): A este tipo de estructura se le
conoce normalmente como fichero binario. Estos ficheros no poseen ningún tipo de
estructura y los datos se pueden leer o escribir byte a byte por medio de un puntero
que se desplaza a través del mismo. Las instrucciones usadas para trabajar con
estas estructuras son: READ BINARY, WRITE BINARY y UPDATE BINARY.
FIGURA 33. Fichero Transparente
3.5.4.5.2 EF Llave y EF Clave (EF KEY, EF CHV): Los archivos de Llaves poseen
las llaves que se utilizaran en los comandos en los que se deben utilizar algoritmos
de encripción ya sea para guardar datos encriptados o para solicitar
autenticaciones. Los archivos de Claves almacenan las claves que se utilizaran para
permitir la manipulación de ciertos datos.
El tamaño mínimo que pueden tener es de 1 byte mientras que el máximo no esta
especificado.
3.5.4.5.3 Fichero Lineal Fijo o de Registro (EF Registro): Esta estructura esta
basada en una serie de celdas de igual longitud que están unidas en forma de
matriz. La unidad más pequeña a la que se tiene acceso es una celda y no se puede
acceder a fracciones de la misma. Las instrucciones que se usan para acceder a las
celdas son: READ RECORD, WRITE RECORD y UPDATE RECORD.
A la primera celda se le identifica con el número 0x01 mientras que el número mas
alto permitido es 0xFE, estando 0xFF reservado para usos futuros. El número de
celdas puede variar entre 1 y 256, siendo las celdas del mismo tamaño cuyo tamaño
máximo puede ser de 65 bytes.
IEL2-I-2003-19 IEL2-I-2003-22
88
FIGURA 34. Estructura de un fichero EF Lineal Fijo
3.5.4.5.4 Fichero Lineal Variable: Debido a las restricciones de espacio de memoria
y como los datos almacenados pueden tener longitud variable, es creado este tipo
de ficheros con el fin de optimizar el uso de memoria. Cada celda puede tener un
tamaño variable en función de los datos que se almacenan en ella. El tipo de
numeración y el tamaño de cada celda son exactamente iguales que en el caso
anterior. Las instrucciones usadas también son las mismas.
FIGURA 35. Estructura de un fichero EF Lineal Variable
3.5.4.5.5 Fichero Cíclico: Consiste en una secuencia de registros que tienen la
misma longitud y se encuentran anillados. Cada registro recibe un número de
acuerdo a la última operación de escritura. De esta forma el registro número 1 es el
último escrito y el registro mas viejo es el que posee el número más grande. Esta
estructura posee dos apuntadores, uno para escritura y otro para lectura. El
apuntador de lectura es posicionado en el último registro escrito mientras que el
puntero de escritura se mueve en modo Anterior (PREVIOUS). Cuando se moviliza
el puntero en forma de Selección (SELECT) el puntero es posicionado en el registro
No. 1. NEXT, FIRS o LAST pueden modificar la posición del puntero de lectura.
IEL2-I-2003-19 IEL2-I-2003-22
89
FIGURA 36. Estructura de un fichero EF Cíclico
3.5.4.5.6 Fichero Ejecutable: Este tipo de estructura está descrita en el estándar
europeo EN 726-3 y ofrece posibilidades de ampliación del sistema operativo de las
tarjetas. Este fichero no se creó para almacenar datos sino para contener ficheros
que puedan ser ejecutados directamente por la propia tarjeta.
3.5.4.6 Tipos de Acceso a los Ficheros: Todas las estructuras contienen datos
que sirven para regular el acceso a las mismas. Estos datos están contenidos en la
cabecera. El peso de la seguridad de los datos almacenados en una tarjeta recae
sobre la administración de ficheros, dado que sirve para controlar el acceso a sus
datos.
La autorización de acceso es determinada cuando se crea el fichero y como norma
general no se puede modificar más tarde. Los distintos tipos de acceso varían en
función del sistema operativo de la tarjeta y de las instrucciones que soporte.
Las instrucciones para manipular ficheros varían de un sistema operativo a otro, las
más comunes pueden verse en la siguiente tabla.
IEL2-I-2003-19 IEL2-I-2003-22
90
INSTRUCCIÓN DESCRIPCIÓN
APPEND Ampliar el tamaño de un fichero
DELETE FILE Borrar fichero
INVALIDATE Bloquear acceso a fichero
LOCK Bloquear indefinidamente fichero
READ/SEEK Lee o busca en el contenido de un
fichero
REHABILITATE Desbloquear fichero
WRITE/UPDATE Escribe en un fichero
CREATE Generar un fichero nuevo
REGISTER Registrar un fichero nuevo TABLA 14. Instrucciones para la administración de ficheros
3.5.4.7 Tributos de los Ficheros: Aparte de los derechos de acceso se determinan
además, en el momento de la creación de los ficheros, atributos que determinan
ciertas características y que además no pueden ser modificados posteriormente.
El atributo WORM: Significa “write once, read many” (Escriba una vez lea muchas)
que determina como se manejara el fichero claramente. El propósito de este atributo
es proteger los datos importantes contenidos en la tarjeta frente a posibles sobre-
escrituras.
Atributo Escritura Múltiple: Es bastante usado en la telefonía GSM para ficheros
de gran uso. Permite que contenido del fichero pueda ser alterado muchas veces, el
número máximo depende de los ciclos de lectura y escritura de la EEPROM.
Atributo de Corrección de Errores: Este atributo se usa para datos que son
particularmente importantes y que requieren algún tipo de código de detección de
errores o EDC (Error Detection Code).
3.5.4.8 “Diario” de Datos: La escritura de datos en la memoria EEPROM son
protegidos mediante un dispositivo que realiza la función de “diario”. Este dispositivo
se encarga de garantizar la integridad de los datos (internos o externos) en el
IEL2-I-2003-19 IEL2-I-2003-22
91
momento de escritura o actualización (writing y updating). O se autoriza o se aborta
la acción en forma completa, de esta manera no existe la posibilidad de escrituras
parciales. Si existe algún problema en el momento de escritura no ocurrirán cambios
en la memoria pues la escritura primero se hace en el “Diario” y posteriormente se
transmiten a la EEPROM.
3.5.4.9 Ficheros Alterados: Los archivos de datos pueden presentar problemas en
ciertas direcciones de memoria de esta forma dichos archivos son considerados
alterados. Sin embargo el sistema operativo de la tarjeta puede localizar dichas
alteraciones y hace que su manipulación sea restringida.
3.6 JUEGO DE INSTRUCCIONES19
La comunicación entre la tarjeta y el terminal lector está basada en un
procedimiento de instrucción y respuesta, esto significa que el terminal envía una
orden a la tarjeta, esta la procesa y a continuación produce un resultado que es
devuelto hacia el terminal. Teniendo en cuenta este modelo de comunicación entre
ambos dispositivos, la tarjeta nunca envía información sin que haya recibido una
instrucción desde el terminal lector.
Como se dijo antes, el intercambio de datos se realiza siguiendo un protocolo
(comúnmente el T=0 o T=1). La información es encapsulada en paquetes llamados
TPDU que representan las instrucciones que son enviadas hacia las tarjetas. Como
el manejo de los datos es basado en el uso de los ficheros, esto ha motivado al
desarrollo de instrucciones totalmente orientadas al uso de ficheros. Existen muchas
instrucciones diferentes, dependiendo de las aplicaciones que se requieran, que
muy pocas tarjetas implementan en su totalidad, solo cierto número de ellas son
utilizadas debido a las restricciones de memoria.
Un fenómeno que se observa en la industria es el que debido a la diversificación de
tarjetas para distintos usos y por los distintos fabricantes se crean nuevas
19 Tablas tomadas de: Manual de Programación de la tarjeta HOST
IEL2-I-2003-19 IEL2-I-2003-22
92
instrucciones que se adaptan a ciertos sistemas operativos debido a que
generalmente no existen instrucciones similares en las recomendaciones
internacionales. Existen cuatro normas en las que se recoge el juego de
instrucciones, en ellas están descritas más de 50 instrucciones junto con sus
parámetros de ejecución.
Los estándares que se refieren a las instrucciones son: GSM 11.11 y EN 726-3,
encaminados a las aplicaciones en telecomunicaciones; el ISO/IEC 7816-4, que no
esta encaminado a aplicaciones específicas y el estándar prEN 1546 orientado a las
aplicaciones de monedero electrónico (pago de artículos usando a la tarjeta
electrónica como medio de pago).
Las instrucciones que se describen en las recomendaciones anteriores pueden
clasificarse de la siguiente manera:
• Selección de ficheros.
• Lectura y escritura de ficheros.
• Búsqueda de ficheros.
• Identificación.
• Autenticación.
• Ejecución de algoritmos criptográficos.
• Administración de ficheros.
• Instrucciones para monederos electrónicos y tarjetas de crédito.
• Ampliación del sistema operativo.
• Comprobación de los elementos hardware de una tarjeta.
• Instrucciones especiales para aplicaciones específicas.
3.6.1 Selección de Ficheros
Como anteriormente se comento, el juego de instrucciones es orientado a objetos
(ficheros) y esto implica que para cada operación que se quiera realizar, antes debe
seleccionarse el fichero sobre el que se quiere trabajar (para que el sistema
IEL2-I-2003-19 IEL2-I-2003-22
93
operativo sepa sobre quien operar). Debe aclararse que para seleccionar algunos
ficheros han de satisfacerse previamente algunas condiciones de acceso.
La instrucción encargada de seleccionar un fichero es SELECT FILE. Para acceder
al fichero es necesario dar el ID del fichero a seleccionar y una vez ejecutada se
pueden ejecutar las otras instrucciones pues ya se ha escogido el fichero a trabajar.
3.6.2 Instrucciones de Lectura y Escritura
Estas instrucciones permiten leer y escribir datos en ficheros elementales EF.
Debido a que los fichero poseen condiciones de acceso, el acceso a los mismos
sólo esta permitido a los usuarios autorizados, por esto deberán satisfacer
previamente unas condiciones de seguridad posteriormente podrán realizarse la
lectura y escritura.
Existen diferentes instrucciones para hacer lectura y escritura de datos, esto debido
a la existencia de distintos tipos de archivos o ficheros. Para ficheros binarios
existen los comandos READ BINARY, WRITE BINARY Y UPDATE BINARY, mientras que para ficheros de tipo registro existen funciones como READ RECORD, WRITE RECORD, UPDATE RECORD, SEEK Y APPEND RECORD. Las funciones
de escritura (WRITE) y actualización (UPDATE) se diferencian en que la escritura
realiza una operación de XOR entre el dato a almacenar en memoria y el contenido
actual en el espacio en memoria que quiere ser escrito, por tanto en la primera vez
que se escribe no hay ningún problema; mientras que la operación UPDATE lo que
hace es precisamente escribir los nuevos datos sin interesa que se encuentra en
memoria. La operación SEEK busca en la estructura del fichero el valor a encontrar
mientras que la función APPEND RECORD se encarga de añadir un número
determinado de registros al fichero de registros seleccionado.
IEL2-I-2003-19 IEL2-I-2003-22
94
3.6.3 Instrucciones para la Administración de Ficheros Con el fin de crear, modificar, bloquear, deshabilitar o borrar un fichero existen
varios comandos que pueden ser utilizados dependiendo de las condiciones de
acceso y el tipo de tarjeta a usarse.
Los comando crear y borrar ficheros (CREATE FILE Y DELETE FILE) sirven como
su nombre lo indican para crear un nuevo fichero donde se deben definir las
condiciones de acceso, tamaño, tipo del fichero, identificación (ID) y otros valores
necesarios para el trabajo con ellos; mientras que la función DELETE es usada para
eliminar el fichero, siempre y cuando se cumplan con las condiciones de acceso.
Si se desea cambiar los atributos que posee un fichero ya creado se puede utilizar
el comando CHANGE ATRIBUTES pero no todas las tarjetas lo poseen.
Los ficheros pueden ser también bloqueados utilizando las funciones INVALIDATE
Y LOCK. La primera lo que hace es bloquear el fichero de forma reversible, con lo
que no se puede realizar ninguna operación con dicho archivo hasta que no sea
desbloqueado; esto se hace con el comando REHABILITATE. El segundo
comando, LOCK bloquea el archivo pero de forma irreversible con la desventaja que
se pierde el espacio en memoria que ocupaba dicho fichero y no puede ser utilizado
por otras aplicaciones. Así que la mejor forma de recuperar dicho espacio es utilizar
el comando DELETE FILE previamente con lo que no se utiliza dicho fichero y se
recupera la memoria utilizada.
3.6.4 Instrucciones de Autenticación
Existen instrucciones que sirven para identificar al portador de la tarjeta frente a
esta. Además existen otros comandos que permiten identificar al terminal frente a la
tarjeta y viceversa.
Dependiendo del sistema operativo de la tarjeta existen varias instrucciones para
realizar dicha verificación. La instrucción GET CHIP NUMBER sirve para obtener un
IEL2-I-2003-19 IEL2-I-2003-22
95
número único de cada tarjeta que será usado para generar las claves necesarias
para el proceso de autentificación. Además se pueden generar número aleatorios
con la función ASK RANDOM, GET CHALENGE o GET REQUEST.
La instrucción que permite identificar la tarjeta frente al terminal lector es INTERNAL AUTHENTICATE, el mecanismo es el siguiente: la tarjeta recibe un número
aleatorio proveniente del lector, lo cifra utilizando una de las llaves que posee ella
que la conoce tanto el lector como ella misma. El resultado del valor encriptado es
enviado al lector quien realiza la misma operación y compara los datos obtenidos
tanto por la tarjeta como por él; si los resultados son iguales se autoriza la siguiente
operación a seguir; si no se tienen los mismos resultados será imposible realizar el
siguiente comando.
El comando EXTERNAL AUTHENTICATE es usado para comprobar la autenticidad
del lector frente a la tarjeta. El mecanismo es el siguiente:_ El terminal solicita a la
tarjeta un número aleatorio (Usando el comando ASK RANDOM o GET REQUEST o
GET CHALLENGE) lo cifra escogiendo una de las llaves que posee la tarjeta y que
también el conoce y el resultado de la encripción es enviado a la tarjeta; la tarjeta
realiza la misma encripción con el mismo dato y la misma llave y compara los
resultados; si la respuesta es la misma la tarjeta permite el intercambio de
información con el lector, de lo contrario no habrá permiso de la tarjeta para acceder
a su información.
Queda claro que para la aplicación de estos comandos se utilizan algoritmos de
encripción que en la mayoría de casos son DES o alguna evolución de este.
3.6.5 Lista de Comandos con los que trabaja la Tarjeta implementada
En la lista a continuación se tienen los comandos con los que trabaja la tarjeta
inteligente implementada de la marca Oberthur. Se especifica si es un comando de
entrada o salida, el nombre del comando, al valor de la instrucción (INS), P1 y P2;
dichos valores están en hexadecimal.
IEL2-I-2003-19 IEL2-I-2003-22
96
TABLA 15. Comandos utilizables con la TI HOST de Oberthur
3.6.6 Comandos y Ficheros
A continuación se presenta una tabla en la que se especifica que comandos se
pueden utilizar dependiendo del tipo de archivos que se tienen.
TABLA 16. Comandos utilizables según el tipo de fichero
IEL2-I-2003-19 IEL2-I-2003-22
97
3.6.7 Palabras de Estado devueltas por la tarjeta (Status Word)
Después de ejecutar un comando la tarjeta envía sistemáticamente un reporte en
dos palabras, SW1 y SW2 , cada una de 1 byte. Los comandos muestran si el
comando ha sido ejecutado satisfactoriamente o no (acorde a lo estipulado en el
estándar ISO 7816-4).
TABLA 17. Palabras de Estado codificadas (Respuesta a comandos APDU)
3.7 DESCRIPCION DE COMANDOS IMPLEMENTADOS EN EL APLICATIVO
En esta sección se mostrara la estructura de ciertos comandos básicos que se
utilizan para las aplicaciones que se quieren implementar en el proyecto. No todos
IEL2-I-2003-19 IEL2-I-2003-22
98
los comandos que se pueden implementar con la tarjeta y el lector están
consignados en este documento.
3.7.1 Comando SELECT FILE
Este comando de entrada es usado para seleccionar un archivo o fichero. El sistema
operativo de la tarjeta, al trabajar con una estructura orientada a objetos siempre
tiene un puntero apuntando a cierto fichero, y el comando SELECT es el encargado
de indicar al puntero cual es el fichero con el que se debe trabajar . Es posible
seleccionar el archivo padre del archivo actual (donde se encuentra en puntero) o a
través del ID del fichero. De tal forma los identificadores (ID) autorizados son los
siguientes:
• Identificador de fichero hijo.
• Identificador de fichero hermano (solo si el fichero actual es uno de tipo EF).
• Identificador de fichero padre.
• Identificador de MF.
Cuando un fichero es seleccionado satisfactoriamente este se convierte en el fichero
actual (el puntero apunta hacia él). Un fichero alterado nunca podrá ser
seleccionado.
La estructura del comando es la siguiente para seleccionar el fichero padre:
CLA Valor del Byte en Hexadecimal
INS ‘A4’
P1 ‘03’
P2 ‘00’
P3 (Long del campo de datos) ‘00’
Campo de Datos Vacío TABLA 18. Campos del comando SELECT para seleccionar fichero padre
IEL2-I-2003-19 IEL2-I-2003-22
99
Y para la selección por identificador:
CLA Valor del Byte en Hexadecimal
INS ‘A4’
P1 ‘00’
P2 ‘00’
P3 (Long. del campo de datos) ‘02’
Campo de Datos ID (Identificador) TABLA 19. Campos del comando SELECT para seleccionar fichero por ID
Después de realizar este comando se debe utilizar el comando GET RESPONSE
pues el sistema operativo genera un reporte en respuesta y la única forma de leerlo
es mediante dicho comando. La estructura de la respuesta al comando SELECT
(después de usar GET RESPONSE) para un MF o un DF es:
Byte Descripción Longitud (bytes)
1 Etiqueta de propietario ‘85’ 1
2 Long. Del byte 3 al final ‘10’ 1
3 - 4 Tamaño del fichero 2
5 - 6 ID del fichero 2
7 Tipo de Archivo 1
8 Método de Acceso al Fichero ‘00’ 1
9 – 11 Condiciones de Acceso 3
12 Estado del Fichero 1
13 Número de hijos MF o DF 1
14-16 Número de las llaves (Condiciones Acceso) 3
17-18 Memoria Disponible en el MF o DF 2 TABLA 20. Campos de la respuesta al comando SELECT para un MF o DF
IEL2-I-2003-19 IEL2-I-2003-22
100
Si se tiene un fichero de tipo EF, la estructura es:
Byte Descripción Longitud (bytes)
1 Etiqueta de propietario ‘85’ 1
2 Long. Del byte 3 al final ‘10’ 1
3 - 4 Tamaño del fichero 2
5 - 6 ID del fichero 2
7 Tipo de Archivo 1
8 Método de Acceso al Fichero ‘00’ 1
9 – 11 Condiciones de Acceso 3
12 Estado del Fichero 1
13 Número de hijos MF o DF 1
14-16 Número de las llaves (Condiciones Acceso) 3
17 Longitud del Registro 1
17-18 Indicador de Enciframiento 1 TABLA 21. Campos de la respuesta al comando SELECT para un EF
La siguiente tabla muestra los posibles valores para el campo de Tipo de Fichero
(Type of File):
‘00’ EF Binario
‘01’ EF Lineal Fijo
‘03’ EF Cíclico
‘04’ EF Transparente
‘10’ MF o DF
‘80’ EF binario sin “diario” TABLA 22. Valor del campo Tipo de Fichero
A continuación se muestra como es la estructura para el campo de Estado del
Fichero (File Status):
IEL2-I-2003-19 IEL2-I-2003-22
101
FIGURA 37. Valor del campo Estado de Fichero
3.7.2 Comando CREATE FILE
Este comando de entrada es usado para crear un nuevo archivo o fichero bajo el
directorio actual (Sea en el MF o un DF). No se puede crear el MF solo DF o EF.
Cuando un fichero es creado es “seleccionado” automáticamente. Es imposible
crear dos archivos con el mismo ID en el mismo directorio. El espacio en memoria
otorgado a un fichero es aproximado hacia un entero mayor que sea divisible por 4.
El espacio ocupado por un fichero es el espacio requerido para el fichero en su
creación mas el espacio necesario para el encabezado del fichero (20 bytes para un
DF y 22 para un EF). La estructura del mensaje es:
CLA Valor del Byte en Hexadecimal
INS ‘E0’
P1 ‘00’
P2 ‘00’
P3 (Long. del campo de datos) Longitud del Dato
Campo de Datos Dato enviado a la tarjeta TABLA 23. Campos del comando CREATE para crear un fichero
IEL2-I-2003-19 IEL2-I-2003-22
102
La estructura del campo de datos del comando CREATE es:
Descripción del campo Byte No. Tamaño
(Bytes) Para un EF Para un DF
1 1 Etiqueta propietario ‘85’ Idem
2 1 Long. Del byte 3 al final del fichero ‘10’ Idem ‘0E’
3 - 4 2 Tamaño del fichero Idem
5 - 6 2 ID del fichero Idem
7 1 Tipo de fichero Idem ‘10’
8 1 Método de Acceso al Fichero ‘00’ Idem
9 – 11 3 Condiciones de Acceso Idem
12 1 Estado del Fichero Idem
13 1 Long. Del byte 14 al final de fichero ‘05’ Idem ‘03’
14 - 16 3 Número de llaves (Condiciones de Acceso) Idem
17 1 Longitud de los Registros
18 1 Indicador de Enciframiento TABLA 24. Estructura del campo de datos del comando CREATE
3.7.3 Comando DELETE FILE
Este comando de entrada es usado para borrar un archivo que se encuentre en el
directorio actual de trabajo. Si un fichero es borrado toda su información es
eliminada y el espacio en memoria que ocupaba es liberado. Un DF puede ser
eliminado solo si esta vacío, mientras que un fichero alterado no puede ser borrado.
La estructura del comando es:
CLA Valor del Byte en Hexadecimal
INS ‘E4’
P1 ‘00’
P2 ‘00’
P3 (Long. del campo de datos) ‘02’
Campo de Datos Dato enviado a la tarjeta TABLA 25. Campos del comando DELETE para borrar un fichero
IEL2-I-2003-19 IEL2-I-2003-22
103
Mientras, el campo de datos es:
Byte No Descripción Longitud (Bytes)
1 - 2 ID del fichero 2
3 - 10 Criptograma (Si esta en modo PRO) 8 TABLA 26. Contenido del campo de datos para el comando DELETE
3.7.4 Comando UPDATE RECORD
Este comando de entrada actualiza la información contenida en un fichero EF de
registro. El dato que se quiere actualizar es remplazado por el nuevo dato. El dato a
escribir debe ser menor o igual en tamaño al tamaño definido del fichero. Para
identificar el registro con el que se desea trabajar (actualizar en este caso), existe un
puntero de registro (record pointer) encargado de esta labor. Para actualizar el
fichero existen varios modos descritos a continuación:
• CURRENT: En este modo el registro (record) a ser actualizado es apuntado por
el apuntador de registro (pointer record).
• ABSOLUTE: El número del registro a ser actualizado se encuentra especificado
en el comando.
• NEXT: El registro a ser actualizado es el registro que sigue al registro al que
apunta el apuntador de registro.
• PREVIOUS: En este modo el registro a actualizarse es el anterior al registro que
apunta el puntero.
• FIRST y LAST: Este modo permite actualizar el primero o el último de los
registros.
Para el caso del proyecto, el modo usado fue el ABSOLUTE con el cual se
especificaba la posición exacta en la que se quería escribir un dato.
IEL2-I-2003-19 IEL2-I-2003-22
104
La estructura del comando es:
CLA Valor del Byte en Hexadecimal
INS ‘DC’
P1 Número del Registro
P2 Modo
P3 (Long. del campo de datos) Longitud del Dato
Campo de Datos Dato a ser modificado TABLA 27. Campos del comando UPDATE para modificar un registro de un fichero
En P2 el modo es codificado como:
MODO VALOR
(Hexadecimal)
FIRST ‘00’
LAST ‘01’
NEXT ‘02’
PREVIOUS ‘03’
CURRENT/ ABSOLUTE ‘04’ TABLA 28. CODIFICACION DEL MODO DE ESCOGENCIA DE REGISTRO
Cuando P2 es ‘04’, el valor P1=’00’ indica que se esta en el modo CURRENT.
Cualquier otro valor corresponde a modo ABSOLUTO. El campo de datos de este
comando es entonces:
Byte No Descripción Longitud (Bytes)
1 – n Dato a ser actualizado n
n+1 - n+8 Criptograma (Si esta en modo PRO) 8 TABLA 29. Campo de datos del comando UPDATE
IEL2-I-2003-19 IEL2-I-2003-22
105
3.7.5 Comando READ RECORD
Este comando de salida es usado para leer una cadena de bytes (que debe ser de
un EF de registro); existen los mismos 6 modos anteriormente descritos en el
comando UPDATE para leer los registros. La estructura del comando es la
siguiente:
CLA Valor del Byte en Hexadecimal
INS ‘B2’
P1 Número del Registro
P2 Modo
P3 (Long. del campo de datos) Número de bytes a leer
Campo de Datos Vacío TABLA 30. Estructura del comando READ
Y la respuesta enviada por este comando determina un campo de datos de la
siguiente forma:
Byte No Descripción Longitud (Bytes)
1 – n Registro de datos n TABLA 31. Campo de datos del comando READ
3.7.6 Comando GET CHALLENGE
Usando este comando de salida, el exterior (lector) puede preguntar por un número
aleatorio de 8 o 16 bytes a la tarjeta. Este comando debe ser siempre ejecutado
antes de otro comando si se trabaja en modo PRO. Es utilizado como se comentó
anteriormente para realizar funciones de seguridad con autenticaciones (que
involucran criptografía).
La estructura del comando es la siguiente:
IEL2-I-2003-19 IEL2-I-2003-22
106
CLA Valor del Byte en Hexadecimal
INS ‘8A’
P1 ‘00’
P2 ‘00’
P3 (Long. del campo de datos) Longitud del número aleatorio pedido
Campo de Datos Vacío TABLA 32. Estructura del comando GET CHALLENGE
La estructura de la respuesta es la siguiente:
Byte No Descripción Longitud (Bytes)
1 – n Número aleatorio n TABLA 33. Respuesta al GET CHALLENGE
3.7.7 Comando EXTERNAL AUTHENTICATION
Usando este comando de entrada, el exterior provee a la tarjeta de su conocimiento
de una llave y puede por tanto ser autenticado por la tarjeta. El exterior pide un reto
(challenge con el comando GET CHALLENGE) a la tarjeta y este le envía el reto
cifrado a la tarjeta (con la llave a autenticar), especificando el número de llave
usada. La tarjeta verifica el criptograma recibido. Si es correcto el derecho AUT
(autenticación) es otorgado.
La estructura del comando es la siguiente:
CLA Valor del Byte en Hexadecimal
INS ‘82’
P1 ‘00’
P2 Número de llave (‘00’)
P3 (Long. del campo de datos) Número de bytes con datos
Campo de Datos Dato enviado a la tarjeta TABLA 34. Estructura comando EXTERNAL AUTHENTICATION
IEL2-I-2003-19 IEL2-I-2003-22
107
Y el campo de datos es de la siguiente forma:
Byte No Descripción Longitud (Bytes)
1 – n Criptograma n TABLA 35. Campo de datos del comando EXTERNAL AUTHENTICATION
3.7.8 Comando GET RESPONSE
Este comando de salida es usado para leer la respuesta preparada por la tarjeta
después de haberse utilizado el comando SELECT o INTERNAL (o EXTERNAL)
AUTHENTICATION o un ATR.
Cualquier respuesta preparada por la tarjeta debe ser leída de inmediato, de lo
contrario, si se realiza otro comando la respuesta se perderá.
La estructura del comando es:
CLA Valor del Byte en Hexadecimal
INS ‘C0’
P1 ‘00’
P2 ‘00’
P3 (Long. del campo de datos) Número de bytes requerido
Campo de Datos Vacío TABLA 36. Estructura comando GET RESPONSE
3.8 MECANISMOS DE SEGURIDAD
3.8.1 Criptografía y Seguridad
3.8.1.1 DES (Data Encryption Standard): El DES es un algoritmo criptográfico de
simetría en bloques de 64 bits creado en los EEUU como resultado del afán del
gobierno americano para la estandarización de un algoritmo de seguridad utilizando
IEL2-I-2003-19 IEL2-I-2003-22
108
encripción de datos. Las principales características de un algoritmo de encripción
radica en:
• Ofrecer un alto grado de seguridad.
• Ser un algoritmo público y de fácil comprensión.
• Residir la seguridad del mismo en la clave secreta y no en el algoritmo en sí.
• Ser de implementación barata y de uso general.
De entrada se tiene un mensaje de 8 bytes mas una llave K (Key) de 8 bytes y la
salida es un dato cifrado C (cipher) también de 8 bytes. La operación es designada
como:
C=DESK(M)
La operación inversa es:
M=DESK-1(C)
El triple DES o 3DES son una extensión de el DES que usa llaves de 16 bytes.
La entrada y la salida permanecen igual (8 bytes). La llave K (16 bytes) consiste en
dos llaves DES (8 bytes cada una):
K1 designa la llave correspondiente a los primero 8 bytes de la llave K y K2 se
refiere a los 8 últimos bytes de K (K = K1||K2 donde || es la unión de cadenas). De
tal forma la operación para los triple DES puede verse como:
C=3DESK1K2(M)=DESK1[DESK2-1(DESK1(M))]
El modo de encripción CBC procesa mensajes cuyo tamaño es mayor a 8 bytes, de
tal forma que el mensaje M es dividido en n bloques cada uno de 8 bytes (el bloque
puede ser rellenado con bytes de valor 0 es decir ‘00’ en hexadecimal) y se escoge
un valor inicial al algoritmo, por tanto la operación que realiza el algoritmo puede ser
vista como:
C0=IV
Ci=DESK(Ci-1 XOR Mi) si 1 ≤ i ≤ n
IEL2-I-2003-19 IEL2-I-2003-22
109
El resultado de la cadena M cifrada por el algoritmo CBCDES bajo la llave K y el
valor inicial IV es la cadena:
C=C1||C2||… ||Cn.
Resumiendo, la operación es:
C=CBCDESK(IV, M)
Y el valor descifrado es:
C0=IV
Mi=DESK-1(Ci) XOR Ci-1 si 1 ≤ i ≤ n
Los algoritmos CBC3DES y CBC3DES-1 pueden ser definidos de la misma forma.
EL modo CBC permite introducir la noción de certificado, De hecho el bloque Cn
depende del mensaje completo M. Como consecuencia, si el mensaje M y el bloque
Cn transmitidos, la integridad del mensaje M y la llave K son verificadas. El bloque
Cn es llamado MAC (Message Authentication Code) del mensaje M y es designado
como:
Cn=MACK(IV,M)
La entrada a todos lo algoritmos solo puede ser múltiplos de 8 (en bytes). Para DES
y triple DES el tamaño específico es 8. Para CBCDES y CBC3DES el tamaño es
8xn donde n es un entero entre 1 y 8.
3.8.1.2 Algoritmo Plano: El algoritmo plano se refiere a que no existe acción alguna
sobre el mensaje M, es decir, este no se encuentra encriptado.
3.8.1.3 Identificador de Algoritmos: Como se puede implementar cualquier
algoritmo de los antes mencionados es necesario aclararle al sistema operativo de
la tarjeta cual de todos ha de ser implementado; cada llave que se utilice podrá
trabajar con alguno de estos algoritmos.
IEL2-I-2003-19 IEL2-I-2003-22
110
Enciframiento Desciframiento
CBC ‘1F’ ‘1B’ DES Simples
No CBC ‘1E’ ‘1A’
CBC ‘1D’ ‘19’ 3 DES
No CBC ‘1C’ ‘18’
PLANO ‘3F’ ‘3F’ TABLA 37. Identificador de Enciframiento
3.8.1.4 Significado de CHV: La CHV (Card Holder Verification) es una clave que
puede ser usada para seguridad adicional. La presentación de una clave puede a su
vez ser plana o cifrada. Diferentes valores de CHV o claves pueden ser
implementadas en la tarjeta y corresponden a varios niveles de autorización.
3.8.2 Manejo de Llaves (Para Encripción)
3.8.2.1 Estructura de los Archivos de Llaves (EFKEY_MAN y EFKEY_OP): Las
llaves para la encripción en una tarjeta son guardadas en dos tipos de archivos o
ficheros dependiendo de su uso. Las llaves usadas para comandos administrativos
(tales como creación, borrado de archivos, etc) de la tarjeta son guardadas en
archivos de tipo EFKEY_MAN. Las llaves referentes a comandos de aplicación
están guardadas en los archivos de tipo EFKEY_OP. Un DF o el MF no contienen
mas de un archivo de cada tipo de los antes mencionados. Cada uno de estos
archivos contiene máximo 16 llaves, numeradas de 0 a 15 (en valor hexadecimal).
Cada llave esta asociada con una longitud, un identificador de algoritmo (que
aparece en la tabla anterior) y un contador de error. El contador de error es
decrementado cada vez que hay error al tratar de utilizar la llave.
3.8.2.2 Estructura de Archivos CHV (EFCHV): Las claves (CHV) son guardadas
en archivos EFCHV. Cada DF o MF no contiene mas de dos archivos de los antes
mencionados llamados EFCHV1 y EFCHV2. Cada archivo contiene una clave y un
valor de desbloqueamiento. Además cada archivo EFCHV contiene:
IEL2-I-2003-19 IEL2-I-2003-22
111
• El valor de inicialización (N) del contador de intentos.
• El número de intentos que quedan. Si la representación es correcta, el contador
se resetea al valor N. Si la representación es errónea se decrementa el valor.
Cuando dicho valor llega a 0 el archivo es bloqueado.
• Existe un contador de desbloqueos que se decrementa cada vez que se hace un
desbloqueo. Si el valor inicial del contador es ‘FF’ el valor del contador no es
decrementado.
3.8.3 Comandos de Seguridad
3.8.3.1 Comandos Relacionados con CHV: VERIFY/CHANGE/UNBLOCK CHV: EL comando VERIFY CHV es el comando de presentación de la clave. Si la clave es
correcta se da permiso para operar sobre los archivos que estén relacionados con
dicha clave. Si la calve es errónea se niega el derecho a acceder a la información y
se decrementa el contador en el EFCHV.
El comando CHANGE CHV cambia el valor de la clave, es claro que debe
conocerse el valor de la clave anterior para poder cambiar el valor de dicha clave.
El comando UNBLOCK CHV sirve para desbloquear la clave cuando el contador de
errores llega a 0. No se puede implementar este comando si no se ha bloqueado la
clave. Cuando se desbloquea la clave, se debe dar una nueva clave y el contador
de errores es reiniciado.
3.8.3.2 Autenticaciones (EXTERNA/INTERNA): El terminal (Tarjeta o lector) o la
aplicación que debe ser autenticada gracias a una llave de encripción usa los
comandos de AUTENTICACION INTERNA Y AUTENTICACION EXTERNA. en la
AUTENTICACION EXTERNA Se debe primero preguntar por el comando GET CHALLENGE de 8 o 16 bytes a la tarjeta. El reto (o challenge) es encriptado o
cifrado bajo una llave que debe ser autenticada y retornado. Si la tarjeta valida la
respuesta (se utilizo una llave correcta) da el derecho a actuar sobre los ficheros
relacionados con la llave (y el archivo que contiene la llave ) en cuestión. Si existe
IEL2-I-2003-19 IEL2-I-2003-22
112
error el contador de errores en el archivo de llaves (EFKEY_MAN o EFKEY_OP) es
decrementado. Existen 32 derechos diferentes (16 para cada tipo de archivo
EFKEY).
El comando de AUTENTICACION INTERNA la tarjeta es la que debe ser validada
por el lector y trabaja en forma simétrica que el de la AUTENTICACION EXTERNA.
El comando no abre ningún derecho ni decrementa ningún contador.
3.8.3.3 Comandos de Entrada/Salida Cifrados: Algunos comandos de entrada
como UPDATE, WRITE BINARY, VERIFY CHANGE, UNBLOCK CHV Y LOAD KEY
FILE pueden ser cifrados para obtener mayor seguridad, sobre todo entre la
comunicación que se realiza entre la tarjeta y la interfaz que la va a leer. El sistema
operativo de la tarjeta descifra el dato de entrada (comando) y lo escribe en forma
plana dentro de ella para poder trabajar.
Para los comandos VERIFY y UNBLOCK CHV, el comando debe ser ejecutado
después del comando GET CHALLENGE. Para los otros comandos deben ser
ejecutados después del comando PUT CHALLENGE. Otros comandos READ
BINARY y RECORD pueden ser cifrados también con lo que su resultado debe ser
descifrado en el exterior posteriormente.
3.8.3.4 Modo PRO (Protección): El modo protegido transmite un certificado junto
con el comando. El certificado es un MAC (Message Authentication Code) que
depende del comando y sus datos. El modo PRO es usado para asegurar la
integridad y el origen de los datos transmitidos desde el exterior a la tarjeta. Para
ejecutar el comando el exterior pide un reto (GET CHALLENGE), los ochos primeros
bytes del reto son usados como valor de iniciación (IV) para el modo CBC (ya
mencionados anteriormente). Entonces el MAC es calculado:
MAC=MACK(IV, CLA||INS||P1||P2||P3||ID||’00’||DATA)
IEL2-I-2003-19 IEL2-I-2003-22
113
Si la verificación del certificado es correcta, la tarjeta ejecuta el comando. No hay
derechos otorgados. Si el certificado es erróneo, el comando no es ejecutado y el
contador de error (en el archivo de llaves) es decrementado.
Solo los siguientes comandos pueden ser ejecutados en modo PRO: CREATE /
DELETE FILE, INVALIDATE, REHABILITATE, WRITE / UPDATE BINARY /
RECORD, LOAD KEY FILE.
3.8.4 Condiciones de Acceso (AC)
Las condiciones de acceso o AC son definidas para cada fichero sea de tipo EF, DF
o MF. Estas condiciones deben ser conocidas antes de tratar de acceder a la
información de estos ficheros vía comandos.
Estas condiciones son definidas en el momento en que se crean los ficheros.
Las AC básicas son:
ALW Las acciones son siempre posibles y ejecutadas sin ninguna
restricción.
NEV La acción sobre el fichero en cuestión nunca es posible.
CHV1 El derecho a actuar corresponde a la correcta presentación de la
clave relevante CHV1.
CHV2 El derecho a actuar corresponde a la correcta presentación de la
clave relevante CHV2.
PRO Los comandos deben ser transmitidos en modo PRO para que la
acción sea realizada.
AUT EL derecho a actuar depende de una autenticación externa exitosa.
La codificación para las condiciones de acceso es la siguiente:
IEL2-I-2003-19 IEL2-I-2003-22
114
ALW ‘0’
CHV1 ‘1’
CHV2 ‘2’
PRO ‘3’
AUT ‘4’
RFU ‘5’
CHV1/PRO ‘6’
CHV2/PRO ‘7’
CHV1/AUT ‘8’
CHV2/AUT ‘9’
RFU ‘A’
RFU ‘B’
RFU ‘C’
RFU ‘D’
RFU ‘E’
Ninguna ‘F’ TABLA 38. Condiciones de Acceso (RFU: reservado para uso futuro)
Donde RFU se refiere a reservado para uso futuro (Reserved for Future Use). Ya
una vez se sabe el código para cada condición de acceso (código que se encuentra
entre 0 y 15 lo que corresponde a un valor hexadecimal entre ‘0’ y ‘F’) se puede
llenar los campos correspondientes a las condiciones de acceso en el momento de
crear un archivo o fichero. Para dichos campos podemos ver las siguientes tablas
que se refieren a los bytes entre 9 y 11 (en el orden correspondiente para las
condiciones de acceso cuando se crea el fichero) cuyos valores varían dependiendo
del tipo de fichero o archivo a crear. Para un DF se tiene:
RFU RFU Byte 9
DELETE FILE CREATE Byte 10
REHABILITATE INVALIDATE Byte 11 TABLA 39. Valores de los bytes para Condiciones de Acceso
IEL2-I-2003-19 IEL2-I-2003-22
115
Para un fichero de claves o CHV:
LOAD KEY FILE UPDATE Byte 9
RFU RFU Byte 10
REHABILITATE INVALIDATE Byte 11 TABLA 40. Valores de los bytes para Condiciones de Acceso
Para un EF binario:
READ BINARY UPDATE BINARY Byte 9
WRITE BINARY RFU Byte 10
REHABILITATE INVALIDATE Byte 11 TABLA 41. Valores de los bytes para Condiciones de Acceso
Para un EF de registro:
READ RECORD UPDATE RECORD Byte 9
WRITE RECORD RFU Byte 10
REHABILITATE INVALIDATE Byte 11 TABLA 42. Valores de los bytes para Condiciones de Acceso
IEL2-I-2003-19 IEL2-I-2003-22
116
4 IMPLEMENTACION REALIZADA EN LA TI HOST DE LA MARCA OBERTHUR
Una vez definida las propiedades, estructura y manejo de la tarjeta inteligente, se
realizó una implementación sobre esta, enfocada al aplicativo con el fin de guardar
cierta información bajo ciertos parámetros de seguridad referente al beneficiario del
servicio de salud.
4.1 ESCOGENCIA DE TI Y LECTOR
Para realizar el piloto, la implementación real del aplicativo, es necesario partir del
uso de cierto lector y cierta tarjeta. No todas las tarjetas funcionan con todos los
lectores, y a su vez no todas las tarjetas sirven para lo que se quiere hacer dados
los tipos de tarjetas definidos en capítulos anteriores.
Los parámetros generales a tener en cuenta para la escogencia de la tarjeta fueron
los siguientes:
• Precio Tarjeta/Lector.
• Capacidad de memoria de la TI.
• Velocidad de Transmisión del lector.
• Tipo de conexión del lector (USB, Serial, etc).
• Software para la gestión del lector.
• Versatilidad de la TI (Si es reprogramable o no).
• Respaldo Técnico por parte del proveedor.
De tal forma, teniendo en cuenta dichos parámetros, se escogió a la marca francesa
Oberthur (con representación en Colombia), para hacer la implementación. De esta
obtuvimos el manual de programación, respaldo técnico (si se decide usar
masivamente a futuro), un lector (el Delarue 132), varias tarjetas (HOST), librería
IEL2-I-2003-19 IEL2-I-2003-22
117
para el control del lector (trabajable en Visual Basic o C). Cabe comentar que la
primera implementación fue realizada con la marca Gemplus, de la cual solo
obtuvimos el lector y ciertas tarjetas; no pudimos obtener la librería de control del
lector y las tarjetas no eran reprogramables, de tal forma buscamos apoyo técnico y
nos llevamos la sorpresa que la marca se fue del país. Por tal motivo se buscó una
nueva marca con la cual trabajar pues estas dos son las más implementadas en
Colombia.
Dentro de las características básicas del lector escogido tenemos:
• Lector de Contacto (necesita tener contacto con la TI)
• Velocidad de transmisión de 38400 baudios (con posibilidad de trabajarse en
múltiplos de 9600 baudios).
• Conexión de tipo Serial.
• Precio cercano a los 40 dólares.
A su vez, para la tarjeta se tiene:
• Reprogramable.
• Capacidad de 8 Kbytes.
• Trabaja con algoritmos de encripción DES, 3DES, CBC DES y CBC 3DES.
• Voltaje de trabajo de 5 V.
• Consumo de potencia de 50 mW.
• Frecuencia de trabajo de 3.57 MHz.
• Precio cercano a los 1.5 dólares.
Refiriéndonos al software para la gestión de la tarjeta y el lector se obtuvo:
• Kit de programación HOST, el cual solo sirve para ver y estructurar la tarjeta
(crear ficheros) pero no para accesar datos.
IEL2-I-2003-19 IEL2-I-2003-22
118
• Librería de Control del lector (GACDLL32.dll) con la que se envían
comandos al lector utilizando ya sea Visual Basic o C como lenguajes de
programación.
4.2 DEFINICION DE LA INFORMACION A MANEJAR
Una vez teniendo dominado el manejo de la tarjeta y el lector, y sabiendo como
estructurar la tarjeta se tuvo que definir cúal era la información que se iba a
almacenar en la tarjeta inteligente (TI), diferente a la Historia Clínica.
Para ello fue necesario recurrir a los datos que manejan usualmente en una entidad
prestadora de salud en el momento de prestar un servicio de salud. Se tuvieron en
cuenta varias fuentes, principalmente:
• Proyecto Sesame Vitale en Francia.
• Proyecto Pasaporte en Salud en EEUU.
• Proyecto SUS en Brasil.
• Estándar que define enfermedades a nivel mundial: Clasificación Estadística
Internacional De Enfermedades Y Problemas Relacionados con La Salud.
Décima Revisión (CIE 10).
• Listado de medicinas autorizadas a otorgar por parte del Seguro Social:
Acuerdo No 83 del Consejo Nacional de Seguridad Social en Salud.
• Colsanitas.
• Seguro Social.
Ya una vez consultada la información que debe manejarse definimos como datos
importantes a manejar los siguientes:
• Nombres y Apellidos del beneficiario.
• Número de Identificación.
• Ciudad, Dirección y Teléfono de residencia.
IEL2-I-2003-19 IEL2-I-2003-22
119
• Fecha de Nacimiento.
• Género.
• Tipo de Contrato.
• Número de Contrato.
• Tipo Sanguíneo.
• Enfermedades crónicas que padece, alergias, etc.
• Drogas que consume.
• Drogas que debe comprar o reclamar.
• Valera (electrónica para este caso).
La idea para la implementación es guardar todos estos datos en forma segura y
ordenada dentro de la tarjeta para ocupar solo lo necesario de memoria. Con estos
datos ya se tiene cierta información básica del beneficiario lo suficientemente útil
para saber de él.
Los 7 primeros manejan la información básica del paciente con la cual puede ser
identificado y localizado. Los siguientes datos manejan toda la información médica
básica, con ella se puede tener una idea del estado del paciente, se puede controlar
la medicación, se puede conocer sus padecimientos graves y sus alergias y además
se tiene un último campo en el que se maneja la valera electrónica, con la cual se
va a controlar la compra y recaudo de vales, ya que el paciente deberá comprar
vales en cierto sitio y después, cuando reciba la atención médica, se descontaran
estos. De tal manera el beneficiario no podrá ser atendido si no esta al día y se
tendrá control sobre el manejo de vales pues con esto se evita la reventa de vales o
la reutilización de estos.
4.3 DEFINICION DE QUIEN MANEJARA LA INFORMACION
Una vez escogidos los campos a utilizarse en la tarjeta inteligente es necesario
definir quién va a manejarlos. Para esto se observaron los cargos que generalmente
se tienen en una entidad prestadora de salud, teniendo en cuenta los proyectos e
instituciones antes mencionados.
IEL2-I-2003-19 IEL2-I-2003-22
120
Generalmente se tienen seis cargos básicos:
• Administrador: Este tiene acceso a toda la información, es la persona con
permiso para leer y modificar todos los datos. Se encarga de manejar la
información tanto de operarios de la entidad de salud como de la
información de los beneficiarios. Es quien puede preparar las tarjetas para
su uso futuro (etapa de pre-personalización que se explicará en capítulos
anteriores).
• Coordinador: Es quien tiene la responsabilidad para crear nuevos
beneficiarios en la entidad. Su misión es llenar los campos de información
básica del paciente para que a futuro este puede acceder a los beneficios.
De tal forma esa información básica va a la TI y a la base de datos. No
podrá llenar los campos médicos ni de valera.
• Cajero: Este tendrá la responsabilidad del manejo de la valera electrónica.
Cargará esta cuando reciba el pago real del beneficiario y solo podrá tener
acceso a este campo.
• Médico: Este podrá leer toda la información en la tarjeta, pero solo podrá
cambiar la información médica. Además esta encargado de manejar la
medicación, manejará la droga a entregar y la droga que consume
regularmente (medicación electrónica).
• Droguista: En este cargo, solo se dará acceso a la información de la
medicación electrónica. El droguista entregará la droga y la borrará de la
tarjeta. De esta forma se controla el manejo de la entrega de drogas y se
evita el fraude. Una vez entregada la droga debe consolidarse en la base de
datos. Podrá además leer la información básica pero no podrá cambiarla.
IEL2-I-2003-19 IEL2-I-2003-22
121
• Emergencia: Este tipo de cargo tendrá el manejo de la información básica y
medica para casos de emergencia en los que se necesite informara a la
familia de un accidente o conocer los antecedentes médicos del
beneficiario. Cabe aclarar que solo tendrá posibilidad de leer esta
información.
Vemos que para cada cargo se pueden manejar solo ciertos campos de toda la
información que contiene la tarjeta. Algunos solo tienen permiso de lectura, otros de
solo escritura y en otros se tiene lectura- escritura.
4.4 DEFINICION DE CÓMO SE VA A MANEJAR LA INFORMACION DE BENEFICIARIOS
Como se dijo al final del numeral anterior, cada cargo manejará solo cierta
información y con ciertas posibilidades de acceso (lectura, escritura, lectura-
escritura).
4.4.1 Ficheros para el Manejo de la Información
Para mantener la información ordenada dentro de la tarjeta se repartió esta en
cuatro campos de la siguiente manera:
• Fichero de Datos Básicos: Este va a contener toda la información básica
del beneficiario.
• Fichero de Enfermedades: Este contiene la lista de enfermedades que
padece al beneficiario.
• Fichero de Drogas: Este contiene la lista de drogas que consume y drogas
a consumir por el paciente.
• Fichero de Valera: Contiene la valera electrónica.
IEL2-I-2003-19 IEL2-I-2003-22
122
• Fichero de Llaves: Donde estarán almacenadas las llaves con las que se
realizan autenticaciones o encripciones.
4.4.1.1 Creación y Estructura de Ficheros: Para poder implementar los ficheros
antes nombrados se tuvo que definir como iba a ser la estructura de ficheros, que
tipo de ficheros se iban a utilizar y de que tamaño iban a ser estos.
En cuanto a la estructura se trabajó de la siguiente forma:
• Un fichero maestro que viene ya definido por la tarjeta (MF)
• 4 ficheros lineales fijos (o EF de Registro) creados para la implementación,
donde cada uno representa a uno de los ficheros antes mencionados.
FIGURA 38. Estructura de ficheros dentro de la TI para la aplicación.
Ya definida la estructura de ficheros se procedió a definir los tamaños de ficheros,
número de registros y tamaño de registros. Para esto se usaron registros del mismo
tamaño para todos los ficheros. Sin embargo el número de registros para cada
fichero varía. De tal forma se tiene:
• Fichero de Datos Básicos: Este tendrá 7 registros, cada uno de 60 bytes
por lo que el fichero tendrá un tamaño de 420 bytes.
IEL2-I-2003-19 IEL2-I-2003-22
123
• Fichero de Enfermedades: Se trabaja con una lista de 10 enfermedades,
cada una con una longitud máxima de 60 bytes, con lo que se tiene que el
fichero es de 600 bytes.
• Fichero de Drogas: Se tiene una lista de 15 drogas, cada una ocupando un
registro de 60 bytes, de tal forma se tiene un fichero de 900 bytes.
• Fichero de Valera: Para la valera solo se utilizó un registro de 60 bytes.
• Fichero de Llaves: Para este fichero existían dos posibilidades, la primera
era crear un nuevo fichero con nuevas llaves (máximo 15 llaves) o utilizar el
fichero de llaves que viene con la misma tarjeta. Por tratarse de un piloto se
decidió utilizar las llaves que venían con la tarjeta. Este fichero posee 15
llaves, cada una de 8 bytes.
De esta forma la capacidad total utilizada de la tarjeta fue de 1980 bytes. Es claro
que se sobre utilizaron recursos de memoria, esto con el fin de no tener problemas
en el momento de trabajar con nombres de enfermedades o drogas muy largos y
pues sabiendo que la capacidad de la tarjeta HOST es de 8000 bytes no se tiene
problema alguno.
Además en el momento de crearse los ficheros, deben definirse ciertos parámetros
como:
• Tamaño del fichero
• ID del fichero
• Tipo de fichero
• Condiciones de Acceso
• Longitud de los registros
• Llaves asociadas al fichero (para autenticación)
IEL2-I-2003-19 IEL2-I-2003-22
124
Que fueron definidos en el capitulo de manejo de la TI.
4.4.2 Seguridad para el Manejo de Datos
Como se observó en el capitulo de mecanismos de seguridad con los que trabaja la
TI, se pueden trabajar básicamente en tres formas:
• Autenticación
• Encripción
• Claves
De estas, la mas segura para el acceso a la información de la tarjeta es el de
autenticación. Lo que tuvimos que hacer fue en el momento de la creación escoger
como condición de acceso la autenticación y a su vez una llave con la cual se va a
realizar la autenticación. La tarjeta, dentro de su fichero maestro (MF) posee un
fichero de llaves (EFKEY) con 15 llaves diferentes, de tal forma que para el acceso
a cada fichero se escogió una llave diferente para cada uno.
De tal manera se tiene que el Fichero de Datos trabaja con la llave No 1.
El fichero de Enfermedades trabaja con la llave No. 2.
El fichero de Drogas trabaja con la llave No. 3.
Y finalmente el fichero de la Valera trabaja con la llave No. 4.
El mecanismo de Autenticación implica que al tratar de leerse o escribirse en cierto
registro de cierto fichero, el exterior (es decir el aplicativo o programa de la interfaz
entre operador y lector) debe pedir un Reto a la tarjeta indicando que llave se
utilizará (definidas en el momento de la creación del fichero). De tal forma si se tiene
la llave correcta el reto será encriptado de la misma forma que lo hace la tarjeta, con
lo que el sistema operativo de esta permite el acceso a la información de los
registros. Si no se utiliza la llave correcta no habrá permiso de acceso a la
información y esta no podrá modificarse.
IEL2-I-2003-19 IEL2-I-2003-22
125
Para toda modificación o lectura de algún fichero de la tarjeta, siempre deberá
pedirse una autorización. De esta manera, nadie que no tenga la llave, podrá
acceder a la información.
IEL2-I-2003-19 IEL2-I-2003-22
126
5 DISEÑO DEL APLICATIVO MEDICO CON TARJETA INTELIGENTE “APMETI”
Una vez que se tuvo dominada la programación y manejo de la TI, se procedió a
elaborar el aplicativo piloto para el manejo de la información de los beneficiarios.
Este Piloto implica la unión de conceptos como: Control de la información, control
del lector (y por tanto de la TI), control de la base de datos e interfaz o punto de
interacción entre el operario de salud y los puntos donde se encuentra concentrada
la información (base de datos y TI).
El aplicativo fue realizado en Visual Basic y Access para las Bases de Datos.
5.1 DEFINICION DE APMETI
Lo primero es definir las entidades que van a manejar la información, por tanto se
tienen:
• Operario de salud.
• Tarjeta Inteligente.
• Base de Datos.
De esta forma se necesita una entidad que sirva de interfaz para el manejo y flujo de
la información. Esa entidad la denominamos Aplicativo, y no es mas que un
software encargado del control de los dispositivos que poseen la información y del
control del acceso y visualización de la misma. Resumiendo las funciones de dicho
software deben ser:
• Control de dispositivos que almacenan la información (como la base de
datos en un PC y la TI (la cual se controla al controlarse el lector)).
IEL2-I-2003-19 IEL2-I-2003-22
127
• Interacción con el operario (permitir accesos, visualización de datos,
aplicaciones específicas, etc.)
• Manejo de la Información (debe controlar la seguridad, lenguajes de trabajo,
forma en la que se debe manipular la información tanto de beneficiarios
como de operarios, etc.)
FIGURA 39. Esquema del Aplicativo
5.2 ACCIONES QUE REALIZA APMETI
En el numeral anterior se dieron a conocer las funciones generales que debe
realizar el aplicativo. Sin embargo si se especifican mas dichas labores se tiene:
IEL2-I-2003-19 IEL2-I-2003-22
128
5.2.1 Creación y Eliminación de Beneficiarios de Servicios de Salud
La idea es que al crearse un nuevo usuario o beneficiario del servicio de salud que
se presta, debe enviarse cierta información a la Base de Datos y a la TI que llevará
dicho usuario; para ello debe cumplirse con ciertas etapas:
5.2.1.1 Etapa Pre – personailizacion: En esta etapa se estructura la tarjeta
virgen que solo tiene el MF y el fichero de llaves que provee el vendedor de
la tarjeta. De esta manera el Administrador podrá tomar cada una de estas
tarjetas y “estructurarlas” para su uso futuro. Es decir, se toma cada tarjeta y
se crean en ella cada uno de los ficheros con los que se van a trabajar
(fichero de datos básicos, enfermedades, drogas y valera electrónica). Una
vez pre-personalizadas las tarjetas se podrá leer y escribir información en
ellas, cumpliendo con las condiciones de acceso o seguridad antes
comentadas.
FIGURA 40. Etapa de Pre-personalización.
5.2.1.2 Etapa de Personalización: En esta etapa se crea el beneficiario como tal.
Después de haber estructurado la TI, el Coordinador tiene que inscribir a nuevos
usuarios o beneficiarios, es aquí cuando la información básica del paciente es
almacenada en la TI y consolidada en la Base de Datos. En esta etapa solo se tiene
acceso a la información básica (solo dicho fichero).
IEL2-I-2003-19 IEL2-I-2003-22
129
FIGURA 41. Etapa de Personalización.
5.2.2 Creación y Eliminación de un Nuevo Operario
A su vez también pueden crease nuevos operarios, para esto el Administrador tiene
acceso a una base de datos en la que se maneja la información de los operarios tal
como:
• Cargo
• Número de Identificación
• Clave personal
• Ciudad
• Jefe a Cargo
Además de crearse o eliminarse a un operario también pueden ser modificados sus
datos.
5.2.3 Manejo de Información según Cargo del Operario
Ya teniendo los cargos definidos y sabiendo que información se va a manejar es
necesario crear para cada operario un panel en el que tendrá acceso a la
información (tanto de usuarios como de operarios) y podrá manipularla, cada uno de
estos páneles trabajan con ciertos botones para cada aplicación y un menú general.
La idea es que el operario pueda leer información de la tarjeta, editarla (borrarla o
modificarla) y consolidarla nuevamente, tanto en la tarjeta como en la base de
IEL2-I-2003-19 IEL2-I-2003-22
130
datos. Por tanto, como se utilizó Visual Basic 6 como herramienta de programación,
cada uno de estos páneles es trabajado en un formulario (término propio para los
páneles en dicho lenguaje) que es el objeto en el que se visualiza la información y
se tienen otros objetos con los cuales puede modificarse esta.
5.2.3.1 Ventana Principal
En este se tiene básicamente un menú principal y una barra de herramientas que
están presentes para cualquier aplicación en cualquier cargo; lo único que varía
para cada una de ellas es la habilitación de ciertos botones y funciones
dependiendo del cargo y de la acción que se esta realizando en el momento. En el
menú principal de tiene:
• Archivo: Dentro de este se tiene:
o Abrir Sesión: En la que se invoca al formulario que pide la
identificación del operario (número de identificación y clave personal)
y posteriormente se invoca al formulario específico para cada cargo.
o Cerrar Sesión: En la que se cierra el formulario del operario después
de que este ha realizado su trabajo.
o Operarios: En este se tiene acceso a la información de operarios
(solo el Administrador tiene acceso a esta). Aca se invoca al
formulario que presenta la información general de todos los
operarios.
o Salir: En donde se pide cerrar el programa y acabar todo trabajo que
se este haciendo.
• Edición: Aca se tienen las aplicaciones típicas de edición como:
o Cortar.
o Copiar.
o Pegar.
IEL2-I-2003-19 IEL2-I-2003-22
131
• Servicios ApMeTI: En donde se tiene acceso al formulario para cada cargo
que solo será habilitado dependiendo del cargo una vez se ha autorizado el
acceso a este. Dentro de este se tiene:
o Administración.
o Coordinación.
o Carga de Valera.
o Drogas.
o Emergencia.
o Servicios Médicos.
• Ayuda: En este se muestra la información del aplicativo en general.
Además del Menú se tiene una Barra de Herramientas la cual se compone de los
siguientes botones:
• Estructurar TI: con este se da la orden de crear los ficheros en la tarjeta. Si
se introduce una tarjeta ya llena o estructurada se borra todo lo que haya en
ella y se estructura de nuevo.
• Editar: Este botón permite visualizar la información ya cargada de la tarjeta
(o de la base de datos para la información de operarios). Es decir permite ver
el formulario de cada cargo con la información completa (según sea el caso).
• Consolidar: Al oprimir este botón se da la orden de escribir en la TI y en la
Base de Datos la información que aparece en ese momento en el formulario.
• Borrar: Con este se borra toda la información que haya en el editor o
formulario de cada cargo. Si posteriormente se da la orden de consolidar se
perderá toda la información que se tenía antes.
• Leer TI: Se da la orden de leer el contenido que hay en la tarjeta.
IEL2-I-2003-19 IEL2-I-2003-22
132
• Activar TI: Este es el botón más importante. Con el se ordena activar el
lector, activar la tarjeta, entablar comunicación con la TI, y leer la información
que hay en la TI. Posterior a oprimir este botón se pueden realizar la edición
de datos en el formulario de cada cargo.
• Desactivar TI: Si se oprime este se ordena terminar la comunicación con la
tarjeta y apagar al lector. No se consolidan los datos al oprimir este, por lo
que es importante estar seguro de que se va a terminar la comunicación con
la TI.
• Ayuda: Este botón hace que se visualice una ventana o formulario con la
información general del programa ApMeTI.
• Salir: Si se oprime se da la orden de cerrar el programa y acabar todas las
aplicaciones.
FIGURA 42. Ventana de Información acerca del programa ApMeTI.
IEL2-I-2003-19 IEL2-I-2003-22
133
5.2.3.2 Ventana de Trabajo para el Administrador
5.2.3.2.1 Ventana para la Información de Operarios: En esta se tiene el panel
de trabajo para el cargo de Administrador, para el manejo de la información de
operarios, acá el Administrador tiene acceso a:
• No de identificación del operario
• Nombre del operario
• No de identificación del supervisor
• Ciudad
• Departamento
• Clave de acceso
• Cargo
El Administrador sobre estos datos puede:
• Ver cada registro con la información de cada operario (registro inicial, final,
siguiente, anterior)
• Buscar un registro
• Editar un registro
• Borrar un Registro
• Grabar los cambios
• Refrescar
IEL2-I-2003-19 IEL2-I-2003-22
134
FIGURA 43. Ventana del Administrador para el manejo de datos de Operarios
5.2.3.2.2 Ventana para Información de Beneficiarios: En esta el Administrador
tiene acceso a toda la información del paciente, puede:
• Modificar la Información Básica del paciente.
• Modificar la Valera Electrónica.
• Modificar las Enfermedades que tiene en lista el beneficiario.
• Modificar las Drogas que tiene en lista el beneficiario.
IEL2-I-2003-19 IEL2-I-2003-22
135
FIGURA 44. Ventana del Administrador para el manejo de datos de Beneficiarios
5.2.3.3 Ventana de Trabajo para el Coordinador: En esta ventana el Coordinador
solo puede accesar Información Básica del Beneficiario. Una vez este conforme con
lo escrito en ella debe oprimir el botón de “Anotar Datos” para asegurar que esa es
la información que se debe consolidar.
IEL2-I-2003-19 IEL2-I-2003-22
136
FIGURA 45. Ventana del Coordinador
5.2.3.4 Ventana de Trabajo para el Medico: En esta ventana el Médico solo puede
observar la Información Básica del paciente o beneficiario mas no puede
modificarla. Tiene además el listado de drogas y enfermedades con las que puede
trabajar (con el fin de estandarizar que cada médico trabaje con la misma lista de
enfermedades y drogas).
Con los botones de agregar o quitar puede llenar la lista propia del paciente para los
campos de enfermedades y drogas como se ve en el siguiente gráfico:
IEL2-I-2003-19 IEL2-I-2003-22
137
FIGURA 46. Ventana de trabajo para Médico
5.2.3.5 Ventada de Trabajo para el Cajero: Este solo puede agregar o quitar vales
de la valera electrónica, puede escoger entre agregar 1, 5 o 10 vales o quitar 1 vale
de la valera.
IEL2-I-2003-19 IEL2-I-2003-22
138
FIGURA 47. Ventana del Cajero
5.2.3.6 Ventana de Trabajo para el Droguista: El Droguista puede ver ciertos
datos de la Información Básica del beneficiario mas no puede modificarlos (esto con
fines de identificar a quien reclama la droga). A su vez puede modificar la lista de
medicamentos que posee el beneficiario en la TI. Puede seleccionar la droga que va
a entregar o des-seleccionarla. A continuación vemos dicho formulario o pantalla.
IEL2-I-2003-19 IEL2-I-2003-22
139
FIGURA 48. Ventana del Droguista
5.2.3.7 Ventana de Trabajo para Funcionarios de Emergencia: Este cargo fue
creado para todo aquel funcionario que necesite saber en caso de emergencia datos
básicos del paciente referentes a su identidad, su medicación y su pasado de
enfermedades. De tal manera solo tiene la posibilidad de leerlos mas no
modificarlos. La ventana que se visualiza es:
IEL2-I-2003-19 IEL2-I-2003-22
140
FIGURA 49. Ventana del operario de Emergencia
5.2.3.8 Ventana de Inicio de Sesión: Cada vez que se abre el programa, el
operario debe identificarse, para esto Abre Sesión en el campo de Archivo del Menú
Principal y posteriormente aparece la ventana para iniciar sesión. En esta se le
pregunta en forma secreta al operario su No de Identificación y su Clave Secreta. Si
ambos son correctos se logra identificar al operario y se le da acceso a su
aplicación, es decir que solo podrá cargar datos a la ventana correspondiente, mas
no tendrá acceso a las ventanas de otros cargos. La ventana es de la siguiente
forma:
IEL2-I-2003-19 IEL2-I-2003-22
141
FIGURA 50. Ventana de Inicio de Sesión
5.3 CÓMO SE CREO APMETI
Como comentamos antes, ApMeTI es el piloto del aplicativo que se tendría que
montar para dar solución al problema de las entidades prestadoras de servicios de
salud. De tal manera que el aplicativo se refiere a la creación de un software
encargado de hacer esto. Dicho software o programa debe ser:
• Sencillo de manejar.
• Trabajar bajo un ambiente Windows por facilidad.
• Permitir la visualización de determinada información.
• Servir de interfaz entre operario y puntos donde se encuentra la
información.
• Tener herramientas para manejar dicha información.
IEL2-I-2003-19 IEL2-I-2003-22
142
• Controlar dispositivos que involucren el manejo de información (Base de
Datos Local y Remota, Lector y TI).
• Control de la seguridad.
• Manejar todos los niveles de programación.
Definidas ya las funciones que debe tener dicho software, decidimos trabajar con el
lenguaje de Programación Visual Basic 6 para crear la interfaz y toda la
infraestructura software en general. A su vez se utilizó la herramienta Acces para el
manejo de la Base de Datos y aquí además se utilizó el lenguaje SQL para la
comunicación con el programa en Visual del piloto y la Base de Datos.
5.3.1 Arquitectura De ApMeTI
Como tenemos un programa encargado de realiza todo el trabajo, debemos
entender que dicho trabajo esta repartido en ciertos niveles los cuales operan bajo
ciertos lenguajes con tareas diferentes.
Para ello definimos 3 niveles básicos:
• Nivel Alto: En este se encuentra todo lo referente a interacción con el
operario. Se refiere a los formularios y ventanas de trabajo. Es programado
netamente en VB6 y lo único que se hace en este es la visualización de
datos y la invocación de funciones de mas bajo nivel para el procesamiento
de estos.
• Nivel Medio: En este ya se trabajan con las funciones invocadas en el nivel
alto y demás funciones encargadas de conformar los comandos APDU para
la interacción con la tarjeta y con la base de datos. Es el nivel mas
importante en cuanto a programación que nosotros realizamos pues aquí es
donde se invocan funciones para consolidar la información, mecanismos de
seguridad, procesamiento de datos (como paso de binario a hexa,
empaquetamiento, fraccionamiento, etc) y manejo de la librería de control del
IEL2-I-2003-19 IEL2-I-2003-22
143
lector (GACDLL32.dll). Los lenguajes de programación aquí involucrados son
VB, SQL (para la Base de Datos) y C (con el que trabaja internamente la
librería).
• Nivel Bajo: Este nivel ya no es trabajado por el programador, es controlado
por la librería y se refiere al control de la comunicación entre tarjeta y lector
(básicamente lenguaje de máquina y señalización eléctrica). A este mismo
nivel debe operar la comunicación entre terminal y base de datos regional y
central (sea TCP o PPP).
5.3.2 Implementación en Visual Basic 6 (VB6)
Es de suma importancia aclarar el porqué se utilizó VB6 como lenguaje de trabajo
para el software encargado de hacer el aplicativo. En primer lugar VB6 es un
lenguaje de programación orientado a objetos refiriéndonos de esta forma a que
las funciones que se trabajan responden a cambios o eventos que ocurren en
ciertos objetos como botones, listas, cuadros de texto, menús, etc. De esta forma
como se quiere plantear una comunicación con el operario en la que este tiene a su
disposición cierta información y puede modificarla de cierta forma (cambiando cosas
y oprimiendo botones, es decir cambio en eventos) es claro que dicho manejo de
datos es orientado a objetos. A su vez, el sistema operativo de la TI, trabaja
orientado a objetos, en este para poder cambiarse cierto valor, en cierto registro, de
cierto fichero es necesario indicarle al SO (sistema operativo) paso a paso lo que se
quiere hacer mediante el uso de apuntadores. Por eso es que en el momento de
escribir en un registro, es necesario primo utilizar el comando Select para
seleccionar el fichero a trabajar y una vez colocado el apuntador de fichero es
necesario ubicar el apuntador de registro, posteriormente es cuando se puede
modificar la información. De esta forma vemos que para armonizar con el SO de la
tarjeta es bueno implementar una programación de este tipo.
Básicamente en VB se tienen dos instrumentos de trabajo: El primero son los
formularios donde se tienen los objetos que interactuarán con el operario y a su
vez toda acción que se haga en estos formularios invocaran a ciertas funciones para
IEL2-I-2003-19 IEL2-I-2003-22
144
el procesamiento de datos, comunicación con la Base de Datos y el Lector; dichas
funciones de procesamiento están contenidas en los denominados módulos. Es así
que se utilizaron varios formularios dependiendo del cargo con el que se
interactuaba y varios módulos dependiendo del tipo de funciones que se trabajaban
para cierta aplicación.
FIGURA 51. Ambiente de Visual Basic de la implementación hecha.
5.3.2.1 Formularios: Estos vemos que son simplemente las ventanas de trabajo
que se utilizaron. En ellos existen ciertos elementos encargados de visualizar
información que puede estar dentro de la TI o que puede ser introducida dentro de
la TI. A su vez para hacer válidos los cambios en estos elementos de visualización
existen botones para ello. Además de Botones se tiene Listas, una Barra de
Herramientas y un Menú con el cual al dar el evento click se invocan ciertos
procesos que son realizados en las funciones contenidas en los módulos.
IEL2-I-2003-19 IEL2-I-2003-22
145
Los formularios son el objeto en VB encargado de interactuar con el usuario (u
operario en nuestro caso). El resto del trabajo se hace en los módulos.
Para el piloto implementado se utilizaron 11 formularios, donde uno de ellos es
formulario padre (la Ventana Principal) y los demás viene encadenados a el
(formularios hijos una para cada ventada dependiendo del cargo y otras
aplicaciones).
5.3.2.2 MódulosEn estos se tienen todas las funciones necesarias para procesar la
información contenida en la tarjeta, en la Base de Datos y la que interactúa con el
operario. Cada vez que un evento es invocado en los formularios o ventanas de
trabajo ciertas funciones deben trabajar en los módulos, estas son implementadas
en serie, una después de la otra, hasta que se cumple algún objetivo (como el de
consolidar la información en la TI o la Base de Datos).
Se trabajaron 7 módulos de la siguiente forma:
• 1 Módulo que implica traducir las funciones que invocan comandos en la TI
hechas en VB a C. Esto porque los comandos invocados en VB deben ser
enviados al lector para que este los envié a la tarjeta, ya que quien controla
al lector es una librería (DLL). De tal forma este Modulo sirve de traductor
entre las funciones en VB que invocan comandos APDU y la librería
GACDLL32.dll.
• 2 Módulos en los que se encuentran funciones que encriptan, pasan de
valores hexadecimales a binarios y viceversa y todo aquello que sea
necesario hacerse para consolidar un comando APDU (recuerde que los
comandos son la forma en la que se comunica el exterior con la TI).
• 1 Módulo en el que se consignaron todas las funciones temporales que
fueron necesarias para comprobar ciertos procesos.
• 1 Módulo en el que se encuentran todas las funciones que invocan
comandos APDU como escribir, leer, estructurar tarjeta, etc.
• 1 Módulo en el que se encuentran todas las definiciones y constantes que
se necesitan en todo el programa.
IEL2-I-2003-19 IEL2-I-2003-22
146
• 1 Módulo en el que están todas las funciones generales encargadas de
tomar datos de los formularios, escribirlos, procesar dichos datos, etc.
En los módulos solo se encuentran funciones y definiciones. Cada función
implementada fue debidamente comentada en el momento de crear el código de
programación.
Cabe comentar que antes de realizar el aplicativo se realizaron pruebas en la tarjeta
HOST. De este trabajo previo podemos ver la siguiente imagen de la ventana de
prueba que se tenía:
FIGURA 52. Ventana de prueba de la primera implementación con la TI HOST.
IEL2-I-2003-19 IEL2-I-2003-22
147
5.3.3 Utilización de ACCESS
Para el manejo de Base de Datos (tanto local como remota y central) el piloto fue
trabajado en esta herramienta por facilidad ya que dentro de las herramientas que
posee Microsoft está esta. La idea es que en cada entidad exista una base de datos
local y pues la mayoría de estos centros poseen las herramientas de Microsoft de tal
forma que no habría que instalar otro software para el manejo de estas. Sin
embargo la Base de Datos mas grandes, como la Regional y la Central podrían ser
de otro tipo más robustas y versátiles, sin embargo este no es el fin primordial en
nuestro piloto.
Se crearon dos bases de datos, una para operarios y otra para beneficiarios, en
cada una de ellas se manejaron ciertos campos como:
FIGURA 53. Base de Datos Inicial para Operarios
IEL2-I-2003-19 IEL2-I-2003-22
148
FIGURA 54. Parte de la Base de Datos de Pacientes
5.3.4 Librería de Control (DLL) del lector implementado (Delarue)
Para poder realizar la implementación sobre la TI utilizando a Visual Basic como
lenguaje de programación de la interfaz es necesario tener una entidad encargada
de traducir el manejo de la información bajo VB al lenguaje que trabaja el lector.
Además de controlar la comunicación, el acceso a la tarjeta y todos los mecanismos
de seguridad. Para tal fin, el proveedor del lector y la TI debe dar una librería
encargada de realizar todas estas tareas. La idea es trabajar en Visual y luego
invocar funciones que realiza la librería.
Esta librería es llamada GACDLL32.dll y es la que maneja:
• Comunicación entre PC, Lector y Tarjeta Inteligente.
• Algoritmos de Encripción (DES, RSA, CBC DES).
IEL2-I-2003-19 IEL2-I-2003-22
149
• Detección de errores.
• Apagado, Encendido del lector.
• Peticiones de recursos del sistema.
Si no se tiene dicha librería es imposible habilitar al lector para interactuar con la TI.
Además de la instalación de la librería, es necesario hacer una previa instalación del
controlador del lector especifico en el Panel de Control en donde se especifica que
lector se va a utilizar y como se le va a llamar.
IEL2-I-2003-19 IEL2-I-2003-22
150
CONCLUSIONES
• Se propuso una solución para las entidades que prestan servicios de salud,
utilizando tecnologías de punta basándose en proyectos ya implementados
en Colombia y el exterior.
• Dicha solución implica el desarrollo de un aplicativo para la gestión de la
información, una implementación con TI y un diseño de una red
transaccional.
• La TI es la mejor opción para el almacenamiento y manejo seguro de
información portable, superando notablemente el desempeño de su
predecesora, la tarjeta de banda magnética.
• Logró implementarse un Piloto del aplicativo propuesto en el cual se
involucró la programación de TI, el acceso seguro a la información contenida
en la TI y el manejo de base de datos.
• Se diseñó y dimensionó la infraestructura necesaria para la ejecución del
proyecto. Así mismo se estimaron costos de inversión inicial en equipos e
instalación y los costos de operación y mantenimiento.
• Dado que para la solución presentada, no se utilizaron todos los recursos
disponibles de la TI, podrían ser implementadas otras aplicaciones de
diversas áreas que ocupen dichos recursos.
• Por la misma razón anterior podría implementarse dentro del aplicativo
herramientas biométricas para brindar un mayor nivel de seguridad al acceso
de datos.
• En aplicaciones futuras puede implementarse las nuevas tecnologías en
ICC, como la Java Card.
• Para la implementación de la Tarjeta Inteligente y su lector, es necesario
definir previamente qué tipo de datos se van a manejar y en qué forma. Una
vez hecho esto se debe escoger cuál de los anteriores usarse pues el éxito
de la aplicación depende de la velocidad de transferencia, la posibilidad de
estructurar la TI muchas veces y la capacidad de almacenamiento de esta.
IEL2-I-2003-19 IEL2-I-2003-22
151
BIBLIOGRAFIA
[1] Tarjetas Inteligentes. Juan Sandoval, Ricardo Brito, Juan C. Mayor. 1999.
Editorial Paraninfo.
[2] Smart Cards, Seizing Strategic Business Opportunities. Catherine Allen, William
Bara. Smart Card Forum. 1997. Editorial Irwin.
[3] Invasión de TI en el sector salud. Udo Flohr. Revista BYTE.Abril del 2001.
[4] Estándar para tarjetas inteligentes ISO/IEC 7816-1, 7816-2, 7816-3 y 7816-4.
[5] Manual de programación tarjeta HOST de la marca Oberthur. Facilitado por
INTELIGENSA. Bogotá. Colombia.
[6] Smart Card Technology International. Una división de Global Projects Group.
Editorial SNP Printing Pte Ltda.
[7] Card Tecnology. Revista especializada en Tarjetas Inteligentes. Smart Card
Forum. Ediciones analizadas de 1997 a 2001. Dirección electrónica de la revista:
http://www.cardtechnology.com.
[8] Byte. Revista de sistemas y desarrollos en computación. Ediciones analizadas
1999 a 2001. Editorial Mc Graw Hill.
[9] Hypercom News and Events. Noticias referentes al desarrollo de TI y estándar
EMV. http://www.hypercom.com/news.
[10] www.iss.gov.co, Vicepresidencia de EPS, “expedición de comprobantes de pago, recaudo y transferencia de dineros provenientes de las cuotas moderadoras y de los copagos en el Instituto del Seguro Social. Dicembre 2002.
IEL2-I-2003-19 IEL2-I-2003-22
152
[11] http://anm.fepafem.org/proacad.htm, Pronuncionamiento de la Academia frente a la Ley 100 de 1993. Dr. José F. Patiño [12] Hypercom Message Specification, Octubre 25 de 2002 [13] Topología de la red de Credibanco en Colombia, Carlos Felipe Rosas, Credibanco – Visa. Junio 1998. [14] SUS Project in Brazil, Hypercom Corporation, 2000. [15] The Hypercom Networking Cookbook, Julio 20 de 1997. [16] Propuesta canales nacionales Frame Relay, Juan Ramón Sanchez, Vicepresidencia Comercial Telecom. Marzo 2003. [17] Propuesta Comercial servicio 01800 para datos, Juan Carlos Uribe Rodríguez, Marzo 2003
IEL2-I-2003-19 IEL2-I-2003-22
153