Entiendo PKI razonablemente bien desde un punto de vista conceptual, es decir, claves privadas / claves públicas, las matemáticas detrás de ellas, el uso de hash y cifrado para firmar un certificado, la firma digital de transacciones o documentos, etc. También he trabajado en proyectos donde openssl Las bibliotecas C se utilizaron con certs para asegurar la comunicación y la autenticación. También estoy extremadamente familiarizado con las herramientas de línea de comandos de openssl.
Sin embargo, tengo muy poca experiencia con proyectos habilitados para PKI basados en web y, por lo tanto, estoy tratando de diseñar y codificar un proyecto personal para comprenderlo mejor.
Los requisitos
Este es el sitio web de un banco. Todos los usuarios de la Banca por Internet pueden usar cualquier certificado emitido por algunas CA conocidas (verisign, Thawte, confían, etc.). El Banco no es responsable de obtener certificados para el usuario. Estos certificados se utilizarán para la autenticación en el sitio web del banco. Las plataformas / SO, etc., aún no están reparadas.
Diseño
Me preguntaba cuál es la mejor manera de hacer la autenticación.
Vi que Apache tiene una forma de habilitar ssl de 2 vías; en este caso, creo que navegar al sitio web solicitaría automáticamente un certificado al usuario. Pero no estoy seguro de si esto es suficiente porque parece que todo lo que verifica es si un certificado está firmado por una CA confiable y también puede ser si está en una lista blanca de líneas de asunto de los certificados, etc. Pero esto no es suficiente para un caso bancario porque necesita poder asociar un ID de usuario bancario con un certificado.
IIS parece tener una manera por la cual puedo tener un certificado almacenado para cada usuario en Active Directory. Esto es lo que entendí al leer algunos artículos de MSDN. Active el SSL de 2 vías en IIS y luego, cuando el usuario intente navegar al sitio web, IIS enviará una solicitud al navegador con una lista de CA aprobadas y el navegador permitirá que el usuario elija un certificado apropiado de su almacén de certificados y lo envíe para backend. Supongo que IIS hará 2 cosas
- Asegúrese de que el usuario tenga la clave privada correspondiente al certificado (según las negociaciones de la cubierta)
- Según el mapeo AD User-Cert, IIS informará el nombre de usuario a la aplicación.
Realice la autenticación explícitamente llamando a funciones criptográficas en lugar de depender del servidor web que lo haga.
- Muestre una pantalla de usuario donde carga un certificado y la aplicación garantiza que el usuario tenga la clave privada correspondiente al certificado (pidiéndole al front-end que firme alguna cadena usando el certificado).
- La aplicación tiene una base de datos que almacena algunos datos, lo que permite que cada usuario se asigne a su ID de usuario. Esto podría ser
- el certificado completo correspondiente a cada ID de usuario
- La CA y el número de serie del certificado correspondiente a cada ID de usuario.
Me preguntaba cuál es el método comúnmente utilizado? ¿Cuáles son las mejores prácticas? Si debo ir con el # 3, ¿cuáles son las mejores formas de hacer esto?
Algo que también puede funcionar fácilmente con aplicaciones de teléfonos inteligentes será una ventaja adicional.
Actualizar
Permítanme aclarar mi afirmación "codifique la parte de autenticación yo mismo" porque algunas de las respuestas parecen indicar que se ha entendido mal, lo que es malo por no ser claro.
Esto no significa que yo mismo escriba cosas criptográficas. Simplemente significa que en realidad llamaré explícitamente a las rutinas criptográficas en lugar de depender de IIS o cualquier otro servidor web lo hará implícitamente.
fuente
Respuestas:
Si bien realmente quería responder tema por tema, creo que abordaré este tema por tema:
Autorización / Autenticación
OK, lo primero es lo primero. Para su ejemplo, necesita ambos:
En cuanto a la autorización, tiene el problema de descubrir el proceso mediante el cual conecta el DN del sujeto de su usuario a su cuenta bancaria. Dada la gravedad de la transacción, definitivamente desea tener un proceso sólido para esto, y no hay una única forma correcta aquí. Tendría que consultar con el banco, y probablemente con abogados, para averiguar cómo hacer esto de acuerdo con la política.
SSL, autenticación de cliente / servidor, prueba de clave privada
El protocolo SSL siempre incluye la autenticación del servidor, con una configuración opcional adicional para la autorización del lado del cliente. Tiene razón con el n. ° 1 en que Apache ofrece una configuración que agrega la autenticación de cliente por PKI, y puede aprovisionarlo con una lista de CA de confianza. Durante la configuración de una sesión SSL que requiere autenticación de cliente a través de PKI, obtendrá una prueba de clave privada.
Tanto la opción n. ° 1 como la opción n. ° 2 proporcionarán esto: tanto Apache como IIS se pueden configurar de esta manera. En cuanto a las mejores prácticas, tomaría cualquiera de ellos para lanzar su propia solución. # 3 se acerca peligrosamente a la regla de "no escriba su propia criptografía". Suponiendo que puede vincular su transacción a la presencia de una sesión SSL autenticada, no hay razón para transferir la suya.
Además, ya sea en la opción n. ° 1 o en la opción n. ° 2, hay una manera de tener en sus manos el certificado completo y, desde allí, cualquier parte del certificado. Normalmente, el DN del sujeto y / o el número de serie del certificado se utilizan para determinar la identidad del usuario con fines de autorización.
En términos de "uso común", todos los principales servidores web son bastante comunes. IIS, Apache, Tomcat y muchos otros se pueden configurar con autenticación de cliente SSL. La decisión a partir de ahí se basa en gran medida en la implementación general. Los principales servidores web han tenido formas de obtener acceso al certificado proporcionado en la sesión SSL, que es lo que necesita para una verificación más detallada.
Complementos de verificación de certificados
Como mínimo, deberá:
Dadas las altas apuestas de la banca, es posible que también desee verificar el estado de revocación del certificado: si la clave privada del usuario se pierde o es robada, su certificado debe ser revocado.
IIS puede tener los ganchos para una verificación OCSP o CRL: tiende a ser un tipo de sistema más completo (¡agarrado a la mano!), Pero no lo recuerdo fuera de mi cabeza. Tampoco recuerdo si te obligará a usar productos de Microsoft para esto. Para Apache, es casi seguro que tendrá que codificar o agregar una verificación OCSP / CRL. Creo que tiene ganchos durante el establecimiento de la sesión SSL: por lo general, esta verificación se realiza una vez cuando se configura la sesión SSL.
Autorización
En el n. ° 1 frente al n. ° 2: tiene razón en que IIS tiene algunas funciones integradas que vincularán el certificado proporcionado en la sesión SSL a un repositorio de AD. Es uno de los casos en que Microsoft hace un esfuerzo adicional para facilitar la compra y el uso de más de sus productos. :) Hay matices de cómo IIS se vincula con AD que están más allá del alcance de esta pregunta y más allá de mi recuerdo inmediato. He hecho algunas cosas bastante locas con IIS y AD, y mi opinión general es que mientras haces algo relativamente simple como extraer el nombre de usuario basado en el certificado de un repositorio de AD, probablemente estés bien. Es cuando te encuentras con problemas más complejos de almacenamiento de datos, búsquedas extrañas de AD y cosas particularmente locas (pero legítimas) con PKI, tú '
Con IIS, aún así, necesitará que se agregue algo a su estructura de AD, o en otro lugar, que vincule el nombre de usuario con la cuenta bancaria. Por lo general, en la banca, un usuario tiene varias cuentas. Y 2 usuarios pueden tener una cuenta conjunta, por lo que esta es una relación de muchos a muchos.
Para el n. ° 1, sí, debe escribir su propia búsqueda. Debe codificar: - una base de datos o una jerarquía LDAP que conecte el certificado al usuario y el usuario a las cuentas bancarias del usuario. La parte única garantizada de un certificado es el número de serie + DN del emisor. A menudo, el Asunto DN funcionará, pero no está garantizado en todos los sistemas PKI.
Así es como lo hacen los desarrolladores que usan PKI para la autenticación de gama alta con Apache. Después de haber trabajado en varios de estos sistemas, todavía tengo que encontrar un caso de reutilización de autorización fácil, por lo que nunca lo veo como un gran inconveniente: voy a tener que tener algo especializado de cualquier manera, ya que los roles / privilegios son nunca fácil.
Esto suena como una combinación de # 1 y # 3, mi mejor consejo sería: use las capacidades nativas de cualquier aplicación / servidor web que use para generar la sesión SSL. Eso permitirá que la configuración del navegador al servidor con la consulta de certificado se realice de la manera estándar, la mejor práctica. A partir de ahí, con Apache, necesitará rodar su propio sistema de autorización. IIS proporcionará la idea de Microsoft de cómo debería funcionar esto para usted.
Gotchas conocidas
Haz un montón de pruebas de navegador. De año en año, de navegador en navegador, encuentro problemas con el manejo de sesiones SSL. Encadenar correctamente la sesión SSL a la serie de solicitudes de páginas web y asegurarse de que el cierre de sesión se maneje correctamente son las principales áreas de preocupación. Y tiene mucho que ver tanto con el servidor como con el software del navegador. SSL es lo suficientemente estable que cuando funciona, generalmente funciona, aunque puede haber problemas de IE frente a todos los demás.
En particular, la última vez que hice esto, la cuestión de la codificación forzada y el tiempo de espera de la sesión fue un gran problema.
Teléfonos inteligentes
Bueno. Suerte. es sobre todo lo que puedo decir No soy en absoluto un desarrollador de aplicaciones móviles, pero mi impresión hasta el momento es que en el teléfono inteligente promedio, el manejo del certificado PKI es inferior o inexistente.
Me encantaría que me demuestren lo contrario.
fuente
Los certificados personales funcionan bien para la renovación periódica de los certificados (que tiene un proceso bastante sólido detrás de ellos) y se pueden implementar como una autenticación "sin contraseña" que a los clientes les gusta
pero donde falla es
Tenga en cuenta que los certificados personales modernos con firma sha-2 no funcionan con Safari en iPad y muchos navegadores modernos. Esto se debe a que los certificados personales nunca despegaron realmente como pensaban las organizaciones de la autoridad de certificación. La emisión de 30,000 certificados (lo que hacemos) cuesta aproximadamente lo mismo por certificado que algunos tipos de token de hardware.
Su estrategia para permitir que los clientes encuentren sus propios certificados no es realmente válida. Hoy en día es difícil encontrar proveedores de certificados personales y son bastante caros: debe asegurarse de que el caso de negocios funcione; de lo contrario, los clientes simplemente no aceptarán esto.
fuente
Bien, están pasando muchas cosas aquí. Lo primero es lo primero, la autenticación del certificado del cliente es inútil si no es compatible con el punto final. Por lo tanto, tenemos una excelente publicación de Intrepidus que cubre los conceptos básicos de autenticación de clientes para aplicaciones de teléfonos inteligentes .
A continuación, permítame sugerirle que no codifique su propia rutina de autenticación. Hay muchas bibliotecas revisadas que manejan esto. Se ahorrará funcionalidad y errores de seguridad al ejecutar con una biblioteca madura para autenticación. Usar una biblioteca madura y examinada para esto definitivamente sería la mejor práctica.
La siguiente mejor práctica es usar un directorio para manejar a su cliente: la asignación de certificados. Entonces estará viendo AD o LDAP. Como mencionó, Windows e IIS hacen que esto sea bastante perfecto para usted. IIS.net tiene un buen resumen sobre la configuración de la asignación de certificados bajo IIS .
Si usa Apache, esto no es tan fácil de usar. Parece que mod_authz_ldap hace el mapeo del certificado del cliente, pero no he trabajado personalmente con él.
Eso nos lleva a la logística de implementar realmente algo como esto. No está firmando los certificados de los usuarios, por lo que necesita un proceso férreo para que un usuario envíe su certificado y haga que su aplicación lo publique en el directorio. Me gustaría ver dos factores para esto, con una autenticación de contraseña y un mensaje de texto o una llamada a un número confiable. Le enviaría un correo electrónico al usuario para informarle que se agregó un certificado a su cuenta. Permitiría que un usuario elimine la asignación de certificado de usuario a través de la página de administración de su cuenta en la aplicación.
Vería lo que hacen Google y Facebook para configurar cookies para dispositivos confiables para evitar dos factores. Tendría la autenticación de dispositivos nuevos con dos factores antes de permitir la autenticación solo con certificado.
También pensaría en cómo manejar los certificados de usuario que se revocan. Esto significa verificar una lista externa de revocación de certificados (CRL). ¿Qué hacer si un certificado de cliente no tiene un punto de distribución CRL definido? ¿Comprueba la CRL cada vez que el usuario inicia sesión o de forma programada como parte de un trabajo, ya que es probable que solo haya un puñado de CRL en uso?
Realmente, esto se reduce a: cómo sé que puedo confiar en que los certificados de los usuarios no se han visto comprometidos, y cómo puedo confiar en que puedo asignar el certificado X al usuario Y.
fuente