El documento describe los protocolos SSL y SET para realizar pagos electrónicos seguros en Internet. SSL proporciona cifrado y autenticación para proteger la transmisión de datos de tarjetas de crédito entre el comprador y el vendedor. SET especifica un protocolo que involucra al comprador, vendedor y entidad financiera para realizar la transacción de pago de manera que ninguna parte tenga acceso a la información de la otra. Ambos protocolos utilizan criptografía para mantener la privacidad y autenticar a las partes involucradas en

1. Aplicaciones Criptográficas en Entornos Económicos
Llorenç Huguet i Rotger, Josep Lluís Ferrer Gomila
Departamento de Ciencias Matemáticas e Informática, Universidad de les Illes Balears
Carretera de Valldemossa km. 7.5, Palma de Mallorca, I. Balears, 07122
{dmilhr0, dijjfg}@uib.es
1. Introducción
El tema del pago en redes abiertas ha adquirido una gran relevancia en los últimos años
debido al creciente desarrollo del comercio electrónico. Los sistemas de pago
electrónicos deben proporcionar la infraestructura necesaria para facilitar el pago en las
transacciones realizadas a través de la red Internet. Son tan importantes y necesarios
que, de no llegar a soluciones satisfactorias, el desarrollo del comercio electrónico se
podría ver seriamente frenado.
Los sistemas convencionales de pago utilizados en el mundo basado en papel no
se adaptan perfectamente al mundo electrónico. Este problema debe ser abordado y
solucionado desde una perspectiva pluridisciplinar (jurídica, técnica, económica, etc.). A
priori puede parecer chocante el hecho de que esquemas de pago que per se son
electrónicos, no encajen perfectamente y de forma inmediata como esquemas de pago
para las transacciones realizadas en Internet. Nos estamos refiriendo, concretamente, a
los sistemas de pago basados en tarjeta. Y es que no podemos olvidar, que el hecho de
que los intercambios sean cara a cara en el comercio presencial tradicional, junto con el
justificante escrito en soporte papel y con firma manuscrita, suponen elementos de
seguridad que deben tener su traducción o equivalente en el mundo electrónico.
De todas formas, algunos de los sistemas de pago del mundo real (por
contraposición al mundo virtual) son más o menos aceptados como métodos de pago en
Internet (como es el caso de las tarjetas de crédito). No obstante, su uso se ve frenado
por las reticencias de los usuarios clientes, que no acaban de confiar en la seguridad de
las transacciones realizadas exclusivamente por medios electrónicos. Para los
vendedores tampoco son la solución ideal. Por ejemplo, en el caso concreto de las
tarjetas de crédito, hasta fechas muy recientes, los costes por transacción eran muy

2. elevados, hecho que las entidades financieras justificaban por el alto riesgo que
suponían este tipo de operaciones. Desde el punto de vista del vendedor existe el
problema de que no tiene garantía de la identidad del usuario de la tarjeta, que puede no
ser su titular legítimo. Este riesgo es un motivo adicional para que los potenciales
vendedores sean reacios a aceptar estos nuevos medios de pago. Las reticencias de los
clientes conducen a un ritmo de ventas inferior al esperado, lo que supone un fracaso
para el empresario que decide utilizar las nuevas tecnologías para desarrollar
plataformas de comercio electrónico.
La criptografía es un elemento indispensable para proporcionar seguridad a las
transacciones electrónicas, y más concretamente al pago electrónico basado en tarjeta de
crédito. En los siguientes apartados se describirán dos protocolos concretos (SSL y
SET) que deberían servir para aumentar la confianza de los usuarios en los nuevos
medios de contratación electrónicos.
2. SSL
Algunas implementaciones del pago con tarjeta de crédito relacionadas con
transacciones electrónicas a través de Internet, obligan al comprador a enviar los datos
de la tarjeta por un canal diferente a la propia red de redes (transmisión por fax o
comunicación telefónica). Una alternativa a estas soluciones sería enviar los datos de la
tarjeta de crédito por medio de una comunicación segura a través de Internet, y tratar la
transacción en su parte de validación por medios convencionales o ligeramente
modificados (el llamado TPV -Terminal Punto de Venta- virtual).
Para que efectivamente la transferencia sea segura son necesarios dos servicios
de seguridad. Por una parte deben cifrarse las comunicaciones entre comprador y
vendedor para evitar que posibles atacantes puedan interceptar los detalles de la tarjeta
de crédito. Por otra parte, el vendedor debe autenticarse de tal manera que no sea
posible que un atacante pueda suplantarle, con el objetivo de obtener los datos de la
tarjeta del cliente. También sería deseable que el comprador se autenticase, pero ni en
las ventas a distancia (en el mundo real) ni en los pedidos por vía telefónica, se exige
este requisito. Generalmente la autenticación del cliente suele dejarse para la etapa de
entrega del producto. Este sistema sólo es útil para el comercio de bienes materiales,
pues en el caso de bienes o servicios digitales no se produce la deseada personación que
permita autenticar al comprador. De esta manera ya estamos estableciendo un primer

