The formal verification of Open Banking API presented in this work is based on a protocol verification methodology proposed in . The methodology utilises the Alice and Bob notation (AnB)  to specify a formal model of the protocol that can be formally verified through information flow (secrecy and authenticity) goals. Such notation abstracts from implementation details, but allows formal representation and analysis of the security-relevant characteristics of protocols.
An AnB specification comprises of several sections. The Types section declares the different identifiers used in the protocol. This includes the agents, constant and variable (random) numbers and transparent functions. Transparent functions are user-defined through their signature, thereby abstracting from their implementation details (i.e. they are uninterpreted). The Knowledge section describes the initial data each agent has before running the protocol. Fresh values are initialised at runtime. The information flow is described in the Actions section, where details about messages exchanged by agents are specified. Furthermore, the model can be used to verify specific security properties, such as (weak and strong) authentication and secrecy goals:
A weakly authenticates B on M: agent A has evidence that the message M has been endorsed by agent B with the intention to send it to A (i.e. non-injective agreement );
A authenticates B on M: weak authentication plus evidence of the freshness of the message M (i.e. injective agreement );
M secret between A, B: message M is kept secret among listed agents.
The formal model captures the protocol requirements . While the Open Banking API describes in details the information-flow, it lacks definitions of security goals that the exchanges between agents are meant to convey. Therefore, part of our work consisted in identifying suitable goals for the protocol model.
For the verification, we used the Open-Source Fixed-Point Model-Checker (OFMC) , a symbolic model-checker supporting the AnB notation. Moreover, the AnBx Compiler and Code Generator  was used to pre-process the model to benefit from a stricter type system and support the extension to AnB that allows named expression abstractions (Definitions section).
The goals we identified (and verified) are based on our understanding of the protocol and on its dependencies. For example, OAuth 2.0 security considerations [6, pp. 52–60], protocol use cases in [13, pp. 20–23] and our expectations of the protocol.
We identified eight goals: four on message secrecy, and four on authentication.
Two goals (G1 and G2) are obvious: the exchanged secrets/credentials between the AISP and PSU and the authorisation server remain secret whilst requesting for a client token (Action 2.1 in the specification) and acquiring consent authorisation (A3.1.2 and A3.3.3). That is because if the AISP credentials are leaked (A2.1), many attacks would be possible (for instance [6, Sect. 10.2] discusses client impersonation). Another secrecy goal (G3) states that various exchanged tokens (A2.2–A2.3 and A3.3.4–A4.1) remain secret between the AISP and the authorisation and resource servers. As tokens are AISP bound, a compromised token cannot be directly used. However, [6, Sect. 10.3] requires tokens to be confidential, to prevent attacks involving valid token injection [6, Sect. 10.12]. These goals clearly indicate the inherited potential vulnerabilities of the Account and Transaction Protocol (ATP) dependencies. The final secrecy goal (G7) is about the resource server message to the AISP (A4.2) and is obvious: account information must remain secret.
The authentication goals relate to the PSU authenticating the consent resource to authorise (G4), the resource server authenticating the PSU’s selected accounts information (G5) and the AISP authenticating the PSU’s account information from the resource server (G8). This last goal between the AISP and the resource server is crucial in verifying the integrity of the account data sent to the AISP by the resource server. In addition to direct data modification, it is important to verify that old data cannot be replayed. For instance, in the case of affordability check, if the PSU was an intruder and modified the data, they could trick an AISP into providing a product they are not eligible for. This goal also enforces fraud detection: if the transactional data can be modified by an intruder to hide fraudulent activity. Given the redirections from the PSU to the authorisation server and AISP (A3.1.1 and A3.3.1–A3.3.2), we weakly authenticate that those endpoints cannot be modified by an intruder to help avoid redirected URI manipulation [6, Sect. 10.6] and phishing attacks [6, Sect. 10.11] (G6).
Model Development. The Open Banking ATP is complex and with multiple dependencies. The AnB model aims to provide an abstract and accurate view of its essential aspects and to verify key properties. The initial AnB model was overly detailed with unnecessary data exchanges. To reach the right level of abstraction, we then decided to first determine the protocol goals prior to abstracting. Even after such endevour, verification was unwieldy: it ran for over two days without response. As is common within model checking problems, state explosion must be tackled beyond abstracting details, abstract on irrelevant data.
Restricting the role of the PSU, where it had to be different from the AISP and servers, considerably reduced the state space. This led to termination with goal verification to be reduced to about seven hours. This enabled us to identify further steps to abstract related to data, which reduced the verification time to about six minutes. A final abstraction, related to the various TLS-related steps, was to abstract them using AnB bullet channels, used to model channels providing authentication and/or secrecy properties at the end-points. The internal efficiency of OFMC dealing with such channels led the final version to verify within eight seconds. This exponential efficiency (up to 5 orders of magnitude) increase is not uncommon in model checking problems, so long the right abstractions are taken alongside expert knowledge of the tool’s implementation.
Model Correctness. We used the OFMC model checker  to verify the eight goals described above. At first, three goals (G4,G7,G8) about PSU intent authentication and account information secrecy and integrity failed. This led us to check these goals independently in order to study their reason for failure quickly. The witness for the PSU authentication failure (G4) relates to the resource server authenticating with an unknown agent rather than the PSU. This was fixed by having the resource server being aware of the PSU’s identity early on when setting up the access consent with the AISP (A3.2). Thus, this failure identifies a previously undocumented vulnerability, which our modification fixes.
The account information goals fail due to a limitation of bullet channels: they do not protect against replay attacks, hence their use here allowed breaking both secrecy (G7) and integrity (G8). The intruder could respond to the AISP’s request for account data by replaying a previous message. This breaks integrity as the response received by the AISP, and perceived to be the account data, has been modified. As the data replayed is known to the intruder, it also breaks secrecy of the account data. However, the TLS protocol does protect against message replay [4, pp. 93–94]. To deal with this limitation and ensure that freshness would resolve the issue, we modified the model to include a nonce generated and sent by the AISP when requesting for the PSU account data and is expected to be part of the response.
These modifications enable checking all goals for one session. Multiple sessions verification is important as there could be attacks relying on multiple concurrent protocol runs. Due to increased state space and limited hardware, we were unable to fully verify the model for two parallel sessions. As customary in under such conditions (e.g.  for iKP and SET), we were able to obtain partial results by increasing the search space up to the available resource limits (search space depth: 15 plies, 14.5 GB RAM, 50 h to run) without being able to reach any attack state.