Mobile Banking integrate with Apple Touch ID

Large scale banks like Bank of America, Chase made a connection with Apple Pay. But, banks in several countries were not worked with Apple Pay directly; they integrated with Apple Touch ID, St George Bank(Australia), Tangerine(Canada), Turkiye Bankasi(Turkey).

They only added the function, authenticated by fingerprint via Touch ID. So, customers can login into mobile banking with their fingerprint instead of the traditional identification, password and PIN.

Banks can develop the fingerprint authentication using Apple’s API. And the biometric data is stored into the customer’s device.

123          234

Video :

[Google Authenticator] Account and Key plaintexts stored in a file

[Google Authenticator] Account and Key plaintexts are stored in a file (May 22, 2012)

I found out a security issue at the Google authenticator in May, 2012. I sent a paper about the details of issue to Google security team, but, I didn’t get a response from them. The authenticator was applied upgrade last year, however, I have no idea whether or not the issue was changed. Anyway I post it before dumping it a behind of memory.

Google provides the 2-step verification to make their service more secure. A user can install and use the Google’s OTP(One Time Passwords) app on their Smartphone. But, I have analyzed a authenticator on Android, I figure out a security issue that can be used to make a clone authenticator on another Smartphone.

When a user try to register their Smartphone to use the authenticator, a user have to input their account and, key or scan QR code. And then, the authenticator it starting to create one time password. Now a user can authenticate with Google services through a one time credential.


< Add account >

The authenticator provides two selections to be initialized, ‘Scan bar-code’ and ‘Manually add account’. But if you choose anything, account and key are stored in a file. But the problem is that the user account and key are stored in a file as a plaintext

Stored file is sqlite and the file path is


As you can see the below, the email  field is a user account and the secret field is a key for the authenticator. The secret are looks encrypted, but it’s not a matter to make a clone authenticator.


< An example of stored key and secret >

If the file is copied or secrets and keys are duplicated into the another Smartphone’ authenticator, now we have a clone authenticator. The duplicated authenticators are creating a same one time password at the same time, and it can be used to authenticate the Google’s services.

I checked that the authenticator is verifying the device with phone number, Serial or IMEI, but device verification were not applied and it’s not affected the authenticator.


< The clone OTP >

The suggestions for this issue

  1. Encrypt account and key files
  2. Verify a device when the app executed to check it is a valid device or not or include a device serial into the one time password creation process
  3. Using more secure space like SIM, Turst Zone to prevent from the malicious access(In Korea, OTP apps for banks and financial sector are stored and executed in the SIM card)

E2E(End To End) Encryption for Secure Communication

When a user’s PC was attacked from a malware, exploit or attacker, an attacker can control the PC, and gain user’s credentials and input data. If an user try to login into the website, such as banks, mails and SNS, their login inputs(ID, Password, Account PIN) can be logged and sent to the attacker.

Focus on keylogger issue, there are many types of keylogger, kernel keylogger, user mode keylogger, COM hooking, DOM, BHO hooking and other keylogging methods. And keyloggers are continuously developed and adopted high level techniques.

To protect user’s PC from the client side attack, financial institutions offer the anti-keylogger, communication security solution and personal antivirus in Korea. And to prevent inputs keylogging, they applied the E2E(End To End) encryption. It means applying encrypted communication for significant user inputs like password, PIN, account information and others from the end of user PC(keyboard device driver) to the application server. Therefore, plaintext of these inputs are not stored in user’s application and web browser, even as memory.

E2E is similar with security communication, SSL, it’s only extended client end point from web browser or application to device driver level. If we adopt H/W encryption device that connected between PC and keyboard port, E2E can be more extended to H/W level.

To adopt E2E on the website(or application), the anti-keylogger and the security communication solution are interacted each other for exchange key and transfer encrypted data. The anti-keylogger is operating on kernel and user mode to protect keylogging, and the security communication solution is operating on web browser(or application) and transfer section to secure transfer.

On the E2E process, first, the anti-keylogger need an encryption(session) key to encrypt user inputs, so the key is exchanged between the anti-keylogger and the server. Next, the anti-key logger is encrypting user inputs from a keyboard using the key and send it to the security communication solution. The security communication solution is encrypting received data using key that pre-exchanged for communication encryption and sending encrypted data to the server. The server will decrypt encrypted data twice(communication decryption and anti-keylogger decryption), and the server is checking and processing the user inputs.

User inputs that applied E2E is securely transmitting from the keyboard driver to the server, therefore user inputs were not leave as a plaintext from the application to the server.

But, As you know that attackers continuously try to develop low-level keyloggers, such as i8042 keyboard driver hooking keylogger and others using bypass methods. H/W based E2E can offers more secure communication, but it has a cost and installation issues. S/W  anti-keylogger and E2E are needed to improve and patch to resist new attacks.

From the news, VISA will launch encryption service for their merchants to prevent storing private and payment information. (Link : Visa to launch encryption service) I think they will apply E2E encryption from the cardreader to the application server and the core process of payment will move to operate on the server.(My personal prospect)

The Client Digital Certificates for Financial Services

In Korea, every customers of e-financial services, such as banking, stock trading, insurance are needed to use client digital certificates by regulation. Every financial institutions offer client digital certificates based on PKI(Public Key Infrastructure) for user. And many services like financial service, e-government service, company internal service can use same certificate for secure service.The main purpose of the certificate are secure authentication and non-repudiation of financial transactions. Let’s talk more details about this.

When a customer want to use an e-financial service, they are needed to be issued digital certificates from service provider’s website like bank, insurance and others. The digital certificate includes a user and a CA(Certification Authorities)’s information, owner’s public key and encrypted private key files (Standard ISO/IEC X.509). Commonly, these information are combined into one or two files, user can select the place to save, such as HDD, USB. A user can optionally store the certificate into a HSM(Hardware Security Module) that protected from removing, copying and other manipulations.(To store certificate into Smartcard was reviewed by some financial institutions, but it was invalidated because of cost issue)

As I mentioned at first, the purpose of client certificates are user authentication and non-repudiation of financial transactions. First, user authentication, when a user try to login into the service, a user load the certificate files using certificate management application and enter the password. A user identification information from the certificate files, such as user name, serial number, expiration date and others are encrypted using the user’s private key that was decrypted from the key file by the user entering password. The encrypted data is sent to the server, the server will decrypt it using the user’s public key and then verify the user.

Second, non-repudiation of financial transactions, when a user transfer a money or get a loan, an user is needed to lode certificate files and to enter the password at the end of the service process. The transfer information, such as user information, account, amount, date and others, and hash that was made by combination of the transfer information are encrypted using user’s private key and it is sent to the server. The server verify the transaction’s integrity by comparison between hash from encrypted data and hash on server-side that was made by transaction information. And the server save the encrypted data with transaction data into DB later, the information can use to prove the user’s non-repudiation of transaction. Encrypted transaction data were encrypted by user’s private key, thus financial institution can confirm that user did it.

The principle of client certificate are based on 1) Only a user had a their own certificate, 2) Only a user knew a certificate password for decrypting private key. So, if the attacker can steal the certificate files and logging the password, the financial transaction can be manipulated by attacker. To prevent the threat, financial institutions offer multi-factor authentication, such as OTP(One Time Password), and make the certificate issuing process more complicated and secure.