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.
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.
References
- Hacking Signatures from Signature Servers (2017), by Ebbe Skak Larsen
- Introducing the Signature Activation Protocol for Remote Server Signing (2016), by Jan Kjærsgaard
- REGULATION (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC(2014) by the European Parliament and the European Commission
-
Electronic Signatures and Infrastructures Activities (2017), by ETSI
- Selected articles on eIDAS (2014-17), by Heather Walker, Guillaume Forget, Jan Kjaersgaard, Dawn M. Turner and more
- Selected articles on Authentication (2014-17), by Heather Walker, Luis Balbas, Guillaume Forget, Jan Kjaersgaard, Dawn M. Turner and more
- Selected articles on Electronic Signing and Digital Signatures (2014-17), by Ashiq JA, Guillaume Forget, Jan Kjaersgaard , Peter Landrock, Torben Pedersen, Dawn M. Turner, Tricia Wittig and more
More Stories
