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

Partes: 1, 2, 3

e le
además le provea comunicación al usuario final.

Para el desarrollo de este proyecto, la red de datos que se utiliza es la red iDEN,
desarrollada por Motorola e implementada en Colombia por la compañía Avantel
S.A. la cual ofrece diferentes tipos de servicios dentro de los cuales están:
comunicación vía radio, acceso telefónico, mensajes de texto y transmisión de datos.

18
2. OBJETIVOS

Objetivo General: Desarrollar un dispositivo electrónico que, conectado a un
teléfono móvil iDEN, sea capaz de realizar una transacción bancaria segura.

Objetivos específicos:
•

•

•
Implementar una aplicación en J2ME y un dispositivo electrónico compatible
con el equipo Motorola iDEN modelo i85s o i58sr, para realizar una
transacción bancaria con tarjetas débito y crédito.
Desarrollar una aplicación en J2ME para interactuar con el dispositivo
electrónico a través del puerto serial del teléfono móvil Motorola.
Aplicar la correspondiente mensajería entre el teléfono móvil Motorola y el
servidor encargado de aceptar las transacciones bancarias para el éxito de ésta,
asegurando la confidencialidad y la integridad de la información.

3. ESPECIFICACIONES DEL DISPOSITIVO

El dispositivo, que de ahora en adelante también denominaremos WI-P.O.S (Wireless
Point of Sales, Punto de ventas Inalámbrico), consiste en un desarrollo que involucra
la comunicación del dispositivo con un servidor, programación de un teléfono móvil
MOTOROLA, manejo de periféricos necesarios para la realización de una
transacción bancaria y cifrado de la información para asegurar la confidencialidad de
ésta. Todo esto es realizado bajo diferentes esquemas de implementación, utilizando
desarrollos en Hardware, Software y Firmware.
FIGURA 1. ESQUEMA GENERAL DE TRANSACCIÓN CON SERVIDOR DE VISA

En la Figura 1 se puede observar un esquema sencillo para la realización de una
transacción bancaria a partir de WI-P.O.S. El equipo recibe la información ingresada
por el usuario, que depende del tipo de transacción que vaya a realizar, y construye

19

Tandem es un nodo en donde se conectan los servidores de los Bancos, y es en estos donde se valida
ASIC, Empresa desarrolladora de aplicaciones en hardware y software, orientada al sector financiero.
20
las tramas necesarias que luego envía al teléfono móvil para que éste se comunique a
través de la red iDEN (ver Anexo Marco Teórico) con un servidor llamado AS400 (es
un servidor con tarjeta criptográfica, esta es una tarjeta capaz de realizar funciones de
cifrado, entre las cuales se encuentra la posibilidad de cifrar con el algoritmo DES))
que después se comunicará con el Tandem1 de VISA y esperará respuesta de la
aprobación de la transacción. Este proceso se realiza por que el protocolo que maneja
las transacciones (Base 24 ver Anexo Marco Teórico) es muy robusto y sería
necesaria una gran cantidad de procesamiento en el equipo que incrementaría en gran
medida los costos y la complejidad del desarrollo. De manera que existe una
aplicación desarrollada por una empresa colombiana (ASIC)2 que recibe cierta
información que es recopilada en el P.O.S. (Point of sales, Punto de Ventas) y
haciendo uso de esta construye las tramas correspondientes al protocolo Base24 (Ver
sección 3.3). En la siguiente sección se presentará un esquema detallado de la
realización de una transacción de pago ya sea con tarjeta débito o crédito.
3.1. DIAGRAMAS DE FLUJO DE LOS PROCESOS NECESARIOS PARA
LLEVAR A CABO UNA TRANSACCIÓN DE PAGO CON TARJETA CRÉDITO
O DÉBITO USANDO WI-P.O.S.
3.1.1. Diagrama de proceso para guardar llaves de cifrado y terminal.
Por cuestiones de seguridad toda la información introducida por el usuario al
dispositivo es cifrada usando el algoritmo DES (Data Encryption Standard) (ver
Anexo Marco Teórico). Por lo tanto, previo a la realización de cualquier transacción,
WI-P.O.S debe tener almacenadas una llave maestra y una llave de transporte (Ver
Sección 3.4). Las llaves se cargan conectando WI-P.O.S al puerto serial de un
computador y por medio de una aplicación realizada en Visual Basic, estas se
guardan en la memoria EEPROM del dispositivo. La llave maestra se usa para cifrar
las otras llaves y almacenarlas de manera segura. La llave de transporte se usa para
1
la transacción.
2

cifrar cualquier información que se transmita al servidor durante la transacción.

Cada dispositivo debe tener un número que lo identifique, es por esto que también se
debe cargar un número de terminal. El número de terminal es representado por 8
caracteres.
A continuación se ilustra el diagrama de flujo de la aplicación realizada en Visual
Basic:
DIAGRAMA DE FLUJO 1
Aplicación de Visual Basic, Administrador de Herramientas para WI-P.O.S Parte 1

21

22
DIAGRAMA DE FLUJO 2
Aplicación de Visual Basic, Administrador de Herramientas para WI-P.O.S Parte 2

23
Esta aplicación realiza 5 funciones principales que son cargar las llaves en el
dispositivo, cargar su correspondiente número de terminal, y realizar la operación de
verificación de dígitos de chequeo.
i)

ii)

iii)

iv)

v)
Cargar las llaves: Es un proceso que permite introducir las llaves maestras
o la llave de transporte al dispositivo desde el computador. Para evitar que
se ingresen valores erróneos el proceso es redundante, es decir, se ingresa
dos veces la información de las llaves, además se verifican otros datos
como el tamaño de la llave, que tiene que ser exactamente de 16
caracteres, tomando valores hexadecimales (0-F).
Cargar número de terminal: Es un proceso que sirve para introducir el
número de terminal del dispositivo. Este valor debe ser único por cada
uno, ya que es quien lo identifica. Al igual que el proceso anterior, la
información se debe ingresar dos veces para evitar que se introduzcan
valores erróneos y su tamaño debe ser de 8 dígitos.
Dígitos de chequeo: Es un proceso necesario para saber si las llaves
ingresadas son correctas. Consiste en el cifrado de ceros con la llave
seleccionada, ya sea maestra o transporte, de esta forma la aplicación
muestra los 4 primeros valores de la operación y se verifica si son
correctos.
Cargar Vector de Inicio: Este proceso consiste en cargar el vector de inicio
en el dispositivo, tiene una longitud de 16 caracteres en hexadecimal, este
valor es indispensable para el correcto cifrado de la información en modo
CBC, proceso que será explicado en los siguientes capítulos.
Reinicio de consecutivo: Es un proceso por el cual a un dispositivo Wi-
P.O.S. se le asigna el valor de consecutivo en ceros, que identifica las
transacciones.

3.1.2
Diagrama de flujo de carga de parámetros iniciales
Diagrama de flujo 3. Petición de parámetros iniciales

Además de tener las llaves almacenadas, WI-P.O.S debe haber cargado (guardado en
memoria) unos parámetros iniciales que obtiene de una conexión con el servidor. Esto
último se debe hacer cada vez que se encienda el equipo. En caso de que alguno de
estos pasos no se haya realizado, es decir si no se han cargado las llaves (de
transporte y maestra) y/o no se han cargado los parámetros iniciales, no se podrá
llevar a cabo la transacción. Por esto cada vez que se va a realizar una transacción el
equipo verifica que estos datos estén almacenados en el dispositivo y envía al
teléfono un mensaje de confirmación.

Para cargar los parámetros iniciales se debe correr una aplicación en J2ME cada vez
que se enciende el equipo, de manera que WI-P.O.S arma la trama denominada
“petición de parámetros inicial” (Ver sección 3.3) y la cifra usando la llave de
transporte para enviarla al servidor. Este devuelve una trama de parámetros iniciales
los cuales se descifran y se almacenan en la memoria del dispositivo. Estos
parámetros iniciales incluyen el porcentaje de IVA, solicitud de propina, dígitos a
ingresar (para la clave) y el nombre del emisor. Estos dependen del terminal que hace

24

25
la petición. (Ver sección 3.3).
3.1.3
Diagrama de flujo de la realización de una transacción de pago con tarjeta
edito o débito:

26

27
DIAGRAMA DE FLUJO 4
Transacción de Pago con tarjeta débito o crédito

28
Después de verificar que los parámetros iniciales estén cargados, por medio de la
pantalla del teléfono se le pide al usuario deslizar la tarjeta. WI-P.O.S recibe la
información de la tarjeta y arma una trama denominada “petición de parámetros de
tarjeta”. Esta trama se cifra y por medio del teléfono móvil se envía al servidor, el
cual devuelve los parámetros de la tarjeta (Ver sección 3.3) que se almacenan en el
dispositivo. Después de esto se verifica con los parámetros de tarjeta recibidos del
servidor si es necesario el ingreso de PIN (Personal Identification Number) o clave
personal, y de serlo así, arma una trama denominada “petición de llave de cifrado de
PIN” la cifra y la envía al servidor el cual devuelve la llave que luego se almacena en
WI-P.O.S. Esta llave sirve para cifrar el PIN Block (Ver sección 3.3) que es una trama
que se construye haciendo uso del PIN y del PAN (Personal Account Number,
Número de Cuenta). Además de ser necesario, el equipo deberá verificar la fecha de
vencimiento de la tarjeta, y compararla con la fecha ingresada por el usuario al
equipo, o con la fecha del sistema.

Luego el dispositivo, según los parámetros de tarjeta recibidos, pide al usuario los
campos correspondientes (valor, cuotas, tipo de cuenta entre otros), arma una trama
denominada “pago con tarjeta”, la cifra, la envía al servidor, y espera respuesta.

Cabe anotar que durante el proceso de la transacción, todas las tramas enviadas y
recibidas del servidor van debidamente cifradas usando el algoritmo DES para
garantizar la seguridad y confidencialidad de la información que se transmite en
ambas direcciones, desde el teléfono y hacia el teléfono.

WI-P.O.S también es capaz de generar transacciones de reverso (ver sección 3.3),
esto en caso que nunca se encuentre respuesta o que se genere algún error durante la
realización de la transacción. Por ejemplo si en el momento de realizar una
transacción ésta fue aceptada pero el mensaje de respuesta no llegó nunca al teléfono
móvil. Al no obtener respuesta en el P.O.S. del resultado de la transacción se debe
generar un reverso que anulará la correspondiente transacción. (Ver sección 3.3).

