At the heart of security within the financial services industry is the good old centralised Public Key Infrastructure (PKI). Every central bank, financial market infrastructure (FMI), payment system, Banking-as-a-Service (BaaS) provider, embedded finance
provider, even the way in which we all connect to secured websites goes through a centralised authority (CA) that effectively delivers the implemented PKI. PKI is essentially the cornerstone of security in the digital age.
For those of you who are not familiar with PKI, here is a quick rundown. A PKI delivers a level of security on the premise that anyone can verify a digital signature from anyone else, providing you have the public key that corresponds with the private key
used to create the digital signature. The two keys are cryptographically linked, so only the public key can verify that which has been created by the private key. With me so far?
On the web, the best example of this in action is sites that are hosted securely, delivering HTTPS. Your web browser depends on a small number of these Central Authorities (CA) who effectively act as the root of trust across the internet. In a web browser,
the owner of the private key is the owner of the website. They have provided the CA with the corresponding public key, which has been signed by the CAs own private key. The CA then issues a public key certificate, which is trusted as it is signed by the CA.
Web browsers effectively check this public key certificate each time you connect to a secured website.
Within financial services, PKI is imperative to secure connections, APIs, payment messages and more. However, PKI brings several security challenges itself. For example, how were keys created? The processes behind distribution of keys? How and who installed
keys? How can you be sure that keys haven’t been shared? Who has access to keys? Even in sophisticated BaaS implementations, keys are often exchanged through a web browser, which means a human is involved in the key exchange and setup. The result, that’s significant
risk, which providers attempt to mitigate by adding complex processes. Far from perfect, and very far from a secure approach you might expect from a financial institution in the 21st century.
Top security experts understand the challenges and risks, and as a result, many central banks and FMIs across the globe are looking to improve security. Most of which are looking at implementing a ‘Y’ security model, which can be seen as a form of Multi-Factor
Authentication (MFA) for connectivity and APIs. To date, (to the best of my knowledge) only one financial services-based organisation has successfully implemented a true ‘Y’ security model – and that achieved this via a DPKI (Decentralised Public Key Infrastructure)
for payment services solution.
‘Y’ Security Model
Anyone that operates within financial services should be striving for a ‘Y’ security model. It’s something that should looked at across all aspects of security, right up to an organisations CISO. But what is it?
A ‘Y’ security model is essentially two independent points of verification that are used together to confirm authentication, in a similar fashion to MFA. However, a ‘Y’ security model, in its truest sense, would not have the same ‘issuer’ of keys or the
process. More often than not, solutions that use MFA still rely on the same infrastructure, same company and same processes to issue, process and verify. That’s not a true ‘Y’ model.
For example, a BaaS provider provides API connectivity to its customers. This could be done using a traditional PKI or a more modern (and secure) decentralised approach. However, the BaaS provider should also be checking that the payload within the API has
not been modified in flight, therefore a good way of doing that is by digitally signing the payload with a private key. The BaaS provider holds the public key. The issue here however, how did the BaaS customer get/create/share its keys? It is typically a process
through a single infrastructure and with the same departments at the BaaS provider. This introduces risk and doesn’t provide a ‘Y’ security model at all, as the keys are still being exchanged and using the same infrastructure (even CA) in the same way.
In a ‘Y’ security model, the message would have been signed using different keys that were created in a totally different fashion, and exchanged via a totally different infrastructure. The BaaS provider would have ideally nothing to do with the key exchange
process itself. Now when a message is signed as the receiver (the provider of the BaaS solution) you have two independently formed points of verification. Hence ‘Y’ model.
How does decentralisation help?
Decentralisation removes the need for CAs from the PKI solution. By moving to a DPKI the CA is removed, and therefore risks associated with a centralised issuing authority are avoided. The CA as a singular point of failure is also removed from the process,
something that regulators often look at when assessing technology systems.
DPKI replaces an organisation, the CA, as the root of trust, and places it in science, more specifically maths. In a DPKI implementation, public keys reside on the blockchain, which is decentralised, highly resilient and available for all to have access.
Not only does the blockchain remove a single point of failure, it also enables significant levels of automation, improved secured communications capabilities for key exchanges and dramatically reduces the cost of implementation and ongoing maintenance.
This implementation then allows subsequent keys to be created, privately, and with DPKI for payment systems bi-laterally (point-to-point) exchanged. This delivers automation and ensures keys are never shared across a centralised infrastructure, removing
human intervention, and therefore associated risk. The resulting public keys being stored on a local private blockchain ledger.
A patented DPKI for payment systems infrastructure is now available for regulated businesses to utilise, securing everything from message communications between institutions, to BaaS implementations, payment systems and much more. It will take some time
for a DPKI for payment systems infrastructure to be adopted across the entire industry, but early adopters of this decentralised approach are already reaping the rewards.
Complex, operational processes are either entirely removed or significantly simplified with a DPKI for payment systems. This simplification reduces costs while at the same time, increases levels of security.
When we look at costs of keys alone, a decentralised approach demonstrates considerable cost savings. As the costs of creating, and securely distributing and sharing keys dramatically falls, the lifespan of a key can be changed. Typically, a key can cost
around £1,000 and as a result, most keys live for approximately 12 months in systems. Longer lived keys carry significantly more risk than keys that live for only a few hours.
Recently, I have been lucky enough to work with a DPKI for payment services implementation. Here, the cost of keys allows them to have a lifespan of just a few hours. The fully automated nature of the implementation means keys are created, issued, destroyed,
and replaced without any human processing at all, removing almost all the typical risks you associate with keys. In this DPKI for payment systems implementation, keys are truly bi-lateral, they deliver a secondary authentication point, so having messages signed
by these keys deliver not only a ‘Y’ security model, but a true end-to-end cryptographic capability, again something FMIs and central banks strive for.
Technology that enables
Within financial services, much is debated when it comes to blockchain technology, primarily because blockchain is almost exclusively discussed as a method for moving money or for the delivery of digital currency itself. Here, the blockchain is the perfect
technology to solve several significant and very real security problems. Here there is no debate regarding the value of the technology, rather the debate is how long will it take for the industry to catch-up and adopt?