Dispositivo electronico para la realización de transacciones bancarias por medio de una red inalámbrica iDEN (página 3)

Error en la conexión a Internet Si durante el proceso de carga de parámetros se da algún error en la comunicación entre el teléfono móvil y el servidor de Internet, se le informa al funcionario de este error para que reinicie la aplicación. Cuando el funcionario oprime “OK”, la aplicación automáticamente vuelve a comenzar, desplegando la pantalla inicial, mostrada anteriormente. La aplicación intenta realizar la carga de parámetros hasta tres veces si hay inconvenientes en la comunicación con el servidor. Después de la tercera vez, se le informa al usuario que la carga de parámetros

82

Figura 27. Carga de Parámetros Iniciales, Error sin solución informa al usuario que la carga de parámetros no es posible en el momento. Estos errores se pueden presentar si la dirección a la que intenta acceder la aplicación no es válida o si el servidor en ese momento no está en servicio.

No se puede solucionar el error

Esta pantalla aparece cuando se ha intentado realizar la carga de parámetros hasta tres veces y persiste el error de comunicación con Wi – POS o el error de comunicación con Internet. En este caso la aplicación le informa al funcionario que debe salir de la aplicación para intentar de nuevo todo el proceso. • . Transacción de Pago Figura 28. Transacción de Pago, Pantalla Inicial Esta aplicación es la que permite al usuario realizar una transacción de pago utilizando tarjeta débito o tarjeta de crédito. El proceso de la transacción es descrito a continuación mostrando cada pantalla que despliega la aplicación, de nuevo utilizando el emulador del equipo móvil Motorola iDEN i85s. Es necesario que los parámetros iniciales estén cargados en el dispositivo antes de poder realizar la transacción de pago. Por esta razón hay que ejecutar primero la aplicación de carga de Parámetros Iniciales para luego poder efectuar con éxito la transacción de pago.

Pantalla Inicial

Esta aplicación comienza con una pantalla de inicio, desplegando el logotipo de Wi – POS. Cuando el usuario oprime “Ingresar” lo primero que hace la aplicación es verificar que los Parámetros Iniciales estén cargados en el dispositivo Wi – POS. La aplicación le envía una

83

84 Figura 29. Transacción de Pago, Parámetros Iniciales no han sido cargados Figura 30. Transacción de Pago, Pantalla de bienvenida dispositivo Wi – POS. La aplicación le envía una instrucción al dispositivo para que le responda si los parámetros están cargados. Si no están cargados, se despliega una pantalla informando al usuario que debe cargar los Parámetros Iniciales antes de intentar realizar la transacción pero si éstos ya están cargados, la aplicación sigue su curso. Parámetros Iniciales no están cargados

Si los Parámetros Iniciales no han sido cargados, se le pide al usuario que salga de la aplicación y los cargue de inmediato.

Pantalla de Bienvenida

En esta pantalla se le da la bienvenida al usuario y se pide que verifique el dispositivo está conectado el equipo móvil correctamente Motorola. Figura 31 Transacción de Pago, Deslizar tarjeta Deslizar tarjeta crédito/débito por el lector En esta pantalla se le pide al usuario que deslice la tarjeta de crédito/débito por el lector de banda magnética. Si la tarjeta es deslizada incorrectamente aparece una pantalla informándole al usuario que la deslizó de forma indebida y que vuelva a intentarlo. De forma contraria, la transacción sigue su curso.

Figura 32, Error de tarjeta

Figura 33. Transacción de Pago, Verificando Datos Verificación de datos En esta pantalla se le pide al usuario que espere un momento mientras se verifican algunos datos. En este instante la aplicación le pide al dispositivo que le envíe la trama de Solicitud de los Parámetros de Tarjeta para enviarla al servidor y que éste le devuelva una trama con dichos parámetros para almacenarlos en el dispositivo y realizar el proceso de la transacción según lo indiquen los parámetros de tarjeta. Al finalizar la carga de los parámetros de tarjeta, la aplicación verifica si el parámetro “módulo 10” está activo y si lo está, procede a ejecutar la clase Modulo10 para verificar que el número de la tarjeta deslizada por el lector es válido.

En caso que sea válido, aparece en pantalla la opción “Continuar” para que el usuario prosiga con la transacción. Si el número no es válido, aparece una pantalla indicándole al usuario de este problema y tiene tres intentos para pasar por el lector una tarjeta válida. Si pasan los tres intentos y la tarjeta no es válida, la aplicación le informa al usuario que debe abandonar la transacción. Si existe algún error de comunicación entre la aplicación y el dispositivo o entre la aplicación y el servidor,

85

86 aparecerá la respectiva pantalla indicando dicho error, así como en la aplicación de Parámetros Iniciales. La pantalla mostrada en la figura 34 , se muestra mientras el equipo se comunica con el servidor y le solicita los parámetros de la tarjeta. Estos parámetros son cargados y solicitados, además en este momento se hace una solicitud de llave de cifrado de PIN de ser necesario y se valida el modulo 10 de la tarjeta. Figura 34. Verificación de datos Esta pantalla aparece cuando el número de la tarjeta es inválido y ésto lo determina la clase Modulo10. Hay tres oportunidades para que el usuario deslice una tarjeta válida por el lector de banda magnética. Figura 35, Número inválido Si después de los tres intentos el usuario no desliza una tarjeta válida, la transacción termina y se le informa al usuario que la aplicación debe terminar. Figura 36, Persiste error de Número Invalido Una vez cargados los parámetros de tarjeta en el dispositivo, la aplicación le pide uno a uno el valor de los diferentes parámetros a Wi – POS para almacenarlos en variables que la aplicación consulta para pedir los diferentes datos al usuario a medida que transcurre el proceso de la transacción. Si alguno de los parámetros no está activo para solicitarlo, la aplicación prosigue a verificar el siguiente. A continuación se muestran cada uno de los parámetros que se solicitan en el orden en que la aplicación los requiere.

El primer parámetro a validar es la fecha de vencimiento. Si este parámetro está activo, se le solicita al usuario ingresar la fecha de vencimiento Figura 37, Ingrese fecha

Si la fecha de vencimiento ingresada por el usuario no corresponde a la de la tarjeta, se le informa que la fecha es inválida y que debe salir de la aplicación.

Figura 38, Fecha Inválida

El siguiente parámetro es comparar la fecha de la tarjeta con la fecha del sistema. Si está activo, internamente el dispositivo compara las dos fechas y si la tarjeta está vigente continúa la transacción, si no, aparece esta pantalla.

Figura 39, Tarjeta Vencida.

Los siguientes parámetros a verificar indican si la aplicación debe pedir al usuario el ingreso de una clave, ya sea para tarjeta débito o para tarjeta de crédito. Si estos parámetros están activos, aparece la pantalla que le pide la clave al usuario.

Figura 40. Ingreso Clave

87

88 A continuación se le pide al usuario el tipo de tarjeta, si este parámetro se encuentra activo. El usuario escoge entre tres opciones: tarjeta débito de ahorros, tarjeta débito corriente o tarjeta de crédito.

Figura 41, Selección de tarjeta

En este momento se le pide al usuario que ingrese el valor de la transacción utilizando el teclado de Wi – POS.

Figura 42, Valor Transacción

El siguiente parámetro a verificar es si se necesita pedir propina al usuario. Si esto es necesario, el usuario ingresa el valor de la propina utilizando el teclado del Wi – POS.

Figura 43, Valor de Propina

A continuación se verifica si es necesario pedirle al usuario el número de cuotas a diferir el pago a realizar. Si está activo, el usuario debe ingresar el número de cuotas por el teclado del dispositivo.

Figura 44, Número de cuotas

El último paso es la validación de la transacción. Una vez solicitado el último parámetro, la aplicación calcula el IVA del valor introducido, la Base de Devolución de IVA (Valor de la transacción sin IVA) y los envía al Wi – POS. Luego solicita al dispositivo la Trama de Pago para enviarla al servidor. El servidor devuelve una trama con la descripción de la respuesta a la transacción. Mientras este proceso ocurre, se despliega una pantalla de Transacción en Proceso.

Figura 45, Transacción en proceso Figura 46, Pantallas de resultado de transacción

Dependiendo del resultado de la transacción se desplegara una pantalla informando la aprobación o error de esta, alguno casos se muestran en la figura 45 Esto lo realiza el teléfono cuando por medio de la aplicación y después de haber recibido la repuesta de transacción, pide al microcontrolador los campos de código de repuesta y descripción de respuesta( Ver sección 3.3.6)

Luego de obtener el resultado de la transacción, se imprime un comprobante de pago solamente si el parámetro que lo solicita está activo. En caso contrario, no se imprime ningún comprobante. El comprobante incluye el valor de la transacción, el consecutivo y el numero de terminal en donde se realizo esta.

4.4. APLICACIÓN EN VISUAL BASIC

La finalidad de esta aplicación desarrollada en Visual Basic es ingresar la

89

