Banking-as-a-Service (BaaS) is an unbelievably powerful concept, one that leads to a plethora of new banking innovation, customer experiences, financial service offerings and even new industries, like embedded finance. But it also helps drive efficiency across the banking sector which in turn helps spread costs – which ultimately helps keep things like current accounts free, or very cheap to use.
Clearly, I am a big fan of BaaS, and no-one will be surprised by that, since I first started designing, I believe the world’s first ever BaaS solution, back in late 2014. This concept went on to form the core offering and proposition that was and is ClearBank, the UKs first new clearing bank in over 250 years and the first bank to bring what I call true Banking-as-a-Service capabilities to the market. I say true because, unlike other offerings, BaaS by ClearBank also means you can potentially leverage the “license”, which in turn means users of ClearBanks BaaS can provide FSCS protected bank accounts.
BaaS always has had and still has today, a challenge regarding security. And this comes down to a few macro level issues, which include:
- Key creation and exchanges always run over the same infrastructure.
- Humans are involved in some aspects of the security process / key exchange
- A single form factor of authentication is used
- Limited capability to limit the lifespan of security keys
- Lack of immutability of messages
These aren’t small issues, and until recently were risks that had to be partially mitigated with complex, cumbersome processes, and the use of technology wherever possible. All this comes at a cost, and since BaaS is about driving costs down and lowering the barrier to entry, security constraints kind of go against the proposition a little. But things all changed when ID Crypt Global started to trail DPKIps, a Decentralised Public Key Infrastructure coupled with some smart tech based components and a set of protocols, aimed at solving the toughest of security challenges, that of systemically important payment systems….
So how does DPKIps help solve these challenges for BaaS. Well let’s look at them one at a time.
Key creation and key exchanges
No matter the BaaS solution, the challenge is always around security keys, their creation and potential reliance on a single point of failure, the Central Authority (CA), and how keys were exchanged between BaaS provider, and BaaS consumer.
With DPKIps, bi-lateral peer-to-peer secure communications channels are setup using the IDC Agent, think of this as an Identity Vault and Hardware Security Module (HSM) that is able to communicate securely with other agents. This peer-to-peer infrastructure is OUTSIDE of the control of the BaaS provider, and as such, removes the BaaS provider from the creation and key exchange infrastructure/processes. This alone significantly improves security and removes many risks.
When peer-to-peer communication channels are opened, they are cryptographically secured, which allows data and sensitive information, like security keys to flow safely between the two IDC Agents. Because of this, DPKIps creates “pairwise” keys which are unique to the peer-to-peer relationship connection itself. These pairwise keys are essentially two sets of private/public keys, where the public keys are exchanged between the two IDC Agents.
For a BaaS provider, this means security keys can be exchanged and the BaaS provider need not build any technology, any additional infrastructure, form a relationship with a CA, act as a CA or spend months building and designing operational processes to mitigate key exchange risk.
With the vast majority of BaaS implementation, security keys/tokens etc require some form of human intervention, be that operationally or even by interfacing with a BaaS providers web portal. At some point, humans are involved in the exchange of security keys, secrets, tokens etc. This adds risk, and when we are talking financial transactions, that potentially could be high value and volume, the risk is simply increased.
With DPKIps, key exchange is automated and humans never know where the keys are physically stored, even system administrators are unable to access the underlying infrastructure used by the IDC Agent.
By removing the need for humans to be involved, not only does DPKIps reduce the associated security risk, it also significantly reduces complexity and operational cost.
Single form factor
Almost all BaaS solutions use API keys and then some form of message signing. However, this doesn’t actually act like Multi-Factor Authentication (MFA) does for end users. There is only ever a single point of authentication – and that is through the BaaS provider.
DPKIps solves this because the creation of security keys and their exchange, takes place on infrastructure outside of the BaaS providers control. It also ensures keys that are exchanged and distributed over one infrastructure have been applied and used correctly for the purpose of message signing within the BaaS solution. This means there are now two independent forms of authentication. The first being the BaaS providers infrastructure and its inherent security, the second being the two cryptographic signatures that are attached with the message. These signatures prove several facts,
- The message was signed correctly using expected keys.
- The message content is immutable (tamper proof)
- Who the message originated from
- The intended recipient of the message (this could be the ultimate recipient, not limited to the BaaS provider)
- The message can be stored tamper proof for the purpose of audit
Note that with DPKIps there are two signatures on the message. The first is based on the identity of the sender, the second on the unique pairwise keys exchanged between IDC Agents. I will talk to why there are two signatures when we look at the “lack of immutability of messages” in BaaS.
BaaS security keys, tokens etc always have a lifespan that is longer than desired. This is purely because of the processes and therefore cost associated with key creation and exchange. Because these processes are fraught with risk, complexity and are expensive, rotating and replacing security keys becomes a risk based exercise. In addition, security keys aren’t cheap. If a CA is used, then keys typically can cost approximately £1,000 per key, so the expense of replacing keys also has to be taken into consideration. Many therefore leave security keys to be rotated/changed on an annual basis.
Longer living security keys carry risk. If a key is compromised and has a longer lifespan, then that key can be used for a longer period of time and therefore poses more risk. Even if the key isn’t used initially, the fact it has a longer window in which to be used, again increases risk.
Ideally, security keys would live for just a few hours, significantly limiting the risk associated with a compromised key. With DPKIps this is exactly what can be achieved…
DPKIps allows key exchanges to be automated, and as such, key creation and exchanges can be scheduled and automated. Since DPKIps delivers security keys without a CA and at a fraction of the cost, security keys can be rotated quickly, efficiently, easily and at a cost that is not prohibitive. One Financial Market Infrastructure (FMI) user of DPKIps rotates ALL keys across every single network member within a time period of less than 24 hours. Keeping in mind, that just two entities will have 4 keys to secure their relationship, a significant number of keys are being exchanged on a daily basis.
Lack of immutability of messages
Messages that flow across BaaS aren’t immutable, they aren’t tamper proof and therefore carry risk. How does a BaaS system cryptographically prove that the message originated from where it should have, and how does it store that message to prove immutability to an auditor years from when the message was sent?
Message signing within BaaS aids with the tamper control around messages, however, since keys will be changed, even if signatures are stored by the BaaS provider and auditor is unable to confirm that the message processed was the message received and more worryingly the message stored.
DPKIps solves this with its two signatures.
The identity signature, known as the public signature is based upon the senders digital identity. The IDC Agent writes the digital identity public key to a blockchain, which is an immutable ledger, therefore ensuring the public key is available to all forever. The public key relates to the identity of the sender, so an auditor is always able to decipher a message signature signed with DPKIps. That signature therefore proves the immutable nature of the message, from its origination to its processing to its storage, it can never be modified – if it is, then the signature no longer matches the message itself. Auditors can for the life of the message being stored, always prove it hasn’t been tampered with.
The second signature relates to the pairwise keys exchanged between the message parties. This signature proves that the sender meant for the recipient to receive the message, along with the immutable nature of the message, it also proves the immutable nature of sending it to the recipient.
Since I first started working on BaaS back in 2014, it’s safe to say it has come a long way. It is now estimated that by 2030, BaaS will be a $7 trillion industry, that’s right a $7 trillion industry. As the adoption of BaaS continues and the value of the industry continues to increase, so is the attention that BaaS providers receive from cyber-criminals. As such, BaaS needs to continue to be at the cutting edge of financial services, this time in terms of security implementation.
From a security footing, DPKIps significantly improves security associated with BaaS implementations, but it does more than just improve security. DPKIps mitigates security risks while at the same time, drives down all associated security and operational costs. Its these two factors, improving security and driving down costs, that sees BaaS and DPKIps strategically aligned.
For more information on DPKIps visit the ID Crypt Global website. You can also get a deeper understanding of what DPKIps is here.