You can just buy counterfeit anti-tamper stickers but if there is a switch inside the unit that flips a bit in some sort of write-once memory, then that would require removal of an entire chip and replacing it with another that may not be 100% the same. You can have a chain of trust in the system where chips will only talk to each other if they all spit out the right hash. Bury the SPI/I2C lines you use for this trust check within the PCB so you can't access it without drilling the card and add a layer of anti-tamper traces that trigger another tamper event if disturbed. Now what was just a quick install has turned into a whole PCB rework job where you are having to swap all the chips with a virgin set, assuming you can't get your hardware in there prior to final assembly.
Use an AES256 key from the factory to hash the chip's burned-in serial number and the time from the RTC. Lock out JTAG interfaces so once the chips are burned, they are inside their own fortress. There are a ton of ways to really lock down the hardware other than a shiny sticker and weird screws. Those keep people from breaking their own hardware, anti-tamper tech in chips keep out bad guys.
The device outer enclosure was tamper evident but the device itself was tamper proof HSM, basically. Any kind of intrusion (melting, dissolving, drilling, etc.) into a secure internal enclosure (separate processor, memory and battery) would cause internal battery to be disconnected from internal SRAM and basically the device would loose all cryptographic material and then self-destruct.
To give a bit of background, when you type your PIN on credit card terminal it is not the terminal application that is really getting the pin (well, except for special credit cards but that is really problem of the Bank that issued the card). The Visa/Mastercard mandate that the application don't have control over the PIN and that the PIN entry uses physically separate keyboard and display.
To achieve this, the keyboard and the display is galvanically separated for the duration of the PIN entry and the PIN is transferred directly to the HSM where it is being encrypted before it is transferred to the application processor for the rest of processing.
Certification. Worked in the same industry, and there were very strict both hardware and software requirements for POS software. Having gone trough credit-card audits, early EMV certification programs, and certification to place non-payment software next to payment software on such systems, I can tell you - it's no joke :)
It's not your problem. For the transaction to take place it has to go to your bank and your bank trusts Visa/Mastercard to manage risks. You would be surprised to know most frauds are absorbed by banks. Nobody is interested in people fearing plastic because it causes people to increase very expensive debt plus additional interchange fee from every transaction.
That, at least, is a problem that cab be solved by tightening security at supplier site.
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.
Those VISA/MasterCard rules can't be universal because there's at least one bank issuing merchant terminals that run Android and take the PIN on the touchscreen:
Clover CEO here. Won't comment on a competing device but this may not work the way you think. In Clover's approach the touch controller input isn't reaching the Application Processor running Android when in PIN entry mode. You can do patent search if you're interested.
That would be in line with the requirements. You go through stringent certification with the software and hardware that has access to the actual PIN and then show that the application and application hardware never really has any access to it so that you can customize/update your software.
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.
Agree the people and process side is very difficult to do well. Familiar with all those and more -- we have extremely good, dedicated employees who care deeply about doing those things right.
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 :)
I have few more stories like the time when I closed the HSM rack door a bit too energetically and caused outage to entire company as we had to bring in third security officer to re-initialize it.
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.)
What you're describing sounds like another backdoor of its own!
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.
Those are universal PCI council rules the fact that the terminal runs android doesn't mean anything it still needs to be compliant with the PIN entry device requirements as well as PTS and POI requirements depending on the exact nature of the device:
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
But this device doesn't need a way for the user to enter the pincode. So, all the sensitive part of the terminal is probably completely isolated from the android part.
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 ?
Yes this is a common design in fact most current solution segregated the POS and POI completely anything that handles the actual credit card whether it's C&P, Track2 or NFC is a closed black box with the required PED/PTS/POI and P2PE certifications the merchant never sees what's going on they only can talk to the thing in bill the next card X and get a confirmation of the transaction that's it they don't see any of the card data they don't even see any card holder data unless they collect it in a side channel e.g. a loyalty program.
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.
Worked in the payment industry for years. Visa/Mastercard do absolutely nothing to verify that companies are not storing Pin codes. The HSM is required for communication with them only.
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.
It is correct. Incompetence abounds. You are correct about the HSM but it does not enforce anything except for the exchange between whoever and MC. You do realize that pin codes are entered into a UI and phone system as plain text right? There are PCI audits but they are a joke.
You realize when we talk pins we mean authorizing your credit card chip&pin transaction? Nothing to do with your phone pin or maybe som other pins.
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.
That's not correct the QSA will validate that the device does not store PIN codes or the that the merchant does not store anything they are not allowed.
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.
The POS and the PED/PTS isn't the same thing the POS can complete the transaction without touching the credit card in fact most of them do exactly that the only thing that it does is communicate with the PED/PTS to send the amount and get a confirmation/denial.
It's not CNP doesn't use the pin it uses the CVV2, you also can't use the chip and pin or track 2 swipe data for a CNP transaction.
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.
SAQs don’t involve QSAs.
They are also intended for merchants which are a rounding error also there is no SAQ for PA, PED, PTS etc. certifications only for merchant PCI-DSS.
You can totally fake your way through PCI audits. I know of a company that did it for years using a fake network and servers. Not sophisticated at all. Most auditors do not find all of the compliance violations. They have one person do it. It's all about money.
You can fake a lot of things so what? That’s not the point, also PCI DSS is pretty crappy but the hardware vendor, payment provider and P2PEE certifications are a completely different story good luck faking it.
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...
Wrong. PIN codes are entered into a damn mobile app and passed through an API. Billions of times per day. You guys are clearly missing the card serciving aspect of the industry.
I never said a nation state couldn't attempt this but just that if you try really hard to lock down your hardware, it becomes very expensive and risky. You may be better off attacking the system in another way other than cracking it open and soldering your payload in there.
Use an AES256 key from the factory to hash the chip's burned-in serial number and the time from the RTC. Lock out JTAG interfaces so once the chips are burned, they are inside their own fortress. There are a ton of ways to really lock down the hardware other than a shiny sticker and weird screws. Those keep people from breaking their own hardware, anti-tamper tech in chips keep out bad guys.