 Hello, my name is Damian Visar and this is the presentation for the Paper Power Yerga, Variable Stretch Security of CCM for Energy Efficient Lightweight IoT, a joint work with Emiliano Giridi and Reza Ariane Itebar. We'll start by reviewing the motivation in the context of lightweight cryptography. Then we'll have a look at Authenticated Encryption with Variable Stretch. We'll introduce the Variable Stretch variant of CCM and talk about experimental results before concluding. This work has everything to do with lightweight cryptography, which is designed and optimized for specific design trade-offs or performance constraint profiles, which are not that well served by conventional versatile cryptography, such as encryption modes based on the AES. And because the design targets for lightweight crypto tend to be a bit extreme and nichey, the meaningful ones should be motivated by applications and use cases which frequently occur in the real world. An example would be the performance and cost optimization for embedded applications. The real world need for new lightweight crypto algorithms is evidenced by the currently ongoing lightweight crypto project run by NIST, in which NIST is looking for new candidates for standardization, for authenticated encryption and hashing. NIST has specified a number of requirements that the submitted candidates must meet, and most of these do not appear to be linked or induced by any very specific use case or application. There is one interesting requirement on which we will focus here, and that is that the candidates should be optimized to process short messages. As a matter of fact, there is a large number of applications which do touch and treat messages which are short or very short. Most of these applications fall under the umbrella of Internet of Things and are growing in numbers proportionally with the IoT itself. On the other side, we then have communication protocols and technologies which are used in these applications with constraints or embedded devices, and we see that the maximal payload sizes that these protocols allow are pretty small themselves. And if we were to look at the actual message sizes that are transmitted by the devices in these applications, we would see that these are even smaller than that. And now our goal is to optimize authenticated encryption for this set of use cases. Let's start with a quick reminder on authenticated encryption. So the nonce-based authenticated encryption with associated data, as formalized by Rugaway, defines deterministic encryption that, with the help of secret key, can encrypt the message authenticated alongside authenticate what we call associated data or a header with help of a nonce, which is an initialization vector type input which must not repeat for encryption. And then when decrypt, the decryption should be able to detect if ciphertext associated data or nonce have been modified. The security of authenticated encryption has been formalized as indistinguishability of encryption and decryption that is made available to the attacker as a blank box using some secret key from a pair of oracles where the fake encryption oracle returns random strings which are completely independent from the oracle inputs and the deep fake decryption oracle always rejects. So it always returns the rejection no matter what the adversary queries. And as long as the attacker does not repeat nonce to the encryption queries and does not try to decrypt a ciphertext tuple that is known to be correct trivially, these two systems should be hard to tell apart. Let's focus on stretch. So this is a particular property of authenticated encryption that is interesting for us in this talk. And that is the fact that in order to have authenticity, the ciphertext of authenticated encryption has to be longer than the plaintext. So there has to be some non-trivial redundancy that is dependent on the key in the ciphertext for the decryption algorithm to be detect if there has been a modification. And for most good authenticated encryption schemes, the size of this overhead that we denote now here is proportional with the resistance against forgery attempts or proportional with the cost an attacker has to pay with attempts before they can forge. So if we go back to the context of wireless communication stretch, so the thing that gives us authenticity becomes overhead. And it's intimately related with the main cost factor of wireless communication, which is the packet length. The longer the packet, the more energy has to be spent to transmit it. And the processing cost here is really negligible compared to the cost for transmission. This may not be very popular to say at the cryptography conference, but cryptography in the broader context is just risk mitigation tool. And so sometimes in some applications, it may make sense to use tags which are shorter than what we cryptographers like to suggest. So this has already been investigated by Desmet and others who took a game theoretic treatment to find optimal length of authenticator tags. And so what we could envision for some of those low power constrained applications is that a simple device like a sensor node would have a secret key used to treat messages with authenticated encryption, such that for messages or data, which are not that critical, I could use shorter stretch, shorter ciphertext expansion, then for messages which are really important and their modification would have a critical impact on the system. But how does one formalize such a thing? You probably noticed that the old conventional formalism for authenticated encryption with associate data does not allow the tag length to be chosen as a user input or as an input argument. So how does one define security when this is now the case? So this is exactly what we did in the previous joint work with Reza Rehanitabar and Serge Vodane. We have formalized the notion of nodes based AAD with variable stretch, and we have defined the security of such a construction through indistinguishability. Here in the real world, the adversary has access to encryption and decryption oracle using the same key for every tag length that is allowed for the given AAD scheme. Then in the ideal world, we select one tag length. It's fixed but arbitrary, so it's a parameter of the notion really, and we replace the encryption and decryption oracles with the same idealized version as in the basic notion. And what this really captures is that no matter what happens with other tag lengths, for example short tags could be already forced by the attacker, this has no bearing on the security for messages that are treated with the target tag length tau C. We have also formalized an auxiliary notion which is useful when approving NVA security. In this notion, we insist that an attacker cannot distinguish between the case where we use the same secret key for all the tag lengths from the case where each tag length has in fact an independently sampled secret key. So in other words, changing the stretch has the same effect as if we changed the key. And then the main interesting result that we have proven is that if an A scheme has the case property and it's also secure in the sense of the simple AAD security, this implies NVA security. So this is how does it look stated formally. Now that we have seen that there is motivation and need, and we have reviewed the formalism and definition of authenticated encryption with variable stretch, the question is how do we build a new scheme for variable stretch AE such that the result has a maximum real-world impact? Well, we should start with an existing AAD scheme which is already standardized and it's already widely used and transform it with the black box transform. In other words, we are only allowed to play with the inputs to the AAD algorithm. We are not allowed to change anything inside the algorithm itself. Is there such a candidate already? Well, you have guessed it. There is CCM. Yeah, CCM has been around for a long time. It's already used the protocols that see massive real-world deployment, in particular for us, BLE and ZigBee for constraint applications. And there are many, many implementations available, especially hardware acceleration in the middits platforms. The downside is that CCM is not really much loved by the community. Among the criticisms is the complaint that the internal structure is a bit inefficient. But it is precisely this internal structure which allows us to define a functioning black box transformation for variable stretch security. All right, let's recap how CCM works. CCM has two principle components. The first is the CBC MAC, which computes authentication tag. We see that the CBC MAC takes processes, these blocks B1, B2 to BLE, and these are obtained by chopping down and encoding of associated data, length of associated data and message. The CBC MAC is started by a special block that consists of the nodes encoding of the message length and some binary flags. Then the encryption of message blocks is done by counter mode, where the key stream blocks are generated with block cipher inputs consisting of the nodes encoding of a counter and some other binary flags, which serve the purpose of domain separation. We see that the counter value zero is used to generate key stream that masks the authentication tag. And this is all it takes to transform CCM into a scheme that is secure with variable stretch. We simply take one byte of the nodes and dedicate it to an encoding of the tag length. And that's it. We just do one byte of the nodes and use it for the tag length. So it's very simple and it may not look very impressively in terms of beautiful cryptographic design, but the beauty lies in its simplicity because it makes it really easy to use and implement correctly. And the main result of our paper is the security bound we have proven, which shows that the variable tag length variant of CCM is indeed secure to be used in this way, variable stretch. If we look at the bounds, we actually see that it's pretty similar to the bounds that regular CCM has. And so moving to variable stretch does not really degrade the security bounds in any significant way, quantitatively speaking. Our security analysis uses the result where NVA security is implied by simple A security and key equivalent separation by stretch. The simple A security of CCM has, of course, been established long time ago by Johnson. For the key separation by stretch, we made the observation that the initial CBC MAC, the initial block cipher call in the CBC MAC, and all the block cipher calls in the counterpart, use nonce as part of the input. And since we're putting tag length into the nonce, we're actually making sure that the block cipher inputs between tag lengths are not colliding, and different tag lengths uses fresh randomness. What remains are the internal calls of the CBC MAC, but these are not directly controlled by the attacker and can only cause a collision randomly. In more detail, we see here the outline of our security analysis. It's pretty standard. And we start by a replacement of the block cipher by a secret random permutation, then we perform an RPRF switch. We follow up with the theorem from previous work, plug in the result by Johnson, and then we perform a case analysis of VCCM. Here we see the contribution of each of these steps to the bound. Then if we add these together, we get the bound we have seen on two slides ago. The main and non-trivial part of the analysis is of course the analysis of KESS security of VCCM. For this purpose, we used the framework of code-based games, where we defined two games, G0, G1, which had produced the identical distributions as the real and ideal game of KESS, respectively, such that these two games had the same code except for what happens after a flight bed. And then the analysis was just looking at what is the probability bed is set. Before bed itself, we also defined an auxiliary bed event which just made sure that there is no collision in the inputs to the block cipher in the real KESS game caused by the CBC MAC, whereas we said previously the intermediate blocks are randomized by feedback, and so we cannot exclude a collision. So when we take that out of the question, what remains is to lazily sample on the real hand side a random function that is used for all the block cipher calls for all tag links, and in the ideal side a collection of independent random functions such that each one is used for one time length. And then we just have to make sure that these two are consistent in the way that is defined on the slide. And if they stop being consistent, this is the bed event. All right, so now we have successfully constructed a provably secure AAD scheme that can be used with variable stretch. We have also claimed that using such a scheme in a clever way will allow us to save energy of a constrained embedded device. And now we have asked ourselves the question, well, okay, how much energy can we actually save with a real device, with real hardware? Because the result that shrinking packets saves energy is pretty folklore, but it's not easy to find the result that would quantify this. Answer the question, how much can I really save? So what we did is we considered a simple scenario where a wireless sensor node is regularly sensing and reporting the sense data, and our objective is to maximize its battery life. And we will apply the suggested way to use variable tag AAD. And that is we will have two classes of messages. Regular messages are the ones that are more frequent. Think about temperature readings from a remote thermometer, which are maybe not that sensitive and we can live with a shorter stretch. And then we have critical messages, which are sent less frequently, but where the modification would have a critical impact on the system. You can think about something like, I have enough battery, you don't need to shut me down remotely. In our experiment, we used a wireless sensor node platform developed at CSCM, which is really optimized for low power consumption. So both the microcontroller and the transceiver are selected to consume as little as possible. The node was running a low power operating system by CSCM, and the application was super simple. The device is sleeping, it wakes up, it encrypts some fake data, transmits them and goes back to sleep. And then we use the Raspberry Pi to verify we're really sending and encrypting something. And we measured the power consumption with an oscilloscope. All right. So then what we did is run the measurements with both the VCCM and CCM using different message sizes and using different tag length. And we measured how much energy is consumed by the device when it wakes up, runs the encryption and then transmits the resulting cipher text. We see the results here. It's not really shocking, the longer tag or message, the more energy we spend. But what's more interesting is when we take these and we use them to compute a expected or projected energy consumption for the device as a function of how long it's running. And what we see is when we compare the case where all the tags are 16 bytes, for example, which would correspond to using the classical CCM and using the maximal tag length as per the security requirements for the critical messages, we have to use it for all the messages because we just have one secret key versus the variant where we can switch the tag length because we can use a VCCM. The total amount of energy that is used by the device, including sleep, encryption, wake up, everything can be reduced by 20%, which is a lot given how little we have done to achieve this. Now that you have seen that we can transform CCM in a rather simple way to work with variable tags, and now that you have seen that this simple modification can have a pretty pretty big impact on the energy consumption of a real system, you should be asking, great, can I apply the same black box transform to all ASCII? The answer is no, already from the previous work because there are some ASCII schemes for which no black box transform works. All right, let's be a bit less ambitious and ask, okay, so are there any schemes for which your black box transform will work? Fortunately here, the answer is yes. Generally speaking, sequential modes are good candidates, and in particular, sponge modes should work like a charm. All right, this is all wonderful, so we can do marvelous things with the variable tag CCM. There's just one last caveat concerning security. What if, if we consider really short tags, say two bytes, getting the first forgery with two bytes of a tag would cost me 65,000 but then, after I have completed this, what if the next one only takes eight attempts? So that's a question of reforgery security. Fortunately, this has been investigated, and the results that exist suggest that the situation is not that tragic with CCM. And with this out of the way, being happy about security of the CCM in all front and sides considered, what we get, something pretty useful because all the implementations of CCM, including hardware implementations, are immediately usable for the CCM. So we can deploy it in the same way, and with the same efficiency as CCM on all the platforms in the shop, on the shelves. And as we have seen, doing these small changes, we can achieve pretty impressive and pretty measurable improvements of energy consumption in low power embedded devices. When we turn to communication protocols, we could ask, oh great, so are there protocols where we could apply variable tag CCM? And the answer is, in ZigBee, it's already the case. So it's already specified, I think optionally, that the tag length can be changed with the same key. It's just never been analyzed. And variable tag length is also a very natural match for Bluetooth low energy, where the different data characteristics treat different data, and the tag length could be fine-tuned for each characteristic sensitivity or risk level. And finally, just a short remark, why isn't the impact of tag length on transmission considered more in this low lightweight crypto project with respect to the optimized treatment of short messages? That's all from my side. Thank you very much.