|
ASPECTOS
A TENER EN CUENTA PARA
IMPLANTAR UNA SOLUCIÓN DE COMERCIO ELECTRÓNICO SEGURA
Y EFECTIVA
(Cuarta Parte)
d.)
Criterios de Seguridad.
La proliferación
de estos sistemas de pago produce como se ha comentado anteriormente
una gran variedad de sistemas de pago que suponen un mal asentamiento
del comercio electrónico. Para ello, se han establecido
unos criterios de seguridad que todo sistema de pago por medios
no seguros, como es el caso de Internet, debe satisfacer para
de este modo impedir cualquier tipo de fraude. Estos criterios
son los siguientes:
Integridad:
Ningún dato puede ser modificado ni durante ni
después de la conexión. Debe por tanto darse
en los datos enviados y en los recibidos. Se consigue con
sistemas de encriptación como puede ser la firma digital
o la emisión de certificados (aplicación del
sistema de encriptación asimétrico RSA y el
algoritmo unidireccional hash).
Autenticación
de la procedencia de los datos. Todas las entidades participantes
en la transacción deben estar debidamente autentificadas
antes de comenzar la compra. Dicha autenticación
también se consigue con la firma digital, ya que
es ésta la que nos permite conocer gracias a las
Autoridades de Certificación o terceras partes de
confianza (Trusted Third Paties) quién es el que
realizó la transacción (cliente), quién
nos envió productos (proveedor), o quién entró
en nuestras páginas o bases de datos.
Confidencialidad
en el envío. Ninguna persona ajena a la transacción
puede tener acceso a los datos. Más aún, las
entidades implicadas en la compra no deberían conocer
más datos que los imprescindibles para realizar su
función. De este modo, el Vendedor no tendría
porque tener acceso a los datos financieros del cliente
y el banco tampoco debería conocer la lista de los
artículos adquiridos. La confidencialidad se consigue
con técnicas criptográficas (por ejemplo el
sistema de encriptación simétrico DES) o con
protocolos de comunicación seguros como el SSL (Secure
Soket Layer)
No
repudio de lo realizado, enviado, recibido o contratado.
Debe garantizarse que una vez finalizada la compra ninguna
de las partes pueda negar haber participado en ella. Es
decir, al finalizar la transacción debe quedar algo
equivalente a un Recibo de compra firmado. Independientemente
de este criterio, la ley española establece que todo
cliente que participe en una compra a distancia tiene el
derecho a negar su participación en ella. Éste
efecto se consigue con la asunción expresa de ambas
partes del mencionado efecto. El contrato de venta, suministro
o distribución debe expresar dicha cualidad, de forma
que no pueda ser rechazado o negado.
Por tanto todo
sistema de pago on-line deberá en la medida de lo posible,
cumplir con estos criterios de seguridad. En la actualidad el protocolo
de seguridad SET cumple con estos cuatro requisitos, también
se produce un efecto parecido con el protocolo seguro de comunicación
SSL y los Certificados X509.
e.) Soluciones
seguras (contenidos facilitados por Oscar Conesa).
Secure
Socket Layer (SSL) y los Certificados X509v3.
El protocolo
SSL fue desarrollado por Netscape para permitir confidencialidad
y autenticación en Internet. SSL opera como una capa adicional
entre Internet y las aplicaciones, esto permite que el protocolo
sea independiente de la aplicación, siendo posible utilizar
FTP, Telnet y otras aplicaciones además de HTTP.
Para establecer
una comunicación segura utilizando SSL se tienen que seguir
una serie de pasos. Primero se debe hacer una solicitud de seguridad.
Después de haberla hecho, se deben establecer los parámetros
que se utilizarán para SSL. Esta parte se conoce como SSL
Handshake. Una vez se haya establecido una comunicación
segura, se deben hacer verificaciones periódicas para garantizar
que la comunicación sigue siendo segura a medida que se
transmiten datos. Tras finalizar la transacción se termina
SSL.
Solicitud
de SSL:
Antes de que
se establezca SSL, se debe hacer una solicitud. Típicamente
esto implica un cliente haciendo una solicitud de un URL a un
servidor que soporte SSL. SSL acepta solicitudes por un puerto
diferente al utilizado normalmente para ese servicio. Una vez
se ha hecho la solicitud, el cliente y el servidor empiezan a
negociar la conexión SSL, es
decir, hacen
el SSL Handshake.
SSL Handshake:
Durante el
hanshake se cumplen varios propósitos. Se hace autenticación
del servidor y opcionalmente del cliente, se determina que algoritmos
de criptografía serán utilizados y se genera una
llave secreta para ser utilizada durante el intercambio de mensajes
subsiguientes durante la comunicación SSL.
Los pasos
que se siguen son los siguientes:
- Client
Hello: El "saludo de cliente" tiene por objetivo informar al
servidor qué algoritmos de criptografía puede
utilizar y solicita una verificación de la identidad
del servidor. El cliente envía el conjunto de algoritmos
de criptografía y compresión que soporta y un
número aleatorio. El propósito del número
aleatorio es para que en caso de que el servidor no posea un
certificado para comprobar su identidad, aún se pueda
establecer una comunicación segura utilizando un conjunto
distinto de algoritmos. Dentro de los protocolos de criptografía
hay un protocolo de intercambio de llave que define como cliente
y servidor van a intercambiar la información, los algoritmos
de llave secreta que definen que métodos pueden utilizar
y un algoritmo de hash de una sola vía. Hasta ahora no
se ha intercambiado información secreta, solo una lista
de opciones.
- Server
Hello: El servidor responde enviando su identificador digital
el cual incluye su llave pública, el conjunto de algoritmos
criptográficos y de compresión y otro número
aleatorio. La decisión de que algoritmos serán
utilizados está basada en el más fuerte que tanto
cliente como servidor soporten. En algunas situaciones el servidor
también puede solicitar al cliente que se identifique
solicitando un identificador digital.
- Aprobación
del Cliente: El cliente verifica la validez del identificador
digital o certificado enviado por el servidor. Esto se lleva
a cabo desencriptando el certificado utilizando la llave pública
del emisor y determinando si este proviene de una entidad certificadora
de confianza. Después se hace una serie de verificaciones
sobre el certificado, tales como fecha, URL del servidor, etc.
Una vez se ha verificado la autenticidad de la identidad del
servidor. El cliente genera una llave aleatoria y la encripta
utilizando la llave pública del servidor y el algoritmo
criptográfico y de compresión seleccionado anteriormente.
Esta llave se le envía al servidor y en caso de que el
handshake tenga éxito será utilizada en el envío
de futuros mensajes durante la sesión.
- Verificación:
En este punto ambas partes conocen la llave secreta, el cliente
por que la generó y el servidor por que le fue enviada
utilizando su llave pública, siendo la única forma
posible de desencriptarla utilizando la llave privada del servidor.
Se hace una última verificación para comprobar
si la información transmitida hasta el momento no ha
sido alterada. Ambas partes se envían una copia de las
anteriores transacciones encriptada con la llave secreta. Si
ambas partes confirman la validez de las transacciones, el handshake
se completa, de otra forma se reinicia el proceso.
Ahora ambas partes
están listas para intercambiar información de manera
segura utilizando la llave secreta acordada y los algoritmos criptográficos
y de compresión. El handshake se realiza solo una vez y se
utiliza una llave secreta por sesión.
En la figura
se ilustra el proceso de handshake:
Intercambio
de datos:
Ahora que
se ha establecido un canal de transmisión seguro SSL, es
posible el intercambio de datos. Cuando el servidor o el cliente
desea enviar un mensaje al otro, se genera un digest (utilizando
un algoritmo de hash de una vía acordado durante el handshake),
encriptan el mensaje y el digest y se envía, cada mensaje
es verificado utilizando el digest.
Terminación
de una sesión SSL:
Cuando el
cliente deja una sesión SSL, generalmente la aplicación
presenta un mensaje advirtiendo que la comunicación no
es segura y confirma que el cliente efectivamente desea abandonar
la sesión SSL.
¿Como
implantamos el protocolo SSL?
El sistema
más utilizado en la actualidad para garantizar pagos seguros
por Internet es el SSL (Secure Socket Layer), un protocolo de
seguridad que se ha convertido en un estándar de Internet
y que viene incluido por defecto en los navegadores Microsoft
Explorer y Netscape Navigator. Lo que permite una implantación
sencilla del sistema de pago ya que el cliente puede comenzar
a comprar sin tener que realizar ningún proceso de autenticación
previa.
Para crear
un sistema de pago electrónico basado en SSL es necesario
conseguir un certificado electrónico para el Vendedor,
generalmente se obtiene de la empresa Verisign (filial de RSA
Data Security Inc. y principal Autoridad Certificadora mundial).
Verisign está considerada por Microsoft y Netscape como
CA de confianza por lo que por defecto viene activada en sus respectivos
navegadores.
Una vez realizado
el pago, el Vendedor obtiene el PIN (Personal Identification Number)de
la tarjeta de crédito del cliente, pasando a continuación
a ejecutar el pago a través del método de comunicación
existente entre el vendedor y el banco, ya que de esta forma puede
enviar estos datos a su entidad financiera que será capaz
de realizar la transferencia bancaria.
En España,
Banesto ha sido pionera en ofrecer un sistema completo de pago
electrónico basado en SSL e incluso ha creado su propia
tarjeta de crédito para este propósito la Virtual
C@sh. La comunicación entre el Vendedor y Banesto se realiza
a través de un protocolo privado.
Otra opción
que han ofrecido varios bancos es la de utilizar un Terminal Punto
de Venta (TPV) para realizar la transferencia. Se conecta el TPV
al servidor del Vendedor y mediante un software CGI se realiza
la comunicación.
Los servidores
seguros SSL los podremos notar porque en al esquina inferior izquierda
cambia a una llave cerrada en el caso de Netscape. En la URL,
cambia de Http:// a Https:// (Hipertext Transport Protocol Secure).
A pesar de
la seguridad en la comunicación, la utilización
este protocolo de comunicación en el pago de los productos
y servicios podría producir desconfianza en el Cliente,
ya que potencialmente el Vendedor puede realizar cualquier tipo
de fraude con total impunidad al poseer su número de tarjeta
y no quedar garantizada la integridad del documento de pago. Sólo
las empresas con muy buena reputación podrían, a
priori, contar con la confianza del consumidor.
Además
el más que posible fraude con números de tarjetas
robados hace que las Entidades de Crédito añadan
una comisión en las compras bastante elevada (un 5% +/-)
para compensar este tipo de fraude. Esto hace que el precio de
la compra se incremente considerablemente, lo que anula el atractivo
inicial de comprar por Internet: los precios bajos.
Si embargo,
con la emisión de Certificados de firma electrónica
(del tipo x509 v.3, se analizarán más adelante)
para los compradores se producirá una mayor confianza tanto
en el consumidor como en el vendedor. Esto es debido a que al
firmar el pago o formulario de pedido hay integridad del documento
(es decir el vendedor no puede cambiar la fecha o cualquier otro
dato), hay autenticidad en la compra (el comprador es quién
dice ser pues su firma digital lo prueba, ya que está respaldada
por una tercera parte de confianza o autoridad de certificación)
y se produce el efecto del no repudio. De este modo con la convinación
de estas dos técnicas de seguridad se podría establecer
un comercio electrónico seguro para las tres partes intervinientes,
Consumidor Vendedor y Banco.
Protocolo
SET.
Las empresas
de crédito son las principales interesadas en que el uso
de las Tarjetas de Crédito se generalice en todos los ámbitos
de la vida, incluyendo evidentemente a Internet. No es de extrañar
por tanto que las dos empresas más importantes de este
sector, Visa y Mastercard uniesen esfuerzos y potenciaran la creación
de un nuevo protocolo que permita los pagos por Internet de un
modo totalmente seguro, sin las limitaciones que plantea SSL.
La idea básica
consistía en crear un protocolo especialmente diseñado
para garantizar la seguridad en el pago mediante Tarjetas de Crédito
a través de medios de comunicación inseguros como
es el caso de Internet y que este protocolo se convirtiese en
un estándar abierto para la industria que sirviese de base
a la expansión del Comercio Electrónico por Internet.
Para ello
debían contar con el apoyo de las principales compañías
informáticas, así que al proyecto se le unieron
empresas de la talla de Microsoft, Netscape, IBM, Verifone-HP,
GTE y contaron como desarrolladores a RSA Data Security, Verisign,
Terisa-Spyrus y SAIC.
El 31 de Mayo
de 1997 se hicieron públicas las especificaciones formales
del protocolo SET versión 1.0, estas especificaciones se
pueden encontrar el web oficial de SET, <www.setco.org>.
Los documentos oficiales son:
Book 1: Descripción
de negocio
Book 2: Guía para Programadores
Book 3: Descripción formal del protocolo
A estos
documentos hay que añadir un cuarto:
Guía de interfase externo
En este documento
se dan las normas para la conexión por Internet, ya que SET
internamente no especifica el tipo de protocolo de comunicación
que debe utilizarse ni las características de los interfases.
Características
principales de SET:
Las especificaciones
de SET parten de una serie de criterios de diseño que permitan
la mayor difusión y seguridad del protocolo. Estas características
generales son:
- Estándar
abierto
- Objetivo
específico: Transferencia de números de tarjetas
de créditos
- Utiliza
codificación estándar (ASN.1 y DER)
- Independiente
del medio de comunicación utilizado
- Utiliza
estándares criptográficos ampliamente manejados
(PKCS, X.509)
- Utiliza
Criptografía de Clave Pública
- Autenticación
basada en la certificación digital de todas las entidades
participantes en la transferencia
Entorno:
A diferencia
de SSL, en SET se definen tres entidades independientes: Cliente(Cardholder),
Vendedor(Merchant) y la Pasarela de Pago(Gateway Payment) que
se interconectan directamente por Internet, haciendo el Vendedor
de puente entre el Cliente y la Pasarela de Pago. Previamente
a cualquier comunicación entre ellos, todas las entidades
deben haber obtenido un certificado digital valido a través
de la Autoridad de Certificación adecuada. La Pasarela
de Pago permite la conexión desde Internet con las Redes
Bancarias como VisaNet, dentro de estas Redes distinguimos otras
dos entidades. El Issuer o entidad emisora de la tarjeta de crédito
y el Adquirer o banco receptor de la transacción electrónica.
SET se diseñó
pensando en su utilización en Internet pero no de un modo
exclusivo como SSL, sino que permite la conexión a través
de cualquier tipo de red siempre que se definan las interfaces
adecuadas.
Jerarquía
de Certificación:
SET es el
primer proyecto de certificación a escala global que se
va ha realizar en el mundo. Los certificados SET se estructuran
siguiendo una jerarquía piramidal única que culmina
en una Autoridad Certificadora Raíz (Root CA) que es la
encargada de certificar a todas las demás autoridades certificadoras.
Bajo la Root CA se encuentran las Brand CA o CA propiedad de las
Entidades emisoras de Tarjetas de Crédito. Obviamente las
primeras Brand CA’s pertenecen a Visa Internacional y MasterCard
Internacional. Las Brand CA’s pueden a su vez certificar
a otras CA’s para que actúen en un ámbito
político determinado, estas CA’s reciben el nombre
de Brand Geopolitical CA. En España, ACE (Agencia de Certificación
Española) asumirá el roll de CA Brand Geopolitical
para las tarjetas Visa y MasterCard así como CA emisora
de certificados de Cardholder, Merchant y Gateway.
Autoridades
de Registro:
SET establece
un protocolo para la obtención de certificados electrónicos.
En la práctica la obtención de un certificado implica
que la CA necesita estar segura de que el destinatario del certificado
digital es realmente quien dice ser. Esta labor la llevaran a
cabo las llamadas Autoridades de Registro, que actuarán
de avaladores ante la CA de los usuarios y se encargarán
de tramitar los certificados liberando al usuario final de gran
parte de esta labor. Las Autoridades de Registro serán
precisamente los bancos, esto permitirá que los certificados
estén asociados a números de cuentas bancarias y
no a personas físicas; permitiendo las compras anónimas,
por lo menos desde el punto de vista del Vendedor.
Pago electrónico:
El esquema
de pago electrónico SET es muy similar al de CyberCash
y, al igual que este, admite una gran variedad de opciones. En
un pago normal SET, todo se inicia con una orden de pago que el
cliente envía al vendedor. Esta orden de pago esta dividida
en dos: la descripción de la compra (OD) y los datos financieros
del cliente (PIN). Estos datos se firman y se relacionan entre
sí por medio de un algoritmo llamado Firma Dual. Los datos
financieros van, a su vez, encriptados con la clave de la pasarela
de pago por lo que no pueden ser consultados por el vendedor.
El vendedor
envía estos datos encriptados a la Pasarela de Pago que
autoriza la transacción. Una vez autorizada, el Vendedor
envía una respuesta al comprador firmada que sirve de comprobante
de venta. Finalmente el vendedor realiza la captura del importe,
es decir envía la orden al banco de que se efectúe
la transacción.
Ventajas
sobre SSL
SET ofrece
una serie de mejoras sobre el sistema basado en SSL. Concretamente
en lo referente a los servicios de seguridad podemos comentar
lo siguiente:
- Confidencialidad:
Al separar los datos financieros de la descripción
de la compra aumentamos la confidencialidad ya que ni el vendedor
ni el banco tienen acceso a datos que no le son imprescindibles
- Integridad:
Todos los mensajes van firmados digitalmente de modo que se
garantiza la integridad de todos los datos incluso tras finalizar
la conexión.
- Autenticación:
Todos los participantes están certificados por una
Autoridad Certificadora única, lo que imposibilita
cualquier tipo de usurpación de identidad así
como la utilización de números de tarjeta de
crédito robados
- No repudio:
Los mensajes firmados pueden servir como Recibo de compra,
sirviendo de prueba inalterable de que la transacción
se produjo de un modo concreto.
Defectos de
SET 1.0:
La versión
1.0 presenta una serie de defectos y debilidades que intimidan
enormemente a la industria y que puede ser uno de los factores
que están retrasando la implantación definitiva
de este sistema en el ámbito mundial.
La primera
deficiencia importante es la dependencia de algoritmos de encriptación
concretos. Esto implica que si se encuentra una vulnerabilidad
en alguno de estos protocolos, la seguridad de SET se vería
seriamente amenazada. Y precisamente esto es lo que ha sucedido
recientemente.
La EFF (Electronic
Frontier Foundation) construyó en Noviembre de 1998 una
maquina llamada DEScracker capaz de desencriptar el protocolo
DES en tan solo 4 días. El objetivo de la EFF no era otro
que demostrar lo que se venía diciendo desde hacia tiempo:
El algoritmo DES está desfasado y es susceptible de ataques.
Pero el gran
defecto de SET 1.0 es su sistema de certificados que presenta
numerosas debilidades a la hora de implementarlo en la práctica.
Concretamente sus puntos débiles son:
- Distribución:
El modo de conseguir un certificado Digital es tremendamente
complicado, especialmente teniendo en cuenta que estos certificados
irían destinados al publico en general.
- Almacenamiento:
El talón de Aquiles de SET 1.0, todo el sistema se basa
en mantener en secreto la clave privada del cliente. Por lo
que esta clave se convertiría en objetivo prioritario
de robos, ataques de hackers y virus informáticos. Con
la agravante de que lo más probable es que el cliente
no fuera consciente de que es lo que debía proteger.
- Movilidad:
El certificado quedaría almacenado localmente en el ordenador
personal del cliente lo que impediría el uso de un terminal
diferente para realizar la compra. Este es un defecto estructural
de gran importancia por sí solo.
- Revocación:
El método utilizado para controlar los certificados revocados
no acaba de convencer a los expertos que están estudiando
otras alternativas. Esto, hasta cierto punto es comprensible
ya que nunca antes se ha probado una jerarquía de certificación
a nivel global de estas características.
SET 2.0
Como respuesta
a todas estas deficiencias se ha creado un equipo de investigación
que esta trabajando en la nueva versión de SET que acabara
con todos estos problemas. Se permitirá que el protocolo
pueda seleccionar entre varios algoritmos de cifrado como SSL
y se perfeccionara el sistema de revocación de certificados.
Pero el punto básico de la versión 2.0 será
la unión de SET con otro tipo de tecnología muy
de moda en la actualidad: Las tarjetas Inteligentes o Tarjetas
Chip.
Las tarjetas
inteligentes son unas tarjetas del tamaño de las tarjetas
de crédito convencionales que en lugar de almacenar la
información en una cinta magnética lo hacen en un
circuito integrado que llevan acoplado a la propia tarjeta. Este
chip es un pequeño Microprocesador con capacidad para almacenar
y generar claves criptográficas y realizar algunos algoritmos
de cifrado.
Con la utilización
de estos dispositivos se solucionarían las deficiencias
más importantes. Las Tarjetas Chip servirían de
sistemas de almacenamiento de claves, evitado el almacenamiento
de las claves en el propio ordenador y permitiendo la movilidad
a otros ordenadores. Además el proceso de certificación
se vería muy simplificado desde el punto de vista del cliente
final: el usuario iría al banco y obtendría su tarjeta
chip debidamente certificada, siendo el propio banco el encargo
de realizar los procedimientos necesarios para la certificación.
El Director
General de Visa España, declaró en la conferencia
"Comercio Electrónico y Dinero Electrónico" organizada
en Abril de 1998 en Barcelona por Fundesco, que Visa España
apostaba por la utilización de las Tarjetas Chip como medio
para evitar el fraude en el pago por Internet y que por ello iban
a mantener la comisión de riesgo (un 5%) a todos los pagos
por Internet que no utilizasen este sistema. En términos
reales esta comisión es uno de los factores decisivos en
la popularización de la compra por Internet dada la enorme
dependencia que presenta el comercio electrónico al precio
final del producto.
El principal
handicap de este sistema es la necesidad de utilizar un Lector
de Tarjetas Chip en cada Ordenador Personal. Estos dispositivos
se popularizarán en un futuro cercano ya que su precio
puede llegar a ser muy asequible (menos de 5.000 pts). Microsoft
ya ha asegurado que la próxima versión de Windows
soportara este tipo de dispositivos.
SET en España.
La primera
compra electrónica utilizando SET en España la realizó
Banesto con la colaboración de IBM el 3 Marzo del 1998.
La operación se llevó a cabo en las oficinas de
la entidad bancaria, donde a través de la tienda electrónica
Dinsa, se adquirió un ordenador personal IBM Aptiva que
se pagó con la tarjeta VirtualCash de Banesto. La oferta
de soluciones de IBM se llama Commerce.POINT y está basado
en el protocolo SET. La Pasarela de Pago utilizada fue la de Sistemas
4B, que sigue en periodo de pruebas.
A principios
de 1999 todavía no se tiene una fecha concreta para el
lanzamiento definitivo de SET en España.
Con la llegada
de SET se hacia necesaria la creación de alguna Autoridad
Certificadora en España con suficiente credibilidad como
para emitir certificados SET en territorio español. Los
principales promotores de este proyecto fueron Telefónica,
Sistemas 4B y Sermepa-Visa España que crearon ACE (Agencia
de Certificación Español) en Agosto de 1997.
Finalmente
se dio entrada en el accionariado de ACE a la Confederación
Española de Cajas de Ahorro (CECA) con el objetivo de que
todos los Bancos y Cajas de Ahorro estuviesen representados en
ella, quedando el accionariado definitivo de esta manera:
40% Telefónica
20% Sistemas
4B
20% Sermepa
– Visa España
20% CECA
Por su composición,
ACE se presenta como una apuesta seria por el Comercio Electrónico
por Internet en España ya que los máximos implicados
en los pagos son a su vez los propietarios de la empresa.
A partir de
Junio de 1998, ACE comenzó a emitir certificados SET válidos
de forma experimental, dejando la emisión definitiva de
certificados al público en general sin una fecha definitiva.
ACE tiene
capacidad para emitir certificados SET para Cardholer, Merchant
y Gateway para tarjetas Visa y MasterCard. Actualmente está
en proceso de convertirse en CA Geo-Political Brand de Visa. El
software utilizado es de la empresa Entrust y ha pasado por todos
los procesos de validación de SETco.
En SET, el
proceso de certificación es una de las partes más
delicadas y que están provocando mayores retrasos y conflictos.
ACE es una autoridad de certificación corporativa por lo
que no atiende directamente las peticiones de particulares. Estas
peticiones se tramitan a través de las Autoridades de Registro,
entidades financieras encargadas de validar la identidad del usuario
final.
Obtención
de Certificados.
El usuario
se personará físicamente en su banco (asumiendo
que previamente el usuario posee una cuenta en dicho banco y una
tarjeta de crédito asociada a la cuenta) y pedirá
un Certificado Digital SET para su tarjeta de Crédito.
El banco le entregará una contraseña que le permitirá
realizar el proceso de certificación vía web.
El usuario,
desde su casa, iniciará el proceso desde su ordenador utilizando
la opción de crear Claves en su Software de Cliente SET.
El software creará una Clave Pública y otra Privada.
La Clave Privada debe permanecer siempre en el ordenador del usuario
ya que es la base de la seguridad del sistema SET. Una vez generadas
las claves se iniciará una sesión en la Web de la
Autoridad de Registro (AR) y se enviará la contraseña
obtenida previamente y la Clave Pública generada. La AR
realizará una petición de certificado a ACE mediante
el protocolo SET de certificación. Como respuesta, ACE
emitirá un certificado digital que la AR remitirá
al usuario final.
El Software
de Autoridad e Registro para comunicarse con ACE ha sido diseñado
por la empresa española Penta3 y está basado en
la placa criptográfica SE500+ creada por la misma empresa.
Esquema del
proceso.
Partimos del
hecho en el que existen dos partes, A comprador y B vendedor,
la tercera parte C (el banco) no interviene en este primer supuesto
para facilitar un primer acercamiento al proceso. A quiere
comprar a B una serie de mercancías o servicios
que ha encontrado en una página web, rellena el formulario
de pedido y lo envía a B. En este proceso ha ocurrido lo
siguiente:
- Al formulario
de pedido o texto claro (en adelante Tc) se le aplica
la función hash de destilamiento. Así obtenemos
un texto mucho más corto llamado hash. A éste
pequeño texto incomprensible se le aplica la clave priva
de A (sistema de encriptación asimétrico),
perdiendo así muy poco tiempo ya que la cantidad de texto
sobre la que se aplica el algoritmo asimétrico es minúsculo
en comparación con el Tc. El resultado obtenido
es la Firma digital de A(en adelante Fa). Con
ello garantizamos autenticación de A.
- Una vez
obtenida la Firma digital del pedido (Tc), solo queda
por incorporar un certificado de clave pública obtenido
de una Autoridad de Certificación. De esta forma y aplicando
el sistema de encriptación simétrico al Tc,
Fa y al certificado de clave pública de A,
generamos una única clave simétrica que será
la llave para desencriptar el mensaje.
- EL último
paso a realizar será el envío del mensaje (ya
encriptado) más la clave simétrica, la cual debemos
encriptar con la clave pública de B (es decir
utilizando de nuevo el sistema asimétrico). Es en este
paso donde se obtiene el segundo certificado de la autoridad
de Certificación , para saber que la clave pública
de B es la que dice ser en la oferta de bienes y servicios.
- B a la
recepción del mensaje obtiene un mensaje encriptado y
una pequeña reseña también encriptada pero
con su clave pública, luego sólo él con
la aplicación de su clave privada podrá abrir
la reseña que es a su vez la llave para abrir el mensaje.
Luego B a la recepción del mensaje tendrá
que seguir los siguientes pasos:
a).
Aplicar su clave privada a la reseña, obteniendo
así la clave simétrica.
b).
Aplicar la clave simétrica al mensaje, obteniendo
el Tc, la Fa y el
certificado
de A.
c.)
Para saber que efectivamente es A y que el mensaje
no ha sufrido alteración alguna durante el trasiego
telemática, B tendrá que aplicar
la clave pública de A a Fa, obteniendo
así el hash del Tc, para seguidamente ejecutar
el algoritmo Hash en el Tc (evidentemente deberá
aplicar el mismo algoritmo que utilizó A)
y cotejarlo con el hash mandado por A, que en el
caso de que sean iguales dará por valida la Oferta
y por tanto cerrado el negocio.
Esquema del proceso
con la firma digital dual.
Todo este
proceso SET es un poco más complicado cuando aparece la
tercera parte C (el Banco) y se aplica la Firma dual. SET
ha introducido una nueva aplicación de la firma digital
llamada firma dual. Este sistema pretende configurar un entorno
en el que el pago por medios electrónicos sea seguro, de
forma que, ni el comerciante conozca los datos bancarios del comprador,
ni el banco conozca la naturaleza de la compra.
Para explicar
este sistema vamos a utilizar un ejemplo.
A desea
enviar una oferta a B para comprar un genero o un servicio
que tiene en venta y además quiere enviar una autorización
a su banco (C) para que le abone a B la cantidad
en el caso de que éste (C) acepte la oferta de A.
No desea ni que B conozca sus datos bancarios ni que el
banco (C) tenga acceso a los términos de la oferta
de A.
La firma dual
se genera de la siguiente forma:
1. Se Ejecuta
la función hash a cada uno de los textos (la oferta T1
y la autorización T2)..
2. Se unen
ambos hash resultantes. Hash1 + Hash2 = Hash3
3. Por último,
ejecuto el hash al Hash3 de forma que quede un único hash
que represente a los dos. Hash dual
Después
A encripta este Hash dual con su clave privada creando,
así, la firma digital(en adelante Fd) que incluye
tanto en la oferta que envía a B como en la autorización
que remite al banco (C). A, además, debe
incluir en cada uno de los mensajes y según el destinatario
el hash del otro documento para que el receptor pueda comprobar
la integridad del texto recibido. A B le debe enviar la
oferta T1, más la Fd, más el hash
de autorización del Banco, es decir el Hash2. Por otro
lado debe enviar a C (el banco) el T2, más la Fd,
más la oferta de B, es decir el Hash1.
El receptor
de cada mensaje puede aplicar al texto que reciba la función
hash y unir el resultado al hash del otro mensaje (el que ha recibido
junto con el suyo). Después aplica la función hash
a esta unión y compara el hash resultante con el de la
firma digital . Si estos dos hash son idénticos, el receptor
puede estar seguro de la validez del mensaje.
continuando
con nuestro ejemplo...
A ha
realizado todos los pasos que requiere la firma dual y ha enviado
la oferta a B y la autorización al Banco (Todo ello
con el método de encriptación simétrico y
con la pequeña reseña que contiene la llave para
desencriptar el mensaje).
Si B
acepta la oferta de A puede enviar un mensaje al banco
manifestando su acuerdo con la oferta de A e incluyendo
el Hash2 que A le envió.
De esta forma
C podrá realizar un ingreso a favor de B
comprobando que el Hash2 que B le ha mandado unido al Hash1
que A le mandó concuerda aplicándole previamente
la función resumen hash con el hash dual de la Fd
de A. Por tanto C verifica la autenticidad de la
oferta que A ha hecho a B y realiza un ingreso a
favor de B, cerrándose por tanto la compraventa,
con el envío de B del producto o servicio.
De esta forma
ni B ha tenido conocimiento de los datos bancarios de A,
ni C conoce las características de la oferta. Se
ha producido por tanto una compraventa electrónica segura.
|
