Downgrade attack

Abstract: Bluetooth (BR/EDR) and Bluetooth Low Energy (BLE) are pervasive wireless technologies specified in the Bluetooth standard. The standard includes key negotiation protocols used to generate long-term keys (during pairing) and session keys (during secure connection establishment). In this work, we demonstrate that the key negotiation protocols of Bluetooth and BLE are vulnerable to standard-compliant entropy downgrade attacks. In particular, we show how an attacker can downgrade the entropy of any Bluetooth session key to 1 byte, and of any BLE long-term key and session key to 7 bytes. Such low entropy values enable the attacker to brute-force Bluetooth long-term keys and BLE long-term and session keys, and to break all the security guarantees promised by Bluetooth and BLE. As a result of our attacks, an attacker can decrypt all the ciphertext and inject valid ciphertext in any Bluetooth and BLE network. Our key negotiation downgrade attacks are conducted remotely, do not require access to the victims’ devices, and are stealthy to the victims. As the attacks are standard-compliant, they are effective regardless of the usage of the strongest Bluetooth and BLE security modes (including Secure Connections), the Bluetooth version, and the implementation details of the devices used by the victims. We successfully attack 38 Bluetooth devices (32 unique Bluetooth chips) and 19 BLE devices from different vendors, using all the major versions of the Bluetooth standard. Finally, we present effective legacy compliant and non-legacy compliant countermeasures to mitigate our key negotiation downgrade attacks.

Abstract: Security-critical tasks require proper isolation from untrusted software. Chip manufacturers design and include trusted execution environments (TEEs) in their processors to secure these tasks. The integrity and security of the software in the trusted environment depend on the verification process of the system. We find a form of attack that can be performed on the current implementations of the widely deployed ARM TrustZone technology. The attack exploits the fact that the trustlet (TA) or TrustZone OS loading verification procedure may use the same verification key and may lack proper rollback prevention across versions. If an exploit works on an out-of-date version, but the vulnerability is patched on the latest version, an attacker can still use the same exploit to compromise the latest system by downgrading the software to an older and exploitable version. We did experiments on popular devices on the market including those from Google, Samsung and Huawei, and found that all of them have the risk of being attacked. Also, we show a real-world example to exploit Qualcomm's QSEE. In addition, in order to find out which device images share the same verification key, pattern matching schemes for different vendors are analyzed and summarized.

Abstract: We survey elliptic curve implementations from several vantage points We perform internet-wide scans for TLS on a large number of ports, as well as SSH and IPsec to measure elliptic curve support and implementation behaviors, and collect passive measurements of client curve support for TLS We also perform active measurements to estimate server vulnerability to known attacks against elliptic curve implementations, including support for weak curves, invalid curve attacks, and curve twist attacks We estimate that 153% of HTTPS hosts, 004% of SSH hosts, and 404% of IKEv2 hosts that support elliptic curves do not perform curve validity checks as specified in elliptic curve standards We describe how such vulnerabilities could be used to construct an elliptic curve parameter downgrade attack called CurveSwap for TLS, and observe that there do not appear to be combinations of weak behaviors we examined enabling a feasible CurveSwap attack in the wild We also analyze source code for elliptic curve implementations, and find that a number of libraries fail to perform point validation for JSON Web Encryption, and find a flaw in the Java and NSS multiplication algorithms

Abstract: Transport Layer Security (TLS) protocol is often vulnerable to version downgrade attacks, where a man-in-the-middle attacker interferes with the handshake protocol and leads the communicating parties to fall back from a higher version of TLS to lower ones, which are typically provided for backward compatibility. In order to thwart the downgrade attack, several defense mechanisms are adopted in most of the recent TLS versions. However, there have not been many studies on analyzing what conditions are needed to guarantee the theoretical security, and understanding how they are implemented in practice in the era of TLS 1.3. To understand the current deployment of downgrade protection mechanisms and their security in the real world, in this paper, we investigated ten major web browsers in five operating systems with diverse implementation conditions of TLS clients and servers. As a result, we identified that two network stacks of Microsoft and Apple are vulnerable to downgrade attacks. We then demonstrate TLS sessions can be downgraded from TLS 1.3 to 1.0 by exploiting the vulnerability. Drawing on our experiment, we analyze the root cause for the vulnerability, and present several mitigation strategies.