90 información de las llaves maestras, de la llave de transporte y del número de terminal. Esta aplicación fue implementada externamente al teléfono móvil para que no todos los usuarios de WI-P.O.S tengan la posibilidad de acceder a estas funciones, es por esto que se recurrió a una aplicación desarrollada en Visual Basic. Para su uso es necesario tener conectado WI-P.O.S por medio de un cable serial RS232 a un computador. Para la comunicación se usaron instrucciones de 8 bits. A continuación en la Figura 47, se muestra la pantalla principal de la aplicación. FIGURA 47, Pantalla principal de la Herramienta de Administración de WI-P.O.S

A partir de las opciones mostradas en el menú principal de la aplicación se explicarán las diferentes funciones del programa.

4.4.1. Enviar Llaves

Esta función sirve para enviar las Llaves Maestras o de Transporte al equipo (Para ver información de Llaves Maestras y de Transporte Ver Capítulo de Especificaciones, numeral 3.4). A continuación se observa la Figura 48, donde se muestran las diferentes opciones de la sección Enviar Llave.

FIGURA 48, Pantalla de Enviar Llaves.

En esta sección se tienen 2 opciones que son las de enviar la llave de transporte o la llave maestra.

4.4.2. Llave de Transporte

En la Figura 49, se muestra la pantalla de la aplicación desde donde se envía la Llave de Transporte. FIGURA 49, Pantalla de envío de llave de transporte.

Para enviar la llave de transporte a WI-P.O.S se manejó un protocolo de comunicación entre las dos partes, todo transmitido y recibido desde el puerto serial del computador. El protocolo establecido para estos procesos esta ilustrado en la Figura 50.

91

FIGURA 50. Protocolo de envío de llave de transporte

La estructura de la aplicación consiste en primero validar la información de la llave de transporte, por lo que se le pide al usuario que ingrese la llave de transporte 2 veces, estas dos llaves deben ser las mismas en longitud y valor, en el momento que se ingresen llaves diferentes o la longitud de las llaves sean diferentes a 16 caracteres la aplicación avisará que se ha producido un error y no enviará la información como se puede ver en la Figura 51 y luego pedirá que se ingresen de nuevo. Al ingresarse las llaves correctamente, la aplicación envía primero a WI-P.O.S la instrucción correspondiente a la carga de la llave de transporte, WI-P.O.S realiza un reconocimiento de la información recibida y envía un ACK para que la aplicación le envíe la llave de transporte. FIGURA 51, Errores producidos al ingresar mal los datos de llave de transporte

Como la información ingresada de la llave se encuentra en ASCII, la aplicación la transforma en Hexadecimal, tomando el entero correspondiente al carácter en ASCII

92

y restándole 48 en caso de ser un valor entre 0 y 9, 55 en caso de ser un valor entre “A” y “F”, o 87 en caso de haber escrito los valores de “a” a “f” en minúscula.

Luego que WI-P.O.S recibe la llave de transporte este procede a enviarle otro reconocimiento es decir un ACK, con este último valor la aplicación en Visual sabe que la información fue enviada satisfactoriamente y avisa al usuario del éxito del proceso, como se puede ver en la Figura 52. FIGURA 52, Envío de la llave de transporte exitosa.

Cabe anotar que en caso que se tenga problemas en la comunicación de WI-P.O.S con el computador, la aplicación avisará al usuario para verificar la conexión como se puede ver en la Figura 53. FIGURA 53, Error en la comunicación entre WI-P.O.S y el Computador.

4.4.3. Llave Maestra

La función de ingreso de la llave maestra varía con respecto a la función de la llave

93

94 de transporte en que se deben seleccionar el número total de subllaves maestras y el número de la subllave que se va a enviar. En la Figura 54, se puede ver la pantalla en que se selecciona el número de subllaves totales. FIGURA 54, Selección de número de llaves totales

Para enviar el número total de llaves maestras a enviar se le envía por el puerto serial a WI-P.O.S la instrucción correspondiente a la rutina para que acepte estos valores, es importante almacenar éste valor porque determina entre cuantas partes se debe hacer XOR, por lo que es almacenado en la EEPROM. En la Figura 55 se observa como se maneja la instrucción de envío de número de partes. FIGURA 55, Envío de número total de llaves maestras

En el momento que se ha aceptado el número de partes la aplicación de Visual Basic despliega la pantalla en que se envía la llave maestra, como se ve en la Figura 56.

FIGURA 56, Envío de llave maestra Para enviar la información de la llave maestra se envía primero la instrucción a WI- P.O.S para que entre en la rutina de ingreso de llave maestra, luego se envía el número de la parte y finalmente la llave maestra. Cabe anotar que se hacen las mismas validaciones de tamaño de la llave e igualdad entre la llave maestra y la confirmación de la llave maestra como se explicó en la sección de llave de transporte. En la Figura 57 se ilustra el proceso de comunicación para enviar las llaves maestras. FIGURA 57. Comunicación entre WI-P.O.S y Computador para envío de Llaves Maestras

4.4.4. Seleccionar Llave Maestra

Como se puede ver en el Capítulo de Especificaciones, en la sección correspondiente a llaves maestras, en el equipo se pueden almacenar 3 tipos de llaves para tener un

95

96 mejor manejo de la seguridad. A continuación se ilustra en la Figura 58, la pantalla de la aplicación en Visual Basic en donde se realiza la selección de la llave maestra. FIGURA 58. Selección de llave maestra

Al igual que en los anteriores procesos de comunicación, WI-P.O.S recibe las correspondientes instrucciones que le permiten realizar los procesos de cambios de llave. Al realizarse la operación satisfactoriamente la aplicación avisa al usuario como se puede ver en la figura 59. FIGURA 59. confirmación de actualización del programa

4.4.5. Dígitos de Chequeo

Los dígitos de chequeo sirven para saber si una llave fue ingresada correctamente en WI-P.O.S, estos dígitos corresponden a los cuatro primeros caracteres resultantes de cifrar ceros con la llave ingresada, de esta manera puede comparar estos valores con unos previamente asignados para la verificación del correcto ingreso de la llave. A continuación en la figura 60 se puede observar la ventana en donde se verifica los dígitos de chequeo de la llave de transporte y de la llave maestra.

En el momento que se oprime el botón de chequeo, la aplicación envía la instrucción correspondiente para que WI-P.O.S genere los dígitos de chequeo y los envíe al computador. En la aplicación de Visual Basic la información llega en formato hexadecimal, por lo tanto para que aparezca en la ventana se debe transformar a formato ASCII de la siguiente manera, si recibe valores entre 0 y 9 la aplicación le sumará 48 y si llegan valores entre A y F la aplicación le sumará 55. De esta manera se tiene el valor correspondiente en ASCII. FIGURA 60. Ventana de dígitos de chequeo

4.4.6. Número de terminal

Para que en una transacción bancaria se identifique a quien realiza la operación, el sistema debe identificar el número de terminal que realiza la transacción, es por esto

97

98 que cada WI-P.O.S debe tener un número único que lo identifique. Por medio de esta sección de la aplicación se pueden ingresar a WI-P.O.S estos valores, en la siguiente figura se observa la ventana donde se ingresa el terminal, cabe anotar que puede tomar valores hasta de 8 caracteres. FIGURA 61, ventana de envío de número de terminal

Al igual que en el envío de la llave de transporte, el sistema valida los caracteres en tamaño y en igualdad antes de enviarlos, de tal manera que avisa al usuario si encuentra alguna inconsistencia.

4.4.7. Vector de Inicio

El vector de inicio es un parámetro necesario para la realización de cifrado en DES en modo CBC (Ver Sección 4.1.5) y es necesario que esté ubicado en Wi-P.O.S. y en el servidor donde llegan las tramas de solicitud para que el cifrado y descifrado sean correcto. Para su implementación se utilizó una interfaz al igual que la llave de transporte donde se debe escribir el valor del vector de inicio y su confirmación por cuestiones de seguridad en el ingreso de la información, a continuación se muestra la pantalla donde se ingresan los datos.

FIGURA 62, ventana de envío de vector de inicio

En esta interfaz se maneja un protocolo de comunicación similar al de la carga de llave de transporte, enviando la instrucción para que Wi-P.O.S. entre a rutina de recolección de vector de inicio, luego recibe reconocimientos y envía la información correspondiente al vector de inicio. FIGURA 63. Comunicación entre WI-P.O.S y Computador para envío de vector de inicio

4.4.8. Inicio de consecutivo

El consecutivo es un valor que identifica la transacción realizada por el terminal específico, es decir, no se van encontrar 2 transacciones hechas por un mismo Wi- P.O.S. que tengan un mismo consecutivo, estos valores son puestos en 000000 a partir de una instrucción enviada desde el administrador de Wi-P.O.S., a su vez para la confirmación del procedimiento de reinicio de consecutivo el administrador espera una instrucción de confirmación. Para este procedimiento se utilizó la siguiente

99

interfaz en donde solo se envía la instrucción y se espera por la confirmación. (Ver Figura 64) FIGURA 64, ventana de envío de vector de inicio

4.5 DISEÑO DEL CIRCUITO IMPRESO

