SlideShare una empresa de Scribd logo
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
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
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
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
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)
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
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
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.
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
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.
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
[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.

Más contenido relacionado

La actualidad más candente

Dermer1 5.6 complementaria
Dermer1 5.6 complementariaDermer1 5.6 complementaria
Dermer1 5.6 complementaria
dermercantil1
 
Diapositivas telemática
Diapositivas telemáticaDiapositivas telemática
Diapositivas telemática
Luis David
 
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
Myrian Medina
 
Dinero electronico
Dinero electronicoDinero electronico
Dinero electronico
sandraehernandez
 
Firma digital
Firma digitalFirma digital
Firma digital
olgaruizparedes
 
Calificación jurídica del mulero en el phising
Calificación jurídica del mulero en el phisingCalificación jurídica del mulero en el phising
Calificación jurídica del mulero en el phising
rafameca
 
Firma Digital
Firma DigitalFirma Digital
Firma Digital
alexanderbetancur19
 
Fraude cibernético
Fraude cibernéticoFraude cibernético
Fraude cibernético
Ulises Ubillus
 
Comercio electrónico y fraude en la red
Comercio electrónico y fraude en la redComercio electrónico y fraude en la red
Comercio electrónico y fraude en la red
Jennifermm2
 
Presentación clase 2 - e-Business
Presentación clase 2 - e-BusinessPresentación clase 2 - e-Business
Presentación clase 2 - e-Business
Juls Allen Zulueta
 
Medios de pago electronico
Medios de pago electronicoMedios de pago electronico
Medios de pago electronico
Julio Gómez
 
Venda sus productos_por_internet
Venda sus productos_por_internetVenda sus productos_por_internet
Venda sus productos_por_internet
Oscar Valbuena
 
Medios de pago dinero electrónico o digital
Medios de pago  dinero electrónico o digitalMedios de pago  dinero electrónico o digital
Medios de pago dinero electrónico o digital
jjreinacrespo00
 
Firmas Digitales
Firmas DigitalesFirmas Digitales
Firmas Digitales
cristinaverduga
 
Comercio electrónico y fraude en la red
Comercio electrónico y fraude en la redComercio electrónico y fraude en la red
Comercio electrónico y fraude en la red
gracii98
 

La actualidad más candente (15)

Dermer1 5.6 complementaria
Dermer1 5.6 complementariaDermer1 5.6 complementaria
Dermer1 5.6 complementaria
 
Diapositivas telemática
Diapositivas telemáticaDiapositivas telemática
Diapositivas telemática
 
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
Manual de procedimientos tecnicas encriptacion certificados digitales y firma...
 
Dinero electronico
Dinero electronicoDinero electronico
Dinero electronico
 
Firma digital
Firma digitalFirma digital
Firma digital
 
Calificación jurídica del mulero en el phising
Calificación jurídica del mulero en el phisingCalificación jurídica del mulero en el phising
Calificación jurídica del mulero en el phising
 
Firma Digital
Firma DigitalFirma Digital
Firma Digital
 
Fraude cibernético
Fraude cibernéticoFraude cibernético
Fraude cibernético
 
Comercio electrónico y fraude en la red
Comercio electrónico y fraude en la redComercio electrónico y fraude en la red
Comercio electrónico y fraude en la red
 
Presentación clase 2 - e-Business
Presentación clase 2 - e-BusinessPresentación clase 2 - e-Business
Presentación clase 2 - e-Business
 
Medios de pago electronico
Medios de pago electronicoMedios de pago electronico
Medios de pago electronico
 
Venda sus productos_por_internet
Venda sus productos_por_internetVenda sus productos_por_internet
Venda sus productos_por_internet
 
Medios de pago dinero electrónico o digital
Medios de pago  dinero electrónico o digitalMedios de pago  dinero electrónico o digital
Medios de pago dinero electrónico o digital
 
Firmas Digitales
Firmas DigitalesFirmas Digitales
Firmas Digitales
 
Comercio electrónico y fraude en la red
Comercio electrónico y fraude en la redComercio electrónico y fraude en la red
Comercio electrónico y fraude en la red
 

Similar a Aplicaciones Criptográficas en Entornos Económicos

Manual de procedimientos
Manual de procedimientosManual de procedimientos
Manual de procedimientos
Oscar
 
Seguridad en las transacciones
Seguridad en las transaccionesSeguridad en las transacciones
Seguridad en las transacciones
guest46247cd
 
Formas de Pago y Seguridad
Formas de Pago y SeguridadFormas de Pago y Seguridad
Formas de Pago y Seguridad
juan
 
Mecanismos de Pago y Aspectos de Seguridad
Mecanismos de Pago y Aspectos de SeguridadMecanismos de Pago y Aspectos de Seguridad
Mecanismos de Pago y Aspectos de Seguridad
chita21
 
Transacciones
TransaccionesTransacciones
Transacciones
MagaliQV
 
Protocolos de seguridad ssl
Protocolos de seguridad sslProtocolos de seguridad ssl
Protocolos de seguridad ssl
norelysmunoz
 
Infraestructura pk ix
Infraestructura pk ixInfraestructura pk ix
Infraestructura pk ix
ptrujillo82
 
Mecanismos de pago y aspectos de seguridad 5
Mecanismos de pago y aspectos de seguridad 5Mecanismos de pago y aspectos de seguridad 5
Mecanismos de pago y aspectos de seguridad 5
Jorge Tun
 
Act 8 pac f garcia
Act 8 pac f garciaAct 8 pac f garcia
Act 8 pac f garcia
Freddy Emerson Garcia Lasso
 
Mecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridadMecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridad
Realform studio
 
Unidad2
Unidad2Unidad2
Unidad2
jesus7garcia7
 
Unidad2
Unidad2Unidad2
Unidad2
karlasan
 
Investigación 3 presentacion
Investigación 3 presentacionInvestigación 3 presentacion
Investigación 3 presentacion
Junior Del Cid
 
Mecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridadMecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridad
Ivan
 
Ssl
SslSsl
Prospectiva e.commerce
Prospectiva e.commerceProspectiva e.commerce
Prospectiva e.commerce
Oscar
 
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE  SEGURIDADMECANISMO DE PAGO Y ASPECTOS DE  SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
Luis Arturo Uc
 
MECANISMOS DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMOS DE PAGO Y  ASPECTOS DE SEGURIDADMECANISMOS DE PAGO Y  ASPECTOS DE SEGURIDAD
MECANISMOS DE PAGO Y ASPECTOS DE SEGURIDAD
Luis Arturo Uc
 
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE  SEGURIDADMECANISMO DE PAGO Y ASPECTOS DE  SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
Luis Arturo Uc
 
Actividad 5 infraestructura pk ix
Actividad 5 infraestructura pk ixActividad 5 infraestructura pk ix
Actividad 5 infraestructura pk ix
ptrujillo82
 

Similar a Aplicaciones Criptográficas en Entornos Económicos (20)

Manual de procedimientos
Manual de procedimientosManual de procedimientos
Manual de procedimientos
 
Seguridad en las transacciones
Seguridad en las transaccionesSeguridad en las transacciones
Seguridad en las transacciones
 
Formas de Pago y Seguridad
Formas de Pago y SeguridadFormas de Pago y Seguridad
Formas de Pago y Seguridad
 
Mecanismos de Pago y Aspectos de Seguridad
Mecanismos de Pago y Aspectos de SeguridadMecanismos de Pago y Aspectos de Seguridad
Mecanismos de Pago y Aspectos de Seguridad
 
Transacciones
TransaccionesTransacciones
Transacciones
 
Protocolos de seguridad ssl
Protocolos de seguridad sslProtocolos de seguridad ssl
Protocolos de seguridad ssl
 
Infraestructura pk ix
Infraestructura pk ixInfraestructura pk ix
Infraestructura pk ix
 
Mecanismos de pago y aspectos de seguridad 5
Mecanismos de pago y aspectos de seguridad 5Mecanismos de pago y aspectos de seguridad 5
Mecanismos de pago y aspectos de seguridad 5
 
Act 8 pac f garcia
Act 8 pac f garciaAct 8 pac f garcia
Act 8 pac f garcia
 
Mecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridadMecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridad
 
Unidad2
Unidad2Unidad2
Unidad2
 
Unidad2
Unidad2Unidad2
Unidad2
 
Investigación 3 presentacion
Investigación 3 presentacionInvestigación 3 presentacion
Investigación 3 presentacion
 
Mecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridadMecanismos de pago y aspectos de seguridad
Mecanismos de pago y aspectos de seguridad
 
Ssl
SslSsl
Ssl
 
Prospectiva e.commerce
Prospectiva e.commerceProspectiva e.commerce
Prospectiva e.commerce
 
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE  SEGURIDADMECANISMO DE PAGO Y ASPECTOS DE  SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
 
MECANISMOS DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMOS DE PAGO Y  ASPECTOS DE SEGURIDADMECANISMOS DE PAGO Y  ASPECTOS DE SEGURIDAD
MECANISMOS DE PAGO Y ASPECTOS DE SEGURIDAD
 
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE  SEGURIDADMECANISMO DE PAGO Y ASPECTOS DE  SEGURIDAD
MECANISMO DE PAGO Y ASPECTOS DE SEGURIDAD
 
Actividad 5 infraestructura pk ix
Actividad 5 infraestructura pk ixActividad 5 infraestructura pk ix
Actividad 5 infraestructura pk ix
 

Más de jcfarit

Conceptos basicos de telefonia
Conceptos basicos de telefoniaConceptos basicos de telefonia
Conceptos basicos de telefonia
jcfarit
 
Manual de usuario Ruani
Manual de usuario RuaniManual de usuario Ruani
Manual de usuario Ruani
jcfarit
 
Unidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linuxUnidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linux
jcfarit
 
Arquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo LinuxArquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo Linux
jcfarit
 
Linq to sql 9
Linq to sql 9Linq to sql 9
Linq to sql 9
jcfarit
 
Linq to sql 8
Linq to sql 8Linq to sql 8
Linq to sql 8
jcfarit
 
Linq to sql 7
Linq to sql 7Linq to sql 7
Linq to sql 7
jcfarit
 
Linq to sql 6
Linq to sql 6Linq to sql 6
Linq to sql 6
jcfarit
 
Linq to sql 5
Linq to sql 5Linq to sql 5
Linq to sql 5
jcfarit
 
Linq to sql 4
Linq to sql 4Linq to sql 4
Linq to sql 4
jcfarit
 
Linq to sql 3
Linq to sql 3Linq to sql 3
Linq to sql 3
jcfarit
 
Linq to sql 2
Linq to sql 2Linq to sql 2
Linq to sql 2
jcfarit
 
Ejemplo Linq To SQL
Ejemplo Linq To SQLEjemplo Linq To SQL
Ejemplo Linq To SQL
jcfarit
 
ISO 27001 -6
ISO 27001 -6ISO 27001 -6
ISO 27001 -6
jcfarit
 
ISO 27001 - 5
ISO 27001 - 5ISO 27001 - 5
ISO 27001 - 5
jcfarit
 
ISO 27001 4
ISO 27001 4ISO 27001 4
ISO 27001 4
jcfarit
 
ISO 27001 -3
ISO 27001 -3 ISO 27001 -3
ISO 27001 -3
jcfarit
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
jcfarit
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
jcfarit
 
Curso ubuntuimprimible
Curso ubuntuimprimibleCurso ubuntuimprimible
Curso ubuntuimprimible
jcfarit
 

Más de jcfarit (20)

Conceptos basicos de telefonia
Conceptos basicos de telefoniaConceptos basicos de telefonia
Conceptos basicos de telefonia
 
Manual de usuario Ruani
Manual de usuario RuaniManual de usuario Ruani
Manual de usuario Ruani
 
Unidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linuxUnidad 3 gestion de procesos en linux
Unidad 3 gestion de procesos en linux
 
Arquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo LinuxArquitectura General del Sistema Operativo Linux
Arquitectura General del Sistema Operativo Linux
 
Linq to sql 9
Linq to sql 9Linq to sql 9
Linq to sql 9
 
Linq to sql 8
Linq to sql 8Linq to sql 8
Linq to sql 8
 
Linq to sql 7
Linq to sql 7Linq to sql 7
Linq to sql 7
 
Linq to sql 6
Linq to sql 6Linq to sql 6
Linq to sql 6
 
Linq to sql 5
Linq to sql 5Linq to sql 5
Linq to sql 5
 
Linq to sql 4
Linq to sql 4Linq to sql 4
Linq to sql 4
 
Linq to sql 3
Linq to sql 3Linq to sql 3
Linq to sql 3
 
Linq to sql 2
Linq to sql 2Linq to sql 2
Linq to sql 2
 
Ejemplo Linq To SQL
Ejemplo Linq To SQLEjemplo Linq To SQL
Ejemplo Linq To SQL
 
ISO 27001 -6
ISO 27001 -6ISO 27001 -6
ISO 27001 -6
 
ISO 27001 - 5
ISO 27001 - 5ISO 27001 - 5
ISO 27001 - 5
 
ISO 27001 4
ISO 27001 4ISO 27001 4
ISO 27001 4
 
ISO 27001 -3
ISO 27001 -3 ISO 27001 -3
ISO 27001 -3
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
 
ISO 27001
ISO 27001ISO 27001
ISO 27001
 
Curso ubuntuimprimible
Curso ubuntuimprimibleCurso ubuntuimprimible
Curso ubuntuimprimible
 

Último

edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
larapalaciosmonzon28
 
Inteligencia Artificial
Inteligencia ArtificialInteligencia Artificial
Inteligencia Artificial
YashiraPaye
 
Herramientas para los abogados, 3 herramientas
Herramientas para los abogados, 3 herramientasHerramientas para los abogados, 3 herramientas
Herramientas para los abogados, 3 herramientas
yessicacarrillo16
 
Gobernanza con SharePoint Premium de principio a fin
Gobernanza con SharePoint Premium de principio a finGobernanza con SharePoint Premium de principio a fin
Gobernanza con SharePoint Premium de principio a fin
Juan Carlos Gonzalez
 
Flows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos FeaturesFlows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos Features
Paola De la Torre
 
Plan de racionamiento de energía en Venezuela
Plan de racionamiento de energía en VenezuelaPlan de racionamiento de energía en Venezuela
Plan de racionamiento de energía en Venezuela
Gabrielm88
 
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
codesiret
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
KukiiSanchez
 
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajasSlideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
AdrianaRengifo14
 
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
KukiiSanchez
 
Plantilla carrier y tecnologia de TIGO.pptx
Plantilla carrier y tecnologia de TIGO.pptxPlantilla carrier y tecnologia de TIGO.pptx
Plantilla carrier y tecnologia de TIGO.pptx
edwinedsonsuyo
 
C1B3RWALL La red de cooperación de Madrid.pptx
C1B3RWALL La red de cooperación de Madrid.pptxC1B3RWALL La red de cooperación de Madrid.pptx
C1B3RWALL La red de cooperación de Madrid.pptx
Guillermo Obispo San Román
 
La Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docxLa Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docx
luiscohailatenazoa0
 
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdfMODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
SeleniaLavayen
 
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANOREVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
gisellearanguren1
 
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptxLA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
pauca1501alvar
 
trabajo monografico sobre el yandex .jim
trabajo monografico sobre el yandex .jimtrabajo monografico sobre el yandex .jim
trabajo monografico sobre el yandex .jim
jhonyaicaterodriguez
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
jgvanessa23
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
renzocruz180310
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
leia ereni
 

Último (20)

edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfqedublogs info.docx asdasfasfsawqrdqwfqwfqwfq
edublogs info.docx asdasfasfsawqrdqwfqwfqwfq
 
Inteligencia Artificial
Inteligencia ArtificialInteligencia Artificial
Inteligencia Artificial
 
Herramientas para los abogados, 3 herramientas
Herramientas para los abogados, 3 herramientasHerramientas para los abogados, 3 herramientas
Herramientas para los abogados, 3 herramientas
 
Gobernanza con SharePoint Premium de principio a fin
Gobernanza con SharePoint Premium de principio a finGobernanza con SharePoint Premium de principio a fin
Gobernanza con SharePoint Premium de principio a fin
 
Flows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos FeaturesFlows: Mejores Prácticas y Nuevos Features
Flows: Mejores Prácticas y Nuevos Features
 
Plan de racionamiento de energía en Venezuela
Plan de racionamiento de energía en VenezuelaPlan de racionamiento de energía en Venezuela
Plan de racionamiento de energía en Venezuela
 
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)
 
TIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololoTIC en educacion.rtf.docxlolololololololo
TIC en educacion.rtf.docxlolololololololo
 
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajasSlideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
Slideshare: definiciòn, registrarse, presentaciones, ventajas y desventajas
 
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
Morado y Verde Animado Patrón Abstracto Proyecto de Grupo Presentación de Edu...
 
Plantilla carrier y tecnologia de TIGO.pptx
Plantilla carrier y tecnologia de TIGO.pptxPlantilla carrier y tecnologia de TIGO.pptx
Plantilla carrier y tecnologia de TIGO.pptx
 
C1B3RWALL La red de cooperación de Madrid.pptx
C1B3RWALL La red de cooperación de Madrid.pptxC1B3RWALL La red de cooperación de Madrid.pptx
C1B3RWALL La red de cooperación de Madrid.pptx
 
La Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docxLa Inteligencia Artificial en la actualidad.docx
La Inteligencia Artificial en la actualidad.docx
 
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdfMODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
MODELOS MODERNOS DE TECLADOS Y PANTALLAS.pdf
 
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANOREVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
REVISTA TECNOLOGICA PARA EL DESARROLLO HUMANO
 
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptxLA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
LA GLOBALIZACIÓN RELACIONADA CON EL USO DE HERRAMIENTAS.pptx
 
trabajo monografico sobre el yandex .jim
trabajo monografico sobre el yandex .jimtrabajo monografico sobre el yandex .jim
trabajo monografico sobre el yandex .jim
 
El uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptxEl uso de las TIC en la vida cotidiana.pptx
El uso de las TIC en la vida cotidiana.pptx
 
INFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIAINFORMATICA Y TECNOLOGIA
INFORMATICA Y TECNOLOGIA
 
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIAMONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
MONOGRAFIA memoria RAM.docx trabajo DE TECNOLOGIA
 

Aplicaciones Criptográficas en Entornos Económicos

  • 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.