Mag stripes died… Is contactless dangerous again?

Felix (09:19)
It’s an interesting problem with space as well, isn’t it? Because I was under the impression that kind of phone theft was increasingly becoming less and less valuable because of all of the protective measures that are in place and so on. But actually there’s maybe like an arms race here, isn’t there? Because if you manage to get hold of a device which has also got loads of credentials and has like the banking app open and that kind of stuff, then you are in a much stronger position to be able to take advantage of the person’s identity and all their money and so on.

Gareth (09:47)
Yeah, there’s two reasons for phone theft. One is the phone itself is valuable, same with car theft, right? Cars that are stolen these days tend to be shipped overseas pretty quick and completely out of the reach of UK law enforcement. And phones are the same. And people will pay money for them.

If you manage to get an unlocked phone, someone’s on the phone at the time you steal it. You’ve got a fair chance of accessing all their bank credentials or their credit card information, passwords for this, that, and the other. So the phone has again sort of become a hugely problematic area for compromising people’s identity and getting hold of people’s financial information.

Felix (10:24)
In 2026, the You Gotta Hack That team has two training courses. On March the 2nd, we start this year’s PCB and electronics reverse engineering course. We get hands-on with an embedded device and expose all of its hardware secrets, covering topics like defeating defensive PCB design, chip-to-chip communications, chip-off attacks, and the reverse engineering process. On June the 8th, we launch the unusual radio frequency penetration testing course. We dig into practical RF skills so that you can take a target signal and perform attacks against it in a safe and useful way. Both courses are a week long. They are a deep dive. They’re nerdy. And we provide everything you need other than your enthusiasm.

As the unusual RF penetration testing course is brand new, you can be one of our beta testers and get £1,000 off. There’s more information available on our website at yougottahatthat.com slash courses, and we recommend booking straight away as we have to limit the spaces to ensure the best learning experience. But for now, let’s get back to today’s topic.

Okay, so in terms of defending the hardware of payment stuff, you briefly mentioned about changing the mag stripe so that it was, presumably by the sense of things, it was more complex. You say they put three read heads in there instead of like two or something.

Gareth (11:37)
The later regulations said you had to have an encrypted mag stripe head. So the data was encrypted on the head and decrypted at the processor. You could still have plain text on the card, but encrypted from the head to the processor that was actually decrypting it into plain text.

Felix (11:45)
Still plain text on the card. That sounds like an impossible key management problem right there.

Gareth (11:58)
Yeah, it’s not the most friendly process, but it’s done within the confines of the two devices. So once they’ve agreed on a mutual key, you know, it will be an AES key or whatever for the duration of the life of the product, but that’ll all be unique. So there’d be some factory initial process which pairs the two together.

Felix (12:17)
OK, that’s interesting.

Gareth (12:19)
But of course you can get around that by, especially when you’ve got things like dip readers where the card is not swiped through but is sort of inserted. There were compromises around having additional mag heads added afterwards and that happens sometimes on ATMs as well. Especially the cheaper ATMs which have got insert dip readers rather than motorised. You can have a second head which is actually reading the card as it goes in, which is not anything to do with the product itself but it’s been added as an after fitting by someone who’s capturing your credit card details.

Felix (12:48)
From my experience, those tend to be in the slightly dodgy corner shops and that kind of thing knocking around across the country. And if that’s the case, then you know, I imagine it’s in a hostile environment because there’ll be all sorts of people who potentially have access to the physical device. And if my guess is correct and the owner of the shop, the proprietor or whatever, is the one who has to refill it with the cash because they’re sort of operating on behalf of the company with an agreement, presumably they’re quite vulnerable to being physically manipulated, shall we say. Is that fair?

Gareth (13:25)
It should be very difficult to do without tampering the device in some way. So it shouldn’t be possible to get to the mag stripe reader internally. Most of those machines, all you can do is refill the cash really. You can’t really do anything else. If you try to, then the tamper mechanisms will be operated.

What can be more problematic is overlays on the outside, which look like they’re supposed to be there, but actually have got some sort of card reading capability in there.

In fact, I saw very recently someone’s got a contactless overlay, which is quite interesting. So basically stuck a contactless card overlay on a contactless reader so that actually the card’s read by both and the contactless details are used for a transaction through a relay attack of some sort.

Felix (14:13)
That’s interesting. And it’s all right, I hadn’t realised it was being done in the contactless space. There’s some interesting RF properties that need to be investigated in some of the communications protocol bits that I need to get my head around to see how I would see that would work. But that’s fascinating.

Gareth (14:17)
No, I haven’t until recently. The contactless is, of course, magnetic coupling. It’s called RFID but it’s all magnetic so it’s quite difficult to get a very large magnetic field enough to illuminate a card. So you’re not going to read cards at a long distance but if you can persuade someone to tap their card onto something such as an overlay then you’ve got a pretty fair chance of intercepting the traffic, which I guess is just a question of making it thin enough and having all the other electronics in there so that it doesn’t look suspicious.

Felix (14:56)
I had made the assumption around contactless payments that the tech involved some form of cryptography between the card and the reader. And if that’s the case, I would have guessed that there would be some form of nonce once you do that cryptographic initialisation. So you can’t just replay that same RF stream.

