 One, I'm going to get started here. So this is session eight on side channel attacks. And for people coming in, there is still a whole row available at the front. And it's fully open, so you can really easily leave if you want. Halfway, don't worry. And there's some seats up here, so please come forward. So the first talk that we're going to hear in this session will be EM analysis in the IoT context. Lessons learned from an attack on thread. And this is really interesting, at least to me personally, as well, because thread is used in the Nest products. And you have stuff like the Nest Protect smart smoke alarm has five microcontrollers, all with over-the-air firmware updates for each of the five microcontrollers in it. So there's probably a lot of interest in work that can be done. And this will be presented by Daniel Dinyu, as well as by Elie Kizotov. I'm going to do my best Canadian pronunciations of all the names, so you'll get to enjoy that as well. Thank you, Daniel. OK, thank you very much for the introduction. So I will start with a short introduction. Then I will present our vulnerability analysis with respect to EM analysis of thread, and I will explain you what thread is. Then I will present the steps of the most feasible attack we could find. I will discuss a little bit what countermeasures can be used to protect against this attack. And finally, I will describe the lessons we learned and how they can be useful for other IoT systems and protocols. So how EM analysis work, the attacker wants to recover some secrets from a target device. Usually it's a secret key. And the attacker observes some computations with that key, and at the same time, it captures the leakage from the device using an oscilloscope, for example. And after, he observes several operations and the associated data process. During those operations, using statistical techniques, the attacker can recover the secret. In this work, I will focus only on electromagnetic analysis. So when you see side channel attacks, it refers to electromagnetic analysis. Thread is a networking protocol for IoT developed by the Thread group, which consists of more than 100 companies from various business sectors, major companies. The one you see on the slide are the founding member of this organization. So they are actively developing the protocol. The protocol is meant to be simple for consumers. To be easy to deploy devices using this protocol, it is designed to be power efficient and to run on existing radio silicon. Also, it uses IPv6 addressing, and it's based on the robust mesh network. What is also important to mention, it provides security, so it is designed to be secure. So what is the motivation of this work? First of all, in the last years, we saw a lot of tools, both hardware and software tools for side channel attacks. And these tools have a lower and a lower cost, so it's becoming easier for an average attacker or a normal attacker to perform such attacks. Also, we wanted to evaluate the effort required to apply electromagnetic analysis attack in the IoT context. And finally, our ultimate goal was to answer the question, do cryptographic implementations in the network layer of an IoT protocol need protection against side channel attacks, or they are fine without any kind of countermeasures? So let's see this. First of all, we looked at the communication security in this protocol. So there are two different layers, and both of them, they use ASCCM for encrypting the communication and authenticating the messages sent at each layer. And the first layer is medium access control layer. It uses the medium access control layer key, KMAC. And the second one is mesh link establishment layer, which uses a different key, MLE key. Essentially, when a node is added to a thread network, it gets the network master key. It's a 16-byte key, K. And from this key, it derives these two temporary keys, KMAC and KMLE, which are used to secure the communication at the two layer. And these two keys are generated from the master key and a sequence number, which is for byte value. And after a certain period of time, the keys are changed. And the default value for a key rotation is set to 28 days. Then we looked how we can trigger some executions of cryptographic operations, because we wanted to recover the keys of the network to be able to get access there and control the network. So one of the first messages, a child, which is a node who connects to the network, is sending, is an MLE parent request message. And here, depending on the sequence number included in this message, the receiving router takes some decisions. So if the received sequence number is different from the sequence number of the router, who is already in the network, then the router will generate a temporary key using the HMAC function. And using that key, it will verify the tag of the received message. On the other hand, if the two sequence numbers are equal, then the router will continue directly with the tag verification of the received message. I won't discuss here the attack on HMAC and how it works. I will focus on the attack on ASCCM. So ASCCM, as you know, is a combination of CBCMAC mode and counter mode. And an attacker can essentially attack execution of any of these two modes of operation. And it can control up to 12 input bytes. So it can control the source MAC address, and it also can control the frame counter. This is known attack was initially presented by Jaffe, I guess, chess 2017, and then by Offlin and Chen, Jose 2016. Then it's important to analyze the relationship between the master key and the MLE temporary key used in the network. So we already saw that having the master key, we can derive the temporary key, the MLE key, using the key derivation function based on HMAC SHA256. The question is, is there any way to get from the temporary key to the master key of the network? Well, surprisingly, yes, there is a way. And it works like this. A child has to send an MLE child ID request to a parent and ask for the master key of the network. And the parent will send back MLE child ID response, which will include the requested information, so it's the case the master key of the network. What does this mean? It means that the two keys are equivalent. Having one, you can also have the other one. So you have K, you can get K MLE, you have K MLE, you can have the master key of the network. OK, so now let's see how all of these can be changed to create a full attack. So in the first step, the attacker simply observes MLE advertisement messages, which are multicasted by the router at the specific interval to advertise its presence in the network. And the attacker will simply record the sequence number, which is unclear in these messages. Then in the second step, it will inject MLE parent request messages with the recorded sequence number, random source MAC address, and frame number. And in this way, it will trigger AS computations on the target's router. And it will simply observe the M leakage of those computations, and it will save traces for these computations and the injected input values. Then in the fourth step, it will mount a differential electromagnetic analysis attack to get K MLE. And having this key, it can come back to the network, send an MLE child ID request message, and ask for the master key of the network. And the target router will send back the master key of the network. Having the master key of the network, the attacker can also connect to the network, essentially. It can communicate with the nodes in the network, can understand the communication in the network, eventually can change parameters of the network, and take full control of the network. OK, so this is how the attack works in theory. Let's see how it is in practice. So we used an experimental setup, which consisted of a TI development board, which has Cortex M3 microcontroller, which was clocked at 32 megahertz, the maximum frequency of this device. We used the open thread implementation of the stack, which is freely available. We used a Likroy oscilloscope, Langer EM probes, and amplifier. We also tried with new AE EM probe. And indeed, in the figure, we can see the amplifier from new AE there. And also for the final results, we did not use any trigger signals. So we tried to use real settings to see how this can be done in real settings. So the results, we had to use a sampling rate of 1 giga samples per second, because a lower sampling rate did not get good results with our lower sampling rate. We were able to measure 10,000 traces in about three hours. And this amount of traces were enough to fully recover the MLI key. Although we struggled a little bit on recovering two key bytes, so these two key bytes were more difficult to recover, we saw in the literature that there are also papers reporting similar problems. Well, we were able to recover the MLI key, but we had the problem when we tried to get the master key of the network. So essentially, what happens there is we send the MLI parent request message to us for the master key of the network. But the answer did not include just the master key of the network, but also some default values, which were added by the router, were not requested by the attacker. And because the total length of this response message was higher than 127 bytes, which is the maximum transmission unit at the MAC layer, it had to be fragmented. And because it was fragmented, it was also encrypted at the MAC layer, which we did not expect when we analyzed it on the paper. And this encryption with the MAC key essentially kind of prevented us to recover the master key. Nevertheless, the paper of Lin and Chen shows that this is possible. It's just a matter of mounting another attack to recover the MAC encryption key, and then having both MAC key and MLI key, you can get the master key of the network. And also, we don't exclude the possibility that this attack will work just with the MLI key in the case depending on the way the stack is implemented. So if the parent sends back only the information that child requests, in our case just the master key of the network, there is no fragmentation. So it should be possible to recover the master key only having the MLI key. So how to protect against this? First of all, we thought, OK, you can put a device inside the metal box, for example, and you already reduce the amount of electromagnetic emissions. And you can make it also temper resistant if you want to have more security confidence in your device. Also, it's a very good practice to protect the cryptographic implementations using well-known countermeasures like masking, hiding, combining both of them. Also, we looked at some protocol level mitigations. And maybe one of them is to limit the number of MLA parent request messages a router is processing in a specified amount of time. In doing this, you can essentially limit the number of traces an attacker can observe for a particular key. And you can also consider rotating the keys in the network much faster than 28 days. Again, you limit the time the attacker can observe computations with the same key. And maybe also a security certification scheme can be useful because it can provide some assurance that each device on the market meets some minimal security requirements. And of course, a combination of all this is better and provides a higher security level. But of course, it's more expensive and increases the cost of products. So what we learned from this? So as I said at the beginning, this helped us to understand what if electromagnetic analysis is a threat to IoT context. And we think that our results can be useful for designers of IoT systems and protocols. So first of all, it's electromagnetic leakage has to be prevented because it can be used to attack IoT devices. Second thing, do not create a mechanism to get the master key from a temporary key because essentially this violates the key derivation principle now. So they should not be equivalent. The third thing, which is kind of also can be considered for future research, is the fact that a network-wide master key seems to be a double-edged sword. It's good because you can easily set up a network. You have one key for all nodes. But also, this means that if a single node in the network is compromised, the whole network is compromised. So for example, combining this with some public key scheme might be useful in the sense that if a node is compromised, the rest of the network is still fine and can work. So finally, I would say side channel attacks are a real threat for the IoT. And this threat should be addressed from the early design phases of IoT systems and products. And I hope all IoT products will be secure. And thank you very much for your attention. Thank you very much. So we have time for a question or two. If there are any? Can you hear me? Yep. Yeah, thank you for the talk. Just a question, what was the most challenging part of the work to apply your side channel attack against the target IoT device? What was the most challenging? Yes, I think one of the first was we wanted to find a way to get into the network, like to find a network mechanism. This was one of the challenges. And after we had this, it was the side channel that part itself. And indeed, I didn't mention, but we spent roughly two-thirds of the time improving the attack and fine tuning. So it's difficult because you also have the radio transceiver. And I think it affects the quality of the signal you get with the EM probe. So this is one of the difficult things as well. OK, so the tricky part was to extract the signal. Yes. And to get to these results, we spent a lot of time arranging the probe and then looking what is wrong. And in India, for example, with those two key bytes, we wished to reduce the number of traces to attack those two key bytes, but we were not able to do this. So it depends. The success of an attack, if you would try to attack another device, depends a lot on the time you invest to understand the leakage of that device and how to place the probe and these kind of things. Maybe a last question. How would you rank the expertise of an attacker trying to apply this attack on the field? Well, indeed, we've done. Yes. So there is no kind of criteria to do this, but we follow the Joint Interpretation Library, which is based on common criteria, and we try to, which provides some way to score attacks. And based on this, we try to score our attack. And the final score suggests that this type of attack is an enhanced-based attack. So it's not easy to perform for someone who is not familiar with side-channel attacks and does not have some minimal background, but it's also not a very demanding attack like you'd need extremely expensive equipment and these kind of things. So in terms of equipment, though we use a liquefied oscilloscope, we think that mid-range devices like PicoScope or a chip whisperer pro should work for the target we analyze. Of course, now if you switch to hardware attacks, implementations, and protected implementations, of course, you will need also to increase the cost and the attack will become more complex. So it will go on the right side of the spectrum. Well, it's OK. Thank you. I think I'm almost out of time now. One quick question. If you talk to Nest or anyone, did they care? What was the response of? Yeah, they care. They acknowledge our findings, and essentially they decided, and this is also mentioned in paper, a thread group to elaborate some guidelines to make software engineers aware of this type of attacks and to prevent them from happening. So definitely it's a concern, and I think it's already addressed in the thread level and all companies involved in thread. They are aware, and definitely this is not in products or. Well, thank you very much. Again, thank you.