 Okay, the third talk of the session will be about the SCP-02 protocol and the talk will be given by Loïc. Thank you very much for the introduction. So good morning, everyone. So the outline of my talk is the following. First, I will briefly describe the SCP-02 protocol that I will present to the Paddingham regular attack and next I will explain the experimental results that we have obtained and finally I will conclude. So SCP-02 is a security protocol promoted by global platform and in fact it's an element of a wider set of protocols such as SCP-03 or SCP-80 and each protocol has different features and SCP-02 is based on two symmetric key functions, DES and TRIPLE DES and with these two functions mutual authentication scheme, a key exchange scheme and finally a secure channel are provided and the secure channel aims at guaranteeing data confidentiality and data integrity. The main purpose of SCP-02 as well as the other SCP protocols is to provide a secure channel. In fact, SCP stands for secure channel protocol and the genuine classical scenario when SCP-02 is used is when one wants to upload in the SIM card an applet. So I'm pretty sure that everyone of us has a SIM card plugged into his or her smartphone and when one wants to use a new service with the smartphone, for instance a transportation service or a payment service through NFC, the first step is to install an applet into the SIM card. So very likely the scenario, the following scenario is followed. So there is a remote server that stores all the applets and an SCP-02 channel is established between this remote server and the SIM card. It's a channel end-to-end between the SIM card and the remote server. There is an application on the smartphone that will relay the encrypted commands sent by the server to the SIM card, which commands carry pieces of the applet. And it may also be possible that an additional security protocol be used between the remote server and the application on the smartphone. And in that case, there are two security layers between the server and the application, for instance, SCP-02 over TLS, and there is only SCP-02 between the application on the smartphone and the SIM card. So since what I'm going to describe does not lie on the way the mutual authentication is done and how the key exchange is done, I will skip this description and I will assume that the remote server and the SIM card are mutually authenticated, and they do share new channel keys, and now the server is ready to send encrypted commands to the SIM card. So when the server wants to send encrypted commands to the SIM card, it does two main operations. The first one is to compute a MAC tag. So a non-encrypted command is made of two fields, the header and the data field, and this data field contains the plain text, which may be a piece of the applet the server wants to upload in the SIM card. So this first operation outputs an 8-byte MAC tag, and the second operation is to actually encrypt the data. Since encryption is done with a block typhoon, the plain text is always followed by the padding data, and then the plain text plus the padding data are encrypted, and this outputs the cipher text. And finally, one gets an encrypted command, which appears at the bottom of the slide. This encrypted command is made of a non-encrypted header and the data field, which contains the cipher text followed by the 8-byte MAC tag. Upon reception of an encrypted command, the card does exactly the reverse operations. First, the card extracts the cipher text, decrypts the cipher text, and gets a byte string that hopefully is made of first the plain text followed by the padding data. Since the padding data has a specific format, the card must be able to discriminate between the plain text and the padding, and in a CPU2, the padding is made of at least one byte, which is equal to 80, followed by one or possibly known null bytes. So once the SIM card has extracted as discriminate the plain text, the card can recompute the MAC tag, and this computation is done over the genuine header and the plain text and some padding data. And then the card compares this new tag with the card the card has received on the encrypted command, and if both tags are recalled, the card assumes that integrity is preserved, and then the plain text may be stored at some offset in the card's memory. So encryption in a CPU2 is done using a CBC mode. So I'm pretty sure that everyone knows how CBC mode works. When one wants to encrypt a plain text block B1, this block is first masked with the previous encrypted block C0, and then this result is actually encrypted, and this outputs a block C1. Conversely, when one wants to decrypt an encrypted block C1, this block is sent as input to the decryption function, and the result is unmasked with the previous encrypted block, and this hopefully outputs the genuine plain text block B1. So as we can see, the previous encrypted block C0 has a direct influence on the result of the decryption. That is, if an adversary drops an encrypted command and changes, for instance, the last byte of the encrypted block C0, this modification will appear at the same position on the decrypted block. If these two blocks C0 and C1 are the two last blocks of an encrypted command, the same card expects after the decryption to find some plain text followed by at least one byte of padding data. And in that case, if there is only one byte of padding data, this byte must be equal to 80 per specification. But of course, since the attacker modifies C0 with some value, it randomly chooses some value G, of course, the result of the decryption very likely will not output a valid padding data. If the attacker likewise repeatedly makes the same change with the same block C0 with different value G, once again, this will not output a valid padding byte 80. But in one case only, in one case among 256, with a specific value G, this will output a valid padding data. So of course, the attacker does not know what's going on inside the card. It does not have access, at least direct access, to the result of the decryption. But let us assume that the adversary is able to get this binary information whether the padding is correct or not after the decryption. Then when the attacker knows that the padding is correct, it knows that B7 plus G is equal to 80, hence the attacker can deduce the secured byte B7. So this means that knowing the validity of the padding after the decryption allows the attacker to deduce one byte of secret data. And this technique is called padding regular attack and is due to Serge Von Ney, which has found it in 2002. So the question now is how may the attacker know when the padding is correct and when the padding is incorrect after the decryption. So there are basically two main cases. The first case is when after the decryption the card is not able to find a valid padding data. And the second case when the card finds a valid padding data. So in the first case, it may happen that the decryption module or the smart card send a specific error code saying that something wrong went with the decryption. Because in the first case, after the decryption, the card cannot distinguish the plain text and likely cannot compute the MAC tag. In the other case, the card decrypts the data, finds some valid padding data and then can proceed to the MAC verification. But recall that this encrypted command has been modified in the first place by the attacker. Therefore, the MAC verification will be incorrect. So it may happen that the card in that case send a different error code saying that something wrong went with the MAC. So if the card behaves so, then this provides the information the attacker needs to perform the padding regular attack. But there may be also another case. And the other case, the other possibility is the following. In the first case, when the card after the decryption does not find a valid padding data, it may happen that the card may not be able to compute the MAC tag. On the other case, the card can decrypt, find valid padding data and then can proceed to the MAC verification. Therefore, the computation time in either case is different and this can also be used by the attacker if it's able to get this information to mount the padding regular attack. So back to our practical experiments. In our case, we have tested several smart cards and what we have observed is that the card open reception of an encrypted command always sends a response. This is per specification. This is the so-called 2 byte status word. We have also observed that be the padding correct or not after the decryption, the card sends always the same error code to the server. And this is per SCP02 specification. But we have also observed the following. This graph depicts the response time of the card in either case. The red curve corresponds to the response time when the padding data is invalid after the decryption and the blue curve corresponds to the response time when the padding is valid after the decryption. So this leads to two observations. The first one is that, seemingly, the card behaves differently in either case. Very likely, when the padding is incorrect, the card decrypts the data but does not make the computation. Whereas in the second case, the card decrypts, finds some valid padding data, and then makes the computation. And this leads to the second observation, which is that the computation time spent by the card is, in fact, directly reflected in the response time. So this response time provides a suitable padding record in order for an attacker to mount the attack. And this observation has been made in several cards that we have tested. The response time may be different depending on the card, but in all cases, we have been able to clearly distinguish between the case when the padding is incorrect after the decryption, which corresponds to the red curve, and when the case when the padding is correct after the decryption. So more practically, more precisely, what we have done is that we have used an experimental setting. We have simulated the server, and we have tested 10 models of smart cards provided by different manufacturers. We have tested two types of smart cards, either SIM cards or generic Java cards. And the experiment that we have done is to randomly generate 16 bytes, and these 16 bytes have been sent through encrypted SAPO to command to the card. And the purpose for our attacker was to retrieve these 16 bytes using this padding record attack and the timing side channel. We have made the same experiment several times with each card, and in all cases, we have been able to retrieve these 16 bytes, which could be asymmetrically, for instance. The complexity of the attack is almost optimal, and regarding the duration of the attack, it ranges from roughly three minutes up to 12 minutes. And in fact, this duration depends almost only on the card, but not on the specifics of the attack, because some cards send the response to the server faster than other cards. So this shows that the padding record attack is applicable to SAPO2 and to several models of cards that do implement the protocol, and the question now is, how many smart cards can be impacted in real life? So I don't have the answer to that question, but at least one can propose a realistic scenario that an attacker can apply in real life. So this scenario is, in fact, the standard, the classical scenario when one wants to upload an applet into its SIM card in order to be able later on to use some service, such as a payment service or transposition service through NFC with her or his smartphone. So the applet carries a symmetric key that will be used by the legitimate owner of the smartphone to authenticate and to grant access to the service. And the purpose of our attacker is to get to retrieve this key in order to impersonate the user. So the first step of this scenario is to infect the smartphone with a Trojan. So this seems difficult to achieve, but last year Google has detected in its store 700,000 applications that were potentially harmful. And this number refers also to applications that were embedding malware or Trojans. So this may be a suitable contamination vector. Once the Trojan is on the smartphone, it can get through privilege escalation, access to the memory space of the application, the legitimate application, that relays the encrypted commands between the server and the SIM card. Then to the other point, the Trojan can modify the encrypted commands and can detect when the SIM card sends the response to the server. That is, the Trojan can apply the padding or echo attack. Moreover, since the attacker needs to make several trials in order to get one byte, the Trojan can repeatedly trigger the installation and the installation of the applet in order to compare the server to repeatedly send the same applet to the SIM card. So now what can be the possible mitigations? So the first mitigation obviously is to correct the implementation. I think that it's not an easy task to achieve. And moreover, it's not a mitigation that can be used for a card that are already deployed. Another possibility is to use additional security mechanisms, either instead or in addition to a CPU. But once again, this assumes that such mechanisms be available on the smart cards that are already deployed. Also, one can use a specific CPU to command, which is called Putki. And when data is encrypted with this command, data is encrypted, in fact, in fact, twice. The first time with an extra channel key, and the second time with the procedure that I have described in this talk. So if an attacker uses this command to apply the attack, the attacker will succeed in breaking the outer encryption layer, but eventually will get data that are encrypted with this extra channel key. So regarding the padding or echo attack, this seems an efficient way to mitigate the attack. Nonetheless, in the CPU too, the encryption schemes are deterministic. So in fact, even if one uses this command, Putki, it's possible to retrieve another type of secrets, maybe a password or a pin code, if the attacker has access to an encryption or echo. Finally, what another way to mitigate the attack is to forbid the server from sending too many times the same secrets to the SIM card. Since the attacker needs to make several trials to get, to retrieve one single byte, this is an efficient way to throw out the attack. So to summary, we have shown that the padding or echo attack against the CPU too is possible. This is possible for two reasons. The first one is theoretical and lies on the way the protocol is designed and more precisely in the encrypted MAC scheme. And the second reason, very likely, is related to the way the protocol is implemented in the smart card. Of course, several requirements must be fulfilled for an attacker to be successful. And in particular, such an attacker must be able to discriminate between the response times sent by the card. In practice, we have shown in an experimental setting that different models of smart cards can be attacked with this attack. And the question is now, how many cards can be impacted in real life? We have informed the MAC card manufacturers that have produced the card we have tested and also global platform, which is in charge of the protocol. And while this paper was under submission, SEPO2 has been deprecated by global platform. And now what is recommended is to use SEPO3 instead. And this concludes my talk. I thank you and I'm willing to answer any question if you want. Thank you. Thank you, Olivier. Do you have a question? Yes? Did they get rid of the MAC then encrypt in SEPO3? Yes, in SEPO3, the scheme is completely different. It's a MAC, it's encrypted than MAC scheme. And moreover, it chooses AES and not SEPO3. Another question, maybe one short question. The attack is existing since 2002. How do you explain that developers have not implemented conter measures against this padding or attack? Well, I don't have exactly an explanation, but I think that the reason why this attack has not been found in this protocol, SEPO2, is because I saw, as I know, the protocol, the specification was presented publicly, maybe a few weeks or a few months before Serge Vonnet has presented his seminal paper on the padding or attack. And I think that this shows that, in fact, all cryptographic schemes should be analyzed based on the new findings in cryptography and security. Another reason, maybe, that, in fact, even though SEPO2 and other SEP protocols are, according to me, widely used in numerous security elements or smart cards, I think that, in fact, there are pretty confidential schemes and they are not publicly discussed nor analyzed. And this may also explain why such attack is possible nowadays. But this flow of SEPO2 was already known? No. The fact that padding or attack was possible? As far as I know, it was not known or at least it was not publicly known. Thank you. Another question? No? Please thank the speaker again.