eIDAS Certificate Handling

The purpose of this section is to describe how Klarna protects the eIDAS (electronic IDentification, Authentication and trust Services) certificates of their customers

The eIDAS certificate is used for the following purposes:

  • Identification and authentication of the customer towards the ASPSP (QWAC [Qualified Website Authentication Certificate], transport layer).
  • Encryption of the traffic between Klarna and ASPSP (QWAC, transport layer).
  • Generating a digital signature of the payload to ensure the integrity and as an additional method for identification/authentication (QSealC, [Qualified Electronic Seal Certificate], application layer).

Security Measures

As the eIDAS certificate offers the ability to prove the identity of the customer, the certificate is considered as sensitive and highly confidential data and must be protected and secured.

Non-technical Security Measures

  • In the contract between the customer and Klarna it is clearly stated that it is an obligation of Klarna to only use the eIDAS certificates in the scope of the defined services of the agreement.
  • The lifecycle of the certificates fully remains in the responsibility of the customer. The certificates used for the Open Banking integration can be revoked by the customer at any time.
  • The customer can (and should) use a separate set of eIDAS certificates only for the Open Banking integration. This makes the certificate lifecycle independent and ensures business continuity of the other operational business of the customer in case of a revocation and creates a direct mapping from the specific eIDAS certificates to the Open Banking use-case. The EBA describes/recommends the same in one of their published letters:

However, in the specific cases where PSPs provide services through agents or EEA branches, or where they have outsourced to technical service providers some of the activities related to access to the online accounts held within an ASPSP, the EBA hereby clarifies that CAs should encourage these PSPs to consider using multiple certificates simultaneously: one per agent, EEA branch or technical service provider. This should ensure business continuity and better risk management of these PSPs because the legitimacy of one certificate would not be affected by the revocation of any other. PSPs remain fully responsible and liable for the acts of their agents and outsource providers as well as for the revocation and updating of the eIDAS certificates used by them.

Technical Security Measures

To offer the best security and protection of the eIDAS certificates and private keys, the customer can choose between two approaches:

  • Klarna HSM: To allow Klarna to fully manage the process, the customer can share the certificates with Open Banking. The certificates will be uploaded to an HSM (hardware security module), which is a proven and certified security platform for managing and storing private keys in a highly protected, architecturally secure system. No one has access to the keys and only the system itself can generate signatures with the HSM based on the customer's eIDAS certificates.
  • Customer operated HSM Reverse API: If the customer wants to be in full control of their eIDAS private keys and does not want to share their certificates with Klarna, Open Banking offers the possibility to integrate a HSM Reverse API. All signing requests will be sent to the customer and it is their responsibility to generate the corresponding signatures within their own environment.

Using the Klarna HSM

There are three procedures for adding the customer's eIDAS certificate to Klarna's HSM.

  • Send Klarna the private key, public key and the cert-file of the eIDAS certificates attached to an encrypted email, preferable via KeePass or GnuPG with symmetric passphrase (gpg -c FILE). Please do not include the password in this email, use a separate communication channel for it.
  • Klarna can generate the private key directly in the HSM. This will ensure that nobody will ever see the private key, but there is no way to share it with the customer later since it is protected by the HSM.
  • Visit one of the Klarna offices and upload the private key to the HSM yourself.

Using a Customer owned/operated HSM Reverse API

Klarna supports HSMs that are are owned/operated by the customer. This enables the customer to fully control the eIDAS certificate private keys in their own HSM.

Requirements

  • A secure connection from Klarna to the customer’s HSM Reverse API service.
  • Implementation of Klarna’s “HSM Reverse API” (see below).
  • The HSM Reverse API must support signing of payloads with different algorithms that are typically used for the QWAC and QSealC certificates.

Implementation of the HSM Reverse API

The HSM reverse API standardizes the complex HSM API. It helps to secure the connection between Klarna and the customer's HSM because Klarna does not need direct access to the HSM itself.

