# How does DSA provide non-repudiation in proving a document was properly displayed (not altered or displayed incorrectly)?

I am building an iOS app that allows the user to sign a document served to them by a web server. So that page of the app simply has a document in the top pane, and at the bottom pane, a place to sign with your finger.

So, I want to use DSA to allow this app to sign that doc and have the non-repudiation property. But a colleague brought up what seems to be a critical flaw.

If I send the iOS app a document, the user can still cryptographically sign it (with the signature bitmap and timestamp) using their private key, but we might actually be displaying some other document. In a sense, the crypto doesn't actually provide any assurance that the signer was looking at the document in question when he signed -- he could have been looking at a picture of Mickey Mouse. It just proves that we had that document in RAM, and that the user signed something.

So clearly it's easy to tell using DSA if someone mistakenly sent you a digitally signed picture of Mickey Mouse instead of a contract. But what if the problem was at the view/display layer, and in point of fact, the correct document was in RAM, and just displayed incorrectly? (For example, say I had some horrid bug that would randomly replace pixels on the screen with pictures of Mickey Mouse at the OS layer?) Then, we would send a seemingly valid signature of the seemingly appropriate contract, while the user in reality had been looking at Mickey.

I'm trying to get my head around how the crypto solves this problem. I'm sure it's something trivial but I'm having so much trouble figuring it out. Any thoughts would be very much appreciated. If this is one of those "nature of the beast" type trust questions, how does Adobe's implementation in PDF provide non-repudiation?

• – user991
Sep 23 '15 at 1:09
• Why would you write your app to show a picture of Mickey Mouse when it should be showing the correct document? You are writing the app. If you don't trust the app to do what you think it is doing, you have written it poorly. Sep 23 '15 at 1:39
• (1/2) @RickyDemer I hadn't ever heard of that before. Sounds very interesting. I'm not sure it applies in this case. The way I read it WYSIWYS, it is to prevent someone from using a trick like this where they append a rar file on the end of a jpg. The user sees the jpg file, signs it and sends over the signature and the file. The other party now renames the extension to .rar, and when un-rared, has a text file that says "I give all my earthly belongings to mikeazo". Sep 23 '15 at 1:49
• (2/2) The semantic meaning of the file has changed from signing to verification. What I understand from what @Jason is saying, he is worried about a bug in his software that, instead of displaying a legal contract to the user, who can then sign it, it has been hacked to show a picture of Mickey Mouse. Then when the user clicks "sign" and (presumably) enters their PIN to unlock the private key to do the signature operation. The hacked software uses access to the private key to sign the contract instead of the Mickey Mouse picture that the user saw. Sep 23 '15 at 1:52
• @mikeazo : $\:$ researchgate.net/publication/… $\;\;\;\;$
– user991
Sep 23 '15 at 2:01

I'm trying to get my head around how the crypto solves this problem.

It doesn't. You need to trust the platform you use to do the signing.

For instance, my bank has replaced the "signature" generation device that I previously used with one that displays the actual transaction, so I don't have to trust the information on the computer screen that much.

• It's pretty cool, it reads a color coded transaction from the screen with a camera and displays the transaction on an LCD. Sep 23 '15 at 1:52

First, there is no way that crypto can keep an attacker from manipulating the data that is shown to the user. to prevent this, you have to trust some part of your hardware, at least the screen that views the data and some chip inside that can do some crypto.

Moreover, digital signatures alone will not solve this problem as the merely capture signing a given bit string. How it is made sure that the user actually intends to sign this bit string is not captured.

The problem is even broader: How do you make sure that the bit string signed is viewed the same way at the verifiers side? Many file formats allow for dynamic content, i.e. you can program a pdf to show something on one day and something else on another day... XML files might be viewed differently depending on the viewer, e.g. a viewer might omit data in some tags, etc.pp. There is a never ending list of these issues.

For that reason, laws for legally binding signatures formulate a bunch of requirements on the hardware and software, used to sign and verify such signatures. If you want to get an overview on these requirements, a good starting point would be https://en.wikipedia.org/wiki/Digital_signatures_and_law.

If you want to dive deeper into the topic, search for "What You See is What you Sign".

In any way, you will not solve this issue on an "open" platform like the iPhone...