Hay una necesidad
apremiante de medidas para garantizar la
privacidad, integridad y disponibilidad de recursos
en los sistemas distribuidos. Los ataques contra la seguridad toman las formas
de escuchas, suplantación, modificación y denegación de servicio
La criptografía proporciona la base de la
autenticación de mensajes así como del secreto y la
integridad. Para explotarla es preciso utilizar protocolos de seguridad
diseñados cuidadosamente. La selección de algoritmos criptográficos y la
administración de claves son puntos críticos para
la efectividad, prestaciones y usabilidad de los
mecanismos de seguridad. La criptografía de clave pública facilita la
distribución de claves criptográficas pero sus prestaciones son inadecuadas
para la encriptación de datos masivos. La criptografía
de clave secreta es más adecuada para tareas de encriptación
masiva. Los protocolos híbridos
como SSL (Secure Sockets
Layer)
establecen canales seguros empleando criptografía de clave pública para
intercambiar claves secretas que se usarán en subsiguientes intercambios de
datos.
En todos aquellos sistemas de computadores, donde
haya objetivos potenciales para ataques maliciosos o con fines de diversión
habrá que incluir medidas de seguridad. Especialmente para sistemas que traten
con transacciones financieras, confidenciales, clasificadas u otra información
cuyo secreto e integridad sea crítica.
La necesidad de proteger la integridad y la
privacidad de la información, y otros recursos que pertenecen a individuos y organizaciones,
conjuga ambos mundos: el físico y el digital. Nace, como es lógico, de la
necesidad de compartir recursos. En el mundo físico, las organizaciones adoptan
políticas de seguridad para poder compartir recursos dentro de unos
límites especificados. Las políticas de seguridad se hacen cumplir con la ayuda
de los mecanismos de seguridad.
En el mundo electrónico, la distinción entre
políticas de seguridad y los mecanismos también es importante: sin ella, seria
difícil determinar si un sistema particular es
seguro. Las políticas de seguridad son independientes de la tecnología empleada, así
como el instalar una cerradura en una puerta no garantiza la seguridad del
edificio a menos que haya una política de uso (por
ejemplo. que la puerta esté cerrada cuando no esté vigilada).
Los mecanismos de seguridad que describiremos no garantizan, por sí mismos, la seguridad de un
sistema. En el tema que se refiere a: “Seguridad
de las transacciones electrónicas” se bosquejarán los
requisitos de seguridad en distintos escenarios simplificados
de comercio electrónico, ilustrando la necesidad de las políticas de seguridad en ese contexto.
Evolución de las necesidades de seguridad.
1965-75 1975-89 1990-99 actualmente
|
Plataformas |
Computadores multiusuario
de tiempo compartido |
Internet, servicios de área extensa |
Internet + dispositivos
móviles |
||
|
Recursos compartidos |
Memoria, archivos |
e-mail, lugares web, comercio Internet |
Objetos distribuidos,
código móvil |
||
|
Requisitos de seguridad |
Identificación y
autenticación de usuario |
Protección de servicios |
Seguridad robusta para
transacciones comerciales |
Control de acceso para
objetos individuales, código móvil seguro |
|
|
Entorno de gestión de la
seguridad |
Autoridad única, base de datos de autorización única (p. ej.: /etc/passwd) |
Autoridad única, delegación, bases de datos de
autorización replicadas (p. e).: NIS) |
Muchas autoridades, sin
autoridad en la red, en general |
Autoridades por
actividad, grupos con responsabilidades compartidas |
|
Describiremos los mecanismos
que permiten hacer cumplir las políticas de seguridad en los sistemas
distribuidos.
La distinción entre
políticas de seguridad y mecanismos de seguridad es de utilidad cuando se
diseñan sistemas seguros, pero no es fácil estar seguro de que cierto conjunto
de mecanismos de seguridad implementan completamente las políticas de seguridad
deseadas. Presentamos un modelo de seguridad diseñado para ayudar en el
análisis de las amenazas de seguridad potenciales en un sistema distribuido.
Resumiendo el modelo de seguridad como sigue:
• Los
procesos encapsulan recursos y acceden a comunicarse con los clientes a través
de sus interfaces. Los usuarios u otros procesos pueden estar autorizados para
operar sobre los recursos y estos deben estar protegidos contra accesos no
autorizados.
• Los
procesos interactúan en la red, que es compartida . Los enemigos o atacantes
pueden acceder a la red y podrán copiar, leer o introducir mensajes
arbitrarios, dirigidos hacia cualquier destino y simular que provienen de
cualquier otro.
Este modelo de
seguridad identifica las características de los sistemas de seguridad expuestos
a ataques.
La emergencia de la
criptografía en el dominio público. La criptografía
proporciona la base para la mayoría de los sistemas de seguridad de los
computadores. La criptografía tiene una larga y fascinante historia. La
necesidad de comunicaciones militares seguras y la correspondiente necesidad
del enemigo de interceptarlas y desencriptarlas ha fomentado la inversión de
mucho esfuerzo intelectual, por parte de los mejores cerebros matemáticos de
cada época.
Pero sólo en tiempos
recientes la criptografía emerge de la trastienda en la que fue puesta por
la-clase dirigente de políticos y militares que solían controlar su desarrollo
y su aplicación. Hoy en día es un tema de investigación abierta y con una
comunidad de investigadores amplia y muy activa.
La reciente apertura es, en .su mayor medida,
resultado del importante crecimiento del interés en las aplicaciones no
militares de la criptografía y los requisitos de seguridad de los sistemas de
computadores distribuidos. Esto desembocó en la existencia, por primera vez, de
una comunidad autosuficiente de criptógrafos aparte del entorno militar.
Irónicamente, esta apertura al público de la
criptografía ha traído consigo un mayor avance de las técnicas criptográficas,
su resistencia a los ataques criptoanalíticos y la comodidad con la que se
despliegan las medidas criptográficas. La criptografía de clave pública es fruto
de esta apertura. Un ejemplo más, el algoritmo de encriptación estándar DES fue
inicialmente un secreto militar. Su eventual publicación y los esfuerzos
exitosos para romperlo han traído consigo el desarrollo de algoritmos de
encriptación de clave secreta mucho más resistentes.
Otro
producto secundario útil ha sido el desarrollo de una terminología y
aproximación común. Un ejemplo de esto último es la adopción de un conjunto de
nombres familiares para los protagonistas (principales) involucrados en las transacciones
que hay que asegurar. El uso de nombres familiares para los principales y los
atacantes ayuda a aclarar y acercar al mundo las descripciones de los
protocolos de seguridad y los potenciales ataques sobre ellos, lo que supone un
paso importante hacia la identificación de sus debilidades.
Alice Primer participante.
Bob Segundo participante.
Carol Otro participante en los
protocolos a tres o cuatro bandas
Dave Participante en protocolos a cuatro
bandas
Eve Fisgón
Mallory Atacante malevolente
Sara Un servidor
Nombres
familiares (del mundo anglosajón) para los protagonistas de los protocolos de
seguridad.
En la mayoría de los
tipos de redes locales es fácil construir un programa sobre un computador
conectado para que obtenga copias de los mensajes transmitidos entre computadores. Otras amenazas son más
sutiles; un programa podría situarse a sí mismo en lugar del auténtico servidor
de archivos y así obtener copias de información confidencial que los clientes,
inconscientemente, envían para su almacenamiento.
Además del peligro de daño de información pueden
aparecer reclamaciones fraudulentas contra el propietario de un sistema que no
sea demostrablemente seguro. Para evitarlo, el propietario debe desacreditar la
reclamación mostrando que el sistema es seguro contra tales violaciones, o
produciendo un registro histórico de todas las transacciones. Un ejemplo es el débito fantasma en los cajeros
automáticos. La mejor respuesta de un banco es proporcionar un registro de la
transacción firmado digitalmente por el titular de la cuenta, que no pueda ser
falsificado.
La principal meta de la seguridad es restringir el
acceso a la información y los recursos de modo que sólo tengan acceso aquellos
que estén autorizados.
Las amenazas de seguridad se dividen en tres clases:
Fuga — la
adquisición de información por receptores no autorizados.
Alteración — la
modificación no autorizada de información.
Vandalismo —
interferencia en el modo de operación adecuado de un sistema, sin ganancia para
el responsable.
Los ataques en los sistemas distribuidos dependen de
la obtención de acceso a los canales de comunicación. Los métodos de ataque
pueden clasificarse en función del modo en que se abusa del canal:
Fisgar -
obtener copias sin autorización.
Suplantar — enviar
o recibir mensajes utilizando la identidad de otro sin su autorización.
Alterar mensajes —
interceptar mensajes y alterar sus contenidos antes de pasarlos al receptor.
Reenviar —
almacenar mensajes interceptados y enviarlos más tarde.
Denegación de servicio — desbordar un canal
o recurso para impedir que otros accedan a él.
Los ataques victoriosos dependen del descubrimiento
de agujeros en la seguridad de los sistemas y estos problemas son comunes en
los sistemas de hoy.
Cuando se diseñó Internet y los sistemas conectados
a ella, la seguridad no era una prioridad.
La incorporación de medidas de seguridad requiere
ser cuidadoso con la etapa de diseño, y se pretende que el contenido de este
capítulo proporcione las bases de tal idea.
Nos hemos concentrado en los ataques a los sistemas
distribuidos que nacen de la exposición de sus canales de comunicación y sus
interfaces. Los mecanismos de seguridad no pueden protegernos contra una clave
de acceso mal elegida o custodiada. Pero para sistemas que incluyan programas
móviles y sistemas cuya seguridad sea sensible a la fuga de información, hay
más ataques.
Ataques desde código móvil. Varios
lenguajes de programación, han sido diseñados para permitir que la descarga de
programas desde servidores remotos y así lanzar procesos que se ejecutan
localmente. En este caso, las interfaces internas y los objetos del interior de
un proceso en ejecución pueden quedar expuestos a un ataque por código móvil.
Java es el lenguaje de este tipo más conocido.
La Máquina Virtual. Java-(JVM) se diseñó con
el código móvil. A cada aplicación se le da su propio entorno
de ejecución. Cada entorno tiene un gestor de seguridad
que determina qué recursos están disponibles para la aplicación.
Cuando un usuario ejecuta un programa como un
visualizador web que descarga código móvil para ser utilizado localmente en su
nombre, no hay ninguna buena razón para confiar en que éste se comporte de una
forma responsable. Para proteger a los usuarios contra código no fiable la
mayoría de los navegadores especifican que los applets no puedan acceder
a archivos locales, impresoras o sockets de red. JVM toma dos
medidas para proteger el entorno local:
1
Las clases descargadas se almacenan separadas de las
clases locales,
2
Se comprueba la validez de los bytecodes. El bytecode
Java válido se compone de instrucciones de máquina virtual Java de un conjunto especificado.
A pesar de la inclusión de mecanismos de
comprobación de tipo y
de validación de código, los mecanismos de
seguridad incorporados a los sistemas de código móvil aún no dan el mismo nivel de confianza en su efectividad que los usados para
proteger los canales e interfaces de comunicación Esto es así porque
la construcción de un entorno para la ejecución de programas
ofrece muchas oportunidades de error, y es difícil tener la certeza de que se han evitado todos.
Fugas de información. Si pudiera observarse la
sucesión de mensajes en
la comunicación entre
dos procesos, sería posible vislumbrar información importante aún de su
sola existencia. Hay
muchas formas sutiles
de fugas de información,
algunas maliciosas y
otras que son consecuencia de errores inadvertidos. El potencial de las fugas aparece cuando se pueden observar los
resultados de un cómputo. La aproximación empleada es la asignación de niveles de
seguridad a la información
y los canales, y analizar el flujo de información hacia los canales con el objetivo de asegurar que la información de alto nivel no fluya
hacia los canales de bajo
nivel.
SEGURIDAD DE LAS TRANSACCIONES ELECTRÓNICAS
Muchas aplicaciones de comercio y demás implican transacciones que
dependen de la seguridad, como ser:
E-mail: hay muchos usos del
correo en que los mensajes deben ser confidenciales (como enviar un número de
tarjeta de crédito).
Compra
de bienes y servicios: estas transacciones
son usuales. Los compradores
seleccionan bienes y pagan por ellos empleando el Web, luego le son enviados por
un mecanismo de reparto. Transacciones bancarias:
los bancos electrónicos ofrecen a los usuarios todos los servicios que
proporcionan los bancos convencionales.
Micro-transacciones:
Internet se presta a proporcionar pequeñas cantidades de información y otros
servicios hacia sus clientes. Por ejemplo, el acceso a la mayoría de las
páginas web no exige ningún pago, pero el desarrollo del Web como un medio de
publicación de alta calidad seguramente depende de hasta qué punto los
proveedores de información puedan obtener beneficio de los clientes de esta
información.
Las transacciones como éstas sólo se pueden realizar
de modo seguro cuando se encuentran protegidas contra la revelación de los
códigos de crédito durante la transmisión, y contra un vendedor fraudulento que
obtenga un pago sin intención de proveer bien alguno.
Una política de seguridad sensata para vendedores y
compradores de Internet exige los siguientes requisitos:
Las necesidades de
seguridad de las transacciones bancarias que emplean una red abierta son
similares a las de las transacciones de compra, con el titular de la cuenta y
el banco como vendedor, aunque hay necesidad de:
En esta situación es importante para el banco estar
seguro de que el titular de la cuenta no pueda negar haber participado en una transacción.
A esto se le da el nombre de no repudio.
El comercio en Internet es una aplicación importante de las técnicas de seguridad, pero no es ciertamente la única. Es una necesidad cuando quiera que dos computadores sean utilizados por individuos u organizaciones para almacenar y comunicar información importante.
Debemos diferenciar las tareas especificas de
un diseñador de sistemas seguros y de un programador. El
objetivo del diseñador es excluir todos los posibles
ataques y agujeros. La
situación es análoga a la del programador cuyo principal objetivo es excluir
todos los errores de su programa. En ningún caso existe un método concreto para
asegurar las metas durante el diseño. Cada uno diseña con los mejores estándares
disponibles y aplica un análisis informal y comprobaciones. Una vez que un
diseño está completo, una opción es la validación formal. La seguridad trata de evitar los desastres y
minimizar los contratiempos. Cuando
se diseña para seguridad es necesario pensar siempre en lo peor.
Para demostrar la validez de los mecanismos de
seguridad, empleados en un sistema, los diseñadores deben construir, en primer
lugar, una lista de amenazas y probar que cada una de ellas se puede
prevenir mediante los mecanismos empleados como por ej. Un histórico de
seguridad.
Un histórico de seguridad contendrá una secuencia de registros fechados
de las acciones de los usuarios. Como mínimo, los registros incluirán la identidad del principal, la
operación realizada), la identidad del objeto sobre el que se opera y la fecha
y hora.
Donde se sospeche que pudiera
haber violaciones concretas, los registros pueden contener
información a mayores para incluir la utilización de los recursos físicos (ancho de banda de
red, periféricos), o disparar un procedimiento histórico especial de
operaciones sobre objetos concretos.
Posteriormente se puede
efectuar un análisis de carácter estadístico o bien basado en búsquedas.
Incluso aunque no se sospeche de alguna violación,
las técnicas estadísticas permitirán comparar registros a lo largo del tiempo
para descubrir tendencias o cualquier suceso inusual.
El diseño de sistemas seguros es un ejercicio de balance
entre los costos y las amenazas ya que:
• Su uso
acarrea un costo (en esfuerzo computacional y uso de la red). Los costos deben
compensar la amenaza.
• Unas
especificaciones de medidas de seguridad inapropiadas podrían impedir a los
usuarios legítimos el realizar ciertas acciones necesarias.
La criptografía moderna incluye algunos algoritmos
seguros de encriptación y desencriptación
de mensajes.
Todos ellos se basan en el uso de ciertos secretos llamados claves.
Una clave criptográfica es un parámetro empleado en un algoritmo
de encriptación de manera que no sea reversible sin
el conocimiento de una
clave.
hay
dos clases principales de algoritmos de encriptación
de uso general:
La primera emplea
claves
secretas compartidas: donde el emisor y el receptor deben compartir el conocimiento de una clave y ésta no debe ser revelada a ningún otro.
La segunda emplea pares de claves pública /
privada: donde el emisor de un mensaje
emplea una clave pública, difundida previamente por el receptor, para encriptar
el mensaje. El receptor emplea la clave
privada correspondiente para desencriptar el mensaje. A pesar de que una
multitud de principales pudiera examinar la clave pública, solamente el
receptor puede desencriptar el mensaje, gracias a su clave privada. Los
algoritmos de encriptación de clave pública requieren usualmente de 100 a 1.000
veces más potencia de procesamiento que los algoritmos de clave secreta, aunque
hay situaciones en las que su conveniencia compensa esta desventaja.
La criptografía juega tres papeles
principales en la implementación de los sistemas seguros:
Secreto e integridad: se emplea
para mantener el secreto y la integridad de la información dondequiera que
pueda estar expuesta a ataques potenciales.
Este uso se corresponde con su papel tradicional en las actividades militares y de inteligencia.
Se explota el hecho de que un mensaje encriptado con
una clave de encriptación particular sólo puede ser desencriptado por un
receptor que conozca la correspondiente clave de desencriptación. Así se
conseguirá el secreto del mensaje encriptado en la medida de que la clave de
desencriptado no esté comprometida
y a condición de que el algoritmo de encriptación sea suficientemente
fuerte como para derrotar cualquier posible intento de romperlo.
También preserva la integridad de la información
encriptada, supuesto que se incluya algo de información redundante, de la misma
forma en que se incluyen y comprueban las sumas de chequeo (checksums)
.
Autenticación: La criptografía se
emplea como base para los mecanismos para autenticar la comunicación entre
pares de principales.
Un principal que desencripta un mensaje con éxito empleando una clave particular puede presuponer que el mensaje es auténtico si contiene una suma de chequeo correcta o, si se emplea el modo de encriptación de encadenamiento de bloques.
Éstos podrán inferir que el emisor del mensaje
estaba en posesión de la clave de encriptación correspondiente y entonces
deducir la identidad del emisor, siempre qué la clave sólo sea conocida por las
dos partes.
En resumen, si las claves se mantienen en secreto,
una desencriptación con éxito da fe de que el mensaje desencriptado proviene de
un emisor concreto.
Firmas digitales: Ésta emula el
papel de las firmas convencionales, verificando a una tercera parte que un
mensaje o un documento es una copia inalterada producida por el firmante.
Las técnicas de firmas digitales se basan en una
modificación irreversible sobre el mensaje o el documento de un secreto que
únicamente conoce el firmante.
Esto se
puede lograr encriptando el mensaje; o mejor, una forma comprimida del mensaje
denominada resumen (digest),
empleando una clave sólo conocida por el firmante.
Un resumen es un valor de
longitud fija calculado mediante la aplicación de una función de resumen
segura.
Un resumen seguro es similar a una función de
chequeo, con la diferencia de que es muy difícil que dos mensajes diferentes
produzcan el mismo resumen.
El resumen
resultante encriptado actúa como una firma que acompaña el mensaje.
La firma se suele encriptar mediante un método de clave pública: el firmante genera una firma con su clave privada; la firma puede ser desencriptada por el receptor utilizando la correspondiente clave pública.
Hay un requerimiento adicional: el verificador de la
firma debe asegurarse de que la clave pública que emplea es la que realmente
pretende el firmante.
Un
certificado digital es un documento que contiene una sentencia (generalmente
corta) firmada por un principal. Estos
pueden emplearse para establecer la autenticidad de muchos tipos de
enunciados
Para
que los certificados sean útiles se requieren dos cosas:
• Un formato estándar y una representación
para ellos de modo que los emisores de certifica dos y los usuarios de
certificados puedan construirlos e interpretarlos.
• Un acuerdo sobre la forma en que se
construyen las cadenas de certificados, y en particular la noción de autoridad
fiable.
Uno de los problemas que aparecen con los
certificados es la dificultad al elegir una autoridad fiable de donde pueda
arrancar una cadena de autenticaciones. La elección de una autoridad dependerá
del objetivo para el que se necesite el certificado. Otros problemas nacen del
riesgo de comprometer (desvelar) las claves privadas y de la longitud
permisible de una cadena de certificación, cuanto más larga mayor es el riesgo
de un eslabón débil.
Históricamente, la protección de los recursos de los
sistemas distribuidos se implanta mayormente en el servicio concreto que
queremos proteger. Los servidores reciben mensajes con peticiones de la forma <op,
principal, recurso>, donde op es la operación solicitada, principal
es una identidad o un conjunto de credenciales del principal que realiza la
petición y recurso identifica el recurso sobre el que se aplica la
operación. El servidor debe, en primer lugar, comprobar la autenticidad del
mensaje de petición y las credenciales del principal y después aplicar el
control de acceso, rehusando cualquier petición para la cual el principal
solicitante no tenga los derechos de acceso pertinentes para realizar la
operación requerida sobre el recurso especificado.
En sistemas distribuidos orientados al objeto puede
haber muchos tipos de objeto a los cuales habrá que aplicar el control de
acceso, y las decisiones son siempre específicas para cada aplicación.
Las decisiones de control de acceso se dejan
usualmente al código de nivel de aplicación, pero se proporciona un soporte
genérico para gran parte de la mecánica que soporta las decisiones. Esto
incluye la autenticación de los principales, la firma y autenticación de las
peticiones, y la administración de credenciales y datos de derechos de acceso.
Dominios de protección. Un
dominio de protección es un entorno de ejecución compartido por un conjunto de
procesos: contiene un conjunto de pares < recurso,
derechos>, que listan los recursos que pueden ser accedidos
por todos los procesos en ejecución dentro del dominio y especificando las
operaciones permitidas sobre cada recurso. Un dominio de protección se asocia
generalmente con un principal dado; cuando un usuario entra en el sistema, se
comprueba su identidad y se crea un dominio de protección para todos los
derechos de acceso que posee el principal. Conceptualmente, el dominio incluye
todos los derechos que posea el principal, incluyendo cualquier derecho que
ella adquiera por el hecho de pertenecer a varios grupos. Un dominio de
protección es sólo una abstracción. En los sistemas distribuidos se emplean
usualmente dos implementaciones alternativas.
Habilitaciones (capabilities): Cada proceso, según el dominio
en que esté ubicado, aloja un conjunto de habilitaciones. Una habilitación es
un valor binario que actúa como una clave de acceso permitiendo al que lo posee
acceder a ciertas operaciones sobre un recurso especificado. Para su uso en los
sistemas distribuidos, donde las habilitaciones deben ser infalsificables,
toman la forma de:
Identificador
del recurso
Un identificador único para el recurso objeto.
Operaciones Una lista de operaciones
permitidas sobre el recurso.
Código
de autenticación
Una firma digital que, hace la habilitación infalsificable.
Cuando se emplean habilitaciones, las peticiones de
los clientes tienen la forma < op,
idUsuario, habilitación >. Se incluye
en ellas una habilitación para acceder al recurso en lugar de un simple
identificador, lo que da al servidor una prueba inmediata de que el cliente
está autorizado a acceder al recurso identificado por la habilitación con las
operaciones especificadas por ésta. Una comprobación de control de acceso sobre
una petición acompañada por una habilitación involucra solo la validación de la
habilitación y una comprobación de que la operación solicitada está en el
conjunto permitido por la habilitación. Esta característica es la mayor ventaja
de las habilitaciones, que constituyen una clave de acceso autocontenida, tal y
como una llave física para una cerradura es una clave para acceder al edificio
protegido por la cerradura. Las habilitaciones comparten dos inconvenientes de
las llaves de una cerradura física:
Robo de llaves:
cualquiera que posea la llave de un edificio puede utilizarla para tener acceso
a él, sea o no un poseedor autorizado de la llave; ésta pudiera haber sido
robada u obtenida de alguna forma fraudulenta.
El problema de la
revocación: la calificación para poseer una llave cambia con el
tiempo. Por ejemplo, el poseedor pudiera dejar de ser un empleado o el
propietario del edificio, pero podría seguir reteniendo la llave, o una copia
de ella, y utilizarla de manera no autorizada.
Quedan claros los problemas análogos para las
habilitaciones:
·
Las habilitaciones podrían, debido a un descuido o
como resultado de un ataque a la confidencialidad, caer en manos de otros
principales que no son para quienes fueron emitidas. Si ocurre esto, los
servidores quedan a merced de ser utilizados ilícitamente.
·
Resulta difícil cancelar las habilitaciones. El
estado del portador pudiera cambiar y sus derechos de
Listas de control de
acceso: Se almacena una lista con cada recurso, con una
entrada de la forma
< dominio,
operaciones > para
cada dominio que tenga acceso al recurso y especificando las operaciones
permitidas al dominio. Un dominio puede especificarse mediante un identificador
de un principal o puede ser una expresión susceptible de ser utilizada para
determinar la pertenencia del principal al dominio
Éste es el esquema
adoptado en la mayoría de los sistemas de archivos, incluyendo UNIX y Windows
NT, donde se asocia a cada archivo un conjunto de bits de permisos de acceso, y
los dominios a los cuales se ceden los permisos se definen por medio de una
referencia a la información de pertenencia almacenada con cada archivo.
Las peticiones a los
servidores son de la forma <op. principal, recurso>, el servidor
identifica el principal y comprueba si la operación solicitada está incluida en
la entrada del principal en la lista de control de acceso del recurso
relevante.
Implementación. Las firmas,
digitales, las credenciales y los certificados de clave pública proporcionan
las bases criptográficas para el control de acceso seguro. Los canales seguros
ofrecen beneficios de prestaciones, posibilitando el manejo de múltiples
peticiones sin necesidad de comprobar los principales y las credenciales
reiteradamente
Ambos CORBA y Java
ofrecen un API de seguridad. Uno de sus principales objetivos es dar soporte
para el control de acceso. Java proporciona soporte para que los objetos
distribuidos administren su propio control de acceso mediante las clases
Principal, Signar y ACL, así como métodos de autenticación por defecto y supone
para certificados, validación de firmas y comprobaciones de control de acceso.
También están soportadas la criptografía de clave secreta y pública. La
protección de los programas Java que incluyen código móvil se basa en el
concepto de dominio de protección; el código local y el código descargado
tienen diferentes dominios de protección en que ejecutarse. CORBA ofrece una
especificación de Servicio de Seguridad
con un modelo de ORB para proporcionar comunicación, autenticación,
control de acceso con credenciales, ACL y auditoria.
Las credenciales son un conjunto de evidencias
presentadas por un principal cuando pide acceso a un recurso. En el caso más
simple, un certificado de una autoridad relevante afirmando la identidad del
principal es suficiente, y ésta podrá emplearse para comprobar los permisos del
principal en una lista de control de. A
menudo esto es todo lo que se necesita o se proporciona, pero el concepto puede
generalizarse para tratar con muchos requisitos más sutiles.
No es conveniente
pedir que los usuarios contacten con el sistema y se autentiquen ellos mismos
cada vez que se requiere su autoridad para realizar una operación sobre un
recurso protegido. En su lugar, se introduce la noción de credencial que habla
por un principal. Así un certificado de clave pública de un usuario habla
por ese usuario; cualquier proceso que reciba una petición autenticada con la
clave privada del usuario puede asumir que la petición fue enviada por ese
usuario.
Las credenciales
basadas en funciones parecen especialmente útiles en el diseño de esquemas de
control de acceso prácticos. Los conjuntos de credenciales basadas en funciones
se definen para las organizaciones o para tareas cooperativas, y los derechos
de acceso de nivel de aplicación se construyen con referencia a ellas. Se
pueden asignar funciones o roles a principales específicos mediante la
generación de un certificado de rol que asocia un principal con un rol
determinado en una tarea u organización específica .
Delegación. Una forma
particularmente útil de credencial es aquella que permite a un principal, o
proceso actuando para un principal, realizar una acción con la autoridad de
otro principal. Una necesidad de delegación puede aparecer en cualquier
situación donde un servicio necesite acceder a un recurso protegido para
completar una acción en representación de su cliente.
Se puede conseguir
la delegación utilizando un certificado de delegación o una habilitación. El
certificado está firmado por el principal solicitante y autoriza a otro
principal (el servidor de impresión en nuestro ejemplo) para
acceder a un recurso con nombre (el archivo que hay que imprimir). En los
sistemas que lo soportan, las habilitaciones pueden lograr el mismo resultado
sin necesidad de identificar a los principales; se puede pasar una habilitación
para acceder a un recurso en la petición al servidor. La habilitación es un
conjunto codificado e infalsificable de derechos de acceso al recurso.
Cuando se delegan
derechos, es común restringirse a un subconjunto de los derechos que posee el
principal que lo emite, de este modo el principal delegado no podrá
abusar de ellos.
Con ellos se
protege una intranet, se realizan acciones de filtrado en las comunicaciones
entrantes y salientes.
Los cortafuegos producen un entorno de comunicación
local en el que se intercepta toda comunicación externa. Los mensajes se
reenvían al recipiente local final sólo para las comunicaciones que estén
autorizadas explícitamente.
Se puede controlar el acceso a las redes internas
mediante cortafuegos, pero el acceso a los servicios públicos a Internet no
puede restringirse porque su objetivo es ofrecer éstos a un amplio conjunto de
usuarios. El empleo de cortafuegos no ofrece protección contra los ataques
desde el interior de una organización, y es ciertamente tosco en el control del
acceso externo. En consecuencia existe una necesidad de mecanismos de seguridad
de un grano más fino, que permitan a los usuarios individuales compartir
información con otros usuarios seleccionados sin comprometer la privacidad y la
integridad.
Los cortafuegos no son particularmente útiles contra
ataques de denegación de servicios, basado
en la suplantación de direcciones IP. El problema es que el flujo de mensajes
generado por tales ataques sobrepasa las capacidades de cualquier elemento de
defensa singular como un cortafuegos. Cualquier remedio contra las riadas de
mensajes debiera aplicarse corriente arriba del objetivo.
Los remedios basados en el empleo de mecanismos de
calidad de servicio para restringir el flujo de mensajes desde la red hasta un
nivel que el objetivo pueda manejar parece ser que prometen.
Un mensaje puede encriptarse mediante la aplicación
por el emisor de alguna regla que transforme el texto en claro del
mensaje a un texto cifrado o criptograma. El receptor debe conocer la regla inversa para transformar el
testo cifrado en el texto original.
La transformación de encriptación se define mediante
dos elementos, una función E y una clave K. El mensaje resultante
encriptado se escribe {M}k.
E(K,M) = {M}k
La función de
encriptación E define un algoritmo que transforma los datos de texto en
datos en-criptados al combinarlos con la clave y transformándolos de un modo
que depende fuertemente del valor de la clave. Podemos pensar en un algoritmo
de encriptación como en una especificación de una familia grande de funciones,
de la que seleccionamos un miembro particular mediante una clave dada. La
desencriptación se lleva a cabo empleando una función inversa D, que también
toma como parámetro una clave. Para la encriptación de clave secreta, la clave
de desencriptado es la misma que la de encriptado:
D(K, E(K, M))=M
Debido este uso
simétrico de las claves, a menudo se habla de la criptografía de clave secreta
como criptografía simétrica, mientras que la criptografía de clave pública
se denomina asimétrica debido a que las claves empleadas para el
encriptado .
Algoritmos simétricos. Si eliminamos de la
consideración el parámetro de la clave y definimos Fk([M]) = E(K,
M), una propiedad de las funciones de encriptación robustas es que Fk([M])
sea relativamente fácil de calcular, mientras que la inversa, Fk-1([M])
sea tan difícil de calcular que no sea factible. Tales funciones se las conoce
como funciones de un solo sentido.
La efectividad de cualquier método para encriptar información
depende del uso de una función de encriptación Fk que posea esta
propiedad de irreversibilidad. Es esta propiedad la que protege a M de
ser descubierto dado {M}k.
Algoritmos asimétricos. Cuando
se emplea un par de claves pública / privada, las funciones de un solo sentido
se explotan de otra forma. La base de todos los esquemas es la existencia de funciones
de puerta falsa. Una función de puerta falsa es una función de un solo
sentido con una salida secreta: es fácil calcularla en una dirección pero
impracticable calcular su inversa a menos que se conozca un secreto..
El par de claves necesario para los algoritmos
asimétricos se deriva de una raíz común. Para el algoritmo RSA, la raíz es un par de números primos muy
grandes que se eligen arbitrariamente.
Cifradores de bloque. La mayoría de los
algoritmos de encriptación operan sobre bloques de datos de tamaño fijado; 64 bits es un tamaño de bloque popular. Cada
mensaje se subdivide en bloques, el último bloque se rellena hasta la longitud
estándar si fuera necesario y cada bloque se encripta independientemente. El
primer bloque está listo para ser transmitido tan pronto como haya sido
encriptado.
Para un simple cifrador de bloque, el valor de cada
bloque del criptograma no depende de los bloques precedentes. Esto constituye
una debilidad, dado que un atacante puede reconocer patrones repetidos e
inferir su relación con el texto en claro. Tampoco se garantiza la integridad
de los mensajes; debido a esto la mayoría de los algoritmos de cifrado de bloque
emplean un encadenamiento de bloques de cifrado (cipher block chaining,
CBC).
Encadenamiento de bloques de cifrado: En el
modo de encadenamiento de bloques de cifrado, cada bloque de texto en claro se
combina con el bloque de criptograma precedente empleando la operación
0-exclusivo (XOR) antes de encriptarlo . En el
desencriptado, el bloque se desencripta y se efectúa una operación XOR con el
bloque encriptado precedente obteniendo el nuevo bloque de texto en claro. Esto
es posible porque la operación XOR es idempotente (dos aplicaciones
sucesivas producen el mismo valor).
Con el CBC se pretende impedir que dos porciones
idénticas de texto en claro deriven en dos porciones de código encriptado
idénticas. Para prevenir esto, necesitamos insertar un trozo de texto en claro
diferente a la cabeza de cada mensaje. Tal texto se denomina vector de
iniciación. Un número conteniendo la fecha y la hora del mensaje sirve bien
como vector de iniciación, y fuerza a que cada mensaje comience con un bloque
de texto en claro diferente.
El uso del modo CBC se restringe a la
encriptación de datos que se transmiten a lo largo de una conexión fiable. El
desencriptado fallará si se pierde cualquiera de los bloques del criptograma
dado que el proceso de desencriptado será incapaz de desencriptar bloques a
partir de ese momento.
Bloques
de texto en claro n+3 n-3 n-1 n+1 n n-2 n+2 Bloques
de texto cifrado
![]()
![]()
![]()
![]()
![]()
Cifradores de flujo. Para algunas
aplicaciones, tales como el encriptado de conversaciones telefónicas, la
encriptación en bloques es inapropiada porque los flujos de datos se producen
en tiempo real en pequeños fragmentos. Las muestras de datos pueden ser tan
pequeñas como 8 bits o
incluso de 1 bit, y
sería un desperdicio rellenar el resto de los 64 bits
antes de encriptar y transmitirlos. Los cifradores de caudal son algoritmos de
encriptado que pueden realizar la encriptación incrementalmente, convirtiendo
el texto en claro en texto criptografiado bit a bit. Esto se logra
construyendo un generador del flujo de clave. Un caudal de clave
es una secuencia de bits de tamaño arbitrario que puede emplearse para
oscurecer los contenidos de un caudal de datos combinando el caudal de clave
con el caudal de datos mediante la función XOR . Si el caudal de clave es
seguro, el caudal de datos encriptados también lo será.
Se puede construir un generador del caudal de clave
iterando una función matemática sobre un rango de valores de entrada para
producir un caudal continuo de valores de salida. Los valores de salida se
concatenan entonces para construir bloques de texto en claro, y los bloques se
encriptan empleando una clave compartida por el emisor y el receptor. Para
conservar la calidad de servicio del caudal de datos, los bloques del flujo de
clave deberían producirse con un poco de antelación sobre el momento en que
vayan a ser empleados, además el proceso que los produce no debiera exigir
demasiado esfuerzo de procesamiento como para retrasar el caudal de datos.
Diseño de algoritmos criptográficos.
Existen muchos algoritmos criptográficos bien diseñados tales que E(K, M) = {M}k oculta
el valor de M y resulta prácticamente imposible recuperar K con
mejor éxito que el que proporciona la fuerza bruta. Todos los algoritmos de
encriptación se apoyan en manipulaciones que preservan la información de M
y emplean principios basados en la teoría de la información que describe los
principios de confusión y difusión para el ocultamiento del contenido del bloque de criptograma M,
combinándolo con una clave K de tamaño suficiente para ponerlo a prueba
de ataques por fuerza bruta.
Cifrador de caudal. n+3 n+2 n+1 Flujo
de texto cifrado Flujo
de texto En
claro Flujo
de clave![]()
![]()
![]()

