Remote Electronic Signatures: How to Improve Performance and Scalability

National digital signature schemes that utilize remote electronic signature technology can achieve very high usage rates, whereas Trust Service Providers and Banks (who might use the schemes) also tend to reach millions if not tens of millions of signatures per year - with peaks exceeding hundreds per minute. In this article we discuss the key elements for designing a scalable architecture to deliver a digital signing service under a high Service Level Agreement (SLA) with high throughput and low latency.

The first element to keep in mind is that the global performance of a digital signing system is the result of a combination of different subsystems. Each subsystem has its own bottlenecks. The global performance is also strongly impacted by the network topology, especially considering that most deployments use a decoupled architecture with functional modules spread in different network zones - as highlighted in the Cryptomathic Signer product page.

A typical remote signing integration is illustrated below.

The web application drives the signature process and is of course a critical element which IT architects must take into considerations.

Such web applications are generally java-based with sessions protected by one-way SSL/TLS. The performance characteristics of such Java applications in the cloud were analyzed by IBM in the following article: https://www.ibm.com/blogs/bluemix/2017/05/performance-case-study-bluemix-online-banking/.  

The above article presents some interesting observations and best practices recommendations to optimize performance of an online banking application.

The next element to consider is the actual user experience with remote signing. Using Cryptomathic Signer (our remote QES solution) as an example, the following steps must be considered:

• The size of the PDF document is an important factor. The larger the document is, the more time it will take to retrieve, prepare, render and manipulate. Best practice is to work with small size PDFs (a few hundred KB or less if possible) with standard fonts/encoding. Business owners should then design a simple PDF form or use third party PDF optimization libraries to remove unnecessary objects in PDF documents, detect and merge duplicate images and fonts, and modify image resolution, compression and color spaces to reduce size. For better performance, Cryptomathic offers PDF conversion to PDF-A 2. This ISO standard ensures that the document will be visualized in the same way in all browsers and helps ensure long term validation.

• The Cryptomathic WYSIWYS (What You See Is What You Sign) Server renders PDF documents into images, which are sent to the client. This allows for the implementation of responsive design to optimize usability. Pages are rendered individually as they are processed but it is nevertheless important to select a server with many cores and optimize performance using tuning techniques such as described here: https://www.mulesoft.com/tcat/tomcat-performance
• In case of extremely high load, the WYSIWYS Server can be set up in an active/active cluster, consisting of several nodes.
• Rendered PDF documents are kept in the WYSIWYS Server primary memory for the duration of the signing process. The RAM needs to be sized according to the document size, document count and average document reading time.
• To optimize the user interface, the system should be able to generate thumbnails of the document pages. These increase the usability due to improved clarity and overview of the document in question. Also, thumbnails only require limited memory on the server and are quickly transmitted to the client.

• The digital signing server, like Cryptomathic Signer, is obviously critical component in terms of the architecture. When designing the signing solution, particular attention must be paid to ensure that the signing server can scale to handle millions of users and a high volume of signature operations. To this extent, Cryptomathic Signer runs a firmware extension inside the HSM to ensure that the security sensitive functions are handled using the HSM without returning to the server, and stores logs and user related information in a high capacity database to allow for clustering. There are multiple configuration factors impacting performance, including:
• Key generation is one of the slowest function as it can take up to a second to generate a 4k RSA key pair, and the time increases exponentially when the key size grows.
• Opting for long-lived keys instead of one-time keys significantly improves performance.
• Using ECC instead of RSA also has a strong impact (with ECC being much faster).
• Database connectivity is key as it sometimes becomes a bottleneck in stress tests.
• The signature throughput can be increased by adding more and faster HSMs to a signing server. Moreover, a signing server itself should have the capability to be clustered as well.

• These systems only sign data using a static key held in the HSM, therefore high performance should be expected. Unfortunately, this is not always the case. These services can have a major impact on the overall throughput, e.g. a PAdES LTA signature requires two timestamps and several OCSP responses.
• The usage of OCSP responses instead of CRLs should be favored. In most cases the CRLs tend to grow, leading to distinctly increased document size and longer network transmission time.

In our benchmark tests, Cryptomathic Signer reached up to 50 signatures per second in an optimized cluster with HSMs using 2k RSA keys. We have verified that performance increased almost linearly when adding additional HSMs or servers. This means whether your solution targets thousands or millions of signatures, Cryptomathic can deliver a cost-effective architecture to meet your performance objectives.

References and Further Reading

• COMMISSION DELEGATED REGULATION (EU) supplementing Directive 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication (2017), by the European Commission
• Selected articles on Authentication (2014-18), by Heather Walker, Luis Balbas, Guillaume Forget, Jan Kjaersgaard, Dawn M. Turner and more

• Selected articles on Electronic Signing and Digital Signatures (2014-todays), by Ashiq JA, Guillaume Forget, Jan Kjaersgaard , Peter Landrock, Torben Pedersen, Dawn M. Turner, Tricia Wittig and more

• REGULATION (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (2016), by the European Parliament and the European Council

• Proposal for a REGULATION concerning the respect for private life and the protection of personal data in electronic communications and repealing Directive 2002/58/EC (Regulation on Privacy and Electronic Communications), (2017), by the European Parliament and the European Council

• Revised Directive 2015/2366 on Payment Services (commonly known as PSD2) (2015), by the European Parliament and the Council of the European Union
• 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

• DIRECTIVE 2013/37/EU amending Directive 2003/98/EC on the re-use of public sector information (2013) by the European Parliament and the Council

• Recommendations for the Security of Internet Payments (Final Version) (2013), by the European Central Bank

Image: fast Gallop, courtesy of Claudia Dea, Flickr (CC BY-ND 2.0)