The notion of Advanced Electronic Signature was introduced in the European Directive for electronic signatures[1], which remains today an important milestone for the standardisation and legal recognition of electronic signatures. Advanced Electronic Signatures (hereinafter AdES) offer a very practical method to protect information and provide trust in electronic business. They can be embedded in popular document formats such as PDF, XML and CMS messages[2] and are also the base stone for creating qualified electronic signatures (QES)[3]
Art. 2 of the directive contains some requirements on signatory identification and. This paper describes how a central signature server can fulfill these requirements. This article relates to the European Commission Standardisation mandate m460 to CEN and ETSI on electronic signatures and is proposed as input for the ETSI standard prTS 14167-5.
What is Advanced Electronic Signature?
The directive broadly defines an electronic signature as data that can be associated with and authenticate other data. To be considered Advanced, an electronic signature must
a) be uniquely linked to the signatory;
b) be capable of identifying the signatory;
c) be created using means that the signatory can maintain under their sole control;
d) be linked to the data to which it relates in such a manner that any subsequent change in the data is detectable.
In practice advanced electronic signatures are therefore implemented using digital signatures based on asymmetric cryptography with the private key uniquely linked to the signatory. The signature is verified using the public key of the signatory and by setting up a proper PKI (typically using certificates) the signature identifies the signatory. Existing signature methods[4] ensure that the signature is linked to the data to be signed in a secure way.
These aspects of advanced electronic signatures are also discussed by the Forum of European Supervisory Authorities for Electronic Signatures (FESA)[5]. However their paper ignores the case where the user/signatory key is stored on a central signature server.
In this analysis, we will look more precisely at the impact of central user key storage which, at a first glance, may seem not to comply with the requirement c) that AdES signature must be created using means that the signatory can maintain under his sole control. In other words, how can the key be solely controlled (I.e. accessed and used for signature purposes) by its owner while it is being stored on a remote server?
First of all it is paramount that the signatory private key is protected by a hardware security module (HSM) on the remote server.
A simple approach would then be to authenticate the signatory using standard username/password and open a SSL/TLS session to the server in order for the user to get access to his private key. This causes a number of issues:
a) Username/Password is a method vulnerable to simple attacks such as phishing or replay attacks and cannot be considered secure enough to ensure sole control
b) if the TLS channel is terminated outside the HSM the password will occur in clear on the remote server in order to be used for getting access to using the private key of the signatory. Access to the key is therefore subject to memory snapshots by a fraudulent system administrator, thus once again defeating the sole control.
How to achieve sole control?
In order to prevent (a), it is recommended to implement a stronger signatory authentication, i.e. implement 2-factor authentication, where the password constitutes one factor. The second factor could be a (preferably) dynamic authentication method based on e.g. OTP. This implies that a trustworthy 2-Factor authentication service is introduced to the solution.
(b) is more difficult of achieve. We need to ensure that no single system administrator can get access to the signatory key (i) or use the key (ii).
For (i) to be fulfilled, the signatory private key shall be protected by an HSM so that the key may never appear in clear outside the HSM.
(ii) can be solved in different ways, ideally by implementing many of the following measures:
-
Make physical AND logical access to the HSM under dual control so that single administrator cannot sign data on behalf of the signatory.
-
Access to use of the key is exclusively possible after successful authentication of the signatory (procedures shall be in place to ensure the system administrators, including HSM administrators, cannot get access to the signatory authentication values, such as passwords or OTPs).
-
The signatory private key can only be applied to (hashes of) messages that are authenticated by the signatory
It is also recommended to implement strong logging functionality in order to securely monitor all actions related to the management of signatory keys and authentication secrets.
Conclusion
This paper shows that there is no reason to restrict the creation of AdES to local smart card/workstation. Trust Service Providers implementing the above measures can perfectly supply advanced electronic signatures in cloud based environments where Application Service Providers rely on such service so that users can sign (web) documents remotely and securely. This offers a number of benefits including:
- Centralised key management: easier process for generating, storing, backing up and renewing keys - immediate disablement upon key revocation
- Value added services: to enhance the value offered to the signatory, the centralized approach allows the Trust Service Provider to mediate connection to time stamping, archival, notary services.
- Reduced costs: no smart card / smart card readers needed, reduced dependency towards the workstation, reduced hotline costs / leverage infrastructures costs for large number of signatories and application service providers.
Such a solution has been implemented by Cryptomathic in the Signer solution. As noted in the introduction, higher assurance levels can be achieved when the associated certificate is qualified and if the central signing service is SSCD certified. Though the Cryptomathic Signer has not undergone a formal SSCD certification process, we have carried out together an external law firm a study showing that it the solution fulfills the SSCD requirements. We are happy to share the findings upon request.
References
[1] Directive 1999/93/EC of the European Parliament and the Council of 13 December 1999 on a Community framework for electronic signatures
[2] The European Telecommunications Standards Institute (ETSI) has published standards for AdES including:
- PaDES: ETSI TS 102 778 "Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles
- XaDES: ETSI TS 101 903 "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signature Profiles
- CaDES RFC 5126 "CMS Advanced Electronic Signatures" and ETSI TS 101 733 "Electronic Signatures and Infrastructures (ESI); CMS based Advanced Electronic Signature Profiles
[3] Advanced electronic signatures based on a qualified certificate and generated using a secure signature creation device must according to the directive be considered equivalent to handwritten signatures. Such signatures are called Qualified Electronic Signature (QES).
[4] E.g., using RSA, DSA og ECDSA.
[5] Working Paper on Advanced Electronic Signatures of October 12 2004 http://www.fesa.eu/public-documents/WorkingPaper-AdvancedSignature-20041012.pdf
More Stories
