Account Aggregator Masterclass - Security, Privacy & Certification
This masterclass contains a presentation from Sasikumar Ganesan (an expert in cryptography and security) about the various security aspects in the Account Aggregator (AA) eco-system. Sasikumar was the security architect of the Aadhaar, co-author of the e-sign, and currently one of the architects for the open-source national identity project named MOSIP.
You can access the videos of the masterclass here: part 1, part 2, part 3.
1.0 Security in Account Aggregator Eco-system (2:57m)
- Security by Design: The security was included from the design phase and utilized the best security mechanisms.
- Security by Default: The best form of security is available by default in all configurations and not included as an afterthought.
Security by Trust: Every person or entity in the eco-system is a trusted party, and the trust is built-in by sharing either a token or certificate.
2.0 Cryptography in Account Aggregator Eco-system (6:43m)
The AA security predominantly uses public key-based cryptography with some changes to support the latest technologies. All the keys available in public are encoded using X509 specification (note, it is not a certificate). The security designs cover confidentiality and anonymity of the data so that the communication can happen anonymously between different entities in the AA eco-system. The data shared is legally validatable and trustable.
2.1 Diffie Hellman Key Exchange (DHE) (13:45m)
DHE provides a unique mathematical property over which two entities derive the same key when communicating over a non-secure channel. They do that using publicly known code words. It is similar to combining three paints to create final paint. No matter in which the paint is mixed, the final color will be the same. A common paint is like a public key that both entities know. The private key is another paint that entities choose, and the secret key is the third paint.
2.2 Forward Secrecy (17:00m)
The forward secrecy is a unique agreement between two entities used if communication goes through a third party (say, AA in-between FIP and FIU). It prevents the third party from reading the data. The unique aspect of forwarding secrecy is that it protects against future comprise or attacks. Since it protects the keys (and not the data) shared between the entities, the hackers cannot decrypt the data.
2.3 Curve 25119 (20:49m)
Curve 25119 is a high-speed cryptographic algorithm used to avoid implementation pitfalls (such as predictable keys). It is immune to timing attacks and also isomorphic (can be used for encryption and signing). Curve 25199 allows a public key to be represented with a simple 32-byte string.
2.4 Key Exchange (0:16m)
The AA security design assumes that the underlying network is dirty and designed to know that they are communicating with the right entities. The entities create a new ECC pair for every new request and exchange the public key nonce.
AA provides a centralized token issuing mechanism, and every eco-system entity gets a token to identify themselves. The entities exchange these tokens to identify themselves to other entities. DHE is used to derive these keys. The nonce is used in exchange to bring in some randomness and uniqueness. Session keys are created by combining DHE keys with nonce and used to encrypt the data. The decryption ensures that the third=parties cannot decrypt the data even it goes through multiple hops.
2.5 Data-Centric Security (3:50m)
Data-centric security ensures that security and privacy move along with data. It is expected that every entity in the eco-system follows this standard. Every customer attribute should be considered as personal data and protected. The transient data can stay in-memory and perish; however, persistent data protection is a must.
2.6 Privacy(5:00m)
The AA security uses isolated caller identifiers by design. The end-users identity to be masked at the point of origination and hidden to maintain anonymity. A hash of data is not a token, and it should be a secure random number with no relevance to the actual data. The OTP mechanism should be compliant with RFC 6263 standards, and the notification sent should have a context for users to be aware of the notification context.
3.0 Account Aggregation Certification (9:40m)
The certification process looks for implementation and confirmation of the APIs. The process looks for the source code, the APIs, and the entire set up. The process also validates storage, deletion, and audit of data in rest and transit.
The certification is a two-step process, as shown below.
- Self-assessment
- Audits.
The entities will perform a self-assessment every quarter with the available tools. A person from AA will perform certification/re-certification audits once in two years. A surveillance audit to be performed based on commitments from previous audits. An intermittent audit to be performed when there is a significant change in specification.
A certification process looks for
- Conformance to APIs, central registry, and usage of HTTPS
- Functional Flows
- Access control test with negative data sets
- Data validation, retention, and protection
- Adopted policies and procedures.
4.0 Best Security Practices in Account Aggregtory Eco-system (1:44m)
Follow the CIS controls and sub-control for better security. The keys used for storage level encryption be derived from end-users attributes so that the back end cannot access data without the end-user logged in. Always use 256 bits or greater for AES as an encryption algorithm. The storage key to be restricted to FIPs 140-level 3 or more compliance devices.
There are two ways to implement anonymization, generalization (segment user data) and suppression (make sensitive information as **). It is recommended to remove the data outliers using the t-closeness principle and never to use the general anonymization technique with large data sets.