API Definition

POST /sign
Authentication+Encryption: JWE

Request:
{
  "session_id": "XS2A-API session_id to correlate this request to an existing session.",

  "alias": "Identifier for the key which must be used to sign the payload.",
  "algorithm": "Algorithm to use for signing.",
  "payload": "Base64 encoded payload that must be signed after decoding it.",
  "tls_client_auth": "Signature is part of the tls_client_auth for an HTTPS tls-handshake.",

  "digest_hash": "Hash of digest_payload generated with digest_hash_algorithm.",
  "digest_hash_algorithm": "The hash algorithm used to generate the digest_hash from digest_payload.",
  "digest_payload": "Base64 encoded input for the digest_hash."
}

Response:
{
  "signature": "Signature generated by the HSM, encoded as Base64."
}

API Data-Type Example

POST /sign
Authentication+Encryption: JWE

Request:
{
  "session_id": "UUID",

  "alias": "klarna-qwac-2019-07-01",
  "algorithm": "SHA256_RSA",
  "payload": "base64-string",
  "tls_client_auth": true/false,

  "digest_hash": ?"base64-string",
  "digest_hash_algorithm": ?"SHA256",
  "digest_payload": ?"base64-string"
}

Response:
{
  "signature": "base64-string"
}
POST /sign
Authentication+Encryption: JWE

Request:
{
  "session_id" : "175cnd9qoj7i9sh4ihf8ch8jrnc6th7t",

  "alias" : "klarna-qseal-2019-07-01",
  "algorithm" : "SHA256_RSA",
  "payload" : "KHJlcXVlc3QtdGFyZ2V0KTogcG9zdCAvb2F1dGgyL3Rva2VuCmRhdGU6IFdlZCwgMzEgSnVsIDIwMTkgMTU6MTI6MjYgR01UCmRpZ2VzdDogU0hBLTI1Nj13MG15bXVMOGFDcmJKbW1hYnMxcHl0WmhvbjhsUXVjVHVKTVV0dUtyK3V3PQp4LWluZy1yZXFpZDogNjYwOTBlNzEtYmQ1Yi00NGU2LTgwOTgtM2ZlYzU1NjhmZTVj",
  "tls_client_auth" : false,

  "digest_hash" : "w0mymuL8aCrbJmmabs1pytZhon8lQucTuJMUtuKr+uw=",
  "digest_hash_algorithm" : "SHA256",
  "digest_payload" : "Z3JhbnRfdHlwZT1jbGllbnRfY3JlZGVudGlhbHM="
}

Response:
{
  "signature": "SIGNATURE"
}
POST /sign
Authentication+Encryption: JWE

Request:
{
  "session_id" : "175cnd9qoj7i9sh4ihf8ch8jrnc6th7t",

  "alias" : "klarna-qseal-2019-07-01",
  "algorithm" : "SHA256_RSA",
  "payload" : "(request-target): post /oauth2/token
date: Wed, 31 Jul 2019 15:12:26 GMT
digest: SHA-256=w0mymuL8aCrbJmmabs1pytZhon8lQucTuJMUtuKr+uw=
x-ing-reqid: 66090e71-bd5b-44e6-8098-3fec5568fe5c",
  "tls_client_auth" : false,

  "digest_hash" : "w0mymuL8aCrbJmmabs1pytZhon8lQucTuJMUtuKr+uw=",
  "digest_hash_algorithm" : "SHA256",
  "digest_payload" : "grant_type=client_credentials"
}

Response:
{
  "signature": "SIGNATURE"
}

API PIS Example

POST /sign
Authentication+Encryption: JWE

