They both are from Munich, from Munich TCC, Hackerspace, and they have yet another talk about lockpicking, I guess. And this time it's about Bluetooth lockpicking of hotels, which I find very interesting. So give a big round of applause for Ray and Emha. This is not Hackagepity, but thank you. Okay, so welcome to our presentation about Bluetooth lockpicking. Who of you did a short race of hands did already lockpicking? So who did Bluetooth lockpicking? Oh yeah, you're perfectly right here. We'll show you how to get into this, and it's a lot of fun. Okay, so first, who are we? For the people who don't know us, Ray. I'm a security researcher, lockpicker, interested in technology and of the Moussi Sisi. And for some reason, I spent many, too many nights in hotels which led to this research. Yeah, hi, I'm Michael. I'm basically a lock nerd. I have been collecting locks since I was a little child, and I never stopped doing that. When I was young, of course, they were mechanical, so I started lockpicking. I joined Sportsfeuner Spertechnik. We also have a tent here in the village, so you can improve your lockpicking skills there. But then all the new locks basically became electronics. So I became an electronic engineer and continued to do that. And yeah, this led to Bluetooth, finally. Yeah, we already had this presentation in an earlier format, a small conference in Vegas, but we were a little worried about their bandwidth capabilities, so hopefully now with MediaCCC we got a good provider to get this content out to the open world. So what is it about? We're talking about smart devices or so-called smart devices using Bluetooth low energy, and we'll show you how to analyze them, how to hack them, and probably if you're building such things, how to build them in a better way. And of course, we'll tell you about vulnerabilities. We found that way, starting from cheap padlocks, some prior research, and then go to hotel systems, which is the newest thing we discovered here. So we give a short introduction about Bluetooth low energy, how these systems work, how to analyze them, and at the end also tell you a little bit about the responsible disclosure process we had with the hotel vendor affected by this vulnerability. Okay, so how does such an ecosystem look like? You basically have a lock, and this is communicating to your smartphone using BLE. But of course, the smartphone is also communicating to some backend in the internet where it gets key data or permissions or stuff like that. So what are the attack vectors and such a system? There are various. For one, you can attack the hardware itself. So on the lock hardware you have electronics, you can read out firmware, you can do side channel attacks, probably power analysis to get out AS keys and stuff like that. You can insert wires sometimes to get to the contact points for flashing or reading out the flash without opening the device. And there's mechanical attacks like vibration, shocking hammering onto it, magnets and stuff like that, attacking the mechanics itself. On a smartphone, I think this is something many people here are familiar with. There might be malware, and there might be distance frauds.  And of course, on the internet API, there is a web server. So web servers have weaknesses, API implementations have weaknesses. There might be wrong authentication or no authentication at all. So this is also a big part. Lots of research has been done there, but this presentation is not covering a lot of this end of the ecosystem. What we will be starting looking at is the connections here. So we have a BLE connection between the lock and your device, and we have an internet connection between your smartphone and the backend API. And both of those can of course be sniffed. You can machine the middle attacks them, and you can do impersonation of one of the two sides of the communication. So taking this all together, there's quite a few attack vectors in such a system, and surprisingly, those systems often fail in some way. So BLE in a very short introduction, as I said, is Bluetooth Low Energy, and it was designed as a cheap alternative to classical Bluetooth. So it consumes less power with devices running on battery and stuff like that. It is part of BT 4.0, so it's out there for quite a while. And for people familiar with classical Bluetooth, it's quite different. So the use cases are mainly devices connected, so-called IoT, but usually they don't have an own IP address. They communicate with the smartphone or other device having an IP address. So the various things like locks, light bulbs, we heard about sex toys, I think at Congress, heart rate sensors, stuff like that is using BLE. But what's about the security of BLE? I think there's also a lot of prior research on this. One of the first papers on the Woot 2013 conference was called with low energy comes low security, and that's basically true. So there are secure options like an out-of-band or BT 4.2 elliptic curve pairing, but they are very uncommon. So usually you can just sniff these connections with easy measures. And so the application has to provide the security for the system, which often fails. So how to find out these vulnerabilities? So we're looking at the BLE layer now. First, if you have such a device yourself, you install the app on your phone and you can yourself analyze your device speaking to your lock or whatever. So on Android, there's a very easy option. You just enable the debug mode and activate in the debug menu the HCI snoop lock. So then it writes a BLE pickup file to your file system. On iOS, there's a similar possibility. You can download a Bluetooth debug certificate from Apple. This is for a few days valid. You install it and your device starts to lock the BLE traffic. So what you then do is you use your app like you normally do.  And I would recommend writing down time stamps of various actions. So like at two minutes, whatever, I opened the locks and I closed it so you can later correlate that to your Bluetooth event. And then you get your lock file from the phone and you can just load it into tools like Wireshark. Wireshark, I think many people here know, has support for BLE. So it will help you decoding it. You can see here the sender in the receiver side and it decodes the Bluetooth protocol stack. So it shows you what kind of request is it where in the layer is the packet and also shows you which is most the interesting part, which data is written to which Bluetooth handle. So here you find the data of the Bluetooth communication. So that's what you do with your own device. But if you want to attack a system or if you want to see if it's a real possible attack, you have to sniff the BLE from the air. So it's relatively easy because there's only three advertising channels where you have to listen to to get the connection and just cheap sniffers out just starting at like $25 like the Adda Bluefruit, which I'm pretty sure many people here have, or the Ubuntu's one, which has a few more capabilities. Both of those support a Wireshark live view.  The drawback of these devices is you only have one advertising channel and if the device you're sniffing doesn't use a standard hopping sequence, you probably miss the start of the connection. So these tools are perfectly fine for proof of concept. If you want to see, okay, I really can sniff this data. But if you want a more reliable attack, our favorite tool is Beetlejack. Beetlejack by Damian Cockwell was released, I think, at Blackhead and it provides firmware for cheap BLE USB devices like the BBC Microbit. So those can be bought for like 15 euros or something and it flashes in firmware on it or the BLE 400 boot or 400 board or even the Addafruit tool. So it supports three devices connected to USB, setting each one to different channels so you now monitor all advertising channels and basically get every connection every time quite reliably. And these tools can do much more than just sniffing. They can, for example, hijack attacks or relay data but we focused on sniffing here. So if you set this up, or I set it up like a very creative way that works basically, Microsoft that looks ugly and builds a quite nice setup using Raspberry Pi. So this is an autonomous sniffing setup running on a battery. You could fit it into a smoke detector, put it somewhere, have it running for a few hours and collect data. There's also a new tool out there called Mirage. It is the author that he looked at the other tools and tried to build something better. It has probably some more capabilities, especially in the part of mandible attacks or something like that. But with powerful tools, there comes complexity. So for starting, we still recommend using the Beetlejack tool. But if you hit a point server, it doesn't help you. Have a look in Mirage. It might be a tool of choice. So now we know how to look at the Bluetooth layer. What's about the backend link? So it usually is TLS encrypted with modern apps. There's very, very few apps still using plain HTTP to talk to the backend.   To make it clear, this is not an attack you do on other users. This is something you do to get your own traffic of your own app analyzed. And I really can recommend you doing that just to look what all your apps are doing in your system.  You just install it and say, I trust this CA. It was the same in Android. But starting with version 7, Android apps don't trust the system certificate store anymore. So you have to, or the difference shape between two certificate store. So you either have to root your device and just replace the original CA store. Or you can, if you for some reason can't root your device, modify the app. So you have to unpack the app, add a network security config to it telling you, telling it, I want to use the user certificate store, rebuild the app, sign it, install it, and then you can also manage the middle traffic on a non-rooted phone. So usually that works, but there are a few apps trying to prevent this by measures like key pinning. And Mike will tell you about that. Yeah, this is an example we found at the conference hotel in Vegas. We didn't hack the system. Of course, we just wanted to see what it's doing. And this is a very nice example because the app actually tells you what went wrong. It says code certificate pinning failure. So basically this app was like, okay, I cannot trust this Android device anyway. I have to check the certificate myself. And that usually doesn't mean the end of this analysis because there's other ways. The first one is really basic and simple, but we think it's a good advice. It often turned out app vendors usually do at least two apps, one for iOS, one for Android. And really often one of the apps doesn't do the certificate pinning, so just try the other one. Or for Android, you can easily get an older version of the app from the internet and try that. But if that doesn't help, then you could modify the application and re-sign it and we'll come to how to look into what to modify. We'll come to that later. You could also use a tool called Frida and potentially the Objection Framework. And that's a really powerful tool for mobile application. It's kind of scary if you're an app developer because this tool allows you to basically change everything. Just a quick example in this 45 minutes, we can't do this in detail, but there's good tutorials. What you would do is, in the example of an Android device, you have a rooted Android device, you run a server component there. Then you could try this Objection, as I said. Here's an example. I think it was the Master Lock BE app, where you just use Objection and type in Android SSL pinning disable and you would get that. If not, I mean if Objection doesn't help, you would have to analyze the app. You would have to write a small JavaScript file, like shown here. This basically overloads the check method of the OK HTTP framework, and it always just returns and does not throw an exception, and it locks out something. In the end, you will basically, at the bottom, you see one of the tools showing the traffic. In this case, you see the non-encrypted traffic. Our opinion is, it may be nice to protect the user from ROGCA that somehow got installed on the device, but if you want to do a secure protocol, that's much better than trying to hide it through this method. Don't rely on SSL pinning. People will be able to analyze it. Okay, now when it works, there's two second use. For example, on the Unix command line, you can use the Mitten proxy. On Mac, I like Charles proxy, but there's many more available, like Burp and Fiddler. The example of the Mitten proxy on the command line is shown here. You can see a flow of the messages, and you can scroll up and down. When you zoom in, it will nicely decode the message for you, show it. This is actually an example we will also come to later. Our advice for you would be to use all these tools when you unbox the system, because you will probably otherwise lose important events, like the first firmware update and maybe the last firmware update was easier to analyze. It is really advisable to have an old Android device, and they are not that expensive. Root it and use it for that. Okay, so now that we know how to get to the data, let's have a look how to analyze it. Basically, you get a lot of bytes, right? What to do with that? We brought an example here. This is a very small, very cheap padlock. It's not really mechanically sound. You can probably just bite on it and it will break something like that, but it's a very nice puzzle. It's cheap. You get it for not much more than $10 from Amazon, or from Alibaba or something like this, and it's a nice puzzle. Basically, you can spend a weekend analyzing it. Interestingly enough, we found that this company sells other locks, for example, bike locks, and there is our friends from Radforschung. They do the bike sharing system here at the camp. They also encountered this, because basically this also comes as a bike lock or a scooter lock. It's also integrated into some, you know, these e-scooters that now pop up on the streets. It's interesting to look at the protocol, and we have to be careful here. This was last year, and the company did improve this in the meantime. For example, in 2018, they did not use HTTPS, so all the Mitten stuff was not really that difficult. You could just listen to the transmission. You would see the password and plain text. And yeah, if you look closely, oops, sorry, if you look closely, you would also see in the transmission from the backend server to the application, you would see 16 bytes that are called lock key. Yeah, so 16 bytes is 128 bits, and it's a very easy assumption to think, well, maybe this is AES128, because that's used in many systems today. So when we looked at the Bluetooth traffic on the left side of the image between the lock and the smartphone, initially it was all random. You just saw randomly looking bits, so you couldn't find out anything. But then we just had a lucky shot on this and used AES decryption. You find even online tools to do that. And yeah, now it doesn't look random anymore. If you look at this closely, you see many zeros, and this is obviously not encrypted, so we got the right way to decrypt it with a lock key from the backend. And then what do you do? How do you find out more about this? Basically to analyze that, you open this lock several times and record several sessions, compare them, and here we underlined bytes that are of interest. And if you do this for a few sessions, you will find some obvious pattern, like, okay, now it's requesting something at a response. There is a session ID, in this case four bytes, sometimes only three bytes. That is always the same. And basically, yeah, this is an example where you can deduce a protocol from just looking at it for, let's say, two hours. And in this case, what we can see, there is a replay protection, there is a random, or nonce, basically, a random value that is created by the lock and changes every session. But as you can see, it does not change within the session, so there's no counter or something like this. And with tools that can actually hijack a connection or that do man in the middle and you can replace and replay things. This may be an interesting attack vector. What would be the next step after you have analyzed this? You could write a software that mimics the application. We use Python for that on a Raspberry Pi. And there's BluePi, for example, as a library. And then you can basically emulate the application and try it yourself, and then you can modify small things and see what happens if I modify the session ID. Will it still work? Will the lock reject it? What happens? And use fuzzing. Doing this, we didn't find any obvious weakness, except for things like, yeah, if you share this secret key with somebody else, then you cannot revoke it because you cannot change it. Well, yeah, but you also want to look at the whole system, of course, yeah? Maybe if somebody integrates this into scooters, do they use a different key for every scooter? Or does this backend really work as you would expect it? Does it not give you other users' keys? Of course, in this case, you have to respect the laws. Oh, yeah. That was a protocol that is not too difficult to understand. What do we do if the protocol really doesn't make sense at all? Next step could be to reverse the application. This also has legal implications. You may have to check the laws. There are certain reasons why you can do this legally protected, but check that. When you recompile an application, you get source code, and you can analyze the source code for Android. That is not too difficult because it's Java, and Java can be recompiled rather easily. In some Android applications, there is native code, that's C++ code, and then you need tools that recompile this. There's, for example, the Ghidor tool by NSA that does that, or Eda, many of you know. For iOS, it's very similar, but you have to get the application first decrypted way. And then you could also use Hopper, for example, to decompile ARM code. When you have that, what do you do? You will start searching for anchors like Android or Bluetooth. If you find something that's Android or Bluetooth.Bluetooth get characteristic, that's where the data is sent or received from the device. You probably also search for things like AES or key. And the second example, that's the real example, if you find a key like this, 0, 1, 2, 3, 4, 5. You may want to look closer, because there may other things be hidden, and Ray will come to that soon. Yeah, the other thing, the one thing that often happens also is that the app is obfuscated, and even though there are symbols in the application, they are just like C0001. And that's extremely hard to read. So it is not really difficult if you use a tool that's made for that, like Android Studio for Android. In this example down there, you see there is an array. On the array, if this is null, then key data is null. It's presented, and this wasn't obfuscated. So then you just replace key data everywhere, and then you go back from this anchor to getting something readable. So on obfuscation, we have a very strong opinion. It doesn't make sense to do that. It makes review harder, but it makes review harder for people that are friendly and will do responsible disclosure. Terminals will still do that, and they will not inform the vendor, so don't do that. Do a proper secure protocol, and then you don't need to hide it. Okay, so what did you find so far using these techniques? Yeah, so a short recap of things probably already published in the past. One very easy example, also something you can try out for getting started is a cheap padlock by the company Anboud. It has a shim proof mechanic, so unlike very cheap locker locks from the US, you can't shim it, but the passcode is transmitted in plain text, and to our knowledge is still the way today, so consider it a zero day, but we assume the vendor knows he is not using encryption, so we didn't have to notify him about that. So if you just look at the transmission here, you'll find a hex string. This hex string translates to decimal. Decimal is the key you have entered for your lock in the app. You sniff it on the air, you enter this code in the app, and you can open someone's airless lock. So this is the quality of these Chinese locks, but I'm pretty sure this is one singular example, right? Who thinks this is a singular example? Yeah, one hand. Okay, so there was a presentation at DEF CON two years ago, or three years into the meantime, by Rosa Ramsey and they tested 16 locks, and 12 had vulnerabilities like that one. So as you could fust them, you could simply read the passcode, you could replay data, something like that. Then of those 16 locks, 14 were padlocks, and two of those padlocks remained unbroken in this very broad approach. So these two padlocks were something by random, we looked into closer. The first one was by the company Master Lock, and we played around with it a little. So we had a similar attack on an older Master Lock, but for sure, like building a new modern Bluetooth lock, they fixed it. So we use an attack tool which is called a so-called magnet. You might have heard about it, and it manipulates the motor from the outside. So by this movement and changing the polarity, we rotate the motor inside the lock without using the electronics at all, and your $80 padlock opens. So that was easy, but not wireless lock picking. So let's look at the other one. The other one I have talked about already at the 33C3, so this is just a short recap for people who didn't see that. If you're more interested in this, just look up lock picking in the IoT and you'll find the old presentation. So the Nokia padlock was one of the first Bluetooth padlocks ever created. It was a Kickstarter project, and what I'm showing you is, of course, for the old version. They did a firmware update after our disclosure, so now this is fixed. We haven't looked into the new one more closely, so... So this lock padlock actually used 128-bit AS back then, and it also used different keys for yourself and for the friends you shared it to. Not different AS keys, but different secrets inside the lock, but the time restrictions were only enforced in the app, which was the first weakness, but that's more like a minor weakness compared to the rest. The main problem was that they used individual session keys for each opening operation, but the session keys were created in an unsecure manner. The only security relied in the secrecy by obscurity of this mechanism. So if you know how to use the disassembler and you'll find operations like XOR and look a little around it, we found out it's a very simple protocol. It sends a nonce encrypted with this pre-shared 1, 2, 3, 4, 5 key. The lock sends you a nonce. Those are added together. They are added to the center of this 0, 1, 2, 3, 4, 5 key. Don't ask me why. So 32-bits in a 128-bit key get changed with data you can reconstruct, and you've got the new session key which is used to open the lock. So when following this, you could just break the whole encryption and read out the data. So this was a more complex lock, but still in the cheap product, so now for the interesting part, hotel keys. So before that, we always had sims like padlocks, vibrators, other cheap toys.  Why do they actually do that? This is really a smart idea. Of course, the main purpose of that is to get rid of personal. No making the experience for the customer more pleasant, I mean. So you can do self-check-in. You don't need a key card anymore. Your mobile phone is your key to your hotel room. So it might be that it's less personal interaction, but of course, in a hotel with big queues, it might actually be an advantage for you if you just check in your app and don't have to go to the front desk. Just walk to your room. So what are the challenges of these systems? This is not your lock. You don't have to compare to this lock getting a code from the packaging or something. There's no big chance to do a big pre-shared, secure pairing or something. Then of course, those hotels are there for quite a while. The locks are probably old and they have to retrofit the Bluetooth stuff, so they probably don't have the most modern crypto chips in there. And then of course, it's a complex ecosystem of the booking companies, of the hotel operators, of the application writing companies, of the lock manufacturers, which have to interact somehow to get a good system out. But so how does it work? So you have normal booking. You link this booking somehow to your account. What we found there is often not very secure mechanisms of authenticating. For example, you need to know a name, a date, and the booking number, which is a sequentially increasing number. And then you can create your mobile key if you know this data. In social engineering, this actually might be a way to get a key easier than walking up to a front desk. But in the normal way, you do an online check-in, and the mobile key is transferred to your app, and then you use the app to open your hotel room. So this actually was not taken at the Black Hat Hotel. We just used the Mitten Proxy to replace the logo. So this is something you can also do with these TLS tools, but you open your door and the door opens, so that's the normal use case. We actually looked into this in two different hotels. The first hotel, we call it the Hotel H, we found a system that we did not break. We looked into it, analyzed it, and found out it was quite using cryptography. So from our perspective, it looks like the vendor has a secret key KS, which is never getting known to us as a user. The back end sends us a key for our Stay K, and then encrypted version of this key K we call K Star. So now our app sends to the log K Star, and the log uses this vendor key KS to decrypt K Star to K. So now as well the app as the log knows the key K, and they can do securely AES encrypted communications. This is a protocol at least somehow working. We didn't find the direct attack vector except for probably extracting the secret key from the physical log. There's lots of talks about getting firmware dumped and stuff like that, that would be possible, but we do this in a hotel where a stay is a normal guest. So we didn't also not really experiment more into this because the system for some reason went down after our first stay. So we have no implications here. We switched to another hotel having logs by the manufacturer M. So this we found early 2019 in the quite upper-class hotel, so talking about four stars, not really five stars, which uses the mobile key basically everywhere but also can use your normal key. And we analyzed the TLS traffic and the BLE traffic. So when I do a link by booking to my app, I get some data and in this I find something called mobile key having a DT array of lots of bytes. We see only the first five bytes here, but it's more like 40 or something. When looking at the BLE traffic, I figured out I see all the bytes I get as a mobile key also on the air. So that doesn't really look good. Is it really just a replay attack? I looked at the data and found out there's quite some handshake happening before this transmission, but after some four-byte signature or something, the whole key gets transferred. So that didn't really look like it will withhold our analysis, but we first had to understand the other bytes happening before that, so Michael will tell you about that. Exactly, so we did the same thing again as we did with the small padlock. We looked at several sessions. You just open the door multiple times, record all this. We found there is something at the end that changes. 32 bits. We made the assumption that half of this may be something like a nonce. The other half would be a CSE. And for the first three messages, we were right with that assumption, so you can see underlined at the end the CSE value. You will find tools to reverse engineer CSEs, for example, CSE Refang. We, however, just used the custom Python script to try out many CSEs. There's always a seed value that can change. There's an XOR value that can change. Direction can change back and forth and so on, but there's not so many and basically brute forces isn't the right word, I think. We just tried them and then we found the right polynomial. And it turned out that the seed, the initial value, was something that's constant within a hotel. It's called SC, probably system code or something, and that's also sent from the back end. We've seen that in a message that was sent from the back end to the application. So we knew how to create the first three messages. You always need, as a seed, the last CSE. But then in the middle, the last of these CSE or whatever, we didn't know at that time, and that was more complicated. There were like six bytes, always zero, and then two bytes had changed. And we had to play with that. There were some values to play and try and play around, but essentially it's like this. There is the values from the previous calculations I used together with the data behind that, and then this used the CSE value that was transmitted by the real application. And now we knew how to create that ourselves. So that was a major breakthrough in this project. We prepared a Python script again. We're using BluePy that calculates these CSEs. Of course, you need a key somewhere. We tried that as well again. So you can see our sniffing attack here. In this case, we did it from inside of the room not to confuse the roommates and so on, but you can see the three little recorders there, and one of them was linking because it actually triggered the, it actually found the transmission. And on the laptop screen, you can see the key data. Insert this into our Python script, and well then... Yeah, then I thought let's try this out for real. I went with my laptop and a classical hacker outfit outside of one of the rooms we had, and let's try it out. So there's the Python script running on my laptop using the data we sniffed on the actual hotel door. You see the light is turning to green, and we enter a room, and suddenly it turned into a quite nice hotel suite because actually in the 37th floor of a luxury hotel. So much for Chinese padlocks. Okay, so after we had that running, we thought let's play around with it a little more, and Michael created a Python script emulating the lock. So we had the other target, the other side of the system, and we could use the real app to play with our simulated target. And we were wondering how big is this problem. We found this in one hotel, but we found out the names of these locks are base 64 encoded binary data that we can understand. So we could just by looking at advertisements from BE locks find out if they belong to the system we analyzed or not. We found another hotel chain and the third hotel chain using the system. After booking a room in one of these chains, we found an even more simple variation of this protocol. So this basically tells us, okay, this is a bigger problem, and from that we also could deduce that the vendor of these locks called Messerschmitt Systems, a German company, is the origin of this protocol. And even so they have like 2,000 hotels altogether. The system is only deployed in like, I'm not sure, but a smaller three digit number or something of them, because they're very, we talked to them and they're very early in adopting this and also they don't put this into their 5-star houses because they don't want mobile keys basically. But in other houses it's getting popular. So we thought, okay, this might be something real and we have to find out can it really be used in a real attack. So we know we can reliably sniff it, but where could you sniff it? Doing it at the door might be a problem because you have to know which lock you're sniffing. So our first way was, oh, probably there's a way to get this out much security considerations. In such a fitness center there might be options like plastic containers that aren't especially hidden somewhere. Having this nicely set up and letting our test guests enter the fitness center, we found out mobile key was down for the fitness center. I'm not sure if they wanted to spoil us or whatever, but there's a second place where everybody uses his key and this actually seemed better for sniffing because if you want to enter your floor you have to activate the elevator using your mobile phone app. So this is a place where you can very unsuspecially work with your backpack, have a sniffing set up or even place it somewhere and everybody has to use his keyser. And if you have the simulator script we built you don't even need special hardware. You just emulate the elevator lock, advertise more heavily and the app of somebody will connect to your laptop and you can complete hardware less attack except for your laptop to get the key. And of course our tool dumps the key for your convenience use. So figuring out this is a real issue which can really be exploited. We thought it would be a good way to disclose this to the vendor and we started this in April. We told them, we told them, yeah, this is the problem and nicely we got an immediate response probably because we did some research in who to write to. We sent him technical detail. First reaction was that it looks very interesting but it can't really work like that. So we sent a very specific mail telling, believe me, we did this in a real hotel. We didn't send the video so but we sent proof of concept codes, they acknowledged it and all the communication went very well. They never tried to prevent publication or anything and they started to work on the update. The challenges of course in such an update is you have to update a whole hotel system, a whole ecosystem. So we found out that the lock the first hotel where we saw the nice video this is a modern hotel being completely online. They can actually remotely update the whole system from their office. In other hotels they will have to walk from door to door to door with what I understand is an infrared update device. So this will be some work and of course the different app vendors will have to integrate the fixed system into their APKs independently of the update of the lock system. So actually this state of now still is a zero day exploit and we had some discussions also already at Black Hat if we should really publish it but figuring out that you can still use your normal key card if you figure you're in such an affected hotel and giving the fact that actually not very many people actually use it so far because it's quite coming up now. We thought it's okay. But one important lesson we learned is you have to really identify all the parties because we informed the vendor very early but the app vendors and the hotels and actually a second vendor which we only heard about two weeks ago were notified a little bit late about that. But still this was quite interesting to see contact to the vendor side and they told us they are in the process of rolling it out starting end of August. Probably this is a little bit delayed now because we haven't really heard of the new protocol yet but they're working on it and we hope this turns out quite well. So what are the takeaways you should take from this presentation? One of course is particularly as sure everybody should know by now the BLE link layer usually can be sniffed reliable with simple tools unless special measures like out of band pairing are taken. And whoever should build this I'm not addressing this to you but to the vendors looking into this talk please don't hide your secrets in apps build secure protocols. This whole things we analyzed are all obviously built on the assumptions that you can do things like that and it works out no it doesn't. And the thing we learned in this is BLE is not just used in toys anymore it's getting to the real world. Now it's in hotels probably it's always getting to really important things like your martyr refrigerator so these things are worth looking into and worth analyzing and I hope that with these entry points here and I can really recommend downloading the slides because all the blue words you saw in several links to more information help you to get into this research field and you can help us make this a safer world by hacking all these things. So thanks for attention and now we have like two minutes 50 seconds for questions. We do have time for some questions so raise your hand if you have one no, the microphone is wired so you need to come to this lovely angel in the center here and ask your question in his microphone. Yes, there is a question over there. Am I supposed to ask is it okay? Hi Ray, I'm Michael I have a question about other transports like is NFC or RFID ever used in hotel door locks? RFID is the standard way today most hotels you have an RFID card today NFC I have not seen but we have for example seen Bluetooth locking systems where you have to near your phone to the lock before the lock activates the Bluetooth but this is not what we looked into and as I said RFID is very standard and of course these cards can clone and everything but it's a different field of research. Bluetooth became popular and popular smartphones so that's the technology they all go for now but of course all the cards you get in the hotels previously some years ago they used magnet stripes but now they are RFID Thanks a lot for this answer do we have another question, yes up there go ahead. Are there some Bluetooth locks that perform some sort of pairing? We have not seen it and it's really inconvenient because you would have to spend too much time to do that so basically all the locked systems except for very few that you put in your front door all of them use just unencrypted link layer and then do the encryption or whatever they think that's appropriate they do on the application layer. The only high security device where I found pairing so far was a luggage bag showing a digital bag tag that used pairing. Thank you for your answer. Do we have any more questions? I don't think that is the case if I'm not mistaken, scream now. No questions on the internet? Okay. Or on the internet of things? No, okay. Then thank you again and please get into hacking these things.