29
3.2
ESPECIFICACIONES DE WI-P.O.S.
WI-P.O.S es un dispositivo que posee los elementos necesarios para la realización de
una transacción de pago con tarjeta débito o crédito. Estos elementos son: un lector de
tarjetas de banda magnética, un teclado (para el ingreso del valor de la transacción,
PIN, número de cuotas, etc.), un módulo de cifrado DES, un puerto serial y una salida
para impresora. El dispositivo tiene una comunicación constante con el teléfono
móvil, quien es el que le envía las instrucciones según la implementación de su
programa a partir de los módulos y clases en J2ME, desarrollados como parte del
trabajo. Además de guiar la transacción, el teléfono móvil tiene el muy importante
papel de enviar la información al servidor.

3.2.1 Entradas y salidas del dispositivo

Entradas del dispositivo
–
–
–
Lector de Banda magnética
Teclado de 4 Filas x 3 Columnas
Entrada serial usando el estándar RS-232
o Conector DB9.

Salidas del dispositivo
–
–
Salida serial por estándar RS-232 conector DB9
Salida conector DB9 para impresora.
A continuación se mostrará un esquema de las entradas y salidas de WI-P.O.S:

FIGURA 2. ESQUEMA DE ENTRADAS Y SALIDAS DE WI-P.O.S

En la Figura 2 se pueden observar las diferentes entradas y salidas que tiene WI-
P.O.S, por medio de las cuales se establece la comunicación, explicada en las
siguientes secciones
•

•
COMUNICACIÓN CON EL USUARIO: El usuario sólo puede interactuar
con WI-P.O.S deslizando la tarjeta de banda magnética por el correspondiente
lector y digitando la información solicitada según la instrucción desplegada en
la pantalla del teléfono. WI-P.O.S tiene su propio teclado debido a que de esta
forma la información digitada no pasa directamente por el teléfono móvil y no
se corre el riesgo que se pueda almacenar en éste sino que toda la información
se cifra y se guarda directamente en WI-P.O.S, evitando problemas de
retención de información, haciendo que la transacción sea más segura. El
usuario también tiene derecho a adquirir el comprobante de su transacción
bancaria por medio de una pequeña impresora que se conecta al equipo.

COMUNICACIÓN CON TELÉFONO MÓVIL: El teléfono móvil se conecta
al puerto serial de WI-P.O.S y es quien “dirige” la transacción, ya que él es
quien envía la instrucción correspondiente a la operación desplegada en

30

•

3.2.2
pantalla. Por ejemplo, en el momento que se solicite digitar la clave, el
teléfono mostrará una pantalla para que el usuario la digite, al mismo tiempo
enviará la instrucción a WI-P.O.S para que se prepare a recibir la
correspondiente información del teclado y luego manipularla. Es decir que
para cada una de las fases de la transacción, el teléfono móvil muestra en la
pantalla lo que el usuario debe realizar y a la vez enviará las instrucciones a
WI-P.O.S para que éste entre a la rutina correspondiente.

INGRESO DE LLAVES: Para el ingreso de las llaves Maestra y de
Transporte se debe conectar el WI-P.O.S con el puerto serial de un
computador y haciendo uso de la aplicación desarrollada en Visual Basic
almacenar estas en la memoria EEPROM del microcontrolador, debidamente
cifradas.

Componentes del dispositivo
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Microcontrolador PIC18F452
Integrado MAX 232
Integrado 74C422N (Manejador del teclado)
Integrado 74LS125
Integrado LM555
Cristal de 4.9152 MHZ
FPGA Altera ACEX1K50TI144-2
Memoria Serial Altera EPC2LC20
Oscilador con cristal de 1MHz
Regulador LM1117DT-2.5
Regulador LM1117DT-3.3
Resistores
Condensadores
2 leds
Interruptor
Lector de Tarjetas de banda magnética Omron V3A

31

–
Teclado de 4filas x 3columnas
3.2.3. Módulos del dispositivo:

El dispositivo cuenta con tres módulos que se listan a continuación, luego serán
explicados.
–
–
–
Modulo de manejo de periféricos
Modulo de cifrado en DES
Desarrollo de Software. Aplicaciones en J2ME y Visual Basic.
•
Modulo de manejo de periféricos
El módulo de manejo de periféricos consiste de un microcontrolador PIC 18F452 que
se encarga de manejar la comunicación, con el teléfono móvil, con la impresora, con
el módulo de cifrado y además recoge la información del lector de banda magnética y
del teclado. Este se encarga de almacenar toda la información, y de armar las tramas
correspondientes a la transacción.
•
Módulo de cifrado en DES
Este es un cifrador/descifrador en hardware (implementado en una FPGA) que
permite manejar información de una manera confiable. Este trabaja con el estándar de
cifrado DES (ver Anexo Marco Teórico) que utiliza una llave de 64 bits. Este realiza
el cifrado/descifrado en bloques de 64 bits. La información se recibe y se envía
serialmente usando una interfase de puerto serial y trabajando como esclavo. Es decir
que sólo envía la información cuando le es solicitada por otro. Tiene un bit de
selección de funcionamiento (cifrar/descifrar).
•
Desarrollo de Software
El teléfono móvil es la interfaz visual con el usuario para la realización de la
transacción, por tanto éste establece una comunicación con WI-P.O.S indicándole los
pasos a seguir, además informa al usuario las acciones que debe realizar. Por esto fue
necesario desarrollar tres aplicaciones: la primera para la petición de los parámetros

32

33
iniciales, la segunda para la realización de un pago y la tercera para reversar una
transacción. Este es un programa (Software) que denominamos “driver” por que es el
que maneja el dispositivo; éste programa incluye todos los pasos y pantallas
necesarias para la transacción. Este Software debe ser instalado en el teléfono móvil
antes de usar WI-P.O.S, por tanto es necesario que el teléfono móvil a usar pueda ser
programado usando J2ME. Además se desarrolló una aplicación en Visual Basic que
permite introducir las llaves y el número de terminal, para que sean almacenadas en
WI-P.O.S.

3.3 PROTOCOLO DE MENSAJES PARA REALIZACIÓN DE LA
TRANSACCIÓN.

El desarrollo realizado usa como puente un servidor para la realización de la
transacción, este tiene una aplicación implementada por ASIC, y se encarga de recibir
ciertos datos del P.O.S y de construir las tramas correspondientes al protocolo de
Base 24 (ver Anexo Marco Teórico). Esto permite que el procesamiento de datos se
reduzca en el punto de ventas ya que el protocolo de Base 24 es bastante robusto y
maneja tramas grandes y complejas. De manera que el equipo desarrollado (WI-
P.O.S) tiene comunicación directa con el servidor AS400 y este último es quien se
encarga de conectarse con el Tandem de VISA.

A continuación se mencionarán los mensajes que se deben construir en el equipo,
para luego enviarlos al servidor AS400 y así poder llevar a buen término la
transacción. Todos estos mensajes se transmiten debidamente cifrados con la llave de
transporte. Los primeros dos bytes de todos los mensajes se denominan tipo de
mensaje y son estos los que identifican el mensaje que se envía o que se recibe. A
continuación se presentarán los mensajes, con una breve descripción y los campos
que los componen.

3.3.1. Solicitud de parámetros iniciales:

Esta trama se debe enviar al servidor cada vez que se prende el equipo, con el fin de
obtener del servidor una serie de parámetros que dependen del tipo de terminal, del
propietario del equipo y de la zona de uso.

La trama tiene los siguientes campos:
i)

ii)
Tipo de mensaje: Dos bytes que identifican el mensaje, estos son
de tipo char.

Terminal: Es un código que identifica cada uno de los equipos
(datáfonos), éste consiste de 8 bytes de tipo char.

3.3.2. Respuesta de parámetros iniciales:

ésta respuesta debe ser enviada por el servidor inmediatamente después de recibir la
trama de petición de parámetros iniciales. Consiste de los siguientes campos.
i)

ii)

iii)

iv)
Tipo de mensaje: 2 bytes de tipo char

Terminal: Debe transmitir el número de terminal del equipo que
envió la solicitud, de ésta manera se puede comprobar en el P.O.S
si el mensaje recibido es correcto.

Porcentaje de IVA: Esta compuesto por dos datos de tipo
numérico, cada uno de 1 byte.

Solicitud Propina: es un carácter que indica si se debe o no pedir la
propina en el equipo.

34

v)

vi)

vii)
Numero de dígitos a ingresar: Este campo compuesto por dos datos
numéricos indica la cantidad de dígitos que se deben ingresar al
pedir el PIN.

Base devolución de IVA: es un carácter que indica si debe o no
viajar la base de devolución de IVA en el momento de hacer la
petición de transacción de pago.

Nombre del Emisor: Es un campo de 10 caracteres que contiene el
nombre de la entidad que presta el servicio.(ej: Visa)

3.3.3. Solicitud de parámetros de tarjeta:

Esta trama se transmite al servidor después de que se ha deslizado correctamente la
tarjeta en el lector. Se hace con el fin de recibir una serie de parámetros que dependen
de la tarjeta deslizada. Sus campos son:

i) Tipo de Mensaje.

ii) Número de terminal.

iii) Número de la tarjeta: Este campo incluye los datos obtenidos de la
Pista 2 de la banda magnética de la tarjeta (Ver Anexo Marco Teórico).
Son 19 bytes de tipo char.

3.3.4. Respuesta de parámetros de tarjeta:

Es la trama que transmite el servidor como respuesta a la petición de parámetros de
tarjeta y que incluye los siguientes campos:

i) Tipo de Mensaje.

35

