NBFC-AA_ Security Overview (1) (1) (1).pdf -

Please enable JavaScript to view the full PDF

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 Symmetric key crypto- secret from all but authorized AES-GCM FIU. Authentication Each participating entity in Hash, HMAC, Digitally Signed NBFC-AA ecosystem is API call, Digital Signature authentic. Integrity Messages have not been Hash, HMAC, Signature modified during transit or at rest. Non-repudiation The participating entities in Asymmetric key crypto, NBFC-AA ecosystem cannot Signature deny their actions after performing the operations. Revocation The user can dismiss the HKDF, Revocation list (RL) authorization on financial information by consent revocation through AA. Anonymity The AA should enable that User-aware consent FIP is not aware of the transformation identity of FIU and vice versa Forward Secrecy NBFC-AA ecosystem should HKDF, Ephemeral DH keys, protect historical information Nonce against future compromises of secret keys or passwords. 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: . 7. Verification algorithm: FIU executes ​DHParamasAlgo()​ and a. On receiving the sig(a) and the message generates the domain parameter (M​, c ​ onset_artefact) , where M is dh_params as follows: (dh_params, dhpk(u), rand(u)), t​ he FIP a. The prime P that specifies executes the ​SignatureVerification() the size of the field to verify the signature. b. The coefficients ​a ​ and b ​ ​of b. Check if the DH parameters are the elliptic curve equation. agreeable. c. The base point ​G ​that c. Check consent artifact is valid or not. specifies the group. d. The order ​n o​ f the group 8. If DH parameters are not agreeable, then e. The cofactor b of the a. FIP picks a new set of DH parameters by subgroup executing ​DHParamasAlgo() 2. Generates DH key pair: b. Executes the ​GenerateDHKeyPair() Executes the algorithm to generate the DH. GenerateDHKeyPair() ​algorithm public/private key pair as follows: 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 dhpk(u)=dhsk(u) G where dhpk(u) private key. is the DH public key and dhsk(u) is c. Generates a 256-bit random nonce: the DH private key. Executes the 3. Generates a 256-bit random GenerateRandomNonce() ​algorithm to nonce: generate a 256-bit random number Executes the rand(p)​. GenerateRandomNonce() d. Sends the message ( M, signature (p,M), algorithm to generate a 256-bit certificate(p), where M=(new_param, random number r​ and(u)​. dhpk(p), rand(p). 4. Constructs the message (M​, 9. If DH parameters are aggregable, then P conset_artefact) , where M is generates the DH key pair in the same group (dh_params, dhpk(u), rand(u)). by executing the ​GenerateDHKeyPair() ​as 5. Generates the signature by follows: executing the dhpk(p)=dhsk(p) G where dhpk(p) is the SignatureGeneration() ​on the DH public key and dhsk(p) is the DH private inputs of the message (M​, key. conset_artefact) 6. Sends the sig(f) and the message 10. Generates a 256-bit random nonce: (M​, c ​ onset_artefact) to the AA Executes the ​GenerateRandomNonce() algorithm to generate a 256-bit random number r​ and(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(). sk(u,p) = AA: GenerateSessionKeyAlgo(​HKDF(dhk(u,p), Executes the rand(u), rand(p))​) SignatureVerification() ​to In the above process, HKDF cryptographic verify the signature on the input standard is used to generate the session key of sig (f) and the message (M​, sk(u,p). conset_artefact). 1. If the signature 13. The session key sk(u,p) (or encryption key) verification returns true, is used to encrypt the xml format FI data by then accept the message executing ​FIDataEncrypt()​ algorithm and and forward it to the FIP generate the ciphertext (C) as follows: along with the signature. 2. Otherwise, reject the C= ​FIDataEncrypt(​AES_GCM(FI_data, sk(u,p))​) message and sig(f) and notifies the error to the 14. Constructs the Message ( M, signature (p, FIU. 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 After receiving the Message ( M, signature and AES-GCM encrypting standard signature (p, M), certificate( p)), where used for encrypting the FI data. M=(OK, dhpk(p), rand(p), C). The FIU executes the following steps: 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. 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))​) 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): ECDH P-25519 1. Parameters Initialization Standard a. Selects elliptic curve: Curve25519 [5] [6] [7] [8] Cryptographic primitives used in NBFC-AA Implementation Standards Hash-based-extractor and expand Key H-MAC based HKDF [10] 1 Derivation Function (HKDF) (Optional) Message Hash function SHA-256 , ​HMAC-SHA256 Encryption using Advanced Encryption AES-128-GCM Standard (AES) in Galois/Counter Mode (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​ * Session ID for the FI Request Session string (path) fipId FIP ID as defined in the Account Aggregator Ecosystem. Maximum 1. string (query) linkRefNumber linkRefNumber/s for the accounts to be fetched from particular FIP. array[string] Supports more than 1. (query) 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​ * Session ID for the FI Request Session string (path) fipId FIP ID as defined in the Account Aggregator Ecosystem. Maximum 1. string (query) linkRefNumber linkRefNumber/s for the accounts to be fetched from particular FIP. array[string] Supports more than 1. (query) 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/