3. límite al posible uso de un sistema sin autenticación previa del comprador, a no ser que
el vendedor quiera asumir el consiguiente riesgo.
En la red Internet, los anteriores servicios de seguridad (confidencialidad de la
comunicación y autenticación del servidor) se proporcionan habitualmente con el uso
del protocolo SSL (Secure Socket Layer). SSL es un protocolo de propósito genérico
que permite el establecimiento de conexiones seguras entre entidades correspondientes a
protocolos de nivel de aplicación (login remoto, correo electrónico, transferencia de
ficheros, etc.), aunque seguramente el protocolo de aplicación que más viene utilizando
SSL es el protocolo http (hypertext transfer protocol) utilizado en el web. El protocolo
SSL fue desarrollado por la compañía Netscape en el año 1994, habiendo evolucionado
hasta una última versión que recibe el nombre de TLS (Transport Layer Security),
aunque la más utilizada en este momento es la versión 3.0 de SSL.
En SSL antes de proteger la información que ha de ser intercambiada (entre la
que se puede encontrar los datos de la tarjeta de crédito) se produce una negociación
entre el programa que utiliza el comprador (típicamente un navegador) y el servidor de
comercio electrónico del vendedor. La secuencia, de forma resumida, es como sigue:
1.- C V:
v_aleatorioC, id_sesión, alg_prop
2.- V C:
v_aleatorioV, id_sesión, alg_escog, certificadoV
3.- C V:
PUV(secreto)
4.- V C:
EKv(datos1)
5.- C V:
EKc(datos2)
...
...
...
...
En el primer paso el navegador del comprador envía un valor aleatorio, uno de
los elementos que se utilizará para generar el material criptográfico necesario, y un
identificador de la sesión, que podrá ser útil para evitar renegociaciones en
transacciones cercanas en el tiempo entre las mismas entidades. El último argumento es
una lista ordenada, por orden de preferencia del usuario, de algoritmos criptográficos.
Deben negociarse: un algoritmo de clave simétrica para conseguir el servicio de
confidencialidad (por ejemplo DES, 3DES, IDEA, RC2, RC4, etc.), un algoritmo para
el servicio de autenticación y de intercambio de claves (por ejemplo RSA o DiffieHellman), y finalmente un algoritmo para garantizar la integridad de los datos
intercambiados (por ejemplo, MD5 o SHA).
En el segundo paso el servidor del vendedor también envía un valor aleatorio,
que se utilizará para generar el material criptográfico necesario, y el identificador de la

