RSA es un estándar oficial y de facto. Al ser el sistema de encriptación mediante clave pública, más utilizado, es una opción segura a la hora de implementar sistemas de encriptación en aplicaciones. El uso generalizado de RSA facilita el intercambio de firmas digitales. Este estándar está muy asentado en los protocolos de transacciones financieras que se están creando para el comercio por vía electrónica. Sólo esta particularida confirma que RSA tiene mucho peso como estándar seguro.
RSA y DES:
RSA es más un complemento que un sustituto de la encriptación DES. Ambos sistemas poseen ventajas de las que el otro carece. DES es un sistema rápido de encriptación que funciona bien en encriptaciones de gran tamaño. Mientras que RSA es bueno para encriptar mensajes pequeños, DES es una mejor elección con mensajes más grandes debido a su velocidad. Además, RSA ofrece firmas digitales y un intercambio seguro de claves sin necesidad de intercambio previo de códigos secretos.
Un usuario que proteja ficheros solo para su uso personal probablemente no use RSA. En este caso, normalmente, basta con un sistema de encriptación de una sola clave como DES, ya que transmitir la clave a otra persona no supone ningún peligro. RSA adquiere importancia cuando tiene que compartir mensajes con otros.
Combinar los dos sistemas de encriptación es como enviar un mensaje codificado en una envoltura segura. Una transacción típica con envoltura digital RSA con otra parte, podría realizarse de la siguiente manera:
Funcionamiento de RSA:
RSA empieza con dos grandes números primos: p y q. El producto de p y q es n, es decir, el módulo. Puede que encuentres documentación relativa a RSA en la que se recomienda elegir un par de claves con números primos "fuertes". Un número primo "fuerte" es el que posee propiedades que dificultan la factorización del producto (n) con determinados métodos.
Un módulo es el proceso matemático de dividir dos operandos y declarar el resto.
Factorización es el proceso de dividir un entero en un pequeño conjunto de enteros (factores) que, al multiplicarlos, dan como resultado el entero inicial. La factorización de números primos exige dividir un entero en factores que son números primos. Multiplicar dos enteros primos resulta fácil, pero factorizar el producto resulta más difícil. Por este motivo los enteros primos son los candidatos predilectos para los sistemas de encriptación. Invertir el proceso de multiplicación empleando números primos resulta extremadamente difícil. A esto se le denomina función "unidireccional", es decir, que es fácil realizar en dirección hacia delante, pero mucho más difícil en dirección inversa.
Debido a los nuevos métodos de factorización, el método de dominio público de elegir números primos "fuertes" ha dejado de suponer una ventaja. Los nuevos métodos tienen tanto éxito con los primos fuertes como con los primos débiles.
Otro aspecto a tener en cuenta a la hora de elegir los números primos, es el tamaño de módulo que te interesa. Aquí entran en juego concesiones mutuas: un módulo más grande crea un sistema de encriptación más seguro, pero también ralentiza el proceso de encriptación. Elije el tamaño del módulo en función de las necesidades de seguridad o en función de los recursos que pode emplear un asaltante para descifrar su mensaje encriptado. A continuación ofrecemos varios datos triviales de investigación que pueden ayudarte a tomar una decisión: las estimaciones de Rivest indican que un asaltante puede factorizar un módulo de 512 bits con un gasto de 8,2 millones de dólares. Si necesita un módulo de 512 bits, cada uno de sus números primos debería tener una longitud aproximada de 256 bits.
El paso siguiente es elegir un número, llamado e, que sea menor que el valor de n y también relativamente primo con respecto a (p-1)(q-1). Después averigüa su valor inverso, d, (mód(p-1)(q-1). Esto quiere decir que (ed=1 mód(p-1)(q-1).
Las variables e y d son, respectivamente, los exponentes público y privado. El par de la clave pública es (n,e). La clave privada es d. Debe mantener secretos los factores p y q o bien destruirlos.
Antes de empezar a redactar tu propio mensaje cifrado, presta atención a la parte que viene a continuación, porque revela el talón de Aquiles de la encriptación RSA.
Averiguar la clave privada a partir de la combinación de la clave pública (n,e) es prácticamente imposible. Observa ahora las variables (p y q) que deseas ocultar o destruir. Si factorizas n en p y q, puedes descubrir la clave privada (d).
El algoritmo de la encriptación RSA sigue estos pasos:
Identificación RSA
La autentificación RSA es un método que se emplea específicamente para crear firmas digitales. Una firma digital posee una ventaja decisiva sobre una firma manuscrita. Con una firma manuscrita, se puede alterar el contenido de un documento sin invalidar la firma. Esto no se puede hacer con una firma digital, porque el contenido del documento comprende la propia firma digital.
La no obtención de una firma digital no siempre significa que alguien haya manipulado indebidamente su documento. Si está transmitiendo el documento por Internet o por otras líneas de una red, la no obtención de una firma digital podría también indicar que se está transfiriendo un fichero determinado.
La firma digital se obtiene a partir de un extracto del mensaje. Un extracto de mensaje es el resultado de una función hash. Una función hash es un algoritmo matemático que lee una fuente de datos de entrada, normalmente un mensaje o algún tipo de documento, y devuelve una salida binaria compacta que representa a la fuente. Otro tipo de programas, como por ejemplo las bases de datos, emplean funciones hash como referencia de la fuente de datos en búsquedas rápidas.
Una función hash emplea una entrada de tamaño variable y devuelve una cadena de tamaño fijo, denominada valor hash.
Las funciones hash que son difíciles de invertir resultan especialmente útiles para crear extractos de mensajes. Un extracto de mensaje es una representación concisa del mensaje que se ha utilizado para crear el extracto. Cualquier modificación del propio mensaje da lugar a una cadena de extracto de mensaje distinta, lo que hace a éste útil como firma digital.
Existen varias funciones de extracto de mensaje conocidas, pero MD5 es quizá la mejor función que se puede implementar como firma digital. MD5 es segura, razonablemente rápida y tanto su comercialización como su uso carecen de restricciones. Para más detalle sobre la función MD5, véase la RFC 1321.
Existe una cuestión importante relativa a las firmas digitales, más bien de carácter jurídico que técnico. Puede que una firma digital no tenga la misma categoría jurídica que una firma manuscrita. Nadie ha cuestionado aún ante un tribunal la validez de una firma digital, por lo que no existe precedente jurídico. No obstante, el National Institute of Standards and Technology (NIST) ha solicitado la opinión de la Oficina General de Contabilidad (GAO) de Estados Unidos en relación con la categoría jurídica de la firma digital. La opinión de la GAO es que las firmas digitales observen las normas jurídicas de las firmas manuscritas.
Especificaciones de seguridad actuales
Las especificaciones son las directrices para la implementación de un concepto. Por ejemplo, Netscape Communications tiene la especificación Secure Sockets Layer (SSL), que aplica en sus productos, Netscape Navigator y Netscape Commerce Server.
Cuando desees implementar una especificación o RFC, por motivos, bien personales o bien comerciales, siempre deberías investigar las cuestiones de propiedad de los algoritmos que se emplean en la especificación. Algunos algoritmos se encuentran en el dominio público, otros quizá resulten gratuitos para uso personal o académico. Si decides implementar un protocolo en una aplicación o producto comercial, puede que tengas que pagar derechos de patente al propietario.
Otro elemento que debes tener en cuenta es el modo en que se solapan distintas especificaciones para resolver un problema similar. Tal vez tengas que emplear uno o varios métodos para resolver tu problema particular . Varios proyectos de Internet pretenden resolver el problema de la seguridad en Internet. Cada uno de estos estándares ataca el mismo problema. Cada estándar propuesto emplea métodos, como la encriptación, que comparte con los otros; con todo, cada propuesta de seguridad ofrece algo único. Los estándares en competencia a menudo suponen más trabajo para los programadores. Hasta que de una guerra de estándares salga un vencedor, quizá se tenga que implementar cada una de estas especificaciones para que los usuarios de una aplicación puedan realizar transacciones con usuarios de otros programas.
La Capa de Zócalos Seguros (SSL)
La SSL es una tecnología de seguridad de Internet del dominio público desarrollada por Netscape Communications. SSL combina elementos de un protocolo de transmisión de Internet con modernas técnicas de encriptación y autentificación. El resultado es un entorno seguro de comunicación de transacciones en una red pública insegura. La SSL implementa encriptación RSA para garantizar comunicaciones privadas y autentificadas por Internet.
El protocolo SSL ofrece tres propiedades fundamentales:
El protocolo de registro (Record Protocol) de SSL, un subconjunto del protocolo SSL, encapsula protocolos de nivel más alto, como el protocolo de establecimiento de comunicación (Handshake Protocol) de SSL. El Handshake Protocol de SSL, permite al servidor y al cliente autentificarse mutuamente y negociar un proceso de encriptación. Por desgracia, el proceso de establecimiento de comunicación de SSL, es un punto potencialmente débil de todo el proceso de seguridad. El proceso de autentificación del cliente es independiente de la solidez del cifrado que se emplee en la sesión. En otras palabras, la solidez del cifrado que el proceso emplea para fijar el proceso de la clave es más débil que la solidez del cifrado que se emplea en comunicaciones posteriores con la clave. La mejor posibilidad que tiene un asaltante de derrotar a la seguridad de SSL es descifrar el débil código que contiene la clave y luego usar esa clave para desencriptar la transacción.
Parte del proceso de establecimiento de comunicación consiste en coordinar los estados del cliente y del servidor. El estado de ambos aparatos puede ser operativo o pendiente. Esta coordinación permite a ambas partes actuar de forma estable, aunque no se encuentren en estados paralelos. Cuando se ha establecido totalmente la comunicación, el cliente y el servidor pueden intercambiar mensajes de especificación de cifrado.
Una especificación de cifrado define el algoritmo de encriptación de grandes volúmenes de datos y un algoritmo de extracto de mensajes. Define también atributos criptográficos, como el tamaño de hash.
SSL requiere un protocolo de transferencia fiable, como el Transmission Control Protocol (TCP). La capa situada por encima del TCP es el Record Protocol de SSL. La capa de registro de SSL recibe datos sin interpretar en bloques de tamaño arbitrario procedentes de clientes. SSL comprime todos los registros empleando el algoritmo de compresión definido en el estado actual de la sesión. Debe usar un algoritmo de compresión sin pérdidas.
La compresión con pérdidas es irreversible. Ofrece el mayor grado de compresión pero a expensas de la pérdida de información. La compresión con pérdidas intenta adivinar qué información puede sacrificar manteniendo el mayor parecido posible con los datos originales.
Sin embargo, la compresión sin pérdidas es reversible. No proporciona tanto compresión como el sistema con pérdidas, pero no pierde información y ofrece un método para recuperar los datos originales.
Aunque el protocolo SSL es en sí bastante complejo, no debería resultar muy difícil implementarlo en las aplicaciones. Esto se debe a que WinSock 2.0 ofrece posibilidades de incorporar SSL. Los creadores de la especificación WinSock 2.0 admiten la necesidad de contar con transmisiones seguras y el carácter omnipresente de Netscape Communications y de su protocolo SSL. En consecuencia, WinSock 2.0 permite nuevas definiciones de constantes y nuevas estructuras de registro para dar cabida a los creadores de aplicaciones que necesitan implementar el protocolo SSL.
LA TECNOLOGIA DE COMUNICACIÓN PRIVADA (PCT)
Microsoft creó el protocolo Private Communication Technology (PCT) para evitar la escucha electrónica en aplicaciones de cliente/servidor. Este protocolo es compatible con SSL, pero exige corregir o mejorar varios puntos débiles de SSL.
La finalidad de PCT es proporcionar una vía de acceso de comunicación privada entre un cliente y un servidor. El protocolo incorpora autentificación al servidor y ofrece la misma opción también a los clientes. Al igual que SSL, PCT requiere un protocolo de transmisión fiable, como TCP. También al igual que SSL, PCT es un protocolo independiente del protocolo de aplicaciones, por lo que protocolos de aplicaciones de nivel más alto como Hypertext Transport Protocol (HTTP) o FTP pueden superponerse y operar de forma transparente.
PCT inicia las conexiones estableciendo una comunicación para negociar algoritmo y clave de encriptación simétrica y luego autentificando el servidor. La diferencia entre PCT y SSL, en este aspecto radica en que, al establecer esta comunicación, PCT emplea claves públicas asimétricas certificadas. Esta medida ayuda a PCT a resolver uno de los problemas de seguridad de SSL potenciales. El protocolo PCT no especifica detalles en relación con la verificación del certificado. PCT espera que el programador aporte una función que decida la validez de los certificados recibidos. Aplicar sus propias normas de validación en realidad es una ventaja, porque le ofrece la opción de elegir un sistema de certificación en función de sus propias necesidades, no en las de un protocolo de transferencia seguro. Tras el establecimiento de la comunicación, PCT encripta todas las transmisiones de datos empleando la clave de sesión negociada durante el proceso de establecimiento de la comunicación.
PCT se diferencia de SSL, principalmente en la fase del establecimiento de la comunicación. Fuera de este aspecto, la seguridad es bastante parecida. Las diferencias principales entre PCT y SSL son:
El protocolo Secure Transaction Technology (STT) es una creación conjunta de Visa y Microsoft que pretende ofrecer un método para asegurar transacciones con tarjeta de crédito en redes abiertas como Internet.
Visa y Microsoft crearon STT como especificación abierta para el sector. Mientras tanto, MasterCard, IBM y otros trabajaron en otra especificación abierta para el sector: el Secure Electronic Payment Protocol (SEPP).
El 1 de febrero de 1996, MasterCard International y Visa International se unieron para anunciar un estándar técnico que pretende proteger las compras con tarjeta de pago efectuadas vía Internet. La nueva especificación recibió el nombre de Secure Electronic Transactions (SET), que combina ambos esfuerzos.
Entrar en un fichero encriptado es una tarea desalentadora y las personas adoptan siempre la línea de mínima resistencia. Descifrar una transacción encriptada es el equivalente moderno de volar el banco para robar el dinero. Como mínimo, no revela gran sutileza. Además, un delincuente debe decidir si el contenido justifica el esfuerzo. Si el botín que contiene el fichero encriptado no es más que una colección de películas de Charlie Brown en formato AVI, probablemente no justifica el esfuerzo que supone descifrar el fichero.
Suponga que un asaltante quiere robarle el dinero. En vez de asaltar
su fichero seguro, podría configurar un servidor de la Web que simule
representar a una empresa legal. Con un poco de programación creativa,
la ubicación del asaltante podría permitirle examinar un
catálogo electrónico de artículos. Una vez que usted
ha decidido hacer una compra, pone en funcionamiento su sistema de encriptación
supersecreto y envía un pago al servidor. Tras una buena ronda de
recogida de números de tarjetas de crédito, el servidor se
desconecta. Usted se pone a esperar angustiado un paquete que nunca llega
y, mientras espera, el asaltante le destroza el historial crediticio. Este
tipo de pesadilla es exactamente lo que quieren evitar los emisores de
tarjetas de crédito. Ya gastan millones de dólares en combatir
el fraude en las tarjetas de crédito.
Ideada para combatir tales estafas, STT tiene los siguientes objetivos:
Las especificaciones del protocolo STT, al igual que las demás especificaciones de seguridad, sólo se pueden aplicar a una parte de los protocolos necesarios para el comercio por vía electrónica. Ya existen protocolos estándar de Internet (como TCP/IP y HTTP) para ofrecer el mecanismo de transmisión, los servicios de comunicación y la interfaz de aplicaciones necesarios para el comercio. STT se diferencia de los protocolos que se han tratado anteriormente en este capítulo en que se centra exclusivamente en los aspectos de seguridad relacionados con las transacciones con tarjeta de crédito. Los siguientes aspectos de las transacciones con tarjeta de crédito caen dentro del ámbito del protocolo STT:
El proceso de autorización y liquidación difiere en función de la tarjeta que se use y de la relación establecida entre el comerciante y la entidad financiera. La STT no modifica el proceso de autorización y liquidación en sí. El comerciante es responsable de autorizar y liquidar transacciones de comercio por vía electrónica de la misma manera que procesa otras transacciones. Los términos de la autorización dependen del acuerdo que haya formalizado el comerciante con su banco.
La STT trae consigo una nueva aplicación de firmas digitales al exigir doble firma. El comercio por vía electrónica requiere dos conjuntos de autorizaciones. Imagine que desea enviar una oferta a un vendedor para comprar un artículo. Usted incluiría una firma digital para autentificarse a sí mismo como comprador y en todo caso validar el mensaje. Al mismo tiempo que envía su mensaje al vendedor, envía otro mensaje a su entidad bancaria en el que autoriza a ésta a liberar los fondos que especifica si el vendedor acepta y oferta. No es necesario que revele los pormenores de la oferta a la entidad bancaria. Lo único que precisa la entidad bancaria es su orden para liberar fondos si se cumple una determinada condición.
Para procesar automáticamente la oferta, el vendedor envía una solicitud de pago, que incluye su firma digital, a su entidad bancaria. La entidad bancaria coteja las firmas. Si verifica que las dos son iguales, transfiere los fondos a su vendedor. La transacción, desde el punto de vista bancaria, está completa.
Una firma doble concatena los extractos de mensaje de las cartas que ha dirigido al vendedor y a la entidad bancaria. STT procesa entonces otro extracto de mensaje del resultado de la concatenación y los encripta con la clave privada de la firma del signatario.
Un elemento fundamental de la autorización es una credencial tanto para los poseedores de tarjeta como para los comerciantes. La entidad bancaria proporciona una credencial a los poseedores de tarjeta. En teoría, no puede alterar estas credenciales y sólo la entidad bancaria puede elaborarlas. Del mismo modo, la entidad bancaria del comerciante emite la credencial del comerciante.