3KeyeIDASPKISigning

eIDAS SignServer: Management of users and cryptographic keys

We have discussed so far the architecture of the remote signing solution and how it can be applied for different use cases like digital signature or electronic sealing on advanced and qualified assurance level according the eIDAS regulation.

The eIDAS SignServer solution provides everything you need for a remote signing application. You can have your own front end and signing logic implemented independently of the SignServer. You can also use any type of the HSM or QSCD to protect the cryptographic keys.

But how you can manage the users and associated private keys? Secure management of users and cryptographic keys is an important task in the remote signing solution. In order to understand it, we need to look at the different perspectives of advanced and qualified remote signing solutions within this context.

User identity in context of remote signing

Identity and authentication provider is an integral part of any modern information system. The remote signing solution must be aware of the identity of the user who would like to execute signing operation. There are many ways how to achieve it, including many different technologies that could be utilized. The signing backend and its logic is responsible for handling the identities in a secure manner.

The main difference is how is the identity and authentication is handled for different assurance levels:

In case of advanced remote signing solution, the user is identified and provisioned into the identity provider repository with the selected or generated credentials. The user needs to be authenticated before the signing operation is performed and based on the user’s identity, certificate and private key is allocated and used.

For the qualified remote signing solution, we have additional component called SAM (see the eIDAS SignServer: Qualified remote signing for more information). As we need to ensure that only the designated user would be able to activate and use the associated private key, we need to provision the user’s identity also into the SAM. This will enable the user to securely establish Signature Activation Protocol and provide Signature Activation Data to authorize signing operation.

Advanced level

User provisioning

  1. User identification verification
  2. Generation of credentials
  3. Provisioning into identity provider stores
  4. Generating the key pair
  5. Issuing certificate for the identity

Signing operation

  1. Authentication of the user
  2. Authorisation of the signing operation
  3. Signing of the data to be signed
  4. Provide result

Qualified level

User provisioning

  1. User identification verification
  2. Generation of credentials
  3. Provisioning into identity provider stores
  4. Provisioning into the SAM
  5. Generating the key pair for the user
  6. Issuing certificate for the identity
  7. User activation of the private key

Signing operation

  1. Authentication of the user
  2. Authorisation of the signing operation
  3. Providing the signature activation data
  4. Signing of the data to be signed
  5. Provide result
Assurance Level Identity Provider Signing Backend SignServer
ADVANCED
Stores users identities and provides authentication
Identification and provisioning process of users into Identity Provider
Authorises signing request based on authentication
QUALIFIED
Stores users identities and provides authentication
Identification and provisioning process of users into Identity Provider and into the Signature Activation Module (SAM)
Authorises signing request based on authentication result provided by Identity Provider and Signature Activation Data provided by the user

The role of the SignServer

Although the signing backend can implement the user and cryptographic keys management directly with the HSMs or SAM modules, usually its preferred that this operations are managed by the SignServer centrally.

The SignServer uses the term of “alias” to represent the information connected with the user and associated private key. The alias is typically used to distinguish the cryptographic keys in various key stores like PKCS#12, JCEKS, or interfaces like PKCS#11.

When you connect the HSM, QSCD, or SAM with the SignServer, you automatically gain the capabilities of:

  • generating and associating private key with the user
  • create a user in the SAM and generate associated private key for the user
  • generate CSR and issue certificates for the user

You can automate it through Web Services or REST API of the SignServer.

Administration web service interface

You can use the administration web services interface of the SignServer with the following methods:

  • generateSignerKey – creates the user and generates the associated key pair identified by alias
  • getPKCS10CertificateRequestForAlias – prepares and signs the CSR with the private key associated to the user, which can be used to issue certificate for the user
  • importCertificateChain – imports signed certificate to the user’s associated alias and the key pair
  • removeKey – destroys the key pair and associated user identified by alias

Admin web interface

If you prefer to do all the user and cryptographic keys management tasks by yourself, you have the possibility to manage it the Admin Web interface. The functionality covers the same as in the case of the administration web services with the addition of the GUI.

Need help?

Do not hesitate to get in touch with us!

Get in touch with us!

security | data intelligence | consulting

Contact us!