Firmas digitales de documentos XML, PDF y Office en cada plataforma

2

Estoy intentando desarrollar un sitio web que realice firmas digitales en el lado del cliente y luego envié el documento firmado al lado del servidor. Quiero hacer las firmas en el cliente, debido al hecho de no enviar la clave privada del usuario. Esta clave (en teoría) debe estar siempre con el usuario y no debe enviarse a la web (incluso si está protegida con SSL, por ejemplo).

Quiero que todas las plataformas puedan firmar los documentos. Ya he desarrollado un Java Applet con los algoritmos de firma, pero Java no es compatible con iOS o Android. En .NET también es imposible. Así que creo que estoy restringido a JavaScript, pero no conozco ninguna biblioteca javascript que firme documentos XML, PDF y Office. ¿Qué debo hacer? Solo con Javascript todas las plataformas funcionan ..

    
pregunta user3411342 12.03.2014 - 17:15
fuente

2 respuestas

2

Divulgación: trabajo para CoSign .

Está planteando la pregunta común de la firma digital de datos en el "borde" de la red.

Buena suerte con la idea de firmar en el cliente / borde, por las razones que discute. Y olvídese de Javascript, es completamente inseguro desde el punto de vista de la criptografía .

Tienes razón en que la clave privada de los firmantes no debe enviarse a ninguna parte.

Buenas noticias: hay una arquitectura alternativa que:

  • No es necesario que las claves privadas se envíen a ningún lado
  • Proteger las claves privadas
  • Habilite la firma de clientes de todo tipo, incluidos dispositivos móviles, Android, .Net, iOS, etc.
  • Disminuya los costos administrativos al centralizar las claves y la administración de claves

La respuesta: utilizar un dispositivo de firma centralizado. El dispositivo se ha endurecido en el nivel de hardware: si intenta abrir la caja, las llaves se destruyen. Los aparatos de firma están hechos por mi empresa y algunos otros.

En este sistema, el documento (o, simplemente, su hash) se envía desde el dispositivo de borde al dispositivo de firma centralizado. El usuario también se autentica con el dispositivo (utilizando cualquiera de varias técnicas). El aparato contiene las claves privadas. Firma el hash y devuelve la firma digital al cliente de borde.

Dependiendo de las capacidades del cliente, puede:

Ensamble el documento firmado en sí mismo (combinando la firma digital con el documento de origen). Beneficio: se deben enviar menos datos entre el cliente perimetral y el dispositivo de firma. Problema: requiere más sw en el cliente. O:

El dispositivo puede devolver el documento firmado completo. Beneficie una implementación más simple en el cliente, pero requiere que el documento se envíe al dispositivo de firma desde el cliente perimetral.

Tenga en cuenta que no es necesario devolver un documento PDF completo: la firma digital PDF se adjunta simplemente al documento de origen. Entonces el flujo puede ser:

  1. Envíe el PDF completo para firmar. (O simplemente envíe el hash si el cliente puede calcularlo).
  2. Reciba nuevamente el PDF completo (firmado), o simplemente una "cola" que, cuando se adjunta al PDF de origen, crea el documento firmado.

Varios tipos de datos Mi empresa admite la firma de PDF, Word, Excel, XML y otros tipos de documentos listos para usar. Por ejemplo, los documentos de Word se firman utilizando el "estándar" de Word: un receptor (verificador) puede verificar un documento de Word firmado digitalmente sin instalar ningún elemento más allá de Word. No hay complementos, etc.

Autenticación de firmante Los firmantes deben autenticarse con el dispositivo centralizado. Mi empresa admite varios tipos de autenticación, incluyendo OTP y 2FA.

    
respondido por el Larry K 13.03.2014 - 07:20
fuente
0

Para los requisitos de seguridad de bajo a moderado, la delegación es más económica y existen muchas soluciones para los servicios de firma, como el dispositivo mencionado en la respuesta anterior. Sin embargo, independientemente de la confiabilidad que proporcione el servicio de firmas, siempre se basará en la capacidad del cliente para autenticar el servicio. Al utilizar el cifrado PKI + suministrado por el proveedor predeterminado, no hay defensa contra un ataque dirigido.

Java podría ser una opción razonable para las firmas del lado del cliente, excepto iOS. No como un applet de Java, sino como una aplicación de Java, algo así como portablesigner (sourceforge). En principio, debería ser posible derivar una aplicación de Android de un proyecto de este tipo. iOS necesitará una aplicación obj-C separada. Teniendo en cuenta que debe administrar las claves de cliente de todos modos, la instalación de Java parece ser un problema menor.

Los navegadores tendrán acceso a la Web Crypto API desde Javascript, y podría valer la pena verlo una vez que el W3C vaya a lanzarlo. Si se encuentra un método para arrancar el código Javascript de una manera segura, puede ser una firma útil del lado del cliente.

    
respondido por el rhoerbe 15.03.2014 - 10:14
fuente

Lea otras preguntas en las etiquetas