Il mio componente aggiuntivo MS Word genera l'anteprima PDF del file DOCX sul PC client e carica entrambi i file sul server. Non riesco a generare PDF sul server.
C'è un modo per assicurarsi che il PDF sia la versione stampata creata dal plugin dal DOCX vero e proprio? Devo assicurare che l'utente malintenzionato del plug-in non può inviare DOCX con PDF modificato poiché il DOCX viene utilizzato come dati per la produzione e il PDF viene utilizzato come anteprima per l'approvazione.
Mi piacerebbe riformulare la tua domanda in questo modo:
"C'è un modo per essere sicuro, in modo crittografico, che due diverse visualizzazioni di alcuni dati abbiano in effetti le stesse informazioni?"
Vedrei due approcci a questo problema. Il primo inizia con i dati, il secondo, con la vista finale.
Data-centric
Per implementare questo, è necessario iniziare con un insieme comune di dati e descrivere un tipo di regola a due vie che genererà le tue viste finali. Può trattarsi di una trasformazione XML, di un tipo di descrizione del modulo o di qualcosa che ti piace finché tutte le informazioni importanti dai dati di origine possono essere identificate in modo sicuro nella vista finale.
Ad esempio, se i tuoi dati rappresentano fatture, l'elemento importante potrebbe essere importo, valuta, numero di conto cliente, codice fiscale, numero di fattura, data fattura, ecc. Potresti quindi trasformare questi dati in un documento (parola, PDF, XML, ecc.) E sarai in grado di estrarre i dati dal documento di output.
In questo caso, dovresti generare una vista separata del tuo documento che contenga tutte queste importanti informazioni commerciali (tipicamente, un documento XML) e le trasformazioni di progetto per tutti gli altri tuoi tipi di documento che produrranno lo stesso formato (in modo da poter estrarre i dati aziendali importanti di ciascun tipo di documento).
Quindi firma digitalmente questo (o con l'identità dell'emettitore o con l'identità dell'applicazione che genera i dati, a seconda di come è progettato il tuo sistema di fiducia). Quella firma digitale potrebbe accadere sul server quando i dati vengono estratti / trasformati, il che significa che è possibile utilizzare una chiave dell'applicazione.
Quando si convalida un documento, un'applicazione può quindi utilizzare le trasformazioni per ottenere una visione sintetica dei dati aziendali e utilizzare la firma digitale per verificare l'autenticità del documento.
Se il design è eseguito correttamente, puoi convalidare i documenti in sicurezza anche se sono stati modificati in modi non importanti.
Lo svantaggio di questo approccio è che non è sempre facile trasformare tutti i tipi di documento nella vista sintetica. Un altro svantaggio è che questo non funziona per i dati che non sono conformi a un modello normale. Ad esempio, se vuoi gestire dati puramente generici (lettere, immagini, ecc.) Questo approccio probabilmente fallirebbe.
documento-centrica
Questo approccio è utile per documenti che non possono essere facilmente trasformati in dati.
È necessario iniziare con il documento finale nel luogo in cui è possibile autenticarli. nel tuo caso, sembra essere il PC dell'utente finale. Quindi generi un piccolo documento di "descrizione" che contiene un hash di ciascun documento (in genere uno snippet XML) e tutti i dati importanti che devono essere autenticati e che non sono già coperti dal sistema di firma digitale.
Quindi firma il file di descrizione e lo carica sul server accanto agli altri due documenti. Il server può quindi verificare la firma sul file di descrizione e confrontare l'hash di ciascun documento con ciò che è memorizzato per poterli autenticare. Poiché tale firma può avvenire solo quando esiste il documento, deve essere applicata dove vengono generati. E poiché ciò accade sul sistema client, significa che dovresti usare una chiave che appartiene all'utente, non all'applicazione.
Il lato negativo di questo approccio è che dipendi strongmente da ciò che accade nel luogo in cui si applica la firma. Il fattore chiave qui è che in effetti hai due documenti da accoppiare e non un modo semplice per assicurarti che veramente appartengano alla stessa coppia: stai inviando un documento dal tuo server e speriamo che il cliente sia sicuro e ti rispedisca una coppia valida insieme alla firma digitale. Significa che un cliente potrebbe decidere di imbrogliare (firmando due documenti che non sono una coppia valida) o che qualche forma di malware potrebbe mostrare una coppia di documenti all'utente e quindi firmare qualcos'altro.
Un modo per (in qualche modo) mitigare quello svantaggio è quello di assicurarsi di avere una buona tracciabilità: se in una fase successiva, qualcuno potrebbe guardare entrambi i documenti e confermare che sono, in effetti, due viste degli stessi dati e fare sicuro che questo riesame è fatto, quindi si pone un strong incentivo per gli utenti a non tentare di imbrogliare il sistema (perché la firma digitale si impegna nelle loro responsabilità). Questo ti lascia una qualche forma di malware sul sistema client. se questo è un rischio accettabile dipende da te.
Perché non fare semplicemente il plugin per preparare un hash del pdf e postarlo in qualche luogo pubblico dove tu (o chiunque altro) puoi successivamente verificare l'hash del pdf fornito dall'utente?
In alternativa, perché non ottenere il plug-in per firmare il PDF con una firma digitale? In seguito è possibile verificare se la firma sul pdf inviato dall'utente è valida o meno.
Questo dovrebbe essere un modo sicuro per decidere se stai vedendo il documento pristine preparato dal plugin o una versione modificata dall'utente.
Forse sto fraintendendo il tuo caso d'uso?
Questa è quasi un'estensione della risposta di Stephanes. (e sono davvero contento della tua domanda, sto avendo una discussione simile sul mio lavoro su come i tecnici comprendano che due documenti sono uguali rispetto a come ... hum ... le persone normali li percepiscono ).
Dato che hai a che fare con 2 diversi formati di file, non puoi confrontare i file con un hash, ovviamente saranno diversi.
Quindi devi concentrarti sul contenuto delle informazioni. Vedo due opzioni:
Estrai solo il testo dai documenti, escludendo qualsiasi formato, producendo qualche tipo di file .txt. Escludi identità, spazi bianchi, ecc. Avrai solo il contenuto dei documenti. Confrontali. Ritocco : un singolo spazio bianco extra, o anche un ordine diverso nei dati estratti da una tabella, pasticcia questo schema. Inoltre, la rimozione della formattazione può comportare alcuni rischi per la sicurezza: se il documento .docx contiene una parola "not" in bianco e il file .pdf lo contiene in nero, sarà visibile solo in un documento e non nell'altro. Chiunque legga un documento capirà una cosa dal .docx e un'altra dal .pdf, e questo metodo fallisce.
Non puoi generare un file .pdf sul server, ma puoi generare qualcos'altro sul server? Potresti trasformare il .pdf in qualche immagine (.bmp o .jpg) e fare lo stesso con il .docx (sì, è possibile; no, non l'ho provato per vedere come appare). Quindi puoi confrontare il diff tra le due immagini, perché dovrai confrontare ciò che la persona vede mentre ha il documento nelle sue mani. E puoi impostare limiti tollerabili a riguardo. Ad esempio, i piccoli punti sparsi non indicano che i documenti sono diversi e lo elimineremmo come rumore di fondo se stampati su carta; differenze contigue sollevano alcune sopracciglia, in quanto potrebbero essere diverse lettere e numeri.
Leggi altre domande sui tag encryption hash certificates non-repudiation