Perhaps this sounds too dull to ask, but what stops the terminal from just ... not separating the keyboard and display?

But still as a user I have no idea if I'm talking to a certified machine or not.

I'm not so sure. "And then initial supplier inserted hardware that thwarted all those pressing considerations" sounds a punchline to me. :(.

The safeties are mainly to guard against the rest of the world. For example it prevents tampering in transit, or even in our own company - disgruntled employee can't do anything.

Or think for a second about the fact that we leave the device for, hopefully, entirety if its life at the client site. We had clients that were shady businesses like strip clubs that no other companies would touch with a stick.

https://www.commbank.com.au/business/merchant-services/eftpo...

This is the easy part.

The hard part I remember was establishing secure communication between all components in the system (initializing HSMs, injecting keys). I remember helping designing the process and writing hundreds of documents describing various security-related procedures like how the HSM racks are inspected, how the keys to the racks are fetched from the safes, how there are multiple safes for multiple security officers, how the officers are prevented from ever having access to other safes, how fetching anything from safes requires logging and using tamper-evident containers, how the logs are inspected, and so on.

I have designed a special cryptographic protocol so that we could generate and inject keys to the devices in KIF (Key Injection Facility) and separately to our database (to establish communication with the terminal). Fun.

We have some fun stories on this topic, like when we were using our PCI PIN approved secure room in our development office for the first time. We papered over the cage to prevent a security camera from being able to see employees entering PINs on the HSM. An eager employee papered over this cage a little too well cutting off the natural flow of air. And then there was a bug in our offline CA code and we spent 30 minutes in that air deprived cage while debugging occured :) finally the bug was fixed, we issued the cert on our first production device, and stepped out to get a breath of fresh air. Obviously this isn't our daily driver secure CA room :)

(If anyone reading is looking for a job in security engineering, we're hiring! https://www.clover.com/careers/engineering)

We also had special screens created for all cameras in the datacenter to block view on the HSM racks.

The biggest issue was, just before end-to-end test we figured out we forgot one of critical procedures (it was establishing authenticity of the HSM used) and we had to scramble to get new HSM and to re-establish all cryptographic material (so new storage keys, etc.)

The general problem with most "industry security" approaches is that they simplistically attempt to wrestle ultimate Godmode-control for themselves, rather than working towards eliminating it.

https://www.pcisecuritystandards.org/documents/pos_ped_secur...

https://www.pcisecuritystandards.org/documents/PCI_PTS_POI_S...

The requirement for the tamper proofings is literally the first requirement in the PED standard:

A1 Vendors must comply with all components of A1.

A1.1

The PED uses tamper-detection and response mechanisms that cause the PED to become immediately inoperable and result in the automatic and immediate erasure of any secret information that may be stored in the PED, such that it becomes infeasible to recover the secret information. These mechanisms protect against physical penetration of the device by means of (but not limited to) drills, lasers, chemical solvents, opening covers, splitting the casing (seams), and using ventilation openings, and there is not any demonstrable way to disable or defeat the mechanism and insert a PIN-disclosing bug or gain access to secret information without requiring an attack potential of at least 25 per PED, exclusive of the IC card reader, for identification and initial exploitation as defined in Appendix B of the PCI POS PED DTRS

I don't know this device internal and the PED/PTS exact requirement but it seems plausible for me.

You have something like a physical compartment who include the NFC and everything needed to process it like in a classical terminal. This compartment is highly secured as requested by the specification with just a very simple interface for the android part to send the amount to bill.

I've seen a lot of each-machine running on windows. Doesn't they work like this with the windows machine just managing the display buttons to select the amount and sending this information to the secure part who handle card interaction, pincode and delivery of the money ?

Now none of these certifications or standards is bullet proof but people have a very skewed vision of the PCI certification process likely due to bias of only having interacting with the PCI-DSS requirements for merchants and low levels to boot meaning they didn't had to do anything but to fill the SAQ themselves and be on their way.

HSMs are required so that the company does not need to have PIN codes exposed anywhere. Not having PINs or full credit card data makes your life easier as there is nothing to steal from you in the first place.

If your company stored PIN codes it means you were in breach of the contract and it had to lie to the auditors to pass the certification.

The pin we are talking about is what is customized on your credit card (directly in its memory) or its equivalent in your bank's HSM for the sole purpose of performing CVM step negotiated by yor card and payment terminal.

Legit companies don't want the info and anyone that wants the info isn't doing anything legal with it.

Devices that accept cards need to comply with PED/PTS security requirements including very strict physical security requirements which are validated by PCI council approved laboratories and firms.

You are not getting a device on the market or usable with any merchanet network without complying with this: https://www.pcisecuritystandards.org/documents/pos_ped_secur... and a few other standards.

The question is, how Chinese banks coax Visa into allowing them using them.

I think the GP is confused on how a POS works, POS isn't a POI most of them don't touch the credit card they just talk to the reader, most readers today are P2PE closed loop solutions so the only thing the POS does is sends to the reader charge the next card $X the reader will then reply if the transaction went through or not and that's it.

The reader itself will talk to the acquiring bank or the payment provider in a point to point encrypted closed loop and the merchant would never see any credit card details.

Sure you can send fake devices to be certified and sell something completely different but the same can be said for any certification and if you get caught boy or boy...