Qualcomm is also vulnerable, it is possible to extract private keys

full_ecdsa_1

In previous posts we made known that the chips Broadcom were vulnerable to attacks and now this time researchers from the company NCC Group disclosed details of the vulnerability (CVE-2018-11976 ) on Qualcomm chips, which allows you to determine the content of the private encryption keys located in the isolated Qualcomm QSEE (Qualcomm Secure Execution Environment) enclave based on ARZ TrustZone technology.

The problem manifests itself in most Snapdragon SoCs, on Android-based smartphones. Fixes for the problem are already included in the April Android update and new firmware versions for Qualcomm chips.

Qualcomm took more than a year to prepare a solution: Initially, information about the vulnerability was sent to Qualcomm on March 19, 2018.

ARM TrustZone technology enables you to create protected hardware isolated environments that are completely separate from the main system and run on a separate virtual processor using a separate specialized operating system.

The main purpose of TrustZone is to provide isolated execution of encryption key handlers, biometric authentication, billing data and other confidential information.

Interaction with the main operating system takes place indirectly through the dispatch interface.

Private encryption keys are placed within a hardware-isolated keystore which, if implemented correctly, prevents them from being leaked if the underlying system is compromised.

About the problem

The vulnerability is associated with a failure in the implementation of the algorithm to process elliptic curves, which led to a leak of information about the data processing.

Researchers have developed a third-party attack technique that allows, based on indirect leakage, rretrieve the content of the private keyss located in a hardware-isolated Android Keystore.

Leakages are determined based on an analysis of the activity of the prediction block transitions and changes in access time to data in memory.

During the experiment, Researchers successfully demonstrated the recovery of 224- and 256-bit ECDSA keys from an isolated keystore on hardware used in the Nexus 5X smartphone.

To restore the key, it took around 12 digital signatures to generate, which took more than 14 hours to complete. The Cachegrab toolkit was used to carry out the attack.

The main cause of the problem is the sharing of common hardware components and cache for computing in TrustZone and in the host system: isolation is done at the level of logical separation, but by using common computing blocks and setting calculation traces and information about jump addresses in the processor common cache.

Using the Prime + Probe method, based on an estimate of the change in the access time to the cached information, you can check the availability of certain patterns in the cache with a sufficiently high precision of the data streams and execution signs of code related to digital signature calculations in TrustZone.

Most of the time of generating digital signatures with ECDSA keys on Qualcomm chips is spent performing multiplication operations in a cycle using the unchanged initialization vector (nonce) for each signature.

Si an attacker can recover at least a few bits with information about this vector, it is possible to launch an attack on the sequential recovery of the entire private key.

In the case of Qualcomm, two points of leakage of this information were revealed in the multiplication algorithm: when performing table search operations and in the conditional data extraction code based on the value of the last bit in the "nonce" vector .

Although the Qualcomm code contains measures to counteract the leakage of information in third-party channels, the attack method developed allows you to bypass these measures and define some bits of the "nonce" value, which is sufficient to recover 256 ECDSA keys bits.


The content of the article adheres to our principles of editorial ethics. To report an error click here!.

A comment, leave yours

Leave a Comment

Your email address will not be published.

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   GeekCube said

    April 28 and I'm still waiting for the patches, that in GNU / Linux does not happen