PSD2 and the need for common security standards

Roderick Hodgson, Secure Chorus: “We need common security standards”

Roderick Hodgson, director, Secure Chorus, explains why we need common standards for secure data exchange and robust authentication of payment services providers’ (PSPs) interfaces to support the introduction of the revised Payment Services Directive (PSD2).

PSD2 came into force on the 13 January 2018. It was designed to address the legal uncertainty and new security risks originating from the rapid growth of fintech and the development of new business models for payment services providers, as well as the geographical expansion of digital payment services beyond national markets into EU-wide markets.

A key point of focus of PSD2 is the requirement for banks to open their IT infrastructures to third-party PSPs, such as small-to-medium fintech innovators providing services to aggregate financial data or perform payment instructions on behalf of consumers. This has caused significant concern in the banking industry, with many seeing this change as exposing the financial services market to systemic risk.

PSD2 includes the requirement for the development of the regulatory technical standards (RTS). The RTS define the requirement for banks to provide “interfaces” through which a third-party PSP can authenticate and retrieve data, or instruct a bank. The RTS also require PSPs to ensure this data exchange is secure, and that robust authentication methods are used between interfaces, making use of open standards of communication.

The RTS further require PSPs to ensure they can appropriately monitor, assess and audit their cybersecurity capability. Finally, they set out requirements regarding traceability, record-keeping and logging of transactions. At the same time, EU General Data Protection Regulation (GDPR) must be followed, bringing with it the obligation for PSPs to give data subjects access to their data.

The European Banking Authority (EBA), which had been commissioned under the PSD2 to develop the RTS, decided not to mandate a specific technology, to ensure technology and business-model neutrality and innovation. However, this lack of concrete guidance presents a challenge for banks and third-party PSPs, which need to implement the RTS by the deadline.

The RTS have been finalised and are now in force as of the 14 March 2018. All banks and third-party PSPs will have to implement the required security measures by the 14 September 2019, when the 18 month transition period ends and obligations of the RTS will apply.

In a closed environment such as the security perimeter of an organisation, securing sensitive data may be relatively straightforward. However, in the payment services market environment where PSPs share data through interfaces, namely outside the security perimeter of each PSP, there are issues of interoperability and the privacy of data. All of this is compounded by the need to ensure the PSPs sending or receiving the data via these interfaces are those who are authorised to do so.

It is therefore important for the payment services market to agree open standards of communication that ensure interfaces are secure, auditable and interoperable by design to facilitiate compliance of all actors with the RTS.

Secure Chorus is a government backed, not-for-profit membership organisation, which serves as a platform for multi-stakeholder collaboration for the development and adoption of common standards to enable the development of secure and interoperable data processing technologies, namely Secure Chorus Compliant Products.

Secure Chorus’ cryptography standard of choice – MIKEY-SAKKE – is a cutting-edge open cryptography protocol, designed for relevant enterprises to enable secure, cross-platform multimedia communications.

MIKE-SAKKE uses an identity-based public key cryptographic (IDPKC) approach, which can provide an effective solution to addressing the requirements of the RTS for open standards of communication that provide for secure data exchange and robust authentication between interfaces.

IDPKC can protect data by providing end-to-end encryption, where encryption keys are directly associated with a consumer’s identity, while also providing authentication of the PSPs from which the data has originated. The interfaces of PSPs, which adopt an IDPKC approach, would enable secure and authenticated communication with each-other by simply exchanging a single piece of data on a regular (typically monthly or yearly) basis: the public keys of their respective key management servers (KMS). It is therefore highly scalable, requiring no prior setup between users or distribution of user certificates.

The RTS mandate the use of qualified certificates to ensure a PSP can be appropriately identified. Certificates can be very effectively combined with an IDPKC approach. Instead of PSPs having to manually exchange public key material with one-another, certificates provide a method for disseminating the public keys of the Key KMSs of each PSP. By issuing certificates, a trust service provider (TSP) can provide assurance that these KMS keys are directly associated with the PSP.

Regarding the RTS requirement for open standards of communication that would provide for auditability of the technology systems used by the PSPs, MIKEY-SAKKE allows a PSP to have full control of its security system, offering strong traceability and auditability capabilities.

Since the specifications of MIKEY-SAKKE are known and open, it is possible for anyone to assess that the technology meets the desired security requirements. As such, Secure Chorus Compliant Products would help PSPs overcome the challenge of meeting current compliance levels and as outlined in the RTS.

Secure Chorus’ interoperability standards would also be able to ensure secure data exchange within the security perimeter of a PSP and beyond. This would be achieved by having the relevant technologies underpinning the PSPs’ interfaces adopt MIKEY-SAKKE, which would then allow the development of common interoperability standards to ensure each PSP’s interface can interoperate with any other.

MIKEY-SAKKE could be therefore considered as the potential standard of choice for PSPs, given that it has been standardised in the Internet Engineering Task Force (IEFT) and has recently been approved by 3rd Generation Partnership Project (3GPP) for use in mission-critical applications, such as emergency services communications. Emergency Services are complex multi-actor environments; hence provide for a good comparative user case with PSPs.

Deploying Secure Chorus’ interoperability standards in the financial services market would ensure all interfaces interoperate, while its cryptography standard of choice would ensure that data is securely processed both at rest – addressing the record-keeping requirements of the PSD2 – and in transit, ensuring the PSD2’s requirement for secure transmission of user credentials. Furthermore, thanks to the fact that organisations can manage their own KMS, banks and third-party providers would have full control of their security system, delivering strong traceability and auditability capabilities.