3

My MS Word Add-In generates PDF preview of DOCX file on client PC and uploads both files to server. I cannot generate PDF on server.

Is there any way to make sure that the PDF is the printed version created by the plugin from the actual DOCX? I need to assure that malicious user of the plugin cannot send the DOCX with modified PDF since the DOCX is used as data for production and the PDF is used as preview for approval.

2

I'd like to to rephrase your question as this:

"Is there a way to make sure, in a cryptographic way, that two different views of some data are, in effect, related the same information ?"

I would see two approaches to that problem. The first one starts with the data, the second one, with the final view.

Data-centric

In order to implement this, you need to start with a common set of data and describe some type of two way rule that will generate your final views. That can be an XML transform, some type of form description or anything you fancy as long as all important information from the source data can be safely identified in the final view.

For instance, if your data represent invoices, the important element might be amount, currency, client account number, tax code, invoice number, invoice date, etc. You could then transform this data into a document (word, PDF, XML, etc) and you be able to extract that data back from the output document.

In this case, you should generate a separate view of your document that contains all this important business information (typically, an XML document) and design transforms for all your other document types that will output the same format (so you could extract the important business data from each document type).

You then digitally sign that (either with the identity of the emitter or with the identity of the application generating the data, depending on how your trust system is designed). That digital signature could happen on the server when the data is extracted/transformed which means that you can use an application key.

When validation a document, an application can then use the transforms to get a synthetic view of the business data and use the digital signature to verify the authenticity of the document.

If the design is done correctly, you could then safely validate documents even if they have been altered in non-important ways.

The downside of that approach is that it isn't always easy to transform all types of document into the synthetic view. Another downside is that this doesn't work for data that doesn't conform to a normal model. For instance, if you want to handle purely generic data (letters, pictures, etc.) then this approach would probably fail.

Document-centric

This approach is good for document that can't easily be transformed into data.

You need to start with the final document at the location when you can authenticate them. in your case, that seems to be the end user PC. You then generate a small "description" document that contains a hash of each document (typically as an XML snippet) and any important data that should be authenticated and that isn't already covered by your digital signature system.

You then sign that description file and upload it on the server alongside the two other documents. Your server can then verify the signature on the description file and compare the hash of each document with what is stored in order to authenticate them. Since that signature can only happen when the two document exists, it should be applied where they are generated. And since that happen on the client system, it means you should use a key that belongs to the user, not the application.

The downside of that approach is that you depend strongly on what happen on the location when you apply the signature. The key factor here is that you have, in effect, two documents that you want to pair and no easy way to make sure they really belong to the same pair: you're sending one document from your server and are hoping that the client will be secure and send you back a valid pair along with the digital signature. It means that a client could decide to cheat (by signing two documents that aren't a valid pair) or that some form of malware could display one document pair to the user and then sign something else.

One way to (somewhat) mitigate that downside is to make sure you have good traceability: if at a later stage, someone could look at both document and confirm that they are, in fact, two view of the same data and make sure this reviewed is done, you then place a strong incentive on users not to attempt to cheat the system (because the digital signature engage their responsibility). That leaves you with some form of malware on the client system. whether or not that is an acceptable risk is up to you.

0

Why not simply make the plugin prepare a hash of the pdf and post it to some public location where you (or anyone else) can later verify the hash of the pdf provided by the user?

Alternatively, why not get the plugin to sign the PDF with a digital signature? You can later verify whether or not the signature on the pdf sent by the user is valid or not.

That ought to be a sure shot way of deciding if you are seeing the pristine document prepared by the plugin or a user modified version.

Maybe I am misunderstanding your use case?

0

This is almost one extension to Stephanes answer. (and I'm really glad about your question, I'm having a similar discussion at my work about how techies understand that two documents are equal versus how... hum... normal people perceive them).

Since you're dealing with 2 different file formats, you can't compare the files with a hash, obviously they'll be different.

So you have to focus on the information content. I see two options:

  1. Extract just the text from the documents, excluding any formatation, producing some kind of .txt file. Exclude identation, white spaces, etc. You'll have just the content of the documents. Compare them. Drawback: a single extra white space, or even a different order in the data extracted from a table, will mess this scheme. And removing formatting also can present some security risk: if the .docx document contains a word "not" in white and the .pdf contains it in black, it will only be visible in one document and not in the other. Anyone reading one document will understand one thing from the .docx and another from the .pdf, and this method fails.

  2. You can't generate a .pdf on the server, but can you generate something else on the server? You could transform the .pdf in some image (.bmp, or .jpg) and do the same to the .docx (yes, it's possible; no, I didn't try it to see how it looks). Then you can compare the diff from the two images, because you'll be comparing what the person sees as he has the document in his hands. And you can set tolerable limits about that. For example, sparse small dots don't indicate that the documents are different, and we would discard it as background noise if printed in paper; contiguous differences raise some eyebrows, as they might be different letters and numbers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.