La PKI El diseño y la política de certificados afectan la seguridad de su red y sus dispositivos en general. Debe diseñar e implementar su PKI para evitar los peligros habituales, de la misma manera que garantizaría que su casa tenga cimientos resistentes a terremotos o un techo resistente a huracanes.
Muchas de estas decisiones deben tomarse con antelación., Durante el diseño y desarrollo de su software o producto. Si bien implementar las medidas de seguridad requeridas en su PKI requiere esfuerzo, tomar las precauciones necesarias le ayudará a reducir los problemas de seguridad en el futuro.
Piense en esto: ¿Qué riesgo para su seguridad representaría un certificado comprometido en su red? ¿Se podría acceder a un servidor usando la autenticación del certificado? ¿Podría usarse contra sus usuarios en un... ¿Ataque del hombre en el medio?
Al crear un programa o dispositivo que utilice certificados para autenticación o comunicaciones seguras, estas cuestiones deben considerarse cuidadosamente. Es necesario tomar decisiones técnicas sobre cómo su producto gestionará los certificados y cómo se diseñará y gestionará su PKI.
Este artículo está dirigido a diseñadores y productores que trabajan con certificados de dispositivos o clientes de confianza privada, como los que se encuentran en software o Internet de los objetos (IO) dispositivos.
Creación de una PKI con seguridad duradera
Conversamos frecuentemente con desarrolladores que desconocen sus alternativas para crear políticas de PKI y certificados. La PKI de confianza privada ofrece gran flexibilidad para los certificados de cliente y dispositivo, lo que permite aumentar la seguridad de su programa o dispositivo.
Analizaremos en detalle tres factores cruciales que debe considerar para mejorar su PKI. La elección de los períodos de validez y reemplazo de los certificados, la protección de las claves privadas y el uso de la revocación de certificados, así como el uso eficaz de estos controles para reducir el riesgo, son los tres primeros temas.
Aunque los certificados ofrecen autenticación y cifradoUsarlos no es tan sencillo como instalarlos y listo. Ambas cualidades pueden verse comprometidas, pero con las medidas de mitigación adecuadas también pueden fortalecerse.
La solución más sencilla podría ser configurar una PKI de mala calidad y no preocuparse nunca por administrar sus certificados, pero esto conlleva riesgos de seguridad en los que quizás no haya pensado.
Tomemos como ejemplo la reciente descontinuación de SHA-1. Los investigadores eran conscientes de la vulnerabilidad del método de hash SHA-1, diseñado para proporcionar firmas criptográficas que identificaran de forma única los certificados. El año pasado, Google mostró dos archivos distintos con el mismo hash en una colisión real.
El algoritmo SHA-1 fue prácticamente destruido por esta colisión, y muchos certificados se cambiaron por el algoritmo SHA-2, más seguro, para mantener la seguridad. También se incluyeron certificados de larga duración, que quedarían más expuestos con el tiempo (el aumento de la potencia de procesamiento facilita su explotación). Aunque una colisión SHA-1 parezca imposible ahora, ¿qué ocurrirá dentro de 5 años? ¿20 años? Estos son factores cruciales a tener en cuenta si sus productos se utilizarán durante un período prolongado.
La complejidad de la seguridad PKI se demuestra rápidamente con este sencillo ejemplo. Necesitaría una técnica para reemitir y reemplazar certificados en sus dispositivos, un mecanismo de revocación para gestionar los certificados que sabe que están comprometidos y la garantía de que su red y sus usuarios ya no estén expuestos para reducir los riesgos de seguridad de un algoritmo hash defectuoso.
Validez de un Certificado
En la sección SSL / TLS En el ámbito de las tecnologías vulnerables, las tecnologías vulnerables son un problema inevitable. Las tecnologías criptográficas fundamentales del protocolo se construyen con una fecha de desuso en mente, ya que anticipamos que computadoras más robustas en el futuro podrían comprometer su seguridad.
Se han producido cambios importantes en los últimos diez años, como el abandono de los algoritmos de hash MD5 y SHA-1 y la adopción de 2048 bits. Con el tiempo, nos quedaremos sin claves de 2048 bits y tendremos que reemplazarlas. Será mucho más fácil afrontar estos cambios si se cuenta con un plan.
Al determinar el tiempo de validez de sus certificaciones, debe sopesar las ventajas de un certificado de larga duración frente a la dificultad de proteger claves de larga duración. Proteger estas claves se vuelve más difícil con el tiempo, a medida que los estándares de cifrado se deterioran, se reemplazan y su colección de certificados se expande. Un algoritmo defectuoso podría eventualmente requerir la sustitución urgente de certificados para una seguridad sostenida, como en el caso de nuestro ejemplo SHA-1.
Es importante considerar tanto la fecha de vencimiento como el proceso de reemplazo de las certificaciones. En la mayoría de los casos, hemos descubierto que intentar usar un solo certificado durante toda la vida útil del dispositivo implica sacrificar demasiada seguridad.
Se establece una mayor variedad de certificados (y sus claves privadas) que deben mantenerse seguros seleccionando períodos de validez más largos. Al otorgarles acceso durante períodos más largos, se amplía el número de objetivos para los atacantes y se les motiva a comprometer un certificado. Esto, a su vez, hace que contar con un sistema de revocación sea crucial y requiere mantener los datos de revocación disponibles durante períodos más largos, lo que resulta en archivos de revocación más grandes y una mayor actividad de la red.
Sin embargo, crear una PKI segura no requiere cambiar los certificados cada año. Se pueden seguir utilizando certificados de larga duración mientras se planifican eficazmente estos cambios. Al reemplazar y renovar los certificados de dispositivo, puede seleccionar el plazo de validez que mejor se adapte a sus necesidades sin preocuparse por tener que reemplazarlos en el futuro.
Cómo mantener seguras las claves privadas
La vulneración de claves comparte muchos de los mismos factores de seguridad que la validez de un certificado. Los atacantes pueden imitar un dispositivo, descifrar y leer datos, y autenticarse en una red si obtienen una clave privada.
Las claves deben protegerse contra ataques, revocarse y reemplazarse si alguna vez se ven comprometidas si se desea ofrecer autenticación y cifrado reales. Esto significa que colocar las claves en un dispositivo en texto plano, donde se puedan extraer fácilmente, no es recomendable. En su lugar, considere una defensa de hardware como un chip seguro (TPM) o una solución de software como un almacén de claves cifradas, que ofrece una defensa real contra atacantes.
Incluso si cree que sus claves están debidamente protegidas, es crucial contar con un sistema de revocación funcional. Los atacantes podrían estar interesados en encontrar una manera de eludir sus medidas de seguridad si descubren que no hay una forma práctica de detenerlos cuando roban una clave. Una línea de defensa adicional, llamada revocación, sirve para neutralizar y disuadir a los intrusos.
Estas barreras tienen mucho en común. Un sistema de revocación confiable, capaz de gestionar una alta tasa de revocaciones, se vuelve más crucial y costoso si sus claves son fáciles de vulnerar.
Revocación
Dado que la revocación de certificados es un servicio costoso que requiere una conexión a internet activa y alta disponibilidad, varios fabricantes y desarrolladores creen que no pueden ofrecerlo. Sin embargo, no es así. Puede consultar la información de revocación utilizando tecnología estándar de la industria sin necesidad de conectarse a un servidor ni usar internet.
CRL (Listas de revocación de certificados) y OCSP son dos tecnologías ampliamente utilizadas en empresas para verificar la información de revocación (Protocolo de Estado de Certificados en Línea). Una CRL es comparable a una lista negra de números de serie de certificados para quienes no están familiarizados con estos sistemas. Con OCSP, el cliente envía una solicitud a través de internet a un servicio central para conocer el estado de revocación de un certificado específico, de forma similar a llamar a una API. El protocolo de certificados X.509 incluye tanto la CRL como el OCSP.
La opción más sencilla, la CRL, ofrece flexibilidad en situaciones en las que su dispositivo podría no tener una conexión a internet fiable o rápida. Tradicionalmente, la CA emisora firma un archivo CRL a diario, al que el cliente puede acceder en línea. Sin embargo, la CRL puede almacenarse en caché cuando el dispositivo no puede conectarse a internet de forma rápida o habitual.
Las CRL están firmadas y tienen un período de validez, al igual que los certificados. Son fiables porque están firmadas por la CA. No es necesario enviar una CRL directamente desde la CA al dispositivo. En su lugar, se pueden distribuir a través de una red, como una red interna o un servidor centralizado en la nube. Esto ofrece una ventaja sobre una simple lista negra o lista blanca: si un archivo CRL tiene una firma válida, se puede descargar desde cualquier lugar sin preocuparse por su manipulación.
Cuando una CRL caduca, lo cual puede estar programado para semanas o más, se puede almacenar en caché en un dispositivo y usarla hasta entonces. Por ello, es una opción ideal para dispositivos con conexiones a internet inestables o erráticas. Esto permite conservar las ventajas de la comprobación de revocación en muchas situaciones sin incurrir en los gastos técnicos que supone obtener nuevos datos repetidamente.
Siempre que los dispositivos tengan acceso a una puerta de enlace o servidor con acceso a internet, OCSP también puede utilizarse cuando los dispositivos no tienen conexión a internet. La información de revocación puede transmitirse durante el protocolo de enlace TLS gracias a una función opcional de OCSP llamada "grapado", que mejora el rendimiento de la red. Se pueden implementar tanto OCSP como listas de revocación de certificados (CRL), utilizando la CRL más reciente como respaldo.
El hecho de que una CA comercial ya admita uno de estos enfoques estándar es una ventaja de emplearlo. Son estándares flexibles que pueden personalizarse para satisfacer sus necesidades específicas, ya que admiten una amplia gama de posibilidades.
Conclusión
Todas estas precauciones se utilizan para reducir y gestionar el riesgo. Es menos probable que los atacantes ataquen claves bien protegidas o aquellas que se pueden revocar y reemplazar fácilmente.
Sus decisiones sobre la política de certificados y el diseño de PKI están relacionadas. Imagine una situación en la que el sistema de revocación es muy rápido, pero las claves privadas se almacenan en texto plano en el dispositivo. Sería fácil comprometer estas claves y tendría que revocar sus certificaciones en cuanto emitiera nuevas. Por otro lado, si sus claves privadas están bien protegidas, pero no hay una forma efectiva de indicar que una clave ha sido pirateada, su sistema también será vulnerable.
Una base de seguridad sólida para sus dispositivos y su red se crea mediante la creación de un sólido PKI que tenga en cuenta los requisitos técnicos de su producto. Seleccionar las políticas más laxas ahora podría generar dificultades de ingeniería más adelante.