Se diseñó un impreso que incluyera en una sola tarjeta el microcontrolador y sus periféricos y la FPGA ACEX con su memoria serial, para su diseño se tuvieron en cuenta los siguientes aspectos.

El tamaño debía ser lo más reducido posible para que el producto final sea cómodo de transportar. Se incluyeron dos reguladores, el primero de 2.5V para alimentar ciertos pines de la ACEX. El segundo de 3.3V para alimentar el resto de integrados. La distribución de las fuentes se realizó en estrella, es decir se envían caminos hacia puntos centrales en donde se ramifican los caminos. Se colocaron condensadores de 100nf cerca de los integrados. Estos para desacople. Las conexiones entre el microcontrolador y la ACEX (módulo de cifrado) se hicieron con caminos cortos y rectos. Esto se logró seleccionando los pines indicados tanto en el microcontrolador como en la FPGA y ubicando de manera apropiada los componentes.

100

101 Se usaron componentes de montaje superficial, para reducir el tamaño. Se hizo plano de tierra para disminuir interferencias, ya que se trabaja cerca de un teléfono móvil. Lograr una distribución adecuada de los componentes para evitar caminos largos y enredados.

A continuación se muestra una fotografía del circuito impreso diseñado. Figura 65, Fotografía del circuito impreso

102 5. PRUEBAS Y ANÁLISIS DE RESULTADOS

5.1 VERIFICACIÓN DE FUNCIONAMIENTO DEL MÓDULO DE CIFRADO.

Para verificar el correcto funcionamiento del módulo de cifrado se utilizó un servidor con tarjeta criptográfica y se diseñó una rutina en la cual se le envía la llave de cifrado y los datos a cifrar desde un computador al microcontrolador y este a su vez se comunica con el módulo de cifrado (este procedimiento se explica en las secciones 4.1.5 y 4.2), luego espera la respuesta y la envía al computador. Esta prueba se realizó en el circuito impreso en el cual ya se encuentran interconectados el microcontrolador y el módulo de la manera adecuada, de modo que lo que se hizo fue tomar varias llaves y datos que luego se cifraron usando la tarjeta criptográfica y el módulo desarrollado en el presente trabajo, luego se compararon los resultados. Para el uso de la tarjeta criptográfica se contó con la asesoría de un ingeniero asociado a la empresa ASIC que tiene acceso al servidor con tarjeta criptográfica y conocimiento del manejo de esta.

A continuación se describen las pruebas realizadas.

5.1.1 Pruebas de verificación de cifrado/descifrado de un bloque sin vector de inicio:

Se realizaron pruebas comparando la información cifrada resultante en WI-P.O.S. con la información cifrada por la tarjeta criptográfica, estos resultados se muestran en el Anexo 2, en la sección de pruebas de cifrado.

De esta misma forma se realizaron otras pruebas similares de resultado satisfactorio que incluyen en su totalidad en el documento, comprobando que el módulo de cifrado funciona de la manera adecuada, ya que no se presentaron errores.

103 5.1.2 Pruebas de verificación de funcionamiento de cifrado en modo CBC. Como se explicó en el capítulo 2 el módulo de cifrado sólo cifra bloques de 64 bits, por tanto para realizar cifrado en modo CBC se elaboró una rutina del microcontrolador (ver sección 4.1.5) que lleva a cabo el proceso necesario. Para probar el buen funcionamiento de ésta, se utilizó el servidor con tarjeta criptográfica, y de manera similar a la descrita en la sección anterior, se hicieron pruebas y se compararon resultados. Algunas de estas pruebas se muestran en detalle en el anexo 2, en los resultados de funcionamiento DES en modo CBC Las pruebas realizadas tuvieron resultados satisfactorios . Esta serie de pruebas demostró que el módulo de cifrado y su interconexión con el microcontrolador funcionan correctamente, cifrando los datos de la manera adecuada en modo CBC. 5.2 PRUEBAS DE LA APLICACIÓN REALIZADA EN VISUAL BASIC La aplicación realizada en Visual Basic es una interfaz entre el usuario y Wi-P.O.S. para poder introducir las configuraciones específicas del dispositivo (Para mayor información remitirse a la sección 4.4.). Para la realización de las pruebas se implementaron los siguientes procesos para determinar si los parámetros fueron correctamente introducidos al dispositivo. En cada uno de ellos se debía tener conectado Wi-P.O.S. a un computador en donde se encontraba cargada la aplicación. La conexión se realiza al puerto serial del computador. 5.2.1.Prueba de carga de llave de transporte y verificación por dígitos de chequeo. Para probar el correcto funcionamiento de la introducción de la llave de transporte se utilizó la función implementada de dígitos de chequeo, la cual se encarga de devolver los 4 primeros caracteres resultantes de cifrar una cadena de ceros con la llave

104 elegida. Para asegurar que el resultado fuese correcto se cifro una cadena de ceros con la misma llave en el servidor de tarjeta criptográfica y se compararon los 4 primeros caracteres resultantes con los obtenidos en el proceso de Dígitos de Chequeo. El proceso en el administrador de Wi-P.O.S. es el siguiente: Se escoge la opción “Enviar Llaves”, luego “Llave de transporte”, luego se introduce la llave y se envía. Al volver al menú principal se escoge la opción “dígitos de chequeo”, donde se selecciona la opción correspondiente a “Llave de transporte” y de esta manera se obtiene la información a comparar con el resultado de la tarjeta criptográfica. (Ver sección 4.4). Algunas de las pruebas se muestran en el Anexo 2, sección de pruebas de funcionamiento de carga de llaves de transporte. Como se puede ver en los resultados, los dígitos de chequeo coinciden con los 4 primeros caracteres del dato cifrado en todas las pruebas. Esto demuestra que la carga de llave de transporte se hace satisfactoriamente. 5.2.2. Prueba de la carga de llaves maestras y verificación por dígitos de chequeo. Esta prueba fue similar a la realizada con la llave de transporte, su única diferencia es que la llave maestra debe ser introducida por partes como se describe en las secciones 1.4.1 y 2.4 , teniendo en cuenta que la llave maestra final es el resultado de la operación XOR entre todas éstas. El proceso de prueba varía en que antes de solicitar los dígitos de chequeo se debe actualizar la llave maestra escogiendo la opción de “Selección de llave maestra” en el menú principal. Los resultados de algunas de las pruebas se describen en el Anexo 2, sección de pruebas de funcionamiento de carga de llaves maestras. De esta manera se comprobó el funcionamiento satisfactorio de la carga de llaves maestras en el equipo haciendo uso de la aplicación en Visual Basic

105 5.2.3. Prueba de Selección de llave maestra. Para la realización de las pruebas se utilizaron los resultados obtenidos en el numeral 3.2.2. La prueba consistía en cargar una llave nueva al sistema, comparar los dígitos de chequeo y luego cargar la anterior llave maestra de la cual también se obtenían los dígitos de chequeo. Para una mayor información acerca de los resultados, favor remítase al anexo 2, sección de selección de llave maestra. 5.2.4. Prueba de carga de número de terminal En el “banco virtual” (Ver sección 5.3) se establecen parámetros iniciales(ver sección 3.3) de acuerdo al número de terminal. La prueba de verificación de la introducción de número de terminal usando la herramienta en Visual Basic consistió en tener 3 tipos de terminales diferentes cada uno con parámetros propios, como por ejemplo, llave de PIN de diferente longitud, valor de IVA y solicitud de propina. Esta información se puede ver más claramente en la TABLA II donde se muestran los valores correspondientes. Esta prueba se encuentra ligada a la sección 5.3.1 ya que las tramas enviadas involucran el número de terminal. 5.2.5. Prueba de la introducción de vector de inicio: Para verificar el funcionamiento de la introducción de vector de inicio se configuró un valor para el vector de inicio en el “Banco virtual”, (Ver sección 5.3) que fue también introducido por el administrador de Wi-P.O.S., las pruebas se pueden consultar en cada uno de las solicitudes hechas en el numeral 5.3. 5.2.6. Prueba de Reinicio de número de consecutivo Reiniciar el consecutivo significa poner seis ceros en el registro de memoria donde se

106 almacena el consecutivo. Como el consecutivo es uno de los parámetro enviados al servidor al momento de realizar una transacción de pago, las pruebas de reinicio de número de consecutivo van ligadas a las pruebas de realización de la transacción de pago descritas en la sección 5.3.2. 5.3. PRUEBAS DE FUNCIONAMIENTO DEL DISPOSITIVO REALIZANDO TRANSACCIONES BANCARIAS: Debido a que el Wi-POS es un prototipo y las políticas de seguridad de VISA sólo permiten el acceso a los proveedores tras un complejo proceso de certificación, se implementó un ambiente de pruebas en donde se simula un banco y tiene las siguientes características: Un servidor con IP pública para tener acceso desde el teléfono Motorola. Una tarjeta criptográfica similar a la utilizada en los procesos de transacciones bancarias. Una base de datos almacenando información correspondiente a varios usuarios del banco virtual. Un software que se encarga de realizar la aprobación o rechazo de las transacciones. Todo este ambiente se desarrolló bajo la asesoría de la empresa ASIC, que es una empresa que ejecuta proyectos con VISA y conoce los procesos de las transacciones bancarias. Es a través de una implementación de dicha entidad que una transacción se podría llevar a cabo con la mensajería que se envía desde Wi-POS (Versecciòn3.3) 5.3.1 Pruebas del proceso de carga de parámetros iniciales: Como se explicó en la sección 3..3, los parámetros iniciales dependen del terminal que los requiere, por esta razón, para verificar que se esté efectuando correctamente el

