Applet de Java para autenticación mutua con tarjeta inteligente

3

Necesito desarrollar un applet de Java, para una autenticación mutua entre Tomcat 6 (servidor) y una tarjeta inteligente "IDGo 300" (cliente).

Para hacer esto, pensé en el siguiente esquema:

  1. Tomcat (servidor) envía a SmartCard (cliente) la solicitud de su certificado digital (firmado por CA).

  2. El cliente ingresa el PIN y selecciona un certificado disponible en la tarjeta inteligente, luego el Applet envía su certificado (firmado por CA) a Tomcat. Tomcat verifica el certificado digital y, si es correcto, lo devuelve.

  3. El applet verifica el certificado del servidor y, si el certificado es correcto, envía una confirmación al servidor. El servidor proporciona acceso completo al cliente para utilizar la aplicación web.

Preguntas :

  1. ¿Es este esquema viable?

  2. Me gustaría administrar todo a través de mi applet y cuando el cliente desconecta la tarjeta inteligente, pierde el acceso al servidor.

pregunta xfocus 29.07.2012 - 15:58
fuente

2 respuestas

3

Sí. Esto es factible. Hay una forma estándar de lograr esto: utiliza SSL con un certificado de cliente. Esta función de SSL ya hace exactamente lo que usted desea, y ha sido bien examinada, por lo que le recomiendo que la use.

En este esquema, el certificado de cliente y la clave privada asociada del cliente se almacenan en la tarjeta inteligente. La clave privada nunca abandona la tarjeta inteligente. Para probar la identidad del cliente, el servidor envía un desafío y la tarjeta inteligente la firma (y otras cosas) con la clave privada del cliente. Todo esto es integrado en SSL , por lo que no necesita implementarlo usted mismo, solo le estoy dando una idea de cómo funciona el protocolo.

No se necesita un applet de Java. Todo lo que necesita es que su navegador sea compatible con PKCS # 11. Por ejemplo, Firefox admite esto.

Si, por algún motivo, desea utilizar un applet de Java, nuevamente desea revisar PKCS # 11, las API de criptografía de Java y el proveedor de servicios criptográficos PKCS # 11 de Sun. Consulte también esta pregunta .

    
respondido por el D.W. 31.07.2012 - 08:19
fuente
0

En primer lugar, en mi humilde opinión, las comunicaciones deben realizarse por ssl entre el applet y el servidor.

En segundo lugar, su protocolo debería tener protección de reproducción (solo en caso de que ssl con su negociación DH lo proporcione en cierta medida).

En cuanto al protocolo en sí, después de que el applet recupera el certificado de los usuarios, debe enviar una solicitud de verificación cifrada y autenticada (por el applet) que puede incluir elementos como el ID de sesión, las credenciales de usuario adicionales, etc.). Esta solicitud se debe cifrar con clave pública de los servidores y autenticada con la clave privada de los applets (obtendremos una doble verificación de que el servidor es el único destinatario y ese applet es remitente autenticado ), después de que SERVIDOR SOLO LADO !!!! , el servidor de verificación debe enviar la respuesta al applet nuevamente encriptado con la clave pública del applet y firmado con la clave privada del servidor , por las razones antes mencionadas). Debería ser solo informativo y el servidor debería manejar las decisiones de autenticación, solo deberíamos proporcionar una ruta confiable entre la tarjeta inteligente y el servidor.

En cuanto al punto 2, puede enviar información a través de nuestro nuevo protocolo al servidor que la tarjeta se desconectó y que la sesión autenticada del usuario se debe invalidar.

P.S. En cuanto al applet de autenticación mutua < - > En el servidor, podemos usar alguna renegociación de tiempo DH si le preocupa la extracción de claves privadas.

    
respondido por el damiankolasa 30.07.2012 - 12:56
fuente

Lea otras preguntas en las etiquetas