Gareth (15:16)
Yeah, you can’t do replay attacks. And I haven’t looked exactly at what they were doing, but I suspect what they’re doing is something along the lines of the reader itself is out of use. Someone taps on it and then it’s relayed in real time somewhere else.

Or they set themselves up as a fake merchant, which is sort of risky because you only need all the credentials to set yourself up as a fake merchant. But, you know, it could be done. You could set yourself up with a card acquirer, with the acquirer as, you know, XYZ company, take a whole load of transactions and then just disappear, I suppose. But I suspect it’s probably a relay to somewhere else. So when you tap the card, you know, that is being transferred to another real reader for some actual transaction. You wouldn’t know the amount, of course, because you don’t know what the amount is.

Felix (16:04)
Yeah, okay, that is really interesting though. All of these little handheld contactless readers, if I wanted to take one to pieces, it wouldn’t be that difficult.

Gareth (16:13)
It wouldn’t.

Felix (16:15)
That depends a little bit. It wouldn’t work anymore for sure. Are we getting somewhere where there is now actually quite difficult technology to overcome? Because a lot of these things, they’re not insurmountable. There’s usually a way, it depends on how much effort you want to put in them. But those look to me like they must be built relatively cheaply because they’re everywhere.

Gareth (16:17)
It shouldn’t work anymore.

Felix (16:37)
They are little tiny consumer little devices and they tend to be paired via presumably Bluetooth or something similar to your phone and then the phone has an app and the app does the transaction. To me those look so flimsy that I can’t imagine they’ve got much security in them at all from a physical point of view.

Gareth (16:54)
They will. There’s actually a bit less sensitivity about just the contactless interface because in theory you can intercept it anyway. But there will be tamper mechanisms which will operate if you disassemble it such that it shouldn’t work afterwards. And that’s really to protect against putting some sort of disclosure bug in which is after the RF interface. The RF interface is relatively complicated.

You’ll see the digital data coming out of the decoder, because it’s a binary bit stream. Mostly, as you say, it’ll be around detecting disassembly of the device. It should permanently tamper. So, you know, it should erase keys, set flags, all that sort of stuff, and become inoperable so that if you have disassembled it, then you can’t actually use it afterwards. Payment terminals have got a lot more security in because they’re handling PINs as well and handling the physical interface, which is in plain text, which is also not a good thing. So…

Felix (17:48)
Yeah, so the contactless stuff is like tokenised transactions as opposed to the card details that are being transferred. So therefore it has a finite value rather than an infinite. If you can keep using these details, it’ll just carry on working. You’re essentially reducing the value of the data you can get. That’s cool.

Gareth (18:06)
But I mean, another shift that is happening is contactless with PIN, right? So, and it’d be interesting to see where that goes. That makes a lot of sense, actually. Much more sense than contactless without PIN. A lot of devices will do contactless with PIN. And then, of course, you’re worried about protecting the PIN entry process, but at least that gives you some sort of, effectively, two-factor authentication, which you don’t get with just a standard contactless transaction.

Felix (18:29)
My slightly ill-educated experience of card stuff was that the PIN was validated locally sometimes, not necessarily to the acquirer or upstream. That presumably can’t be the case anymore, contactless with PIN, because the data wouldn’t have been transferred to be able to validate what that PIN number was.

So if that’s no longer the case, is that going to be only available when you’ve got a good internet connection and suitable equipment? Cause I’ve not seen that become an option for me as a consumer. I bank with one of the sort of more forward-leaning banks, should we say, and they tend to have a lot of the security options available to you as a consumer quite early on. So you can turn things on and make it more secure if you wish and so on.

So presumably, contactless with PIN, then you have to have an internet connection. It’s a mandated aspect of this.

Gareth (19:30)
Yeah, my understanding is it goes back to the acquirer for PIN verification. Yeah. Okay. Yeah.

But you’re right, on chip with PIN, the PIN can be verified by the card because the PIN is also transferred to the card in the clear, which is pretty bad. And another reason why you need to worry about the interface between the card and the terminal. That’s again, historical costing, you know, it was expensive to have cryptographic capabilities on cards. So the specifications didn’t demand it.

And therefore once you’ve got your PIN on the terminal you transfer it in plain text to the card, which means of course you can intercept the PIN in transit if you want to, relatively trivially, if you haven’t got a lot of protections around it.

Felix (20:16)
So back in the early stage of my career, I was a PCI QSA, so payment industry qualified security assessor, if I remember the acronym correctly. And I’ve got to be honest, I didn’t enjoy the work, so I didn’t do it for very long, but it was a bit of a segue into an interesting part of the world.

And from a PCI DSS point of view, the data security standard, what I found was that it was quite binary in terms of the requirement that is being placed on the merchants and that kind of stuff. I mean, aside from the fact that you can do different SAQs and so on, the kind of the technical requirements for delivering a secure environment and all the rest of it were very, very simplistic, but very, very specific.