proceso, se almacenó en la base de datos la información correspondiente a tres números de terminal diferentes con parámetros iniciales distintos y de esta manera se pudieron tener varias opciones en cada parámetro.

En el proceso se envía al servidor la trama denominada “petición de parámetros iniciales” debidamente cifrada, usando el modo CBC del algoritmo DES, con llave de transporte y vector de inicio comunes previamente ingresados en el dispositivo (Ver sección 4.4.2) y en el banco virtual.

El software instalado en el servidor “Banco Virtual”, se encarga de descifrar la trama utilizando la tarjeta criptográfica, luego reconoce el tipo de mensaje (Ver sección 3.3) y si se trata de un mensaje de petición de parámetros iniciales, busca en una tabla de la base de datos la información correspondiente al terminal contenido en el mensaje. Con esta información construye una trama de respuesta de parámetros iniciales, luego la cifra y la envía como respuesta al teléfono móvil.

Los tres terminales ingresados tenían los siguientes datos:

TABLA II. Números de terminal consignados en la base de datos y sus parámetros correspondientes. Para ver que el proceso se estuviera llevando a cabo adecuadamente, se desarrolló una página web en donde se podían ver los mensajes que entraban y salían del “Banco Virtual”, cifrados y en claro.

107

108 En el anexo 2, sección de pruebas de funcionamiento de parámetros iniciales, se muestra en detalle lo sucedido en varias de estas pruebas. Con los resultados obtenidos en estas pruebas se comprobó el buen funcionamiento del equipo en lo que respecta a la construcción y cifrado/descifrado de las tramas y la conexión con el servidor a través de la red iDEN 5.3.2 Pruebas del proceso de transacción de pago con tarjeta crédito o debito. El proceso completo de la transacción de pago depende de los parámetros iniciales cargados previamente y de la tarjeta deslizada. Como se vio en la sección anterior se dispuso de tres tipos de terminal con diferentes parámetros iniciales y además de esto, la base de datos contaba con un registro de usuarios del banco. Para esto, se usaron varias tarjetas crédito y débito, propias de los miembros del grupo. A cada tarjeta se le asignaron distintos parámetros para poder probar diferentes casos en las transacciones. Para realizar este procedimiento, el banco virtual procesa tres tramas diferentes en distintos tiempos para poder validar la transacción, estas tramas son: Trama de solicitud de parámetros de tarjeta, trama de solicitud de llave de PIN y trama de solicitud de transacción de pago (Ver sección 3.3). En el proceso el servidor descifra cada una de estas tramas en el momento que las recibe, valida la información, genera respuestas dependiendo de cada solicitud y finalmente cifra la información para enviarla de nuevo a Wi-POS. Para ver el proceso completo de una transacción el lector puede remitirse al diagrama de flujo 3. Con el banco virtual se puede verificar si el proceso se lleva a cabo satisfactoriamente, si los campos que se le piden al usuario a través de la pantalla del teléfono móvil, son acordes a los parámetros enviados. Para ver la secuencia de pantallas del teléfono móvil, que se debe observar en el proceso de la transacción remítase a la sección 4.3.3. Para observar los resultados de las pruebas de funcionamiento, remítase a las pruebas de funcionamiento de transacciones en el anexo 2.

109 5.3.3. Pruebas con los posibles errores de una transacción de pago. Así como se hicieron pruebas de transacciones satisfactorias se evaluó el funcionamiento del dispositivo ante errores con los siguientes casos: El usuario desliza mal la tarjeta: Caso en el cual el teléfono debe mostrar en pantalla un mensaje de error al leer tarjeta y mostrar al usuario la posibilidad de salir de la aplicación o de continuar. Fecha de vencimiento incorrecta: En el caso de ser solicitada, el usuario ingresa de forma errónea la fecha. Clave incorrecta: Se digita incorrectamente la clave. Por tanto la transacción no se puede realizar y debe mostrarse una pantalla que lo indique. Tipo de cuenta errónea. En el momento en que se muestra la pantalla de seleccionar el tipo de cuenta el usuario elige una cuenta que no tiene registrada en la basa de datos, le transacción debe ser errónea y se debe mostrar la pantalla adecuada. Valor de la transacción superior al cupo de la cuenta. El módulo 10 de la tarjeta es erróneo: Si se desliza una tarjeta cuyo parámetro de módulo 10 está activo y al realizarse el chequeo de módulo 10 éste es erróneo, se debe mostrar una pantalla indicándolo. Estas pruebas se realizaron para saber si el dispositivo funciona correctamente en todos los casos y si muestra todas las pantallas necesarias. Al igual que las pruebas anteriores, estas se realizaron constatando en la página de Internet las tramas enviadas y recibidas por Wi-POS, cifradas y en claro. Los resultados fueron los esperados, demostrando que Wi-POS está enviando las tramas necesarias debidamente cifradas, que está recibiendo, descifrando y almacenando las tramas entrantes, y que además de ello los otros procesos como verificación de fecha de vencimiento, creación y cifrado de la trama de PINBLOCK y lectura de la tarjeta de banda magnética funcionan correctamente. Además que se muestran avisos gráficos en caso de que ocurra

cualquier error, esto es importante ya que asegura que el equipo no está almacenando información errónea.

5.4 ANÁLISIS DE RESULTADOS.

Después de probar todos los aspectos del dispositivo como se describió en las secciones anteriores se encontraron los siguientes aspectos importantes: •

–

– El módulo de cifrado funciona de manera correcta, ya que en ninguna de las pruebas que involucraron cifrado de datos obtuvieron errores. Esto indica que la conexión de la FPGA con la memoria serial (ver sección 4.2) está bien y que el ruido no afecta las señales que interconectan al módulo con el microcontrolador, cosa que si ocurría en el montaje en protoboard. Este aspecto es de gran importancia porque así se garantiza la seguridad de la transacción, lo cual estaba planteado en los objetivos. Esto además asegura que los mensajes enviados y la información almacenada de los mensajes recibidos sea correcta, ya que un pequeño error en el cifrado o descifrado altera totalmente el mensaje en claro.

Las rutinas del microcontrolador (ver sección 4.1.6) se realizan de manera satisfactoria. Todas las tramas son armadas de la manera correcta y la información recopilada y almacenada como estaba previsto.

La aplicación en J2ME corre como estaba esperado mostrando las pantallas necesarias para la realización de la transacción y manteniendo una comunicación con el servidor en donde se envían y reciben las tramas necesarias para llevar a cabo la transacción. Además maneja de manera satisfactoria el dispositivo, es decir mantiene la comunicación indicada con el microcontrolador para que este realice el proceso necesario en el momento requerido.

110

111 – El equipo se encarga de construir de manera correcta las tramas que envían la información necesaria para realizar una transacción bancaria haciendo uso del servidor de ASIC, de esta manera empleando el dispositivo se pueden realizar transacciones bancarias. Con lo que no cuenta el dispositivo es con los permisos necesarios para su uso comercial. Lograr esos permisos y hacer pruebas usando el Tandem de VISA requiere de la firma de un acuerdo comercial como proveedor cuyo primer paso es un proceso de certificación.

Al hacer las pruebas se observó que en la realización de las transacciones hay una demora cuando se recibe información del servidor debido a que el equipo móvil Motorola envía muy lentamente la información por su puerto serial. Este retardo no se debe a la tasa de transmisión del equipo(se uso de 9600bps ver sección 4.1.1) sino a la manera en que se programo el manejo del puerto serial en la aplicación realizada para el teléfono. Esto no afecta los objetivos de éste proyecto pero es un tema que se puede mejorar en un futuro haciendo que la transacción se realice en un tiempo considerablemente más corto.

En ciertas ocasiones se presentaron errores de comunicación en el puerto serial del teléfono debido a que ciertos datos son ingresados muy rápidamente y el teléfono no los recibe de manera adecuada, es por esto que se usa un indicador (LED) que le muestra al usuario cuando el equipo esta listo para recibir la información.

112 5.5 COSTOS DEL PROYECTO

A continuación se presenta una tabla que contiene la información de los costos del proyecto. TABLA III Costos del proyecto

