Validating the iDIN Signature

<< Click to Display Table of Contents >>

Navigation:  Validating electronic signatures >

Validating the iDIN Signature

The PAdES document with an iDIN Signature can be validated in the same manner as a document with an embedded AES. The PDF document is signed by the DISP (Signant) on behalf of the Signatory, and will appear and validate as an ordinary PAdES document in the PDF reader.

 

The visual signature attributes

In the Adobe Reader - Signature Panel, you can inspect the details of each signature in a sequence of signatures.

Please note the Signature Details - Reason, as it contains relevant information on acting parts of the iDIN Signature:

 

iDIN Signed by “Name”: The signatory “Name” signed by means of iDIN signature service

BIN: The personal unique ID provided by the certificate issuer (Bank) for the signatory.

TransactionID: The Transaction ID identifying the SAML assertion.

DocumentID: The SHA256 hash value of the document.

 

View sample screenshot

 

The signature widget

 

validate_idin2

 

 

Signant embed a visible signature widget for each signatory. The signature widget is the only visible modification supported by the PAdES format enabling the document to be recognized as a signed document even if it is printed.

The iDIN signature includes the following information:

Label “iDIN Signing”

Signatory name

Date of signature

 

 

Validating the signature

The SAML assertion is the actual signatory AES part of the iDIN Signature. The assertion is however not suitable for being displayed in the Signature Panel. Instead it is attached in the same PDF document as an embedded file contained in the Document Dictionary entry “Signant.AttachedFiles”.

The SAML assertion will provide the following data structure:

 

Encrypted SAML Attributes

Encrypted symmetric key(s)

Document_ID

 

Issuer Signature

Issuer public key

 

 

To view SAML assertion we need to:

1. Extract the SAML Response from the PDF Document Dictionary section:

Open the signed document in a text editor and locate the key “Signant.AttachedFiles”.

It should look like this

 

2. Convert the content from hexadecimal to Ascii format.

By copying and converting the hexadecimal content (i.e Signant.AttachedFiles <content>) to ASCII  you will find the SAML response XML document, which in turn contains the SAML assertion.

SAML response with the initial part of the SAML assertion (highlighted) 

 

In the SAML response some attributes are encrypted with AES keys which are encrypted with the DISP/Merchant private key. In order to make the validation of SAML response independent of DISP/merchant private key, the decrypted AES keys are also provided in the Signant.AttaachedFiles section in the following json format:

 

AttributeList: [{"Name":"urn:nl:bvn:bankid:1.0:consumer.bin","Value":"NLINGB123456789"},

{"Name":"urn:nl:bvn:bankid:1.0:bankid.deliveredserviceid","Value":"20942"},

{"Name":"urn:nl:bvn:bankid:1.0:consumer.legallastname","Value":"Doe"},

{"Name":"urn:nl:bvn:bankid:1.0:consumer.preferredlastname","Value":"Doe"},

{"Name":"urn:nl:bvn:bankid:1.0:consumer.initials","Value":"J"},

{"Name":"urn:nl:bvn:bankid:1.0:consumer.dateofbirth","Value":"19730102"},

{"Name":"urn:nl:bvn:bankid:1.0:consumer.telephone","Value":"\u002B3120123456789"},{"Name":"urn:nl:bvn:bankid:1.0:consumer.email","Value":"johndoe@currencetest.com"},{"Name":"urn:nl:bvn:bankid:1.0:merchant.documentID","Value":"7A632C2637A66D80775715A551D780BDDD16C0DD643B3D86C15580EC640C7B26"}]