Request:
{
  "session_id" : "175cnd9qoj7i9sh4ihf8ch8jrnc6th7t",

  "alias" : "klarna-qseal-2019-07-01",
  "algorithm" : "SHA256_RSA",
  "payload" : "ZGlnZXN0OiBTSEEtMjU2PTdPaCs1UG9hSFNEUXphYnkxTGZYUEZjTis1bFQvVXJzaWNKaDlBbERqK3c9CngtcmVxdWVzdC1pZDogZjJlNGIwYjUtODUyNC00NTgzLWFkOWUtMmI0ZTkxNGMxNTMzCnBzdS1pZDogVlJLMTIzNDU2Nzg5ME9QVApkYXRlOiBUaHUsIDEgQXVnIDIwMTkgMDg6MTg6MjggR01U",
  "tls_client_auth" : false,

  "digest_hash" : "7Oh+5PoaHSDQzaby1LfXPFcN+5lT/UrsicJh9AlDj+w=",
  "digest_hash_algorithm" : "SHA256",
  "digest_payload" : "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxEb2N1bWVudCB4bWxucz0idXJuOmlzbzpzdGQ6aXNvOjIwMDIyOnRlY2g6eHNkOnBhaW4uMDAxLjAwMS4wMyI+PENzdG1yQ2R0VHJmSW5pdG4+PEdycEhkcj48TXNnSWQ+MTY2NDgxODUzMTAxOC01ODMwMTcwNTk8L01zZ0lkPjxDcmVEdFRtPjIwMTktMDgtMDFUMTA6MTg6MjcuOTM2KzAyOjAwPC9DcmVEdFRtPjxOYk9mVHhzPjE8L05iT2ZUeHM+PEN0cmxTdW0+MTIzNDwvQ3RybFN1bT48SW5pdGdQdHkvPjwvR3JwSGRyPjxQbXRJbmY+PFBtdEluZklkPjE2NjQ4MjU1NDY1MzMtOTA5NzA2NjY8L1BtdEluZklkPjxQbXRNdGQ+VFJGPC9QbXRNdGQ+PE5iT2ZUeHM+MTwvTmJPZlR4cz48Q3RybFN1bT4xMjM0PC9DdHJsU3VtPjxQbXRUcEluZj48U3ZjTHZsPjxDZD5TRVBBPC9DZD48L1N2Y0x2bD48L1BtdFRwSW5mPjxSZXFkRXhjdG5EdD4yMDE5LTA4LTAxKzAyOjAwPC9SZXFkRXhjdG5EdD48RGJ0ci8+PERidHJBY2N0PjxJZD48SUJBTj5ERTM5NDk5OTk5NjAwMDAwMDA1MTExPC9JQkFOPjwvSWQ+PC9EYnRyQWNjdD48RGJ0ckFndD48RmluSW5zdG5JZD48T3Rocj48SWQ+Tk9UUFJPVklERUQ8L0lkPjwvT3Rocj48L0Zpbkluc3RuSWQ+PC9EYnRyQWd0PjxDaHJnQnI+U0xFVjwvQ2hyZ0JyPjxDZHRUcmZUeEluZj48UG10SWQ+PEVuZFRvRW5kSWQ+Tk9UUFJPVklERUQ8L0VuZFRvRW5kSWQ+PC9QbXRJZD48QW10PjxJbnN0ZEFtdCBDY3k9IkVVUiI+MTIzNDwvSW5zdGRBbXQ+PC9BbXQ+PENkdHIvPjxDZHRyQWNjdD48SWQ+PElCQU4+REUwMjUwMDEwNTE3Mjg1NzY3MzMxNTwvSUJBTj48L0lkPjwvQ2R0ckFjY3Q+PFJtdEluZj48VXN0cmQ+dGhpcyBpcyBhIHRlc3QgcHVycG9zZSB0ZXh0PC9Vc3RyZD48L1JtdEluZj48L0NkdFRyZlR4SW5mPjwvUG10SW5mPjwvQ3N0bXJDZHRUcmZJbml0bj48L0RvY3VtZW50Pg==",
}

Response:
{
  "signature": "SIGNATURE"
}

results matching ""

    No results matching ""