...

2. Overview

The Central Bank of Bahrain (CBB) has worked with experts to develop rigorous security specifications for the wider Open Banking ecosystem. This document This chapter covers the key considerations of security that would be essential from an Open Banking ecosystem and applicable to ASPSPs and AISPs/PISPs.

The CBB Rulebook and the Personal Data Protection Law (PDPL) provide PDPL provides direction on multiple internal security controls, processes and rules for adherence by ASPSPs and AISPs/PISPs. The objective of this document the chapter is to provide additional guidance and best practices on leveraging globally accepted and widely adopted security standards to help create a more robust/secure Open Banking ecosystem in Bahrain. 

All requirements and best practices stated in this document are in addition to existing rules and guidelines set by the CBB and the PDPL. In all cases, external assurance and certification of the Information Security adherence is preferable to self-certification.

...

•  Accurately evaluate organisational ability to defend against the attack

• Obtain the detailed information on actual, exploitable security threats

• Intelligently prioritise remediation activity, apply necessary security patches and allocate security resources

...

Further, penetration and vulnerability testing may be additionally conducted by AISPs/PISPs/ASPSPs based on the Open Banking release cycle, i.e. every time a major release related to the entities entity's OB systems, and any minor release that may potentially directly impact/expose any sensitive or personal data of users/customers.

...

All participants must implement the Open Banking security aspects of the API specification, including authentication, authorisation, access levels and , permission and encryption. The following API security specifications leverage the OpenID foundation’s financial API (FAPI) to read and write an API security profile. This specification is published on the OpenID Foundation website at - openid.net. (OpenID Foundation, a non-profit international standardisation organisation of individuals and companies committed to enabling, promoting and protecting OpenID technologies, is working to ensure that the profile is maintained as a world-class security standard which provides the very best protection available for all users/customers.).

The This section covers Open Banking security aspects of the API specification, including:

• Authentication and Authorisation

• Data Encryption

• Fraud detection Detection and monitoringMonitoring

 4.1 Authentication and Authorisation

The process through which a user/customer authenticates itself to its data attribute provider or ASPSP (in order to further authorise a third party access) will be a tripartite process and should be designed to minimise digital friction. Specifically:

• Data attribute providers or ASPSPs should retain control over authentication method

• All authentication and authorisation protocols must adhere with OAuth 2.0 and OpenID Connect

Once a user/customer has authenticated with their data attribute providerASPSP, tokens should be used to ensure the third party is acting within the bounds of the permissions granted. The third-party service should provide evidence that it is entitled to use the authorisation token (e.g. by way of providing a client ID and client secret) to the data attribute providerASPSP.

Each data attribute provider ASPSP will be responsible for issuing its own tokens and ensuring third parties are in possession of legitimate tokens.

...

• The OAuth 2.0 authorisation framework enables a third-party application to obtain limited access (i.e. set scope) to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its behalf. This specification replaces and obsoletes the OAuth 1.0 protocol

• OAuth 2.0 provides delegated authorisation workflows for diverse applications such as web applications, desktop applications, mobile phones and home automation devices while providing a simple platform for developers to harness

• In an OAuth based authorisation, a consumer requests access to resources under the control of a resource owner. For accessing these resources, the consumer is provided a different set of credentials

• This can be used for accessing the APIs from multiple devices including mobile apps, desktops, etc.

• Further details on the OAuth 2.0 specifications can be found on their website

...

• OpenID Connect (OIDC) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of simplifying things and works over the existing HTTP standard

• OpenID Connect enables developers to create an authentication mechanism across websites and applications without creating a separate username/ password file combination of their own

• OpenID has the capability to manage multiple types of clients including browser based JavaScript and native mobile applications. Apps designed using OpenID are able to utilise sign-in workflows and receive confirmable assertions about the identity of the user . (Identity, Authentication + OAuth 2.0 = OpenID Connect)

