The recent article published by Ebbe Skak Larsen, KMD (hereafter "the Article") on hacking signatures from signature servers, describes a simplified setup of a remote signature (RS) solution and mounts an attack on that. The article then concludes that the only mitigation to the attack is to strengthen the script in the browser using obfuscation techniques.

It continues and uses the conclusion to advocate, that a strong, obfuscated JavaScript client can just as well be used to generate key pairs and sign in the browser, and in that way, make remote signature services redundant.

The article goes on to claim that this 100% browser based solution is at least as secure as remote signature solutions – unfortunately without any arguments.

Let’s look a little deeper into that and see why this is not true.

What You See Is What You Sign (WYSIWYS)

A secure signature solution encompasses many different aspects including key management and a public key infrastructure. A central security goal is to ensure that the user can only sign authentic documents or, more generally, information that is presented to the user – meaning that if a document has been tampered with, the user cannot sign it. This is called WYSIWYS and is the subject of the Article. Below we will focus on the WYSIWYS property of signature solutions as well, but we will also need to touch upon key management and PKI in general.

No single mechanism, which is provably secure and practical to the WYSIWYS problem, has been demonstrated as of today. However, in remote signature solutions, several mechanisms can be brought into play each of which helps improving the security of the overall solution. Some of these are

  • Including information of the document to be signed in the authentication mechanism used to ensure sole control of the private signature key. E.g., using OCRA or SMS

  • Providing information of the document to be signed using a separate channel ensuring that the attacker must attack two independent channels to lure the signer into signing the wrong document.

  • Most likely, a business application like a public service, gaming, or online bank is involved and it is that application and not the user that submits the document to the WYSIWYS component. In this situation, it can be guaranteed that the signed document the service provider allowed to request digital signatures.

  • Enhancing the security of the user interface to make it more difficult for the attacker to manipulate what is shown to the user as suggested in the Article.

In any signature solution, a mixture of the available mechanisms must be applied to obtain WYSIWYS. While the last enhancement may not be necessary in some cases, improving the security of the client will generally help providing WYSIWYS.

New Call-to-action

Browser Security

The Article proposes to base all security of the signature solution on securing the JavaScript code executed in the browser. Not only is this mechanism used to ensure WYSIWYS, it is also suggested as the basis of securing the private key.

As mentioned above, Cryptomathic endorses multi layered security schemes to enhance client and solution security. One such scheme is obfuscation of JavaScript code which aims to protect the code from reverse engineering and code modification. While used with success in many deployments, these schemes lack recognized security proofs and trusting the confidentiality of signature keys solely on this is asking for trouble.

In addition, trusting an obfuscated client executed in a browser is part of the risk assessment the trust service provider operating the signing service should conduct. The assessment should cover how many copies of the signature key that exist in the user’s environment. Operating system page swapping and todays widespread virtualization increase the risk that a key may occur in various instances. Since cryptographic keys appear more random than other data, they are easily spotted for an attacker with the capabilities as the one described in the Article who has access to install a malicious browser plugin in the user’s browser.

Using Secure JavaScript in Remote Signature Solutions

Cryptomathic fully supports securing JavaScript running in the browser, to obtain a mechanism helping to ensure WYSIWYS. However, we will definitely not recommend basing security of a complete signature solution on this. Additional layers of protection are needed and the remote signature solution is perfectly suited for combining several security mechanisms to obtain “security in depth” as coined by Bruce Schneier.

To come back to the claim in the Article that the proposed solution is at least as strong as remote signature solutions, we hope that the above illustrates that any mechanism used to strengthen the browser can also be used to improve WYSIWYS in remote signature solutions. However, when using remote signatures, additional security mechanism can be added independently of this, resulting in a more secure signature solution.

Protection of Signature Keys

Furthermore, we would never recommend signature solution based on keys in software – even if the corresponding certificates are only valid for a short time.

The Article proposes to have keys generated in the browser. Key generation algorithms require a seed obtained from a good random source, which is difficult to achieve in the browser on all typical devices including smart phones. If the random source does not have the expected quality, then the keys can be broken much easier than where is has it strength (factorization, discrete logs).

This is unlike the keys that are used in remote signature solutions, as such keys are generated in a certified HSM, which ensures that the keys have full strength.

A note on the Legal Requirements

With eIDAS, qualified electronic signatures have the same status as a hand-written signature and are recognized cross border in the internal market. Businesses and services can as part of their digitization strategy look beyond the home marked and enjoy the opportunities provided by EU.

While eIDAS on one side provides opportunities, it also puts requirements for devices that has signature keys. Remember that these keys can protect high values. The requirement is that these devices are carefully looked after in a tedious certification process to prevent against attackers with much higher capabilities than script kiddies; we are protecting keys and preventing their theft, potentially from national security agencies.

Since browser based keys don’t have the physical protection, such solutions will never pass a certification, it is as simple as that.

There is a long list of requirements produced by ETSI ESI and CEN TC224 WG17, which the operator of a qualified signing service must conform to. The operator must demonstrate how the signing service mitigates several attack scenarios – including the one sketched in the Article. So just to be clear; if a remote signing service would be subject to the described attack, it would not be allowed to be put into operation.

Conclusion

In this article, we have demonstrated why a remote signature solution provides significantly better WYSIWYS security than a solution purely based on securing JavaScript in the browser as proposed in the Article.

Furthermore, the proposed solution in the Article has a very weak point on the protection of signature keys as protection by obfuscation is simply inadequate for preventing keys against being copied.

In relation to this, we stress that eIDAS requirements for legally binding signatures require that keys cannot be copied. Therefore, the proposed solution cannot be used under eIDAS.

 Download white paper

References

Photo: "Multiple Locks" courtesy of Michael Coghlan (CC BY-SA 2.0)

Other Related Articles: # Digital Signatures # eIDAS

Want to know how we can help ?

Get in touch to better understand how our solutions secure ecommerce and billions of transactions worldwide.