Mi je Vastimel, zelo sem hobbyist, všeč imam hobbyist zelo slapelokatore. Zelo se vsečen, zelo seziv naredil slop, ali je bil prezvodnjena. V 6.4 rc1, ko sem ustaljala, vseč na slapelku, jasno je slop 3. If anyone needs to use the kernel on some small system, they have the alternative in the slab tiny configuration option. And why is this relevant is that it means that now we can call K3 objects that were allocated on KMM cache alok, as well as KMLok, which is something that XFS people were interested in at some point. And it also means that K3 RCU and KV3 RCU should work as well. And there should be no downside except after Joel session it means that if we implement something for slab to handling use case, it means it will have to be supported by all caches and not just KMLok caches, because somebody might call it K3 RCU on some non-KMLok objects, so we'll just have to keep that in mind. And another maybe surprise might be that somebody might try to use trace points, which are separate for K3 and KMM cache free. And if they don't enable both, they might miss some free that went through the other API. So if you are tracing slab allocations, you should keep that in mind. But hopefully that's not critical user space breaking. So with a slop out, that's fine, but that was the allocator that I'm able to pronounce well. And there's still slab and slab, and I always don't know how to pronounce them properly, so the next step is that I would like to remove slab as well. And besides that reason, the other reason is that, of course, that's another thousand lines of code to maintain. And sometimes we find out that some part feature of that, like the debugging, has been broken for years, because nobody uses that, so we can have unknown breakage. But another thing is that for the two allocators, we maintain the common layer, which is another bunch of lines. And with these common layers, it's always trade-off between do I duplicate code that can then be nicely inlined, or do I have this common layer in another C file, which has to go into the implementation-specific file, and those calls cannot be inlined without link-time optimization. Then there are features that either had to be re-implemented for both allocators or were implemented for just one of them. For example, the memcg support had to be duplikated work because it was done in both. For preempt RT, just slab is supported. And the last thing is that, once we have a single allocator, it's much easier to think and implement of more API improvements, like the one that Joel was talking about, and I will do some more later. And it's also not common in the kernel to have multiple implementations of the same thing. It made some sense for Slop, which had a very specific use case and was sufficiently small, but it was still blocking some API progress. And another example is, I can't think of, just the ZS malok backing storages, which we have also multiple ones, but these are pretty small self-contained things, and while K malok is something everybody uses. So this is not the first time that Slop was proposed to be removed. I found at least three cases when it was discussed at the Linux MMA link list. And usually the main reason was that there are workloads that would regress when switching from Slop to Slop, and so it was always rejected. So I guess the question is, are there still objections today? And since Google guys were one of those that always objected, I guess it's a question for them. Yeah, thank you. For Google's perspective, I think with the introduction of Perseapu partial slabs that Slub has come a long way to, especially addressing the point from 2012 there, for the 10% performance degradation, at least for TCPRR. And what my colleague Binder did in the last bullet point is he has recently compared these results and posted them. I think performance is, it can go in either direction if Slab or Slub is better for microbenchmarks and some well-known open source workloads. The big thing that he is calling out is the overhead in metadata or just for because Slub uses much larger page sizes and it has the Perseapu partial slabs as to get a lot of that performance back from TCPRR that he finds that on some workloads that we have to 300% increase in the amount of memory that is set aside using Slub. And so I don't think there's an objection to removing Slab for the cleanup. I think a lot of folks, because Slub has become the default, perhaps are unaware of the much larger memory footprint of Slub and that now that we have our attention focus on it that we can make some incremental progress in that direction as well. But I wouldn't have an objection from Google perspective from Slab, but happy for others to talk about it as well if anybody else has a thought. Just for the background, we were using Slab for a long time in SUSE kernels and when we were evaluating to essentially move to Slub, Mel has done quite a lot of benchmarking and found out exactly the same thing. It can be some plus for one, some minus for another, but essentially on par. And so back then when we were moving to Slub, our main reason to do that was debugability because Slab just had to, you had to recompile, hope for reproduction with Slub. Everything is just, you can enable that in runtime and that's a huge advantage. So that was the main decision point for us to move away from that. And so those two main reasons from 2019 are gone. So unless there is somebody very married to Slab, then I guess we should just go ahead and just remove it and fix those problems that David has mentioned incrementally. When I was at Intel, I was working with a team that did TPC benchmarking for an unnamed commercial database and Slab was at the time better performing. That same unnamed commercial company that did TPC benchmarking and enabled Slub. So clearly the rationale for using Slab for TPC benchmarking must have gone away for that to have happened. I wasn't at that company when it made the choice. I don't know what the decision making process was, but clearly it was made. But does somebody online? Yeah, this is Greg, also from Google. I just had a question. I agree with what everybody is saying but it's sort of being washed depending on which direction you look at it. But in terms of the memory overhead, are these structural things or are these the kind of known matters that we can chip at? Because it feels like everybody in the room is getting more and more sensitive to cost in memory spend. So maybe the memory overhead is even more critical than the performance parity. Yeah, I was actually surprised that the memory overhead was brought up as the reason this time. Like main objection, I think the results showed what like 30% more of binder, or something like that. But the question is, it's 30%, but is it so large in absolute numbers as well? I mean, yeah, the dementia mark in binder did a complete workup and were thankful for it. On some workloads, yes. Just in boot overhead, I think that he was seeing on a regular off the shelf. I forget whether it was Skylake or Cascade Lake, he was seeing that just after boot Slub was taking 110 megabytes more than Slab. But depending on the benchmark, it depends on how many, it scales with cores, of course, per CPU partial slabs. And that is how we address the TCP round robin problem to get that performance parity back. But at the same time, with very large core counts, 160, 192, depends on how many slab caches you have. And that's why we're excited about the third bullet point here, which is the per object Kmem accounting that we now have, where we can share those Kmem caches together. And as a result, I think that we are willing to fine tune Slub to use not only smaller order pages for its slab caches, but also being able to shrink down the number of per CPU partial slabs depending on the core count that it can be minimized but not achieve the same level of slab. I agree that it's a structural problem because the way that, as you said, Slub achieves performance by having many per CPU caches. And it's actually interesting because I think when Christopher Lameter introduced Slub, one of the points was that slab caches too much objects in the array caches. But as time went on and the number of cores increased, then we have more slabs because they are per core and also the default algorithm that selects the default order also takes the number of CPUs into account so that even makes the problem worse. So if we had to deal with this, we would have to achieve the performance by something else than having multiple slabs and per CPU and then probably means going back to something like the array caches. I just wanted to mention as far as I understand the array cache takes up space inside the slab, inside the slab. It can, but the problem was not the array object itself but how many allocated objected caches. Because the array is missing in the slab allocator, wouldn't you have, would you be able to store more objects per slab because now you have the space that goes for the array now can be used for objects. But yeah, I need to look into the per CPU partial slab thing. Yeah. Yeah, the per CPU partial slabs, the documentation in the kernel tree is actually wrong, it's not just a read-only value, you can write to it. His analysis, as you can shorten that, it's up to the control of root. One thing from at least Google Cloud's perspective of why we really, really want to move to slub is because it solves our CPU jitter problem. I say we, I'm talking on behalf of the Google Cloud customer here, that if we send over a set of reserved cores, then because you do the cache reaping every two seconds on every one of these cores is a design of slab. You see these little hicups every two seconds when you're trying to do these reserved cores and they actually don't get exactly what they're paying for, and so slub doesn't have that downside and it's one of the reasons that we at Google, at least in Google Cloud definitely want to move toward to using slub, even if it has increase in memory footprint. Okay, so I guess I have one question. So I just want to say that early it was mentioned that slub uses more metadata, but it sounds like it's not really the metadata that causes that memory overhead difference, but the caching. Yeah, it is more slab pages that are tied to CPUs. So you have free space in those pages, even though nobody allocated them yet. Next question is where the CPU caching makes sense as we increase number of cores. So when we have like 16-32 cores maybe it makes sense, but when once we go to hundreds maybe there shouldn't be just a linear increase. There should be some smaller kind of increase in caches. In some CPU caching has to be there otherwise it wouldn't scale good, but right now it caches the slab pages which contains both used and unused object, and if it was just an array of unused objects then it could be more effective, hopefully. I understand for the concurrency reasons why we do the CPU caching, I'm just saying that sounds to me that if we just go proportionally to the number of CPUs, we start caching too much memory than actually more memory than is actually needed. Maybe I'm wrong. So you mean the heuristic that... So I'm not saying to have smaller caches principally, I'm saying there should be some kind of tree or something from each of the resources that they can again. The racism and scalability should be resolved but having a pre-CPU is not the only solution. I'll just say that I think that Slub's original design is based on returning cache-hot objects for every CPU. Yeah, I didn't understand your point because the objects that are cached per CPU actually move between CPUs. So for now the CPU needs it, it's not going to sit in the same cache. The mechanism is designed to transfer objects and then transfer them back. So there's that sort of stuff going on. I don't know, under memory pressure what happens, maybe the per-CPU caches are shrunk or something, I don't know. But I know that they do travel as needed. So they travel but obviously there is a high memory overhead with Slub and the high CPU account systems. Yeah, but it would be fair to argue that with more CPUs you've got more memory so you care less. It doesn't scale so rapidly that it would be a bigger problem or at least that's my perception. So I'm not really sure whether that's really a big problem. Is it for anybody? It is a big problem for Google. Yeah, but the question is how it can be solved by keeping the same scalability. Yeah, maybe that's one idea that you proposed and it would have to be tried. So I guess nobody here seems to be objecting to the removal, so I guess the next step would be to again propose it on the mailing list and see if there are other people objecting and ideally they would come with a use case or some benchmark that's regressing and it's really regressing because of the different design of the allocators and not just some random effect of different object layout affecting caches, which is always problem in these kinds of benchmarks. And hopefully the motivation would be some actual workload and the benchmark just hopefully that produces that thing but we shouldn't hold back just for the sake of some micro benchmark. And if something like that objection and concrete benchmark is found we can discuss how to change slab to accommodate that. There have been also some efforts in the past to merge the best of both allocators which were abandoned I think not because some fundamental issue was found but what I was reading in the archives it always just died because there was no sustained effort and probably things changed since then so the ideas should be adapted anyway. So if we can assume that slab can be removed we can consider just how to improve further the remaining allocator which means it doesn't have to be implemented more than once and we already discussed that some different kind of object caching should make sense and I think there are many use cases for that for example the better performance or hopefully less memory overhead we can also consider whether we want to support allocation in things like NMI context using these per CPU caches but without no guarantee of success because if the cache is empty you cannot do much else in such context and that would hopefully allow us to remove the BPF allocator which was created just for this use case and it would be nice if this was provided by slab itself then maybe some use cases would need guarantees like the maple tree node preallocations so hopefully this kind of caching could accommodate that use case as well the question is if there would be cache for each cache K-man cache and CPU or for each user that would say I want this cache of this size we can discuss that and the point is that lots of many people reinvent the wheel in the kernel to accommodate for things that the memory management doesn't support itself and it would be glad if we could do something about that because for example these non-MM implementations often don't either think like they should have shrinkers to prevent premature OM that I think is for example problem of the BPF allocator and if we did the implementation we would do everything properly because we are familiar more with the MM so if there are any other ideas I'm open to the problem we have and arguably this should be fixed in the call and not in the slow allocator is decache poisoning that in a system that has a huge amount of memory that is under no memory pressure the decache will essentially grow without bound because you can create as many negative de-entries as you want just by looking at files that don't exist and we rely on there being you should run the shrinker and of course you actually do run the shrinker and it turns out the 11 billion objects and the shrinker that now takes forever to run and something in there is OM squared and it's just an absolute nightmare and Oracle aren't the only people hitting this we don't hit this on all systems but we have some very specific systems that do most of our systems are under plenty of memory pressure, thank you but some of them not and we're not the only people who come across this if you look for decache poisoning or something like that you'll find a number of problems over the years so I don't know if this needs to be fixed in slab arguments decache as well but something to consider I guess it's specific somehow to the use case but I guess the allocator could provide some building blocks on top of which the solution could be built and if there is just single allocator it's simpler to do that another questions or ideas I'm overtime anyway, right? OK, so thank you and wish me luck