• This can be used for accessing the APIs from multiple devices including mobile apps, desktops, etc. in a manner similar to how Google/Facebook single sign on works across other websites. This can be modified to include the UID as the access token against which an individual or an organisation can be authenticated

• Further details on the OIDC specifications can be found on their website

...

Part 2: Read and Write API Security Profile

4.2 Data

...

Encryption

API connections and data in transit should be encrypted to ensure that all data in transit is safe and secure.

...

• TLS was designed with the goal of providing privacy and ensuring data integrity between two communicating applications

• This has two layers:

  • The first layer uses the TLS Record Protocol to encapsulate other higher level protocols

  • The second layer uses the TLS Handshake Protocol which allows the server and client to authenticate each other. The protocol allows negotiation and agreement of a cryptographic algorithm and keys prior to transmission or receipt of any data

• This is a basic level of security which that rides on the TCP protocol and HTTPS. All RESTful APIs by default are created to use this as an encryption mechanism

While the participants are required to adhere to TLS 1.2 MA, additionally they might consider adopting the latest available TLS version.

In order to achieve full FAPI compliance, all Open Banking stakeholders may run an additional layer of AES 128/256-bit encryption of signatures.

The Industry stakeholders may also further consider non-repudiation of messages using digital signatures, and explore the usage and adoption of streaming APIs[1] for reading data, especially for AISP related use cases.

Note: The APIs require TLS 1.2 Mutual Authentication and this may be used as a means of non-repudiation. However, it would be difficult to maintain digital records and evidence of non-repudiation if the API only relied on TLS 1.2. A solution for non-repudiation that does not rely on TLS, would be achieved by providing a JWS with detached content (as defined in RFC 7515 - Appendix F) in the HTTP header of each API request. The HTTP body would form an un-encoded payload as defined in RFC 7797. The JWS would be signed using an algorithm that supports asymmetric keys. A request would be signed by an AISP’s/PISP’s private key and a response would be signed by the ASPSP's private key. Digital signatures are used to provide non-repudiation and authenticity by using public key algorithms. Private and public key is used to encrypt/decrypt the hash of the content. Encrypted The encrypted hash is called a digital signature. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. The certificate is digitally signed by the trusted Certificate Authority (CA) – the hash of the certificate is encrypted with the private key of the trusted CA.

...

[1] Streaming APIs enables a subscription for receiving events in near real time using push technology. Streaming APIs invert the conversational nature of REST and enables the ASPSP server to send information to an AISP/PISP when an update is ready. While the AISP/PISP can, in theory, request an update, the streaming server of the ASPSP should pre-empt this with updates as ready. Streaming API reduces the load on the system by reducing the number of API calls thereby improving performance.

4.3 Fraud

...

Detection and

...

Monitoring

In addition to the counter fraud function, all participants must include completed risk indicators within their payload to facilitate strong security across the Open Banking ecosystem and aid fraud detection and prevention.

• The API must provide support for out-of-band (OOB) authentication:

  • Out-of-band (OOB): Out-of-band authentication is a type of authentication that requires a secondary verification method through a separate communication channel along with the typical ID and password. Using a separate authentication channel makes it significantly more difficult for an attacker to intercept and subvert the authentication process

  • Forms of OOB authentication include codes sent to a mobile device via SMS, authentication via a voice channel, codes sent to a mobile app via push notifications, and codes sent to or received from a trusted execution environment connected to the host device that is trying to establish an authenticated connection

  • Out-of-band OOB is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity "Examples include secure authenticator mobile applications"

• ASPSPs must notify the user/customer asynchronously/OOB when significant actions have occurred (e.g. a change to a payee)

• The ASPSP API response should inform the third party that an OOB process is underway so that, where appropriate, they can inform the user/customer

• ASPSP and AISP/PISP should include fraud-relevant information (e.g. IP addresses, Geo locationGeolocation) in the API messages

• The reporting of incidents and the process to handle it shall be covered as per the existing guidelines related to cyber risk in the CBB Rulebook

...