And I don’t necessarily think that’s a bad thing, but I do think it means that there are opportunities for people to be excluded incorrectly or have problems with their network that they would have maybe picked up on anyway, because it wasn’t part of the requirements, and they were left open for whatever reason. I find that interesting, but then I also recognise that it was a reasonable amount of time between iterations of this standard. And it wasn’t huge, it’s shorter than some, but it was still long enough for there to be like a technological lag between what the world seemed to be expecting of this set of tech and what the requirements were.

My guess is that the requirements for the kind of PIN entry devices would be even slower to evolve or at least have this kind of overlapping arrangement because there’ll be lots of kit out there already that’s to a previous standard.

Gareth (22:00)
Yeah, to a degree. I think a solid difference between the payment terminal standard and the DSS standard is that the testing regime was less objective, I guess. So for PCI-PTS, you got a set of requirements that you had to meet. They were fairly high level, right? So, you know, along the lines of there should be no way of an attacker obtaining the PIN from the keyboard, right? Or something really high level like that.

And then the assessment was via a small number of labs who pretty much came up with their own ideas of how they think they should attack individual terminals. So they would give it to someone who had obviously done this quite a lot. And it was, as you were saying before, it was a time and cost analysis. So, you know, if the guy in the lab said, you know what, I’ve tried this, that, I’ve tried poking it with sticks, I’ve tried, you know, putting it in liquid nitrogen, whatever you want to do with it. I think it would take at least a week and $100,000 to attack this thing.

The return on the investment at that point becomes dubious and therefore that meets, they give you points basically. So you’d have got six points for that and you’d have got, you get X points for clearing buffers or doing all the stuff you’re meant to do, not being able to get to the display. So they basically do various different tests. They were pretty subjective tests. So there wasn’t like a pass fail in the same way. It was more the assessor decided that in their opinion, it would take X and Y amount of time and resources.

That did leave it a bit open for novelty because you could have novel solutions that perhaps they hadn’t seen before, which might be low cost, but still meet the objective. And as long as the assessor couldn’t find a way to break it, then in a short period of time or something, then that would work.

Felix (23:55)
Okay. How did that relate to the hardware requirements then? Because we talked before we were on air that would you ever have JTAG ports still on a board? And presumably the answer would be no, and that would have been the case from quite early on.

But removing JTAG is not just a case of simply not exposing the test pins. It’s more than just that. You’re having a processor that doesn’t have JTAG exposed on its edges, or, you know, only using BGA chips or something so that it’s really difficult to get access to or something. But presumably it’s in there somewhere and it must have been programmed at some point. So JTAG is a legitimate option for that.

Gareth (24:39)
Yeah, what you tend to find, and this is supposed to, again, a difference and a challenge for commercial implementations, is that most payment terminals will use a small number of secure processors for all the important stuff, right? So there are a relatively small number of manufacturers who make a relatively small number of devices which by default don’t have provisions to either turn this stuff off or not have it, or, you know, the version of the chip which doesn’t have it, when you have another one which you use for development or things like that.

So, yeah, mostly that problem is solved that way, which is slightly different from what’s gonna happen in a commercial environment where people are gonna wanna use more off-the-shelf devices and use them in a secure way. So I think that, you know, that potentially is a challenge.

The opposite, I guess, is that, you know, semiconductor vendors are gonna have to come up with more secure solutions. And I know that, you know, there are some out there. I know, you know, the likes of ST and NXP and Maxim will make secure devices and some of them are quite low cost, you know, the security infrastructure built in. So, don’t know, a lot of these devices, you know, they have dedicated tamper detection. So either physical tamper detection or over temperature, under temperature, over voltage glitch detection.

Felix (25:40)
If you use them correctly, they do raise the… sounds like a whole other podcast episode there, Gareth. We could… But for today, have you got any other lasting thoughts that you’d like to share with the audience?

Gareth (25:59)
Yes, yeah. The lasting thought really, especially about the EU CRA, is that the time to start thinking about it is now because it’s going to be too late in two years’ time and you won’t necessarily be able to fix it in software. So you need to start taking a look at your hardware and making sure that it will actually be compliant at the end of the day.

Felix (26:23)
Yeah, we need to touch on the EU CRA, the Cyber Resilience Act, because it’s a whole topic in its own right and has some quite significant implications for embedded systems as a whole, not just the hardware. Perhaps that’s also another episode.

Gareth (26:42)
Well, maybe, yeah. I think some sort of practical guides for developers and implementers might be useful because a lot of these standards, as you know, can be very generic and it’s difficult to actually tease out of them exactly what you actually have to do. All they’re so high level as to be almost meaningless.

Felix (26:58)
This appears to be the case for pretty much every standard out there. Yeah, for sure. Gareth, it has been a pleasure chatting to you today. Thank you for joining me. Cheers. And thanks to everyone for listening. I hope you’ve all enjoyed it. Your reviews are really important to us. So if you haven’t already, please do give us that five star rating and recommend us to all your friends and colleagues and everybody else, including the dog if necessary.

If you have any questions about cybersecurity of embedded systems, why don’t you get in touch? You never know, we might be able to answer it on air for everyone to hear.

You can also find us by email on helpme@yg.ht, with @gotta hack on Bluesky, or by searching for You Gotta Hack That on LinkedIn.