4

Suppose I work for a bank and am asked to write an NFC payment app for the iPhone 6 or Android but not use Apple Pay. To simply send the credit card details to the reader via NFC.

Now assume I'm not storing the credit card details using a one-one hash that the credit card company at the other end will match to validate the payment. Assume I'm simply giving the credit card details to the reader, in a similar fashion to a shop-assistant manually typing in the credit card numbers into the reader when the magnetic strip fails.

To do that - I've got to store the credit card details in either un-encrypted, or two-way encrypted fashion on the iPhone or Android.

If I store it as unencrypted on the iPhone or Android - then any other app could read the data and potentially send it on for nefarious use. (Similar to the way that FileApp works).

If I store it as encrypted on the iPhone or Android, then it has to be a two-way encryption, and then any other app that uses that encryption mechanism can read the data from the phone. (Ie - you could obtain the encryption mechanism by reverse engineering LLVM bytecode of my application).

My question is: Is building an NFC payment app without a secure element like Apple Pay for iPhone or Android fundamentally insecure?

Community
  • 1
hawkeye
  • 207
  • 1
  • 7
  • I would say building an NFC app for iPhone's that isn't Apple Pay is impossible right now. I say that because Apple has confirmed they are not opening up the NFC system for other apps to use at this time: http://www.cultofmac.com/296093/apple-confirms-iphone-6-nfc-apple-pay/ – John Downey Sep 24 '14 at 16:46
  • Isn't this a little like asking "is using a browser other than Safari on iOS fundamentally insecure"? Pretty sure the answer should be no - there's no inherent insecurity to using tools that the OEM doesn't themselves develop, so long as the tools you're using are actually made to be secure. – Iszi Sep 24 '14 at 18:57
  • Based on the content of your question, do you actually mean something like "is creating an NFC payment app using HCE, i.e. without a secure element, inherently insecure"? Apple Pay is only one of various mobile payment systems that use a secure element. – lxgr Sep 25 '14 at 15:04
  • Depends on what you mean by "insecure." Everything is insecure given enough time and the tools. An acceptable level of security is really what you want. I think whitebox crypto might be what you are looking for. Many payment apps use whitebox encryption to secure HCE on Android and provide secure key management for secret and private keys for both iOS and Android. Whitebox is also then leveraged for obfuscation and tamper-resistance - a must on Android. –  May 13 '15 at 17:20

1 Answers1

2

The information stored on a handset using HCE for contactless payments is probably limited in some ways (time, usage or both).

Take Google Wallet (the HCE-version): Google states that

You will need to be connected to the internet in order to unlock the app with your 4-digit security PIN and tap and pay in stores. However, if you set your PIN timeout in the app settings, you can be offline for up to 24 hours and still tap and pay without being connected to the internet.

This sounds like the dynamic per-transaction data the phone creates for every transaction will only be valid for a limited timespan. Ideally, the used keys/secrets would be replaced every time the phone is able to connect to Google Wallet.

Some Android phones also support a hardware-backed keystore, which allows creating an RSA key inside a protected part of the system; the OS will only allow API users to perform private key operations, but will never reveal the key itself. This could presumably be used to emulate the behavior of a dedicated secure element (I don't know if the key formats used are compatible with the EMV specification, though. Physical secure elements also have the advantage that they can be directly connected to the NFC interface of the phone and detect whether they are communicating with an actual NFC reader or with software on the application processor).

Of course, if the phone can be completely controlled by an attacker (e.g. by exploiting some security bug in the Android framework or in the Linux kernel, which both have happened before), it might be possible to copy (or relay in real time) all necessary data to authenticate to the Wallet servers and sniff the user's PIN while it is being entered. This would (hopefully) be caught by the HCE operator (e.g. by looking for concurrent requests using the same credentials from different network locations).

Note: I interpreted your requirement of "not using Apple Pay" as "not using a secure element like Apple Pay does", since it seems unlikely that Apple will be allowing competing contactless payment applications on iOS. (There currently isn't any NFC API, and even if they were, I very much doubt that NFC payment apps could be distributed on the App Store). Android applications, on the other hand, could not be using Apple Pay for obvious reasons.

lxgr
  • 4,094
  • 3
  • 28
  • 37