Dispositivo electronico para la realización de transacciones bancarias por medio de una red inalámbrica iDEN (página 3)
de carga de parámetros se
da algún error en la comunicación entre el
teléfono móvil y Wi – POS, 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
Wi – POS. Después de la tercera vez, se le
informa al usuario que la carga de parámetros
no es posible en el momento. Estos errores
pueden ocurrir si el dispositivo no está
conectado de la forma correcta al teléfono
móvil.
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).
 Página anterior | Volver al principio del trabajo | Página siguiente  |