Architecting a Cloud Signature Consortium (CSC) signature solution

Bun-Ny TAN
3 min readSep 2, 2020

Last year, I helped a customer to build a cloud-based signature solution, compatible with Cloud Signature Consortium (CSC), using FIDO authentication. The solution was presented during the International Cybersecurity Forum (FIC) in January 2020. This article describes the implemented solution and its architecture.

What is CSC

For a long time, end-users used devices such as desktop computers and laptops to access online services including accessing bank accounts, authorizing payment transactions, signing contracts… Accordingly, digital signatures are tailored to these devices by using smartcard and token-based solutions, which usually need thick-clients or drivers installed. Nowadays, this assumption is no longer true since mobile devices such as smartphones and tablets have started to replace desktop computers and laptops.

In this regard, recent regulations in various regions in the world, like eIDAS in the European Union, have introduced the “remote signature creation device” concept, meaning that the signature device is no longer a personal device under the user physical control, but is replaced by remote/cloud-based services provided by Trusted Service Providers (TSP). However, exchanges with TSP usually use proprietary APIs and are not standardized.

Thus, industry and academic organizations have created the Cloud Signature Consortium (CSC) in order to build a new cloud-based digital signature standard. This standard supports web and mobile applications, helps adoption and interoperability, and complies with the most demanding regulations in the world. The CSC provides:

  • Architectural designs
  • Communication protocols
  • APIs
  • Data structures
  • Technical requirements

CSC architecture

The schema below is the architecture provided by CSC.

The Signature Application retrieves the document to sign and shows it to the end-user.

The end-user authenticates and gives his/her consent to sign either through the Signature Application or through an external Authorization Server.

The Signature Application requests the Remote Signing Service Provider (RSSP) to create the signature.

Implemented solution and its architecture

The schema below shows how we have implemented the CSC architecture.

The Signature Application, which is either a web application or a mobile application, retrieves the document to sign and shows it to the end-user.

When the end-user wants to sign the document, the Signature Application redirects the end-user to the Authentication and Authorization Server. The Authentication and Authorization Server deployed is an open source OpenID Identity Provider (IDP) such as Keycloak or ORY Hydra. It handles end-user authentications, Remote Signing Service Provider (RSSP) and end-user signing key access authorizations.

The end-user authenticates using his/her password plus FIDO token and gives his/her consent to sign. This is a 2 Factor Authentication (2FA) where the FIDO token (mobile device, USB token or NFC token) stays under the end-user physical control.

The end-user is redirected back to the Signature Application with an authorization code.

The Signature Application sends the authorization code and the document to sign to the Signature Gateway.

The Signature Gateway requests the Authentication and Authorization Server an access token, computes the document hash.

With the access token, the Signature Gateway requests the RSSP to create the hash signature. The RSSP is an in-house developed server.

The RSSP validates the access token, signs the hash, and returns the signature to the Signature Gateway.

The Signature Gateway reconstructs the signed document and sends it back to the Signature Application.

At the end, the end-user gets the signed document.

Links

Here are some links related to CSC

--

--