4. sesión que envió el navegador. El último argumento es el conjunto de algoritmos
criptográficos que ha escogido el servidor, de entre los propuestos por el cliente. Si
entre los algoritmos propuestos por el cliente no hubiera uno de cada servicio válido
para el servidor, debería abortarse la sesión.
A continuación el servidor envía al navegador un certificado de clave pública. Se
trata de un documento electrónico que vincula la clave pública del vendedor, con la
identidad del mismo. De esta manera el comprador puede tener la garantía de que está
dialogando con una máquina bajo el control del vendedor que posee el nombre de
dominio al que se ha conectado.
En el tercer paso, el navegador genera un parámetro secreto que deberá ser
conocido por el servidor, pero sólo por el servidor. Para que así sea, cifra este valor con
la clave pública del servidor, pues de esta manera sólo él, con su clave privada, podrá
tener conocimiento de ese parámetro secreto. A partir de este parámetro secreto (y los
valores aleatorios de los primeros pasos) ambas entidades generan claves secretas de
sesión (una para cada sentido) y claves secretas de integridad (también una para cada
sentido de la comunicación). Una vez que se han generado estas claves, ya puede
empezar la fase de intercambio de datos. El uso de la criptografía simétrica y de las
funciones de integridad con parámetro secreto, permitirá que la comunicación de los
datos sea confidencial, con el servicio de integridad, y con autenticidad (aunque
generalmente sólo del servidor).
3. SET
El ámbito del protocolo SET se ciñe a la fase de pago de las transacciones electrónicas.
Las especificaciones de este protocolo aclaran que las funciones para la fase de compra,
negociación del precio, selección del método de pago, etc., deben ser desarrolladas por
otros protocolos. SET sólo interviene una vez que el comprador ha decidido qué va a
comprar, a qué precio, y que va a utilizar una tarjeta para realizar el pago.
En una transacción por vía telefónica, el comprador proporciona los datos de su
tarjeta al comerciante, el cual contacta con su entidad financiera con el objetivo de
obtener la autorización del pago. Esta entidad financiera, a su vez, puede obtener la
autorización de entidad que emitió la tarjeta a través de las redes financieras operadas
por la asociación de tarjetas (por ejemplo, Visa o MaterCard). Estas redes privadas hace
tiempo que existen y utilizan protocolos propietarios que operan sobre enlaces
dedicados con mecanismos de seguridad adecuados en operación. Por tanto, existe una

5. infraestructura de enlaces y ordenadores para procesar las transacciones. De hecho, SET
asume la existencia de estas redes y sólo especifica las reglas de diálogo entre el
comprador y el vendedor, y entre el vendedor y una entidad denominada pasarela de
pago. El modelo previsto en SET, con sus participantes, es el siguiente:
Red Financiera
FUERA
DE SET
FUERA
DE SET
Entidad Financiera
Emisor de
la tarjeta
SET
SET
Vendedor
Comprador
El protocolo SET consiste en un conjunto de pares de mensajes petición /
respuesta, como puede verse a continuación:
1.- C V:
PInitReq = idioma, ID_TC, retoC, IDmarca, IDbanco
2.- V C:
PInitRes = SignV(ID_T, fecha, retoC, retoV), CertF, CertV
3.- C V:
PReq = OI, H(PI), Sign_dualC(OI, PI),
EK1(PI), PUF(K1), H(OI)
4.- V F:
AuthReq = EK2[SignV(Info_auth)], PUF(K2)
5.- F N:
Autorización por la red bancaria [fuera de SET]
6.- F V:
AuthRes = EK3[SignF(Info_auth_res)], PUV(K3)

6. 7.- V C:
PRes = SignV(ID_T, retoC, código, resultado)
Uno de los objetivos de SET es que el vendedor no tenga acceso a los datos financieros
del comprador, y que la entidad financiera no tenga acceso a los datos relativos al
producto o servicio adquirido, proporcionando además el servicio de no repudio de las
partes implicadas en la transacción. Para conseguir los anteriores objetivos es preciso
utilizar técnicas de criptografía clásica y de criptografía asimétrica.
El proceso de SET se inicia tras la presentación al comprador de un formulario
de orden de compra rellenado, cuyo contenido haya sido aceptado. Cómo se han
seleccionado los productos y cómo se presenta la orden de compra al usuario queda
fuera del ámbito de SET. El mensaje PInitReq sirve para indicar al vendedor que el
comprador está preparado para pagar los bienes o servicios acordados, y contiene la
siguiente información:
 idioma: idioma que utiliza el comprador
 ID_TC: un identificador local de la transacción
 retoC: un valor numérico que será utilizado en la respuesta del vendedor para
garantizar que la transmisión es "en tiempo real"
 IDmarca: la marca de la tarjeta que se utilizará para realizar el pago (por ejemplo, Visa
o MasterCard)
 IDbanco: número de identificación del banco del comprador
Tras la recepción del anterior mensaje. el vendedor envía el mensaje PInitRes, que
contiene los siguientes datos:
 ID_T: el vendedor genera un identificador global de la transacción que combinado
con el identificador del comprador sirve par formar un identificador de transacción
único, que identificará una compra específica respecto de los demás posibles
mensajes de compra recibidos
 fecha: el día y hora en el que se realiza la transacción
 retoC: el valor numérico que envió el comprador
 retoV: un valor numérico generado por el vendedor
 CertF: el certificado de clave pública de la entidad financiera del vendedor
 CertV: el certificado de clave pública del vendedor
