Review of the Bank of Russia Standards. Security of financial (banking) operations

Ruslan Rakhmetov, Security Vision

In recent years, the Central Bank has paid special attention to financial technologies (fintech) as a source of increasing the competitiveness of the Russian payment space, developing internal competition, and improving the quality and security of services provided in the financial market. A number of fintech initiatives could not have developed without the active position of the mega-regulator for natural reasons, such as resource intensity, the scale of changes required and the resistance of certain groups of business participants. Examples include the creation of the Faster Payments System, the Digital Rouble, the Unified Biometric System and other fintech projects.

One of the Central Bank's important initiatives is the development of open banking, a concept that implies the use of open APIs (software interfaces) in banks in order to ensure competition at the ‘last mile’ to the customer. To be clearer, a customer will be able to use multiple services/applications to perform financial transactions, giving them access to their data at the bank. For example, to put an application, in fact, a universal client-bank, with the help of which he will be able to connect his accounts in different banks and manage his funds from one application, getting additional conveniences and advantages, for example, in the form of automatic selection of the most favourable method of payment for goods or independent choice of insurance when applying for a loan.

Obviously, this meets strong resistance from banks that develop their own applications and ecosystems and do not want to allow third-party services to reach their customers. Therefore, the regulator is currently working on standardising open APIs and initiating the creation of the relevant infrastructure (e.g. the creation of a certification stand on the basis of the FinTech Association). All these are preparatory measures for the introduction of this concept in the Russian payment space through mandatory requirements, following the example of the European Union with its Payment Services Directive, known as PSD2. Open APIs will push the development of innovation and digital technologies, providing the most personalised services possible through guaranteed access to infrastructure for financial service providers. Through such interfaces, banks, among others, will be able to interact with each other.

At the same time, all participants will ultimately benefit from the introduction of open APIs.

- Banks will get access to the latest technologies (they will be able to provide them to their clients), will be able to receive additional information about their clients.

- Fintech companies will get unification and reduced time to market for new products with the widest audience reach, will be able to focus on improving their solutions.

- Customers will receive new services, a reduction in their cost and an increase in quality and speed, and will be able to choose services and manage their data.

Starting from 2020, the Bank of Russia has issued a number of standards dedicated to open APIs. An important point in such interaction between parties in the provision of financial services is information security, which is also subject to standardisation. In the relevant section ‘Information Security’ of the Bank of Russia's website there is a number of standards dedicated to the security of open (externally accessible) APIs in the financial sphere, such as STO BR FAPI.PAOK-1.0-2021 ‘Security of financial (banking) operations. Application Programme Interfaces. Ensuring the security of financial services at initiation of OpenID Connect by the client of the authentication flow through a separate channel. Requirements ‘ dated 16.08.2021 and Standard of the Bank of Russia STO BR FAPI.SEC-1.6-2020 ’Security of financial (banking) operations. Application software interfaces for ensuring the security of financial services based on the OpenID protocol. Requirements ‘ dated 23.10.2020.

We will not retell the standard, but consider only the key features of the Bank of Russia Standard STO BR FAPI.SEC-1.6-2020 ‘Security of financial (banking) operations. Applied software interfaces to ensure the security of financial services based on the OpenID protocol. Requirements’ and requirements for the implementation of the applied technologies, which are the basis of the open API (OAuth 2.0, OpenID Connect).

At the very beginning of the document it is worth paying attention to the paragraph stating that the requirements of the standard are applied voluntarily, unless mandatory requirements are established by regulations of the Bank of Russia, which indicates the regulator's intention to gradually move to mandatory requirements, as stated earlier in the article. An important section is the part of the Standard containing references to existing regulatory requirements. Although some documents will soon become invalid (Regulation of the Bank of Russia No. 382-P dated 9 June 2012), it is clearly stated that it is necessary to analyse vulnerabilities in application software, ensure other legal requirements (protection of personal data) and use appropriate (threats and intruders) cryptographic information protection tools.

The rest of the content of the Standard is devoted to the security profile in the conditions of application of open APIs for access to services in different modes. But the following information security requirements/approaches should be noted throughout the document:

- Application of tokenisation. Provides replacement of critical authentication data with derived data (tokens) with certain characteristics to minimise risks in case of compromise.

- Use of TLS protocol for data transmission that provides encryption.

- Application of different authentication scenarios depending on the client's trust, i.e. taking into account the risks of information security allows to apply easier (more convenient) authentication methods or more reliable ones.

- Application of pre-registration of forwarding addresses on authorisation servers. This measure allows minimising the risks of using fraudulent services at certain steps of the process of gaining access to resources, due to the permissive maintenance of services for redirection.