113 Impresora 1 $ 350.000,00 $ 350.000,00 Otros (Resistores, condensadores, 1

Cantidad 5 resmas 6 1 1 2

Cantidad 840 1728 $ 10.000,00

Valor Unidad $ 8.000,00 $ 25.000,00 $ 4.000,00 $ 45.000,00 $ 2.000,00

Valor Unidad $ 161,00 $ 1.100,00 espadines) Total Equipo Papelería Papel Encuadernación Empaste Cartuchos de impresora CD Total Papelería Costos Indirectos Energía Transporte Valor total $ 10.000,00 $ 4.082.600,00 Total $ 40.000,00 $ 150.000,00 $ 4.000,00 $ 45.000,00 $ 4.000,00 $ 243.000,00 Total $ 135.240,00 $ 1.900.800,00 $ 67.525.600,00

6. Conclusiones El trabajo de grado realizado obtuvo como resultado un dispositivo para realización de transacciones bancarias por medio de una red inalámbrica iDEN. Es un dispositivo pequeño, lo que lo hace cómodo de cargar y sencillo de manipular. Su realización involucró desarrollos en hardware y en software y sus objetivos se cumplieron satisfactoriamente. A continuación se presentan una serie de conclusiones surgidas durante la realización del mismo. •

•

• Gracias a la disponibilidad de equipos y herramientas con que se cuentan en el desarrollo de un trabajo de grado, éste abre un espacio en el cual se pueden generar productos innovadores y realizar proyectos complejos que de otro modo serían muy complicados y costosos de llevar a buen término. J2ME demostró ser una poderosa herramienta de fácil manejo para la programación de equipos móviles, lo que hace que proyectos como éste motiven y generen nuevas ideas para desarrollos que involucren el uso de aplicaciones de red y de telefonía móvil. Se utilizó el lenguaje J2ME porque es el lenguaje con el cual se programan los equipos móviles Motorola i85s e i58sr, además por ser un lenguaje fácil de implementar y de gran conocimiento a nivel mundial ya que la comunidad de programadores de J2ME es muy amplia. Las licencias de software de desarrollo para J2ME y para los equipos Motorola son gratuitas y la información sobre actualizaciones e implementaciones de diferentes elementos de este lenguaje son de fácil acceso para todo el mundo. Las herramientas de desarrollo de ALTERA proporcionan facilidad para la realización de algoritmos complejos implementados en hardware. En el caso del dispositivo desarrollado en el trabajo de grado, que requería del cifrado en DES por hardware, permitió su implementación sin mayores inconvenientes ya que la herramienta de desarrollo cuenta con posibilidades de simulación que permiten estar seguros del funcionamiento del programa antes de cargarlo en la FPGA. Para la implementación de DES se manipularon bloques de 64 bits, que en caso de haberse hecho en el microcontrolador hubiera tomado más

114

115 •

•

•

•

• tiempo de desarrollo y hubiera aumentado considerablemente los tiempos de respuesta por la velocidad de procesamiento y por la obligación de manipular datos de 8 bits de longitud. La red iDEN de AVANTEL y sus teléfonos móviles Motorola, permiten el desarrollo e implementación de proyectos que involucran hardware y software, abriendo la posibilidad a la realización de trabajos innovadores que involucran comunicaciones a través de las redes inalámbricas. En el caso de Wi-POS su implementación se puede expandir a otros tipos de redes. El desarrollo de este trabajo de grado permitió implementar de forma integral diferentes áreas de la electrónica lo cual demostró que los conocimientos adquiridos a lo largo de la carrera permiten contar con las herramientas y criterios necesarios para realizar desarrollos innovadores y útiles. Conceptos de áreas como Transmisión de Datos, Integración de Redes y el manejo de Sistemas Digitales dentro de este proyecto, así como el manejo de diversos lenguajes de programación, permitieron la realización exitosa de este Trabajo de Grado. La ingeniería es una carrera que abre las puertas hacia la riqueza, ya que a partir de un producto creado se puede generar trabajo para muchas personas. Esta afirmación no implica el enriquecimiento de pocas personas sino de aquellas que de una u otra manera se ven afectadas positivamente en el desarrollo, elaboración y comercialización de un producto. Para el diseño y desarrollo de un producto se necesita de la colaboración de expertos en varias áreas, a veces la autonomía intelectual del ingeniero electrónico conlleva a que los proyectos mueran por falta de fuerza en otras áreas del desarrollo del producto. La realización del proyecto hizo notar que los protocolos y estándares de comunicación existentes permiten la integración de distintos módulos con relativa facilidad y esto permite que trabajos como este puedan llegar a implementar con diferentes tipos de dispositivos.

116 7. Bibliografía •

•

• •

• • • • •

• TANENBAUM, Andrew. Redes de computadores. México D.F. Prentice Hall. 1997, 753 p. KEOGH, James. J2ME: The Complete Reference. Berkeley, California: McGraw-Hill, 2002. 745 p. BECERRA, Cesar. Los 600 Principales métodos del Java. FEDERAL INFORMATION PROCESSING STANDARDS. Publicación 46-3. Data Encryption Standard (DES). Estados Unidos, 1999. 26 p. (FIPS PUB 46-3). STALLING, William Cryptography and Security http://idenphones.motorola.com/iden, Motorola iDEN. http://java.sun.com/j2me, Lenguaje de Programación J2ME de Java. http://www.geocities.com/45peter/iden.html, How iDEN Works. http://www.iec.csic.es/criptonomicon/articulos/expertos30.html, Seguridad en los Nuevos Medios de Pago. http://www.kanecal.net/mag-stripe-reader-scanner.html, Magnetic Readers. • Magnetic http://www.magtek.com/documentation/public/99800004-1.pdf, Stripe Card Standards. •

• • http://www.valhallalegends.com/docs/magcards.htm, Lectores de Banda Magnética. http://www.altera.com hojas de especificaciones ACEX1k100. Patiño Paola Helena, Rubio Martín Alberto. Diseño e implementacion de encriptore desencriptor triple DES(3DES) en FPGA. Trabajo de grado. Universidad Javeriana, Facultad de Ingenieria, Departamento de electrónica.

117 ANEXO 1 MARCO TEORICO

1.A DES (DATA ENCRYPTION STANDARD):

DES (Data Encryption Standard) es un sistema estándar de uso internacional para convertir datos en secuencias de bits, que carecen de significado, cuando se encuentran en tránsito por un medio de comunicación. Esta información entra a un sistema en el que se codifica de forma binaria mediante algoritmos matemáticos y los procedimientos de cifrado son realizados a partir de una llave que se encarga de cifrar/descifrar los datos. Esta llave es de conocimiento exclusivo del sistema que realiza el proceso.

En 1999 la NIST (National Institute of Standard and Technology) publicó por medio de la FIPS (Federal Information Processing Stardards Publications), la última versión del estándar DES que fue nombrado como el documento FIPS 46-3, en donde se explican los algoritmos matemáticos para el proceso de cifrado y descifrado de información.

Una llave DES tiene una extensión de 64 bits de los cuales 56 bits son utilizados en el proceso de cifrado, los otros 8 pertenecen a la paridad impar de cada bloque de 8 bits. La información sólo es recuperada por medio de la misma llave que fue usada para ser cifrada. Quien posea la información cifrada y conozca el funcionamiento del sistema de cifrado no puede encontrar la información original sin tener conocimiento de la llave de cifrado, a menos que intente determinar la llave por medio de fuerza bruta, es decir, probando todas las llaves posibles.

Introducción al Algoritmo de cifrado DES

118 Este algoritmo está diseñado para cifrar y descifrar bloques de información de 64 bits bajo el control de una llave de 64 bits. El descifrado debe realizarse con la misma llave con que fue cifrado, pero con un orden diferente de las subllaves generadas explicadas más adelante.

Un bloque para ser cifrado es sometido primero a una permutación inicial IP (Ver tabla 1A) en donde el orden de los bits se altera teniendo en cuenta la tabla, luego a una computación compleja dependiente de la llave ingresada y finalmente a una permutación inversa IP-1 (Ver tabla 2A).

La computación realizada sobre la llave es definida en términos de la función f, llamada función de cifrado, además de una función KS, llamada conmutación de llaves.

Cifrado

Un esquema general de proceso de cifrado es visto en la figura 1A.

Los 64 bits de la trama a ser cifrada son primero sometidos a la permutación de la tabla 1A, llamada permutación inicial IP.

Donde el bit 58 de entrada es ahora el primer bit, el bit 50 de entrada es el segundo, así sucesivamente hasta que el bit 7 de entrada sea ahora el último. La salida de esta computación es luego la entrada de la computación compleja dependiente de la llave. Este resultado generado será ahora la entrada de la permutación inicial inversa, que se puede ver en la tabla 2A.

119 FIGURA 1A. Esquema general del proceso de Cifrado

Tabla 1A. IP (Permutación Inicial) Tabla 2A. Permutación Inicial Inversa

Donde el bit 40 de la salida del algoritmo complejo dependiente de la llave es ahora el primer bit, el 8 bit el segundo y así hasta que el bit 25 sea el último.

La computación dependiente de la llave consiste en 16 iteraciones de bloques intercambiados en cada paso, explicados mas adelante, en términos de la función f, la cual opera con una entrada de un bloque de 32 bits y otro bloque de 48 bits, teniendo como salida un bloque de 32 bits.