Los certificados de clave pública remitidos contienen las claves públicas que serán
necesarias en futuros mensajes. Por otra parte, obsérvese que los cuatro primeros
parámetros van firmados por el vendedor. De esta manera, y si el valor retoC coincide

7. con el que generó el comprador, éste podrá estar seguro de que está dialogando con un
vendedor concreto y autorizado a realizar transacciones SET.
Los mensajes de orden de compra ejecutan el pedido efectivo que el comprador
realiza al vendedor. Es el par de mensajes más complejo del protocolo de pago. El
comprador envía dos elementos, la información del pedido (OI por Order Information)
y las instrucciones de pago (PI por Payment Instructions). El elemento OI contiene los
datos que identifican la descripción del pedido. El elemento PI contiene los datos de la
tarjeta de crédito del comprador, y los identificadores de pedido y transacción. Este
último elemento se cifra con la clave pública de la entidad financiera del vendedor, de
tal manera que el vendedor no tendrá acceso a su contenido. Posteriormente se reenviará
a la entidad financiera en la fase de autorización.
El elemento OI contiene la siguiente información (mucha de ella de la fase de
inicialización):
OI = ID_T, retoC, retoV, IDbanco, IDmarca, H(pedido)
El uso del reto generado por el vendedor sirve para garantizar que se trata de un mensaje
vinculado a la transacción en curso. El último elemento es un resumen de la
información relativa al pedido:
pedido = descripción, cantidad, salt
El valor aleatorio salt es generado por el comprador para prevenir posibles ataques por
fuerza bruta (o basados en diccionario). El parámetro cantidad indica el valor
económico de la transacción.
Para construir el elemento PI son necesarios dos elementos. El primero son los
datos de la tarjeta:
datos_tarjeta = núm_tarjeta, fecha_expiración, núm_secreto, nonce
donde núm_secreto es un número compartido entre el comprador, la pasarela de pagos y
la entidad financiera del comprador; nonce es un valor aleatorio para evitar ataques de
repetición y de fuerza bruta. El segundo elemento necesario es el resumen de la
información relativa al pedido. Entonces, el elemento PI es de la siguiente forma:
PI = ID_T, H(pedido), cantidad, IDV, PUF(datos_tarjeta)
Obsérvese que para proporcionar mayor seguridad al intercambio, los datos
correspondientes a la tarjeta han sido cifrados con la clave pública de la entidad
financiera. Posteriormente también son cifrados con un algoritmo de criptografía
simétrica (junto con otra información). También puede verse que en las instrucciones de

8. pago no se encuentra directamente información del pedido, sino tan sólo un resumen del
mismo, H(pedido).
En el mensaje PReq se utiliza un tipo de firma especialmente importante en el
protocolo SET: la firma dual. Para generar esta firma debe procederse de la siguiente
manera:
 obtener el resumen (aplicar una función hash) por separado de OI y PI
 concatenar los dos resúmenes y aplicar la función hash al resultado
 aplicar el cifrado de clave pública al anterior resumen ("firmar")
 adjuntar los resúmenes, H(OI) y H(PI), para que los destinatarios puedan verificar la
firma dual sin necesidad de tener acceso al contenido de la parte del mensaje que no
les corresponde
Una vez que el vendedor ha recibido la orden de compra del comprador, extrae
las dos partes fundamentales (OI y PI), y verifica la firma dual (para lo que necesitará el
certificado de clave pública del comprador). A continuación, habitualmente, aunque hay
otras posibilidades, el vendedor pasará a la etapa de autorización antes de enviar la
pareja del mensaje PReq, es decir, PRes.
El proceso de autorización permite al vendedor verificar que el comprador tiene
crédito para el pedido que ha realizado, y para obtener el permiso de cargo de la
transacción a la tarjeta del comprador. En la petición de autorización el vendedor envía
a su entidad financiera información relativa al pedido, firmada y cifrada. Las
instrucciones de pago (PI) del comprador también se envían en esta petición. Más
concretamente encontramos la siguiente información:
Info_auth = ID_T, fecha, cantidad, PI, H(pedido), H(OI),
datos_vendedor, datos_comprador, firma_dual
Obsérvese que en la anterior información encontramos un resumen del pedido. La
entidad financiera verificará que coincida con el contenido en las instrucciones de pago
(PI). Si es así, la entidad financiera sabrá que el comprador y el vendedor están de
acuerdo sobre los bienes o servicios y la cantidad a ser cargada. La firma dual sobre PI
permite verificar que esta orden procede del comprador. El resumen de OI en la petición
del vendedor demuestra el conocimiento de los datos del OI que va firmado en la firma
dual, permitiendo demostrar el acuerdo en los datos del pedido sin necesidad de revelar
estos datos a la entidad financiera. También se envían datos relativos al comprador,
como la dirección de remisión de la factura (obtenidos por vías externas al protocolo
SET), y otros relativos al vendedor.