What if viruses hold a key to the future medicine? What if porous small lava stone we can find that the Jeju Island can teach us how to design future medicine? I'm going to talk about two very important medical amenities and how we try to solve these biomedical challenges by learning from this tiny virus and porous lava stone. One medical amen need is about targeted delivery. If we can selectively deliver drugs to the target site, such as a cancer tissue or a target organ, then we could dramatically increase the therapeutic efficacy with less amount of drug, with less adverse effects. And another medical amen need is about intracellular delivery. So certain drug candidates, such as small RNAs, fail to become commercial drugs because they cannot go into cells and they are degraded by enzymes in vivo. Therefore, we need some kind of protective delivery and a carrier is needed for intracellular delivery of this kind of drugs. So how can you make the biotherapeutics go into cells? The answer is in the nature. We can mimic virus infection. Viruses go into cells to survive and scientists revealed that viruses go into human cells by a mechanism called endocytosis. So in my lab, we mimic this virus and we engineered virus particle mimicking, small nanoparticle. The name is degradable. So our particle degradable is very similar to virus in terms of its intracellular delivery mechanism. And also in addition, they can sustainably release drugs inside cells. The degradable, we engineered this particle to have numerous pores inside to accommodate many copies of therapeutics inside, just like this porous lava stone. And also it can maintain the structural robustness just like porous lava stone. And also we can control all the physical and chemical properties of these degradable. For example, for the loading of negative charged RNAs, we can chemically modify inner surface of this degradable to load this negative charged drugs inside the pores by electrostatic interaction. To be successful as a gene delivery carrier, the degradable should go into cells. In fact, we found that degradable is readily uptaken by human cells. And after its mission of drug delivery, they just disappear from the body because we used biodegradable materials to build up this tiny porous nanostructure. We first designed our degradable for the SIRNA delivery. SIRNA is a short interfering RNA which can inhibit the targeting expression. We designed the sequence of the SIRNA to inhibit the protein expression which is responsible for fast tumor growth. We found that our degradable could greatly block the growth of tumors. Our degradable is also very effective for the therapeutic DNA delivery. So in fact, traditionally people use viruses, real virus for the gene delivery. But that kind of approach raised many concerns on safety. Now we can use our degradable for safe and effective therapeutic DNA delivery in vivo. We next tested our degradable for wound healing model. Here, we tested that our DNA plus degradable for the wound healing and we found that our complex induced very fast wound healing. This approach can be applied for other vascular diseases also. Our next challenge is in the field of immunoconcology. So we found that our degradable can induce higher therapeutic efficacy with less amount of antibodies in this tumor model. Our degradable is also compatible with intra-arterial delivery of cancer drugs through this microcatheter which is inserted through artery. We can combine many different kinds of drugs with our degradable and then put them through this microcatheter for better tumor targeting. So by this way, we can generate many different types of drugs. Our degradable is very broad platform technology which enables many drug modelogies. I expect that this degradable technology could be a powerful solution for the future biotherapeutics development, especially for cancer therapy. So far I talked about how we designed and developed the degradable inspired by virus and small porous lava stone. We expected this degradable will be a very good key platform technology to solve medical unmanage by enhancing drug efficacy with less adverse effects for the diverse range of future drugs, especially for RNA DNA biotherapeutics. Thank you.


