Dispositivo electronico para la realización de transacciones bancarias por medio de una red inalámbrica iDEN (página 2)
Enviado por Daniel Felipe Pinilla Garcia
Para el desarrollo de este proyecto, la red de datos que se utiliza es la red iDEN, desarrollada por Motorola e implementada en Colombia por la compañía Avantel S.A. la cual ofrece diferentes tipos de servicios dentro de los cuales están: comunicación vía radio, acceso telefónico, mensajes de texto y transmisión de datos.
18 2. OBJETIVOS
Objetivo General: Desarrollar un dispositivo electrónico que, conectado a un teléfono móvil iDEN, sea capaz de realizar una transacción bancaria segura.
Objetivos específicos:
Implementar una aplicación en J2ME y un dispositivo electrónico compatible con el equipo Motorola iDEN modelo i85s o i58sr, para realizar una transacción bancaria con tarjetas débito y crédito. Desarrollar una aplicación en J2ME para interactuar con el dispositivo electrónico a través del puerto serial del teléfono móvil Motorola. Aplicar la correspondiente mensajería entre el teléfono móvil Motorola y el servidor encargado de aceptar las transacciones bancarias para el éxito de ésta, asegurando la confidencialidad y la integridad de la información.
3. ESPECIFICACIONES DEL DISPOSITIVO
El dispositivo, que de ahora en adelante también denominaremos WI-P.O.S (Wireless Point of Sales, Punto de ventas Inalámbrico), consiste en un desarrollo que involucra la comunicación del dispositivo con un servidor, programación de un teléfono móvil MOTOROLA, manejo de periféricos necesarios para la realización de una transacción bancaria y cifrado de la información para asegurar la confidencialidad de ésta. Todo esto es realizado bajo diferentes esquemas de implementación, utilizando desarrollos en Hardware, Software y Firmware. FIGURA 1. ESQUEMA GENERAL DE TRANSACCIÓN CON SERVIDOR DE VISA
En la Figura 1 se puede observar un esquema sencillo para la realización de una transacción bancaria a partir de WI-P.O.S. El equipo recibe la información ingresada por el usuario, que depende del tipo de transacción que vaya a realizar, y construye
19
Tandem es un nodo en donde se conectan los servidores de los Bancos, y es en estos donde se valida ASIC, Empresa desarrolladora de aplicaciones en hardware y software, orientada al sector financiero. 20 las tramas necesarias que luego envía al teléfono móvil para que éste se comunique a través de la red iDEN (ver Anexo Marco Teórico) con un servidor llamado AS400 (es un servidor con tarjeta criptográfica, esta es una tarjeta capaz de realizar funciones de cifrado, entre las cuales se encuentra la posibilidad de cifrar con el algoritmo DES)) que después se comunicará con el Tandem1 de VISA y esperará respuesta de la aprobación de la transacción. Este proceso se realiza por que el protocolo que maneja las transacciones (Base 24 ver Anexo Marco Teórico) es muy robusto y sería necesaria una gran cantidad de procesamiento en el equipo que incrementaría en gran medida los costos y la complejidad del desarrollo. De manera que existe una aplicación desarrollada por una empresa colombiana (ASIC)2 que recibe cierta información que es recopilada en el P.O.S. (Point of sales, Punto de Ventas) y haciendo uso de esta construye las tramas correspondientes al protocolo Base24 (Ver sección 3.3). En la siguiente sección se presentará un esquema detallado de la realización de una transacción de pago ya sea con tarjeta débito o crédito. 3.1. DIAGRAMAS DE FLUJO DE LOS PROCESOS NECESARIOS PARA LLEVAR A CABO UNA TRANSACCIÓN DE PAGO CON TARJETA CRÉDITO O DÉBITO USANDO WI-P.O.S. 3.1.1. Diagrama de proceso para guardar llaves de cifrado y terminal. Por cuestiones de seguridad toda la información introducida por el usuario al dispositivo es cifrada usando el algoritmo DES (Data Encryption Standard) (ver Anexo Marco Teórico). Por lo tanto, previo a la realización de cualquier transacción, WI-P.O.S debe tener almacenadas una llave maestra y una llave de transporte (Ver Sección 3.4). Las llaves se cargan conectando WI-P.O.S al puerto serial de un computador y por medio de una aplicación realizada en Visual Basic, estas se guardan en la memoria EEPROM del dispositivo. La llave maestra se usa para cifrar las otras llaves y almacenarlas de manera segura. La llave de transporte se usa para 1 la transacción. 2
cifrar cualquier información que se transmita al servidor durante la transacción.
Cada dispositivo debe tener un número que lo identifique, es por esto que también se debe cargar un número de terminal. El número de terminal es representado por 8 caracteres. A continuación se ilustra el diagrama de flujo de la aplicación realizada en Visual Basic: DIAGRAMA DE FLUJO 1 Aplicación de Visual Basic, Administrador de Herramientas para WI-P.O.S Parte 1
21
22 DIAGRAMA DE FLUJO 2 Aplicación de Visual Basic, Administrador de Herramientas para WI-P.O.S Parte 2
23 Esta aplicación realiza 5 funciones principales que son cargar las llaves en el dispositivo, cargar su correspondiente número de terminal, y realizar la operación de verificación de dígitos de chequeo. i)
ii)
iii)
iv)
v) Cargar las llaves: Es un proceso que permite introducir las llaves maestras o la llave de transporte al dispositivo desde el computador. Para evitar que se ingresen valores erróneos el proceso es redundante, es decir, se ingresa dos veces la información de las llaves, además se verifican otros datos como el tamaño de la llave, que tiene que ser exactamente de 16 caracteres, tomando valores hexadecimales (0-F). Cargar número de terminal: Es un proceso que sirve para introducir el número de terminal del dispositivo. Este valor debe ser único por cada uno, ya que es quien lo identifica. Al igual que el proceso anterior, la información se debe ingresar dos veces para evitar que se introduzcan valores erróneos y su tamaño debe ser de 8 dígitos. Dígitos de chequeo: Es un proceso necesario para saber si las llaves ingresadas son correctas. Consiste en el cifrado de ceros con la llave seleccionada, ya sea maestra o transporte, de esta forma la aplicación muestra los 4 primeros valores de la operación y se verifica si son correctos. Cargar Vector de Inicio: Este proceso consiste en cargar el vector de inicio en el dispositivo, tiene una longitud de 16 caracteres en hexadecimal, este valor es indispensable para el correcto cifrado de la información en modo CBC, proceso que será explicado en los siguientes capítulos. Reinicio de consecutivo: Es un proceso por el cual a un dispositivo Wi- P.O.S. se le asigna el valor de consecutivo en ceros, que identifica las transacciones.
3.1.2 Diagrama de flujo de carga de parámetros iniciales Diagrama de flujo 3. Petición de parámetros iniciales
Además de tener las llaves almacenadas, WI-P.O.S debe haber cargado (guardado en memoria) unos parámetros iniciales que obtiene de una conexión con el servidor. Esto último se debe hacer cada vez que se encienda el equipo. En caso de que alguno de estos pasos no se haya realizado, es decir si no se han cargado las llaves (de transporte y maestra) y/o no se han cargado los parámetros iniciales, no se podrá llevar a cabo la transacción. Por esto cada vez que se va a realizar una transacción el equipo verifica que estos datos estén almacenados en el dispositivo y envía al teléfono un mensaje de confirmación.
Para cargar los parámetros iniciales se debe correr una aplicación en J2ME cada vez que se enciende el equipo, de manera que WI-P.O.S arma la trama denominada petición de parámetros inicial (Ver sección 3.3) y la cifra usando la llave de transporte para enviarla al servidor. Este devuelve una trama de parámetros iniciales los cuales se descifran y se almacenan en la memoria del dispositivo. Estos parámetros iniciales incluyen el porcentaje de IVA, solicitud de propina, dígitos a ingresar (para la clave) y el nombre del emisor. Estos dependen del terminal que hace
24
25 la petición. (Ver sección 3.3). 3.1.3 Diagrama de flujo de la realización de una transacción de pago con tarjeta edito o débito:
26
27 DIAGRAMA DE FLUJO 4 Transacción de Pago con tarjeta débito o crédito
28 Después de verificar que los parámetros iniciales estén cargados, por medio de la pantalla del teléfono se le pide al usuario deslizar la tarjeta. WI-P.O.S recibe la información de la tarjeta y arma una trama denominada petición de parámetros de tarjeta. Esta trama se cifra y por medio del teléfono móvil se envía al servidor, el cual devuelve los parámetros de la tarjeta (Ver sección 3.3) que se almacenan en el dispositivo. Después de esto se verifica con los parámetros de tarjeta recibidos del servidor si es necesario el ingreso de PIN (Personal Identification Number) o clave personal, y de serlo así, arma una trama denominada petición de llave de cifrado de PIN la cifra y la envía al servidor el cual devuelve la llave que luego se almacena en WI-P.O.S. Esta llave sirve para cifrar el PIN Block (Ver sección 3.3) que es una trama que se construye haciendo uso del PIN y del PAN (Personal Account Number, Número de Cuenta). Además de ser necesario, el equipo deberá verificar la fecha de vencimiento de la tarjeta, y compararla con la fecha ingresada por el usuario al equipo, o con la fecha del sistema.
Luego el dispositivo, según los parámetros de tarjeta recibidos, pide al usuario los campos correspondientes (valor, cuotas, tipo de cuenta entre otros), arma una trama denominada pago con tarjeta, la cifra, la envía al servidor, y espera respuesta.
Cabe anotar que durante el proceso de la transacción, todas las tramas enviadas y recibidas del servidor van debidamente cifradas usando el algoritmo DES para garantizar la seguridad y confidencialidad de la información que se transmite en ambas direcciones, desde el teléfono y hacia el teléfono.
WI-P.O.S también es capaz de generar transacciones de reverso (ver sección 3.3), esto en caso que nunca se encuentre respuesta o que se genere algún error durante la realización de la transacción. Por ejemplo si en el momento de realizar una transacción ésta fue aceptada pero el mensaje de respuesta no llegó nunca al teléfono móvil. Al no obtener respuesta en el P.O.S. del resultado de la transacción se debe generar un reverso que anulará la correspondiente transacción. (Ver sección 3.3).
29 3.2 ESPECIFICACIONES DE WI-P.O.S. WI-P.O.S es un dispositivo que posee los elementos necesarios para la realización de una transacción de pago con tarjeta débito o crédito. Estos elementos son: un lector de tarjetas de banda magnética, un teclado (para el ingreso del valor de la transacción, PIN, número de cuotas, etc.), un módulo de cifrado DES, un puerto serial y una salida para impresora. El dispositivo tiene una comunicación constante con el teléfono móvil, quien es el que le envía las instrucciones según la implementación de su programa a partir de los módulos y clases en J2ME, desarrollados como parte del trabajo. Además de guiar la transacción, el teléfono móvil tiene el muy importante papel de enviar la información al servidor.
3.2.1 Entradas y salidas del dispositivo
Entradas del dispositivo – – – Lector de Banda magnética Teclado de 4 Filas x 3 Columnas Entrada serial usando el estándar RS-232 o Conector DB9.
Salidas del dispositivo – – Salida serial por estándar RS-232 conector DB9 Salida conector DB9 para impresora. A continuación se mostrará un esquema de las entradas y salidas de WI-P.O.S:
FIGURA 2. ESQUEMA DE ENTRADAS Y SALIDAS DE WI-P.O.S
En la Figura 2 se pueden observar las diferentes entradas y salidas que tiene WI- P.O.S, por medio de las cuales se establece la comunicación, explicada en las siguientes secciones
COMUNICACIÓN CON EL USUARIO: El usuario sólo puede interactuar con WI-P.O.S deslizando la tarjeta de banda magnética por el correspondiente lector y digitando la información solicitada según la instrucción desplegada en la pantalla del teléfono. WI-P.O.S tiene su propio teclado debido a que de esta forma la información digitada no pasa directamente por el teléfono móvil y no se corre el riesgo que se pueda almacenar en éste sino que toda la información se cifra y se guarda directamente en WI-P.O.S, evitando problemas de retención de información, haciendo que la transacción sea más segura. El usuario también tiene derecho a adquirir el comprobante de su transacción bancaria por medio de una pequeña impresora que se conecta al equipo.
COMUNICACIÓN CON TELÉFONO MÓVIL: El teléfono móvil se conecta al puerto serial de WI-P.O.S y es quien dirige la transacción, ya que él es quien envía la instrucción correspondiente a la operación desplegada en
30
3.2.2 pantalla. Por ejemplo, en el momento que se solicite digitar la clave, el teléfono mostrará una pantalla para que el usuario la digite, al mismo tiempo enviará la instrucción a WI-P.O.S para que se prepare a recibir la correspondiente información del teclado y luego manipularla. Es decir que para cada una de las fases de la transacción, el teléfono móvil muestra en la pantalla lo que el usuario debe realizar y a la vez enviará las instrucciones a WI-P.O.S para que éste entre a la rutina correspondiente.
INGRESO DE LLAVES: Para el ingreso de las llaves Maestra y de Transporte se debe conectar el WI-P.O.S con el puerto serial de un computador y haciendo uso de la aplicación desarrollada en Visual Basic almacenar estas en la memoria EEPROM del microcontrolador, debidamente cifradas.
Componentes del dispositivo – – – – – – – – – – – – – – – – Microcontrolador PIC18F452 Integrado MAX 232 Integrado 74C422N (Manejador del teclado) Integrado 74LS125 Integrado LM555 Cristal de 4.9152 MHZ FPGA Altera ACEX1K50TI144-2 Memoria Serial Altera EPC2LC20 Oscilador con cristal de 1MHz Regulador LM1117DT-2.5 Regulador LM1117DT-3.3 Resistores Condensadores 2 leds Interruptor Lector de Tarjetas de banda magnética Omron V3A
31
– Teclado de 4filas x 3columnas 3.2.3. Módulos del dispositivo:
El dispositivo cuenta con tres módulos que se listan a continuación, luego serán explicados. – – – Modulo de manejo de periféricos Modulo de cifrado en DES Desarrollo de Software. Aplicaciones en J2ME y Visual Basic. Modulo de manejo de periféricos El módulo de manejo de periféricos consiste de un microcontrolador PIC 18F452 que se encarga de manejar la comunicación, con el teléfono móvil, con la impresora, con el módulo de cifrado y además recoge la información del lector de banda magnética y del teclado. Este se encarga de almacenar toda la información, y de armar las tramas correspondientes a la transacción. Módulo de cifrado en DES Este es un cifrador/descifrador en hardware (implementado en una FPGA) que permite manejar información de una manera confiable. Este trabaja con el estándar de cifrado DES (ver Anexo Marco Teórico) que utiliza una llave de 64 bits. Este realiza el cifrado/descifrado en bloques de 64 bits. La información se recibe y se envía serialmente usando una interfase de puerto serial y trabajando como esclavo. Es decir que sólo envía la información cuando le es solicitada por otro. Tiene un bit de selección de funcionamiento (cifrar/descifrar). Desarrollo de Software El teléfono móvil es la interfaz visual con el usuario para la realización de la transacción, por tanto éste establece una comunicación con WI-P.O.S indicándole los pasos a seguir, además informa al usuario las acciones que debe realizar. Por esto fue necesario desarrollar tres aplicaciones: la primera para la petición de los parámetros
32
33 iniciales, la segunda para la realización de un pago y la tercera para reversar una transacción. Este es un programa (Software) que denominamos driver por que es el que maneja el dispositivo; éste programa incluye todos los pasos y pantallas necesarias para la transacción. Este Software debe ser instalado en el teléfono móvil antes de usar WI-P.O.S, por tanto es necesario que el teléfono móvil a usar pueda ser programado usando J2ME. Además se desarrolló una aplicación en Visual Basic que permite introducir las llaves y el número de terminal, para que sean almacenadas en WI-P.O.S.
3.3 PROTOCOLO DE MENSAJES PARA REALIZACIÓN DE LA TRANSACCIÓN.
El desarrollo realizado usa como puente un servidor para la realización de la transacción, este tiene una aplicación implementada por ASIC, y se encarga de recibir ciertos datos del P.O.S y de construir las tramas correspondientes al protocolo de Base 24 (ver Anexo Marco Teórico). Esto permite que el procesamiento de datos se reduzca en el punto de ventas ya que el protocolo de Base 24 es bastante robusto y maneja tramas grandes y complejas. De manera que el equipo desarrollado (WI- P.O.S) tiene comunicación directa con el servidor AS400 y este último es quien se encarga de conectarse con el Tandem de VISA.
A continuación se mencionarán los mensajes que se deben construir en el equipo, para luego enviarlos al servidor AS400 y así poder llevar a buen término la transacción. Todos estos mensajes se transmiten debidamente cifrados con la llave de transporte. Los primeros dos bytes de todos los mensajes se denominan tipo de mensaje y son estos los que identifican el mensaje que se envía o que se recibe. A continuación se presentarán los mensajes, con una breve descripción y los campos que los componen.
3.3.1. Solicitud de parámetros iniciales:
Esta trama se debe enviar al servidor cada vez que se prende el equipo, con el fin de obtener del servidor una serie de parámetros que dependen del tipo de terminal, del propietario del equipo y de la zona de uso.
La trama tiene los siguientes campos: i)
ii) Tipo de mensaje: Dos bytes que identifican el mensaje, estos son de tipo char.
Terminal: Es un código que identifica cada uno de los equipos (datáfonos), éste consiste de 8 bytes de tipo char.
3.3.2. Respuesta de parámetros iniciales:
ésta respuesta debe ser enviada por el servidor inmediatamente después de recibir la trama de petición de parámetros iniciales. Consiste de los siguientes campos. i)
ii)
iii)
iv) Tipo de mensaje: 2 bytes de tipo char
Terminal: Debe transmitir el número de terminal del equipo que envió la solicitud, de ésta manera se puede comprobar en el P.O.S si el mensaje recibido es correcto.
Porcentaje de IVA: Esta compuesto por dos datos de tipo numérico, cada uno de 1 byte.
Solicitud Propina: es un carácter que indica si se debe o no pedir la propina en el equipo.
34
v)
vi)
vii) Numero de dígitos a ingresar: Este campo compuesto por dos datos numéricos indica la cantidad de dígitos que se deben ingresar al pedir el PIN.
Base devolución de IVA: es un carácter que indica si debe o no viajar la base de devolución de IVA en el momento de hacer la petición de transacción de pago.
Nombre del Emisor: Es un campo de 10 caracteres que contiene el nombre de la entidad que presta el servicio.(ej: Visa)
3.3.3. Solicitud de parámetros de tarjeta:
Esta trama se transmite al servidor después de que se ha deslizado correctamente la tarjeta en el lector. Se hace con el fin de recibir una serie de parámetros que dependen de la tarjeta deslizada. Sus campos son:
i) Tipo de Mensaje.
ii) Número de terminal.
iii) Número de la tarjeta: Este campo incluye los datos obtenidos de la Pista 2 de la banda magnética de la tarjeta (Ver Anexo Marco Teórico). Son 19 bytes de tipo char.
3.3.4. Respuesta de parámetros de tarjeta:
Es la trama que transmite el servidor como respuesta a la petición de parámetros de tarjeta y que incluye los siguientes campos:
i) Tipo de Mensaje.
35
36 ii) Número de Terminal iii) Número de la tarjeta: Se transmite de vuelta el número de la tarjeta para corroborar que los parámetros si correspondan a esa tarjeta. iv) Validación fecha de vencimiento1: Es un carácter (de 1 byte) que indica si se debe o no solicitar al usuario que ingrese la fecha de vencimiento de la tarjeta, para corroborar con lo leído en la PISTA2. v) PIN para tarjetas de crédito: Es un carácter que indica si se debe o no solicitar PIN con esa tarjeta de crédito. vi) Solicitud de tipo de cuenta: Es un carácter que indica si se debe solicitar al usuario el tipo de cuenta. vii) Validación fecha de vencimiento: Es un carácter que indica si se debe validar localmente o no la fecha de vencimiento obtenida de la PISTA2 con la fecha del sistema. viii) Impresión Recibo: Este carácter indica si se debe o no imprimir el recibo de Credibanco. ix) Módulo 10: Un carácter que indica si se le debe hacer la validación de módulo 10 al número de cuenta de la tarjeta (ver Anexo Marco Teórico) x) Solicitud de cuotas: Es un carácter que indica si se debe o no solicitar un número de cuotas xi) Solicitud de PIN: Este carácter indica si se debe pedir PIN para tarjetas débito.
3.3.5 Solicitud de transacción de pago: Es la trama que se debe construir después de haber solicitado todos los datos necesarios. Contiene los siguientes campos:
i) Tipo de Mensaje
ii) Número de terminal
iii) Consecutivo: Este es un número compuesto por seis datos de tipo numérico (cada uno de un Byte) que identifica cada transacción. Este número se debe aumentar cada vez que se realiza una transacción. Este dato se encuentra almacenado en memoria EEPROM.
iv) PISTAII: Se debe enviar toda la información del PISTAII de la tarjeta deslizada. Tiene una longitud de 37 caracteres (cada uno representado por un Byte)
v) PISTAI: Si la tarjeta tiene información en el PISTAI este se debe enviar, tiene una longitud de 76 caracteres.
vi) PINBLOCK: El PINBLOCK es una trama de 16 caracteres que se construye haciendo operaciones lógicas entre el PIN y el PAN (Número de cuenta). Este se introduce en la trama debidamente cifrado con la llave de cifrado de PIN. Este espacio de la trama se llena dependiendo si se debe o no solicitar el PIN; si no, se deja vacío.
vii) Tipo de cuenta: Un dato numérico (representado en un Byte) indica el tipo de cuenta del usuario. Este campo se llena o no dependiendo de los parámetros de la tarjeta.
37
38 viii) Cuotas: 2 bytes indican el número de cuotas. Viaja o no dependiendo de los parámetros. ix) Valor de la transacción: Es el valor por el cual se realiza la transacción, se representa en doce datos de tipo numérico en donde los últimos dos se usan para centavos. x) IVA: Es la parte del valor de la transacción que corresponde al IVA se representa con doce datos numéricos. xi) Base de devolución de IVA: Se representa con doce datos numéricos, viaja o no dependiendo de los parámetros iniciales. 3.3.6. Respuesta de transacción de pago Tiene los siguientes campos i) Tipo de Mensaje ii) Número de terminal. iii) Consecutivo: Se envía para saber si la respuesta si corresponde a la debida transacción. iv) Código de respuesta: Son dos caracteres (cada uno representado en 1 Byte) que indican si la transacción fue exitosa o si existe algún error. v) Descripción de respuesta: 20 caracteres que describen la aprobación o el error de la transacción.
39 vi) Código de autorización: Es un código de 6 datos de tipo numérico, diferentes de cero cuando la transacción es aprobada.
3.3.7. Petición de transacción de reverso:
Es una trama que se construye en caso de necesitar un reverso. El reverso anula o revierte la transacción indicada por el consecutivo enviado. Los campos son:
i) Tipo de Mensaje. ii) Número de terminal. iii) Consecutivo
3.3.8. Respuesta de transacción de reverso:
Tiene los mismos campos que la respuesta de transacción de pago pero se identifica con otro tipo de mensaje.
3.3.9. Solicitud de llave de cifrado de PIN:
Con esta trama se hace una solicitud al servidor de una nueva llave para el cifrado de PIN, contiene los siguientes campos: i) Tipo de Mensaje. ii) Número de terminal.
3.3.10. Respuesta de llave de cifrado de PIN:
Contiene los siguientes campos
i) Tipo de Mensaje. ii) Número de terminal. iii) Llave de cifrado de PIN: Contiene 16 caracteres que representan la llave de cifrado de PIN
3.4. MANEJO DE LLAVES DE CIFRADO
3.4.1. Manejo de Llave Maestra.
La llave maestra es una llave de cifrado usada para mantener la información de las llaves de transporte y de PIN almacenadas seguramente en el equipo.
El proceso para almacenar una llave maestra en un POS es el siguiente: primero se acuerda cierta cantidad de subllaves que se van a generar, la llave maestra se genera al hacer una operación lógica XOR entre éstas. La finalidad de generar cierta cantidad de subllaves es la de entregarle una a diferentes personas, las cuales ingresarán la información al POS en diferente tiempo, de esta manera nadie conocerá la llave maestra sino solamente un fragmento.
La forma en que se introducen las llaves maestras en un POS es mediante una aplicación que se ejecuta desde un Computador al cual se conecta el POS, ésta conexión depende de las características de cada POS.
En un POS, siempre se deben almacenar máximo 3 llaves maestras, la última llave maestra usada antes de la actualizada, la llave maestra actual y la llave resultante de la XOR de las partes ingresadas. En el momento que se desean actualizar las llaves maestras, éstas sufren un corrimiento, de tal manera que la llave resultante de la XOR pasa a ser la nueva llave actual y la llave actual pasa a ser la última llave.
En caso que se desee volver a usar la última llave como llave maestra actual, se tiene
40
la opción de hacer que la última llave ocupe de nuevo la actual, quedando vacío el espacio que ocupaba antes. Este proceso se hace en caso que se presenten inconvenientes con la llave maestra actual. Para una mejor idea del proceso se puede ver más detalladamente en la Figura 3. FIGURA 3, Proceso de Carga de Llaves Maestras
3.4.2. Llave de Transporte
Es una llave de cifrado que sirve para enviar y recibir información entre WI-P.O.S. y el servidor, previamente esta llave ha sido concretada entre las dos partes e ingresada en los 2 sistemas. Por seguridad este tipo de llave no permite que tenga un intercambio dinámico.
Por seguridad ésta llave es cifrada dentro de WI-P.O.S por medio de la llave maestra y luego almacenada. Es necesario que sea guardada en una memoria no volátil para evitar que se borre cada vez que se apague el equipo.
Para el ingreso de la llave de transporte se debe hacer mediante una interfaz en un
41
42 computador.
3.4.3. Llave de cifrado de PIN
La llave de cifrado de PIN se usa exclusivamente para cifrar el PINBLOCK, esta es una llave que se genera aleatoriamente en la tarjeta criptográfica del servidor y se debe pedir cada vez que se hace una transacción, ésta se almacena en la memoria RAM. La llave de cifrado de PIN se solicita usando la trama denominada petición de llave de cifrado de PIN. (Ver sección 3.3.9)
43 4. DESARROLLO El diseño y elaboración del dispositivo denominado WI-P.O.S contó con desarrollos en Hardware, Software y Firmware. Estos fueron divididos en tres áreas principales que serán explicadas a continuación. 1) Manejo de periféricos y procesamiento de datos en el dispositivo, 2) Cifrado de datos y 3) Aplicaciones en J2ME y Visual Basic. 4.1 MANEJO DE PERIFÉRICOS Y PROCESAMIENTO DE DATOS. Como ya se ilustró en la sección 3.2 los periféricos que maneja el dispositivo son: un lector de banda magnética, un teclado de 4 filas x 3 columnas, una impresora y un teléfono móvil. Además se puede tomar el bloque de cifrado como un periférico más y la comunicación con éste se explica más adelante. Para manejar los periféricos, como unidad de procesamiento central se eligió un microcontrolador PIC 18F452. Este es un microcontrolador de 8 bits , cuenta con una memoria FLASH de 32Kbytes, una memoria RAM de 1536 bytes y una EEPROM para datos de 256 bytes, cuenta con un USART (Addressable Universal Synchronous Asynchronous Receiver Transmitter) y un módulo MSSP (Master Synchronous Serial Port) éstos últimos muy útiles para el desarrollo. Además tiene 5 puertos de entrada/salida, 1puerto de 7 pines, 3 de 8 pines y uno de 3 pines. En la rutina principal del microcontrolador, este se encuentra esperando datos a través de la USART, cada vez que ingresa un dato este lo lee y decide a que subrutina debe entrar, ejecuta las acciones correspondientes y vuelve a su estado inicial. Para que el
44 dispositivo desarrollado contara con versatilidad y posibilidades de expansión, se fijo una serie de rutinas que se realizan dependiendo de la instrucción recibida por el puerto. El dispositivo cuenta con un interruptor de reset para inicializar el equipo en caso de fallas, el circuito de reset se implemento haciendo uso de un integrado LM555. 4.1.1 Comunicación con el teléfono móvil. La comunicación con el teléfono móvil se hace a través de la USART del microcontrolador. La USART (Addressable Universal Synchronous Asynchronous Receiver Transmitter) es uno de los 2 módulos de transmisión serial con que cuenta el microcontrolador. Este puede funcionar de manera sincrónica o asincrónica. Para el desarrollo del proyecto se decidió trabajarlo de manera asíncrona ya que es así que funciona el teléfono móvil, el cual maneja el protocolo EIA/TIA 232. En modo asíncrono el puerto usa un formato de datos estándar de no retorno a cero. La transmisión se hace de a 8 bits con un bit de inicio. Para la comunicación se eligió una tasa de transmisión de 9600bps. El generador de rata de transmisión divide el reloj de funcionamiento del microcontrolador en un número entero, para el caso específico en que se trabajó al microcontrolador, es decir, en modo de velocidad baja, se usa la siguiente fórmula para la rata de transmisión Tasa de transmisión = Fosc/(64(n+1)) En donde n es un número entero que se debe poner en el registro SPBRG (registro de generación de tasa de transmisión de la USART) del microcontrolador al inicializar el puerto y Fosc la frecuencia del reloj con que trabaja el microcontrolador. Como n es un número entero, si la frecuencia del reloj no es un múltiplo entero de 9600 se va a generar un porcentaje de error en la transmisión, es por esto que se eligió un reloj de 4.9152Mhz para el microcontrolador, si se remplaza en la fórmula se encontrará un
45 valor de n igual a 7 y un porcentaje de error debido a tasa de transmisión de 0%.
El puerto serial (USART) del microcontrolador se usa para comunicarse con el teléfono, con el computador y con la impresora. Estos tres usan el protocolo EIA/TIA 232 cuyos voltajes exceden el límite de trabajo en el circuito ya que éste opera con una fuente sencilla de 3.3V, que lo hace compatible con la batería del teléfono en caso de querer conectarlo a ésta. Por ésta razón, se hace necesario el uso de un integrado MAX 232 que convierte los voltajes del protocolo EIA/TIA 232 a voltajes compatibles con TTL y CMOS. Es de notar que se cuenta con un sólo puerto (USART) y se necesita establecer comunicación con tres periféricos diferentes. Para solucionar este inconveniente se tuvieron en cuenta los siguientes aspectos: el microcontrolador no se comunica con dos periféricos a la vez, además se conecta con el computador para cargar la llaves y el número de terminal, momento en el cual no debe estar conectado al teléfono móvil, y por último, el integrado MAX 232 cuenta con dos entradas y dos salidas. Como resultado se decidió usar un buffer tristate cuyos output enable se manejan desde el microcontrolador con dos salidas digitales. De modo que para el teléfono y el computador se usa la misma línea ya que estos no se conectan simultáneamente. La salida Tx del puerto de USART se conecta simultáneamente a la entrada de dos buffers tri state y las salidas de cada uno de éstos se conectan a cada una de las entradas de la MAX 232 (ver figura 4). Así, si se quiere transmitir al teléfono o al computador se habilitará dicho buffer y si se quiere enviar datos a la impresora se habilitará el otro buffer.
46 Figura 4. Conexión del puerto serial USART. Para evitar los errores en la comunicación con el teléfono se estableció un protocolo en el que éste envía los datos al microcontrolador y el último responde un mensaje de recibido y luego ingresa a la rutina deseada. De ésta manera, desde el teléfono siempre es posible saber si la información se recibió correctamente. Para cada una de las rutinas que puede realizar el microcontrolador (Ver sección 4.1.5) existe un código específico de 8 bits de manera que éste puede ser controlado totalmente desde la aplicación desarrollada en J2ME residente en el teléfono móvil. 4.1.2 Comunicación con la impresora El envío de datos a la impresora se hace de manera serial por el puerto de USART usando la conexión explicada en la sección anterior. Esta es una comunicación en un sólo sentido usando el protocolo RS_232 de la impresora, que cuenta con ciertos mensajes de funcionamiento (imprimir, pasar línea) y recibe los datos a imprimir en un formato ASCII. 4.1.3 Lector de banda magnética Para el desarrollo del dispositivo se usó un lector de tarjetas de banda magnética
OMRON V3A, que es un lector de tecnología CMOS de bajo consumo con salidas compatibles con TTL. Es un lector de 9 pines que lee la PISTA I y la PISTA II (ver Anexo Marco Teórico) de las tarjetas de banda magnética. Por cada pista tiene 3 pines, uno llamado card loaded que se pone en un cero lógico cuando se pasa una tarjeta, el segundo es un pin de envío de datos vía serial y el tercero es el reloj de los datos. Aunque es posible realizar transacciones teniendo sólo la PISTA II de la tarjeta, se implementó la lectura de la PISTA I para que el diseño se adapte a futuros requerimientos.
Para recibir la información proveniente del lector se usaron cuatro entradas digitales (2 entradas para datos y dos de reloj) del microcontrolador. Los datos y el reloj de la tarjeta vienen negados, es decir se leen cuando el reloj esté en 0; los datos de la PISTA II vienen en bloques de a 5 bits, 4 de datos y uno de paridad (ver Anexo Marco Teórico). Para el caso de la PISTA I vienen en bloques de 7 bits (un dato de paridad). El equipo tiene una rutina para leer la tarjeta, al entrar a esta rutina se le indica cual pista se quiere leer (la 1, la 2 o ambas). De este modo el microcontrolador pasa a la rutina indicada. Se tienen tres rutinas, una para leer la PISTA I, otra para leer la PISTA II y una última que lee las dos pistas a la vez. A continuación se explican brevemente estas rutinas. Leer PISTA II Al entrar en la rutina de Leer PISTA II el microcontrolador debe encontrar dentro de los datos provenientes de la tarjeta una B en hexadecimal que indica el comienzo de la trama. Para lograr esto, se verifica el pin del reloj hasta que se encuentre en 0, en ese momento se guarda el bit que se encuentra en la entrada de datos de la tarjeta en el bit menos significativo de un registro que previamente ha sido iniciado en 00h, luego vuelve a mirar el pin de reloj hasta que entre otro dato. Cuando el reloj se pone de nuevo en cero (es decir, cuando hay otro dato disponible), se hace un corrimiento hacia la izquierda en el registro y se pone de nuevo el dato que se encuentre en la
47
entrada de datos de la PISTAII en el menos significativo. Después de esto se compara el registro con el dato A0h que es el dato Bh más la paridad negados, lo que indica el comienzo de la trama de la pista.
Después de haber encontrado el comienzo de la trama se leen los datos bit por bit y se van almacenando en registros. Después de leer los cuatro bits de cada dato se revisa la paridad, en caso de ser errónea (hay un error en los datos), se envía un mensaje de error y se sale de la rutina, en caso de estar bien se compara el dato con un 0Fh que indica el final de la trama, si se leyó bien se envía por USART (hacia el teléfono) un indicador de que la tarjeta se ha leído satisfactoriamente. Leer PISTA I A diferencia de la lectura de la PISTA II, la información se encuentra agrupada por bloques de 7 bits, donde el último simboliza la paridad. Para iniciar el proceso, el equipo Motorola debe enviar la instrucción para la lectura de la PISTA I. Para su lectura, la unidad de procesamiento debe encontrar un 2 en hexadecimal en el primer grupo de 7 bits y luego un 5 en hexadecimal en el siguiente grupo de 7 bits. Lo que se hace es un proceso similar a la lectura de la PISTA II, donde se hace un corrimiento y una comparación de los datos provenientes del lector de banda magnética, teniendo en cuenta el reloj para sincronizar la información. Cada vez que hay un cambio de reloj a cero lógico se toma la información de la PISTA I y se almacena, al mismo tiempo se va a haciendo un corrimiento del dato anterior. Con el nuevo dato en memoria se procede a realizar una comparación con 2 en hexadecimal; una vez se encuentra, se realiza el mismo proceso pero con el 5 en hexadecimal. Finalmente, al encontrarse los bits de inicio, se comienza a recibir la información por bloques de 7 bits, realizando la paridad con cada bloque.
Este proceso se realiza hasta que se encuentre un 0F en la información entrante, por lo que se debe estar comparando constantemente para saber si la información ya se
48
terminó de enviar.
Al finalizar el proceso, se envía una señal al teléfono para que continúe con la siguiente rutina. Leer Ambas Pistas Para leer ambas Pistas se creó una instrucción híbrida entre la lectura de PISTA I y PISTA II. El proceso consiste en realizar el proceso de la lectura de PISTA I pero haciendo llamados al proceso de lectura de PISTA II. Se escogió como proceso principal la lectura de PISTA I debido a que ésta tiene un reloj mas rápido que la PISTA II, por lo tanto se asegura que no se pierda información de la PISTA II.
Al hacerse el proceso de llamado de la instrucción de lectura de PISTA II se controlan los estados con banderas que indican en que paso se encontraba, de ésta forma se sabe si se encuentra esperando por la B en hexadecimal o si se encuentra esperando información.
4.1.4 Teclado para ingreso de datos.
El dispositivo cuenta con un teclado numérico de 4 filas x 3 columnas que además tiene un botón de aceptado marcado A y uno para borrar marcado B. El teclado funciona como un arreglo de interruptores que ponen en corto ciertos puntos de una matriz, por tanto se uso un manejador de teclado (integrado 74HC922) cuyas ocho entradas se conectaron a las salidas del teclado y cuyas cuatro salidas se conectaron a cuatro entradas digitales del microcontrolador. Además se usó una salida de Data Available (Dato disponible) del 74HC922 que se conectó a otra entrada digital del microcontrolador y se usó una salida digital de éste último para conectarla a la entrada de Output Enable (habilitar salida) del manejador ya que éste funciona de
49
modo tristate. Figura 5. Conexión del teclado.
En las rutinas de recepción de datos a través del teclado se espera a que haya un 0 en Data Available, en ese momento se habilita la entrada de datos (usando el pin de output enable) se leen estos datos, se almacenan en un registro y se envían por USART (al teléfono). En caso de borrar se vacía el registro anterior y se envía un 0Bh al teléfono para que éste sepa que debe borrar. Los datos son enviados al teléfono porque se deben mostrar en pantalla para que el usuario verifique los datos que esta introduciendo. En el caso de la clave se envían asteriscos.
4.1.5 Comunicación con el modulo de cifrado.
Para comunicarse con el modulo de cifrado se utilizó el puerto serial MSSP (Master Synchronous Serial Port, Puerto Maestro Serial Sincrónico) del microcontrolador.
50
51 Este puerto usa tres pines SCK (Serial Clock, Reloj Serial) SDI (Serial Data In, Entrada de datos serial) y SDO (Serial data Out, Salida de datos serial). El puerto se programó en modo SPI (Serial Peripheral Interface), de este modo se transmite en bloques de 8 bits sin bit de inicio ni de parada. La tasa de transmisión es de ¼ la frecuencia del reloj de trabajo del microcontrolador. Para el caso particular del dispositivo desarrollado es de 1,229MHZ. Además se trabajó en modo maestro, es decir el microcontrolador es quien proporciona el reloj. Las señales de entrada son muestreadas al final del tiempo de la información, la transmisión se hace con borde de subida del reloj como se muestra en la figura 6.
Figura 6 Transmisión de un 85h seguido de un ABh
Las señales con las que se controla el modulo de cifrado son: CLK (reloj), SERIAL CLOCK (reloj serial), D (datos), OUT DATA (salida de datos), NRESET, TAKE_D (tomar datos), DONE (realizado), ENABLE_D (datos habilitados), CRYPT (cifrar) y START. (El funcionamiento detallado del módulo de cifrado se explica en la sección 4.2). Las señales SERIAL CLOCK, OUTDATA y D corresponden en el microcontrolador a los pines del SPI. El resto de señales se implementaron en salidas y entradas digitales y se manejan de acuerdo a lo requerido. (Ver figura 7)(Ver sección 4.2).
52 Figura 7 Conexión con el módulo de cifrado. Se implementó una rutina en el microcontrolador para cifrar / descifrar bloques de 64 bits. En el momento de enviar un bloque de 64 bits a cifrar / descifrar el proceso que se sigue en el microcontrolador es el siguiente: 1. Se verifica con que llave se desea cifrar. (Transporte, Master, PIN). Esto se hace verificando un indicador de llave que se debe enviar como parámetro de esta rutina. 2. Se verifica si la llave esta cargada en el módulo de cifrado. El cifrador tiene la capacidad de almacenar la llave por tanto si se requiere cifrar dos bloques con la misma llave no es necesario cargar esta de nuevo. Al cargar una llave se altera una bandera dentro del microcontrolador la cual es verificada cada vez que se va a enviar a cifrar un bloque de datos. 3. En caso de no estar cargada se debe cargar la llave de datos. Se envía serialmente la llave de 64bits con las señales correspondientes (Ver sección de 4.2), éstas llaves se deben haber almacenado previamente en memoria
53 4. Se envía el bloque de datos de 64 bits. Se hace de manera serial por el puerto SPI.
5. Se transmite una señal de inicio y la señal de cifrado / descifrado CRYPT. (Ver sección 2.2)
6. Se verifica si se terminó el proceso de cifrado.
7. Se envía el reloj para recibir los datos de manera serial y se almacenan.
En el desarrollo se usó el modo de cifrado / descifrado CBC (ver Anexo Marco Teórico) en el cual los datos a cifrar se envían en bloques de 64 bits, pero el segundo que se transmite es la XOR del primer bloque cifrado, con el segundo bloque a cifrar y la XOR de estos con un 0C en hexadecimal, así consecutivamente. (Ver figura 8). Además tiene un vector de inicio, de manera que el primer bloque a cifrar hace XOR con este. Figura 8 Cifrado usando modo CBC (Cipher Block Chaining) B1, B2, B3 son bloques de 64 bits de una misma trama, E1, E2, E3 el resultado de cifrar
54 Figura 9 Descifrado usando modo CBC (Cipher Block Chaining) De modo que este proceso de realizar la operación lógica XOR también se lleva a cabo en el microcontrolador, cada vez que se envía un bloque que no es el primero a cifrar se hace la XOR con el resultado de cifrar el bloque anterior. En el momento de descifrar se hace un procedimiento algo parecido, la diferencia consiste en que se hace la XOR del último bloque descifrado con el anterior aún cifrado. 4.1.6 Rutinas del microcontrolador. Para hacer del dispositivo desarrollado un equipo versátil, se desarrollaron una serie de rutinas que pueden ser llamadas desde el teléfono móvil (o desde un computador en caso de ser necesario). Cada una de estas rutinas tiene un código de 8bits con la que se identifica, para llamar una rutina del microcontrolador se sigue el proceso mostrado en la figura 10. Cabe anotar que el proceso o rutina determinada puede
requerir de transmisión de información hacia el teléfono. Toda comunicación entre el teléfono (o computador) y el microcontrolador se hace a través del puerto de USART. (Ver sección 4.1.1) Fig. 10 Proceso para llamar las rutinas del microcontrolador.
A continuación se explicará el funcionamiento de cada rutina:
1. Leer tarjeta: En esta rutina el microcontrolador espera recibir los datos que le indican que pista leer, luego habilita los pines del lector de banda magnética, lee los datos (ver sección 4.1.3), en caso de presentarse algún inconveniente (la paridad de algún dato esta mal) devuelve un mensaje de error, de lo contrario devuelve un mensaje de aceptado y guarda los datos de la tarjeta de
55
56 banda magnética en memoria RAM. 2. Leer clave: Al recibir la instrucción de leer clave el microcontrolador espera dos parámetros que deben ser enviados desde el teléfono móvil, el primero es el numero de dígitos de la clave y el segundo el indicador de la llave con que se cifrara el PINBLOCK. Estos parámetros son necesarios porque la longitud del PIN puede variar según el país o la región o con el paso del tiempo se pueden requerir un mayor número de dígitos. Después de haber recibido estos dos parámetros el microcontrolador habilita los pines del teclado, cada vez que el usuario oprime una tecla se envía un mensaje de asterisco hacia el teléfono por el puerto para que éste último ponga asteriscos en la pantalla. Después de haber recibido la cantidad de dígitos necesaria por parte del usuario (dependiendo del parámetro ingresado desde el teléfono) se procede a armar una trama conocida como PINBLOCK, esta es una trama que se construye haciendo operaciones lógicas con el PIN del usuario y el número de la cuenta, por esto es necesario que para correr esta rutina ya se haya deslizado la tarjeta. El resultado (una trama de 64 bits) se cifra usando la llave cuyo indicador que se ingresó como parámetro y se almacena en memoria RAM. El PINBLOCK se cifra inmediatamente porque es un dato que requiere de total confidencialidad, para evitar problemas de seguridad se almacena debidamente cifrado. 3. Obtener datos: Esta es una rutina en la que se almacenan datos provenientes del teclado. Sirve para almacenar datos tales como valor, cuotas y propina. El microcontrolador cuenta con 10 posiciones de memoria para almacenar datos, cada una de 10 bytes. Al entrar en esta rutina el microcontrolador espera dos parámetros, el primero es el número máximo de dígitos del dato a recibir y el segundo el índice en donde se guardará el dato (éste último se encuentra entre 1 y 10). Luego se habilita el teclado, se leen los datos, se envían al teléfono cada vez que se oprima una tecla para que puedan ser mostrados en pantalla. Este proceso se realiza hasta que se haya ingresado el número máximo de
57 dígitos o el usuario presione la tecla A del teclado. Los datos son almacenados en memoria RAM y la posición donde se almacenan depende del índice introducido como parámetro. 4. Pedir tarjeta: Esta rutina envía por USART los datos de la PISTA 2 de la tarjeta que debe haber sido deslizada previamente. 5. Pedir datos: Esta rutina recibe como parámetro el índice de los datos que se requiere (entre 1 y 10) y devuelve los datos que fueron almacenados haciendo uso de la rutina obtener datos. 6. Cifrar: Esta rutina espera dos parámetros, primero espera el bloque de 64 bits a cifrar y segundo el indicador de la llave a utilizar. Luego cifra el bloque de 64 bits haciendo uso del modulo de cifrado y almacena los datos en memoria RAM. Cabe anotar que como las llaves se almacenan debidamente cifradas (usando la llave maestra) en el proceso de cifrado se debe descifrar primero la llave a usar para luego enviarla al módulo de cifrado. El cifrado/descifrado de las llaves se hace de la misma manera que con cualquier bloque de 64bits. 7. Descifrar: Esta rutina funciona de manera similar a la de cifrar, la diferencia consiste en que se elige otro modo de operación del módulo de cifrado haciendo uso del pin CRYPT (Ver Sección 2.2). 8. Reset: Esta instrucción inicializa el microcontrolador. 9. Recibir Terminal: Esta rutina se debe correr desde un computador personal y no desde el teléfono. El número de terminal es un código que identifica cada equipo y que es necesario para llevar a cabo una transacción. En esta rutina se recibe el número de terminal desde el computador (8 bytes) y se almacena en la memoria EEPROM del microcontrolador. Este es un código que se utiliza en todas las transacciones y por eso es necesario cargarlo en una memoria no
58 volátil. 10. Recibir llave de transporte: Esta rutina se corre desde un computador y no desde el teléfono móvil. En esta rutina se recibe de manera serial la llave de transporte, se cifra usando la llave maestra y se almacena en memoria EEPROM del microcontrolador, esta llave se usa para el cifrado de las tramas que se envían al servidor. 11. Recibir llave maestra: La recepción y almacenamiento de la llave maestra requiere de varias rutinas, este proceso se explica detalladamente en la sección 4.4. 12. Parámetros iniciales: Para correr esta rutina de manera correcta se debe haber cargado el número de terminal, la llave maestra y la llave de transporte. Al entrar en esta rutina el microcontrolador construye la trama de petición de parámetros iniciales (ver sección 3.3.1), rellena con el carácter F los bytes restantes necesarios para tener una trama que sea múltiplo entero de 64 bits (para que pueda ser cifrada). Luego cifra esta trama haciendo uso de la llave de transporte usando el modo de cifrado CBC y la envía al teléfono, después queda en estado de espera de los parámetros iniciales. Al recibir la trama de parámetros iniciales la descifra usando la llave de transporte, verifica que no haya errores en el mensaje, esto lo hace verificando ciertos campos del mensaje recibido (tipo de mensaje, terminal) en caso de no haber errores almacena los parámetros en memoria RAM y envía un mensaje de aceptado. En caso de errores se envía un mensaje de error. Esta rutina se debe realizar cada vez que se enciende el equipo porque los parámetros iniciales son indispensables para cualquier transacción. 13. Pedir Parámetros iniciales: Es una serie de rutinas que envían al teléfono cualquiera de los parámetros iniciales. Existe una rutina para cada uno de los parámetros, al entrar en ésta el microcontrolador envía la información
59 almacenada en la posición de memoria de ese parámetro. (Para ver cuales son los parámetros iniciales ver la sección 3.3.2) 14. Parámetros de tarjeta: Para correr esta rutina se deben haber cargado previamente los parámetros iniciales y además se debe haber deslizado la tarjeta de banda magnética. En este proceso el microcontrolador construye la trama denominada petición de parámetros de tarjeta, rellena con el carácter F hasta tener una trama múltiplo entero de 64 bits, la cifra usando el modo CBC y la envía al teléfono, luego queda en estado de espera de respuesta. Al recibir la trama de respuesta de parámetros iniciales se descifra, verifica que este correcto el tipo de mensaje y almacena los parámetros de la tarjeta en ciertas posiciones de memoria RAM establecidas para esto. 15. Pedir parámetros de tarjeta: Similar a la petición de parámetros iniciales se implementó una serie de rutinas para pedir cada uno de los parámetros de la tarjeta, en las que el microcontrolador envía a través del puerto la información almacenada en las posiciones de memoria destinadas para los parámetros de la tarjeta. 16. Petición de llave de cifrado de PIN: Esta rutina se encarga de construir la trama de petición de llave de cifrado PIN; la cifra usando la llave de transporte y la envía, luego queda en estado de espera. Cuando recibe la respuesta descifra la trama, verifica el tipo de mensaje y el terminal, cifra la llave de cifrado de pin usando la llave maestra y la almacena en memoria RAM. Como la llave de cifrado de PIN se pide durante cada transacción no es necesario almacenarla en EEPROM. 17. Solicitud de transacción de pago: Para ejecutar correctamente esta rutina se deben haber solicitado parámetros iniciales, parámetros de tarjeta y todos los campos adicionales dependiendo de la tarjeta (valor, cuotas, PIN, tipo de cuenta entre otros, ver sección 3.3). Al tener estos datos, el microcontrolador
60 construye la trama de petición de transacción de pago y la envía por el puerto serial, luego queda en estado de espera. Al recibir la respuesta la descifra, revisa errores (en caso de error transmite un mensaje específico); de estar correcto, almacena los datos de respuesta de transacción de pago en los campos de memoria RAM destinados para ello. 18. Petición de respuesta de transacción: Se implementó una serie de rutinas para pedir cada uno de los campos de la respuesta de transacción de pago, en las que el microcontrolador envía a través del puerto la información almacenada en las posiciones de memoria destinadas para los parámetros de la tarjeta. 19. Transacción de reverso: En esta rutina se construye la trama de transacción de reverso, se cifra y se envía, luego se espera recibir la respuesta, se verifica que no tenga errores y almacenan los datos en memoria. 20. Inicializar consecutivo: El consecutivo es un número que caracteriza cada una de las transacciones. Esa rutina pone en cero los seis registros en EEPROM correspondientes al consecutivo. 21. Aumentar consecutivo: Esta rutina le suma 1 a los registros del consecutivo, teniendo en cuenta que los datos son de tipo numérico, es decir van entre 0 y 9 (ver sección 3.3.5). 22. Comparar fecha de vencimiento: Esta rutina compara una fecha ingresada desde el teléfono con la fecha de vencimiento que se encuentra en la PISTA II de la tarjeta. La fecha de vencimiento de la tarjeta debe ser mayor a la fecha ingresada por el usuario, de no ser asi se envia un mensaje de error. 23. Comparar fecha de vencimiento 2: Esta rutina compara una fecha ingresada por el usuario con la fecha de vencimiento de la tarjeta que se encuentra en la Pista II de la tarjeta. Envía un mensaje de respuesta, dependiendo del
resultado, en este caso las fechas deben ser iguales .
4.2. Cifrado de datos
Una parte fundamental del trabajo de grado y sin la cual un dispositivo como WI- P.O.S no tendría validez alguna en el mercado es el módulo de cifrado, ya que es la parte que se encarga de darle un nivel de seguridad a la información cuando viaja por la red.
Debido a que WI-P.O.S debe ser un dispositivo que cumple con los estándares de seguridad, su módulo de cifrado se basa en un algoritmo DES (Data Encryption Standard), este sistema de cifrado es utilizado en el mercado colombiano por la complejidad que implica el tratar de descifrarlo sin tener el acceso a las llaves.( ver Anexo Marco Teórico)
Para su implementación se evaluó que la mejor forma de hacerlo era mediante el uso de una FPGA (Field Programmable Gate Array, Arreglo de compuertas programables ), debido a que por medio de este dispositivo se tenía la posibilidad de manipular directamente los 64 bits de la llave y de la información.
La FPGA seleccionada fue una ACEX 1K50TI144-2, esta consta de 50 mil compuertas lógicas, teniendo aproximadamente 5000 elementos lógicos programables, tiene un empaque de montaje superficial delgado y un total de 144 pines. Una de las características de las FPGA es que tienen memoria volátil, por lo que es preciso utilizar una memoria para recargar los parámetros del programa desarrollado, en nuestro caso el cifrado en DES, de lo contrario, cada vez que se prendiera la FPGA tendría que programarse directamente de la herramienta de desarrollo. Por esto se implementaron las conexiones correspondientes entre la ACEX 1K y una memoria serial de ALTERA EPC2LC20. A continuación se hace una descripción de las conexiones en la Figura 11, el tipo de conexión utilizado es llamado Passive Serial, o Serial Pasivo.
61
62 FIGURA 11, Configuración Serial Pasiva entre la memoria EPC2 y la FPGA ACEX 1K3
A parte de las conexiones entre memoria y FPGA se deben crear conexiones al programador, que en este caso es JTAG (Joint Test Action Group), que es usado por las herramientas de desarrollo de ALTERA. A continuación se muestran las conexiones correspondientes en la Figura 12 y en la Tabla 1 .
3 en la página www.altera.com
TABLA 1 Conexiones ente ACEX1K y JTAG en modo Serial Pasivo4 Figura 12, conector JTAG para programar la ACEX1K
Con la información de la figura y la tabla anterior se pueden establecer las conexiones, cabe anotar que los componentes electrónicos con que se trabajó se encuentran disponibles solo en montaje superficial, lo que hace que sus pruebas se 4 Para manyor información acerca de las conexiones favor remitirse a la pagina www.altera.com
63
deban realizar directamente en el impreso, por esto se debe tener un especial cuidado en las conexiones y en el diseño del impreso.
Para el desarrollo de DES se siguió el proceso establecido según el documento FIPS 46, explicado en el marco teórico, se evaluaron las posibles herramientas para su implementación como MAX PLUS II, MODELSIM y QUARTUS II, y finalmente se decidió implementar en esta última, por la facilidad y comprensión de la herramienta y por que las FPGAs que tenía cumplían con las características apropiadas para la implementación del módulo de DES.
Debido a que el dispositivo se tiene que comunicar con el PIC por medio de su puerto SPI, la información de los datos y de la llave se deben cargar serialmente, de manera que se implementaron 2 módulos aparte del de DES, estos son: un módulo que convierte la información de serie a paralelo para poder recibir la información en el módulo DES y otro módulo que convierte la información de paralelo a serie para poder enviar la información ya cifrada. Cabe anotar que estos módulos fueron implementados dentro de la misma FPGA. En la figura 13, se puede observar la conexión de los módulos entre ellos. FIGURA 13, Módulos de entrada y saluda a DES
4.2.1. Módulo Serie-Paralelo
Este módulo recibe la información que proviene de forma serial y la convierte en paralelo, debe entender en que momento se envía la información de la llave o de los
64
datos a cifrar, también debe ser enviado con su respectivo reloj para poder interpretar la información serial.
Es por esto que se han definido 3 señales de entrada importantes en este módulo, los cuales son:
D: Por esta entrada se envían los datos. SERIAL_CLOCK: Por esta entrada se envía el reloj para que el módulo interprete los datos. NRESET: Con esta señal se puede dar reset al módulo, borrando sus registros y sus contadores internos. Cabe anotar que esta señal es negada. ENABLE_D: Este Pin identifica si la información enviada pertenece a la llave o a los datos a ser cifrados. 1: Datos a ser cifrados. 0: Llave. KEY (0..63): Salida donde se almacena la llave. KEY READY: Salida que indica que la llave fue cargada. 1: Llave cargada 0: Llave no cargada. DATA (0..63): Salida donde se almacenan los datos a ser cifrados. En la Figura 14 se pueden ver las entradas y las salidas del módulo. FIGURA 14, Módulo serie-paralelo
65
Para enviar la información serial se deben seguir las siguientes especificaciones: primero se debe enviar un 01h para poder comenzar la transmisión de datos al módulo Serie-Paralelo, todo sincronizadamente con la señal de reloj. Desde este punto el módulo cuenta 64 ciclos de reloj para saber que la información ha llegado completa. Si la información que se envió pertenecía a los datos, la entrada de ENABLE_D debió haber permanecido en 0 durante el envío de la información. En el momento de ser la llave cargada, un contador interno cuenta los 64 ciclos de reloj de la carga de la llave y en el momento de terminar de contar levanta la señal de KEY READY. Si la información que viajaba eran los datos a ser cifrados ENABLE_D debió haber permanecido en 1 durante el envío de la información. En la Figura 15, se observa cuando el módulo recibe la información de los datos a cifrar y en la Figura 16 se puede ver cuando recibe la información de la llave. FIGURA 15, Simulación de módulo Serie-Paralelo con recepción de datos a cifrar
En el ejemplo de la Figura 16, se puede observar que para enviar la información se necesita primero enviar el 01h para que el sistema se prepare a recibir los siguientes 8 Bytes, también la señal de ENABLE_D se encuentra en todo momento en 1 al igual que la señal de NRESET. Al finalizar el envío de la información se puede ver en la salida data la información en paralelo. FIGURA 16, Simulación de módulo Serie-Paralelo con recepción de llave
66
En la Figura 16, se muestra el envío de la información de la llave, por lo que, en lo único que difiere del ejemplo de la Figura 15, es en la señal ENABLE_D que se encuentra en 0.
4.2.2. Módulo Paralelo-Serie
Este módulo se encarga de recibir la información de 64 bits en paralelo ya cifrada del módulo DES y volverla serial para poderla enviar al microcontrolador. Recordando que todo el módulo de cifrado funciona como esclavo del microcontrolador la información que entrega el módulo paralelo-serie, depende del reloj enviado por el maestro.
Sus entradas y salidas son las siguientes:
Q (63..0): En esta entrada se pone la información paralela que será convertida en serie por el módulo, es decir, el resultado de la realización del cifrado en el módulo de DES. TAKE_D: Con esta entrada se le indica al sistema cuando tomar los datos que se encuentran en su entrada Q (63..0). SERIAL_CLOCK: Esta entrada pertenece al reloj generado por el maestro quien controla en que momento se le debe enviar la información serial. NRESET: Con esta señal se puede dar RESET al módulo, borrando sus registros. Cabe anotar que esta señal es negada. OUTDATA: En esta salida la información ingresada paralelamente al sistema sale de forma serial, sincronizada con la señal de SERIAL_CLOCK enviada por el maestro, cabe anotar que la información es enviada con el borde de subida de la señal de reloj.
En la Figura 17, se pueden ver las señales del módulo paralelo-serie.
67
FIGURA 17, Módulo paralelo-serie
Para solicitar al módulo la información se debe primero poner en 1 por 8 ciclos de reloj la señal TAKE_D, esto, debido a que con esta señal se cargan los registros de entrada almacenando la información que se encuentra en Q (63..0), luego se solicitan los datos cifrados con sólo enviar el reloj. A continuación en la Figura 18, se muestra un ejemplo de cómo el módulo paralelo-serie entrega la información cifrada. FIGURA 18, simulación del módulo Paralelo-Serie
4.2.3. Modulo DES:
Para la elaboración de este módulo se siguieron los pasos establecidos en el Marco Teórico en la sección de DES, donde se explica el funcionamiento de este sistema de cifrado.
Para su implementación se desarrollaron diferentes funciones en el lenguaje de ALTERA AHDL, en donde se repartieron los desarrollos de las tablas de permutación, sustitución y otros, para distribuir el módulo DES de una manera más sencilla de desarrollar.
68
4.2.4. Funciones de Tablas:
A continuación se explican las funciones de las tablas desarrolladas para la implementación de DES, para un mayor entendimiento del funcionamiento de cada tabla se recomienda referirse al marco teórico.
? IP (Initial Permutation) ? IP-1 (Inverse Initial Permutation) ? PC1 (Permuted Choice 1) ? PC2 (Permuted Choice 2) ? E (Expantion) ? P (Permutation) ? Sn (Tablas de Sustitución)
IP (Initial Permutation):
La permutación inicial es realizada sobre la información de 64 bits a ser cifrada, como salida se tienen 2 bloques de 32 bits cada uno denominados L0 y R0, este proceso se puede ver claramente en el marco teórico. En su implementación en AHDL la entrada se reordena según la tabla IP, utilizando para esto funciones de tablas por su facilidad de manejo. IP-1(Inverse Initial Permutation): La permutación inicial inversa es hecha sobre el último bloque R16L16 teniendo como entrada un bloque de 64 bits, estos bits son reordenados según la tabla IP-1 del E (Expantion): La tabla de Expansión se aplica sobre el bloque Rn en cada iteración, tiene una
69
entrada de 32 bits y una salida de 48 bits, de ahí el nombre que recibe. P (Permutation): La tabla de permutación P se aplica sobre la información que sale de las tablas de sustitución, tiene como entrada 32 bits y como salida 32 bits. PC-1(Permutation Choice 1): Esta tabla tiene como entrada el bloque de 56 bits de la llave sin sus bits de paridad y como salida tiene 2 bloques de 28 bits cada uno, denominados en el Marco teórico como C0 y D0. PC-2(Permutation Choice 2): Esta tabla tiene como entrada la unión de los bloques Cn y Dn después de su corrimiento, tiene como entrada un bloque de 56 bits y como salida un bloque de 48 bits. Tablas de sustitución Estas tablas tienen como entrada un bloque de 6 bits, donde el primer y último bit significan el número de la fila de la tabla, que va de 0 a 3 en binario. Los bits de la mitad simbolizan el número de la columna y pueden tomar los valores de 0 a 15 en binario.
4.2.5. Funciones Específicas:
A partir de la definición e implementación de cada una de las tablas anteriores por
70
medio de funciones se generaron otras funciones más específicas para generalizar los pasos. Función de sustitución: Al tener implementadas las funciones de las tablas de sustitución se creó una función más general en la que se invocaban todas, teniendo como entrada un bloque de 48 bits y una salida de 32 bits. La función divide el bloque de 48 bits de entrada en pequeños grupos de 6 bits, en donde el primer grupo entra a la primera tabla de sustitución, el segundo a la segunda tabla y así sucesivamente. Como cada tabla de sustitución genera como respuesta bloques de 4 bits, éstos son unidos al final, generando un total de 32 bits al agruparlos. Función F: Esta función, definida en el marco teórico, tiene como entradas dos bloques, uno de 32 bits que representa Rn y otro de 48 bits que representa la subllave, como salida tiene un bloque de 32 bits. Esta función introduce el bloque Rn en la función de la tabla de Expansión E, generando una salida de 48 bits, que son operados con la subllave por una XOR. Estos 48 bits resultantes son introducidos a la función de sustitución explicada anteriormente, teniendo como salida un bloque de 32 bits. En este punto se ve la importancia de haber desarrollado el sistema de cifrado por funciones. DES: Para la generación del algoritmo DES se utilizaron los recursos de memoria de la FPGA para almacenar las subllaves generadas para cada función F, incluyendo el archivo de manejo de memorias llamado lpm_ram_dq.inc, donde se almacenaron 16 llaves cada una de 48 bits. Esta librería permite manejar memorias con tamaño de
71
información variable, para el caso de la generación de las subllaves fue conveniente porque se utilizaron 48 bits de tamaño de dato.
Para la generación de las subllaves, el bloque de 64 bits de entrada fue primero pasado por la función PC-1, la cual entregaba 2 bloques de salida C0 y D0, luego como la generación dependía de corrimientos a la izquierda, los 2 bloques fueron introducidos en una máquina de estados que realizaba los corrimientos según la iteración en que se encontraba. Al realizarse los bloques Cn y Dn eran unidos y se llamaba la función PC-2 donde finalmente se tenía la subllave generada. Con esto se almacenaba la información en memoria.
Para cifrar la información, se cogían los datos y se llamaba la función IP, con este resultado se generaron los bloques L0 y R0 los cuales eran pasados por la función F creada anteriormente. Para las iteraciones se creó una máquina de estados donde en cada iteración se hacían los cambios de los bloques L y R y además se llamaba la función F invocando la subllave de la memoria.
4.2.6. Entradas del módulo ? KEY (64..1): Entrada paralela de la llave de 64 bits. ? DATA (64..1): Entrada paralela de la información a cifrar o descifrar.
? CRYPT: Señal que indica si la operación que se va a realizar es de cifrado o descifrado.
1: Cifrado.
0: Descifrado. ?
? START_KEY: Entrada, esta señal le indica al módulo DES que comience a generar las subllaves.
START: Entrada esta señal le indica al módulo DES que comience a cifrar la
72
?
?
? información.
CLOCK: Reloj del módulo.
NRESET: Señal negada que le da reset al sistema
1: No reset.
0: Reset.
OUT_DES (64..1): Salida paralela de la información ya cifrada o descifrada. FIGURA 19, Entradas y Salidas del modulo DES
4.2.7. Integración de los módulos:
De acuerdo a la descripción de los módulos explicados anteriormente, son unidos por medio de sus señales entre sí. El módulo serie-paralelo se interconecta con el módulo DES por medio de las señales de la salida paralela de la llave de 64 bits y la salida de la información a cifrar de 64 bits. La señal de KEY_READY se encarga de dar la orden al módulo DES de comenzar a generar las subllaves, ésta señal se conecta con START_KEY.
El módulo DES se conecta con el módulo paralelo-serie por medio de la salida paralela de OUT_DES. Las conexiones entre cada módulo se pueden ver en la Figura19.
73
4.2.8. Módulo de Cifrado
Teniendo los módulos interconectados se genera el módulo de cifrado, el cual tiene las siguientes señales de control.
? NRESET: Esta señal de entrada se encarga de reiniciar los módulos y borrar la información almacenada en sus registros. 1: No reset. 0: Reset ?
? ENABLE_D: Esta señal de entrada indica que información se va a enviar al módulo por la entrada D. 0: La información que entra a D pertenece a la llave. 1: La información que entra a D pertenece a la información a cifrar. D: Esta entrada recibe la información serialmente, ya sea la llave o la información a cifrar. ? SERIAL_CLOCK: Reloj que sincroniza la información que entra por la entrada serial D. ? START: Con esta entrada se da la orden al módulo de comenzar a cifrar. ? CLOCK: Reloj del módulo de cifrado. ? CRYPT: Señal de entrada que indica si se va a realizar una operación de cifrado o descifrado. 1: Cifrado. 0: Descifrado. ? TAKE_D: Esta señal de entrada prepara al módulo de cifrado para enviar la información del resultado del cifrado o descifrado. 1: Enviar información. 0: No enviar la información. ? ? OUT_DATA: Señal de salida por donde se envía la información. DONE: Señal de salida que indica que la información ya se terminó de cifrar o descifrar
74
75 FIGURA 20, Interconexión entre módulos 4.3 APLICACIÓN EN J2ME PARA EL TELÉFONO MÓVIL MOTOROLA Para el uso apropiado del dispositivo es necesario tener una interfaz gráfica amable que es la encargada de interactuar con el usuario para llevar a cabo la transacción con
76 éxito, ya que esta interfaz le permite al usuario llevar el control de la transacción paso por paso ingresando la información necesaria de la forma como la aplicación se la va solicitando. Esta aplicación fue desarrollada en el lenguaje de programación Java 2 Micro Edition (J2ME), que está orientado a dispositivos móviles con limitada capacidad de procesamiento y de memoria como los teléfonos móviles y PDAs, y que está siendo incorporada de fábrica en los equipos móviles Motorola iDEN de Avantel a los cuales está orientado WI-P.O.S. 4.3.1. Descripción de la aplicación: Existen dos aplicaciones importantes que son las que permiten llevar a cabo con éxito una transacción bancaria utilizando el dispositivo desarrollado en este Trabajo de Grado. Hay una tercera aplicación que consiste en generar el reverso de una transacción, es decir anula la ultima transacción realizada, esto por si existe algún tipo de error. La primera de ellas es la encargada de permitir cargar los Parámetros Iniciales(ver sección 3.3) al dispositivo. Es una aplicación en la cual no interactúa el usuario que va a realizar un pago a través de tarjeta débito o tarjeta de crédito sino que la ejecuta el funcionario del establecimiento cada vez que se enciende el equipo. La segunda aplicación es la aplicación de Transacción de Pago, la cual permite realizar un pago con tarjeta débito o tarjeta de crédito. Las aplicaciones mantienen un contacto permanente con el dispositivo WI-P.O.S por medio de un puerto serial que tiene el teléfono y también se comunican con el servidor que recibe y envía información acerca de la transacción a través del protocolo seguro de Internet HTTP (HyperText Transfer Protocol), utilizando la red iDEN de Avantel. Las aplicaciones están divididas en clases, propias del lenguaje
Java que es orientado a objetos, las cuales permiten un manejo completamente modular ya que hay un programa principal donde se desarrolla la secuencia de cada aplicación y en ese programa principal se hacen diferentes llamados a estas clases para que realicen acciones específicas, y a veces repetitivas, reduciendo la cantidad de código para la aplicación.
4.3.2 Clases desarrolladas en la aplicación:
CommPuerto: Permite la comunicación del dispositivo móvil con el puerto serial para enviar y recibir información, manejando número enteros. Esta clase recibe tres parámetros de tipo entero (int). El primero es el dato a enviar por el puerto serial, el segundo es un entero que indica cuantos bytes espera recibir la aplicación de la unidad central de procesamiento y el tercero es un entero que indica si se envía un dato o solamente se espera una respuesta. Cada byte que esta clase recibe del Wi POS, lo convierte a un número entero. Al final, devuelve una cadena de caracteres, con números enteros, a la aplicación principal.
CommPuerto2: Permite la comunicación del dispositivo móvil con el puerto serial para enviar y recibir información, manejando información en hexadecimal. Recibe los mismos tres parámetros que CommPuerto pero la diferencia es que cada byte que recibe, lo expresa en una cadena hexadecimal. Al final devuelve una cadena de caracteres, con números en hexadecimal, a la aplicación principal.
DataRequest: Permite el envío de instrucciones a la unidad central de procesamiento para que guarde información ingresada por el teclado y esta información se vea en la pantalla del teléfono móvil. Esta clase recibe como parámetros un entero que expresa cuantos dígitos se esperan recibir del teclado, un objeto de tipo Forma que es la pantalla que se muestra en ese momento al usuario en la cual van a ir apareciendo los números que se digiten
77
por el teclado del Wi POS, y un índice que le indica a la unidad central de procesamiento en qué lugar de memoria se debe guardar esa información. Al final, devuelve una cadena de caracteres indicando si la operación fue exitosa o no.
Flag, positionThread: Estas clases permiten el manejo de pantallas temporales, muy usadas en la aplicación, para mostrar al usuario una información mientras el equipo realiza otra tarea. Una vez finalizada esa otra tarea, se cambia la pantalla a una pantalla final. Un ejemplo de esto es cuando la aplicación muestra la pantalla que le indica al usuario que deslice la tarjeta por el lector. Mientras que el Wi POS espera que esto ocurra, el teléfono muestra esa pantalla y apenas el usuario desliza la tarjeta, el Wi POS le indica a la aplicación que la tarjeta fue deslizada y la aplicación muestra la pantalla siguiente. Son pantallas que permiten al usuario ver que el sistema se encuentra realizando algún proceso, cuando éste puede tardar varios segundos. Si ésta clase de pantallas no se incorporaran en la aplicación, el usuario podría confundir una pantalla congelada temporalmente con un bloqueo de la aplicación.
Httpconnection: Permite la conexión a Internet, enviando y recibiendo datos a esta red. Esta clase recibe como parámetro una dirección de Internet a la cual el dispositivo se va a conectar y devuelve una cadena de caracteres indicando si la conexión fue exitosa o no.
PINEntry: Esta clase envía instrucciones a la unidad central de procesamiento para que guarde la información proveniente del teclado que se refiere a la clave del usuario y que en pantalla se vean asteriscos. Esta clase recibe como parámetros un entero que indica el número de dígitos que se van a ingresar por el teclado, un entero que indica cual llave de cifrado debe utilizarse para cifrar los datos que se ingresen por el teclado, y un objeto tipo Forma que es la pantalla a mostrar mientras se digita la clave, que no muestra los números
78
digitados sino asteriscos. Al final, devuelve una cadena de caracteres indicando que la operación fue realizada satisfactoriamente.
ReadCardRequest: Esta clase permite el envío de instrucciones a la unidad central de procesamiento para que reciba la información del lector de banda magnética. Esta clase recibe dos parámetros de tipo cadena de caracteres los cuales indican qué información recoger de la tarjeta deslizada: la Pista I o la Pista II. El primer parámetro hace referencia a la Pista I y el segundo parámetro hace referencia a la Pista II. Devuelve a la aplicación principal una cadena de caracteres indicando si la acción realizada fue correcta o no.
Reset: Esta clase reinicia la unidad central de procesamiento. Envía al Wi POS una instrucción que hace que el equipo reinicie. Se utiliza en algunos puntos de la aplicación principal para verificar que el funcionamiento es correcto y que no hay pérdida de información, o en procesos que pueden bloquear a la unidad central de procesamiento. Esta clase no recibe ningún parámetro de entrada ni devuelve algún dato.
Tabla: Esta clase realiza la conversión de números en formato hexadecimal a enteros. Recibe como parámetro de entrada un carácter en hexadecimal, lo compara con una tabla que tiene y devuelve un entero, correspondiente al dato en hexadecimal.
Tramas: Esta clase solicita a la unidad de procesamiento las tramas respectivas para enviar a Internet, espera una respuesta y devuelve a la unidad de procesamiento una trama. La clase recibe como parámetros de entrada tres datos de tipo entero. El primero hace referencia a la instrucción enviada al Wi POS. El segundo hace referencia a la cantidad de bytes que se espera recibir del Wi POS, dependiendo de la instrucción solicitada. El tercero indica el tamaño de la trama que devuelve el servidor en cantidad de caracteres, para guardarlos en una matriz, convertirlos a enteros para luego pasarlos a
79
hexadecimal y enviarlos byte por byte al Wi POS.
Modulo10: Esta clase verifica si el número de la tarjeta es un número válido haciendo uso del algoritmo de chequeo de modulo 10(ver Anexo Marco Teórico). Recibe como único parámetro una cadena de caracteres con el PAN (Personal Account Number) y devuelve verdadero (true) si el número de la tarjeta es un número válido, o falso (false) si éste es inválido.
Con estas clases, las aplicaciones principales pueden mantener contacto permanente con la unidad central de procesamiento y con el usuario/funcionario a través de la pantalla del teléfono.
4.3.3. Descripción de las aplicaciones principales.
A continuación se explicará la secuencia que siguen las aplicaciones de Carga de Parámetros Iniciales y de Transacción de Pago ilustrando lo que se ve en la pantalla del teléfono móvil utilizando el emulador del equipo Motorola iDEN i85s. Carga de Parámetros Iniciales Los parámetros iniciales se solicitan al servidor, el cual devuelve una trama con ciertos parámetros que dependen del terminal que los solicita(Ver sección 3.3.1). Esta trama se almacena en la unidad central de procesamiento y al momento de la transacción se validan los diferentes datos con estos parámetros. La secuencia de esta aplicación se da de la siguiente forma: Pantalla Inicial
En esta pantalla se le informa al funcionario que puede cargar los Parámetros Iniciales.
Figura 21. Pantalla Inicial
80
81 Figura 22. Carga de parámetros en proceso
Figura 23. Carga de Parámetros Iniciales Carga de parámetros correcta.
Figura2 4, Carga de parámetros incorrecta Carga de Parámetros en proceso En esta pantalla se le informa al funcionario que se está efectuando la carga de los Parámetros Iniciales en el equipo. Durante la carga de los parámetros se despliega una barra que muestra el progreso del proceso. En este momento la aplicación se comunica con el dispositivo y le solicita la trama de Solicitud de Parámetros Iniciales, la cual es enviada al servidor. El servidor devuelve una trama de respuesta con todos los parámetros iniciales, que recibe la aplicación y que inmediatamente es enviada al dispositivo.
Confirmación de la carga de los parámetros
Se le informa al usuario que la carga de parámetros iniciales ha sido exitosa y por lo tanto ya se pueden realizar transacciones de pago.
Carga de parámetros incorrecta: En esta pantalla se le informa al usuario que la solicitud y carga de parámetros iniciales ha tenido problemas. Este error ocurre cuando la trama de respuesta enviada por el servidor al dispositivo no es la esperada y hay información errónea en algún campo de la trama.
Figura 25. Carga de Parámetros Iniciales, Error en el puerto serial
Figura 26. Carga de Parámetros Iniciales, Error en la conexión a Internet Error en la comunicación con Wi POS Si durante el proceso
Página anterior | Volver al principio del trabajo | Página siguiente |