9. Tras haber recibido la petición de autorización, la entidad financiera descifra las
distintas partes del mensaje, verifica las firmas, y comprueba la consistencia entre los
detalles del pedido enviado por el vendedor y los que se encuentran en las instrucciones
de pago, PI. A continuación la entidad financiera obtiene la autorización a través de la
red bancaria existente. Si recibe una autorización positiva de la entidad emisora del
comprador, la entidad financiera del vendedor prepara el mensaje de respuesta de
autorización para el vendedor, que incluye el código de autorización del emisor. La
información contenida en la respuesta es:
Info_auth_res = ID_T, cantidad, código, datos_captura
Tras recibir una autorización correcta, el vendedor puede enviar los bienes al
comprador. Una autorización correcta indica que el emisor de la tarjeta ha verificado los
detalles de la tarjeta y el límite del crédito, y por tanto el pedido puede ser cursado.
La respuesta que envía el vendedor al comprador contiene el status de la
transacción y los códigos de respuesta disponibles. El código indica si se han
completado los pasos de autorización o captura. El campo resultado contiene los
códigos de autorización o captura, si es que se han producido estos pasos. Estos códigos
se generan en la red bancaria para autorizar y compensar la transacción, y pueden
aparecer en el cargo mensual de la tarjeta del comprador.
4. SET y SSL
Algunos autores han visto SSL y SET como competidores que comparten un mismo
objetivo. De hecho no tiene porqué ser así, pudiendo llegar a ser complementarios. SSL,
tal como se ha visto, puede servir para proteger información en tránsito, y para dar
autenticidad del servidor al cliente. Los servicios de seguridad que proporciona SSL son
limitados. Por su parte, SET se centra exclusivamente en la fase de pago, y por tanto
quedan fuera de su ámbito las fases de negociación y de entrega (esta última
especialmente a ser considerada en el caso de bienes y servicios digitales). Por tanto,
parece claro que podría utilizarse SSL para las fase previas y posteriores a la fase de
pago, y utilizar el protocolo SET para esta fase concreta.
SSL no proporciona no repudio en origen, y por tanto esto significa que
comprador y vendedor pueden negar a posteriori haber intervenido en una determinada
transacción electrónica. En estas primeras etapas del comercio electrónico, y en las
transacciones de bajo coste (por ejemplo, la compra de un libro por medios
electrónicos), el vendedor estará dispuesto a asumir que el comprador niegue a

10. posteriori haber realizado el pedido, con los consiguientes costes que le pueda suponer.
También a la inversa, el comprador está dispuesto a asumir que el vendedor no envíe el
producto supuestamente encargado (siempre asumiendo que su entidad financiera
deberá devolverle el importe de la transacción de la operación no realizada). Pero
pensemos en transacciones de un nivel más elevado, y llegaremos al convencimiento de
que el modelo basado exclusivamente en SSL no es estrictamente adecuado.
También hay que indicar que el hecho de comunicar los datos de la tarjeta al
vendedor, supone asumir un riesgo no siempre deseado. Esto no es estrictamente nuevo,
y de hecho este riesgo se asume también en las transacciones presenciales. Nos estamos
refiriendo al uso fraudulento de esos datos en poder del vendedor, por parte del propio
vendedor o de terceros. Periódicamente pueden leerse noticias de desarticulaciones de
redes que se dedican a obtener esos datos, a través de terminales legítimos o no
(restaurantes, tiendas, terminales bancarios falsos, etc.). La única novedad que introduce
la no presencialidad es el hecho de no saber realmente con quién se está dialogando.
La conclusión es que SSL no es la vía más adecuada para realizar pagos con
tarjeta de crédito a través de Internet, siendo recomendable el uso del protocolo SET. La
siguiente cuestión sería por qué SET, que corrige esas deficiencias, no es más utilizado.
La respuesta más clara la encontramos en la complejidad de la especificación. El
esfuerzo para desarrollar y verificar los programas asociados a SET es considerable.
Otro motivo que explica el retraso en la implantación efectiva de SET la
encontramos en la incorporación de la firma electrónica. En SET, y ese es precisamente
uno de sus puntos fuertes, comprador y vendedor deben disponer de su firma digital, y
de sus correspondientes certificados digitales. En el caso de SSL, es opcional que el
cliente disponga de un certificado de clave pública. Obviamente el hecho de que sea
más restrictivo SET, es decir, que obligue a los compradores a disponer de un
certificado de clave pública, frena su implantación. En un futuro cercano cuando todos
los usuarios dispongan de esa posibilidad, será más viable el uso de SET.
5. Conclusiones
Las tarjetas de crédito son un medio de pago que está demostrando con su relativo éxito
su adecuación para los pagos en las transacciones de comercio electrónico de Internet.
Por una parte disponemos de una amplia base de usuarios a lo largo del mundo que
disponen y utilizan tarjetas de crédito en el comercio convencional, y que desean (con
reticencias por la falta de seguridad apreciada) utilizarlas en los pedidos electrónicos.