Well it's really a blessing and an honor for me to be able to share the stage tonight with Sister Jose. I was very excited when I found out that we were going to each be giving a short presentation and then after that we will open up to some dialogue and some question and answer time before the time of Iftar at the evening meal. And Sister Jose proposed what I thought was the perfect thing to spend our time on this evening. And that was texts and traditions from our respective faiths having to do with the love of God. After a couple of years of isolation, of not being able to gather like this, and really I feel like escalating tensions and conflicts in our homes, in our communities, in the world, nothing could be more fitting than to spend our time talking a little bit about the love of God. Now I want to preface my talk by saying this, the scriptures that I picked, I feel are not necessarily the most universal ones that we have in the Bible that Christians and for two thirds of it Christians and Jews share. I did that very deliberately. It is not in any way to be divisive but rather an acknowledgement of the fact that I believe each of our faiths has something quite unique to offer the conversation about God's love. And I thought why don't I see what is pretty uniquely Christian and I trust that Sister Jose will offer us some things that are uniquely Muslim and that that would actually create a richer dialogue. So I offer this not in exclusion of any other perspective but rather as something rather unique that I feel that the Bible and the Christian tradition might have to offer this. So I'm going to focus my talk on three things and these are terms that I will unpack because they may be unfamiliar to some. Incarnation, resurrection, and trinity. Incarnation, resurrection, and trinity. And these are three themes that you will find very much throughout the pages of the New Testament. And the various authors that are represented in the New Testament each emphasized it to a somewhat different extent. And I want to make sure before we go into it that I'm also very clear on a perhaps misconception that occurs and Christian theologians over the centuries have very much had to deal with this because everything about this incarnation, resurrection, and ascension can leave one scratch, I'm sorry, and trinity, can leave one scratching one head thinking wait a second, is Christianity a monotheistic or a polytheistic religion because all of this speak to sort of more than one aspect of God. So let me just say Christianity is unapologetically a monotheistic, a one God religion. In everything I'm about to present from the Bible and everything from our tradition, all you're hearing about is different faces, different aspects, sometimes even different persons that language gets used of God, but it is all the one and only God. So I'm going to begin with the Gospel of John. There are several texts in the New Testament that are attributed to the Apostle John and the community of the shores of the Dead Sea that really took its inspiration and its theology from him. And I'm going to read the very opening verses of the Gospel of John. So these are the first several verses known as the prologue to the Gospel of John. In the beginning was the Word and the Word was with God and the Word was God. He was in the beginning with God. All things came into being through him and without him not one thing came into being. What has come into being in him was life and the life was the light of all people. The light shines in the darkness and the darkness did not overcome it. There was a man sent from God whose name was John. He came as a witness to testify to the light so that all might believe through him. He himself was not the light, but he came to testify to the light. The true light which enlightens everyone was coming into the world. He was in the world and the world came into being through him. Yet the world did not know him. He came to what was his own and his own people did not accept him. But to all who received him who believed in his name, he gave power to become children of God who were born not of blood or of the will of the flesh or of the will of man, but of God. And the Word became flesh and lived among us. And we have seen his glory, the glory as of a Father's only Son full of grace and truth. Okay, so that's a lot to unpack. This Word that you hear so many times here is in Greek the logos. And the logos refers to the wisdom of God, the logic of God, the Word of God. And this is something that gets pulled actually from two places. One is from the Hebrew Old Testament, especially in the literature that is attributed to King Solomon. We hear a great deal of wisdom, and wisdom is actually personified as this beautiful, powerful woman. And this is the personification of some of God's creative power and of God's wisdom. Well, John pulls from that and says that that wisdom actually took on flesh in Christ. And this is what in Christian circles we've referred to as incarnation. It's the notion that the fullness of God, the Word of God, the wisdom of God actually came into a human body and lived among us. And I feel like this is one of the many ways that in our New Testament tradition the love of God is spoken of very powerfully, because it's very easy to look around and say, yeah, it's great to say that God loves us, but where's the evidence so much that that stuff is happening? If God loves us, why is there a war? Why is there a pandemic? Why do our kids get addicted to drugs and have horrible accidents? Why does all this stuff? Why do our friendships and our families fall apart? Why does all this stuff happen? And if we look at the incarnation, it gives us a very different perspective. It gives us a perspective of a God who actually somewhat hesitates to use the divine power to actually intervene in human affairs, but rather loves us in a very different way. And I'll give an analogy. If you have ever raised children, you know that when they're tiny, tiny, you do everything for them. And you intervene at any point when they have a need or where they may be in danger. But the older they get, the less and less you do that.  At some point, you need to pull back.  The older they get, it's more and more a presence of an equal rather than a superior. This is what we see in the doctrine of the incarnation.   But as you grow, I'm going to begin to use that divine power and that divine intervention less and less because my dream for you is that you yourself become more and more like the divine.  And so this is what we see in the doctrine of the incarnation, but there is more. Right now in most Christian churches, we find ourselves in the season of Easter. This is the season that we really focus very heavily on resurrection. So the tradition is that on Good Friday, Christ was nailed to the cross and died, spent all of Saturday in the tomb, and early Sunday morning was the tomb was found empty. The accounts differ just in slight detail, but they all agree that it was actually his female companions who were the first ones to witness the empty tomb. And Mary Magdalene is the one who was known for telling the apostles that she had first seen the risen Christ. And so we look at this tradition of resurrection and the passage that I'd like to go to actually comes from the literature of Paul. Paul authored slightly over half of the New Testament. The New Testament is comprised of Gospels, which are accounts of the life, death and resurrection of Jesus, and then numerous letters to early churches and early pastors in the church, many of which were penned by St. Paul. One of his longest and best known is the letter to the Romans, and this was not surprisingly to the fledgling church in Rome in the first century. And this is one of the passages that we read most commonly during the Easter season. Please forgive me, I have lost my place. We know that Christ, being raised from the dead, will never die again. Death no longer has dominion over him. The death that he died, he died to sin once for all. But the life he lives, he lives to God. So you also must consider yourselves dead to sin and alive to God in Christ Jesus. Now you might wonder at first, the word love does not appear anywhere in that passage. So what does that have to do with the love of God? As a matter of fact, the word death appears in that passage more than once, and we don't often think of death in terms of love. But let's unpack it a little bit. This passage, perhaps more than any other, presents in three very short verses the entire theology of resurrection found in the Christian tradition. And the idea is that Christ died to sin, and therefore as humans we can consider ourselves dead to sin, and Christ rose, became alive again to God, and therefore as humans we can consider ourselves alive to God. Now this whole dead to sin business doesn't sound like great news, but if you stop and think about the one advantage that a dead person has, it actually says a great deal about the love of God. Think about it.  Absolutely nothing. The dead person is not vulnerable to any of those attacks. So if we think about this text that way, we are dead to sin and alive to God. It's really good news. If God has made us people who are as invulnerable to sin and sin is all around us, it's in us, the temptation is everywhere and we often succumb to it. But if we are as imperturbable to that as a dead person is to any of the abuses that can be heaped upon them, I really have a hard time imagining a more loving act than that. This story of death and resurrection at first doesn't seem very loving at all. In fact, it actually seems rather horrific. But if I spent a little bit of time just meditating on those three verses on the purpose of death and resurrection, all of a sudden it has a very, very different meaning. So the final thing I want to discuss a little bit is Trinity back to John. But we're not going to go back to John's Gospel. There are also a few letters that are attributed to John in the Old Testament and they all come out of this same Dead Sea community. And this theme of God's love is incredibly strong in these. So I'm going to read a short passage from the first letter of John. Beloved, let us love one another because love is from God. One who loves is born of God and knows God. Whoever does not love does not know God, for God is love. Now that probably pretty obvious why I would pick a passage like that when we were talking about the love of God. But you might be wondering what on earth does that have to do with Trinity? And Trinity is the Christian understanding of God that while God is absolutely one, within that one there are three persons, three aspects, three faces, if you will, that we refer to in worship as Father, Son, and Holy Spirit. These are definitely not three separate gods, but rather three expressions of the same God. And it is only because of that understanding that the author of this letter can say God is love. Because notice that the Greek is very specific. It does not say God is loving. It says God is love. In other words, God's nature is love. Well, to love there must be a subject and an object, right? Love can exist if there isn't a giver and a receiver of it. And in this understanding of God as Trinity, we had this idea that within God's self there are these persons who love one another. So God is not only loving, but by nature, God is love.  There are so many facets within you and often those facets seem like they're at war with one another. You ever had the experience of looking at the mirror and thinking, I don't like myself very much or one part of me doesn't like another part of me very much or I'm in conflict with myself. I'm ready to jump out of my skin. I drive myself crazy and that's only looking in the mirror. Try living in family or in a religious community or in a civic community or a global community. We know how well that turns out sometimes. But if we not only as individuals, but as a human family are created in the image and likeness of God, this passage has something incredibly important to say to us, which is it's okay if there's tension. It's okay if there's conflict. It's okay if one aspect of you doesn't like another aspect of you doesn't understand another aspect of you. It is okay if you don't like or understand your neighbor because being made in the image and likeness of God, you as individuals and you as community are love. And this isn't the kind of emotional love where it's like we feel all warm and butterflies for each other. It's rather that fierce kind of love which is I may not like you. I may not understand you. But when push comes to shove, I recognize you as my sister, my brother. And if the train's coming down the tracks about to hit you, I'm going to do everything I possibly can to stop it. It's that kind of love. So this was my offering from the Christian tradition in the New Testament scriptures on incarnation, resurrection, and trinity and what they have to say about the love of God. And I look forward so much to hearing what you have to offer to sister Hosea. Thank you. First of all, thank you so much, Reverend Andy, and this wonderful congregation for opening up your space for us in the month of Ramadan. This is such an honor. I really feel very honored to be here and I thank you so much. I'd like to first greet you with the universal greeting of peace. As Muslims, when we see one another, even if we're complete strangers, we offer prayer and that is, again, from the faith, as an extension of love, but that is also to anyone that we wish peace for all. So I would like to greet you with assalamu alaykum, which just simply means may peace be upon all of you. And with that said, I begin in the name of God, the most gracious, the most merciful. This presentation, as Reverend Andy mentioned, came out of deliberation about what do we really need to focus on as faith communities. And as he so eloquently said, because of everything that's happened in the past couple of years, but certainly before that as well, I think we all agree we definitely need more love. Our world is fragmented, maybe more than ever before, and we need to come together. So that's why I so appreciate any work with other faith communities, because I think we all really do have those same, you know, objectives, which is just just spread love and certainly love of God. So I've prepared a presentation here that I'd like to invite all of you to join me as I go through the slides and Brother Menir is going to help me. So we'll go to the first slide here, which for Muslims, we understand love first and foremost as a divine attribute. And for those who are not familiar, God is certainly one. We are absolutely, as Reverend Andy also stated, a monotheistic tradition. We are very, very monotheistic, but we do also hold that God defines himself according to what we call the 99 names or the 99 attributes of God. So here is a quote from Prophet Muhammad, God's peace and blessings upon him that he said, God has 99 names and whoever preserves them will enter paradise. He also had a specific prayer that he taught us that he called upon God by, as this quote says here. I ask you by every name that you have named yourself, revealed in your book, taught any of your creation or kept unto yourself in the knowledge of the unseen that is with you. And so this is a prayer that Muslims will learn and memorize and also say following his example. So the 99 names, the image I apologize, I know it's probably very difficult to see. I can't even see it in the laptop. But I've tried to give you at least a preview of some of the names that are on here. There are again 99, and these are just partial. There's actually in fact more names as well in the Quran that God describes himself by. But this is a collection that is heavily known and taught. So here are some of the names. The most merciful, the most generous, the gentle, the provider, the appreciative and giving, the peace, the Lord, Incidentally, that's the word rabbi, right? We kind of, there's a Symmetica relation there between rabbi and rabbi. And so I wanted to just highlight this last attribute, al-Wadud, as I mentioned. We understand love as an idea, as a concept, because of God's attributes. So we are then taught what that means by looking at his words as he defines what love is. And here is a verse from the Quran, chapter 11, verse 90, where God says, وَسْدَغْفِرُ رَبَّكُمْ ثُمَّ تُوبُ إِلَيْهِ إِنَّ رَبِّ رَحِيمُ مُوضُودِ That's in Arabic, and that translation is, and ask forgiveness of your Lord. Then repent to him. Surely my Lord is all compassionate, all loving. Now this specific word al-Wadud, which is defined as the loving and the affection, also needs to be understood in the context of love in the Arabic language. There are several different ways to express love. The predominant words that are used to define love are hope, which is really the feeling, that internal fuzzy-wuzzy feeling that Reverend Andy was talking about, that feeling that we all feel for each other, hopefully, for our family, our spouses, our children, our community members. So we feel things internally. But then the manifestation of that love is referred to as wud, and this is the expression that is then defined by al-Wadud. And so this, you know, God has again named himself by this attribute, to convey that he is not only loving, but that he shows his love to his servants. Now when God loves a servant, here's another quote from Prophet Muhammad, peace be upon him. This is a really beautiful exchange between, and you might notice some familiar names here, that God says when he loves someone, he calls to the angel Gabriel, who is referred to as Jibril in the Arabic language. He says, oh Gabriel, I love such and such a person, so love him. And then Gabriel will call to the angels of the heavens, Allah, which is just an Arabic word for God, loves such and such a person. So love him, and the angels will love that person. And then Allah will place acceptance on earth for that believer. So this is how God again expresses his love in the heavenly realm. Now God's love is reflected in his creation also in different ways. And here's another quote from the Prophet Muhammad or Hadith, which is just a quote of his, where peace be upon him, where he says, Verily, Almighty God rewards for gentleness what he does not give for rudeness. If God loves a servant, if Allah loves a servant, then he grants him the quality of gentleness. No household is deprived of kindness, but that they have been truly deprived. God also responds to our love of him with love. So here's a very famous, these are a category of Hadith that we call Hadith Qudsi, where God is actually speaking in the first person. So it's not revelation from the Quran, but it is considered still revelation or sacred text. If my servant comes closer to me, a hand span, I come closer to him or her an arms length. And if he or she comes to me walking, I come to him or her at speed. So God is responsive to our love of him. The most beloved servants to God, who are they? The most beloved people to God are those who are most beneficial to people. The most beloved deed to God is to make a believer happy or to remove one of his troubles or to forgive his debt or to feed his hunger. And again, if you look at the wording here, this is not exclusive to just Muslims. It's to humanity, people. We also have in the Quran defined groups that God has outlined of people that he loves. So I'll read these and there are no particular order. The first group are called the al-mahsineen. And these are the doers of good. So people who are engaged in just good, benevolent acts and deeds. The second are al-muktaqeen. And these are those people who are mindful of God, who are really self-aware and watchful over themselves.  Al-muksiteen, these are the equitable and just. So people who really push for justice and fairness. Those who purify themselves. We have a tradition of the Prophet Muhammad peace be upon him that cleanliness is part of or half of faith. So that's why you may find when you visit a mosque, for example, we will have spaces, pretty large considerable spaces for the what we call the lustration or ablution that we as required of us before prayer. So Muslims will sometimes be washing our limbs face up to four or five, maybe more times a day, depending on how many prayers we're doing. And so cleanliness in general is a very big part of our faith. Tawabin, those who return to him. So this is repentant.  And they do not let their sinfulness impede that process of of returning to him, no matter how many times they make mistakes. And there's quite a few different traditions of the Prophet Muhammad, where he shares that even if your sins are as much as the foam of the ocean, and if you've ever stood at the coastline here in California or anywhere and looked out into the ocean and seen the foam, you can see it's difficult to even, you know, see how vast that is. But that's the point is that don't get worried about the number of sins. Just keep returning, keep returning. And many other beautiful traditions that have the same message that God will forgive all who ask. And in Ramadan, one of the famous or sorry, the popular prayers that Muslims are saying every day in this month is Allahumma innaka affoon tuhibbun afwa faafoo anni, which is, oh God, you are the one that forgives. So please forgive me, right? So that's, this is a prayer that Muslims are saying all day. Throughout the month of Ramadan. But this idea of returning to God, no matter what you think of yourself, because you have certainty that God is the most merciful of the merciful, which is an attribute he also defines himself as. Al-Mutawakirin are those who put their trust in him. So this is also a category of people that God loves.  But those who have surrendered to know that God is in control and they turn to God first with prayer, with seeking his help, his assistance. And then of course, whatever world to know that he exists to be able to access his words. And so we look at the even the Quran is often called the ultimate love letter from God. So there's love is a very big part of the Islamic tradition. And again, there wasn't enough time, but there are many more passages and many more sacred texts that we could pull from to show that. But I thank you again so much for the honor of presenting to you. And I wish you all nothing but love. God's love. Thank you so much.