36
ii) Número de Terminal
iii) Número de la tarjeta: Se transmite de vuelta el número de la tarjeta
para corroborar que los parámetros si correspondan a esa tarjeta.
iv) Validación fecha de vencimiento1: Es un carácter (de 1 byte) que
indica si se debe o no solicitar al usuario que ingrese la fecha de
vencimiento de la tarjeta, para corroborar con lo leído en la PISTA2.
v) PIN para tarjetas de crédito: Es un carácter que indica si se debe o no
solicitar PIN con esa tarjeta de crédito.
vi) Solicitud de tipo de cuenta: Es un carácter que indica si se debe
solicitar al usuario el tipo de cuenta.
vii) Validación fecha de vencimiento: Es un carácter que indica si se debe
validar localmente o no la fecha de vencimiento obtenida de la PISTA2
con la fecha del sistema.
viii) Impresión Recibo: Este carácter indica si se debe o no imprimir el
recibo de Credibanco.
ix) Módulo 10: Un carácter que indica si se le debe hacer la validación de
módulo 10 al número de cuenta de la tarjeta (ver Anexo Marco Teórico)
x) Solicitud de cuotas: Es un carácter que indica si se debe o no solicitar
un número de cuotas
xi) Solicitud de PIN: Este carácter indica si se debe pedir PIN para tarjetas
débito.

3.3.5
Solicitud de transacción de pago:
Es la trama que se debe construir después de haber solicitado todos los datos
necesarios. Contiene los siguientes campos:

i) Tipo de Mensaje

ii) Número de terminal

iii) Consecutivo: Este es un número compuesto por seis datos de tipo
numérico (cada uno de un Byte) que identifica cada transacción. Este
número se debe aumentar cada vez que se realiza una transacción. Este
dato se encuentra almacenado en memoria EEPROM.

iv) PISTAII: Se debe enviar toda la información del PISTAII de la tarjeta
deslizada. Tiene una longitud de 37 caracteres (cada uno representado por
un Byte)

v) PISTAI: Si la tarjeta tiene información en el PISTAI este se debe
enviar, tiene una longitud de 76 caracteres.

vi) PINBLOCK: El PINBLOCK es una trama de 16 caracteres que se
construye haciendo operaciones lógicas entre el PIN y el PAN (Número de
cuenta). Este se introduce en la trama debidamente cifrado con la llave de
cifrado de PIN. Este espacio de la trama se llena dependiendo si se debe o
no solicitar el PIN; si no, se deja vacío.

vii) Tipo de cuenta: Un dato numérico (representado en un Byte) indica el
tipo de cuenta del usuario. Este campo se llena o no dependiendo de los
parámetros de la tarjeta.

37

38
viii) Cuotas: 2 bytes indican el número de cuotas. Viaja o no dependiendo
de los parámetros.
ix) Valor de la transacción: Es el valor por el cual se realiza la transacción,
se representa en doce datos de tipo numérico en donde los últimos dos se
usan para centavos.
x) IVA: Es la parte del valor de la transacción que corresponde al IVA se
representa con doce datos numéricos.
xi) Base de devolución de IVA: Se representa con doce datos numéricos,
viaja o no dependiendo de los parámetros iniciales.
3.3.6. Respuesta de transacción de pago
Tiene los siguientes campos
i) Tipo de Mensaje
ii) Número de terminal.
iii) Consecutivo: Se envía para saber si la respuesta si corresponde a la
debida transacción.
iv) Código de respuesta: Son dos caracteres (cada uno representado en 1
Byte) que indican si la transacción fue exitosa o si existe algún error.
v) Descripción de respuesta: 20 caracteres que describen la aprobación o
el error de la transacción.

39
vi) Código de autorización: Es un código de 6 datos de tipo numérico,
diferentes de cero cuando la transacción es aprobada.

3.3.7. Petición de transacción de reverso:

Es una trama que se construye en caso de necesitar un reverso. El reverso anula o
revierte la transacción indicada por el consecutivo enviado. Los campos son:

i) Tipo de Mensaje.
ii) Número de terminal.
iii) Consecutivo

3.3.8. Respuesta de transacción de reverso:

Tiene los mismos campos que la respuesta de transacción de pago pero se identifica
con otro tipo de mensaje.

3.3.9. Solicitud de llave de cifrado de PIN:

Con esta trama se hace una solicitud al servidor de una nueva llave para el cifrado de
PIN, contiene los siguientes campos:
i)
Tipo de Mensaje.
ii) Número de terminal.

3.3.10. Respuesta de llave de cifrado de PIN:

Contiene los siguientes campos

i)
Tipo de Mensaje.
ii) Número de terminal.
iii) Llave de cifrado de PIN: Contiene 16 caracteres que representan la
llave de cifrado de PIN

3.4. MANEJO DE LLAVES DE CIFRADO

3.4.1. Manejo de Llave Maestra.

La llave maestra es una llave de cifrado usada para mantener la información de las
llaves de transporte y de PIN almacenadas seguramente en el equipo.

El proceso para almacenar una llave maestra en un POS es el siguiente: primero se
acuerda cierta cantidad de subllaves que se van a generar, la llave maestra se genera
al hacer una operación lógica XOR entre éstas. La finalidad de generar cierta cantidad
de subllaves es la de entregarle una a diferentes personas, las cuales ingresarán la
información al POS en diferente tiempo, de esta manera nadie conocerá la llave
maestra sino solamente un fragmento.

La forma en que se introducen las llaves maestras en un POS es mediante una
aplicación que se ejecuta desde un Computador al cual se conecta el POS, ésta
conexión depende de las características de cada POS.

En un POS, siempre se deben almacenar máximo 3 llaves maestras, la última llave
maestra usada antes de la actualizada, la llave maestra actual y la llave resultante de
la XOR de las partes ingresadas. En el momento que se desean actualizar las llaves
maestras, éstas sufren un corrimiento, de tal manera que la llave resultante de la XOR
pasa a ser la nueva llave actual y la llave actual pasa a ser la última llave.

En caso que se desee volver a usar la última llave como llave maestra actual, se tiene

40

la opción de hacer que la última llave ocupe de nuevo la actual, quedando vacío el
espacio que ocupaba antes. Este proceso se hace en caso que se presenten
inconvenientes con la llave maestra actual. Para una mejor idea del proceso se puede
ver más detalladamente en la Figura 3.
FIGURA 3, Proceso de Carga de Llaves Maestras

3.4.2. Llave de Transporte

Es una llave de cifrado que sirve para enviar y recibir información entre WI-P.O.S. y
el servidor, previamente esta llave ha sido concretada entre las dos partes e ingresada
en los 2 sistemas. Por seguridad este tipo de llave no permite que tenga un
intercambio dinámico.

Por seguridad ésta llave es cifrada dentro de WI-P.O.S por medio de la llave maestra
y luego almacenada. Es necesario que sea guardada en una memoria no volátil para
evitar que se borre cada vez que se apague el equipo.

Para el ingreso de la llave de transporte se debe hacer mediante una interfaz en un

41

42
computador.

3.4.3. Llave de cifrado de PIN

La llave de cifrado de PIN se usa exclusivamente para cifrar el PINBLOCK, esta es
una llave que se genera aleatoriamente en la tarjeta criptográfica del servidor y se
debe pedir cada vez que se hace una transacción, ésta se almacena en la memoria
RAM. La llave de cifrado de PIN se solicita usando la trama denominada petición de
llave de cifrado de PIN. (Ver sección 3.3.9)

43
4. DESARROLLO
El diseño y elaboración del dispositivo denominado WI-P.O.S contó con desarrollos
en Hardware, Software y Firmware. Estos fueron divididos en tres áreas principales
que serán explicadas a continuación. 1) Manejo de periféricos y procesamiento de
datos en el dispositivo, 2) Cifrado de datos y 3) Aplicaciones en J2ME y Visual
Basic.
4.1 MANEJO DE PERIFÉRICOS Y PROCESAMIENTO DE DATOS.
Como ya se ilustró en la sección 3.2 los periféricos que maneja el dispositivo son: un
lector de banda magnética, un teclado de 4 filas x 3 columnas, una impresora y un
teléfono móvil. Además se puede tomar el bloque de cifrado como un periférico más
y la comunicación con éste se explica más adelante.
Para manejar los periféricos, como unidad de procesamiento central se eligió un
microcontrolador PIC 18F452. Este es un microcontrolador de 8 bits , cuenta con una
memoria FLASH de 32Kbytes, una memoria RAM de 1536 bytes y una EEPROM
para datos de 256 bytes, cuenta con un USART (Addressable Universal Synchronous
Asynchronous Receiver Transmitter) y un módulo MSSP (Master Synchronous Serial
Port) éstos últimos muy útiles para el desarrollo. Además tiene 5 puertos de
entrada/salida, 1puerto de 7 pines, 3 de 8 pines y uno de 3 pines.
En la rutina principal del microcontrolador, este se encuentra esperando datos a través
de la USART, cada vez que ingresa un dato este lo lee y decide a que subrutina debe
entrar, ejecuta las acciones correspondientes y vuelve a su estado inicial. Para que el

44
dispositivo desarrollado contara con versatilidad y posibilidades de expansión, se fijo
una serie de rutinas que se realizan dependiendo de la instrucción recibida por el
puerto. El dispositivo cuenta con un interruptor de reset para inicializar el equipo en
caso de fallas, el circuito de reset se implemento haciendo uso de un integrado
LM555.
4.1.1 Comunicación con el teléfono móvil.
La comunicación con el teléfono móvil se hace a través de la USART del
microcontrolador. La USART (Addressable Universal Synchronous Asynchronous
Receiver Transmitter) es uno de los 2 módulos de transmisión serial con que cuenta el
microcontrolador. Este puede funcionar de manera sincrónica o asincrónica. Para el
desarrollo del proyecto se decidió trabajarlo de manera asíncrona ya que es así que
funciona el teléfono móvil, el cual maneja el protocolo EIA/TIA 232. En modo
asíncrono el puerto usa un formato de datos estándar de no retorno a cero. La
transmisión se hace de a 8 bits con un bit de inicio. Para la comunicación se eligió
una tasa de transmisión de 9600bps. El generador de rata de transmisión divide el
reloj de funcionamiento del microcontrolador en un número entero, para el caso
específico en que se trabajó al microcontrolador, es decir, en modo de velocidad baja,
se usa la siguiente fórmula para la rata de transmisión
Tasa de transmisión = Fosc/(64(n+1))
En donde n es un número entero que se debe poner en el registro SPBRG (registro de
generación de tasa de transmisión de la USART) del microcontrolador al inicializar el
puerto y Fosc la frecuencia del reloj con que trabaja el microcontrolador. Como n es
un número entero, si la frecuencia del reloj no es un múltiplo entero de 9600 se va a
generar un porcentaje de error en la transmisión, es por esto que se eligió un reloj de
4.9152Mhz para el microcontrolador, si se remplaza en la fórmula se encontrará un

