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


Chris, thanks for having me here. I'm just in Singapore for a week working with some artists' drama box in Chinatown and consulting with them on technology and in practice in their artwork, and I looked online and I saw you guys have a JavaScript meet-up and so I thought, and there was one on Wednesday and I was like, oh, I'll put in a talk and you guys kindly let me come along and speak. So thank you very much. Yeah, so I'm going to talk about something I've been working on for a while now, which is decentralized systems on the web. So do you guys know what WebRTC is in general, some of you? So WebRTC is basically a way of two computers, two browsers, talking directly to each other over the internet, rather than, you know, typically when you have like a chat program, you'll have your browser, two different browsers and they'll talk via a server.  So it's a very complicated protocol because it has to negotiate. Both ends have to figure out a pathway behind through firewalls and stuff like that. But when you get it working, it's pretty magical because it's, yeah, like just literally two browsers talking to each other. And so, yeah, that's what I've been interested in and building stuff around that. And yeah, so this is what I'm going to cover today. I'm actually going to start with a demo. What could possibly go wrong with that? Then I'm going to talk about how to build your own version of the, using the library that I've developed. I should say, if you want to read more, that's the URL at the top, bugout.network. So that's where I'm doing all the decentralized stuff and writing about that and my email and my Twitter account, if you want to stay in touch. So, yeah, then I'm going to talk about how you can build stuff using this library. And then I'm going to show you a bit of hardware at the end. And then I'm going to talk about some of the limitations, like things that don't quite work that well yet with this because it's quite new technology. The first speaker you were talking about, people just jumping in and adopting new technology. Well, no one should do that because this is like very unstable. And anyway, this is my living room back in Perth. So five hours flight south of here. This little machine is sitting there. Actually, this slides a lie because it's now in near my kitchen because I had to move it because my wife said it was in the way. But anyway, it's in my house. And there's only one of what I'm about to show you in the whole world, like this type of server running on that. But I think maybe one day a lot more people might run this kind of thing. So if you go to this URL, you'll see a message board. And a message board back end is pretty simple generally. So fundamentally, it reads some data, which is the list of posts that people have written. And it writes some data, which is writing new posts to the database. And then it talks to browsers to let people do those two things. Usually the back end to that, like what I was saying before, would run on a VPS server. So Linux machine somewhere in a service provider's warehouse on the internet somewhere. Here in Singapore, Digital Ocean have a presence, I think, and Amazon. So you guys get really fast ping times to these VPSs. My own mail server is here in Singapore. So let's check out the message board. I guess some of you might have scanned that by now. Hopefully it's working. Where's my mouse? So this is the message board here. Yeah, some of you have connected. I can see four people. Oh, lots of messages. It'll probably crash. So obviously, if you look at this URL up here, it's loading the actual page and the code from GitHub. And GitHub doesn't have a server back end. It's static pages only. So all the data here that you can see is actually being sent directly from your phones to that Raspberry Pi that's sitting in my living room. That's where it's writing the data and reading it off to print it here. That's probably the hardest workout it's ever got. Yeah, so I've said all that. Yeah, so that's what's going on. It's going from your browser directly to and the way the reason it can run on a Raspberry Pi is on this Raspberry Pi, yeah, on this Raspberry Pi. It's actually running not just like in a shell or in the background. I've actually got a browser running headless on the Raspberry Pi, and that's what's running the server back end. So the server is running inside the browser kind of thing. Sorry, I'm just jumping ahead of my notes here. So yeah, so that's what's happening. The page is being read from GitHub. Then the data is going back to a browser that's running on this Raspberry Pi in Perth, and your computers are talking directly to it. So what does this mean? What this means is, well, one side effect is that I have physical access to the Raspberry Pi and the data on the message board. So I can physically secure it if I want to. I could put it in a safe in my house. And you can do the same kind of thing if you had a computer, a laptop in your house, and you had a reverse SSH tunnel. But I think what's exciting about this is it is really directly browser to browser. You don't need to be a sysadmin. Anybody can visit that tab and run their own message board. So if you look at the bottom of the tab here, if you scroll down, it says, fire up your own copy of the server. Now, if I launch this, now I have this server running on my laptop here. And if you connect to that one, then your phones will be sending messages directly to my laptop. And the laptop's running in the back end inside the browser tab. So it's a very different paradigm from how things normally work. We have a server in the cloud, and your browser talks to the cloud. So what's the point of this? I've been interested in self-hosting movement for a while as a model of computing. Do you guys know what self-hosting idea behind it is? It's like basically running your own stuff. So running your own mail server, running your own calendar server, instead of relying on Google or whatever other provider you want. Yeah. So instead of doing that, you have a VPS somewhere and you'll run your own mail server. And I like this idea. I like the idea of users being able to control the software. So instead of having upgrades forced on them by a company, they can decide when they want to upgrade. And they can decide, like I was saying before, with the Raspberry Pi. Like my mail server is on a VPS here in Singapore, but if there was the equivalent kind of thing that you could run on your own Raspberry Pi, you can literally have your mail server running in your living room. And all of your emails go to your living room kind of thing. And I kind of like that idea of having sovereignty over your own data. Yeah. And the other thing is that it's easy for us tech people to run servers on VPS computers. Like a lot of people here probably run Node.js servers. And we know how to do that. We know how to SSH in or launch a Heroku instance or deploy something on AWS or etc. But a lot of people don't. And it's doing things like setting up SSL certificates is very complicated. Getting a domain name is complicated. And I started thinking about what it would be like if it was as easy for an ordinary non-technical person to run their own servers as it is for them to run like phone apps. So you can install an app on your phone. You're probably your parents. Maybe sometimes they get you to do it. But your parents could probably even install an app on their own phone. And yeah. So what if it was as easy enough for your parents to run their own servers? So what if your parents could do things like run their own calendar server or they have some reading meetup and they could host the forum system for their reading meetup themselves instead of having relying on some third party or a drop box. They have maybe they're part of some other organization or at their work and they want to run their own drop box. So currently things are very centralized. And it's interesting to think about what happens if that's decentralized more and we can all do our own kind of stuff. So that's what's possible with this WebRTC kind of architecture. And so this library I built is called Bugout. And you can find that on if you go to bugout.network or my GitHub username is chr15m slash bugout. You'll see the library as well. And what it is is a layer for doing networking and cryptography. So getting the browsers to talk to each other securely. And it's built on top of something else called WebTorrent. And WebTorrent is basically like implementation of BitTorrent that runs in the browser. Because it runs in the browser it's got a bunch of limitations. And real BitTorrent is a lot better than WebTorrent. But yeah, so I was trying to make that a bit more accessible and more useful. So the way Bugout works is to treat the WebTorrent info hashes as chat rooms. So like when you download a torrent on the internet using BitTorrent it has something called an info hash which is like a cryptographic set of numbers that identifies that one file. And that info hash is how all the other computers on the internet can find each other to share that one file. And so this uses a similar kind of idea. There's a room name which I'll get to in a minute. Yep. And all the other thing Bugout does is encrypt things. So traffic between nodes is encrypted. Because you're sending actually WebRTC is already encrypted. But in this case because you've got browsers connecting to each other and you might get a situation where you have someone in the middle listening. So this adds another layer of cryptography on top of it. All right. So if you Google or if you search for maybe use duck duck go. If you search for build a decentralized chat in 15 minutes you can find an article that I wrote which is basically what I'm about to show you now. Which is how to build your own stuff. And I start with the example of building a decentralized chat. So two browsers no server back end and the two browsers are sending chat messages directly to each other. So you start with I know you guys are JavaScript developers so you probably all know node and you can NPM install Bugout and do this stuff that way. But I'm just going to show it with script tags because you know I'm old school and I like the idea of all you need is a browser and the JS file and then you can build something. So start with a basic index file index.html and load the library. Once you have the library loaded you open a new script tag and create a bug out instance like this. So it's very simple. Be equals actually that's got a typo in it. It should be new bug out. So you create a new bug out object and every instance that you create in every browser has its own ID. And you get that doing B dot address. So that's a base 58 encoded string starting with the letter B. You might notice this address looks a bit like a Bitcoin address. That's because bug out uses a similar kind of hashing and encoding when it generates the key pair. And when it shows you that that's basically a hash of the public key. So when you instantiate a bug out instance it'll start reaching out into the network and trying to find other bug out nodes using the same room hash. In the instantiation here we haven't we haven't passed an address that it should connect to. So the default in that case is to connect to its own address. And the reason for that is if you have a bug out node running you can then say you can give out the address to other people and when they connect they put that into their connect string and they'll all connect to that. But you can also use a generic room name so a shared room name. So you might have an application here we've got one elite secret hacker room and every bug out in the world right now if you wrote this code in your browser your instance would connect to all the others that have that same room name. So once you've connected you can listen out for messages from other nodes by binding event handlers. This is a classic JavaScript way of doing things. So this first callback will fire whenever a new peer node is seen by your node that you've created and the second callback will fire whenever a message is received by your node from another node. Messages can still get through from peers in the same room even if the peer doesn't directly connect to them because they use a gossip protocol to reshare everything. So if you have WebRTC isn't perfect and maybe two maybe you've got three nodes in your chat and this one can see this one and this one can see this one but these two can't see each other the bug out protocol has a built-in gossip system so it everything is overshared as much as possible so there's high redundancy. Finally to send a message it's pretty simple you just do b.send and obviously you can like do a JSON encoded packet or any other kind of thing you want to put in there. And that's basically it. These are the simple components that the message board demo that you saw before is built on it's just sending and doing when it receives on message it writes it to local storage and that's yeah so there's a bunch of other things you could do with bug out like RPC which is remote procedure calls but this is the core functionality that enables and the main thing which is browsers talking to each other in a decentralized peer-to-peer way. So again if you want to go through that tutorial in your own time you can look up build a decentralized chat in 15 minutes. So I was thinking about all this stuff and one of the big problems with building decentralized systems is okay let's say you build a something like Facebook but it just runs in everyone's browsers and there's no back-end server what happens when if you I've done a bunch of posts and then I close my browser and I go to sleep and then my friend is looking at my posts and he can't see anything because the data is not available it's on my laptop that's closed and so then I was thinking about this idea of a box so I made this thing called the bug out box which is you can connect to it from anywhere in the world using its it uses the bug out library underneath and you can get it to do things like run server apps which all it does is it's running in in a browser on the Raspberry Pi and it pulls down a piece of JavaScript and runs it locally and you can also get it to torrent do web torrents so you can share data files onto the internet in a highly available way even when you're not around so you just leave the box running so really it's kind of like I'm trying to productize this first thing that you saw here that's in my living room already so try it I've been thinking about a way to make that more available to other people and at the moment it's very beta so I don't know where I'm going with it but the source code is online um yeah so if you want to find out more about that that's at bugout.network slash box so that's all pretty interesting I guess took browsers talking to each other what are what are some of the problems with this it's very it's very new technology web RTC and one of the problems is web RTC signaling so when you have these two browsers that need to find each other on the internet they before they can talk directly to each other they need some way to rendezvous and to negotiate the connection and that actually now is very centralized so the recommendation by the people who like the big companies Google and Apple and that who designed web RTC is to run a signaling server so it's like this centralized server and you're if you're building a web RTC application you use this centralized server to communicate directly um that to me kind of like it's still more decentralized than not doing that than not having web RTC but that signaling phase means that for example if you were hosting us hosting a chat that was directly browsed a browser and some government didn't like what you were doing they could close that signaling server and none of the browsers could find each other after that point so I've been thinking a lot about how to solve that and at the moment I'm working on something which is like a web RTC signaling server mesh so it's like you run a node and on in the on the internet in the back end there's all these servers that form like a cloud so you can't shut them down because anyone in the world is kind of like the bitcoin network where anyone in the world can run their own one and they all interoperate and if one gets shut down you could still connect to other ones but so that's at the moment that's vaporware I've only written like the just started that project but uh that's where I'm going to going with that um and the other downside to this is cryptography in the browser and key management which is related uh browsers are really leaky you know like they're very good at uh it it's very easy to exfiltrate data from a browser if you're like a security engineer and um they you know you can do things like piggyback people's passwords on css requests and that there's just lots of vectors for getting out there so um yeah if if this becomes a thing where it's more common for people to write systems that talk directly to each other on the internet browser to browser there'll have to be some of those security issues solved but my feeling is it's better to move forward on the on the idea and then hopefully the security um from the browser vendors would catch up uh and the other thing which I discussed already is where to store the data and that's uh yeah I think the solution to that is people in the in the long run I can see people running in their own house actually like people used to everyone had a pc at home that was sit on their desk I can imagine people again having a little box that has their like mail and calendars and their dropbox and all that kind of stuff so I'm hoping that that's where things go in the future so we don't have to rely on big companies who sometimes cut people off or whatever um and the other limitation that's not up here it's not really a limitation but it's something someone flagged um when I gave this uh a different version of this talk at a security conference is right now WebRTC is actually um quite invasive in that when you guys connect to that message board um the you can't the WebRTC connection is quite opaque you're like when you you know when you open your console and you see the network requests come going out WebRTC requests aren't in that and to me that's the browser vendors should really do something about that because it's not great that uses I I'm sure I'm sure that there are advertising companies right now using that to fingerprint people like opening up WebRTC requests back to their own servers and it people don't know that it's happening because it's not very visible um so I hope that that gets addressed as well um yeah so you can stay updated with what I'm working on uh at bugout.network or follow me on Twitter um feel free to email me or anything if you'd like to discuss and uh thanks very much for letting me come and talk at your meetup what is it called WebBundles oh wow cool how do you spell that WebBundles yeah so I've got and actually uh the other two weeks ago digital ocean deleted my server here in Singapore um and uh then sent me a $15 uh credit as as like sorry just like erased the whole thing anyway but uh luckily I had backups but um yeah so that's that's one of the problems is I have I I'm personally running the signaling server for the bugout stuff uh because it's built on a web torrent what I'm actually running is a web torrent um tracker and luckily also in the message board and the other stuff and the library itself it has two other trackers that are run by some of the other web torrent lead devs so it still kept working even after my signaling server went down so it is somewhat it's it's not as fragile as it could be and like I don't know those guys I don't know who those people are running those things which I think is a good thing that's that's that's part of decentralization is that like people independent of each other running these things but yeah it's I would like that to be a lot more decentralized than it is the signaling aspect so so right now the aesthetic front end is basically on github and then the connection is initiated via the RTC via that server via yeah no so from so your browser goes to github and gets the page and all the code and then the page is running in your browser and your browser makes a connection to the other browser in via the signaling via the signaling server that's right yeah and so if when I finish that signaling mesh idea what will happen is if you've got two different people with different browsers and they want to chat this person might connect to this signaling mesh node and this might connect to this one and then on the back end they use bit torrent to communicate with each other so it's much more resilient and if any if any one of them goes down it doesn't matter because the whole cloud is still working yeah so my brother works for the company that runs ipfs so yeah we're always fighting dirk is his name yeah yeah ipfs looks cool it's um it's interesting the way so what ipfs is like distributed file system so when you put a file into ipfs it's kind of sharded and run across a whole bunch of computers and I don't like that idea because I don't like other people and their computers so um no I'm only joking I like other people but it's like to me that seems quite fragile I know that they've got lots of awesome maths and stuff that solves it but then I really like the idea of when I put a file on a computer I know which computer it's on and especially if it's like actually my computer so like a vps is good but then digital ocean can just delete my droplet whereas if it's like literally in my house and um my kid flushes it down the toilet then it's my fault but it's like it's you know it's within my I can I can prevent that from happening I think there are two big companies but two companies here and it's important to work a lot with webRTC um one that's the entire intolerability testing for webRTC across browsers so long because it's a horrible problem when it comes to complexity to make sure webRTC works from different versions of browsers to different versions of browsers different operating systems and different firewall configurations and all that kind of stuff and there's another one that uh of officers for signaling and this whole firewall mitigation strategy and so on um to be able to run services is a really quality video right around webRTC and some data is kind of like a side effect of that yeah that's the funny thing about webRTC isn't it it's kind of like they built it so that they could do video chat because it's just much more efficient to send the video straight from one browser to another but then they kind of like left this data channel in there and to me the data channel is what's really exciting it's like you can have it's a socket between two browsers yeah have you used the ipfs stuff I haven't used the ipfs stuff I've had long conversations with a friend of mine who works all right about it and there were like a lot of interesting strategies in it especially it comes to caching because every content has a mini cache meaning if your computer downloads like content from friend like there's a certain cache on your site now meaning the content if labeled available is still kind of available from your cache meaning if your computer goes down because I loaded it from you with that specific version um people can still request it from me instead of from you because I have a cache copy and and having all that built in like a really distributed system for data storage yeah and it's fascinating yeah you know people can see always the limits yeah I mean I think yeah for what it for what it is I think it's kind of like aiming at a different area and also you know like my stuff is really experimental I'm just hacking on things whereas they ipfs are like doing it properly like they're really engineering it and they've got a big team and they've they've got like every language you know whenever I look at their whenever I go to one of their projects it's like there's like seven different github repositories with every language implemented so it's like yeah a big project yeah your friend probably knows my brother because he works at protocol labs yeah no it doesn't just like it probably would if you were doing something that was data heavy so um yeah if you wanted to do like video or audio I would say you would switch to the actual web rtc protocol because this is like layers on top um and then have the two nodes talk directly and use the what what that's good for but uh yeah no it it probably would be a concern I mean my main interest in developing this is is like the idea of social networks and chat and stuff like that so protocols that aren't super bandwidth heavy um yeah so there was somebody who had a decentralized social network and uh New Zealand government they can't get implemented in music players you the music player where like the moment you run an application your music becomes available and everybody can just stream it from you wow like so shared playlists and so on and so on like so it becomes like a social network around music where if you have somebody a friend like boom yes your friend's music and you stream it in a direct way via web rtc and you build this as a um but it was built on top of somebody else's work already to build a social network completely distributed is that the um there's one called scuttlebutt I think yes that one yeah there's also another one uh on top of something called gun with two ends yeah and that's built by Malmo Marti who was the first committed to the bitcoin code base before like after Satoshi Nakamoto so um yeah there's a Wow It was very fascinating but then there's no marketing money there's no company behind it and so on and it was like just getting a big push anywhere um so it's maybe not as interesting because the people making good music might be on it do you use this to like tunnel API requests to your local server like running in your browser I haven't but that's one of yeah that's one of the things I think you could do with that bug out box idea is like have the services running on the raspberry pi in your house and then you could get tunnel packets so right front ends that run in the cloud and then they talk to your own machine yeah yeah well uh yeah so oh I see what you mean so if you had an HTTP server running on the Raspberry Pi and then you make like a request through web RTC and then it comes out as a get request locally and then goes back in and yeah proxying it you could do stuff like that I mean yeah no and I think one of the interesting areas is also like internet of things I mean I don't like buzzwords but uh having you know a raspberry pi or something like that um and it's got the pins that you connect to physical devices and then you can you can have a situation where you can have a browser that talks directly to that controller controlling physical stuff without having to have the server infrastructure so you could just make it a lot cheaper and I think that's that might be one of the reasons why there's a lot of like activism around decentralized web and re-decentralize the web and all that but I think one of the reasons it might actually end up working out is because it because the economics of it are good so if you're if you're building like a competitor to Slack now and you tried to use this kind of stack you would you would need way less server infrastructure basically you can replace a lot of what the server does with cryptography so um yeah make a cheaper version and uh yeah yeah no they're just very very long so like the probability of two IDs colliding is like so astronomically it's the same as like bitcoin private keys um well yeah so yeah you could oh yeah you could do custom room names so the id comes from so every bug out node has an nacl key pair and you cannot choose the public key like because that's the whole point of how cryptography works you can you can take a seed which is a random string generate a private key and the public key will come out of that but you can't decide what the public key is that would take like the lifetime of the universe to choose your own public key but you can what you were saying before is right you can have a room name that's not the public key of either node or any node and all the nodes use the same room name and that means they connect together so if you're building a chat application that's what you would do like if you're building a chat for your family you would say to your whole family okay this is our room name um and everybody would type it into their phone and they would all connect to that one room name but they wouldn't be connecting to a server they would be connecting to the pool of all of them no it's just a big namespace so if you if you use a a key that anyone can guess you'll get all these other nodes joining in so yeah so I haven't addressed that part but what you would probably do is like some kind of you would hash you would take a password and do key stretching and then use that whatever that's generated and hash it with the room name and then you'd use that so the whole family knows the password and the room name and it would generate something unguessable um there probably is no I mean I haven't I that's something I should should know and I should have tests around but I don't thank you oh yeah cool thank you very much