![]()
![]()
![]()
![]()
![]()
![]()
![]()
Confusión: Las
operaciones de carácter no destructivo como XOR y el desplazamiento circular se
emplean para combinar cada bloque de texto en claro con la clave, produciendo
un nuevo patrón de bits que oscurece la relación entre los bloques de M
y los de {M}k.
Difusión: En el
texto en claro es normal que aparezcan repeticiones y redundancias. La difusión
disipa la existencia de patrones regulares mediante la transposición de panes
de cada bloque de texto en claro. Si se emplea CBC, la redundancia también se
distribuye a lo largo de un texto suficientemente grande. Los cifradores de
caudal no pueden emplear difusión dado que no hay bloques.
ALGORITMOS DE CLAVE
SECRETA (SIMÉTRICOS)
Describiremos a
continuación tres de ellos. El primero, TEA, se ha escogido por la simplicidad
de su diseño e implementación. Se continua la discusión con DES e IDEA aunque
en menor detalle. DES ha sido un estándar nacional de los EE.UU. aunque su
interés es histórico dado que sus
claves de 56 bits
son demasiado reducidas para resistir un ataque por fuerza bruta con el
hardware actual. IDEA emplea una clave de 128 bits y
es, probablemente, el algoritmo de encriptación simétrico de bloques más
efectivo.
TEA. Los
principios de diseño para los algoritmos simétricos que se delinearon
anteriormente se ven ilustrados en Tiny
Encryption Algorithm (TEA, pequeño algoritmo de encriptación).
Void encripta (unsigned long k [ ], unsigned
long texto [ ]{
unsigned
long y = texto [0], z = texto [1];
unsigned long delta = 0x 9e3779v9, suma = 0; int n;
for ( n = 0 ; n < 32; n ++){
suma +
= delta;
y
+ = (( z << 4) + k [0]) ^ ( z + suma) ^ (( z >> 5) + ( k [1]);
z
+ = (( y << 4) + k [2]) ^ (y + suma ) ^ (( y >> 5 ) + (k [3]);
}
texto [0] = y; texto [1] = z;
}
El algoritmo TEA emplea vueltas de sumas enteras,
XOR y desplazamientos lógicos de bits, para obtener la difusión y confusión de
los patrones de bits en el texto en claro. El texto en claro es un bloque de 64
bits representado como dos enteros de 32 bits en el vector de texto [ ]. La
clave tiene 128 bits representada como cuatro enteros de 32 bits. Esta clave es
segura contra los ataques de fuerza bruta.
En cada una de las 32 etapas, se combinan
repetidamente las dos mitades del texto con porciones desplazadas de la clave y
entre sí en las líneas 5 y 6 el empleo de XOR sobre porciones del texto
desplazada introduce confusión y el desplazamiento e intercambio de las dos
porciones del texto introduce difusión. La constante delta que se
combina con cada porción del texto en cada ciclo para oscurecer la clave en
caso de que fuera revelada por una sección de texto que no variará. La función
de desencriptado es la inversa de función de encriptación.
Void encripta (unsigned long k [ ], unsigned
long texto [ ]{
unsigned long y = texto [0], z = texto [1];
unsigned long delta = 0x 9e3779v9, suma = 0; int n;
for ( n = 0 ; n < 32; n ++){
suma +
= delta;
y
+ = (( z << 4) + k [2]) ^ ( z + suma) ^ (( z >> 5) + ( k [3]);
z
+ = (( y << 4) + k [0]) ^ (y + suma ) ^ (( y >> 5 ) + (k [1]);
}
texto [0] = y; texto [1] = z;
}
DES: El Estandar de Encriptación de Datos (Data
Encryption Standar), usado para aplicaciones gubernamentales y de negocios.
En este estándar la función de encriptación proyecta un texto en claro de 64
bits usando una clave de 56 bits. El algoritmo tiene 16 etapas dependientes de
claves conocidas como Vueltas en las que el dato a
encriptar se rota bit a bit un número de veces que depende de la clave y tres
transposiciones no dependientes de la clave. Sobre los computadores de los años
setenta y ochenta, el algoritmo suponía un coste computacional no despreciable,
y consecuentemente fue implementado en hardware VLSI con su consiguiente
aplicación en interfaces de red y demás dispositivos de comunicación.
A pesar de que aún se emplea en muchas aplicaciones
comerciales y de otro tipo, DES, en su forma básica, debe considerarse obsoleta
para la protección de aquello que no sea información de bajo interés. En la
práctica se utiliza un sistema conocido como triple-DES (o 3DES). Este
método conlleva la aplicación repetida de DES con dos claves K1
y K2:
E3DES (K1 , K2
,M)= EDES
(K1 , EDES (K2
, EDES ,( K1 ,M)))
Esto proporciona una
resistencia contra los ataques por fuerza bruta equivalente a una longitud de
clave de 112 bits,
proporcionando resistencia suficiente para un futuro previsible a corto plazo,
aunque tiene el problema menor de mayores requerimientos de cálculo, como
resultado de la aplicación repetida de un algoritmo que aisladamente ya es
lento para los estándares modernos.
IDEA. El Algoritmo de
Encriptación de Datos Internacional (International Data Encription
Algorithm, IDEA) se desarrolló a comienzos de los años noventa como
sucesor de DES. Como TEA, emplea una clave de 128 bits
para encriptar bloques de 64 bits.
El algoritmo se basa en el álgebra de grupos y tiene ocho vueltas XOR, suma
módulo 216 y multiplicación. Tanto DES como IDEA, emplean una misma
función para la encriptación y desencriptación: una propiedad útil para los
algoritmos que han de implementarse en hardware.
El IDEA realiza la encriptación y desencriptación a
una velocidad tres veces superior que la de DES.
AES. En 1997, el
Instituto Nacional para los Estándares y la Tecnología (NIST) publicó una
invitación para remitir propuestas de un algoritmo seguro y eficiente que seria
adoptado como nuevo Estándar de Encriptación Avanzada (Advanced Encryption
Standard, AES)
La comunidad de investigación sobre
criptografía remitió quince algoritmos, como respuesta a la invitación inicial
para el AES. Tras una intensa inspección técnica se seleccionaron cinco de
ellos para la siguiente fase de evaluación. Todos los candidatos soportaban
claves de 128, 192 y 256 bits, siendo todos ellos de altas
prestaciones. La evaluación concluyó en mayo del año 2000, cuando se
seleccionó un estándar preliminar.
ALGORITMOS DE CLAVE
PÚBLICA (ASIMÉTRICOS)
Hasta la fecha sólo se
han desarrollado unos pocos esquemas prácticos de clave pública. Dependen del
uso de funciones de puerta falsa de números grandes para producir las claves.
Las claves Ke y Kd son números muy grandes, y la función de
encriptación realiza una operación, con una exponenciación de M, usando
una de ellas. La desencriptación es una función similar usando la otra clave.
Si la exponenciación usa una aritmética modular, puede demostrarse que el
resultado es el mismo que el valor original de M; es decir:
D ( Ke E ( Ke, M ) ) = M
Un principal que
desee participar en una comunicación segura con otros confecciona un par de
claves Ke, y Kd y guarda en secreto la
clave de desencriptación Kd. La clave de encriptación Ke
puede publicarse para cualquiera que desee comunicar; la que podrá verse
como parte de una función de encriptación de un sentido E, y la clave de
desencriptación Kd es el conocimiento secreto que permite al
principal p invertir la encriptación. Cualquiera que posea Ke
puede encriptar mensajes íMýke, pero
solamente el principal que posea el secreto Kd puede operar
la puerta falsa.
El algoritmo RSA es
ciertamente el algoritmo de clave pública más conocido que lo describiremos a
continuación
RSA. (Rivest, Snamir y Adelman ) el diseño para el
encriptador de clave pública, se basa en el uso del producto de dos números
primos muy grandes (mayores que 10^100),
la determinación de los factores primos de números tan grandes es
computacionalmente imposible de calcular.
A es objeto de
extensas investigaciones, no se encontrándose flaquezas en él hasta el momento,
por lo que se lo usa ampliamente.
Bosquejo del método RSA
Para encontrar las
claves e, d:
1. Elíjanse dos números primos grandes, P
y Q (mayores que10^100), y fórmese
N = P x Q
Z = (P- 1) x (Q- 1)
2. Para d
elíjase cualquier número primo con relación a Z (esto es, que d no tenga factores en común con Z).
Ilústreme los cálculos correspondientes empleando valores
pequeños de P y Q
P = 13 . Q = 17
→ N = 221 . Z = 192
d = 5
3. Para
encontrar e resuélvase la ecuación:
e x d = 1 mod Z
Esto
es, e x d es el número más pequeño divisible por d en la
serie Z + 1, 2Z + 1, 3Z + 1,
Para encriptar
el texto en claro se divide en bloques iguales de longitud k bits
donde 2 ^ k < N (el valor numérico de un bloque es siempre
menor que N; en aplicaciones prácticas, k está generalmente en el
rango de 512 a 1.024).
La función de encriptación de un bloque de texto en
claro M es:
E' ( e, N, M ) = M ^e
mod N
Para desencriptar un bloque de texto encriptado c para producir el bloque de texto en claro original es:
D' ( d, N, c) = c^
d mod N
S e probó que E'
y D' son inversas mutuas (esto es, que E' ( D' (x) ) = D' (
E' (x) ) = x ) para
cualquier valor P en el rango 0 ≤ P ≤ N.
Se podría intentar
desencriptar un mensaje desconocido encriptando exhaustivamente secuencias
arbitrarias de bits hasta que concuerden con el mensaje objetivo. Este ataque
se conoce como ataque de texto en claro escogido, y se vence asegurando
que todos los mensajes son más largos que la longitud de la clave, de forma que
el ataque por fuerza bruta sea menos factible que un ataque directo sobre la
clave.
Algoritmos de curvas elípticas._
Un
algoritmo puede generar pares de claves pública / privada basándose en las
propiedades de las curvas elípticas.
Las claves de derivan de una rama diferente de las matemáticas, y a
diferencia de RSA su seguridad no depende de la dificultad de la factorización
de números grandes. Las claves cortas son seguras, y los requisitos de
procesamiento para la encriptación y la desencriptación son menores.
Podrían ser adoptados más ampliamente en el
futuro, especialmente en sistemas como los que incorporan los dispositivos
móviles, con recursos de procesamiento limitados.
La criptografía de clave pública es apropiada para
el comercio electrónico porque no hay necesidad de un mecanismo de distribución
segura de claves.
La criptografía de clave pública demanda costos
elevado para la encriptación incluso de mensajes de tamaño medio como los que
se encuentran habitualmente en el comercio electrónico.
La solución
adoptada en los sistemas distribuidos de gran escala es el empleo de un esquema
de encriptación híbrido en el que se emplea criptografía de clave pública para
autentificar cada parte y para encriptar un intercambio de claves secretas, que
se emplearán para toda la comunicación subsiguiente.-
Una firma digital robusta es un requisito
esencial para los sistemas seguros. Se las necesita para certificar ciertos
trozos de información, por ejemplo para proporcionar enunciados dignos de
confianza que relacionan identidades de usuarios con claves públicas.
Las firmas manuscritas necesitan verificar que
éste es:
·
Autentico:
convence al receptor de que el firmante firmó deliberadamente el documento y
que la firma no ha sido alterado por nadie .
·
Infalsificable:
aporta la prueba de que el firmante firmó el documento.
·
No
repudiable: el firmante no puede negar de forma creíble que el documento fue
por él.
Las propiedades de los documentos digitales
almacenados en archivos o mensajes son completamente diferentes de las de los
documentos en papel. Los documentos digitales son trivialmente fáciles de
generar, copiar y alterar. La simple adición de la identidad del emisor en
forma de cadena de texto, una fotografía o una imagen manuscrita, no tiene
valor alguno como medio de verificación.
Lo que se requiere es un medio de enlazar una
identidad de un firmante a la secuencia completa de bits que representa un
documento. Con esto cumplimos el primer requisito anterior, de autenticidad.
Como con las firmas manuscritas, la fecha del documento no está garantizada por
la sola firma. El destinatario de un documento firmado sólo sabe que el documento fue firmado con anterioridad
a la recepción.
Se puede considerar que un documento con firma
digital es más robusto frente a la falsificación que un escrito a mano.
FIRMAS DIGITALES CON CLAVES PUBLICAS
La criptografía de clave pública se adapta
particularmente bien a la generación de firmas digitales dado que es
relativamente simple y no requiere ninguna comunicación entre el destinatario
de un documento firmado y el firmante.
El método para que A firme un mensaje M y B lo
verifique es el siguiente:
Firmado Firmado


1)
A
genera un par de claves Kpub y Kpri y publica la calve Kpub
situándola en una ubicación bien conocida.
2)
A
calcula el resumen de M,H(M) empleando una función de dispersión segura H
acordada y la encripta utilizando la calve privada Kpri para producir la firma S = (H(M)) Kpri
3)
A
envía el mensaje firmado (M)K = M, S a B
B desencripta S empleando Kpub y calcula el resumen de M,
H(M). si concuerda, la firma es valida.
Funciones resumen. Las funciones resumen se
denominan también funciones de dispersión seguras y se denotan con H(M). Éstas
deben diseñarse cuidadosamente para asegurar que H(M) sea diferente de H(M')
para todos los probables pares de mensajes M y M'.
FIRMAS DIGITALES CON CLAVES
SECRETAS, MAC
No hay ninguna razón técnica por la que un
algoritmo de encriptación de clave secreta no pueda usarse para encriptar una
firma digital, pero existen algunos problemas:
·
El
firmante debe conseguir que el verificador reciba la clave secreta empleada
para firmar de modo seguro.
·
Debe
ser necesario poder verificar una firma en varios contextos diferentes y en
momentos diferentes.
·
El
descubrimiento de una clave secreta empleada para una firma es poco deseable
puesto que debilita la seguridad de las firmas realizadas con ellas, podrían
falsificarse una firma por alguien que posea la clave y que no sea su
propietario.
Existe una excepción cuando se utiliza un canal
seguro para transmitir los mensajes desencriptados pero subsiste la necesidad
de verificar la autenticidad de los mensajes. Estas firmas se denominan códigos de autenticidad de mensajes (MAC) para
reflejar su objetivo más limitado: autentican la comunicación entre pares de
principales basándose en un secreto compartido.
El siguiente método ilustra la técnica de firmado
de bajo coste basada en claves secretas que da seguridad suficiente para muchos
propósitos:
1)
A
genera una clave aleatoria K para firmar, y la distribuye utilizando canales
seguros a uno o más principales que necesitan autenticar los mensajes recibidos
de A.
2)
Para
cualquier documento M que A desee firmar. A concatena M con K , calcula el
resumen del resultado : h = H (m + k) y envía el documento firmado (M)k = M , h
a cualquiera que desee verificar la firma ( el resumen h es un MAC). K no queda comprometida por la publicación
de h, dado que la función de diversión oscurece totalmente su valor.
3)
El
receptor, B, concatena la clave secreta K con el documento recibido M y calcula
el resumen h´= H ( M + K ). La firma es valida si h = h´.


La ventaja de este método es que no involucra
encriptación alguna. (La dispersión segura es aproximadamente de 3 a 10 veces
mas rápida que la encriptación simétrica).
Hay muchas formas de
producir un patrón de bits de longitud fija que caracterice un mensaje o documento
de longitud arbitraria. Quizás la más simple es utilizar repetidamente la
operación XOR para combinar trozos de tamaño fijo del documento fuente. Tal
función se emplea a menudo en protocolos de comunicación para producir un
patrón de dispersión de longitud fija para caracterizar un mensaje con fines de
detección de errores; pero este sistema es inadecuado como base de un esquema
de firma digital.
Una función de
resumen segura h = H(Af)
debería poseer las siguientes propiedades:
Tales funciones se denominan también funciones de
dispersión de un solo sentido. La propiedad 3 requiere
una característica adicional: incluso aunque conozcamos que la aplicación de la
función de dispersión no dé un valor único (porque el resumen es una
transformación de reducción de información), necesitamos asegurarnos que un
atacante, dado un mensaje M que produce un valor h, no pueda
descubrir otro mensaje M' que también produzca
h. Si un atacante pudiera hacer esto,
podría falsificar un documento firmado M' sin tener que conocer la clave
de la firma, simplemente copiando la firma del documento firmado M y
añadiéndosela a M'.
Desde luego, el conjunto de mensajes que se aplican
sobre el mismo valor está restringido y el atacante lo tendría difícil para
producir una falsificación con sentido, pero con paciencia podría hacerse, de
modo que hay que prevenirlo. La posibilidad de conseguirlo aumenta
considerablemente si se emplea el denominado (ataque del cumpleaños
(birdrthday attack):
Si nuestros valores de dispersión tienen un tamaño de 64 bits, sólo necesitamos 2" versiones de M y
M' por término medio. Es demasiado poco para quedar conforme. Al menos
necesitamos que nuestros valores de dispersión tengan 128 bits para alejar el peligro de este ataque.
El ataque descansa sobre la paradoja estadística
conocida como la paradoja del cumpleaños: la probabilidad de encontrar un par
idéntico en un conjunto dado es mucho mayor que la de encontrar la pareja para
un individuo dado.
Para
satisfacer las propiedades indicadas anteriormente hay que diseñar la función
de resumen segura cuidadosamente. Las operaciones al nivel de bit empleadas y
su secuenciación son similares a las que se encuentran en la criptografía
simétrica, pero en este caso las operaciones no tienen por qué preservar la
información, dado que la función no tiene por qué ser reversible en absoluto. De
modo que una función de resumen segura puede emplear cualquier operación
aritmética y lógica al nivel de bit. La longitud del texto fuente se incluye
habitualmente entre los datos resumidos.
Dos funciones de resumen ampliamente utilizadas son
el algoritmo MD5 (llamado así porque es el quinto de una serie de algoritmos de
resumen desarrollados por Ron Rivest) y el SHA (Secure Hash Algoritm)
adoptado para su estandarización por el NIST.
MD5. El
algoritmo MD5 emplea cuatro vueltas, cada una aplicando una
de cuatro funciones no lineales a cada uno de los dieciséis segmentos de 32 bits de un bloque de texto fuente de 512 bits. El resultado es un resumen de 128 bits. MD5 es uno
de los algoritmos más eficientes de que se dispone hoy en día.
SHA. Es un algoritmo
que produce un resumen de 160 bits.
Se basa en el algoritmo de Rivest MD4 (similar a MD5) con
algunas operaciones adicionales. Es sustancialmente más lento que MD5, pero el resumen de 160 bits ofrece una mayor seguridad contra los
ataques por fuerza bruta y del cumpleaños.
Empleo de un algoritmo de encriptación para obtener
un resumen. Es posible utilizar un algoritmo de encriptación
simétrico para producir un resumen seguro. En este caso, la clave debería ser
pública de modo que el algoritmo pudiera ser aplicado por cualquiera que
deseara verificar una firma digital. El algoritmo de encriptado se emplea en
modo CBC, y el resumen es el resultado de combinar el penúltimo valor CBC con
el bloque final encriptado.
X.509 es el formato
estándar de certificación más ampliamente usado [CCITT 1988b]. es parte del
estándar X.500 para la construcción de directorios globales de nombres y
atributos.
La estructura y contenido de un certificado X.509 se enlaza una clave pública a
una entidad con nombre denominada sujeto. El enlace está en la firma,
que es emitida por otra entidad denominada emisora. El certificado tiene
un período de validez, que es definido mediante dos fechas. Los
contenidos etiquetados como < Nombre Diferenciado > se refieren al nombre de una
persona, organización o cualquier otra entidad junto con suficiente información
contextual para darlo por único.
Formato de
Certificado X.509.
Sujeto Nombre Diferenciado,
Clave
pública Emisor Nombre Diferenciado, Firma Período de validez Fecha inicio, Fecha
expiración Información administrativa Versión, Número de Serie Información añadida
Procedimiento de verificación
de dos pasos para cualquier certificado X.509:
1.
Obtener el certificado de clave pública del emisor (una autoridad de
certificación) desde una fuente fiable.
2.
Validar la firma.
Aproximación SPKI. La aproximación X.509 se basa en la
unicidad global de los nombres diferenciados. Ya se ha indicado que esta meta
es inalcanzable dado que no refleja la realidad actual legal y de la práctica
comercial en la que no se presupone la unicidad de la identidad de los
individuos si no se hace referencia a otras personas y organizaciones. Esto se
pone en evidencia, por ejemplo, en el uso de un permiso de conducción o una
carta de un banco para autenticar el nombre y dirección de un individuo (un
nombre a secas puede estar repetido si consideramos la población mundial). Esto
nos lleva a cadenas de verificación más largas, puesto que hay muchos emisores
posibles de certificados de clave pública, y sus firmas deben validarse a
través de una cadena de verificación que nos lleve a alguien conocido en quien
confíe el principal que realiza la verificación. A pesar de ello la
verificación resultante suena más convincente, y muchos de los pasos de esta
cadena pueden guardarse para acortar el proceso en otras ocasiones.
Los argumentos de
arriba son la base de las propuestas recientemente desarrolladas para la
Infraestructura de Clave Pública Simple (Simple Public-key Infrastructure,
SPKI) Éste es un esquema para la creación y administración de conjuntos de
certificados públicos. Posibilita el procesamiento de cadenas de
certificaciones empleando inferencia lógica para producir certificados
derivados.
PRESTACIONES DE LOS ALGORITMOS
CRIPOTOGRÁFICOS
|
TEA DES Triple-DES IDEA RSA RSA MD5 SHA |
Tamaño de clave / tamaño de dispersión(bits) 128 56 112 128 512 2048 128 160 |
Velocidad extrapolada (kbytes/sec) 700 350 120 700 7 1 1740 750 |
PRB
optimizado (kbytes/s) ---- 7746 2842 4469 ---- ---- 62425 25162 |
En el cuadro que vemos arriba se puede observar
el tamaño de la clave y la velocidad de los algoritmos de encriptación y las
funciones de resumen seguras.
Se dan dos medidas de seguridad:
1.
Velocidad Extrapolada: basada en cifras de Schneier
excepto para TEA, que se basan en Wheeler y Needham [1994].
En ambos casos se han ajustado las cifras
teniendo en cuenta los avances de los procesadores. Los números pueden tomarse
como estimaciones aproximadas sobre un procesador Pentium II a 330 Mhz.
La longitud de las claves encriptadas
proporciona una indicación del coste computacional de un ataque por fuerza
bruta sobre la clave. La autentica resistencia de los algoritmos criptográficos
es mucho mas difícil de evaluar.
La diferencia entre las dos columnas de
prestaciones proviene del hecho de que las cifras dada por Schneier están
basadas en el código C, sin ningún intento de optimizar el código. Y las del
PRB son el resultado de un esfuerzo para producir implementaciones
propietarias, optimizadas, de los algoritmos en el lenguaje ensamblador.
Preneel y otros presentan una discusión útil sobre la resistencia y
prestaciones de los algoritmos simétricos.
Los
algoritmos sobresalen alrededor de los años ochenta y noventa, cuando comienzan
a utilizarse las redes de computadores con objetivos comerciales, por esto se
hace evidente las necesidades de seguridad naciendo así la criptografía (arte
de escribir con clave o de modo enigmático).
Pero
esta necesidad emergente trajo aparejado el surgimiento de grandes obstáculos
políticos como lo que impuso la Agencia de Seguridad Nacional (National Security
Agency, NSA) al precisar que este
mecanismo criptográfico al estar disponible para otras naciones, volvía
vulnerable cualquier comunicación secreta por objetivos de inteligencia
militar; y otra de las oposiciones también dependiente del gobierno de los
EE.UU. mas precisamente por la Oficina Federal de Investigación (Federal
Bureau of Investigation, FBI) trataba sobre asegurar que sus agentes
pudieran tener acceso privilegiado a las claves empleadas por todas las
organizaciones privadas e individuos de los EE.UU. con el objetivo de poder
ejercer la ley.
Como
conclusión el software criptográfico se clasificó como armamento y quedaba
sujeto a estrictas restricciones de exportación lo que llevo a grandes
compañías de software de los EE.UU. a
protestar ante los mismos ya que estas
restricciones inhibían la exportación de cierto software como los
visualizadores, logrando reformar las restricciones de modo que se permitía la
exportación de código que utilizara claves de no más de 40 bits.
La
situación actual es que el software que implementa la mayoría de los algoritmos
criptográficos ha estado disponible por todo el mundo durante años,
impreso y en línea, en versiones
comerciales y gratuitas Por ejemplo el programa llamado PGP (Pretty Good
Privacy), que es parte de una campaña técnica y política para asegurar que
la disponibilidad de métodos criptográficos no se encuentre controlada por el
gobierno de los EE.UU. (otorgaba cierto grado de privacidad al usuario)
El
gobierno de los EE.UU. tomo conciencia del daño que causaba (con las políticas
N.S.A.) a la industria de computadores y en enero del año 2000
introduce
una nueva política que permitió a los
vendedores de software de los EE.UU.
exportar productos software que incorporara encriptación de hasta 64 bits y hasta 1.024 en el caso de claves públicas
para su uso en firmas e intercambios de claves.
CASOS DE ESTUDIO: NEEDHAM-SCHROEDER, KERBEROS, SSL
Y MILLICENT
Los
protocolos de autenticación publicados Needham y Schroeder
[1978] son
el núcleo de muchas técnicas de seguridad siendo uno de los más importantes
entre sus sistemas de protocolo el Kerberos que fue diseñado para proporcionar
autenticación entre clientes y servidores en redes.
Existen
dos casos de estudio que describen protocolos de seguridad en el nivel de
aplicación importante para el comercio electrónico:
EL PROTOCOLO DE
AUTENTICACIÓN DE NEEDHAM Y SCHROEDER
Fue
empleado debido a una necesidad urgente
de mejores formas de administrar la seguridad de las redes locales.
En
la misma publicación, Needham y Schroeder también confeccionan un protocolo
basado en el uso de claves públicas para autenticación y distribución de claves
y que no depende de la existencia de servidores de claves seguros, resultando
el más adecuado para su empleo en redes con muchos dominios de administración
independientes, como Internet.
La
propuesta autentica de estos dos creadores se basa en un servidor de
autenticación que proporciona claves secretas a sus clientes en forma segura.
El trabajo del
servidor de autenticación es proporcionar una forma segura por la que pares de
procesos obtengan claves compartidas. Para hacer esto, debe comunicarse con sus
clientes usando mensajes encriptados.
Needham
y Schroeder con claves secretas. El protocolo se describe para dos procesos arbitrarios A y B, pero en
sistemas cliente-servidor, A es cualquier cliente que inicie una secuencia de solicitudes
hacia algún servidor B. La clave le viene dada a A de dos formas, una que A
puede usar para encriptar los mensajes que envíe a B y otra que pueda
transmitir de modo seguro a B. (La última se encuentra encriptada en una clave
que es conocida por B pero no por A, de modo que B puede desencriptarla y no se
compromete durante la transmisión.)
El
servidor de autenticación S mantiene una tabla que contiene un nombre y una
clave secreta para cada principal conocido por el sistema.
Nunca
se muestra a terceras partes y se transmite por la red como máximo una sola
vez, cuando se genera.
Una
clave secreta sería el equivalente de la contraseña (password) que se
emplea para autenticar usuarios en los sistemas centralizados. Para los
principales humanos, el nombre conocido por el servicio de autenticación es su
<<nombre de usuario>> y la clave secreta es su password.
El
protocolo se basa en la generación y transmisión de tickets por el servidor de
autenticación, que son mensaje
encriptado que contiene una clave para su uso en la comunicación.
El
servidor de autenticación es S. Na y NB son ocasiones. Una ocasión es un valor entero que se añade a un mensaje para
demostrar su frescura. Las ocasiones se utilizan una sola vez y se generan bajo
demanda únicos mensajes que han sido enviados conteniendo KAB fueron encriptados en la clave secreta de A o
en la de B.
|
ENCABEZADO 1. A à S: 2. S à A: 3. A à B: 4. B à A: 5. A à B: |
MENSAJE A, B, NA {NA, B, KAB, {KAB, A}KB}KA {KAB, A}KB {NB}KAB {NB – 1}KAB |
ANOTACIONES A solicita a S una clave para comunicarse con B. S retorna un mensaje encriptado en la clave
secreta de A, que contiene una clave
nueva KAB, y un <<ticket>> encriptado en la
clave secreta de B. La ocasión NA demuestra
que el mensaje fue enviado en respuesta a la anterior. A cree que S envió el
mensaje porque solo S conoce la clave secreta de A. A envía el <<ticket>> a B. B desencripta el ticket y usa la nueva clave KAB para
encriptar otra ocasión NB. A demuestra a B que fue el emisor del mensaje
anterior devolviendo una transformación acordada sobre NB. |
Protocolo de
autenticación de clave secreta de Needham – Schroeder
Existe
una debilidad en este protocolo, ya que un intruso puede obtener información de
un descuido y utilizarla para iniciar un intercambio posterior con B,
suplantando a A, para que no ocurra este ataque debe comprometerse un antiguo valor de KAB, en terminología de hoy en día. Esta
posibilidad no fue incluida por Needham y Schroeder en su lista de amenaza
cuando debían hacerlo, pero esta debilidad se puede remediar añadiendo una
ocasión o una marca temporal. Solución adoptada por Kerberos.
Kerberos
se desarrolló en el MIT en los años ochenta, para proporcionar un catalogo de
medios de autenticación y seguridad para su uso en la red de computación del
campus en el MIT y otras intranets. Ha soportado varias revisiones y mejoras,
de las cuales surgió entre otras la versión 5 de Kerberos ( 1994 ), la cual
esta en vía de ser un estándar Internet y es usada hoy en día por muchas
compañías y universidades. El código fuente de la implementación de Kerberos
está disponible desde el MIT, en el Entorno de Computación Distribuida de OSF y
en el sistema operativo Windows 2000 como servicio de autenticación como
servicio de autenticación por defecto. Se ha propuesto su extensión para
incorporar el uso de certificados de clave pública para la autenticación
inicial de principales.
Kerberos
trata con tres clases de objetos de segundad:
Ticket:
una palabra enviada a un cliente por el servicio de concesión de tickets para su presentación a un servidor particular, y que verifica que el
emisor se ha autenticado recientemente frente a Kerberos.
Los tickets incluyen un tiempo de expiración y una clave de sesión generada en
este momento para su uso por el cliente y el servidor.
Autenticación:
una palabra construida por un cliente y enviada al servidor para demostrar la
identidad del usuario y la actualidad de cualquier comunicación con un
servidor. Un autenticador sólo puede usarse una
vez. Éste contiene el nombre del cliente y una marca temporal y se encripta con la clave de sesión apropiada.
Clave de sesión: una clave secreta
generada aleatoriamente por Kerberos y enviada a un cliente para su uso en la
comunicación con un servidor particular; la clave de sesión se emplea para
encriptar la comunicación con aquellos servidores que la pidan y para encriptar
todos los autenticadores.
Los
procesos clientes deben poseer un ticket y una clave de sesión para cada
servidor que empleen. La mayoría de los tickets se conceden a los clientes con
un periodo de vida de varias horas, de modo que puedan utilizarse para
interactuar con un servidor particular hasta que expiran.
Un
servidor Kerberos es conocido como Centro de Distribución de Claves, ofrece un
Servicio de Autenticación y un Servicio de Concesión de Tickets. Al presentarse
al sistema, los usuarios son autenticados por el SA, y el proceso del cliente
que actúa en representación del usuario recibe un ticket de concesión de
tickets y una clave de sesión para comunicarse con el SCT. Posteriormente el
proceso cliente original puede usar el ticket de concesión de tickets y las
claves de sesión para los servicios especificados desde el SCT.
El
Kerberos tiene muy en cuenta los valores del tiempo (fecha y hora) usando como
ocasiones. Esto sirve a dos objetivos:
·
Protegerse de la repetición de mensajes
antiguos o rechazar los viejos tickets encontrados en algún lugar de la memoria
de máquina.
·
Aplicar un tiempo de vida a los tickets,
permitiendo que el sistema revoque los derechos de acceso de usuarios cuando,
por ejemplo, deja de ser usuarios autorizados del sistema.
Aplicación
de Kerberos.
Kerberos
se desarrolló para su uso en el proyecto Atenía en el MIT; una infraestructura
de computación en red por todo el campus. El entorno es tal que no es posible
presuponer ni la confianza en los clientes ni la seguridad de la red y las
máquinas que ofrecen servicios de red; por ejemplo, las estaciones de trabajo
no están protegidas por la instalación de software desarrollado por los
usuarios, y las máquinas servidoras ( diferentes al servidor Kerberos) no están
aseguradas contra una interferencia física con su configuración software.
Kerberos
proporciona virtualmente toda la seguridad del sistema Atenía. Se emplea para
autenticar usuarios y otros principales. La mayoría de los servidores que
operan en la red solicitan un ticket de cada cliente al comienzo de cada interacción
cliente-servidor. En éstos se incluyen, el almacenamiento de archivos, correo
electrónico, etc.. Las claves de acceso de los usuarios son conocidas solo por
cada uno de ellos y por el servicio de autenticación Kerberos. Los servicios
tienen claves secretas conocidas solo para Kerberos y los servidores que
proporcionan el servicio.
Entrada
en el sistema con Kerberos.
Cuando
un usuario entra en una estación de trabajo, el programa de bienvenida envía el
nombre del usuario al servicio de autenticación de Kerberos. Si el usuario es
conocido al servicio de autenticación éste responde con una clave de sesión y
una ocasión encriptada en una clave de acceso y un ticket para el SCT. El
programa de bienvenida, ahora, intenta desencriptar la clave de sesión y la
ocasión empleando la clave de acceso que deberá introducir el usuario. Si la
clave de acceso es correcta, el programa de bienvenida comprueba la ocasión y
almacena la clave de sesión junto al ticket para ser usado cuando se comunique
con el SCT. En este momento, el ticket ya sirve para autenticar al usuario; se
inicia la sesión del usuario en la estación del sistema. La clave del usuario
nunca se expone en la red y se borra de la memoria tan pronto como se ha
empleado.
Acceso
a los servidores en Kerberos.
Cuando
un programa en ejecución solicita el acceso a un nuevo servicio, pide un ticket
para este servicio al servicio de concesión de tickets. Por ejemplo, cuando un
usuario desea acceder a un computador remoto, el mandato rlogin de la estación
del usuario obtendrá un ticket del servicio de concesión de ticket de Kerberos
para acceder al servicio de red rlogind. El programa del mandato
rlogin envía el ticket, junto con un nuevo autenticador. El programa rlogind
desencripta el ticket con la clave secreta del servicio rlogin y
comprueba la validez del ticket.
Implementación de Kerberos. Se
emplea el algoritmo de encriptación DES, pero se implementa en un módulo
separado que puede reemplazarse fácilmente.
El servicio Kerberos
es escalable; el mundo se divide en dominios de autoridades de autenticación
separados, denominados esferas ( realms ), cada una con su propio
servidor Kerberos. La mayoría de los principales están registrados en una sola
esfera, pero los servidores de concesión de ticket de Kerberos están
registrados en todas las esferas. Dentro de un dominio, puede haber varios
servidores de autenticación, cada uno de los cuales tiene copias de la misma
base de datos de autenticación. La base de datos de autenticación se replica
mediante una simple técnica maestro-esclavo. Las actualizaciones se aplican a
la copia maestra por un único servicio de Administración de Base de Datos
Kerberos (Kerberos Datábase Management, KDBM) que se ejecuta sólo en la
máquina maestra. El KDBM maneja las solicitudes de cambio de claves de acceso
de los usuarios y las peticiones de los administradores para añadir o borrar
principales y para cambiar sus claves de acceso.
Para
hacer transparente este esquema a los usuarios, el tiempo de vida de los
tickets TGS debería ser tan largo como la sesión de usuario más larga posible,
dado que el uso de un ticket expirado trae consigo el rechazo de las
solicitudes de servicio.
SSL está soportada en
la mayoría de los visualizadores y se usa ampliamente en el comercio en
Internet Sus características más importantes son:
Encriptacion y
algoritmos de encriptación negociables. SSL se ha diseñado
para que puedan negociarse los algoritmos de encriptación y autenticación entre
los procesos al principio y al final de la conexión durante el saludo (handsake)
inicial. Pudiera ocurrir que no tuvieran suficientes algoritmos en común, y
en este caso el intento de conexión fallaría.
Autoarranque de la comunicación segura. Para
cumplir con la necesidad de comunicación segura sin
una negociación previa y sin ayuda de tercera partes, el canal seguro emplea
una comunicación no encriptada en los intercambios
iniciales después criptografía de clave pública y
finalmente se conmuta a criptografía de clave privada una vez que se ha
establecido una clave de secreta compartida El cambio a cada etapa es opcional
y viene precedido por una negociación
Consiguientemente el
canal seguro es completamente configurable, permitiendo que la comunicación en
ambas direcciones este incriptada y autenticada
SSL consta de dos capas, una capa de Protocolo de
Registro SSL, que implementa
un canal seguro encriptando y autenticando mensajes transmitidos a través de
cualquier protocolo orientado
a conexión, y una capa
de handsake, conteniendo
el protocolo de handsake y otros dos protocolos relacionados que establecen y
mantienen una sesión SSL (esto es, un canal seguro) entre un cliente y un
servidor.
El protocolo de registro de SSL es una capa de nivel
de sesión; puede emplearse para transportar datos del nivel de aplicación de
modo transparente entre un par de procesos mientras garantiza su privacidad,
integridad y autenticidad. En SSL hay opciones para que los participantes de la
comunicación escojan si desplegar o no la desencriptación y autenticación de
los mensajes en cada dirección. A cada sesión segura se le da un identificador
y cada participante puede almacenar los identificadores de sesión en una caché
para su uso subsiguiente, evitando la sobrecarga de establecer una nueva sesión
cuando se requiere otra sesión segura con el mismo compañero.
Protocolo de handshke SSL Protocolo de alerta
SSL Telnet HTTP Cambio especificaciones Cifrado SSL
![]()
![]()
Protocolo de registro
SSL
Capa de transporte
(habitualmente TCP)
Capa de red
(habitualmente IP)
![]()
Protocolos SSL Otros
protocolos
SSL se usa
ampliamente para añadir una capa de comunicación segura a los protocolos del nivel
de aplicación existentes. Su uso más extendido es, probablemente, la seguridad
de las interacciones HTTP. El uso del prefijo de protocolo https: en un
URL inicia el establecimiento de un canal seguro SSL entre un navegador y un
servidor web. También se ha empleado para proporcionar implementaciones seguras
de Telnet, FTP y muchos otros protocolos de aplicación. SSL se utiliza en
aplicaciones que requieran canales seguros, con interfaces de programación para
CORBA y Java.
El handshake se realiza sobre una conexión
existente. Comienza con texto en claro y establece una sesión SSL
intercambiando las opciones y parámetros acordados que se necesitan para
realizar la encriptación y la autenticación. La secuencia de handshake varía
dependiendo de si se requiere, o no, autenticación de cliente y servidor. Protocolo
de handshake de SSL

SSL
soporta una variedad de opciones de funciones criptográficas. El nombre
colectivo que recibe es catálogo de cifrado. Un catálogo de cifrado incluye
una elección única para cada una de las características.
Se
suelen encontrar ya cargadas cierta variedad usual de catálogos de cifrado, con
identificadores estándar tanto en el cliente como en el servidor. Durante el
handshake, el servidor ofrece al cliente una lista de los identificadores de
catálogos de cifrado disponibles, y el cliente responde seleccionando uno de
ellos. En esta etapa también deben acordar (opcionalmente) un método de
compresión y un valor de arranque aleatorio para las funciones de encriptación
de bloque CBC .
El
Protocolo de registro de seguridad de SSL muestra la operación del protocolo de
registro. Un mensaje a transmitir se fragmenta inicialmente en bloques de un
tamaño manejable, y opcionalmente después se comprimen. La compresión no es
estrictamente una característica de la comunicación segura, pero se incorpora
aquí para sacar provecho del procesamiento masivo de datos que se genera en los
algoritmos de encriptación y firma digital. En otras palabras, dentro de la
capa SSL de registro se puede establecer conjuntamente un flujo de
transformaciones sobre los datos mucho más eficiente que si se realizaran
individualmente.
Las
transformaciones de encriptado y autenticación de mensajes (MAC) lanzan los
algoritmos especificados en el catálogo de cifrado acordado. Finalmente, el
bloque firmado y encriptado se transmite al destinatario mediante la conexión
TCP asociada, donde se invierten las transformaciones para producir el bloque
de datos originales.
Protocolo
de registro de seguridad de SSL:
abcdefghi
Datos de la aplicación


Fragmentada /
combinada
def ghi abc
Unidades de registros de protocolo
Comprimen
Unidades comprimidas
![]()
Dispersion
Mac
Encriptar
![]()
Encriptado
Transmite
Paquete TCP
Resumen. SSL proporciona una
implementación práctica de un esquema de encriptación híbrido con autenticación
e intercambio de claves basado en claves públicas. Dado que los cifradores se
negocian en la etapa de handshake, no depende de la disponibilidad de ningún
algoritmo en particular. Tampoco depende de servicios de seguridad en el
momento de establecer la sesión. El único requisito es que los certificados de
clave pública enviados por una autoridad sean reconocidos por ambas partes.
TRANSACCIONES ELECTRÓNICAS DE PEQUEÑO IMPORTE: EL PROTOCOLO MILLICENT
Un requisito de los sistemas de paso seguro en
Internet es que sea económico y conveniente para la compra de servicios de
impone pequeño y el acceso a recursos electrónicos con precios en el rango de 0,1 a 100
céntimos. El
esquema emplea la forma simple de una firma digital basada en clave secreta
para reducir su costo computacional. Sólo se empleará la encriptación cuando se
requiera privacidad.
Sistemas de pago actual y sus desventajas. Los
autores del protocolo Millicent han resumido las desventajas de los métodos de
pago disponibles actualmente como sigue. Todos ellos necesitan seguridad
criptográfica, sus costes de comunicación y de cálculo varían pero en cualquier
caso son no despreciables.
Tarjetas de crédito: El problema del
empleo de tarjetas de crédito para pequeñas transacciones es el alto costo de
la transacción que resulta de la necesidad de interaccionar con el sistema
central de la compañía, lo cual se agrava por los costos adicionales de las
transacciones electrónicas seguras y otras características como la preparación
de informes para los clientes.
Los clientes mantienen cuentas con los vendedores: Los
clientes necesitan establecer una cuenta con un vendedor antes de la primera
transacción. Los costos de la transacción son entonces bajos, pero la
sobrecarga inicial tiende a desanimar las transacciones casuales. Un vendedor
debe mantener una entrada de cliente en una base de datos de cuentas durante un
período bastante largo.
Acumulación de transacciones: Cuando
un cliente realiza varias cuentas, el vendedor puede guardar los registros de
ellas y facturarle al final del período. Esto es parecido al mantenimiento de
cuentas aunque puede evitar ciertos costos iniciales. El vendedor debe mantener
registros incluso de los clientes que han realizado una sola compra, y el costo
de ésta podría exceder el beneficio.
Dinero digital: AI igual que el
dinero convencional, el dinero digital (es decir testigos digitales de un
valor, emitidos por un banco o un agente de bolsa) ofrecería un medio eficiente
de pago para transacciones pequeñas, pero los desarrolladores del dinero
digital deben resolver el problema del doble gasto. El doble gasto es
una consecuencia del hecho de que el portador de un testigo digital puede
realizar cualquier número de copias indetectables.
El esquema Millicent. El proyecto
Millicent ha desarrollado un esquema para la distribución segura y el uso de vales
(scrip).
• Tiene un valor sólo
para un vendedor específico
• Sólo se
puede gastar una vez
• Es resistente a las
modificaciones y difícil de falsificar
• Sólo puede gastarlo
su auténtico propietario
• Puede producirse y
validarse eficientemente
El diseño del esquema Millicent es escalable porque cada
servidor del vendedor es responsable solamente de validar el vale que ha
emitido Los clientes pueden adquirir vales directamente del vendedor, o de un
intermediario que posea vales de muchos vendedores, mediante una transacción
comercial
El vale (scnp),
la moneda específica de un vendedor presentada por Millicent, se representa
mediante fichas digitales con el siguiente formato:
Vendedor ID
Vale ID
Cliente Fecha de expiración Valor
propiedades Certificado
El campo de propiedades está disponible para
los usos que determine el vendedor. EL certificado es una firma digital
que protege todos los campos del vale contra su modificación La firma se
produce mediante un método MAC.
El vale lo generan y
distribuyen brokers; son servidores que tratan con los vales de modo
masivo, relevando a los clientes y a los servidores de algunas de las
sobrecargas que implica el uso de vales y los intermediarios que intercambian
vales por dinero real, comprando vales (o el derecho de generarlos) a los
vendedores, con cierto descuento, y vendiéndolos a los clientes con cargo a una
tarjeta de crédito u otro medio de pago .
Metas. Millicent se diseñó
como un sistema de dinero electrónico que evita las sobrecargas de comunicación
y los retrasos asociados a los sistemas centralizados, mientras que proporciona
una seguridad adecuada para prevenir el uso fraudulento. La seguridad de los
vales se basa en las firmas digitales: se emplea encriptación para mantener la
privacidad sólo cuando sea necesario.
El esquema Millicent funciona aisladamente. Puede
implementarse sin apoyo de otros servicios, como un servicio de nombres seguro.
Este genera y distribuye claves secretas únicas para su uso por las partes de
las transacciones con vales.
Implementación.
Antes de generar cualquier vale, un vendedor (o un
intermediario con licencia de un vendedor) generará un vector de secretos
maestros de vale de 64 bits.
Cada secreto de esta clase sería suficiente, pero la disponibilidad de vanos
permite seleccionar uno nuevo cada vez para evitar su descubrimiento por
accidente o en caso de un ataque con éxito.
Cada elemento del vale tiene un identificador único.
Su valor incluye un índice de secretos maestros de 8 bits, que se emplea
para seleccionar un secreto maestro del vector de secretos maestros.
Los secretos maestros son retenidos por el vendedor
y se emplea uno de ellos para producir un certificado por cada elemento del
vale que se genera.
Para validar elemento de un vale:
1) El
vendedor comprueba que no ha sido falsificado o modificado por medio de una
comprobación de firma para lo que emplea el secreto maestro relevante (usando
el índice de secretos maestros a partir del ID-vale para seleccionarlo del
vector de secretos maestros) y lo compara con la firma del certificado.
2) El
vendedor comprueba que el vale no ha sido ya
gastado. Para hacer esto, ella mantiene una lista de los ID y fechas de
expiración de todos los vales que ha emitido, con una indicación de si ha sido
ya gastado El campo de 1.: fecha de
expiración permite al vendedor borrar el vale caducado de la lista, previniendo
-sí que crezca continuamente. Los clientes deben intercambiar vales viejos por
los nuevos antes de que caduquen.
La protección contra
el robo requiere que el vendedor o el intermediario que vende vales mantengan
un vector de secretos maestros -del cliente (seleccionados utilizando
una parte del ID-cliente) y enviar a cada cliente un secreto de cliente.
El secreto del cliente se construye añadiendo el secreto maestro del cliente al
ID-cliente y aplicando una función de dispersión segura como MD5 al resultado.
El secreto del cliente debe transmitirse desde el vendedor al cliente mediante
un canal seguro. Se recomienda emplear SSL en cada compra inicial de vales.
Una vez transmitido al cliente, el secreto del
cliente puede usarse como una clave secreta compartida entre el cliente y el
vendedor. El cliente puede usarla para firmar transacciones y tanto el cliente
como el vendedor pueden usarla como clave de encriptación cuando se requiere
confidencialidad.
Para prevenir el
robo, las transacciones están firmadas por el cliente, usando su secreto del
cliente, y el vendedor comprueba que el ID-cliente del vale concuerda con el
ID-cliente asociado con el secreto del cliente. Si no, entonces el vale seria
gastado por alguien distinto al cliente a quien se vendió; en otras palabras,
sena robado.
Para proporcionar
confidencialidad, un cliente envía su ID-cliente al vendedor y establece un
canal seguro usando un algoritmo de encriptación de clave secreta con la clave
del cliente como clave de encriptación. El canal seguro es un medio útil para
realizar una transacción en secreto.
CONCLUSIÓN: Los ataques a la seguridad son partes de la
realidad de los sistemas distribuidos. En esencial proteger los canales e
interfaces de comunicaciones de cualquier sistema que trate con información que
sea susceptible de ser atacada.
Sistemas
Distribuidos. Capítulo 7. Páginas (235 - 289). 3º Edición . Coulouris Dolumore.
![]()
Número de visitantes actuales disponible desde el 14/07/2002:
Autor: lrmdavid@exa.unne.edu.ar
Ó FACENA - http://exa.unne.edu.ar
Servicios WEB: webmaster@exa.unne.edu.ar