• Docs »
  • Security »
  • Data in Transit Encryption

Security - Data In Transit Encryption

Overview
This document describes the end-to-end data-in-transit encryption mechanism followed by Onemoney. Onemoney is the Account Aggregator application (mobile app and web app) of Finsec AA Products and Solutions India Pvt Ltd.
Financial Information Users (FIU) connects to Onemoney to receive information about consents provided by its consumers and use the same to request data through the Onemoney from the Financial Information Providers (FIP) that manage the consumer’s financial accounts.
Financial Information Providers (FIP) connects to Onemoney to receive information about consents provided by its consumers (parties that have accounts with them). When FIUs request data through Onemoney, FIP Gateway connects to the FIP’s systems to fetch the requested data and transmit the same securely and in the right format.
All communication involving exchange of consent information and financial data is always through an Account Aggregator (like Onemoney).

TERMS

Public Keys

  • FIU Key Pair – an ephemeral Curve 25519 key pair generated by the FIU while sending a request for data. The public key of this pair is included in the request.
  • FIP Key Pair – an ephemeral Curve 25519 key pair generated by the FIP while sending data in response to an FIU’s request. The public key of this pair is included in the FIP’s response.
    By using the same Curve type, the FIU and FIP generate Diffie Hellman (DH) key pairs that are mutually agreeable.

Shared Keys

  • FIP Shared Key – a secret value generated by the FIP using an Elliptic Curve Diffie Hellman (ECDH) function using the FIU’s public key received in the data request.
  • FIU Shared Key – a secret value generated by the FIU using an Elliptic Curve Diffie Hellman (ECDH) function using the FIP’s public key, received in the FIP’s response.

Nonces

  • FIU Nonce - a 256-bit random value sent to the FIP as part of the data request.
  • FIP Nonce - a 256-bit random value generated by the FIP while sending data in response to the FIU’s request.

The two nonce values are used by the FIP to generate a Salt that is used in the algorithm to generate the session key used for encrypting the data.

The same two nonce values are also used by the FIU to generate a Salt that is used in the algorithm to generate the session key used for decrypting the data received.

Signatures

  • Sig (f) – A SHA-256 Hash value computed by the FIU on the contents of its data request
  • Sig (A) – A SHA-256 Hash value computed by the AA on the contents of its message sent to an FIP, after verification of the data request received from the FIU.
  • Sig (p, M) – A SHA-256 Hash-based Message Authentication Code (HMAC) generated on the contents of the message sent by the FIP in response to the FIU’s data request.

INITIATING A DATA REQUEST
Upon receiving approval for the consent sought from the consumer via a consent artefact sent by the AA (Account Aggregator), an FIU may initiate a Data Request. The Data Request comprises the details of the consent and key material that is to be shared with the FIP to encrypt the data sent in response. The Data Request is digitally signed by the FIU.
The steps followed to generate the key material are -
1. The FIU generates an ephemeral Curve 25519 Key Pair comprising the FIU Public Key and the FIU Private Key. These keys are valid only for one data exchange session.
2. The FIU generates a 256-bit nonce.
3. The FIU combines the FIU Public Key, the nonce and the Curve name along with the consent details into a Message.
4. The FIU then generates a SHA-256 Hash of the Message and attaches that as the Digital Signature - Sig (f) – while transmitting the data request to the AA.
5. In addition, the FIU appends its permanent digital signature before transmitting the request to the AA.

VERIFYING THE DATA REQUEST
Upon receiving the data request from the FIU, the AA is expected to verify the Digital Signature – Sig (f), before signing the request itself and forwarding it onward to the FIP.
The steps expected to be implemented by any AA for data request verification are as follows -
1. The AA first verifies the identity of the FIU by comparing its permanent digital signature with what is stored in the Central Registry.
2. On successful verification, the AA extracts the Message from the Data Request received from the FIU.
3. The AA then generates a SHA-256 Hash of the Message.
4. It then compares the generated Hash with the Sig (f) received as part of the data request.
5. On receiving an exact match, the AA generates a SHA-256 Hash of the entire contents of the message to be forwarded to an FIP. This is the AA’s Digital Signature and is termed Sig (A).
6. The AA appends its Digital Signature Sig (A) to the contents received from the FIU.
7. It then signs the entire contents with its permanent Digital Signature and transmits the message to the FIP.

