A eKYC failure case-study

Issue #1206 resolved
Nat Sakimura created an issue

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?

Comments (9)

  1. Torsten Lodderstedt

    Thanks for bringing this tho our attention. I suggest to add text to the security considerations sections pointing our the importance of appropriate authentication assurance when retrieving claims with a high identity assurance level. And clearlry, acr_values and acr are the parameter/claim to go.

  2. Vladimir Dzhuvinov

    Ouch. Bank account numbers cannot be considered secrets, so the initial authentication hangs on those 4-digit PINs. If a large enough pool of account numbers gets harvested (or guessed - what's the possibility for that in Japan?), then an attack based on simple PIN guessing could also theoretically succeed.

    In addition to what Torsten proposed we could also say:

    Data obtained via eKYC should not be used for local end-user authentication at the RP, unless the IAL of the eKYC matches or exceeds the required IAL for the local end-user authentication.

    The data provenance will become more crucial when eKYC data starts getting aggregated and involves multiple hops.

  3. Kai Lehmann

    Would it be possible to help creating appropriate standardized acr values which should be used/required?

  4. Log in to comment