 So, welcome everybody. The next talk is under the topic shoplifting, shop shifting, sorry. Shoplifting is something completely different. That's nothing to do with shop shifting. The outcome is the same. And I present to you Casten, Fabian, Boynlein and Dexter from Berlin and some of you may have already seen the one or the other face here and you may have heard of things like the my fair air friday problems that we had the GSM SIM card hacks and things like a bad USB and these people and people around them are all responsible for that so give them a warm applause and status use Thank you very much It's great to be back looking at yet another technology and Searching for security vulnerabilities We focus our research on technologies that most of us use on a daily basis that are typically outdated Very widely deployed and insecure Took us many years to finally come around to look at payment protocols, which we'll be discussing today In parts it took so long because we just didn't think we would find anything After all some of the best people in our industry work at banks and banks have among the most developed risk management So at least in my experience Banks are good at reacting to to security evolution That's what I thought up until maybe the middle of this year when we started this research And we're here now today to take this preconception away from whoever may still be Suffering from this illusion that banks actually do keep their systems very secure at least we found in two cases to very widely deployed protocols That there's gaping holes and have been for a couple of years Both of these protocols are involved in payment That is if you go into a store and you pay with a card those protocols are invoked at least in Germany and protocols are called ZVT and Poseidon they used for very different purposes But they're both terminated at a payment terminal The one protocol ZVT is spoken between a cashier station and this payment terminal So somebody would scan some items or type in some amounts into this cashier station and then say now Please pay and a commander sent to the payment terminal which then request a card and perhaps a pin number For most transaction in Germany and then and turn it invokes another protocol that this payment terminal speaks with a payment processor it's a service provider that connects these terminals to banks and Basically facilitates the actual payment and then the payment processor or the bank to validate the account details and so forth They send the confirmation and that confirmation again over ZVT is sent back to the cashier station That is in a nutshell how a payment transaction works So it it's based on two protocols both of them fairly old and base Probably by virtue of being so old very widely deployed In Germany you will hardly find anything other than these two protocols being used We'll look at an international angle towards the end of the talk Just a short summary most of these problems would probably exist in most of the countries as well So let's in turn Look at ZVT and then preside on to identify their security issues Starting with ZVT. This is again the protocol that's spoken in the shop Between a cashier station and the terminal but in almost all cases over network connection Very old systems would use a serial cable, but today a network is used So assuming that that a fraudster somehow can get access to that local network by plugging into some open ports Or by even being a customer at your hotel and just being connected to the same Wi-Fi as your cashier system What can this attacker do? Let's start with something simple that That doesn't even really require any hacking In this case somebody wants to steal the magnetic stripe details of a card So the way this should work is the cashier station sends a command To the payment terminal and then gets a confirmation back after some processing now what the attacker does in this case is Get in between those two in a connection Through just traditional app spoofing so you proxy the connection between the cashier station and The payment terminal sitting in the local network again. Well, we'll look at internet-wide attacks In a few minutes, but for now we're talking about inside the shop or in Wi-Fi range of that shop, right? so you up spoof and You receive that author Authorization request that's supposed to be sent to the payment terminal where the cashier station basically says there's a customer here The customer wants to pay something please authorize the payment, right? We take that Command and do not forward it but instead send another command which basically says read a card So the terminal will then Display what the customer expects please insert a card customer does so and the magnetic stripe information is read and send back over the network to the attacker No transaction has been done yet Immediately following the these magnetic stripe details the tackle would then send an actual author authorization request message Supplying the magnetic stripe info so instead of asking for a card the payment terminal just takes this max drive now and go through the transaction So two things happen first the attacker did receive a copy of the max drive Second the actual transaction the intended transaction did go through so neither the customer nor the merchant sees any different But the attacker does have a copy of the max drive now and then countries where max drive is enough Let's say us prior to chip and pin. This is enough to completely clone a card Fortunately Most other countries do require pin numbers making this attack ineffective But perhaps motivating a slightly improved attack. So let's say the frauds that wanted to also steal the pin number remotely Right max drive and pin number. That's really all you need to to pay in Germany say So the way pin transactions are supposed to work They are much more secured or well, they're secured at all versus max drive, which isn't secured So the top part of this slide shows How a pin transaction is supposed to work? Again over ZVT the The cashier desk or Whatever speaking to to the terminal in the store sends an authorization request this time specifically saying do require pin number Or perhaps that is even configured in the terminal to always require pin number Either way inside the terminal all the security magic happens now. There's different Components of the terminal. There's a there's a main CPU that does all the network communication both ZVT and Poseidon Which is supposed to be somewhat secure, but really isn't As by the way some research a couple years has shown that specifically looked at the security of one of these terminals But that's not the topic of today. We're looking at at the standard security But so inside this terminal. There's also a hardware security module and HSM and that's that HSM does all the heavy lifting When it comes to cryptographic keys and so forth The HSM is also directly connected to the display and the pin pad of the machine So you tell the HSM inside the terminal Do a pin transaction it shows something on the display enter pin It receives the input and instead of giving out the pin number to the less secure side of the terminal It encrypts it with a key that only the payment processor is supposed to have so the The main CPU or anybody really outside of the HSM does not see the pin number. That's how things are supposed to work Now the lower part of this light develops an attack idea was one catch will resolve that in a minute though This attack idea would use a different message to actually receive the pin number. So instead of saying do a Pin transaction it would just say display some text and give me the input That would work beautifully, right? So you display the text give me the pin number and whatever's typed in you get that that input This very flexible functionality. We don't really know what it's ever used for we've never seen it But we're suspecting it's used for things like Asking customers for their zip code or something right type something in and send it over the network and We've partly never seen this because it really can't be used these messages need to be signed We don't know who's supposed to sign these messages messages. We've tried to find a person, but nobody feels responsible So there's there's some functionality in a standard here That's never used and nobody knows how to use it because of this cryptographic signature on this light called a message authentication code Mac That's required and it's actually checked by the HSM. So if you want to do your please enter zip code Scheme across all your stores You got to get your message signed and that signed message then works across all terminals and if we want Our please enter pin number message to be shown. We got to get this signed or Find some way to sign this ourselves and now we're entering the real hacking. So I'm handing over to Fabian Who did almost all this research? So it was just my honor to introduce these two guys here All right, so to find well at max for arbitrary text we exploited a time-based Side-channel vulnerability within one HSM implementation So for this to work reliable we had to have the ability to send messages directly to the HSM To accomplish that we used an active JTAC interface We found for the main CPU on the PCB and loaded our customers and the program What this one did was just sending messages messages with our text and some Macs to the HSM And stop the time that it needs to respond So we were we are doing that and are trying every single possibility every single value for the first byte of this eight byte Mac When you do that you will see that so that's a bit over simplified But you will get the chest you will see that for one particular value The HSM needs a bit longer to respond. So like just five CPU cycles within the HSM Now you already have the first The first digit the first byte of this eight byte Mac. You can set this and do the same thing for the second one So why does that work? this works because they use an Symmetric key for the calculation of the Mac within the HSM There is a key that the payment processor has and then stored inside the HSM Which is able to calculate the correct Mac for any text And what happens next this is the first minor issue because you should use asymmetric cryptography the next thing is that The comparison between the correct Mac that has been calculated within the HSM and the Mac We have input through this display text message is compared by it by bite So it checks if the first byte of the input message matches the first byte of the correct Mac And if it doesn't match it will return immediately if it matches it will try to compare the second byte and if it doesn't match it will turn immediately so this time it needs to To check one more byte we can measure with some more work so With this thing with the correct Mac for the please enter pin screen We can give you a quick demonstration of how this works in real life and for that we would need the GoPro That we already have Ah big GoPro, yeah So this is the setup here Here we need the computer with a green text on the black terminal alright here We have a normal cashier register. It's some windows XP software running here. We have the actual payment terminal These two are connected Through this Fritz Fritz box and standing here just some normal internal home network now There's also another Participant in the setup, which is the attacker In this case connected via LAN, but he could also be connected via Wi-Fi in the car Outside the street and so on so What we have running here is The attacker software when we will introduce now initiate a payment Through this cashier register the attacker as a man in the middle between these two devices will simply drop this message and Replace it with the first street card message You will pay with an with the card Yeah All right, please insert the card now. Yeah here We can also see we can already see the car data and partially censored for our own safety And and here's entered the pin already. So what you have seen it was a bit fast, but what you have seen was the pin he has entered Appeared here as soon as he entered it because it wasn't the real pin entry screen It was just our fake pin entry screen. I hope you have seen that you saw that on the terminal That's the first demo. That's how we steal the pin number I Did he move out attack a little bit, right? Can we show this receipt go pro while you're here? So This line in an in a normal transaction when you enter pin number is supposed to say zero card and instead this now says ELV offline So in some cases actually a parent, but who actually pays attention to these details, right? Right in addition to this this is means that the transaction has gone through with last shift without the pin however, we can also Choose our attack to simply fail the first time So it says like system failure or pin incorrect and we'll do a second transaction again with pin authorization That's fine or in bigger setups not the terminal itself prints the receipt But external printer that's connected to the cashier register and for that to work the terminal again Has to send the receipt line by line to the cashier register again without any encryption or authentication So we can simply replace the line with zero card or drop some lines and do whatever you want Very cool So that was an attack against the customer that is pretty much everybody here unless you really only ever pay was cash There's there's some other attacks that target the merchant instead so everybody who operates one of these terminals and according to the banks there's 770,000 such terminals in operation today in Germany So I guess at this point in time everybody who has even the tiniest of shops will accept cashless payments So let's look at that next so for the next attack we are trying to Get all the money that's been transferred on this terminal to our own bank account Again, we assume we have local Local access to the network, but this time we won't try to become man in the middle between the cashier register and the terminal But between the terminal and the internet in this case the payment processor By up spoofing again, so that we see Includes a message and defines this message in the specification to reset the terminal ID Which is basically the identifier that It says to which bank account the terminal is linked to we can we can reset and set this again with Password more on that we will show later If we have set this we will now Tell the terminal to initiate and it's extended diagnosed to the back end again Why are so we tell it why are the set BT protocol to? initiate a message on the Poseidon protocol we need that because when we reset the terminal ID The terminal will get reconfigured For the attacker terminal ID so for my one and this also means that the merchant banner So in German, it's the Hender logo the thing that's printed on the top of every receipt This would also be my one the attackers one, but we don't want that So we tell the terminal to make another transaction another extended diagnosed We will simply pass that through to the back end as a man in the middle and the response includes some limits for offline electronic cash and so on and also the merchant banner and this again We can simply swap we can swap with the original one So no one will get that this idea actually occurred And this is again possible because no authentication is implemented here now for the actual transaction and If the back end port is already the correct one, we can simply pass all the messages through so the back end port is Each payment processor has like one IP address responding for all the terminals However for both load balancing reasons or something like that They have like 100 different ports each port responses before 50,000 terminals But each terminal can only can only be managed by one specific port So if this port already matches we can simply pass from through every a payment done by this terminal will now Result in some more money in our bank account if this one doesn't match We as a man in the middle can simply redirect the messages to the correct back-end parameters And again Let's see it in action so what we have here is a Terminal we have configured it to be configured as another merchant you will see in the end which one it was Again, we have the attacker's PC that's running the malicious software and Now we will issue the the registration just that we are able to send safety messages to the terminal And now we will reset the terminal ID from the one that's correctly set to our own one The one we have got from our contract with a payment processor We are setting this terminal ID and now the terminal already gets its new configuration and Encrypted as you will see But it receives that So this is all happening with real terminals for real transactions. So Whoever is watching this at the banks. Thank you for not blocking us yet But we use the 3g network. So in case they have blocked the IP address range here. Oh Right, so Normally this thing you recognize that this would have been printed on the terminal itself And we can see now this terminal now prints as belonging to as our laps and Normally this would be the full terminal ID that we censored a bit and you can see this is the whole configuration And it's also configured to be able to issue prepaid cards Normally this would be printed on the terminal, but because that would be Pretty uncool because then you would recognize it. We transferred all the output to our own to our notebook Now we will start the man in the middle server for this last part exchanging the terminal banner we will change the logo and we will Now issue a demo transaction. So just like the cashier register software did we will now issue a transaction and As you will see this terminal now belongs to or still belongs to Can you see that put it on the table? Yeah No Can we switch back to the slides? Thank you So that's how you steal money from an actual merchant while in the store That perhaps be the first catch that you have to be in the store the second catch as Probably the ones following along noted is the attacker also needs to be merchant here You just change from money going to one merchant account From that to going to another merchant account, but you need to be registered as a merchant somehow, right? There may be a cash. I don't know how well set up criminals are with actual businesses but The next attack we're gonna show does not come with this cash It does not require you to be in the store and does not require you to have anything preconfigured and This is an attack on the Poseidon protocol remember that's the protocol spoken between the terminal and The payment processor, right? Take it away. All right. So now for the third attack In that case what we are taking a specific look at is the initialization routine of Poseidon This part is normally done at the payment processor when you get your terminal Pre-configured he has done this configuration to assign your terminal to your bank account to make this match How is this done? The terminal sends and Poseidon is initialization routine with a terminal it to the back end The back end then will get the configuration for that terminal ID send it to the payment terminal in An encrypted way symmetrically encrypted with a key only within the HSM and the payment processor has So far so good. That's the normal pre-shared key thing that we know However, what we have found is that this key this exact same key is used not in only one terminal But in many many terminals so what is left of this authentication is just a username the terminal ID and This username is public as you will see so The idea now is to have our own terminal that we got from eBay We got like three of them for seven euros including shipping cost costs And configure our terminal to act like just some random terminal somewhere for example in Bonn the mouse shop as we have demonstrated and At that point. I almost feel like apologizing because for this hack no actual hacking is involved. It's just The system is just broken in that case you will see so You just need a few parameters to Configure your terminal as another one and this is at first the service management password only service technicians should have The second one is the terminal ID of your victim and the last one is the Backend port that is responsible for managing your victims terminal ID So the first one, how do we get that you will simply Google and find it on the internet and some internal documents This one is the same across all terminals of one payment processor, so completely independent of the model Every terminal you got from the same payment processor the same password So the second one the terminal ID as you have already seen you can find it on every received and you can guess them as there are increment assigned incrementally second one and for the last one there are like Hundred different possibilities So just try them all and see which one of these hundred ports doesn't answer with a message saying I don't know you But with a merchant banner, so we all have all three things set and let's demonstrate it So for this demonstration, we have already told you we don't have to be at the set on the same network So and this is the terminal here for Ccc that we have shown you we will simply disconnect that it's not on the same network What we have here is a terminal And without any terminal ID, we just set that into factory reset This is how you would get it from eBay if the seller did a good job and put it in factory reset Alright the service password Okay, yeah, no cameras good Come tight store. All right. We have entered the terminal ID the back-end port is already correct And we will issue an extended Diagnose to get the new configuration And and once you're registered what? What once you register here? What can you actually do to to that victim merchant? We will show The prepaid top up so if the victim merchant has the prepaid Product prepaid feature activated we will have it activated as well because we are the victims terminal So what we can do is simply print and print Prepaid top ups and for example call our own premium number to make it to actual money or try to sell it So let's try that some O2 maybe 15 euros is enough. Of course we paid in cash Does anybody actually use O2 prepaid? Some somebody will will find this useful Also shortly demonstrate the second way to get money and this is simply to transfer ourselves some money There's a feature called refund, but it is completely independent from previous transaction So a refund is a transaction with a negative value and you can do this to any bank account. So Hundred yeah, I'm good Can we go back to the slides All right, that was that was pretty pretty fast So let's summarize what just happened Somewhere in Germany does a terminal configured with a certain terminal ID and that terminal ID says this terminal belongs to a certain merchant So everything that every money that's put into that terminal goes to that merchant account and everything that's paid with that terminal comes out From that account now Here's a second terminal and we configure that second terminal to the same terminal ID and It goes through a cryptographic process by which it it registered self with the back end This leaves the original terminal completely working So the merchant can still do in a shop whatever they want But it's a second terminal a complete clone of the first one that now can do the exact same things if you were to Send money into that terminal the merchant would get the money But if we do refunds or SIM card top up from that terminal the money comes out from that merchants account Right very straightforward. You saw what it took three little numbers all of which are easy to find right Based on a terminal that that we purchased on eBay. What's the maximum scale of fraud that somebody could take this towards? First of all, you don't have to do this manual on your terminal Everything we just did you can do over ZVT so you can script this and it's attractive to script it if you had a long list of valid terminal IDs Now I should know that these are assigned incrementally. So if you know one terminal ID If you know one terminal ID, you know hundreds of thousands of valid terminal IDs right, so You register your terminal over ZVT with one merchant at a time go through a long succession thousand stents of thousands and Send refunds or print top-up money from every single account In Germany through this Poseidon protocol probably you can take this to other countries too Poseidon's just one dialect of a of a more Internationally spoken Isis standard so chances are this works in other countries as well. So this could really be a pretty large fraud scheme That Fortunately hasn't occurred yet, and there's still time to fix it again those people at the banks, right? Summarizing over the three attacks we've seen so far So there's two protocols in Germany that are used for payments Both of them are severely broken and they affect Customers mostly in the store by stealing the pin numbers and max drives They affect merchants in the store or even over the internet. We've tried to Poseidon attack over tour works beautifully Coincidentally these these protocols, of course We are designed completely independently from one another they both are vulnerable because of the same root cause they share Secret keys across terminals you saw in the ZVT case that we needed to sign a message That signed message was valid across all the different terminals because they all have the same signing key in it We saw in Poseidon that we could just register one terminal as another one because all of them actually Properly authenticate to the back end cryptographically all of which was the same key though. So they're not distinguishable It's secure as long as every terminal is in good hands, which of course is a silly assumption in in a scheme like that So each of these These these protocols is severely broken and we should have just stopped our research here, but We wanted to get those keys and Dexter wouldn't be here with us today If there there went some hardware hacking involved So we snuck in a few weeks of of actual hardware hacking and next is going to tell you what he did Okay, well, you know make a works Yeah Let's go Yeah Let's talk about the HSM. I Did with the HSM which the HSM module is our research So the HSM modulus where all the magic happens. So let's see gray box you'll see On the picture above that's that's the HSM module and it's basically a smart card on steroids So it has a display directly connected as said it has a keypad connected and it processes all the sensitive data Yeah, of course you want you want to have these area at least in the terminal well protected So you want to have that separate from the application processor where all the insecure stuff happens There are a couple of protection measures for example one important characteristic is that the Static RAM the SRAM that holds the Secret keys is battery backed up So if the battery dies you lose the keys and that's just because it's It's simple to erase a battery backed up as from you just shut down the power Yeah around the model is a couple of switches and These switches if an attacker unscrews the case that you lift the switches and then you chip the temperature protection and Yeah, but that's no problem. That's easy to defeat there's a More elaborated protection measurement measure as well. So there's a mesh underneath these cap there's a metalized a thin metalized mesh that is printed with an conductive ink inside the inner surface of the of the HSM cap and Yeah, and if an attacker would drill or cut or even rip off the cap then you would trip the at hyper protection, of course We found an exploitable mechanical weakness in this particular Implementation we found out has terminals there and If you look carefully at the picture you see on the gray cap you see in the corners You see these little dents that says that is where and the The mesh is electrically connected to the underlying PCB. So there it's connected to the Circuit inside that measure a continuum. What in continuum money towards the message is a continuous Continuous monitoring unlike smart cards where you don't have a continuous money if they're off there off but this is always on and Yeah, the problem is that the connection is only in the four corners not at the size So at the side a side there is a possibility to enter the HSM the confined space with some metallic Peace or something and and furthermore these cap is doing the manufacturing processes It's glued on top of the PCB with a slightly rubbery glue and these glue leaves a small slot and we thought of Yeah, how can we? try to push something under it and probably defeat the temple protection and We found something here from the doctors basically that's a syringe. They need to be flattened that with a pair of pliers and indeed we managed to push that under the cap underneath the cap underneath the mesh in right into the HSM and We may experimentation we found a weak spot in our case It was just the power supply of the temple protection. We need to short out to ground So then it's defeated then it's off and then we can safely open the mesh You see the grounding clip on the left side. That's that's the short circuit of the temple protection temple protection detection circuit and We use the soldering iron to cut it because you want to avoid any vibrations, of course This is a delicate task and Yeah, then there then you have Then the fruits are exposed you have physical access to the flesh to the Astrum to the microcontroller and even to the j-tech and in case j-tech doesn't work and you're only interested in the flesh They are there ways to do it That's how we did it the first time Yeah, so Here we have attached the j-tech interface to the HSM and the HSM is still alive We have a terminal right there. You can look the HSM's the kind of working and Yeah, you can do All sorts of things you can of course debug you can do experiments to reverse engineer stuff And you can also dump the RAM and serum the SRAM Microtent some secrets in our case. We did a little experiment. We tried to use the HSM module as an oracle as you have seen before you need some max is the message authentication code for the Pin entry screen the screen the fake screen you've probably seen in the images that that was protected with such a Mac and Yeah, what you just do you This is the text thing you want to have signed you send it to the HSM with an obviously or wrong makes that's the 4141 you know that That's the wrong Mac doesn't doesn't matter which value that is We just send it in and that is the blue the blue stuff you see there is the text We want to have signed and then yeah matches them happily compares it to And says here Aaron doesn't match But no problem. We just hauled ccpu via Jtech dumps the RAM. We just look up the correct Mac. That's it then Yeah so much for the So much for the not so secure hardware security module and now It's there go back to Carson here. Thanks. Yeah, good job Yeah, just a bit of hardworking fun. This wasn't actually necessary for anything but I think it is a I Think it is important To know that this is possible to drive one Keypoint home. So in this next chapter, we'll talk about what would actually need to change For these protocols to be secure and one thing that cannot happen is for them to again bury some secret keys in some some Security module that they give hundreds of thousands of copies out HSM and generally the idea of security by obscurity is broken and we need a better approach here What exactly do we need though? Let's first revisit why these two protocols are so severely broken as I said earlier both of them have the issue of Keys that are spread over a very large population of terminals some of which may be secure Others are very insecure like this ancient model that we are looking at here The weakest link of the system then obviously determines the protection of these system-wide keys The system-wide keys that play out very differently in these two protocols here though. Remember in ZVT There's a Mac a message signature Which can actually be made very secure even with a system-wide key as long as you're using public key crypto If only one person can sign messages It's fine for everybody to have the same public key to verify the messages now in this case these terminals I guess when when they were designed I didn't hear about this great invention of asymmetric photography And they're using symmetric Signature so designing keys distributed in seven hundred some thousand copies throughout Germany Amplifying the problem and first of course amplifying by putting them in shitty HSM's that are well Not just a vulnerability to dexter style hacking but to simple timing side channel attacks On the Poseidon side of things It's a little bit cleaner. We're not talking about cryptographic signatures here, but about authentication and Look at this as online banking right each of these terminals is kind of like an online banking login to a merchant account And if they're all using Similar user names and everybody uses the exact same password Cryptographic key in this case this could not possibly be secure This cannot be fixed with public key crypto as long as everybody uses the same in that case then digital certificate This is not going to be secure either in both these cases though. We need more individual keys as at least a mid-term goal right fortunately these protocols do have a provision To distribute a new key to a terminal and this mechanism could be used to give a different key to every single terminal So the the road ahead should be clear some of the back-end systems probably need to be adapted to to work with individual keys per terminal It's already clear how we would get out of this mess give a different key to every single terminal That's not gonna save us in a long run when people start attacking the HSM chips again individually and then defrauding these merchants individually, but it would at least get rid of the possibility of very scalable fraud Against tens of thousands hundreds of thousands of merchants or consumer in this case So the long-term goal is clear better protocol the mid-term goal Needs to be individual keys for each of these terminals and a short-term goal could be things like switch off functionality that you don't actually need how many shops do need to print sim card top-up certainly not every hotel and Other establishments how many stores do really need to refund through a card, right? Maybe you just do refund and cash and switch off that functionality to Similarly in ZVT how many merchants actually want a terminal to be reconfigurable over a network with no confirmation What serve on the terminal perhaps a little is this okay message and somebody has to press a button Would already fix a lot of this so switch off what's not necessary and Detect suspicious behavior. You can read faster than I can speak you probably already went through this list So I'll I'll save you that I promise a couple of times a more international perspective on this everything we discussed so far is As is focused on Germany and some neighboring countries depending on which of these protocols it is But we suspect very similar issues to exist in most other countries The ZVT alternative that's used more internationally. It's called OPI the open payment initiative And that is a much newer protocol that Still does not have any encryption though whoever sought in 2003 to specify a payment protocol and not to add in an encryption Please send me Neymar. I I'm curious They did however do do the what would seem smart thing of leaving out functionality that nobody needs anyway And in fact functionality that we are exploiting like remote manageability of these terminals Though the few instances of OPI we have found in Germany, however, they reintroduced that functionality as custom extensions So apparently the terminal manufacturers they they find it very useful to have remote manager ability And if the protocol doesn't Give it to them. They will introduce it as an extension So exact same level of vulnerability in those few instances that we looked at of course the research community at largest is is needed to verify this in different countries and And just with a little bit of wire shark on the wire You typically can Similarly for Poseidon as I said earlier This is just one dialect of a of an Isis standard that originally came from from MasterCat and visa So this is just suggested payment back-end protocol pretty much worldwide And we have we have seen encryption in some cases not encryption in others It doesn't matter though. Remember the attack actually goes through a full cycle of authentication It establishes all keys. Well, it does all of this correctly, but everybody has the same key Well, we're yet to see is a protocol by which you could exchange keys with these individual terminals He's a put the key in or find which key it's using to establish individual keys If anybody has more information on that definitely look us up But as far as we are informed that there isn't a single instance Where this is a protocol actually is used with a meaningful key management protocol and where This would at least have the foundation to be secure, but again you the international research community over to you for looking at this in your countries With that to to to quickly conclude two protocols Used for payment in Germany both of them to be considered insecure and Very outdated They both have the same root cause something that fortunately can quickly be fixed So there is time to improve the system before actual fraud hits We as a research community should should keep up the pressure for them to actually do that But we as customers we should not believe them anymore And when they say you must have given your pin number to somebody hence this fraudulent transaction on your Account have been a number of cases like that in Germany this year And I think it's time to show them who's really responsible for the security vulnerabilities and For leaving them open for so many years. Thank you very much We have seven minutes for q&a thanks to our speakers again for a only theoretical thread on the payment systems Of course in a strictly lab environment as the press wrote Please leave quickly and quietly through the side doors now. So we have five minutes of q&a and Mike two starts how did you handle the question of disclosure? So did you do full disclosure responsible disclosure? How much time did you give them? We went through responsible disclosure, I guess Meaning that we in detail tried to explain all of these attacks to an audience that we thought could fix this About a month ago Right, and have you seen any reaction to that like have they tried fixing it? I'm sure somebody's working on a fix, but Nobody would tell me Okay, and we have one questions from the internet So can you say if there's an easy fix like just flashing a new firmware and into our terminals Yeah, like flashing firmware to all turn it's an easy fix Yeah, you have showed the fixes these are The difference between this research and the research done three years before is that this are now flaws in the protocol So these need new protocols new New versions and you yeah, that's it. So these are no implementation flaws right now But would you have to scrap all terminals and by or construct new ones? I I think the honest answer is that Criminals are slow too. So this will this will have to be a somewhat longer journey In which we first replace the system-wide keys by individual keys That would already help tremendously in making it less attractive to do these types of off attacks But then in the meantime work on better protocols So we don't keep finding ourselves in a situation where it will take years to fix protocols Well, let's use those years ahead of us to do that Thanks. Okay much from eight, please How many tries to take to get pulling the keys out of the terminal how many boxes you have to blow Three or so Yeah, I mean the first one was surprisingly in immediate success We managed to restore the s-trum is out destroying it Second one we broke immediately into third one had issues after it, but we managed to fix it So you didn't like you didn't wipe any keys bypassing the mesh Didn't understand acoustically sorry when you were bypassing the mesh you got that the first try Yeah, I tried at the first time. Wow So like a bit of preparation and then one one hour of actual work Well, you destroy the first terminal but for just looking at how it's built, right? Yeah, yeah, we knew how it was made up because we took a few apart before of course Not with the intention to do that just because they're broke and then we took it apart to look up to read Also flash this bug-bonded thingy that was one of the very first ones that broke Okay microphone seven, please Would you please briefly describe what will do the terminal in case if Some transaction wasn't processed by the bank. What kind of information it will store in a memory and how long Hmm store bear and I don't think the terminal stores anything. It's pretty much stateless. It receives a command It looks up its configuration like terminal ID it pushes it down to 8 hsm to get signed or get a pin number Pushes it over Poseidon and forgets all about that transaction So it's not trying to recent the transaction again somehow later Good question this this is not part of the attacks you have demonstrated But what happens is that normally you will do an end-of-day command or a cousin schnitt in Germany And there are all the transactions that have been accumulated Throughout the day will be sent to the payment processor and this is the exact moment Where all these transactions are then sent by the transaction processor to the bank So at this point for example, no reversal is any more possible reversal like and reverse one one purchase on the same day Because then the bank has already the information and then no no information is stored anymore on the terminal If this one was successful Okay, thank you and a more one more remote question, please. So it's the communication that You used in the man in the middle attacks also susceptible to replay attacks. Can you just? Do it without a terminal if you recorded the conversation between terminal and processing server Sure, we can inject messages is that VT messages most of them are not actually protected with a Mac For instance, you can query a Mac stripe with with with no protection However, there needs to be somebody in the store who expects you to do that, right? So it's convenient to just be man in the middle in an actual transaction because you know There's somebody waiting for you to stick in the car. There's a customer waiting to stick in their car So you wouldn't get that from just sending random messages. There's just nobody there with a card Okay, and one last question a quick question from microphone one Yes, you said there's the possibility to give an individual individual key to each terminal So you have an identical terminal to another one So if the payment processor sends out individual keys to each terminal and there are two of one terminal What will happen? Yeah, good good question So if if the fraudsters first take over all the terminals and you then send individual keys It's not gonna help you get to be ahead of the bad guys here Okay, thanks again to