El cifrado basado en certificados es un sistema en el que una autoridad de certificación utiliza criptografía basada en ID para producir un certificado . Este sistema proporciona a los usuarios una certificación tanto implícita como explícita, el certificado se puede utilizar como un certificado convencional (para firmas, etc.), pero también implícitamente con fines de cifrado.
Ejemplo [ editar ]
Un usuario Alice puede encriptar doblemente un mensaje usando la clave pública ( Bob ) de otro usuario y su identidad ( Bob ).
Esto significa que el usuario ( Bob ) no puede descifrarlo sin un certificado actualmente válido y también que la autoridad de certificación no puede descifrar el mensaje ya que no tiene la clave privada del usuario (es decir, no hay depósito implícito como con la criptografía basada en ID) , ya que el doble cifrado significa que no pueden descifrarlo únicamente con la información que tienen). El certificado es la confianza entre dos partes.
Revocación de clave [ editar ]
La revocación de claves se puede agregar al sistema al exigir que se emita un nuevo certificado con la frecuencia que requiera el nivel de seguridad. Debido a que el certificado es "información pública", no necesita ser transmitido por un canal secreto. La desventaja de esto es el requisito de una comunicación regular entre los usuarios y la autoridad de certificación, lo que significa que la autoridad de certificación es más vulnerable a los ataques electrónicos (como los ataques de denegación de servicio ) y también que tales ataques podrían detener efectivamente el funcionamiento del sistema. . Este riesgo puede reducirse parcial pero no completamente al tener una jerarquía de múltiples autoridades de certificación.
Aplicaciones prácticas [ editar ]
El mejor ejemplo de uso práctico del cifrado basado en certificados es el Sistema de codificación de contenido (CSS, por sus siglas en inglés), que se utiliza para codificar películas en DVD de tal manera que solo se puedan reproducir en una parte del mundo donde se venden. Sin embargo, el hecho de que la clave de descifrado de la región se almacene a nivel de hardware en los reproductores de DVD debilita sustancialmente esta forma de protección.
Un ataque de texto cifrado elegido ( CCA ) es un modelo de ataque para el criptoanálisis en el que el criptoanalista puede recopilar información obteniendo las descifraciones de los textos cifrados elegidos . A partir de estos datos, el adversario puede intentar recuperar la clave secreta oculta utilizada para el descifrado.
Para definiciones formales de seguridad contra ataques de texto cifrado elegido, ver por ejemplo: Michael Luby [1] y Mihir Bellare et al.
Introducción [ editar ]
Una serie de esquemas seguros pueden ser derrotados bajo el ataque de texto cifrado elegido. Por ejemplo, el criptosistema El Gamal es semánticamente seguro bajo un ataque de texto plano elegido , pero esta seguridad semántica puede ser derrotada trivialmente bajo un ataque de texto cifrado elegido. Las primeras versiones del relleno RSA utilizado en el protocolo SSL eran vulnerables a un sofisticado ataque adaptativo de texto cifrado elegido que revelaba claves de sesión SSL. Los ataques de texto cifrado elegido también tienen implicaciones para algunos cifrados de flujo de sincronización automática . Diseñadores de tarjetas inteligentes criptográficas resistentes a la manipulación. debe ser particularmente consciente de estos ataques, ya que estos dispositivos pueden estar completamente bajo el control de un adversario, que puede emitir una gran cantidad de textos cifrados elegidos en un intento de recuperar la clave secreta oculta.
No estaba claro en absoluto si los criptosistemas de clave pública pueden resistir el ataque de texto cifrado elegido hasta el trabajo inicial de Moni Naor y Moti Yung en 1990, que sugirió un modo de encriptación dual con prueba de integridad (ahora conocido como "Naor-Yung" paradigma de cifrado). [3] Este trabajo hizo que la comprensión de la noción de seguridad contra el ataque de texto cifrado elegido fuera mucho más clara que antes y abrió la dirección de investigación para construir sistemas con diversas protecciones contra variantes del ataque.
Cuando un sistema de cifrado es vulnerable al ataque de texto cifrado elegido, los implementadores deben tener cuidado para evitar situaciones en las que un adversario pueda descifrar los textos cifrados elegidos (es decir, evitar proporcionar un oráculo de descifrado). Esto puede ser más difícil de lo que parece, ya que incluso los textos cifrados parcialmente elegidos pueden permitir ataques sutiles. Además, existen otros problemas y algunos sistemas criptográficos (como RSA ) utilizan el mismo mecanismo para firmar mensajes y descifrarlos. Esto permite ataques cuando el hash no se usa en el mensaje que se firmará. Un mejor enfoque es usar un sistema de cifrado que sea demostrablemente seguro bajo ataque de texto cifrado elegido, incluyendo (entre otros) RSA-OAEP seguro bajo la heurística aleatoria de oráculo, Cramer-Shoupque fue el primer sistema práctico de clave pública en ser seguro. Para los esquemas de cifrado simétrico, se sabe que el cifrado autenticado, que es una primitiva basada en el cifrado simétrico, brinda seguridad contra ataques de texto cifrado elegidos, como lo demostraron por primera vez Jonathan Katz y Moti Yung . [4]
Variedades [ editar ]
Los ataques de texto cifrado elegido, como otros ataques, pueden ser adaptativos o no adaptativos. En un ataque adaptativo de texto cifrado elegido, el atacante puede usar los resultados de descifrados anteriores para informar sus elecciones de qué textos cifrados se descifrarán. En un ataque no adaptativo, el atacante elige descifrar los textos cifrados sin ver ninguno de los textos claros resultantes. Después de ver los textos simples, el atacante ya no puede obtener el descifrado de textos cifrados adicionales.
Ataques a la hora del almuerzo [ editar ]
Una variante especialmente notada del ataque de texto cifrado elegido es el ataque "almuerzo", "medianoche" o "indiferente", en el que un atacante puede realizar consultas adaptativas de texto cifrado elegido, pero solo hasta cierto punto, después de lo cual el atacante debe demostrar alguna habilidad mejorada para atacar el sistema. [5] El término "ataque a la hora del almuerzo" se refiere a la idea de que la computadora de un usuario, con la capacidad de descifrar, está disponible para un atacante mientras el usuario está almorzando. Esta forma de ataque fue la primera que se discutió comúnmente: obviamente, si el atacante tiene la capacidad de hacer consultas adaptativas de texto cifrado elegidas, ningún mensaje cifrado sería seguro, al menos hasta que se elimine esa capacidad. Este ataque a veces se denomina "ataque de texto cifrado elegido no adaptativo"; aquí, "no adaptativo" se refiere al hecho de que el atacante no puede adaptar sus consultas en respuesta al desafío, que se da después de que la capacidad de realizar consultas de texto cifrado ha expirado.
Ataque adaptativo de texto cifrado elegido [ editar ]
Un ataque de texto cifrado elegido (completo) adaptativo es un ataque en el que los textos cifrados se pueden elegir de forma adaptativa antes y después de que se le dé un texto cifrado de desafío al atacante, con la única condición de que el texto cifrado de desafío no se pueda consultar. Esta es una noción de ataque más fuerte que el ataque a la hora del almuerzo, y comúnmente se conoce como un ataque CCA2, en comparación con un ataque CCA1 (hora del almuerzo). [6] Pocos ataques prácticos son de esta forma. Más bien, este modelo es importante para su uso en pruebas de seguridad contra ataques de texto cifrado elegido. Una prueba de que los ataques en este modelo son imposibles implica que no se puede realizar ningún ataque realista de texto cifrado elegido.
Un ataque práctico adaptable de texto cifrado elegido es el ataque Bleichenbacher contra PKCS # 1 . [7]
Numerosos sistemas criptográficos están probados como seguros contra ataques adaptativos de texto cifrado elegido, algunos demuestran esta propiedad de seguridad basada solo en suposiciones algebraicas, y algunos requieren además una suposición de oráculo aleatorio idealizado. Por ejemplo, el sistema Cramer-Shoup [5] es seguro basado en suposiciones teóricas de números y sin idealización, y después de una serie de investigaciones sutiles también se estableció que el esquema práctico RSA-OAEP es seguro bajo el supuesto RSA en el azar idealizado modelo de oráculo.
En criptografía , una lista de revocación de certificados (o CRL ) es "una lista de certificados digitales que han sido revocados por la autoridad emisora de certificados (CA) antes de su fecha de vencimiento programada y ya no se debe confiar".
Estados de revocación [ editar ]
- Revocado: un certificado se revoca de forma irreversible si, por ejemplo, se descubre que la autoridad de certificación (CA) emitió un certificado de forma incorrecta, o si se cree que una clave privada se ha visto comprometida. Los certificados también pueden revocarse por incumplimiento de la entidad identificada con los requisitos de la política, como la publicación de documentos falsos, la tergiversación del comportamiento del software o la violación de cualquier otra política especificada por el operador de CA o su cliente. La razón más común para la revocación es que el usuario ya no está en posesión exclusiva de la clave privada (por ejemplo, el token que contiene la clave privada se ha perdido o ha sido robado).
- Retener: este estado reversible se puede utilizar para observar la invalidez temporal del certificado (por ejemplo, si el usuario no está seguro de si se ha perdido la clave privada). Si, en este ejemplo, se encontró la clave privada y nadie tenía acceso a ella, el estado podría restablecerse y el certificado es válido nuevamente, eliminando así el certificado de futuras CRL.
Razones para la revocación [ editar ]
unspecified(0)keyCompromise(1)cACompromise(2)affiliationChanged(3)superseded(4)cessationOfOperation(5)certificateHold(6)removeFromCRL(8)privilegeWithdrawn(9)aACompromise(10)
Tenga en cuenta que el valor 7 no se utiliza.
Publicación de listas de revocación [ editar ]
Una CRL se genera y publica periódicamente, a menudo en un intervalo definido. También se puede publicar una CRL inmediatamente después de que se haya revocado un certificado. Un emisor de CRL emite una CRL, que normalmente es la CA que también emitió los certificados correspondientes, pero que podría ser otra autoridad confiable. Todas las CRL tienen una vida útil durante la cual son válidas; este plazo suele ser de 24 horas o menos. Durante un período de validez de CRL, una aplicación habilitada para PKI puede consultarlo para verificar un certificado antes de su uso.
Para evitar ataques de suplantación de identidad o denegación de servicio , las CRL generalmente llevan una firma digital asociada con la CA por la cual se publican. Para validar una CRL específica antes de confiar en ella, se necesita el certificado de su CA correspondiente,
Los certificados para los que se debe mantener una CRL a menudo son certificados X.509 / clave pública , ya que este formato es comúnmente utilizado por los esquemas PKI.
Revocación vs. caducidad [ editar ]
Las fechas de vencimiento no son un sustituto de una CRL. Si bien todos los certificados caducados se consideran inválidos, no todos los certificados no caducados deben ser válidos. Las CRL u otras técnicas de validación de certificados son una parte necesaria de cualquier PKI operada adecuadamente, ya que se espera que ocurran errores en la verificación de certificados y la gestión de claves en las operaciones del mundo real.
En un ejemplo digno de mención, se emitió por error un certificado para Microsoft a un individuo desconocido, que se había hecho pasar exitosamente como Microsoft ante la CA contratada para mantener el sistema ActiveX 'certificado de editor' ( VeriSign ). [3] Microsoft vio la necesidad de parchear su subsistema de criptografía para verificar el estado de los certificados antes de confiar en ellos. Como una solución a corto plazo, se emitió un parche para el software de Microsoft relevante (lo más importante, Windows) que enumera específicamente los dos certificados en cuestión como "revocados". [4]
Problemas con las CRL [ editar ]
Las mejores prácticas requieren que donde sea y sin importar el estado del certificado se mantenga, debe verificarse siempre que se desee confiar en un certificado. De lo contrario, un certificado revocado puede ser aceptado incorrectamente como válido. Esto significa que para usar una PKI de manera efectiva, uno debe tener acceso a las CRL actuales. Este requisito de validación en línea niega una de las principales ventajas originales de PKI sobre los protocolos de criptografía simétrica , a saber, que el certificado es "auto autenticado". Los sistemas simétricos como Kerberos también dependen de la existencia de servicios en línea (un centro de distribución clave en el caso de Kerberos).
La existencia de una CRL implica la necesidad de que alguien (o alguna organización) aplique la política y revoque los certificados considerados contrarios a la política operativa. Si un certificado se revoca por error, pueden surgir problemas importantes. Como la autoridad de certificación tiene la tarea de hacer cumplir la política operativa para la emisión de certificados, generalmente es responsable de determinar si la revocación es apropiada y cuándo es adecuada al interpretarla.
La necesidad de consultar una CRL (u otro servicio de estado de certificado) antes de aceptar un certificado plantea un posible ataque de denegación de servicio contra la PKI. Si la aceptación de un certificado falla en ausencia de una CRL válida disponible, entonces no se pueden realizar operaciones que dependan de la aceptación del certificado. Este problema también existe para los sistemas Kerberos, donde la falla al recuperar un token de autenticación actual impedirá el acceso al sistema.
Una alternativa al uso de CRL es el protocolo de validación de certificados conocido como Protocolo de estado de certificado en línea (OCSP). OCSP tiene el beneficio principal de requerir menos ancho de banda de red, permitiendo verificaciones de estado en tiempo real y casi en tiempo real para operaciones de alto volumen o alto valor.
A partir de Firefox 28, Mozilla ha anunciado que están despreciando la CRL a favor de OCSP. [5]
Los archivos CRL pueden crecer bastante con el tiempo, por ejemplo, en el gobierno de EE. UU., Para ciertas instituciones de varios megabytes. Por lo tanto, las CRL incrementales se han diseñado [6] a veces denominadas "CRL delta". Sin embargo, solo unos pocos clientes los implementan.
No hay comentarios:
Publicar un comentario