Barry O’Donohoe, Raidiam’s CEO and Co-Founder, addresses the important and often neglected topic of cryptography and its vital role in ensuring the success of a data sharing ecosystem.
Data sharing ecosystems can be created to implement national-level programmes (regulated or not) such as Open Finance, a commercial consortium play, or even by a single enterprise wishing to benefit from a platform business model. Regardless of the scale or type of ecosystem, trust and security of interactions between all parties is critical. A fundamental requirement to ensure success here is to focus on the role that standards, digital certificates and Public Key Infrastructure (PKI) – sometimes collectively referred to as ‘trust services’ – play and their use of cryptography.
Three key trust services for Open Finance success and their use of cryptography
1. FAPI
The financial-grade API (FAPI) standard is the dominant international model for secure data sharing being applied globally with 12 major international markets (and growing) having already built on this. FAPI, from the OpenID Foundation, is a robust profile of OAuth2 and OpenID Connect designed for the needs of high assurance data sets – such as financial data or payments. Raidiam is named co-author having led this for the UK Open Banking in 2017/18. Open Finance programmes across the globe from the UK, Europe, Australia, Brazil, North America and MENA have all gravitated toward using the FAPI international security standards and profile. To ensure the highest levels of trust and security FAPI mandates the use of asymmetric cryptography for various electronic exchanges between parties to mitigate various attack vectors, according to the formal security analysis. FAPI outlaws the use of API Keys and API Secrets – analogous to usernames and passwords, which are the mainstay of how APIs are secured globally today. Whilst API Keys and Secrets might be okay for social media, they are not nearly strong enough to be acceptable for high assurance data sets such as banking, payments, and health.
2. Digital Certificates
A digital certificate is an electronic credential that identifies, and can electronically authenticate, a subject. The subject could be a human, an organisation, a software application, a client or server component. These electronic credentials are small electronic files that operate like a digital passport; they include information (as attributes) about the issuer, the subject that it identifies, a unique serial number and a validity period, for example. Importantly, a digital certificate comprises a public key and a private key that are mathematically related – essentially two long prime numbers that, when cryptographic functions are applied, can be used to provide various critical security functions.
Before outlining what those functions are it is important to clarify the parties and roles being played in such an exchange – they are:
- The Resource Owner – typically a personal or business customer user who owns their customer account data and authorises payments.
- The Data Provider – typically an accredited licensed financial service provider who provides a current account or other financial service product and gives access to third party data receivers via an API.
- The Data Receiver – also an accredited licensed financial service provider who consumes API resources exposed by the data provider, authorised by a resource owner (with their explicit consent).
The security functions (provided by digital certificates) needed in such an exchange include:
- Authentication – to prove that an entity is who they claim to be in a digital exchange. For example, with the FAPI security standard all exchanges between the communicating parties must take place over Transport Layer Security (TLS) and in many cases mutually-authenticated TLS where both communicating parties authenticate each other and establish a secure encryption key for all messages sent back and forward over the (insecure) internet.
- Confidentiality or privacy of the data in transit between the communicating parties so that data on the wire is never in a cleartext, readable format.
- Digital Signatures – to convey origin authentication, message integrity and non-repudiation.
- Integrity – to ensure that messages cannot be changed or tampered with after they are created.
- Non-repudiation – so that a party can’t deny having undertaken a digital interaction involving their private key after the fact.
3. PKI and Certificate Authorities (CAs)
Digital certificates are manufactured by a Certificate Authority (CA) using common open standards and apply asymmetric cryptography that has underpinned most of our everyday digital exchanges for decades now – think SIM cards, credit or debit chip cards, telecommunications networks and much more. Digital Certificates follow the X.509 standard. In the Open Banking or Open Finance world there are various approaches to meeting the digital certificate needs of an ecosystem.
Private Certificate Authority
Option 1 is a private and dedicated CA provided by, or on behalf of, an ecosystem operator such as a Central Bank or sector regulator – for example Open Banking Limited in the UK. In this model a single PKI and CA is used by a closed user group in which all ecosystem participants subscribe to the same CA and enrol for certificates in a self-service manner. Having a single issuing Certificate Authority greatly simplifies the ongoing certificate lifecycle management concerns – for renewal, replacement, deactivation, revocation/blacklisting, suspension/resumption etc. And critically, it makes the reliance on these certificates by data providers/receivers much more simple, as they have a single Certificate Authority to trust across their API platforms.
Decentralised Certificate Authority
Option 2 involves a decentralised Certificate Authority approach with several commercial providers as seen in the example of the EU, which is market led. The European Banking Authority’s regulatory technical standards permits Qualified Trust Service Providers (QTSPs) operating across the EU under eIDAS to issue digital certificates to organisations wishing to engage in Open Banking activities regulated under PSD2. In this model, participants seeking to obtain digital certificates must identify and subscribe to one of many certificate providers (~100), which have varying enrolment processes, procedures and associated costs and can make choosing one difficult.
In this approach, the work for data providers is much higher, as they have multiple Certificate Authorities to trust and maintain across their API estate. This problem is compounded by a conceptual flaw applied to the digital certificate structures.
The eIDAS model per EBA PSD2
When eIDAS certificates are issued for PSD2 purposes, the PSD role(s) the organisation can perform is encoded within the certificate as defined by the Regulatory Technical Standard (RTS) from the European Banking Authority (EBA). These roles are maintained by the National Competent Authority (NCA) of each member state which acts as the supervisory body. In the UK, for example, the FCA acts as the authority for licensing organisations to perform certain roles in an Open Banking context and maintains the FCA register which is the master list of what roles an organisation is permitted to perform e.g. Payment Initiation Service Provider (PISP).
When a Third Party Provider (TPP) is licensed, it must then obtain an eIDAS digital certificate from one of several QTSPs which acts at the certificate authority. In minting the certificate, the QTSP must check the NCA register to confirm the license before encoding this as attributes in the certificate being issued. Once the certificate has been issued to the TPP, it can be presented to any authorised Data Provider (bank) who is obliged to accept the certificate and grant access to APIs that can act on behalf of its (the bank’s) customer. The bank needs to determine whether the certificate can be accepted for this purpose without adding in unnecessary barriers to entry.
The difficulty arises where the bank cannot rely solely on the authorisation encoded within the certificate as it may have changed at the NCA since being issued by the QTSP – for example, if the organisation has lost its license to perform the accredited role. This requires further checks against the respective NCA which can be arduous given the non-standard interfaces they expose for the purpose.
This anti-pattern has created a market for solutions that do the painstaking task of aggregating the authorisation data across all EU national registers and standardise the interface to query it. This could be better undertaken by a single common Trust Framework that solves it for the entire ecosystem in a standardised way and saves banks from having to source and integrate with proprietary commercial solution providers.
To use the digital passport analogy once more, this would be similar to including membership of a country’s library network and right to borrow books in your passport. The difficulty with this is that you are storing volatile attributes – those which can quickly change – in an authentication credential with a long validity period. The passport provider (certificate issuer) might only check with the library network when they issue the passport (certificate issuance), before recording your borrowing rights (minting a digital certificate) that remain set in stone for the life of the passport. A problem arises when your membership of the library network is withdrawn and there are no standard mechanisms for the passport issuer (Certificate Authority) who issued the passport (certificate) to become aware of this and revoke the certificate.
This means the passport (certificate) could be accepted and grant unauthorised access to the holder when their rights have actually been revoked. Translating the passport example to Open Banking, the library network acts like an NCA, who licenses a bank to operate as a library in this example, and the library user is a TPP. No standard scaled model exists anywhere, let alone in Europe, for NCAs (library networks) to notify all the PKI Certificate Authorities (passport issuers) so that Banks (libraries) only permit authorised TPPs (library users) to perform PSD2 roles (withdraw books).
This is further compounded in Europe, where each member state’s NCA maintains a register of organisations and their corresponding PSD license authorisation(s) for that country. Nor is this done in a standardised way – as different NCAs use different interfaces, data formats, flat files, issuance periods, etc. This is without even getting into this issue of passporting of roles into different member states, which adds an additional layer of challenges.
So, the key takeaway for National or Supranational Sector regulators is to avoid encoding volatile role or authorisation information in a digital certificate – a long-lived identity credential. This anti-pattern is conceptually and practically flawed on several levels leaving the market vulnerable to unauthorised access. Public key infrastructures (PKIs) were not designed for this purpose.
Choosing the right PKI provider
Finally, when choosing a PKI provider for any large-scale or national data sharing scheme, it is critical to factor in the PKI’s ability to meet the hyper-scalability, performance, and availability of high-volume API calls.
From our own experience working with global Open Finance initiatives, we’ve witnessed the problems that can be caused with certificate issuers and PKI providers who struggle to deal with the scale and performance of a high-volume usage API ecosystem. Here in the UK, Open Banking’s outsourced PKI service has suffered availability issues that took out the entire ecosystem on a couple of occasions, with significant impact to the market.
This is why we’ve specifically designed the Raidiam Connect PKI for hyper-scale, performance and availability as a fully integrated solution. Our solution deals with these related API concerns and maintains an integrated public key set in JWKS format both at a software and an organisation level. It also enables the related lifecycle management to support the corresponding digital certificate lifecycle and status – traditional PKIs do not deal with this concern at all. We also support a ‘Bring Your Own Certificate’ model (BYOC) and can accept certificates from third party issuers, however this does suffer from the aforementioned issues.
That has been a whirlwind tour of a complex and technical issue. Please get in touch if you have questions and wish to discuss further.
Considering setting up your own data sharing ecosystem? Get in touch today and learn how our Raidiam Connect Trust Platform will deliver what you need.
Barry O’Donohoe is CEO and Co-Founder of Raidiam.
