Technique - Digital Signature Service


Present situation

  • Today most electronic signature services use a general purpose server certificate to sign documents.
  • This means that there is no individual document signature of any of the Signatories.
  • The intent and action of each Signatory is covered by only one general server signature.
  • These services cannot create signatures with a Secure Signature Creation Device (SSCD).

In some cases, signing a document once with a general purpose server certificate ("server stamping") is enough, just as for example a verbal recorded consent, scribbling with the mouse or clicking a button with the text "I sign".

But if you need a stronger signature, which is also compliant with the Public Sector requirements (eIDAS) you should consider using ProSale Signing.

Click to enlarge

ProSale Digital Signature Service

The core of ProSale Signing is the "Digital Signature Service". This service can be used separately and is then called ProSale DSS. It complies with the OASIS DSS standard and with the Swedish requirements defined by the Swedish E-identification Board. Detailed descriptions of the specifications are given below.

ProSale DSS was tested during the spring of 2014 and approved by the Swedish National Procurement Services September 2, 2014 as the first electronic signature service. The approval allows public authorities to suborder our services.

Problems we solve

With ProSale Signing individual, secure and legally binding document signatures are created.

How we achieve this

The simple explanation is that we separate the action of "identification" from "signing". This means that you identify yourself electronically. The service then authenticates the signatory with an Identity Provider (IdP). Different types of identification schemes are classified according to Levels of Assurance.

After authentication of the signatory, it can access the document to be signed. This is very important as many documents to be signed contains sensitive information only intended to be accessed by a specific Signatory. When the signatory wants to sign the document, an additional authentication can be performed if required. In other cases the existing authentication can be reused with Single-Sign On (SSO) without renewed authentication.

When the signatory performs the action to sign the document, a one-time key pair is produced in a Hardware Security Module (HSM) with the required algorithm (RSA, ECDSA, etc.). After signing the document hash, the private key is destroyed immediately and a certificate created with the public key.

Major components

The following diagram shows an overview of the major components involved with the ProSale DSS:

Click to enlarge

ProSale Signing or other SP

ProSale Signing (or other Service Provider) authenticates the Signatory and displays the document to be signed. When the Signatory wish to sign, a document hash is calculated and securely sent to ProSale DSS in a Sign Request via the Signatory's web browser.

Signatory

The Signatory now has access to its personal attributes from the Identity Provider via a SAML-ticket. It uses the Web Browser and has intent e.g. “To Sign” a document according its attributes.

Identity Provider

The Identity Provider is used to authenticate the Signatory and to provide relevant attributes. After the receipt of SAML Authentication Request the Signatory is identified. The result is the return of a SAML Authentication Response.



ProSale DSS

When ProSale DSS receives the Sign Request it authenticates the Signatory with the possibility of using Single Sign-On.

A one-time private and public key pair is created in a Hardware Security Module (HSM) for the transaction. The private key is used to sign the document hash and is destroyed immediately after it is used.

The public key is placed in a one-time certificate for the transaction and the Signatory.

ProSale DSS now returns the signed document hash, the public certificate of the Signatory, the root certificate and possible intermediate certificate to ProSale Signing (or other Service Provider) in a Sign Response.

ProSale Signing (or SP) checks the Sign Response and uses the results as required. This could for example be to assemble a signed PDF and return this to the Signatory or storing a signed XML-string in a database.

Standards

ProSale DSS implements the following standards: XAdES signature, ETSI Advanced Electronic (AdES) standard formats, PKC, QC and QC/SSCD certificates, RSA, ECDSA, SHA, XML, PDF, ASiC signature formats, DSS protocol, XHTML forms, CA, CRL, OCSP, XKMS, Certificate policy TS 101 456 and TS 102 042 from ETSI, NIST SP 800-131 and ETSI TS 102 176-1, CMS IETF RFC 5652, Discovery Service, SSO, IdP, LoA, SAML, XML Dsig, ASN.1, BER, SAML 2.0, PKI.

Specifications

Here are some important specifications that we comply with:

Server Stamping

We also provide the option of "Server Stamping" for the purpose of electronic signature when required.

PDSS Support Service

To integrate ProSale DSS with an e-Service or Business Application using a low-level API such as OASIS DSS SignReqest and SignResponse can be very time-consuming and costly.

In order to facilitate this work we provide the PDSS Support Service. This can start the signing process very easily with the ProSale API. The basic input for the service is only the document to be signed and details about the Signatories.

When the signing process is completed the PDSS Support Service assembles the signed document (e.g. XML, PDF, etc.) and returns this to the e-Service or Business Application.

Another very important aspect is that the PDSS Support Service can be hosted within the company’s own network. This feature allows documents to stay under company control and not disclosing any sensitive or top-secret information to any third party.