SENDING DATA IN RESPONSE
Upon receiving the forwarded data request from the AA, the FIP verifies the identity of the AA and then generates a session key using the key material sent in the data request from the FIU. This session key is used by the FIP to encrypt the financial data sent in response to the FIU’s data request. It also sends key material that is needed by the FIU to generate a “shared” session key, which it uses to decrypt the data sent by the FIP.
The steps followed by the FIP are -
1. The FIP verifies the identity of the requesting AA by comparing the permanent Digital Signature received with what is stored in the Central Registry.
2. On successful verification, the FIP verifies that the Curve type followed by the FIU to generate its public-private key pair is Curve 25519.
3. On successful verification, the FIP generates an ephemeral Curve 25519 Key Pair comprising the FIP Public Key and the FIP Private Key. These keys are valid only for the current data exchange.
4. The FIP generates a 256-bit nonce.
5. The FIP then computes a “secret”, also known as a “shared key” using an ECDH function that takes the FIU Public Key as the input.
6. The FIP then generates a Salt using the FIU Nonce and the FIP Nonce as inputs.
7. Using the Shared Key and the Salt, the FIP uses an HMAC-based Key Derivation Function (HKDF) to generate a 256-bit session key.
8. With the session key generated, the FIP uses an AES-256bit–GCM (Galois Counter Method) algorithm to encrypt the financial data to be sent.
Note: There is no initialization vector (iv) supplied to the encryption function. It is assumed that the FIU will also not use any iv to decrypt. 9. In order to sign the encrypted data and the key material, the FIP generates a SHA-256 Hash using the 256-bit session key as an input. This signature is termed Sig (p, M).
10. The FIP signs the entire message with its permanent digital signature and transmits the message to the AA.

VERIFYING THE DATA RESPONSE
Upon receiving the data response from the FIP, the AA is expected to verify the FIP’s permanent digital signature before signing the request itself and forwarding it onward to the FIU.
The steps expected to be implemented by any AA for data response verification are as follows -
1. The AA first verifies the identity of the FIP by comparing its permanent digital signature with what is stored in the Central Registry.
2. On successful verification, it then signs the entire contents with its permanent Digital Signature and transmits the same onward to the FIU.

DECRYPTING THE DATA RECEIVED
Upon receiving the FIP’s message from the AA, the FIU verifies the identity of the AA. On successful verification, the FIU generates the “shared key” (the “secret”) by using the key material received in the message. This is further used to generate the same session key that was used by the FIP to encrypt the data. The session key is then used by the FIU to decrypt the data.

The steps followed by the FIU are -
1. The FIU compares the permanent digital signature of the AA in the message received with that stored in the central registry.
2. On successful verification, the FIU extracts the FIP’s public key from the key material sent in the message. Using the same ECDH instance that it used to originally create its own DH key pair (while sending the data request), the FIU computes the “secret”, also known as the “shared key”.
3. The FIU then generates a Salt using the FIU Nonce and the FIP Nonce as inputs.
4. Using the Shared Key and the Salt, the FIU uses an HMAC-based Key Derivation Function (HKDF) to generate a 256-bit session key. This session key will have the same value as what was used by the FIP to encrypt the data.
5. Using the session key, the FIU implements an AES-256 bit-GCM algorithm to decrypt the financial data received.
Note: There is no initialization vector (iv) supplied to the decryption function. It is assumed that the FIP will also not use any iv to encrypt.

Conclusion
The data exchange between an FIU, the AA and the FIP is encrypted end-to-end while it is in transit. The Diffie Hellman protocol ensures a way for the two parties, i.e. the FIU and the FIP, to use a shared secret, which is ephemeral in nature, i.e. is valid only for the current exchange session. In addition to the shared secret, the usage of two nonces generated at each end to derive the session key ensures perfect forward secrecy, i.e. even if keys used are known to a third party, the third party cannot use it to decrypt any previously exchanged data.