 Thank you for the introduction. This is a joint work with Stig Freuden. And it comes from a particular practical area, the area of mobile communications in general, and the LTE, or 4G in particular. In LTE, for user equipment, to authenticate and get access to the services of a network, the user equipment, it is attached with a SIM card that contains an IMSI, which is an international mobile subscriber identity, and a cryptographic key key. This IMSI identifies the subscriber in the following sense. For example, if the matching between the subscriber and the IMSI is known, then if an IMSI is known, it's a eavesdrop in a specific area. It means that the subscriber with high probability has been in that area. So this can be considered to be a location attack. In order to avoid these and other kinds of attacks, the IMSI should not be sent over in clear. And a simple countermeasure is to send temporary identifiers that are changed over time. However, there is a breach in the security of LTE that is accepted in the standard. And that says that there are some scenarios for which the IMSI is sent in clear by the user equipment when it is asked by a base station, by E-NodeB. And this was considered to be like a trade of between efficiency and security. So we leave security behind because of efficiency reasons. And it's understandable. What did we do? We looked at a rogue E-NodeB. If it's possible or not to ask IMSI and collect IMSI for users in a specific area. And in order to do that, we used an open source software that is installed on a normal computer, which emulates the core network of LTE. And then a software-defined radio equipped with antennas that emulates the functionality of the E-NodeB, so sends and receives messages communicating with the user equipment. And the idea is that, in fact, we did not use only one, but two, this kind of rogue E-NodeB because in LTE there are some special security measurements and also for efficiency. Once a user equipment, so a phone is connected to a cell, it camped on a cell, it does not reselect another cell so easily. So we used first the jammer to jam the connectivity to the commercial network. And then we used the collector to collect the user equipment IMSI once the user equipment tries to connect to our rogue base station. The hardware used for that as software-defined radio is the A200 mini equipped with some antennas, which is credit-sized cards. And this is enclosed. This is manufactured in our university. It's just an enclosure. Some normal computers, mobile terminals, and some SIM cards. And for software, we use the open area interface, which is an open source software that provides a standardly compliant implementation of LTE. It's partially because it's not complete, but it was enough for our purpose, which is available to download on the internet. And a Samsung Galaxy S4 device with service mode, which can be accessed by dialing a code. This is not only for this device. For Android, usually in Android, there is another code. So some information about the network can be extracted from there. More a little bit into details. The user equipment is initially connected to a commercial E-node B. We used a jammer to disconnect the user equipment from the E-node B. And in order to know the frequency to jam, we just use this code and get the information from the phone. And after that, the user equipment will try to connect to another cell, which is on a frequency based on a list of priorities. Because in LTE, there is a list of priority of frequencies. So if the first priority is not available, it goes to the second and so on. So the collector should be configured on the second highest priority frequency in the list. So once the jammer disconnects the user equipment from the E-node B, the user equipment connects to the collector. And then in order to get the second frequency to know how to configure the collector, it's really easy. Because first, in the first phase, we just gather some information from the user equipment running this code. And then we run the jammer. And the user equipment will connect again to the commercial network on the second frequency. So the collector will then be set up with this second frequency. Then first, the collector will be run. Then the jammer will be run. Again, the jammer will make the user equipment disconnect and then connect back to the collector, giving the EMC information required. There is an extra requirement for that. There should be a different tracking area code, where tracking area code is a set of cells. But this is a little bit more technical information. Like for results, there are some EMCs that are catched here. This is a Warshark capture. And this is from the logs of the open area interface. The behavior is different in the sense that after disclosing the EMC, the user equipment can go back to the commercial network, can just remain in the denial of service until rebooting. So until rebooting, it will have no access to mobile services at all. Or it can go back to the commercial network, but it can go downgrade from LTE to 3G or 2G. Our work is not novel in terms of ideas. And there have been other works similar. Here are only two of them. The first one being this one in the field. However, we are the first, as far as we know, using the open area interface for that, which gives an advantage in the sense that there is absolutely no change in the code required to perform the attack, at least for the denial of service until rebooting the phone. So EMC catchers are existing in the real world. It's not just a theoretic idea. And one example is very mediatized, very top-ranked investigation in the newspapers of Norway quite recently about the possibility of EMC catchers close to the parliament building in Norway. Then there exist EMC catchers publicly available on the internet for 2G, 3G, or 4G. And this can be considered like the new versions for the old known thingry, for which even the manuals have been released last year. What does this have to do with crypto? Or what is the cryptographic problem that is underneath this? The problem is that how can we construct efficient and scalable secure identification mechanisms in mobile communication systems? Because, for example, we have a subscriber that wants to authenticate to a network, to a provider. It has an ID and it has a key, a cryptographic key. And the subscriber has all the list. And then the provider, based on a protocol, should output the ID and the key. Is it possible to do that while the ID and, of course, the key remain unknown or secure for any kind of adversary? And, of course, in the public key settings, there exists a trivial solution, just to encrypt the identity under the public key of the provider, the provider decrypts. The problem is that we don't want a public key solution because, in the particular case of LTE, that has not been accepted at the beginning. A linear solution exists even in the symmetric settings. A random number is chosen, then is encrypted under an appropriate encryption system. And then all the keys are tried until successfully decrypts the R. But this has another problem. The problem is that it takes linear time. So it has to go through all the list. The provider needs to go through all the list in order to get the ID. There is a lot of related work, very specific to mobile communication or specific to RFID. However, our solution or our problem wants to be somehow independent of the scenario and even more decoupled by the registration and the authentication that follows afterwards. But just to find the simple solution in the settings of symmetric crypto. In summary, all the existing solutions are not efficient or not appropriate to some scenarios. And of course, it also remains the problem if the MC catching is a bug or a feature because it can be considered in both ways. But it has to be a way that a thing that should be considered for 5G and beyond. Thank you. Mentioned the jamming. You said that you use information from the client device to set up the jamming. Is that does that require you to actually access the specific client device or do all the client devices in the same cell share that information? All the clients in the same cell share the same information because the information that we need here, in fact, it's the frequency band, the download band, the tracking area code, which is a set of cells in the location area, mobile country code, so the country code, the network code, the operator code, and the cell ID. So all the devices share the same information. Otherwise, the attack would have not been possible, of course. Thank you. Thank you. Any more questions? No? All right. Well, thank you very much, Roshanda. Thank you.