45
valor de n igual a 7 y un porcentaje de error debido a tasa de transmisión de 0%.

El puerto serial (USART) del microcontrolador se usa para comunicarse con el
teléfono, con el computador y con la impresora. Estos tres usan el protocolo EIA/TIA
232 cuyos voltajes exceden el límite de trabajo en el circuito ya que éste opera con
una fuente sencilla de 3.3V, que lo hace compatible con la batería del teléfono en
caso de querer conectarlo a ésta. Por ésta razón, se hace necesario el uso de un
integrado MAX 232 que convierte los voltajes del protocolo EIA/TIA 232 a voltajes
compatibles con TTL y CMOS. Es de notar que se cuenta con un sólo puerto
(USART) y se necesita establecer comunicación con tres periféricos diferentes. Para
solucionar este inconveniente se tuvieron en cuenta los siguientes aspectos: el
microcontrolador no se comunica con dos periféricos a la vez, además se conecta con
el computador para cargar la llaves y el número de terminal, momento en el cual no
debe estar conectado al teléfono móvil, y por último, el integrado MAX 232 cuenta
con dos entradas y dos salidas. Como resultado se decidió usar un buffer tristate
cuyos output enable se manejan desde el microcontrolador con dos salidas digitales.
De modo que para el teléfono y el computador se usa la misma línea ya que estos no
se conectan simultáneamente. La salida Tx del puerto de USART se conecta
simultáneamente a la entrada de dos buffers tri state y las salidas de cada uno de éstos
se conectan a cada una de las entradas de la MAX 232 (ver figura 4). Así, si se quiere
transmitir al teléfono o al computador se habilitará dicho buffer y si se quiere enviar
datos a la impresora se habilitará el otro buffer.

46
Figura 4. Conexión del puerto serial USART.
Para evitar los errores en la comunicación con el teléfono se estableció un protocolo
en el que éste envía los datos al microcontrolador y el último responde un mensaje de
recibido y luego ingresa a la rutina deseada. De ésta manera, desde el teléfono
siempre es posible saber si la información se recibió correctamente. Para cada una de
las rutinas que puede realizar el microcontrolador (Ver sección 4.1.5) existe un
código específico de 8 bits de manera que éste puede ser controlado totalmente desde
la aplicación desarrollada en J2ME residente en el teléfono móvil.
4.1.2 Comunicación con la impresora
El envío de datos a la impresora se hace de manera serial por el puerto de USART
usando la conexión explicada en la sección anterior. Esta es una comunicación en un
sólo sentido usando el protocolo RS_232 de la impresora, que cuenta con ciertos
mensajes de funcionamiento (imprimir, pasar línea) y recibe los datos a imprimir en
un formato ASCII.
4.1.3 Lector de banda magnética
Para el desarrollo del dispositivo se usó un lector de tarjetas de banda magnética

OMRON V3A, que es un lector de tecnología CMOS de bajo consumo con salidas
compatibles con TTL. Es un lector de 9 pines que lee la PISTA I y la PISTA II (ver
Anexo Marco Teórico) de las tarjetas de banda magnética. Por cada pista tiene 3
pines, uno llamado card loaded que se pone en un cero lógico cuando se pasa una
tarjeta, el segundo es un pin de envío de datos vía serial y el tercero es el reloj de los
datos. Aunque es posible realizar transacciones teniendo sólo la PISTA II de la
tarjeta, se implementó la lectura de la PISTA I para que el diseño se adapte a futuros
requerimientos.

Para recibir la información proveniente del lector se usaron cuatro entradas digitales
(2 entradas para datos y dos de reloj) del microcontrolador. Los datos y el reloj de la
tarjeta vienen negados, es decir se leen cuando el reloj esté en 0; los datos de la
PISTA II vienen en bloques de a 5 bits, 4 de datos y uno de paridad (ver Anexo
Marco Teórico). Para el caso de la PISTA I vienen en bloques de 7 bits (un dato de
paridad). El equipo tiene una rutina para leer la tarjeta, al entrar a esta rutina se le
indica cual pista se quiere leer (la 1, la 2 o ambas). De este modo el microcontrolador
pasa a la rutina indicada. Se tienen tres rutinas, una para leer la PISTA I, otra para
leer la PISTA II y una última que lee las dos pistas a la vez. A continuación se
explican brevemente estas rutinas.
•
Leer PISTA II
Al entrar en la rutina de Leer PISTA II el microcontrolador debe encontrar dentro de
los datos provenientes de la tarjeta una “B” en hexadecimal que indica el comienzo
de la trama. Para lograr esto, se verifica el pin del reloj hasta que se encuentre en 0,
en ese momento se guarda el bit que se encuentra en la entrada de datos de la tarjeta
en el bit menos significativo de un registro que previamente ha sido iniciado en 00h,
luego vuelve a mirar el pin de reloj hasta que entre otro dato. Cuando el reloj se pone
de nuevo en cero (es decir, cuando hay otro dato disponible), se hace un corrimiento
hacia la izquierda en el registro y se pone de nuevo el dato que se encuentre en la

47

entrada de datos de la PISTAII en el menos significativo. Después de esto se compara
el registro con el dato A0h que es el dato Bh más la paridad negados, lo que indica el
comienzo de la trama de la pista.

Después de haber encontrado el comienzo de la trama se leen los datos bit por bit y se
van almacenando en registros. Después de leer los cuatro bits de cada dato se revisa
la paridad, en caso de ser errónea (hay un error en los datos), se envía un mensaje de
error y se sale de la rutina, en caso de estar bien se compara el dato con un 0Fh que
indica el final de la trama, si se leyó bien se envía por USART (hacia el teléfono) un
indicador de que la tarjeta se ha leído satisfactoriamente.
•
Leer PISTA I
A diferencia de la lectura de la PISTA II, la información se encuentra agrupada por
bloques de 7 bits, donde el último simboliza la paridad. Para iniciar el proceso, el
equipo Motorola debe enviar la instrucción para la lectura de la PISTA I. Para su
lectura, la unidad de procesamiento debe encontrar un 2 en hexadecimal en el primer
grupo de 7 bits y luego un 5 en hexadecimal en el siguiente grupo de 7 bits. Lo que
se hace es un proceso similar a la lectura de la PISTA II, donde se hace un
corrimiento y una comparación de los datos provenientes del lector de banda
magnética, teniendo en cuenta el reloj para sincronizar la información. Cada vez que
hay un cambio de reloj a cero lógico se toma la información de la PISTA I y se
almacena, al mismo tiempo se va a haciendo un corrimiento del dato anterior. Con el
nuevo dato en memoria se procede a realizar una comparación con 2 en hexadecimal;
una vez se encuentra, se realiza el mismo proceso pero con el 5 en hexadecimal.
Finalmente, al encontrarse los bits de inicio, se comienza a recibir la información por
bloques de 7 bits, realizando la paridad con cada bloque.

Este proceso se realiza hasta que se encuentre un 0F en la información entrante, por
lo que se debe estar comparando constantemente para saber si la información ya se

48

terminó de enviar.

Al finalizar el proceso, se envía una señal al teléfono para que continúe con la
siguiente rutina.
•
Leer Ambas Pistas
Para leer ambas Pistas se creó una instrucción híbrida entre la lectura de PISTA I y
PISTA II. El proceso consiste en realizar el proceso de la lectura de PISTA I pero
haciendo llamados al proceso de lectura de PISTA II. Se escogió como proceso
principal la lectura de PISTA I debido a que ésta tiene un reloj mas rápido que la
PISTA II, por lo tanto se asegura que no se pierda información de la PISTA II.

Al hacerse el proceso de llamado de la instrucción de lectura de PISTA II se
controlan los estados con banderas que indican en que paso se encontraba, de ésta
forma se sabe si se encuentra esperando por la B en hexadecimal o si se encuentra
esperando información.

4.1.4 Teclado para ingreso de datos.

El dispositivo cuenta con un teclado numérico de 4 filas x 3 columnas que además
tiene un botón de aceptado marcado A y uno para borrar marcado B. El teclado
funciona como un arreglo de interruptores que ponen en corto ciertos puntos de una
matriz, por tanto se uso un manejador de teclado (integrado 74HC922) cuyas ocho
entradas se conectaron a las salidas del teclado y cuyas cuatro salidas se conectaron a
cuatro entradas digitales del microcontrolador. Además se usó una salida de Data
Available (Dato disponible) del 74HC922 que se conectó a otra entrada digital del
microcontrolador y se usó una salida digital de éste último para conectarla a la
entrada de Output Enable (habilitar salida) del manejador ya que éste funciona de

49

modo tristate.
Figura 5. Conexión del teclado.

En las rutinas de recepción de datos a través del teclado se espera a que haya un 0 en
Data Available, en ese momento se habilita la entrada de datos (usando el pin de
output enable) se leen estos datos, se almacenan en un registro y se envían por
USART (al teléfono). En caso de borrar se vacía el registro anterior y se envía un 0Bh
al teléfono para que éste sepa que debe borrar. Los datos son enviados al teléfono
porque se deben mostrar en pantalla para que el usuario verifique los datos que esta
introduciendo. En el caso de la clave se envían asteriscos.

4.1.5 Comunicación con el modulo de cifrado.

Para comunicarse con el modulo de cifrado se utilizó el puerto serial MSSP (Master
Synchronous Serial Port, Puerto Maestro Serial Sincrónico) del microcontrolador.

50

51
Este puerto usa tres pines SCK (Serial Clock, Reloj Serial) SDI (Serial Data In,
Entrada de datos serial) y SDO (Serial data Out, Salida de datos serial). El puerto se
programó en modo SPI (Serial Peripheral Interface), de este modo se transmite en
bloques de 8 bits sin bit de inicio ni de parada. La tasa de transmisión es de ¼ la
frecuencia del reloj de trabajo del microcontrolador. Para el caso particular del
dispositivo desarrollado es de 1,229MHZ. Además se trabajó en modo maestro, es
decir el microcontrolador es quien proporciona el reloj. Las señales de entrada son
muestreadas al final del tiempo de la información, la transmisión se hace con borde
de subida del reloj como se muestra en la figura 6.