El bloque de entrada de 64 bits proveniente de la permutación inicial es dividido en 2 bloques de 32 bits, uno llamado L y otro llamado R. La entrada a esta computación se puede definir como LR.

K es un bloque de 48 bits generados por la llave de cifrado, que será explicada más adelante. Por lo tanto el bloque L1R1 de la primera iteración es definido mediante la

120

siguiente función. Donde significa la operación XOR. Para la segunda iteración el bloque de entrada será R1L1 y el bloque K será uno diferente al anterior dependiendo de la llave de cifrado. Con más notaciones podemos describir la iteración con más detalles. Llamemos KS como la función que toma un entero n en el rango de 1 a 16 como entrada además de la llave. Esta función tiene como salida un bloque de 32 bits. Con determinado por las diferentes posiciones de la llave que serán explicados más adelante.

Ahora llamaremos la salida de la permutación inicial el bloque L0R0 de acuerdo al número de la iteración. Por lo tanto en las siguientes funciones tenemos un término más general para todo el proceso de computación compleja. Donde 1 toma los valores entre 1 y 16 según sea la iteración. La salida final de este proceso es el bloque R16L16.

Descifrado:

El proceso de descifrado es similar a los anteriores salvo en el orden de los bloques K ingresados a la función f. En la siguiente ecuación se muestra el cambio de esta ecuación.

121

Donde el orden de K es el inverso al anterior.

Función de cifrado f:

Un esquema del cálculo de la función f(R, K) esta dado en la Figura 2A. FIGURA 2A, Calculo de f(R, K)

E es una función la cual convierte un bloque de entrada de 32 bits en un bloque de salida de 48 bits, mediante la conmutación de bits descritos en la tabla 3A. TABLA 3A. Tabla de expansión E

La salida de la expansión E es operada por medio de una XOR con una subllave de 48

122

123 bits que será explicada mas adelante. Este resultado de 48 bits es luego separado en 8 grupos de 6 bits, con los cuales se introducen en las tablas de sustitución de la siguiente manera, como ejemplo se tomará la primera tabla de sustitución ilustrada en la Tabla 4A. TABLA 4A. Tabla de sustitución S1

Para la tabla de sustitución S1, se debe usar el primer bloque de 6 bits llamado B, donde los bits serán divididos de la siguiente manera, B1B6 representarán la fila de la tabla de sustitución en binario, teniendo como valor mínimo 0 y valor máximo 3, es decir si B1B6 es igual a 10, la fila será la número 2, los bits B2B3B4B5 corresponden a la columna de la tabla de sustitución, teniendo como valor mínimo 0 y valor máximo 15. De esta manera se tiene un punto coordenado en la tabla donde se encuentra un valor en binario entre 0 y 15.

Este proceso se realiza con las demás bloques de 6 bits correspondiéndole a cada uno una tabla de sustitución S. Las tablas de sustitución se encuentran en la Tabla 5A y Tabla 6A.

TABLA 5A. Tablas de Sustitución S1, S2, S3 y S4 TABLA 6A. Tablas de sustitución S5, S6, S7 y S8

Finalmente se concatenan los resultados de todas las tablas de sustitución en un sólo valor. Como cada tabla de sustitución entrega un valor de 4 bits, el resultado final

124

125 tendrá un tamaño de 32 bits. Este valor es sometido a la permutación según se puede ver en la tabla P de la Figura 7A. TABLA 7A Tabla de permutación P

Generación de las subllaves:

Por cada iteración en la computación compleja se genera una subllave, por lo tanto en total se tienen 16. El cálculo de las 16 subllaves esta descrito en el esquema de la Figura 3A.

FIGURA 3A . Cálculo de las 16 subllaves

Este proceso consiste en el paso de la información por dos tablas de permutación PC1 y PC2 y por un corrimiento generado según el número de la iteración.

La tabla de permutación PC1 se encuentra descrita en la tabla 8A. TABLA 8A. Tabla de Permutación PC-1

126

La tabla ha sido dividida en dos grupos donde se describe como se divide la información en dos bloques de 28 bits donde los primeros toman el nombre de C0 y los segundos toman el nombre de D0. Luego, estos bloques son sometidos cada uno a un corrimiento hacia la izquierda según el número de la iteración como lo ilustra la tabla de la Tabla 9A. Tabla 9A. Corrimientos a la izquierda de los bloques Cn y Dn según el número de la iteración.

Finalmente el resultado de la iteración del bloque Cn y Dn es unido formando el bloque CnDn que es pasado por la tabla de permutación PC-2 que se caracteriza porque de 56 bits que le entran salen 48 bits. TABLA 10A. Tabla de permutación PC-2

De esta forma se generan 16 subllaves según la iteración, que serán introducidas en la

127

función f, explicada anteriormente.

Tarjetas De Banda Magnética5.

Una tarjeta de banda magnética es un elemento que almacena información mediante el uso de materiales ferromagnéticos, los cuales tienen la capacidad de almacenar datos en forma de campo magnético. Cada tarjeta de banda magnética puede almacenar información en tres pistas distintas. Cada una de estas pistas se usa para guardar cierto tipo de información como se describe a continuación. •

•

• PISTA 1 (International Air Transport Asociation (IATA)): Posee una densidad de almacenamiento de 210 bits por pulgada. Cada carácter puede ser configurado a partir de 7 bits incluyendo su paridad y puede guardar hasta 79 caracteres alfanuméricos.

PISTA 2 (American Bankers Asociation (ABA)): Tiene una capacidad de almacenamiento de 75 bits por pulgada. Cada carácter puede ser representado a partir de 5 bits incluyendo su paridad y tan sólo puede almacenar 40 caracteres alfanuméricos.

PISTA 3: Puede almacenar 210 bits por pulgada. Sus caracteres son descritos a partir de 5 bits incluyendo la paridad y puede almacenar hasta 107 caracteres alfanuméricos.

Estas tarjetas de banda magnética están definidas por el estándar internacional ISO– 7811 el cual regula los estándares en cuanto al manejo de la información que transportan las tarjetas que usan este tipo de almacenamiento.

A continuación se muestra como esta distribuida la información en la Pista II. 5 Magnetic Readers, < http://www.kanecal.net/mag-stripe-reader-scanner.html>

128

FIGURA 4A. TRAMA DE DATOS DE TARJETAS DE BANDA MAGNÉTICA TIPO PISTA II

Las tarjetas de crédito y débito almacenan información en las Pistas I y II; en la siguiente figura se muestra la distribución de la información en la Pista I. FIGURA 5A. TRAMA DE DATOS DE TARJETAS DE BANDA MAGNÉTICA TIPO PISTA I

Los lectores de banda magnética consisten en dos solenoides, uno que se encarga de inducir corriente a la tarjeta y otro que se encarga de leer los picos de voltaje que se le inducen a la tarjeta. Al tener esta información, el lector se encarga de amplificar la señal y procesarla para poder manipularla fácilmente.

Magnetic Stripe Card Standards,

129

130 FIGURA 6A LECTOR DE BANDA MAGNETICA Bloque de PIN (Personal Identification Number): El bloque de PIN es la forma en que se debe enviar la información del número de cuenta y la clave del usuario cifrada con llave de PIN bajo un estándar. Este bloque tiene una longitud de 64 bits y es usado únicamente en las transacciones bancarias en donde se debe digitar la clave del usuario. El bloque de PIN tambien conocido como PINBLOCK se genera usando una serie de ecuaciones logicas sobre el PIN(clave personal) y el PAN(numero de cuenta) del usuario, este bloque es creado por seguridad . Módulo 10: Es un proceso matemático que se utiliza para verificar si el número de una tarjeta débito o crédito es válida haciendo operaciones con sus dígitos. Primero se mira si la cantidad de números de la tarjeta es par o impar, si es par, el primer número de la tarjeta se multiplica por 2, si no, el primer número de la tarjeta se multiplica por 1. Luego de determinar si es par o impar se multiplican todos los números de la tarjeta alternadamente entre 2 y 1, por lo tanto si es par, se comienza con 2, se sigue con 1, se continúa con 2 y así sucesivamente. Si es impar se comienza con 1 se sigue con 2 y así sucesivamente, si alguno de los dígitos al multiplicarlo da un valor mayor a 9, se debe restarle 9. El proceso se realiza comenzando con el número mas a la derecha.Finalmente se deben sumar todos los valores y el resultado final debe ser un múltiplo de 10 para que el número de la tarjeta sea válido.

131 Tecnología iDEN.

La red iDEN (Integrated Digital Enhanced Network) fue introducida en 1993 por Motorola en Estados Unidos y Japón, y en 1994 mundialmente6. Ésta abrió al mercado una nueva generación de soluciones inalámbricas diseñadas para diferentes estilos de aplicaciones móviles enfocadas a los negocios. Hoy en día los equipos inalámbricos iDEN son utilizados en una gran variedad de ambientes de trabajo así como en telefonía móvil comercial.

