20 March 2018: Padding oracle attack on SCP.
A padding oracle attack was found on the Secure Channel established between the device and Ledger’s HSM. It allows an attacker to decrypt the firmware updates.
A blogpost is already written and explains the technical details of this vulnerability.
Loading and upgrading BOLOS
The load and upgrade of BOLOS is performed using a Secure Channel. It’s inspired from the Global Platform SCP-02 standard, modified by replacing T-DES with AES. This protocol guarantees authenticity and confidentiality. It’s based on an Encrypt then MAC scheme.
When BOLOS needs to be upgraded, a secure channel is established between the Secure Element of the device and Ledger’s HSM. This channel allows to send our firmware in an encrypted way. Furthermore, it also allows the HSM to attest the Ledger device to which it’s connected is genuine. Finally, the firmware authenticity is proven using a standard signature. The modified version of our SCP-02 we implemented did not embed the MAC part allowing a padding oracle attack.
Padding oracle attack
The padding oracle attack is a famous cryptographic attack discovered in 2002 by Serge Vaudenay. It allows an attacker to know whether the padding of an encrypted message is correct or not. This mechanism allows to decrypt the datastream without actually knowing the key being used. Mounting this attack can be a bit tricky, especially considering that the throughput of the leakage is very low.
In our case, the researcher demonstrated that it was possible to mount the attack but was only able to retrieve a few bytes of the datastream.
He worked a lot on understanding our protocol and how the secure channel is mounted. It consists first on an ECDH to share a common secret which is used afterwards as the key for the AES-CBC. The IV is initially 0x0. The padding check is performed by the device, if it’s not found, a status error is raised 0x6802, otherwise, the message is handled normally.
To implement it, it’s necessary to brute force all possible value of a byte paddings so that the guessed plaintext byte turns into a 0x80, mounting another Secure Channel each time in order to retrieve which one gives the correct message. The throughput is thus very low since our HSM is shared with all our users and mostly because there are a lot of different padding values to test.
The SCP implementation has been updated to add the MAC part which prevents this kind of attack. Furthermore, additional countermeasures have been implemented server side mitigating the issue until the 1.4.1 upgrade is available.
Impact on Ledger devices
There is no impact regarding the security of the device. Ledger don’t base the security of its devices on the confidentiality of the firmware. Decrypting the firmware doesn’t give attackers any information on the seed/secret data.
On the contrary, what is important from a user perspective is to be able to prove the genuineness of the device and the authenticity of the firmware. Those two security claims remain intact.
We would like to thank the security researcher Timothée Isnard who discovered the vulnerability and reported it through our bug bounty program. We also thank him for his good work, his help and his professionalism through the disclosure process.