Can your e-signatures survive court scrutiny?

?Projects implementing e-signatures (including digital signatures) usually focus on the business benefits of cost-cutting, efficiency and improved user experience.

Often, however, the initial driver for e-signing projects can be compliance and regulations.

Even without compliance requirements, it's unlikely you would be asking your customers, employees or partners to sign documents unless you wanted their agreement to be legally-binding in case of disputes.

Some examples of documents which may ultimately lead to disputes later include employees e-signing company policies or customers agreeing to the terms of an online service as part of the initial application.

When implementing e-signing for your processes it's important to consider the threat scenarios. Let's explore some common arguments you may need to respond to as part of proving your e-signature solution can be trusted. This will help you to determine how adequately your e-signature technique will stand up in a court of law under expert review.

Threat 1:?That is not my signature!

Typically, e-signature solutions allow the signer to make their mark on a document to indicate their approval of the document contents.

Often such marks are just squiggles drawn using a mouse or a touch screen, very much like the process of ink-signing on paper.

Although in the paper world it’s not easy to copy an ink-signature from one document to another without detection as a fake, in the electronic world any image can be easily cut and pasted from one document to another and look no different to the original.

An independent adjudicator can’t pass judgement solely by looking at signature images! As the service provider how do you prove that a particular person created that signature mark? A person can easily claim that a signature mark on a document is not theirs (referred to as “repudiating” a signature).

To counter this at a basic level you could show server logs to prove the user logged into the system. From these you can show how they were authenticated (e.g., using strong multi-factor authentication) before viewing and signing the document.

You could even show IP address and geo-location information of where the user was when logging in. However, none of the above evidence can prove that they actually made that particular signature mark on that particular document! So, a squiggle signature mark by itself can never give you this proof - i.e., the server logs and the document are different things and not connected in a non-refutable manner. Instead, what is required is the signer's trusted e-identity to be tied to the document in an undeniable way.

PKI-based digital signatures achieve exactly this, a person is issued a unique digital identity (X.509 certificate) by a trusted third party (referred to as a Certificate Authority or CA) after secure verification of their real-world identity. The person can then use their X.509 certificate to digitally sign a document.

The act of signing cryptographically embeds and locks the person's digital identity into their signature so there can be no doubt on who signed. CAs typically are trusted organizations like government bodies, banks, mobile operators or even your own enterprise.

Threat 2: ?The document was changed after I signed it!

Another threat is that the signer could claim the document was changed after they signed it. This is quite easy to counter if your e-signature solution uses strong and standard cryptographic techniques, e.g., SHA256 hashing algorithm with RSA 2048-bit keys.

These cryptographic algorithms can prove with very high levels of assurance that any changes to the document (even a single binary bit change in the document) will be detected when verifying. Earlier algorithms such as use of SHA1 and MD5 are no longer considered strong from a legal perspective, so must not be relied upon.

It's important to use standard algorithms and standard ways of signing so that in a court the signed documents can be verified using multiple software solutions, i.e., you are not relying on proving a digital signature using a single vendor's software solution – which could be considered faulty or even malicious!

Standard ISO/ETSI PDF signatures are recommended for this reason.

Threat 3: ?That was not the document I signed?

In this threat scenario the signer claims that they signed a different document to the one which is being presented now.

The fact that there is a cryptographic signature on the document which indicates that they signed it is not enough if it can be proven that when the user viewed the document the content was different, i.e., the claim is that when the user viewed the document, they saw something else and what was cryptographically signed was something different.

This is a complex threat to counter successfully. The e-signing solution needs to prove that the document was shown to the user in a secure manner.

Typically, this means presenting documents in PDF/A format which is a “flattened” document format ensuring the document does not have any software code running which can present the document differently to if it was printed on paper.

PDF/A format also ensures the fonts are embedded inside the document and are not dynamically linked such that they can be misrepresented later.

To counter Man-In-The-Middle (MITM) or Man-In-The-Browser (MITB) threats, industry best practice recommends that the document is signed initially by the service provider before presenting to the user.

