[OpenID-Specs-eKYC-IDA] Issue #1206: A eKYC failure case-study (openid/ekyc-ida)

Nat issues-reply at bitbucket.org
Wed Sep 9 13:57:38 UTC 2020


New issue 1206: A eKYC failure case-study
https://bitbucket.org/openid/ekyc-ida/issues/1206/a-ekyc-failure-case-study

Nat Sakimura:

In the last couple of days, there were payment-related incidents in Japan. 

It was a Fintech drawing fund from a Bank account. The account at the Fintech was “identity proofed” using Bank provided KYC data. The Fintech was allowed to draw fund from the Bank account provided that 

1. The name etc. matches with both accounts;
2. The 4-digits PIN that was received through the Fintech was correct one for the Bank account. 

According to the publicly available information, the incident seems to have happened as follows. 

1. The bank account number and associated PIN were leaked somehow. It could have been from Phishing attack or from the data processing facility or through PIN spray attack. We do not know the details but there are many that are being sold in the dark market. 
2. The Fintech did the KYC for its account by receiving KYC data from Bank. Some banks required OTP etc., some banks only required the Bank Account Number and 4-digit PIN. In the latter case, the attacker could easily impersonate the victim by using the Account Number/PIN pair that he bought from the dark market. 
3. Now that the attacker has a “KYCed” account at the Fintech, he sets up the fund draw relationship between the Fintech Account and the Bank account. He only needs the following: 

    1. He gets authenticated at the bank by providing Bank Account Number and 4-digits PIN. 
    2. The account name/address etc. in the Fintech Account and the Bank Account matches. 
    
4. Since these trivially matches \(they are from the same source!\), the fund drawing relationship is now set up so that the attacker can fill the Fintech account using the Bank account. 

This case tells us a few things. 

1. eKYC that the Fintech went though is Level-0. The AAL at the Bank when providing the KYC data is zero, so the resulting IAL from this eKYC process is also Zero. However, it was not regarded like that and the original IAL level at the Bank got propagated. 
2. Verification logic using the matching degenerated as they used the same source. 

These tell us the following: 

1. IAL when providing eKYC data is very important and should be reflected in `acr` claim. 
2. The provenance of data should always be checked if any kind of verification is being performed. 

Perhaps it is a good idea to reflect these in the document?




More information about the Openid-specs-ekyc-ida mailing list