AttributeEncryptionKeyList: [{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.bin","AesKey":"r00TkFZPGiLuf7q6/ewuMy52XN/w6o16I6dIoiV1524="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.legallastname","AesKey":"7HTEf3yRWo4KpS9URXqIpFDGX+1u2rsUbfuPKd8qi88="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.preferredlastname","AesKey":"csVFI2Im7N4jpFW0W47yNLO08jgsJ8N7DRDwHAE2sqU="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.initials","AesKey":"B7rT/h7l++BeVciqyvdl/wq4OPCex2FuW17/zV7lZDo="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.dateofbirth","AesKey":"vFfPDqdLvsfj2iqIj27DIqBqcZ7bWnbpdbI5OfHIZHU="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.telephone","AesKey":"EcF8cjoNUW4xT0K9w7LqPaqNe35OBFKfxwDKdXrFXAE="},{"AttributeName":"urn:nl:bvn:bankid:1.0:consumer.email","AesKey":"3Iz/gPBapUco+SyBCNodc+k4UrZZY1SVkZrcjtGfRwU="}]

 

Among the DecryptedAttributes please note the DocumentID together with the consumer attributes.

 

Validation of the SAML assertion

The SAML is signed by the Validation Service (VS) at the Issuer. The public key of the VS certificate used for signing is included in the X509Certificate element in the X509Data element in the KeyInfo element in the SAML assertion. The public key of the certificate used to sign the SAML assertion can be used to validate the signature made by the concerned VS. The VS in whose name the certificate is issued is a (former) licensee of iDIN.

 

At the time of signing, the VS must use a valid certificate derived from a parent certificate, which is on the EU Trust List (EUTL) or the Adobe Approved Trust List (AATL) and, in the case of the EUTL, which complies with one of the certificate profiles NCP / NCP +, QCP-N, QCP-L, QCP-N-QSCD, QCP-L-QSCD as defined in ETSI 319411-1 / -2.  In this way it is guaranteed that the certificate has actually been issued to the VS concerned.

 

The attributes with which the consumer can be identified are encrypted in the SAML assertion. The consumer attributes are encrypted with symmetric AES keys. These AES keys are in turn encrypted with the public key of the certificate of the DISP. Then the entire SAML assertion is signed by the VS with its private key (see point 1). After decrypting the symmetric AES keys with the private key of the DISP's certificate, the DISP has included the symmetric decrypted AES keys in the PDF.

The symmetric AES keys included in the PDF are used to decrypt the encrypted attributes in the SAML assertion signed by the VS. If these decrypted attributes provide readable and understandable information then the only conclusion can be that the VS has supplied the consumer attributes to the DISP.

 

Validating the DocumentID (hash)

Now that we are able to validate the SAML assertion, we need to verify that it actually is related to the document in question. The DocumentID is the SHA256 hash value of the document to be signed. In a sequence of signatures the DocumentID will effectively bee identical to the SHA256 hash value of the document including the previous signature. To provide a reference point for the first signatory, the document is initially signed by a single time stamp. This initial time stamp serve as the previous signature for thee first signatory. The image below illustrate how the DocumentID is in fact the hash value of the document including the previous signature.

 

validate_idin5

Signature sequence with 2 signatures

 

Validating the DocumentID in the first signature SAML assertion is a matter of calculation the hash of the time stamped edition and prove it identical to the DocumentID recorded in the assertion.

 

Procedure to validate the DocumentID

In Adobe Reader open the signature panel and right click on the initial time stamp.

 

validate_idin4

Signature panel in Adobe Reader. View and save the signed version.

 

Select "View Signed Version" and save this version to a separate file (e.g initial.pdf).

The SHA256 hash value of the extracted file can calculated using the  certutil  command-line utility like this:

 

c:>certutil -hashfile initial.pdf SHA256

SHA256 hash of initial.pdf:

7a632c2637a66d80775715a551d780bddd16c0dd643b3d86c15580ec640c7b26

CertUtil: -hashfile command completed successfully.

 

 

Comparing the DocumentID in the SAML assertion and the calculated SHA256 hash value from the initial document:

SAML assertion DocumentID

SHA256 hash value

7A632C2637A66D80775715A551D780BDDD16C0DD643B3D86C15580EC640C7B26

7a632c2637a66d80775715a551d780bddd16c0dd643b3d86c15580ec640c7b26

 

The two identical values proves that the iDIN Signature is infact tied to this document.

This procedure can be repeated for each signatory in the sequence of signatories calculating the SHA256 hash value from the previous signed version.