Figura 6 Transmisión de un 85h seguido de un ABh

Las señales con las que se controla el modulo de cifrado son: CLK (reloj), SERIAL
CLOCK (reloj serial), D (datos), OUT DATA (salida de datos), NRESET, TAKE_D
(tomar datos), DONE (realizado), ENABLE_D (datos habilitados), CRYPT (cifrar) y
START. (El funcionamiento detallado del módulo de cifrado se explica en la sección
4.2). Las señales SERIAL CLOCK, OUTDATA y D corresponden en el
microcontrolador a los pines del SPI. El resto de señales se implementaron en salidas
y entradas digitales y se manejan de acuerdo a lo requerido. (Ver figura 7)(Ver
sección 4.2).

52
Figura 7 Conexión con el módulo de cifrado.
Se implementó una rutina en el microcontrolador para cifrar / descifrar bloques de 64
bits. En el momento de enviar un bloque de 64 bits a cifrar / descifrar el proceso que
se sigue en el microcontrolador es el siguiente:
1. Se verifica con que llave se desea cifrar. (Transporte, Master, PIN). Esto se
hace verificando un indicador de llave que se debe enviar como parámetro de
esta rutina.
2. Se verifica si la llave esta cargada en el módulo de cifrado. El cifrador tiene
la capacidad de almacenar la llave por tanto si se requiere cifrar dos bloques
con la misma llave no es necesario cargar esta de nuevo. Al cargar una llave
se altera una bandera dentro del microcontrolador la cual es verificada cada
vez que se va a enviar a cifrar un bloque de datos.
3. En caso de no estar cargada se debe cargar la llave de datos. Se envía
serialmente la llave de 64bits con las señales correspondientes (Ver sección de
4.2), éstas llaves se deben haber almacenado previamente en memoria

53
4. Se envía el bloque de datos de 64 bits. Se hace de manera serial por el
puerto SPI.

5. Se transmite una señal de inicio y la señal de cifrado / descifrado CRYPT.
(Ver sección 2.2)

6. Se verifica si se terminó el proceso de cifrado.

7. Se envía el reloj para recibir los datos de manera serial y se almacenan.

En el desarrollo se usó el modo de cifrado / descifrado CBC (ver Anexo Marco
Teórico) en el cual los datos a cifrar se envían en bloques de 64 bits, pero el segundo
que se transmite es la XOR del primer bloque cifrado, con el segundo bloque a cifrar
y la XOR de estos con un 0C en hexadecimal, así consecutivamente. (Ver figura 8).
Además tiene un vector de inicio, de manera que el primer bloque a cifrar hace XOR
con este.
Figura 8 Cifrado usando modo CBC (Cipher Block Chaining) B1, B2, B3 son bloques de
64 bits de una misma trama, E1, E2, E3 el resultado de cifrar

54
Figura 9 Descifrado usando modo CBC (Cipher Block Chaining)
De modo que este proceso de realizar la operación lógica XOR también se lleva a
cabo en el microcontrolador, cada vez que se envía un bloque que no es el primero a
cifrar se hace la XOR con el resultado de cifrar el bloque anterior. En el momento de
descifrar se hace un procedimiento algo parecido, la diferencia consiste en que se
hace la XOR del último bloque descifrado con el anterior aún cifrado.
4.1.6 Rutinas del microcontrolador.
Para hacer del dispositivo desarrollado un equipo versátil, se desarrollaron una serie
de rutinas que pueden ser llamadas desde el teléfono móvil (o desde un computador
en caso de ser necesario). Cada una de estas rutinas tiene un código de 8bits con la
que se identifica, para llamar una rutina del microcontrolador se sigue el proceso
mostrado en la figura 10. Cabe anotar que el proceso o rutina determinada puede

requerir de transmisión de información hacia el teléfono. Toda comunicación entre el
teléfono (o computador) y el microcontrolador se hace a través del puerto de USART.
(Ver sección 4.1.1)
Fig. 10 Proceso para llamar las rutinas del microcontrolador.

A continuación se explicará el funcionamiento de cada rutina:

1. Leer tarjeta: En esta rutina el microcontrolador espera recibir los datos que le
indican que pista leer, luego habilita los pines del lector de banda magnética,
lee los datos (ver sección 4.1.3), en caso de presentarse algún inconveniente
(la paridad de algún dato esta mal) devuelve un mensaje de error, de lo
contrario devuelve un mensaje de aceptado y guarda los datos de la tarjeta de

55

56
banda magnética en memoria RAM.
2. Leer clave: Al recibir la instrucción de leer clave el microcontrolador espera
dos parámetros que deben ser enviados desde el teléfono móvil, el primero es
el numero de dígitos de la clave y el segundo el indicador de la llave con que
se cifrara el PINBLOCK. Estos parámetros son necesarios porque la longitud
del PIN puede variar según el país o la región o con el paso del tiempo se
pueden requerir un mayor número de dígitos. Después de haber recibido estos
dos parámetros el microcontrolador habilita los pines del teclado, cada vez
que el usuario oprime una tecla se envía un mensaje de “asterisco” hacia el
teléfono por el puerto para que éste último ponga asteriscos en la pantalla.
Después de haber recibido la cantidad de dígitos necesaria por parte del
usuario (dependiendo del parámetro ingresado desde el teléfono) se procede a
armar una trama conocida como PINBLOCK, esta es una trama que se
construye haciendo operaciones lógicas con el PIN del usuario y el número de
la cuenta, por esto es necesario que para correr esta rutina ya se haya
deslizado la tarjeta. El resultado (una trama de 64 bits) se cifra usando la llave
cuyo indicador que se ingresó como parámetro y se almacena en memoria
RAM. El PINBLOCK se cifra inmediatamente porque es un dato que requiere
de total confidencialidad, para evitar problemas de seguridad se almacena
debidamente cifrado.
3. Obtener datos: Esta es una rutina en la que se almacenan datos provenientes
del teclado. Sirve para almacenar datos tales como valor, cuotas y propina. El
microcontrolador cuenta con 10 posiciones de memoria para almacenar datos,
cada una de 10 bytes. Al entrar en esta rutina el microcontrolador espera dos
parámetros, el primero es el número máximo de dígitos del dato a recibir y el
segundo el índice en donde se guardará el dato (éste último se encuentra entre
1 y 10). Luego se habilita el teclado, se leen los datos, se envían al teléfono
cada vez que se oprima una tecla para que puedan ser mostrados en pantalla.
Este proceso se realiza hasta que se haya ingresado el número máximo de

57
dígitos o el usuario presione la tecla “A” del teclado. Los datos son
almacenados en memoria RAM y la posición donde se almacenan depende del
índice introducido como parámetro.
4. Pedir tarjeta: Esta rutina envía por USART los datos de la PISTA 2 de la
tarjeta que debe haber sido deslizada previamente.
5. Pedir datos: Esta rutina recibe como parámetro el índice de los datos que se
requiere (entre 1 y 10) y devuelve los datos que fueron almacenados haciendo
uso de la rutina obtener datos.
6. Cifrar: Esta rutina espera dos parámetros, primero espera el bloque de 64 bits
a cifrar y segundo el indicador de la llave a utilizar. Luego cifra el bloque de
64 bits haciendo uso del modulo de cifrado y almacena los datos en memoria
RAM. Cabe anotar que como las llaves se almacenan debidamente cifradas
(usando la llave maestra) en el proceso de cifrado se debe descifrar primero la
llave a usar para luego enviarla al módulo de cifrado. El cifrado/descifrado de
las llaves se hace de la misma manera que con cualquier bloque de 64bits.
7. Descifrar: Esta rutina funciona de manera similar a la de cifrar, la diferencia
consiste en que se elige otro modo de operación del módulo de cifrado
haciendo uso del pin CRYPT (Ver Sección 2.2).
8. Reset: Esta instrucción inicializa el microcontrolador.
9. Recibir Terminal: Esta rutina se debe correr desde un computador personal y
no desde el teléfono. El número de terminal es un código que identifica cada
equipo y que es necesario para llevar a cabo una transacción. En esta rutina se
recibe el número de terminal desde el computador (8 bytes) y se almacena en
la memoria EEPROM del microcontrolador. Este es un código que se utiliza
en todas las transacciones y por eso es necesario cargarlo en una memoria no

58
volátil.
10. Recibir llave de transporte: Esta rutina se corre desde un computador y no
desde el teléfono móvil. En esta rutina se recibe de manera serial la llave de
transporte, se cifra usando la llave maestra y se almacena en memoria
EEPROM del microcontrolador, esta llave se usa para el cifrado de las tramas
que se envían al servidor.
11. Recibir llave maestra: La recepción y almacenamiento de la llave maestra
requiere de varias rutinas, este proceso se explica detalladamente en la sección
4.4.
12. Parámetros iniciales: Para correr esta rutina de manera correcta se debe haber
cargado el número de terminal, la llave maestra y la llave de transporte. Al
entrar en esta rutina el microcontrolador construye la trama de petición de
parámetros iniciales (ver sección 3.3.1), rellena con el carácter “F” los bytes
restantes necesarios para tener una trama que sea múltiplo entero de 64 bits
(para que pueda ser cifrada). Luego cifra esta trama haciendo uso de la llave
de transporte usando el modo de cifrado CBC y la envía al teléfono, después
queda en estado de espera de los parámetros iniciales. Al recibir la trama de
parámetros iniciales la descifra usando la llave de transporte, verifica que no
haya errores en el mensaje, esto lo hace verificando ciertos campos del
mensaje recibido (tipo de mensaje, terminal) en caso de no haber errores
almacena los parámetros en memoria RAM y envía un mensaje de aceptado.
En caso de errores se envía un mensaje de error. Esta rutina se debe realizar
cada vez que se enciende el equipo porque los parámetros iniciales son
indispensables para cualquier transacción.
13. Pedir Parámetros iniciales: Es una serie de rutinas que envían al teléfono
cualquiera de los parámetros iniciales. Existe una rutina para cada uno de los
parámetros, al entrar en ésta el microcontrolador envía la información