Los usuarios de equipos Motorola iDEN están encontrando nuevas aplicaciones y descubriendo soluciones de comunicaciones únicas para hacer que sus negocios evolucionen y crezcan. Por ejemplo, las soluciones Motorola iDEN ofrecen la posibilidad de mantener una conferencia con un gran número de personas con sólo oprimir un botón, eliminando la pérdida de tiempo y el costo de realizar llamadas individuales.

La tecnología iDEN permite a sus usuarios aprovechar las ventajas de las aplicaciones inalámbricas avanzadas con un equipo móvil digital que combina: radio digital de dos vías, teléfono inalámbrico digital, mensajes alfanuméricos y transferencia de datos vía Internet. La tecnología iDEN también ofrece un sistema completo de comunicaciones que incluye comandos de voz, agenda telefónica, correo de voz, Internet y e-mail móviles y módems inalámbricos que permiten recrear virtualmente una oficina en cualquier lugar.

La nueva generación de equipos Motorola incorpora la tecnología J2ME ofreciendo la posibilidad de ejecutar aplicaciones interactivas, desde poderosas herramientas de negocios hasta juegos con alto contenido gráfico. 6 Motorola iDEN, < http://idenphones.motorola.com/iden/application?namespace=main>

132 Transacciones Financieras

Las transacciones financieras son procesadas por redes de Intercambio Financiero compuestas por computadores que en conjunto facilitan la transferencia de fondos en línea. Existen cinco componentes principales que participan en una transacción financiera: Tarjetahabiente, Establecimiento Adquiriente, Switch Bancario, Emisor de Tarjetas y Autorizador de Transacciones, entre los cuales cuatro son los que conforman las redes de Intercambio Financiero: Establecimiento Adquiriente, Switch Bancario, Emisor de Tarjetas y Autorizador de Transacciones. Tarjetahabiente: Es la persona propietaria de la tarjeta débito o crédito Establecimiento Adquiriente: Esta representado por uno o más computadores que están conectados a los cajeros automáticos, Cajas registradoras, dispositivos de Internet Voice Response (IVR) o PC de Comercio Electrónico por Internet de los diferentes establecimientos comerciales, los cuales introducen transacciones financieras a la red. Switch Bancario: Esta representado por uno o más computadores que dirigen las transacciones de múltiples adquirientes al respectivo emisor de tarjetas. Emisor de Tarjetas: Es la institución financiera que tiene una cuenta relacionada con el consumidor. Autorizador de Transacciones: Maneja la validación y autorización de transacciones contra los parámetros definidos por el Emisor de Tarjetas. Puede estar ubicado en el mismo Emisor de tarjetas, el switch bancario o en una Entidad Independiente.

La siguiente figura describe el escenario común del procesamiento de transacciones financieras, con los componentes nombrados anteriormente:

133 ! FIGURA 7A. COMPONENTES DE UNA TRANSACCIÓN BANCARIA

Mensajería ISO8583-BASE24

BASE24, es un lenguaje de comunicación interna que manejan los autorizados de transacciones bancarias. El Administrador de Mensajería ISO 8583/BASE24 maneja el formato de los mensajes y requerimientos a nivel de protocolo de transacciones enviadas y recibidas hacia y desde un servidor del Emisor de Tarjetas, basándose en los archivos de configuración del mismo. Adicionalmente maneja las funciones de almacenamiento y envío de transacciones; y ejecuta requerimientos criptográficos como cifrado/descifrado de PIN y cambio dinámico de llaves de cifrado de PIN.

El Mensaje Externo BASE24 está basado en el mensaje externo estándar desarrollado por la Organización Internacional de Estandarización ISO. Este es un mensaje de longitud y contenido variable que puede ser configurado de formas diferentes, basándose en el tipo de mensaje que está siendo enviado. Los procesos del Administrador de Mensajería ISO 8583/BASE24 son los procesos responsables de traducir Mensajes Externos BASE24 entrantes y salientes, hacia y desde formatos de mensajes internos de productos específicos BASE24. Los procesos del servidor Interfaz BASE24 crean e interpretan mensajes externos de acuerdo a las especificaciones. El Mensaje Externo BASE24 permite a los mensajes entrantes y salientes ser configurados individualmente por un servidor, dependiendo de la información del mensaje que el servidor desea enviar y recibir.

134 " # $% &'&( )* $ + +% , +% " – " – " $ )* FIGURA 8A . ADMINISTRADOR DE MENSAJERÍA ISO8385/BASE24

135 ANEXO 2 RESULTADOS DE ALGUNAS DE LAS PRUEBAS REALIZADAS CON WI-P.O.S. Prueba de Funcionamiento de cifrado/descifrado en DES A continuación se muestran algunos de los resultados obtenidos de el cifrado en DES con WI-P.O.S. Primera prueba (Todos los datos en formato hexadecimal) Dato (en hexadecimal): ABC125463BCAFBD0 Llave de cifrado: AB345623DBCDE129 Dato cifrado usando el módulo: 34DA135BC205154D Dato cifrado usando la tarjeta criptográfica: 34DA135BC205154D. Coincide. Segunda prueba (cifrado) Dato: 15975ACDE455ADE2 Llave: 0123456789ABCDEF Dato cifrado módulo: 1A165D46E7AA37A5 Dato cifrado tarjeta: 1A165D46E7AA37A5. Coincide. Tercera prueba (descifrado) Dato: 987DEF3DEF145ABF Llave: 0133FF569932AB54 Dato descifrado módulo: 9378BC9A8722620D Dato descifrado tarjeta: 9378BC9A8722620D. Coincide. Cuarta prueba (descifrado)

Dato: 62547AB34F5A65E8 Llave: 987654321045ABDE Dato descifrado módulo: 1AC298D759C62FC8 Dato descifrado tarjeta: 1AC298D759C62FC8. Coincide.

Pruebas de Funcionamiento de cifrado en DES en modo CBC

A continuación se muestran los resultados de algunas de las pruebas realizadas con WI-P.O.S. al cifrar y descifrar ciertas tramas, cabe anotar que se realizaron muchas mas pruebas.

Primera Prueba (cifrado)

Dato (en hexadecimal): ABC125463BCAFBD0CE45BCADAC5DE435 Llave de cifrado: AB345623DBCDE129 Vector de inicio: 9378BC9A8722620D Dato cifrado usando el módulo: 69881742C5DC217680FCD24EB9D963BD Dato cifrado usando la tarjeta criptográfica: 69881742C5DC217680FCD24EB9D963BD. Coincide.

Segunda Prueba (cifrado)

Dato (en hexadecimal): 12345AEFD1D2E2FA89ED2A1B1A2E3E5A2D2E1A1D24AB1234 Llave de cifrado: 12345AB56E3E2E1F Vector de inicio: E7D845D4E67C6EFD Dato cifrado usando el módulo: : 80F6253A35E6075864AADB9A3716BC9F3F259789BE0600C2 Dato cifrado usando la tarjeta criptográfica: Coincide. 80F6253A35E6075864AADB9A3716BC9F3F259789BE0600C2.

Tercera Prueba (descifrado)

136

Dato (en hexadecimal): CADE123E45E67EAFE781231256875423 Llave de cifrado: 1AB3CDEF56ED4DE3 Vector de inicio: E5DC76456EDC4565 Dato cifrado usando el módulo: 043C8A19F711D522121C9F432B4A5E74 Dato cifrado usando la tarjeta criptográfica: 043C8A19F711D522121C9F432B4A5E74. Coincide.

Cuarta Prueba (descifrado)

Dato (en hexadecimal):ABC125463BCAFBD05ABCD3547CDFEC4DE7D845D4E67C6EFDEA Llave de cifrado: 12DEFEEE54541BCD Vector de inicio: 1AB3CDEF56ED4DE3 Dato cifrado usando el módulo: 9C0157C8F82030E76F397E30C8EF228544626EC1C8053C9F Dato cifrado usando la tarjeta criptográfica: 9C0157C8F82030E76F397E30C8EF228544626EC1C8053C9F. Coincide. Prueba de funcionamiento de carga de llave de transporte y verificación por dígitos de chequeo

A continuación se muestran las pruebas realizadas al cargar diferentes llaves de transporte en WI-POS, por medio de la aplicación realizada en Visual Basic y luego verificadas con la opción de dígitos de chequeo.

Primera Prueba:

Llave de cifrado: 0123456789ABCDEF Dato cifrado usando tarjeta criptográfica: D5D44FF720683D0D Dígitos de chequeo obtenidos de la herramienta en Visual Basic: D5D4. Coincide.

Segunda Prueba:

137

