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?