59
almacenada en la posición de memoria de ese parámetro. (Para ver cuales son
los parámetros iniciales ver la sección 3.3.2)
14. Parámetros de tarjeta: Para correr esta rutina se deben haber cargado
previamente los parámetros iniciales y además se debe haber deslizado la
tarjeta de banda magnética. En este proceso el microcontrolador construye la
trama denominada “petición de parámetros de tarjeta”, rellena con el carácter
“F” hasta tener una trama múltiplo entero de 64 bits, la cifra usando el modo
CBC y la envía al teléfono, luego queda en estado de espera de respuesta. Al
recibir la trama de respuesta de parámetros iniciales se descifra, verifica que
este correcto el tipo de mensaje y almacena los parámetros de la tarjeta en
ciertas posiciones de memoria RAM establecidas para esto.
15. Pedir parámetros de tarjeta: Similar a la petición de parámetros iniciales se
implementó una serie de rutinas para pedir cada uno de los parámetros de la
tarjeta, en las que el microcontrolador envía a través del puerto la información
almacenada en las posiciones de memoria destinadas para los parámetros de la
tarjeta.
16. Petición de llave de cifrado de PIN: Esta rutina se encarga de construir la
trama de petición de llave de cifrado PIN; la cifra usando la llave de
transporte y la envía, luego queda en estado de espera. Cuando recibe la
respuesta descifra la trama, verifica el tipo de mensaje y el terminal, cifra la
llave de cifrado de pin usando la llave maestra y la almacena en memoria
RAM. Como la llave de cifrado de PIN se pide durante cada transacción no
es necesario almacenarla en EEPROM.
17. Solicitud de transacción de pago: Para ejecutar correctamente esta rutina se
deben haber solicitado parámetros iniciales, parámetros de tarjeta y todos los
campos adicionales dependiendo de la tarjeta (valor, cuotas, PIN, tipo de
cuenta entre otros, ver sección 3.3). Al tener estos datos, el microcontrolador

60
construye la trama de petición de transacción de pago y la envía por el puerto
serial, luego queda en estado de espera. Al recibir la respuesta la descifra,
revisa errores (en caso de error transmite un mensaje específico); de estar
correcto, almacena los datos de respuesta de transacción de pago en los
campos de memoria RAM destinados para ello.
18. Petición de respuesta de transacción: Se implementó una serie de rutinas para
pedir cada uno de los campos de la respuesta de transacción de pago, en las
que el microcontrolador envía a través del puerto la información almacenada
en las posiciones de memoria destinadas para los parámetros de la tarjeta.
19. Transacción de reverso: En esta rutina se construye la trama de transacción de
reverso, se cifra y se envía, luego se espera recibir la respuesta, se verifica que
no tenga errores y almacenan los datos en memoria.
20. Inicializar consecutivo: El consecutivo es un número que caracteriza cada una
de las transacciones. Esa rutina pone en cero los seis registros en EEPROM
correspondientes al consecutivo.
21. Aumentar consecutivo: Esta rutina le suma 1 a los registros del consecutivo,
teniendo en cuenta que los datos son de tipo numérico, es decir van entre 0 y 9
(ver sección 3.3.5).
22. Comparar fecha de vencimiento: Esta rutina compara una fecha ingresada
desde el teléfono con la fecha de vencimiento que se encuentra en la PISTA II
de la tarjeta. La fecha de vencimiento de la tarjeta debe ser mayor a la fecha
ingresada por el usuario, de no ser asi se envia un mensaje de error.
23. Comparar fecha de vencimiento 2: Esta rutina compara una fecha ingresada
por el usuario con la fecha de vencimiento de la tarjeta que se encuentra en la
Pista II de la tarjeta. Envía un mensaje de respuesta, dependiendo del

resultado, en este caso las fechas deben ser iguales .

4.2. Cifrado de datos

Una parte fundamental del trabajo de grado y sin la cual un dispositivo como WI-
P.O.S no tendría validez alguna en el mercado es el módulo de cifrado, ya que es la
parte que se encarga de darle un nivel de seguridad a la información cuando viaja por
la red.

Debido a que WI-P.O.S debe ser un dispositivo que cumple con los estándares de
seguridad, su módulo de cifrado se basa en un algoritmo DES (Data Encryption
Standard), este sistema de cifrado es utilizado en el mercado colombiano por la
complejidad que implica el tratar de descifrarlo sin tener el acceso a las llaves.( ver
Anexo Marco Teórico)

Para su implementación se evaluó que la mejor forma de hacerlo era mediante el uso
de una FPGA (Field Programmable Gate Array, Arreglo de compuertas
programables ), debido a que por medio de este dispositivo se tenía la posibilidad de
manipular directamente los 64 bits de la llave y de la información.

La FPGA seleccionada fue una ACEX 1K50TI144-2, esta consta de 50 mil
compuertas
lógicas,
teniendo
aproximadamente
5000
elementos
lógicos
programables, tiene un empaque de montaje superficial delgado y un total de 144
pines. Una de las características de las FPGA es que tienen memoria volátil, por lo
que es preciso utilizar una memoria para recargar los parámetros del programa
desarrollado, en nuestro caso el cifrado en DES, de lo contrario, cada vez que se
prendiera la FPGA tendría que programarse directamente de la herramienta de
desarrollo. Por esto se implementaron las conexiones correspondientes entre la ACEX
1K y una memoria serial de ALTERA EPC2LC20. A continuación se hace una
descripción de las conexiones en la Figura 11, el tipo de conexión utilizado es
llamado Passive Serial, o Serial Pasivo.

61

62
FIGURA 11, Configuración Serial Pasiva entre la memoria EPC2 y la FPGA ACEX 1K3

A parte de las conexiones entre memoria y FPGA se deben crear conexiones al
programador, que en este caso es JTAG (Joint Test Action Group), que es usado por
las herramientas de desarrollo de ALTERA. A continuación se muestran las
conexiones correspondientes en la Figura 12 y en la Tabla 1 .

3
en la página www.altera.com

TABLA 1 Conexiones ente ACEX1K y JTAG en modo Serial Pasivo4
Figura 12, conector JTAG para programar la ACEX1K

Con la información de la figura y la tabla anterior se pueden establecer las
conexiones, cabe anotar que los componentes electrónicos con que se trabajó se
encuentran disponibles solo en montaje superficial, lo que hace que sus pruebas se
4
Para manyor información acerca de las conexiones favor remitirse a la pagina www.altera.com

63

deban realizar directamente en el impreso, por esto se debe tener un especial cuidado
en las conexiones y en el diseño del impreso.

Para el desarrollo de DES se siguió el proceso establecido según el documento FIPS
46, explicado en el marco teórico, se evaluaron las posibles herramientas para su
implementación como MAX PLUS II, MODELSIM y QUARTUS II, y finalmente se
decidió implementar en esta última, por la facilidad y comprensión de la herramienta
y por que las FPGAs que tenía cumplían con las características apropiadas para la
implementación del módulo de DES.

Debido a que el dispositivo se tiene que comunicar con el PIC por medio de su puerto
SPI, la información de los datos y de la llave se deben cargar serialmente, de manera
que se implementaron 2 módulos aparte del de DES, estos son: un módulo que
convierte la información de serie a paralelo para poder recibir la información en el
módulo DES y otro módulo que convierte la información de paralelo a serie para
poder enviar la información ya cifrada. Cabe anotar que estos módulos fueron
implementados dentro de la misma FPGA. En la figura 13, se puede observar la
conexión de los módulos entre ellos.
FIGURA 13, Módulos de entrada y saluda a DES

4.2.1. Módulo Serie-Paralelo

Este módulo recibe la información que proviene de forma serial y la convierte en
paralelo, debe entender en que momento se envía la información de la llave o de los

64

datos a cifrar, también debe ser enviado con su respectivo reloj para poder interpretar
la información serial.

Es por esto que se han definido 3 señales de entrada importantes en este módulo, los
cuales son:
•
•

•

•

•
•

•
D: Por esta entrada se envían los datos.
SERIAL_CLOCK: Por esta entrada se envía el reloj para que el
módulo interprete los datos.
NRESET: Con esta señal se puede dar reset al módulo, borrando sus
registros y sus contadores internos. Cabe anotar que esta señal es
negada.
ENABLE_D: Este Pin identifica si la información enviada pertenece a
la llave o a los datos a ser cifrados.
1: Datos a ser cifrados.
0: Llave.
KEY (0..63): Salida donde se almacena la llave.
KEY READY: Salida que indica que la llave fue cargada.
1: Llave cargada
0: Llave no cargada.
DATA (0..63): Salida donde se almacenan los datos a ser cifrados.
En la Figura 14 se pueden ver las entradas y las salidas del módulo.
FIGURA 14, Módulo serie-paralelo

65

Para enviar la información serial se deben seguir las siguientes especificaciones:
primero se debe enviar un 01h para poder comenzar la transmisión de datos al
módulo Serie-Paralelo, todo sincronizadamente con la señal de reloj. Desde este
punto el módulo cuenta 64 ciclos de reloj para saber que la información ha llegado
completa. Si la información que se envió pertenecía a los datos, la entrada de
ENABLE_D debió haber permanecido en 0 durante el envío de la información. En el
momento de ser la llave cargada, un contador interno cuenta los 64 ciclos de reloj de
la carga de la llave y en el momento de terminar de contar levanta la señal de KEY
READY. Si la información que viajaba eran los datos a ser cifrados ENABLE_D
debió haber permanecido en 1 durante el envío de la información. En la Figura 15, se
observa cuando el módulo recibe la información de los datos a cifrar y en la Figura 16
se puede ver cuando recibe la información de la llave.
FIGURA 15, Simulación de módulo Serie-Paralelo con recepción de datos a cifrar

En el ejemplo de la Figura 16, se puede observar que para enviar la información se
necesita primero enviar el 01h para que el sistema se prepare a recibir los siguientes 8
Bytes, también la señal de ENABLE_D se encuentra en todo momento en 1 al igual
que la señal de NRESET. Al finalizar el envío de la información se puede ver en la
salida data la información en paralelo.
FIGURA 16, Simulación de módulo Serie-Paralelo con recepción de llave

66

En la Figura 16, se muestra el envío de la información de la llave, por lo que, en lo
único que difiere del ejemplo de la Figura 15, es en la señal ENABLE_D que se
encuentra en 0.