This locks the document’s integrity such that the user can verify the service provider has sent the document and that it has not changed by anyone in the middle. This can give assurance to users that the document is authentic and can be signed by them.

Users should also be encouraged to download and save a local copy of the document (ideally before and after signing) as additional proof of what they signed if considered appropriate.

Threat 4: My signing key was used by someone else to sign!

This is where it starts to get complicated! A fraudster could claim that the digital ID used to create the digital signature was compromised somehow by a hacker, or even from the service administrator’s side where somehow access to a central copy of the digital ID and private signing key to create the digital signature was gained.

To successfully overcome this claim, the service provider needs to prove that industry best practices were employed to protect user signing keys and in fact no one else could have reasonably accessed the key. Industry best practice requires, amongst many other things, that the user keys must be stored in tamper-resistant hardware security modules (HSMs) which are trusted and can't be hacked. If implemented properly this line of argument can be easily defeated.

Threat 5: I had revoked my Digital ID!

The claim this time is that the user’s Digital ID (X.509 certificate) was revoked by the user and that the signature took place subsequent to this; so, it must have been done by someone else.

To counter this threat scenario requires the e-signature solution to create standard long term digital signatures. These signatures include an embedded timestamp to prove when the document was signed according to a trusted Time Stamp Authority (TSA). The status of the signer’s digital ID can also be embedded into the signature at the time of signing to prove the signer’s key was valid. With long-term signatures it does not matter if the user’s signing key is later revoked because at the time of signing it was valid, therefore previously signed documents can continue to be considered legally valid even after the user’s signing key is compromised, revoked or expires.

Threat 6: I didn't understand what I was doing!

This can be a very common concern – a user can easily claim that they did not know what they were doing at the time of signing. For example, they didn’t realize that a particular GUI button/link when clicked would actually sign the document at that moment in time or they were not aware the signatures would have legal significance or even that they did not get a chance to read the document fully before signing etc. To counter such arguments, the e-signing solution has to ensure the signing action is a willful act. This requires employing features such as:

? Showing a legal notice (in the user’s local language) enabling the user to be fully aware of the legal implications of their signature. The user should not be able to proceed with the signing action until they have approved this.

? Providing initials against important paragraphs or on every page, to prevent the user from claiming something important was missed whilst they were signing

? Ensuring that the GUI shows clear “SIGN” or “APPROVE” buttons in the user’s local language and ensuring there is an opportunity for the user to cancel the operation even after initiating the process. Most business applications also need a workflow process option for the user to “DECLINE” the signing action if they don’t agree. To ensure the signing operation was a willful act an additional step could be to authenticate the user again at the time of signing (as opposed to just at time of login and viewing the document). This again helps to prove the user knew what they were doing.

Conclusion.

?Not all e-signatures are the same. To implement legally binding signatures requires businesses to think of the potential threat scenarios and ensure they have put in place countermeasures that mitigate the risks.

Now we have discussed a range of threat scenarios and presented relevant countermeasures. It’s important to note legally binding e-signatures are not just about the technology, you need to take a holistic approach and look at the complete process of viewing and signing documents to ensure an independent adjudicator can have no reasonable doubts on who signed and whether they knew the implications of their actions at the time.

We provide a robust combination of features to counter such threats including:

? Flexible e-signing policy management and control over the signing process to meet EU eIDAS Regulations, US EsignAct, Adobe AATL & CDS requirements plus others

? Advanced digital signatures using unique signing keys for every user,

? Long-term signatures with embedded trusted timestamps and signer’s certificate status info

? Strong cryptographic algorithm support,

? Advanced HSM support, including cloud based HSMs and secure bulk key management using HSM,

? Legal notices,

? Initials and mandatory input fields,

? Simple and intuitive GUI,

? Multi-lingual support,

? Workflow completion report (a signed PDF report listing all modifications to the document, who performed these and when),

? Detailed server process logging as additional audit trail. We have a long history in developing secure digital signature technology to meet the most stringent of legal requirements for government and financial clients.