Mi complemento MS Word genera una vista previa en PDF del archivo DOCX en la PC cliente y carga ambos archivos al servidor. No puedo generar PDF en el servidor.
¿Hay alguna forma de asegurarse de que el PDF sea la versión impresa creada por el complemento desde el DOCX real? Necesito asegurarme de que el usuario malintencionado del complemento no puede enviar el DOCX con el PDF modificado, ya que el DOCX se usa como datos para la producción y el PDF se usa como vista previa para su aprobación.
Me gustaría reformular tu pregunta de la siguiente manera:
"¿Hay una manera de asegurarse, de forma criptográfica, de que dos vistas diferentes de algunos datos estén, en efecto, relacionadas con la misma información?"
Vería dos enfoques para ese problema. El primero comienza con los datos, el segundo, con la vista final.
Data-centric
Para implementar esto, debe comenzar con un conjunto común de datos y describir algún tipo de regla de dos vías que generará sus vistas finales. Puede ser una transformación XML, algún tipo de descripción de formulario o cualquier cosa que desee, siempre que toda la información importante de los datos de origen se pueda identificar de manera segura en la vista final.
Por ejemplo, si sus datos representan facturas, el elemento importante puede ser la cantidad, la moneda, el número de cuenta del cliente, el código impositivo, el número de factura, la fecha de la factura, etc. Luego, puede transformar estos datos en un documento (Word, PDF, XML, etc.) y podrá extraer esos datos del documento de salida.
En este caso, debe generar una vista separada de su documento que contenga toda esta información comercial importante (generalmente, un documento XML) y transformar el diseño de todos sus otros tipos de documentos que generarán el mismo formato (para que pueda extraerlos). los datos comerciales importantes de cada tipo de documento).
Luego lo firma digitalmente (ya sea con la identidad del emisor o con la identidad de la aplicación que genera los datos, dependiendo de cómo esté diseñado su sistema de confianza). Esa firma digital podría ocurrir en el servidor cuando se extraen / transforman los datos, lo que significa que puede utilizar una clave de aplicación.
Cuando se valida un documento, una aplicación puede usar las transformaciones para obtener una vista sintética de los datos comerciales y usar la firma digital para verificar la autenticidad del documento.
Si el diseño se realiza correctamente, puede validar los documentos de manera segura, incluso si se han modificado de manera no importante.
La desventaja de este enfoque es que no siempre es fácil transformar todos los tipos de documentos en una vista sintética. Otro inconveniente es que esto no funciona para datos que no se ajustan a un modelo normal. Por ejemplo, si desea manejar datos puramente genéricos (letras, imágenes, etc.), este enfoque probablemente fallará.
Document-centric
Este enfoque es bueno para documentos que no pueden transformarse fácilmente en datos.
Debe comenzar con el documento final en la ubicación cuando pueda autenticarlos. En su caso, ese parece ser el PC del usuario final. A continuación, genera un pequeño documento de "descripción" que contiene un hash de cada documento (generalmente como un fragmento de código XML) y cualquier información importante que deba autenticarse y que no esté cubierta por su sistema de firma digital.
A continuación, firma ese archivo de descripción y lo carga en el servidor junto con los otros dos documentos. Su servidor puede verificar la firma en el archivo de descripción y comparar el hash de cada documento con lo que se almacena para autenticarlos. Dado que esa firma solo puede ocurrir cuando los dos documentos existen, debe aplicarse donde se generan. Y como eso sucede en el sistema cliente, significa que debe usar una clave que pertenezca al usuario, no a la aplicación.
La desventaja de este enfoque es que usted depende fuertemente de lo que suceda en la ubicación cuando aplique la firma. El factor clave aquí es que, en efecto, tiene dos documentos que desea emparejar y no es una forma fácil de asegurarse de que realmente pertenezcan al mismo par: está enviando un documento desde su servidor y esperamos que el cliente esté seguro y le envíe un par válido junto con la firma digital. Esto significa que un cliente podría decidir hacer trampa (firmando dos documentos que no son un par válido) o que algún tipo de malware podría mostrar un par de documentos al usuario y luego firmar otra cosa.
Una manera de (de alguna manera) mitigar ese inconveniente es asegurarse de que tenga una buena trazabilidad: en una etapa posterior, alguien podría mirar ambos documentos y confirmar que son, de hecho, dos vistas de los mismos datos y Asegúrese de que se haga esta revisión; luego, se le da un fuerte incentivo a los usuarios para que no intenten engañar al sistema (porque la firma digital compromete su responsabilidad). Eso te deja con algún tipo de malware en el sistema cliente. Si es o no un riesgo aceptable, depende de usted.
¿Por qué no simplemente hacer que el complemento prepare un hash del pdf y lo publique en algún lugar público donde usted (o cualquier otra persona) pueda verificar posteriormente el hash del pdf provisto por el usuario?
Alternativamente, ¿por qué no hacer que el complemento firme el PDF con una firma digital? Más tarde, puede verificar si la firma en el pdf enviado por el usuario es válida o no.
Esa debería ser una forma segura de decidir si está viendo el documento original preparado por el complemento o una versión modificada por el usuario.
¿Tal vez estoy malinterpretando su caso de uso?
Esto es casi una extensión de la respuesta de Stephanes. (y estoy realmente contento con tu pregunta, estoy teniendo una discusión similar en mi trabajo sobre cómo los técnicos entienden que dos documentos son iguales en comparación con cómo ... hum ... personas normales los perciben ).
Ya que estás tratando con 2 formatos de archivo diferentes, no puedes comparar los archivos con un hash, obviamente serán diferentes.
Por lo tanto, debes concentrarte en el contenido de la información. Veo dos opciones:
Extraiga solo el texto de los documentos, excluyendo cualquier formato, produciendo algún tipo de archivo .txt. Excluya identificaciones, espacios en blanco, etc. Tendrá el contenido de los documentos. Compararlos. Drawback : un solo espacio en blanco adicional, o incluso un orden diferente en los datos extraídos de una tabla, ensuciará este esquema. Y eliminar el formato también puede presentar algunos riesgos de seguridad: si el documento .docx contiene una palabra "no" en blanco y el .pdf lo contiene en negro, solo será visible en un documento y no en el otro. Cualquiera que lea un documento entenderá una cosa del archivo .docx y otra del archivo .pdf, y este método falla.
No puede generar un .pdf en el servidor, pero ¿puede generar algo más en el servidor? Puedes transformar el .pdf en alguna imagen (.bmp o .jpg) y hacer lo mismo con el .docx (sí, es posible; no, no lo intenté para ver cómo se ve). Luego puede comparar la diferencia entre las dos imágenes, porque estará comparando lo que la persona ve cuando tiene el documento en sus manos. Y puedes establecer límites tolerables sobre eso. Por ejemplo, los puntos pequeños dispersos no indican que los documentos sean diferentes, y los descartaríamos como ruido de fondo si se imprimieran en papel; las diferencias contiguas provocan algunas cejas, ya que pueden ser letras y números diferentes.
Lea otras preguntas en las etiquetas hash encryption certificates non-repudiation