4.2.2. Módulo Paralelo-Serie

Este módulo se encarga de recibir la información de 64 bits en paralelo ya cifrada del
módulo DES y volverla serial para poderla enviar al microcontrolador. Recordando
que todo el módulo de cifrado funciona como esclavo del microcontrolador la
información que entrega el módulo paralelo-serie, depende del reloj enviado por el
maestro.

Sus entradas y salidas son las siguientes:
•

•

•

•

•
Q (63..0): En esta entrada se pone la información paralela que será convertida
en serie por el módulo, es decir, el resultado de la realización del cifrado en el
módulo de DES.
TAKE_D: Con esta entrada se le indica al sistema cuando tomar los datos que
se encuentran en su entrada Q (63..0).
SERIAL_CLOCK: Esta entrada pertenece al reloj generado por el maestro
quien controla en que momento se le debe enviar la información serial.
NRESET: Con esta señal se puede dar RESET al módulo, borrando sus
registros. Cabe anotar que esta señal es negada.
OUTDATA: En esta salida la información ingresada paralelamente al sistema
sale de forma serial, sincronizada con la señal de SERIAL_CLOCK enviada
por el maestro, cabe anotar que la información es enviada con el borde de
subida de la señal de reloj.

En la Figura 17, se pueden ver las señales del módulo paralelo-serie.

67

FIGURA 17, Módulo paralelo-serie

Para solicitar al módulo la información se debe primero poner en 1 por 8 ciclos de
reloj la señal TAKE_D, esto, debido a que con esta señal se cargan los registros de
entrada almacenando la información que se encuentra en Q (63..0), luego se solicitan
los datos cifrados con sólo enviar el reloj. A continuación en la Figura 18, se muestra
un ejemplo de cómo el módulo paralelo-serie entrega la información cifrada.
FIGURA 18, simulación del módulo Paralelo-Serie

4.2.3. Modulo DES:

Para la elaboración de este módulo se siguieron los pasos establecidos en el Marco
Teórico en la sección de DES, donde se explica el funcionamiento de este sistema de
cifrado.

Para su implementación se desarrollaron diferentes funciones en el lenguaje de
ALTERA AHDL, en donde se repartieron los desarrollos de las tablas de
permutación, sustitución y otros, para distribuir el módulo DES de una manera más
sencilla de desarrollar.

68

4.2.4. Funciones de Tablas:

A continuación se explican las funciones de las tablas desarrolladas para la
implementación de DES, para un mayor entendimiento del funcionamiento de cada
tabla se recomienda referirse al marco teórico.

? IP (Initial Permutation)
? IP-1 (Inverse Initial Permutation)
? PC1 (Permuted Choice 1)
? PC2 (Permuted Choice 2)
? E (Expantion)
? P (Permutation)
? Sn (Tablas de Sustitución)

• IP (Initial Permutation):

La permutación inicial es realizada sobre la información de 64 bits a ser cifrada,
como salida se tienen 2 bloques de 32 bits cada uno denominados L0 y R0, este
proceso se puede ver claramente en el marco teórico. En su implementación en
AHDL la entrada se reordena según la tabla IP, utilizando para esto funciones de
tablas por su facilidad de manejo.
•
IP-1(Inverse Initial Permutation):
La permutación inicial inversa es hecha sobre el último bloque R16L16 teniendo como
entrada un bloque de 64 bits, estos bits son reordenados según la tabla IP-1 del
•
E (Expantion):
La tabla de Expansión se aplica sobre el bloque Rn en cada iteración, tiene una

69

entrada de 32 bits y una salida de 48 bits, de ahí el nombre que recibe.
•
P (Permutation):
La tabla de permutación P se aplica sobre la información que sale de las tablas de
sustitución, tiene como entrada 32 bits y como salida 32 bits.
•
PC-1(Permutation Choice 1):
Esta tabla tiene como entrada el bloque de 56 bits de la llave sin sus bits de paridad y
como salida tiene 2 bloques de 28 bits cada uno, denominados en el Marco teórico
como C0 y D0.
•
PC-2(Permutation Choice 2):
Esta tabla tiene como entrada la unión de los bloques Cn y Dn después de su
corrimiento, tiene como entrada un bloque de 56 bits y como salida un bloque de 48
bits.
•
Tablas de sustitución
Estas tablas tienen como entrada un bloque de 6 bits, donde el primer y último bit
significan el número de la fila de la tabla, que va de 0 a 3 en binario. Los bits de la
mitad simbolizan el número de la columna y pueden tomar los valores de 0 a 15 en
binario.

4.2.5. Funciones Específicas:

A partir de la definición e implementación de cada una de las tablas anteriores por

70

medio de funciones se generaron otras funciones más específicas para generalizar los
pasos.
•
Función de sustitución:
Al tener implementadas las funciones de las tablas de sustitución se creó una función
más general en la que se invocaban todas, teniendo como entrada un bloque de 48 bits
y una salida de 32 bits. La función divide el bloque de 48 bits de entrada en pequeños
grupos de 6 bits, en donde el primer grupo entra a la primera tabla de sustitución, el
segundo a la segunda tabla y así sucesivamente. Como cada tabla de sustitución
genera como respuesta bloques de 4 bits, éstos son unidos al final, generando un total
de 32 bits al agruparlos.
•
Función F:
Esta función, definida en el marco teórico, tiene como entradas dos bloques, uno de
32 bits que representa Rn y otro de 48 bits que representa la subllave, como salida
tiene un bloque de 32 bits. Esta función introduce el bloque Rn en la función de la
tabla de Expansión E, generando una salida de 48 bits, que son operados con la
subllave por una XOR. Estos 48 bits resultantes son introducidos a la función de
sustitución explicada anteriormente, teniendo como salida un bloque de 32 bits. En
este punto se ve la importancia de haber desarrollado el sistema de cifrado por
funciones.
•
DES:
Para la generación del algoritmo DES se utilizaron los recursos de memoria de la
FPGA para almacenar las subllaves generadas para cada función F, incluyendo el
archivo de manejo de memorias llamado “lpm_ram_dq.inc”, donde se almacenaron
16 llaves cada una de 48 bits. Esta librería permite manejar memorias con tamaño de

71

información variable, para el caso de la generación de las subllaves fue conveniente
porque se utilizaron 48 bits de tamaño de dato.

Para la generación de las subllaves, el bloque de 64 bits de entrada fue primero
pasado por la función PC-1, la cual entregaba 2 bloques de salida C0 y D0, luego
como la generación dependía de corrimientos a la izquierda, los 2 bloques fueron
introducidos en una máquina de estados que realizaba los corrimientos según la
iteración en que se encontraba. Al realizarse los bloques Cn y Dn eran unidos y se
llamaba la función PC-2 donde finalmente se tenía la subllave generada. Con esto se
almacenaba la información en memoria.

Para cifrar la información, se cogían los datos y se llamaba la función IP, con este
resultado se generaron los bloques L0 y R0 los cuales eran pasados por la función F
creada anteriormente. Para las iteraciones se creó una máquina de estados donde en
cada iteración se hacían los cambios de los bloques L y R y además se llamaba la
función F invocando la subllave de la memoria.

4.2.6. Entradas del módulo
?
KEY (64..1): Entrada paralela de la llave de 64 bits.
? DATA (64..1): Entrada paralela de la información a cifrar o descifrar.

? CRYPT: Señal que indica si la operación que se va a realizar es de cifrado o
descifrado.

1: Cifrado.

0: Descifrado.
?

?
START_KEY: Entrada, esta señal le indica al módulo DES que comience a
generar las subllaves.

START: Entrada esta señal le indica al módulo DES que comience a cifrar la

72

?

?

?
información.

CLOCK: Reloj del módulo.

NRESET: Señal negada que le da reset al sistema

1: No reset.

0: Reset.

OUT_DES (64..1): Salida paralela de la información ya cifrada o descifrada.
FIGURA 19, Entradas y Salidas del modulo DES

4.2.7. Integración de los módulos:

De acuerdo a la descripción de los módulos explicados anteriormente, son unidos por
medio de sus señales entre sí. El módulo serie-paralelo se interconecta con el módulo
DES por medio de las señales de la salida paralela de la llave de 64 bits y la salida de
la información a cifrar de 64 bits. La señal de KEY_READY se encarga de dar la
orden al módulo DES de comenzar a generar las subllaves, ésta señal se conecta con
START_KEY.

El módulo DES se conecta con el módulo paralelo-serie por medio de la salida
paralela de OUT_DES. Las conexiones entre cada módulo se pueden ver en la
Figura19.

73

4.2.8. Módulo de Cifrado

Teniendo los módulos interconectados se genera el módulo de cifrado, el cual tiene
las siguientes señales de control.

? NRESET: Esta señal de entrada se encarga de reiniciar los módulos y borrar la
información almacenada en sus registros.
1: No reset.
0: Reset
?

?
ENABLE_D: Esta señal de entrada indica que información se va a enviar al
módulo por la entrada D.
0: La información que entra a D pertenece a la llave.
1: La información que entra a D pertenece a la información a cifrar.
D: Esta entrada recibe la información serialmente, ya sea la llave o la
información a cifrar.
? SERIAL_CLOCK: Reloj que sincroniza la información que entra por la entrada
serial D.
?
START: Con esta entrada se da la orden al módulo de comenzar a cifrar.
? CLOCK: Reloj del módulo de cifrado.
?
CRYPT: Señal de entrada que indica si se va a realizar una operación de cifrado
o descifrado.
1: Cifrado.
0: Descifrado.
? TAKE_D: Esta señal de entrada prepara al módulo de cifrado para enviar la
información del resultado del cifrado o descifrado.
1: Enviar información.
0: No enviar la información.
?
?
OUT_DATA: Señal de salida por donde se envía la información.
DONE: Señal de salida que indica que la información ya se terminó de cifrar o
descifrar

74

75
FIGURA 20, Interconexión entre módulos
4.3 APLICACIÓN EN J2ME PARA EL TELÉFONO MÓVIL MOTOROLA
Para el uso apropiado del dispositivo es necesario tener una interfaz gráfica amable
que es la encargada de interactuar con el usuario para llevar a cabo la transacción con