- The redirection URIs (services accessible via them) must use the HTTPS protocol.

- Simultaneous application layer use of data encryption for confidentiality and signature for sender authentication.

- Requirements for the authorisation server to use countermeasures against cross-site request forgery (CSRF) and Clickjacking when communicating with the client.

- Recommendations for the use of single-use tokens and authorisation codes where possible, with appropriate checks implemented in software code.

- Application of short-term tokens and authorisation codes (limited in time of validity as much as possible).

- Tracking of errors in the use of tokens/authorisation codes, in particular the registration of repeated attempts to use them and, in particular, the implementation of appropriate revocation of all access tokens issued on the basis of a compromised authorisation code.

- Control by the client of the completeness of the specified parameters with refusal of processing in the absence of completion of mandatory parameters.

- Ignoring by the client (without returning codes) unrecognised response parameters.

- Control of the length of parameters by the client.

- Control of token timestamps (comparison of token creation time, validity period and current time).

- Notification of the resource owner when requesting long-term permission for client access to resources. Mechanisms for managing issued tokens (with partial revocation) must be provided.

- Application of TLS with mutual authentication of client and server, both using self-signed certificates and PKI.

- Exclusion of using the same key for both signing and encryption of data. Different keys for TLS and OIDC implementations should also be used.

- Timely decommissioning of cryptographic keys.

- Requirements for generating key information using an ACS.

- Realisation of the TLS protocol using modern (specific cryptonets are specified in the standard) RF cryptographic algorithms and certified ACS.

- Application of a persistent version of TLS version 1.2 and higher.

- Application of minimum length keys and token values with a certain entropy. In essence, these are the requirements for cryptography persistence and key information generation.

- Application of token binding technology to the TLS connection. A technological measure that ensures reconciliation of the channel owner and tokens.

Consider the following Standard of the Bank of Russia STO BR FAPI.PAOK-1.0-2021 ‘Security of financial (banking) operations. Application Programme Interfaces. Ensuring the security of financial services during the initiation of OpenID Connect by the client of the authentication flow through a separate channel. Requirements’. The peculiarity of the standard is presentation of requirements to authentication in conditions of risks of client use (for example, when using a public client) and application of a separate channel for authentication. In this standard, as well as in the first mentioned document, there is a section with reference to the same regulatory requirements, the only difference is that immediately emphasised the use of certified ACS and the fact that the class of ACS should be determined by the results of analysis of the system (which is a very non-trivial task in the conditions of participation in the process of many parties). In general, this Standard is a continuation (development) of the first Standard in the context of a more specific task and has the following features (requirements/approaches):

- Authentication over a separate channel is performed directly from the client to the authorisation server, without going through the browser.

- When accessing read-only services, TLS with mutual authentication of the parties is allowed, and when accessing for writing, TLS with two-party authentication is required.

- When a client accesses the authentication server, user identification information is transmitted to the authentication server. For example, user identification token, token defining user login or directly user login (login_hint).

- When communicating via a separate channel, the authentication server does not communicate with the user via the service access device.

- Depending on the risks, an additional user_code is available to eliminate the risk of authentication request requests for the end user by third parties knowing login_hint or other end user identifiers. The client requests a user_code from the end user for each authentication flow and does not need to store it.

- Registering a pre-allowed authentication method for the client.

- The value of the identifiers shall not indicate to the client a relationship to other data or be meaningful.

- Values for delays between requests, that is, the amount of time the client waits between polling requests to the token endpoint.

- Requirements for exceptions and error types, such as missing mandatory parameters, presence of invalid parameters, parameter repetitions (duplication), invalid values, identification errors, etc.

- Token scope control (assignment control).

- Requirements to support only confidential (trusted) clients for authentication flow over a separate channel.

- Requirement to match the level of user authentication with the level of operations performed (the more critical the operation and the greater the risks, the stricter the authentication should be).

- Reliable transmission of tokens and other sensitive information between the authentication device and the end user's access to services.

- Requirements to control (monitor) the authentication spoofing attack on a separate authentication stream parallel to the main stream.

An interesting point is the requirements for the use of domestic encryption systems - now these are optional standards, but it is likely that in the future we will see a mass transition of the financial industry to the use of GOST TLS as a continuation of the vector of import substitution in the credit and financial sector. We would also like to note the wide opportunities for building event monitoring and appropriate response processes. In any case, the implementation of secure open APIs will have a great positive effect on the market, but strict control of security requirements and certification of solutions presented to the market is necessary.