NBFC-AA: Security Overview 1. Abstract 2 2. NBFC-AA: Financial Information Security 2 2.1. Security Objective 2 2.2. NBFC-AA Encryption Overview 3 2.2.1. Key Generation 3 2.2.2. Encryption of data in transit 4 3. Implementation Standard Guidelines 7 4. An Example of API Interaction for E2EE 8 4.1. Request for Accessing FI Data 8 4.2. Request for fetching the FI Data 10 5. References 14 Acronyms AA Account Aggregator FIU Financial Information User FIP Financial Information Provider AES-GCM Advanced Encryption Standard with Galois/Counter Mode (GCM) for authenticated encryption HMAC A hash based MAC algorithm HKDF Hashed Message Authentication Code (HMAC)-based key derivation function DH Diffie Hellman ECDH Elliptic Curve Diffie Hellman 1. Abstract Account Aggregator (AA) is an entity that performs financial information aggregation by storing user’s consent and communicating the information flow between Financial Information User (FIU) and Financial Information Provider (FIP). This document provides technical details about the communication protocols and encryption algorithms integrated into NBFC-AA technical specification. This document describes an end-to-end encryption mechanism for secure sharing of financial information in NBFC-AA. 2. NBFC-AA: Financial Information Security 2.1. Security Objective Security requirements Description Crypto techniques Confidentiality Financial information is kept secret from all but authorized FIU. Symmetric key crypto- AES-GCM Authentication Each participating entity in NBFC-AA ecosystem is authentic. Hash, HMAC, Digitally Signed API call, Digital Signature Integrity Messages have not been modified during transit or at rest. Hash, HMAC, Signature Non-repudiation The participating entities in NBFC-AA ecosystem cannot deny their actions after performing the operations. Asymmetric key crypto, Signature Revocation The user can dismiss the authorization on financial information by consent revocation through AA. HKDF, Revocation list (RL) Anonymity The AA should enable that User-aware consent FIP is not aware of the identity of FIU and vice versa transformation Forward Secrecy NBFC-AA ecosystem should protect historical information against future compromises of secret keys or passwords. HKDF, Ephemeral DH keys, Nonce 2.2. NBFC-AA Encryption Overview 2.2.1. Key Generation Key generation algorithm enables the user or FIU to access the encrypted financial information by establishing the session key and calculating the symmetric encryption key. In order to get access to the encrypted data, FIU application or AA client (installed in customer device) generates ECDH key pair and saves it securely in the application’s private storage area. A consent artifact is generated so as to authorize access to the financial information for the FIU. To generate a DH public/private key pair (dhsk(U), dhpk(U)), FIU picks a set of Diffie-Hellman (DH) parameters over Curve25519 [ add reference ]. Similarly, FIP also calculates the DH public/private key pair (dhsk(P), dhpk(P)) over the FIU selected Diffie-Hellman (DH) parameters for generating the session key and the encrypted key. In this process, FIU first selects the parameters from Curve25519 [ https://tools.ietf.org/html/rfc7748 ] and sends it to the AA. NBFC-AA encryption protocol supports forward secrecy by generating a new set of key agreement of parameters for each session. These parameters can never be reused and never be stored. 1. Permanent public/private key pair generation: A Certifying Authority (CA) issues a permanent public/private key pair to the AA, FIU, and FIP. AA server and FIU server initialize their application with the permanent public key at the time of installation in the device of the user and store the private key in the private storage of the server. AA server, FIU server, and FIP request to the CA for generating the permanent public/private key pair to achieve the undeniability and non-repudiation properties by generating the digital signature. a. AA public/private key pair: AA server has a public key pk(A) and private key sk(A) generated by the CA. b. FIU public/private key pair: FIU server has a public key pk(U) and private key sk(U) generated by the CA. c. FIP public/private key pair: FIP server has a public key pk(P) and private key sk(P) generated by the CA. 2. Session initiating public/private key pair generation: a. Customer public/private key pair: AA application selects the random number dhsk(C) and calculates dhpk(C)= dhsk(C) P, where dhsk(C) is the private key and stores it in a private storage environment of the customer, dhpk(C) is the public key, and P is the generator of the curve. b. FIU public/private key pair: FIU selects the random number dhsk(U) and calculates dhpk(U)= dhsk(U) P, where dhsk (U) is the private key, dhpk(U) is the public key, and P is the generator of the curve. c. FIP public/private key pair: FIP selects the random number dhsk(P) and calculates dhpk(P)= dhsk(P) P, where dhsk(P) is the private key, dhpk(P) is the public key, and P is the generator of the curve. Key Name Minimum Key Size Description dhpk(u) 256 bit FIU generates the public key for Diffie-hellman key exchange. dhsk(u) 128 bit FIU generates the private key for Diffie-hellman key exchange. rand(u) 256 bit A random number generated by FIU. dhpk(p) 256 bit FIP generates the public key pair. dhsk(p) 128 bit FIP generates the private key pair. rand(p) 256 bit A random number generated by FIP. dhk(U,P) 128 bit DH shared key sk(u,p) 256 bit A generated session key used for encryption and decryption of the FI. Summary of Key information 2.2.2. Encryption of data in transit In this case, the FIU initiates the data flow via AA by requesting for one-time FI or periodic FI data access. One-time/periodic data fetch: FIU (u) FIP (p) 1. Initialization Algorithm: FIU executes DHParamasAlgo() and 7. Verification algorithm: a. On receiving the sig(a) and the message generates the domain parameter dh_params as follows: a. The prime P that specifies the size of the field b. The coefficients a and b of the elliptic curve equation. c. The base point G that specifies the group. d. The order n of the group e. The cofactor b of the subgroup 2. Generates DH key pair: Executes the GenerateDHKeyPair() algorithm to generate the DH public/private key pair as follows: dhpk(u)=dhsk(u) G where dhpk(u) is the DH public key and dhsk(u) is the DH private key. 3. Generates a 256-bit random nonce: Executes the GenerateRandomNonce() algorithm to generate a 256-bit random number rand(u) 4. Constructs the message (M , conset_artefact) , where M is (dh_params, dhpk(u), rand(u)). 5. Generates the signature by executing the SignatureGeneration() on the inputs of the message (M , conset_artefact) 6. Sends the sig(f) and the message (M , conset_artefact) to the AA (M , conset_artefact) , where M is (dh_params, dhpk(u), rand(u)), the FIP executes the SignatureVerification() to verify the signature. b. Check if the DH parameters are agreeable. c. Check consent artifact is valid or not. 8. If DH parameters are not agreeable, then a. FIP picks a new set of DH parameters by executing DHParamasAlgo() b. Executes the GenerateDHKeyPair() algorithm to generate the DH. public/private key pair as follows: dhpk(p)=dhsk(p) G where dhpk(p) is the DH public key and dhsk(p) is the DH private key. c. Generates a 256-bit random nonce: Executes the GenerateRandomNonce() algorithm to generate a 256-bit random number rand(p) d. Sends the message ( M, signature (p,M), certificate(p), where M=(new_param, dhpk(p), rand(p). 9. If DH parameters are aggregable, then P generates the DH key pair in the same group by executing the GenerateDHKeyPair() as follows: dhpk(p)=dhsk(p) G where dhpk(p) is the DH public key and dhsk(p) is the DH private key. 10. Generates a 256-bit random nonce: Executes the GenerateRandomNonce() algorithm to generate a 256-bit random number rand(p) 11. Generates the DH shared key dhk(u,p) by executing the DHSharedKeyAlgo(). dhk(u,p)= DHSharedKeyAlgo(dhpk(u),dhsk(p)) 12. Generates the 256-bit session key sk(u,p) ( encryption key) by executing the GenerateSessionKeyAlgo(). AA: Executes the SignatureVerification() to verify the signature on the input of sig (f) and the message (M , conset_artefact). 1. If the signature verification returns true, then accept the message and forward it to the FIP along with the signature. 2. Otherwise, reject the message and sig(f) and notifies the error to the FIU. After receiving the Message ( M, signature (p, M), certificate( p)), where M=(OK, dhpk(p), rand(p), C). The FIU executes the following steps: 16. FIU first verifies the signature of AA and extracts the data from the API. 17. FIU verifies the signature of FIP by executing the SignatureVerification() algorithm on the input of the Message ( M, signature (p, M), certificate( p)) 18. Generates the DH shared key dhk(u,p) by executing the DHSharedKeyAlgo(). dhk(u,p)= DHSharedKeyAlgo(dhsk(u),dhpk(p)) 19. Generates the 256-bit session key sk(u,p) ( encryption key) by executing the GenerateSessionKeyAlgo(). sk(u,p) = GenerateSessionKeyAlgo( HKDF(dhk(u, p), rand(u), rand(p)) ) sk(u,p) = GenerateSessionKeyAlgo( HKDF(dhk(u,p), rand(u), rand(p)) ) In the above process, HKDF cryptographic standard is used to generate the session key sk(u,p). 13. The session key sk(u,p) (or encryption key) is used to encrypt the xml format FI data by executing FIDataEncrypt() algorithm and generate the ciphertext (C) as follows: C= FIDataEncrypt( AES_GCM(FI_data, sk(u,p)) ) 14. Constructs the Message ( M, signature (p, M), certificate( p)), where M=(OK, dhpk(p), rand(p), C) Here, the signature(p,M) uses the Encrypt-then-MAC method to generate the signature and AES-GCM encrypting standard used for encrypting the FI data. 15. Sends the Message ( M, signature (p, M), certificate( p)), where M=(OK, dhpk(p), rand(p), C) to the AA. The AA forwards it to the FIU after verifying the signature of FIP. In the above process, HKDF cryptographic standard is used to generate the session key sk(u,p). 20. Decrypt the FI data by executing the FIDataDecrypt() algorithm. FI_Data= FIDataDecrypt(AES_GCM(FI_data, sk(u,p)) 3. Implementation Standard Guidelines The following cryptographic primitives are used to perform the end-to-end encryption (E2EE) In Account Aggregator ecosystem. 1. Diffie-Hellman (DH) initialization parameters DHE will be performed over Elliptic Curve Cryptography (ECC) groups. We recommend the use of Curve25519, which is used in DHE implementations in a lot of protocols like SSH and WhatsApp [5]. 2. ECDH (Elliptic Curve Diffie Hellman) algorithm -- To establish the secret key--- 3. HKDF (Hash-based-extractor and expand Key Derivation Function) -- Key derivation hash function -- 4. Establish Session Key: 5. Encryption using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM): 6. Signature Algorithm: The main cryptographic algorithms can be considered for implementing the Consent based Secure Financial Information Sharing are listed in the following table. Algorithms Implementation Standards Elliptic Curve Diffie Hellman (ECDH): 1. Parameters Initialization Standard a. Selects elliptic curve: Curve25519 [5] [6] [7] [8] ECDH P-25519 Cryptographic primitives used in NBFC-AA Implementation Standards Hash-based-extractor and expand Key Derivation Function (HKDF) (Optional) 1 H-MAC based HKDF [10] Message Hash function SHA-256 , HMAC-SHA256 Encryption using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) AES-128-GCM 4. An Example of API Interaction for E2EE An FIU or customer make a request to the FIP for accessing the financial information via submitting a FI request to the AA by calling POST /FI/Request. 4.1. Request for Accessing FI Data Account Aggregator API 1. POST /FI/Request { "ver" : "1.0" , "timestamp" : "2018-12-06T11:39:57.153Z" , "txnid" : "e8cc6822-d4bb-4eb1-9e1b-4996fbff8acb" , "FIDataRange" : { "from" : "2018-12-06T11:39:57.153Z" , "to" : "2019-12-06T11:39:57.153Z" }, "Consent" : { "id" : "654024c8-29c8-11e8-8868-0289437bf331" , "digitalSignature" : "Digital signature of the consentDetail section in the consent Artefact" }, "KeyMaterial" : { "cryptoAlg" : "ECDHE" , 1 https://tools.ietf.org/html/rfc5869 "curve" : "Curve25519" , "params" : "string" , "DHPublicKey" : { "expiry" : "2018-12-06T11:39:57.153Z" , "Parameters" : "string" , // DHPubicKey "KeyValue" : "string" // dhpk(u) }, "Nonce" : 0 , "Signature" : "Signature as defined in W3C standards; Base64 encoded" } } Response: { "ver": "1.0", "timestamp": "2018-06-09T10:05:50.505Z", "txnid": "c4a1450c-d08a-45b4-a475-0468bd10e380", "consentId": "654024c8-29c8-11e8-8868-0289437bf331", "sessionId": "caa2f259-2dc2-4075-87aa-6d81018b6183" } FIP API 2. POST /FI/Request Model { "ver" : "1.0" , "timestamp" : "2018-06-09T09:58:50.505Z" , "txnid" : "c4a1450c-d08a-45b4-a475-0468bd10e380" , "Consent" : { "id" : "654024c8-29c8-11e8-8868-0289437bf331" , "digitalSignature" : "Digital signature of the consentDetail section in the consent Artefact" }, "FIDataRange" : { "from" : "2018-11-27T06:26:29.761Z" , "to" : "2018-12-27T06:26:29.761Z" }, "KeyMaterials" : { "cryptoAlg" : "ECDHE" , "curve" : "Curve25519" , "params" : "string" , "DHPublicKey" : { "expiry" : "2019-06-01T09:58:50.505Z" , "Parameters" : "string" , // DHPubicKey "KeyValue" : "string" // dhpk(u) }, "Nonce" : 0 , "Signature" : "Signature of AA as defined in W3C standards; Base64 encoded" } } Response: 200 Ok { "ver" : "1.0" , "timestamp" : "2018-06-09T10:05:50.505Z" , "txnid" : "c4a1450c-d08a-45b4-a475-0468bd10e380" , "consentId" : "654024c8-29c8-11e8-8868-0289437bf331" , "sessionId" : "caa2f259-2dc2-4075-87aa-6d81018b6183" } 4.2. Request for fetching the FI Data FIP API This API is used to fetch the financial information from the FIP against a given SessionId. It is called after the AA has received the <FI-Ready> notification from the FIP. GET /FI/fetch/{SessionId} Parameters Name Description sessionId * string (path) Session ID for the FI Request Session fipId string (query) FIP ID as defined in the Account Aggregator Ecosystem. Maximum 1. linkRefNumber array[string] (query) linkRefNumber/s for the accounts to be fetched from particular FIP. Supports more than 1. Response: 200 OK { "ver" : "1.0" , "timestamp" : "2018-11-27T06:41:54.904+0000" , "txnid" : "af5b8023-aabc-4a46-8f37-d3c167129b1e" , "FI" : [ { "fipID" : "FIP-1" , "data" : [ { "linkRefNumber" : "XXXX-XXXX-XXXX" , "maskedAccNumber" : "XXXXXXXX4020" , "encryptedFI" : "string" } ], "KeyMaterial" : { "cryptoAlg" : "ECDHE" , "curve" : "Curve25519" , "params" : "string" , "DHPublicKey" : { "expiry" : "2019-06-01T09:58:50.505Z" , "Parameters" : "string" ,// DHPubicKey||ciphertextspecification||signature||sessionkey "KeyValue" : "string" // dhpk(p)||AES/GCM/PKCS5Padding||HMAC||HKDF }, "Nonce" : 0 , "Signature" : "Signature of AA as defined in W3C standards; Base64 encoded" } } ] } AA API Once FIU receives the notification <Data-Ready> from AA, using digitally signed consent request received from AA, this API can be used to fetch the financial information from the AA. GET /FI/fetch/{SessionId} Parameters Name Description sessionId * string (path) Session ID for the FI Request Session fipId string (query) FIP ID as defined in the Account Aggregator Ecosystem. Maximum 1. linkRefNumber array[string] (query) linkRefNumber/s for the accounts to be fetched from particular FIP. Supports more than 1. Response: 200 OK { "ver" : "1.0" , "timestamp" : "2018-12-06T11:39:57.153Z" , "txnid" : "3dd436f8-0747-4a8f-9001-375e419430be" , "FI" : [ { "fipID" : "FIP-1" , "data" : [ { "linkRefNumber" : "XXXX-XXXX-XXXX" , "maskedAccNumber" : "XXXXXXXX4020" , "encryptedFI" : "string" } ], "KeyMaterial" : { "cryptoAlg" : "ECDHE" , "curve" : "Curve25519" , "params" : "string" , "DHPublicKey" : { "expiry" : "2018-12-06T11:39:57.153Z" , "Parameters" : "string" , //DHPubicKey||ciphertextspecification||signature||sessionkey "KeyValue" : "string" \\ dhpk(p)||AES/GCM/PKCS5Padding||HMAC||HKDF }, "Nonce" : 0 , "Signature" : "Signature as defined in W3C standards; Base64 encoded" } } ] } 5. References [1] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, (draft) November 2008. [2] American National Standards Institute (ANSI), ANS X9.62-2005: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005. [3] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Work in Progress, October 2008. [4] [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC2: Elliptic Curve Cryptography", Version 2.0, September 2010. [5] “SafeCurves: choosing safe curves for elliptic-curve cryptography”, https://safecurves.cr.yp.to/ [6] D. J. Bernstein, "Curve25519: new Diffie-Hellman speed records", Proceedings of PKC 2006, February 2006. [7] Josefsson, Simon, and Yoav Nir. "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement." (2016). [8] Khazan, Roger, and Jonathan Herzog. "Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax." (2011). [9] “Cryptographic Key Length Recommendation”, https://www.keylength.com/en/3/ [10] “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)” https://tools.ietf.org/html/rfc5869 A few examples to see how to hash API requests are below: 1. Twitter’s guidelines for developers for signing API requests: https://developer.twitter.com/en/docs/basics/authentication/guides/creating-a- signature 2. Amazon’s guidelines for signing API requests for AWS: https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html References https://cybersecurity.ieee.org/blog/2016/06/02/design-best-practices-for-an-authentication-sy stem/ Design Best Practices for an Authentication System https://openid.net/specs/openid-financial-api-jarm-ID1.html Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) https://github.com/OWASP/owasp-mstg/blob/master/Document/0x04g-Testing-Crypt ography.md https://www.keylength.com/en/3/