76
éxito, ya que esta interfaz le permite al usuario llevar el control de la transacción paso
por paso ingresando la información necesaria de la forma como la aplicación se la va
solicitando.
Esta aplicación fue desarrollada en el lenguaje de programación Java 2 Micro Edition
(J2ME), que está orientado a dispositivos móviles con limitada capacidad de
procesamiento y de memoria como los teléfonos móviles y PDA’s, y que está siendo
incorporada de fábrica en los equipos móviles Motorola iDEN de Avantel a los cuales
está orientado WI-P.O.S.
4.3.1. Descripción de la aplicación:
Existen dos aplicaciones importantes que son las que permiten llevar a cabo con éxito
una transacción bancaria utilizando el dispositivo desarrollado en este Trabajo de
Grado. Hay una tercera aplicación que consiste en generar el reverso de una
transacción, es decir anula la ultima transacción realizada, esto por si existe algún tipo
de error.
La primera de ellas es la encargada de permitir cargar los Parámetros Iniciales(ver
sección 3.3) al dispositivo. Es una aplicación en la cual no interactúa el usuario que
va a realizar un pago a través de tarjeta débito o tarjeta de crédito sino que la ejecuta
el funcionario del establecimiento cada vez que se enciende el equipo.
La segunda aplicación es la aplicación de Transacción de Pago, la cual permite
realizar un pago con tarjeta débito o tarjeta de crédito.
Las aplicaciones mantienen un contacto permanente con el dispositivo WI-P.O.S por
medio de un puerto serial que tiene el teléfono y también se comunican con el
servidor que recibe y envía información acerca de la transacción a través del
protocolo seguro de Internet HTTP (HyperText Transfer Protocol), utilizando la red
iDEN de Avantel. Las aplicaciones están divididas en clases, propias del lenguaje

Java que es orientado a objetos, las cuales permiten un manejo completamente
modular ya que hay un programa principal donde se desarrolla la secuencia de cada
aplicación y en ese programa principal se hacen diferentes llamados a estas clases
para que realicen acciones específicas, y a veces repetitivas, reduciendo la cantidad
de código para la aplicación.

4.3.2 Clases desarrolladas en la aplicación:
•

•

•
CommPuerto: Permite la comunicación del dispositivo móvil con el puerto
serial para enviar y recibir información, manejando número enteros. Esta clase
recibe tres parámetros de tipo entero (int). El primero es el dato a enviar por el
puerto serial, el segundo es un entero que indica cuantos bytes espera recibir
la aplicación de la unidad central de procesamiento y el tercero es un entero
que indica si se envía un dato o solamente se espera una respuesta. Cada byte
que esta clase recibe del Wi – POS, lo convierte a un número entero. Al final,
devuelve una cadena de caracteres, con números enteros, a la aplicación
principal.

CommPuerto2: Permite la comunicación del dispositivo móvil con el puerto
serial para enviar y recibir información, manejando información en
hexadecimal. Recibe los mismos tres parámetros que CommPuerto pero la
diferencia es que cada byte que recibe, lo expresa en una cadena hexadecimal.
Al final devuelve una cadena de caracteres, con números en hexadecimal, a la
aplicación principal.

DataRequest: Permite el envío de instrucciones a la unidad central de
procesamiento para que guarde información ingresada por el teclado y esta
información se vea en la pantalla del teléfono móvil. Esta clase recibe como
parámetros un entero que expresa cuantos dígitos se esperan recibir del
teclado, un objeto de tipo “Forma” que es la pantalla que se muestra en ese
momento al usuario en la cual van a ir apareciendo los números que se digiten

77

•

•

•
por el teclado del Wi – POS, y un índice que le indica a la unidad central de
procesamiento en qué lugar de memoria se debe guardar esa información. Al
final, devuelve una cadena de caracteres indicando si la operación fue exitosa
o no.

Flag, positionThread: Estas clases permiten el manejo de “pantallas
temporales”, muy usadas en la aplicación, para mostrar al usuario una
información mientras el equipo realiza otra tarea. Una vez finalizada esa otra
tarea, se cambia la pantalla a una pantalla final. Un ejemplo de esto es cuando
la aplicación muestra la pantalla que le indica al usuario que deslice la tarjeta
por el lector. Mientras que el Wi – POS espera que esto ocurra, el teléfono
muestra esa pantalla y apenas el usuario desliza la tarjeta, el Wi – POS le
indica a la aplicación que la tarjeta fue deslizada y la aplicación muestra la
pantalla siguiente. Son pantallas que permiten al usuario ver que el sistema se
encuentra realizando algún proceso, cuando éste puede tardar varios segundos.
Si ésta clase de pantallas no se incorporaran en la aplicación, el usuario podría
confundir una pantalla congelada temporalmente con un bloqueo de la
aplicación.

Httpconnection: Permite la conexión a Internet, enviando y recibiendo datos a
esta red. Esta clase recibe como parámetro una dirección de Internet a la cual
el dispositivo se va a conectar y devuelve una cadena de caracteres indicando
si la conexión fue exitosa o no.

PINEntry: Esta clase envía instrucciones a la unidad central de procesamiento
para que guarde la información proveniente del teclado que se refiere a la
clave del usuario y que en pantalla se vean asteriscos. Esta clase recibe como
parámetros un entero que indica el número de dígitos que se van a ingresar
por el teclado, un entero que indica cual llave de cifrado debe utilizarse para
cifrar los datos que se ingresen por el teclado, y un objeto tipo “Forma” que es
la pantalla a mostrar mientras se digita la clave, que no muestra los números

78

•

•

•

•
digitados sino asteriscos. Al final, devuelve una cadena de caracteres
indicando que la operación fue realizada satisfactoriamente.

ReadCardRequest: Esta clase permite el envío de instrucciones a la unidad
central de procesamiento para que reciba la información del lector de banda
magnética. Esta clase recibe dos parámetros de tipo cadena de caracteres los
cuales indican qué información recoger de la tarjeta deslizada: la Pista I o la
Pista II. El primer parámetro hace referencia a la Pista I y el segundo
parámetro hace referencia a la Pista II. Devuelve a la aplicación principal una
cadena de caracteres indicando si la acción realizada fue correcta o no.

Reset: Esta clase reinicia la unidad central de procesamiento. Envía al Wi –
POS una instrucción que hace que el equipo reinicie. Se utiliza en algunos
puntos de la aplicación principal para verificar que el funcionamiento es
correcto y que no hay pérdida de información, o en procesos que pueden
bloquear a la unidad central de procesamiento. Esta clase no recibe ningún
parámetro de entrada ni devuelve algún dato.

Tabla: Esta clase realiza la conversión de números en formato hexadecimal a
enteros. Recibe como parámetro de entrada un carácter en hexadecimal, lo
compara con una tabla que tiene y devuelve un entero, correspondiente al dato
en hexadecimal.

Tramas: Esta clase solicita a la unidad de procesamiento las tramas
respectivas para enviar a Internet, espera una respuesta y devuelve a la unidad
de procesamiento una trama. La clase recibe como parámetros de entrada tres
datos de tipo entero. El primero hace referencia a la instrucción enviada al Wi
– POS. El segundo hace referencia a la cantidad de bytes que se espera recibir
del Wi – POS, dependiendo de la instrucción solicitada. El tercero indica el
tamaño de la trama que devuelve el servidor en cantidad de caracteres, para
guardarlos en una matriz, convertirlos a enteros para luego pasarlos a

79

•
hexadecimal y enviarlos byte por byte al Wi – POS.

Modulo10: Esta clase verifica si el número de la tarjeta es un número válido
haciendo uso del algoritmo de chequeo de modulo 10(ver Anexo Marco
Teórico). Recibe como único parámetro una cadena de caracteres con el PAN
(Personal Account Number) y devuelve “verdadero” (true) si el número de la
tarjeta es un número válido, o “falso” (false) si éste es inválido.

Con estas clases, las aplicaciones principales pueden mantener contacto permanente
con la unidad central de procesamiento y con el usuario/funcionario a través de la
pantalla del teléfono.

4.3.3. Descripción de las aplicaciones principales.

A continuación se explicará la secuencia que siguen las aplicaciones de Carga de
Parámetros Iniciales y de Transacción de Pago ilustrando lo que se ve en la pantalla
del teléfono móvil utilizando el emulador del equipo Motorola iDEN i85s.
•
Carga de Parámetros Iniciales
Los parámetros iniciales se solicitan al servidor, el cual devuelve una trama con
ciertos parámetros que dependen del terminal que los solicita(Ver sección 3.3.1).
Esta trama se almacena en la unidad central de procesamiento y al momento de la
transacción se validan los diferentes datos con estos parámetros. La secuencia de
esta aplicación se da de la siguiente forma:
Pantalla Inicial

En esta pantalla se le informa al funcionario que
puede cargar los Parámetros Iniciales.

Figura 21. Pantalla Inicial

80

81
Figura 22. Carga de parámetros
en proceso

Figura 23. Carga de Parámetros
Iniciales
Carga de parámetros correcta.

Figura2 4,
Carga de parámetros
incorrecta
Carga de Parámetros en proceso
En esta pantalla se le informa al funcionario que se
está efectuando la carga de los Parámetros Iniciales
en el equipo. Durante la carga de los parámetros se
despliega una barra que muestra el progreso del
proceso. En este momento la aplicación se
comunica con el dispositivo y le solicita la trama de
Solicitud de Parámetros Iniciales, la cual es enviada
al servidor. El servidor devuelve una trama de
respuesta con todos los parámetros iniciales, que
recibe la aplicación y que inmediatamente es
enviada al dispositivo.

Confirmación de la carga de los parámetros

Se le informa al usuario que la carga de
parámetros iniciales ha sido exitosa y por lo tanto
ya se pueden realizar transacciones de pago.

Carga de parámetros incorrecta: En esta pantalla se
le informa al usuario que la solicitud y carga de
parámetros iniciales ha tenido problemas. Este
error ocurre cuando la trama de respuesta enviada
por el servidor al dispositivo no es la esperada y
hay información errónea en algún campo de la
trama.

Figura 25. Carga de Parámetros
Iniciales,
Error en el puerto serial

Figura 26. Carga de Parámetros
Iniciales,
Error en la conexión a Internet
Error en la comunicación con Wi – POS
Si durante el proceso