 Hello everyone and thank you for joining us. My name is Daniel de Almeda Braga and I'm about to present a joint work between Pierre Alonfouk, Mohamed Sapt and me from the MSEC team at E-Rizaren in France. So this work target SCP-10 which is a secure communication protocol designed for smart cards by global platform. So in this presentation I will start by giving a little bit of context on the smart card world and present the protocol we studied at least the relevant part for this talk. Then we'll discuss all the flaws we discovered and their impact on the protocol security. Since the attacks themselves are not new I will not dive into the details here but feel free to ask me later if you're interested or to take a look at our paper. I will end up with a few words on a secure implementation implementing all mitigation we suggested. So we did it to to estimate the overhead induced by those mitigation. Smart cards are little electronic devices which look like a little yellow chip with a very low computational power but which can ensure a very wide variety of application and are used basically everywhere. So they are used for instance in the electronic ID card in banking card, in mobile phone with a well known SIM card and in a lot more field. So from this massive usage arise a real need to make interoperable deployment and management of application easier, regardless of the card manufacturer. And that's where global platform steps up as a consortium of multiple companies trying to define some standard specification, namely they define how the card will communicate with each other, so they define the communication protocol to be used. In this communication smart card will always act like a server so they can only process request and respond to this request with what's called an APDU which stands for application protocol data unit. And they will interact with what we will call in the rest of this presentation an off card entity through a reader which can be either a standard reader, in this case a reader itself is the off card entity or which can act as a proxy receiving command from an external server, in this case the server will be the off card entity. So all communication goes through a secure channel defined by the secure communication protocol. The goal of such protocol is obviously to establish a secure communication session between a card and an off card entity by starting with a key exchange step in order to ensure that some secure cryptographic key material is shared by both the server and the card which is then used to control security in the following communication. So there are various versions of such protocol, for instance we can mention SCP 1, 2 and 3 only 3 is not deployed today but all these three versions are strongly based on symmetric cryptography meaning that pre-shared key need to be manually deployed on the smart card beforehand and all the security of the protocol relies on symmetric cryptography. SCP 10 has a particularity to rely on the public key infrastructure meaning that both the card and the off card entity will have a key pair with a public key and a private key and they will use each other public key during the key exchange step in order to encrypt and verify some messages. So in this presentation we will focus on the key exchange part of the protocol and not the communication because the communication part is basically the same between SCP 10 and SCP 3 and SCP 3 already received a quite strong security review from academics. So key exchange can be declined in two mode key transport mode and key agreement mode. Let's focus on the first one for now. So the off card entity will start by sending two APDU to a smart card which are the setting management APDU. The first one is to select the applet responsible from SCP 10 and the second is used to set some security parameters namely the key exchange mode to be used for the key exchange. Following the setting APDU, there is a somewhat classical certificate exchange with a certificate verification from both parts and then comes the interesting part of the key transport mode. Performed security operation decryption APDU. For this APDU, the off card entity will start by generating the session keys to be used for the following communication and encrypt them with the card public key before sending it in the APDU. And only after sending these four session keys the off card entity will authenticate itself to the card by signing a challenge provided by the card. The optional internal authentication is possible but only optional and could be skipped to avoid some heavy computation from the card. Key agreements mode follows a quite similar workflow but mutual authentication is mandatory here since the key material is exchanged along the way by both parts this time and the session keys are derived only after the mutual authentication. In this key exchange mode Performed security operation APDU becomes useless since we do not exchange raw session keys so there is no need to perform this operation. So it's quite obvious that key agreements provide stronger security guarantees than key transports. However in such a constrained environment performance is a big deal and key transports require way less computational power. So what we did was to take a look at the specification describing this protocol and try to identify some flaws and some blur. Namely we focused on the RSA encryption key transports since it's used to protect very sensitive data. We are talking about the raw session keys to be used and with what we are to be some very reasonable assumption we are able to mount two different and independent attacks allowing a full session care recovery. The first attack took only a few milliseconds while the second is quite long it takes a little bit more than two and a half hour. However with the second attack we are able to combine it with an additional design flow specification to produce some valid certificate forgery signed by the card allowing to impersonate the card in all future sessions. To test our attack we had to implement our own version of SCP-10 as an applet to deploy on a card because we didn't manage to find any open source and public implementation of this protocol. And finally we implemented all mitigation we suggested to patch these flaws in order to estimate the overhead of these mitigations. So as I said we didn't attack any real cards because we didn't manage to find any card implementing this protocol but we have strong evidence suggesting that SCP-10 is in use as we speak first there are some patents issued recently by some Chinese banking company and when we talked about the global platform they told us they couldn't deprecate SCP-10 because it was in use and as I said we didn't try to identify weakness in the symmetric encryption part used during application because it is the same as SCP-3 so it will only be redundant to work. So if you were about our threat model we put our attacker in a classical man in the middle position meaning the attackers are able to initiate a session with SCP-10 with the card using SCP-10 as anybody could do without any guarantee of success and they are able to intercept, read and modify any messages between an off-card entity and the smartcard from this last capability the attacker can also measure the time needed by the card to process an APU so to perform some specific operations simply by looking at when the card receives the APU and when it emit a response to this APU however the attacker are not able to perform any physical operation of the card so we exclude any physical side-channel leak like pora-consumption attack and we exclude any fault attack and of course the attacker are not able to break the cryptographic primitives used by the smartcard and the off-card entity So after this long introduction let's start with the first issue we noticed SCP-10 specification specifically mandates to use a deterministic padding for RSA encryption in key transports so if you remember the performance security operation APU is very very sensitive since it's used to transport the raw session keys to be used for the communication part so the message to be encrypted will look like this there is a 3 byte of parameters followed by one or more CRT CRT is a control reference template which is basically a data structure containing a key along with some parameters describing its usage and if the key is to be used for integrity purposes an IV is added at the end and the padding described in the specification look like this and as you can see instead of a random byte string as used in the classical pkcs1 version 1.5 padding for encryption we have a fixed byte string with only SF bytes so this only leaves very few unknown bytes compared to the modules size so this leads us back to 1997 with the copper smith attack which allows an attacker to recover the message if the unknown part is small enough compared to the exponent namely if the unknown part is less or equal to n to the power 1 over e we are able to recover the whole message with n and e being the public key used to encrypt the data now assume that the smart card is using a 1024 bits modules routed by the specification and a small public exponent let's say e equals 3 so e equals 3 is not a common value in servers but in such constrained devices it's not rare to see this kind of value used in order to optimize some heavy computation and in need there are even some guidelines specifically designed to smart cards which allow to use e equals 3 for optimization purposes if there are less than 3 entities involved so here we only have 2 entities involved so it's fair to assume that this kind of value could be used and with this assumption we end up with a bound allowing us to recover the message if there is up to 42 bytes of unknown data this bound of 42 bytes is quite hard to meet in practice because the computation becomes really heavy so this bound however an encryption key or an integrity key yell at most 34 unknown bytes which lead to a practical attack which take on average 0.3 seconds this means that the attacker will be able to recover the session key before the smart card is able to decrypt it it will take more time for the smart card to decrypt the APNU then the attacker will need to recover the unknown part and what's nice with this attack is that it's only a passive manage the middle attack the attacker will need to intercept the off-card entity APNU and all computation are performed offline there is no need to contact the card at any time of course it only works in key transport mode since in key agreement we do not transmit forward session keys and we do not use such a weak padding so two mitigation are possible for this attack first we can mandate a sufficiently big public exponent but a better mitigation will be to use some randomness in the padding as it should be done however we need to be careful not simply increase the RSI module since it will only make the attack easier it will increase the bound on the unknown part of the message and we are able to recover and we also need to be careful and how we add randomness to the padding because simply switching to a classical pks1 version 1.5 padding may not be a valid solution indeed this kind of padding is very well known to be subject to attack to a very well known Blacenmacher padding or echo attack which in success perform a modular exponentiation using the victim private key on an arbitrary string of byte meaning an attacker will be able to either decrypt the message or to forge a signature and all an attacker needs to perform this attack is to be able to distinguish if some data have a specific format once decrypted here the perform security APDU is also a very good candidate because there is no prior authentication to reach this type of protocol an attacker can simply send the setting management APDU to the smart card and then replay a valid certificate to reach this type of protocol and if we take a look at what's performed by the card on reception of this APDU we can see that the card will perform 3 steps first it will decrypt the payload embedded in the APDU then it will verify the padding and only after this it will try to parse the data and process it so by for instance saving the session keys here the specification mandates to return a unique error code if some error occurs in one of these 3 steps so that's good but there is no mention whatsoever of constant time implementation and past attack have shown us that handling this kind of padding security is quite hard and it is very subject to side channel attack like timing attack and if we add some TLV parsing on top of the padding verification it becomes very very unlikely that a common developer will implement security without a proper guidance so this make us believe that a developer will likely introduce some time unique at this point in order to demonstrate our assumption we implemented it quite naively by simply surrounding these 3 steps in a try-catch clauses and returning a unique error code in case of error so by processing a compliance implementation and we ended up with this result so this graph represents the average processing time of this APDU by the card the red curve represents the average processing time of this APDU in case of invalid padding where the blue curve represents the average processing time with valid padding but an error during the CRT parsing so with some well chosen threshold and a little bit of basic statistical test we are able to really distinguish which APDU belongs to the red distribution or the blue distribution and we are able to guess the padding validity of an arbitrary data string so this mean we are able to perform the bleche error code attack with an average 28000 queries so it's a little bit more than the state of the optimization but we needed to repeat some measurements in order to be sure of choice because the false positive of some very bad consequences in this kind of attack obviously 2 and a half hour is a little bit too much to be considered an on-the-fly attack but the attack can be splitied across multiple sessions and allow an attacker to collect the messages perform the attack over a long period of time across multiple sessions and recover session key a simple mitigation will be to switch to a better RSA padding such as OAP which is quite widely implemented on smart cards nowadays so this attack may seem a little bit useless since we already can achieve the same result in less than a second with the first attack however if we combine it with a design flow which is implementation dependent which is very inherent to the specification with a very much satisfying result indeed the same RSA key is used for basically everything it will be used for both key transport and key agreement but also to ensure confidentiality and authentication and this is a very big problem we imagine that it is done to save up on storage and overall complexity but it came at a huge security cost because the attack we describe targeting key transport and a specific decryption operation during the key transport can be propagated to the authentication to forge for instance a signature and for instance to forge a valid certificate issued by the card so with a valid certification chain going up to the certification authority so this would allow card impersonation in all future sessions if we imagine that the certification authority is shared between multiple cards for instance if all card issued by the same card manufacturer shared common certification authority this would allow impersonation on a very large scale so forging a signature is a little bit harder than simply decrypting a message since there is a previous step at the beginning of the attack but it took on average 7 hours to forge a valid certificate which can also be splitted across multiple sessions and considering the outcome of the attack it becomes much more interesting of course the mitigation would be to isolate key usage at least between confidentiality and authentication so as I said we implemented all mitigation we suggested and at the end only the key isolation part yield a very significant overhead we can deny it and it's it was expected because instead of only one instead of only one key to transmit one certificate to transmit at the beginning of the session there is two certificates to transmit from each part with two signatures to verify and it's quite heavy operation for a smart card but this operation only need to be performed the first communication since after a successful key establishment the smart card and your quantity will save the certificate and consider it as verified so the certificate will not need to be transmitted again on the following session so it's really a one time overhead to sum up we try to apply a very well known attack to the smart card world where public infrastructure is still quite unusual and with what we believe to be some quite reasonable assumption given past attack we found two practical attack low in a full session care recovery and a certificate for jury attack allowing to impersonate smart card on a large scale we suggest some quite simple mitigation which are easy to add to the specification and which come with a reasonable overhead once we are past the first the first session establishment we discussed all of this with global platform and support them during the update process of the specification they recently released an amendment to specification which is still a work in progress some issues have been fixed but other remains but it's quite a long process to patch such a huge specification with international entity involved thank you very much for your intention if you have any question feel free to contact me near the author of the paper we will be glad to answer them