Posts Tagged ‘Smart card

Why signing XML documents is different ?

Why relying on XML for solving the “what you see is what you sign” problem? Our ideas can be summarized in two points:

  1. If a document to be signed is either not well-formed in the sense of XML, or not valid in the sense of its accompanying schema, or both, than it must strictly be assumed that the document has been manipulated. In consequence, it has to be dropped, and the user has to notified.
  2. A smart card application can extract certain content items for dis-play on the smart card reader¬from a structured and formally described document. The extraction and display operations are fully controlled by the tamper-proof smart card—which is the same environment that generates the digital signature.

The fundamental property of XML documents is wellformedness. Ac-cording to the XML specification every XML processing entity has to check and assert this property. Regarding digital signing wellformedness is important, since it ensures the uniqueness of the XML documents’ interpretation. Wellformedness also ensures the usage of proper Unicode characters and the specification of their encoding. This is also very important regarding digital signatures, since character set manipulation can be used to perform “what you see is what sign” attacks.

Validity is a much more restrictive property of XML documents com-pared to wellformedness. A smart card which checks validity of XML documents with respect to a given schema before signing ensures due to the tamper resistance of the smart card that only certain types of XML documents are signed. Consider for example a smart card which contains your private key, but only signs XML documents which are valid with respect to a purchase order schema. You could give this card to your secretary being sure, that nothing else than purchase order is signed using your signature. Using additional constrains in the schema, e.g. the restriction of the maxi-mum amount to 100 Euro, eliminates the last chance of misusage.

When operated in a class 3 card reader (i.e. a card reader including a dis-play and a keypad) the card can display selected content and request user confirmation. This finally solves the “what you see is what you sign” problem. Obviously, XML processing is not an easy task to perform on resource-constraint SmartCards. The following table therefore summarizes the challenging XML properties and the resulting opportunities for improving the signing process.

Tags : , , , , , , , ,

Checking and Signing XML Documents on Java Smart Cards

Smart card assistance for generating digital signatures is current state of the art and bestpractice. This is mainly due to the fact that smart cards now a days have enough processingpower to produce digital signatures for documents by on card resources (processor and memory)only. This way the owner’s private signing key never has to leave the smart card: The signingkey is and remains permanently stored in a tamper proof environment. A closer look at thesigning process however reveals a still existing major security problem: the problem known asthe “what you see is what you sign” problem. Before signing a document the signer usuallywants to check the document’s syntactic and semantic correctness.

When compared to the traditional process of signing a paper document with a hand writtensignature, the difference can easily be identified: In the traditional case, it is relativelyeasy for the user to assert the correctness, because syntactic and semantic document checkingand signature generation are in immediate context. Digitally signing an electronic documentis completely different, because checking and signature generation are executed in twodifferent environments, exposing fundamentally different characteristics different withrespect to security on the one hand and processor, memory, and display resources on the other hand.

Traditionally, the signing application computes the document’s digest using a one way hashfunction and sends the result to the smart card. The card encrypts the digest by an asymmetriccipher using the signing key stored on the card. The resulting value is the digital signatureof the document. It is sent back to the signing application. The user can neither check thesyntactic correctness of the document (in case of XML documents: well formedness, validity)nor the semantic correctness of the document. What really is signed is beyond the user’scontrol. It might for instance be the digest for a manipulated document. Even if the smartcard can be regarded as tamper proof, the terminal (e.g. a PC) and the programs running onit are vulnerable to viruses and Trojan horses. Such evildoers might obviously also affectsigning applications and let them produce valid signatures for from the user’s perspectiveinvalid documents. Such incidents invalidate the signing process in total.

We propose an enhanced architecture which performs checking and signing of XML documents onJava smart cards, called JXCS architecture. The basic idea of JXCS is to shift the syntacticvalidation and hash value generation from the vulnerable PC to the trusted smart card.Syntactic validation imposes the following challenges and opportunities: Challenging is theneed of processing XML documents on resource constraint Java smart cards. The opportunity ofthe approach is the possibility to perform syntactic and even semantic checks on the XMLdocument in a tamper proof environment which improves the security of the signing process.We propose the need for three major checks on the XML documents to be signed: Wellformedness, validity and content acknowledgement using a class 3 card reader. Taken togetherall three checks can defeat “what you see is what you sign” attacks.

Enhanced by Zemanta

Tags : , , , , , , , , , ,