12

Square recently launched their Square Reader physical device. AS well as accepting NFC based payments (e.g. Contactless or Apple/Android Pay, it also accepts Chip and PIN authentication.

However the PIN entry takes place in an app on the smart phone using software rendered buttons. How does this meet the EMV requirement for the PIN Pad to be a "tamper evident" device(as described in the EMV specifications, book 2 section 11.1) - pushing buttons on an app that talks over bluetooth doesn't seem to be tamper evident to me.

The full flow is that the retailer installs the Square app onto their Android/iOS device. They then pair with the Square Reader over bluetooth. At payment time the retailer opens the Square app, and enters the items/total as per a usual Point of Sale system. When they total it and proceed to the payment step the customer then inserts their Chip and PIN enabled card into the Square Reader and then, on the retailers smart phone, validates the amount to be charged and enters their PIN into the app to authorize the transaction. The PIN is presumably sent over the bluetooth connection, with the amount, to the Square Reader where it then is passed into the Chip.

Am I misunderstanding the requirements on PIN Pads, or am I misunderstanding the functionality of the Square Reader?

Megan Walker
  • 223
  • 1
  • 7
  • The tamper evident hardware regulation is presumably only important to shared pin entry devices. The user enters the pin on their own device which is in their control and is unlikely to have been comprised to obtain a pin. I guess the emv regulations haven't caught up with this method of pin entry yet. Not sure you could assert that bluetooth comms between the reader and the pin pad could ever be tamper evident. – iainpb May 09 '17 at 22:32
  • @iain *Does* it prompt on the customer's device? I don't see how it can. The customer wouldn't have the app, nor is there functionality in all smartphones to arbitrarily prompt for a PIN number. – Bobson May 10 '17 at 00:27
  • 1
    @Megan Are you sure it prompts for a PIN at all? As far as I know, it's perfectly valid (albeit unusual) for a device to advertise its capabilities with a [tag 9F33 of E028C8](http://tvr-decoder.appspot.com/t/decode/constructed/EMV/9F3303E028C8), which means it has no PIN capability at all. The card can then choose whether that's sufficient, which might depend on whether it can go online. – Bobson May 10 '17 at 00:37
  • 1
    @iain The PIN is entered on the retailers iPhone/Android device in the Square app, not on the customer's device. I've confirmed this with a friend who has a Square Reader for their business. I'll update the question to clarify this. – Megan Walker May 10 '17 at 11:48

1 Answers1

5

From what I have seen of the device, your description of the Square Reader and it's operation is spot on. The requirement for a pin pad to be tamper evident is however no longer required.

The update was published here on May 2015: http://www.emvco.com/download_agreement.aspx?id=1113

And contains the following excerpt: "remove a requirement for PIN Pads to be tamper evident, since PIN Pad security is addressed by individual payment systems."

That being said, the actual update to Book 2 section 11.1 without knowledge of the intent statement above, still does not make it clear what is required in my opinion.

Joe
  • 1,214
  • 1
  • 11
  • 16
  • Interesting. While that is the explanation of the change; the actual change itself changes it to "is a tamper evident". Which to me still sounds like they intend it to be tamper evident. But given the decription of the change, I think I must be misinterpreting. – Megan Walker May 30 '17 at 09:03
  • I am working with an Android POS terminal and the SDK uses a virtual PINpad on the screen. The point is, that once you call to start the PIN verification process you must pass the buttons to the method and from there it generated a random pinpad each time. There is not way to intercept or manipulate the key our touch event as the buttons listeners are managed by the API core process – Delcasda Aug 08 '17 at 14:51
  • The "funny" thing is that the individual payment systems security requirements point back to PCI requirements. For example: https://www.google.bg/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjKz8C99K7WAhUCbhQKHRKwCVMQFgg5MAM&url=https%3A%2F%2Fwww.mastercard.us%2Fcontent%2Fdam%2Fmccom%2Fglobal%2Fdocuments%2FSPME-manual.pdf&usg=AFQjCNHO3JHDpM2v7AKEY27ry0foQrbOSQ. Regretably this answer seems that it is not really answering the question... – Ognyan Sep 18 '17 at 14:39