11. Por otra parte tenemos un colectivo de marcas de tarjeta de crédito, que prácticamente
son aceptadas en todo el mundo, y que de forma inherente proporcionan la posibilidad
de utilizar múltiples divisas en las operaciones.
Como parte negativa hay que reconocer que las transacciones no presenciales,
que es el caso de Internet, son inseguras y susceptibles de padecer cierto nivel de fraude
(como de hecho así sucede). Esto es debido, en general, a que no hay identificación del
usuario de la tarjeta, ni justificante escrito y firmado de la operación y ni, en última
instancia, utilización de la tarjeta en sentido estricto, que puede seguir en poder del
titular legítimo. Por tanto hay que protegerse frente a los posibles ataques que pueden
padecerse.
En esta ponencia se ha revisado el protocolo SSL, que proporciona dos
funciones básicas de seguridad. En primer lugar, permite tener la seguridad de que el
vendedor con el que se está tratando es efectivamente quien dice ser. En segundo lugar,
se produce un cifrado del enlace, de tal manera que los detalles de la tarjeta de crédito
no pueden ser interceptados en tránsito. Así se resuelven dos problemas, que aunque se
pueda alegar que no son los que provocan mayores problemas en las transacciones
electrónicas, pueden servir para dar mayor confianza a los compradores, y por tanto
mayor posibilidad de negocio a los empresarios.
SET aparece como un protocolo que puede resolver todos los problemas de
seguridad ligados a los pagos con tarjeta de crédito en Internet. Por desgracia su
aceptación no ha sido la deseada, pero en un futuro no muy lejano debe aparecer alguna
alternativa que sí tenga la aceptación del mercado.
Bibliografía
[1]
D. Abrazhevich: "Classification and Characteristics of Electronic Payment
Systems"; EC-Web 2001, LNCS 2115, pp. 81-90, Springer Verlag, 2001.
[2]
N. Asokan, P.A. Janson, M. Steiner y M. Waidner: "The State of the Art in
Electronic Payment Systems"; IEEE Computer, pp. 28-35, 1997.
[3]
G. Drew: "Using SET for Secure Electronic Commerce"; ed. Prentice-Hall,
1998.
[4]
A. Freier, P. Karlton y P. Kocher: "The SSL Protocol: Version 3.0"; Netscape
Communication Corp., noviembre de 1996.
http://home.netscape.com/eng/ssl3/index.html

12. [5]
MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book
1: Business Description Version 1.0"; mayo de 1997.
http://www.setco.org
[6]
MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book
2: Programmer's Guide Version 1.0"; mayo de 1997.
http://www.setco.org
[7]
MasterCard y Visa: "Secure Electronic Transaction (SET) Specification - Book
3: Formal Protocol Definition Version 1.0"; mayo de 1997.
http://www.setco.org
[8]
D. O'Mahony, M. Pierce y H. Tewari: "Electronic Payment Systems for ECommerce"; ed. Artech House, segunda edición, 2001.
[9]
E. Rescorla: "SSL and TLS: Designing and Building Secure Systems"; ed.
Addison-Wesley, 2001.