138 Llave de cifrado: FEDCBA9876543210 Dato cifrado usando tarjeta criptográfica: A68CDCA90C9021F9 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: A68C. Coincide. Tercera Prueba: Llave de cifrado: 9876543210987654 Dato cifrado usando tarjeta criptográfica: DF998E5C01B982C9 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: DF99. Coincide. Prueba de funcionamiento de carga de llave maestra y verificación por dígitos de chequeo Las siguientes pruebas describen los resultados del ingreso de las llaves maestras por medio de la aplicación en Visual Basic y su verificación con los dígitos de chequeo. Prueba con una sola llave maestra: Número de llaves maestras introducidas: 1 Llave maestra 1: 1237894561237894 XOR de Llave maestra: 1237894561237894 Dato cifrado usando tarjeta criptográfica: F027F940D5A45D93 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: F027. Coincide. Prueba con dos llaves maestras: Número de llaves maestras introducidas: 2 Llave maestra 1: ACDEF65432FE7891 Llave maestra 2: 001599884411223312 XOR de Llave maestra: B9477E1023DC4B83

139 Dato cifrado usando tarjeta criptográfica: E63A3D454FD9CDE0 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: E63A. Coincide. Prueba con tres llaves maestras: Número de llaves maestras introducidas: 3 Llave maestra 1: A1D5E6B478CCBB0 Llave maestra 2: F896321475FACDEF Llave maestra 3: 558899665544212358 XOR de Llave maestra: A703F5196732277C Dato cifrado usando tarjeta criptográfica: 23C13EA287C14ECA Dígitos de chequeo obtenidos de la herramienta en Visual Basic: 23C1. Coincide. Pruebas de selección de llave maestra A continuación se ilustran los resultados obtenidos al seleccionar la llave maestra, verificando con los dígitos de chequeo. Primera prueba de selección de llave maestra Llave maestra anterior: 1237894561237894 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: F027 Llave maestra nueva 1: ACDEF65432FE7891 Llave maestra nueva 2: 001599884411223312 XOR de Llave maestra nueva: B9477E1023DC4B83 Se actualiza la llave maestra. Dígitos de chequeo obtenidos de la herramienta en Visual Basic: E63A Se selecciona de nuevo la llave maestra anterior y se solicitan los dígitos de chequeo: F027

140 Segunda prueba de selección de llave maestra

Llave maestra anterior: B9477E1023DC4B83 Dígitos de chequeo obtenidos de la herramienta en Visual Basic: E63A Llave maestra 1: A1D5E6B478CCBB0 Llave maestra 2: F896321475FACDEF Llave maestra 3: 558899665544212358 XOR de Llave maestra: A703F5196732277C Se actualiza la llave maestra. Dígitos de chequeo obtenidos de la herramienta en Visual Basic: 23C1

Se selecciona de nuevo la llave maestra anterior y se solicitan los dígitos de chequeo: E63A. Con esto se comprobó que tanto la aplicación realizada en Visual Basic como el microcontrolador funcionan correctamente en lo que respecta a selección de llave maestra.

Pruebas de funcionamiento de carga de parámetros iniciales

Para cada una de estas pruebas se usó una llave de transporte diferente y un vector de inicio diferente (cargados en Wi_POS y en el “Banco Virtual”). A continuación se observan los números de terminal consignados en la base de datos y sus parámetros correspondientes.

Tabla 1B. Información asociada a los números de los terminales.

141 Los campos de tipo de mensaje han sido alterados ya que esta información es confidencial. Todas las tramas se encuentran explicadas en detalle en la sección 3.3 para entender los campos que las componen remitirse a esa sección. Las tramas se rellenan con el carácter F para que sean múltiplo de 64 bits y puedan ser cifradas.

i) Prueba con el número de terminal 12345678 El proceso se realizó satisfactoriamente y esto se comprobó pidiendo los parámetros iniciales usando las rutinas del microcontrolador desarrolladas para ello (Ver sección 4.1.5).

El tiempo que se tardó en efectuar el proceso fue de 32.42s. Este tiempo es medido desde el momento en que se ingresa a la aplicación en el teléfono hasta que aparece la pantalla de carga de parámetros exitosa (Fig. 23, Cap4). Para la ver la secuencia de carga de parámetros en la aplicación de J2ME vea la sección (4.3.3.)

ii) Prueba con el número de terminal 87654321 Trama cifrada enviada desde Wi-POS al Banco 39338F0332DC0601AB31D8D21B2748B7

El proceso fue satisfactorio y tardó 30.01s.

iii) Prueba con el número de terminal 13482579 El proceso fue exitoso y se llevó a cabo en 29.01s

iv) Prueba con llaves de transporte diferentes.

La siguiente prueba se realizó con llaves de transporte erróneas, es decir una llave de transporte en el Wi-POS y otra diferente en el servidor con el fin de observar si la aplicación en J2ME y el microcontrolador funcionan bien en caso de error, es decir si despliegan la pantalla correspondiente al caso. La prueba demostró que al descifrar incorrectamente la trama en el servidor, se devolvió como respuesta una trama que el

142

143 microcontrolador no entendió, de manera que en pantalla apareció que la trama recibida era errónea, como era de esperarse.

v) Prueba con número de terminal no registrado.

Se realizó una prueba más para verificar si se despliega la pantalla correspondiente a un error en los mensajes. Como el número de terminal no estaba registrado se devolvió una trama errónea, de manera que apareció una pantalla indicando lo sucedido, tal como era esperado.

Pruebas de funcionamiento de transacciones

Los parámetros para los usuarios ingresados en la base de datos fueron los siguientes:

Tabla 2B. Usuarios ingresados en la base de datos y sus correspondientes parámetros.

144 Tabla 3B. Parámetros de cuenta de los usuarios Como el proceso de transacción también depende de los parámetros iniciales, las pruebas se hicieron con distintos números de terminal. A continuación se muestran unas pocas pruebas.

i). Prueba de transacción satisfactoria, con el usuario 1, con el terminal 1.

Para que el proceso fuera satisfactorio se tuvo cuidado de no excederse en el valor y de ingresar correctamente la clave. Se realizó una transacción por 12.000 pesos y se dio una propina de 500 pesos, se digitó correctamente la clave y como tramas enviadas y recibidas al banco virtual se tuvieron las tramas mostradas en la tabla III

A continuación se muestra la trama enviada con la solicitud de parámetros de tarjeta (Para ver los campos específicos de esta trama remitirse a la sección 1.3), donde por cuestiones de seguridad se ha cambiado el número de la tarjeta usada. Nótese que en esta trama se solicitan los parámetros específicos de la tarjeta y como respuesta se reciben los valores consignados en la Tabla III para el “Usuario 1”, indicando que se debe mostrar el ingreso de tipo de cuenta, se debe pedir el PIN del usuario y se debe imprimir el comprobante.

Debido a que el parámetro de PIN está habilitado, se debe solicitar una llave de cifrado de PIN al Banco Virtual, por lo que se construye la trama de solicitud de llave de PIN (Esta trama se explica con detalles en la sección 3.3), a continuación se muestran los resultados de esta solicitud. Después de esto Wi-POS pidió a través de la pantalla del teléfono los campos correctos y fueron ingresados de manera correcta. Con la información ya recopilada se armó la trama de solicitud de transacción de pago (esta trama se encuentra descrita en la sección 3.3), a continuación se muestran los resultados.

145

146 La transacción se llevó a cabo satisfactoriamente mostrando la información correcta en el equipo Motorola. Se puede ver que los mensajes enviados fueron los correctos y que se transmitieron debidamente cifrados Al mismo tiempo en el banco virtual se realizó el descuento de la cuenta. La transacción fue hecha por un valor de 12.000 pesos, en la cuenta se tenía un cupo de 100.000, se entregó una propina por 500 pesos, quedando como cupo final un valor de 87.500 pesos. ii). Prueba de transacción satisfactoria, con el usuario 2, con el terminal 2. A continuación se muestra una transacción con una tarjeta de crédito, en donde no se

147 pide al usuario que ingrese el PIN, por lo tanto la solicitud de llave de PIN no es enviada al Banco Virtual.

En la siguiente tabla se muestran las tramas de solicitud de parámetros de tarjeta Después de esto se envía la solicitud de transacción que se muestra a continuación:

148 Los resultados de la transacción fueron satisfactorios y se confirmaron al observar en la tabla de base de datos el descuento al cupo del usuario. Y al analizar las tramas enviadas y recibidas y concluir que eran correctas.

iii). Prueba de transacción satisfactoria, con el usuario 3, con el terminal 3.

Esta prueba de transacción fue realizada con una tarjeta de crédito a la que se le pedía PIN y todos los demás parámetros. A diferencia de los demás terminales, este pide como PIN un número de 5 dígitos.

Primero se pide la trama de solicitud de parámetros de tarjeta, que se muestra en la siguiente tabla.

149 Debido a que entre sus parámetros de tarjeta estaba explícito la solicitud del PIN, se realiza a continuación una solicitud de PIN. Después de ingresar los valores solicitados se envía la trama de solicitud de transacción bancaria.

150 La transacción se llevó a cabo de manera correcta y las pantallas mostradas por el teléfono fueron las adecuadas.

De manera similar se hicieron otras pruebas satisfactorias mostrando que el equipo funciona de acuerdo a lo requerido. En algunas de estas pruebas se presentaron errores de comunicación por el puerto serial del teléfono, mostrándose así, la pantalla apropiada para cada caso (Ver sección 4.3).