Buypass policy for cryptographic keys signing assertions/tokens

Introduction

The concept of an Identity Provider (IdP) is important in modern authentication (and authorization) protocols like OIDC and OAuth2. An IdP issues assertions/tokens etc that may be used for clients to get access to resources or services at a Relying Party (RP). Thus the RP must trust the IdP, and for use cases where the IdP and RP are managed by the same organization the trust may be implicit. However in the general case, the IdP should include some mechanism to prove it's trustworthy to any RP.

Assertions are statements from an IdP to an RP that contain information about the end user (claimant/subscriber). The IdP issues assertions/tokens by signing such statements using digital signature technology, i.e. the signature is based on public key cryptography (PKC) but it's not required to use digital certificates (PKI). 

The specifications and standards used for these protocols are technical specifications, but without policy requirements saying how to establish the trust between the RP and IdP. The protocols support different methods for trust establishment and (public) key distribution. The flexibility in methods are there to support different use-cases and scenarios as well as differences in security levels. The challenge then is to find a balance between sufficient trust level and technical and practical complexity of both private and public key management. 

The IdP may also take an important role as a integral part of the authentication mechanism as defined in the eIDAS requirements, see section 2.3.1 of Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015 where an important requirement is:

The authentication mechanism implements security controls for the verification of the electronic identification means, so that it is highly unlikely that activities such as guessing, eavesdropping, replay or manipulation of communication by an attacker with enhanced-basic/moderate/high attack potential can subvert the authentication mechanisms.

The words enhanced-basic/moderate/high is used to differentiate between the requirements for Level-of-Assurance (LoA) Low/Substantial/High respectively (the terminology is taken from Common Criteria). In order to comply with this requirement, we must ensure that the authentication protocol and the IdP is included in the analysis of the authentication mechanism. In this case, the security of the operation of the IdP must be taken into consideration. As an example of how to address this, we may use NIST SP 800-63C Federation and assertions where we find this requirements in section 4.1 Key management:

.. and all IdPs asserting authentication at AAL3 SHALL protect keys used for signing or encrypting those assertions with mechanisms validated at FIPS 140-2 Level 1 or higher.

AAL3 * is comparable to eIDAS LoA=High when it comes to assurance levels. (The FIPS 140-2 is replaced by FIPS 140-3 by now, but this is mainly used as an illustrative example of a relevant policy requirement). 

This document defines a policy for the use and management of cryptograhic keys signing assertions/tokens for security domains used in Buypass and for Buypass services. However, the concept and policy levels could be adapted to similar purposes also outside Buypass.

*) Authenticator Assurance Level (AAL) defines the robustness of the authentication process itself and AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber.

Buypass policy

Security mechanisms

We have identified three different, but complementary security mechanisms that could be used to differentiate between trust in terms of assurance (policy) levels for an IdP signing assertions/tokens:

1. Protection of private keys for signing assertions/tokens, e.g. protected by tamper resistant hardware devices (e.g. HSMs) or in software key stores - this a security mechanism addressing the security of the IdP operation
2. Linking the private keys to the IdP legal identity by means of digital certificates issued by a trusted service provider, e.g. a QTSP issuing certificates to the legal entity operating the IdP - this is all about establishing trust between the IdP and a RP
3. The frequency of rotating the signing keys, an assertion signing key may be frequently used and the rotation of keys (replacement) may be an important parameter for the security of the IdP operation - this is also important for the security of the IdP operation

A fourth mechanism is public key distribution. Signed assertions/tokens are signed and designed to be verifiable «offline» by the RP, given that the RP have/can get the correct public key. This can for example be done using well-known URLs and the JWKS protocol supporting multiple active keys and key identification as part of the token. An alternative approach is to distribute the public keys as a set of predefined certificates to the RPs in a parallel channel (e.g. sent by mail or downloadable from a web-site), we may consider to implement this by using our CertPub service. 

In addition the cryptographic algorithms used for signing the assertions must comply with current best practices, e.g. by following the recommendations in ETSI TS 119 312, 

The security mechanisms are further elaborated in the sections below. 

Protection of signing keys

By default, an authentication/authorization server used in OIDC/OAuth2 like Keycloak may use cryptographic keys stored in clear in its own DB. This type of protection is too weak and we have identified some additional levels of protections.

A very high level of protection of cryptographic keys is by using an HSM where the private keys are protected in tamper resistant hardware devices certified according to FIPS 140-2 level 2 or higher. This is comparable to the NIST requirement for AAL3 (although level 1 allows for FIPS certified SW implementations). This is also similar to the level of protection of private keys Buypass have used previously in older authentication protocols (e.g. used in WIPS). 

Our new system architecture also includes the Vault as a component for protecting secrets, this may also be used for protecting private keys although the keys must be imported to Keycloak for use. We call this way of protecting the private keys for Vault protection, i.e. the keys are protected in a software key store, but the access to this store is limited. Even though the keys are protected in a software key store, the creation and use of them are protected within the system architecture which ensures a higher level of protection than the default mechanism described above. 

Certifications for public keys corresponding to signing keys

An IdP is typically operating a set of services identified by an URI and some well defined endpoints under this "Root URI", for Buypass this is https://auth.buypass.no/auth/realms/SECURITYDOMAIN; In this case we may say that the "trust is in the URI", if an RP trust that Buypass IdP is operating this Root URI, the RP will find all information for using the Buypass IdP services in this Root URI.

However, this is apparently a weak trust anchor in the general case and we think it is necessary to consider basing the trust on a more traditional trust anchor, e.g. a CA issuing digital certificates. To ensure a commonly accepted trust anchor, we could require that the CA must be an QTSP issuing digital certificates for legal persons at defined policy levels. The ETSI standards defines policy levels like QCP (Qualified Certificate Policy), NCP (Normalized Certificate Policy) and LCP (Lightweigth Certificate Policy) which could be used for this purpose - see Business Certificates - an introduction v1.2.pdf for more details. 

By basing the trust a digital certificate binding the public key to the IdP identity (i.e. the legal person operating the IdP) we get stronger level of trust. In addition, the TSP issuing the certificates should be a publically trusted TSP, e.g. a QTSP like Buypass AS. 

Key rotation frequency

Rotation of the signing key is also a recommended security mechanism, this is partly due to the potentially high volume of assertions (i.e. transactions) signed by the private key and also an agile way of being able to replace keys due to several situations that may occur. Of course, the key rotation frequency must also take the key protection mechanism and the use of certificates, e.g. a signing key protected in an HSM and where the public key is certified in a digital certificates does not to be as frequently replaced as a signing key less secure protected. 

Defined policy levels

We have defined three different levels of assurance (or policy levels) for the use and management of cryptographic keys signing assertions based on the three identified security mechanisms: 

In addition to choosing a proper policy level for a security domain, an IdP must also take into consideration how to distribute the public keys, by using well-known URLs and the JWKS protocol or by "out-of-band" distribution of certificates (e.g. by means of CertPub).

Common for all policy levels is the use of cryptographic algorithms, based on recommendations from ETSI TS 119 312. The current requirement (as of 2020) is "at least 112 bits cryptographic security", i.e. at least SHA-256 and 2048 bits RSA (or similar for ECC, e.g NIST P-256).

Buypass security domains

The table belows defines the recommended policy levels for each Buypass Security Domain:

References

Buypass

• Buypass Authentication with Open ID Connect (OIDC)

General:

• Commission Implementing Regulation (EU) 2015/1502 of 8 September 2015
• eIDAS Interoperability Architecture