TL;DR: Black Hat Asia invited Zengo’s research team to present research on a critical but often overlooked vulnerability in cryptography and cybersecurity: Bad Randomness. Based on our research, attackers are taking advantage of these vulnerabilities in the wild and their exploits can lead to large financial losses for victims. Below is a summary of our presentation.
Importantly, this research further highlights the value of drawing inspiration from MPC cryptographic architecture – like the solution applied by our Zengo wallet – to increase security and reduce these types of vulnerabilities.
The perfect crypto crime?
What makes a crime “perfect”? According to wikipedia : “A perfect crime is a crime that is undetected, unattributed to an identifiable perpetrator, or otherwise unsolved or unsolvable.”
Naturally, the malicious outcome needs to be major, as getting away with a misdemeanor is not impressive. Summing up: a perfect crime must be both lethal and undetected, and we showed in our talk (and share below) how Bad Randomness fits this characterization.
Randomness is vital for cryptography: The most critical part of a cryptography algorithm, its key creation, depends on its randomness. Additionally, randomness is used for many other critical auxiliary parameters such as Initialization Vectors (IV) and Nonces. As said by Prof. Dodis: “Randomness in cryptography is like the air we breathe. You can’t do anything without it”. The flip side of this coin: The lack of randomness is Lethal.
On the other hand, the problem with random numbers is that there is no such a thing. “Random number“ is a colloquialism for “a number selected at random”. This is not merely a matter of linguistic nit-picking, but a matter of great importance. Since the randomness is a property of the process and not of the number itself, there is no way to find out if a number is random. Additionally, due to the fact that many times the results of randomness are cryptographic secrets, saving them to logs can create a security vulnerability.
As a result, it is very hard or even impossible to prove that indeed attackers fiddled with randomness.
We had discussed this issue and its implications for cryptocurrency in a few previous blog posts. Below, we demonstrate how it is being actively exploited in in other fields of cryptography.
TLS Malware
Transport Layer Security (TLS) is the protocol that keeps our Internet traffic secure. According to wikipedia, “Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.”
In 2019, Kaspersky analyzed the Reductor malware that induced bad randomness into its victims’ TLS code in order to mark these targets TLS traffic, so it can be later decrypted and manipulated by an active Monster-in-the-Middle (MITM) actor.
According to Kaspersky, the attackers’ malware fiddled with TLS Client Random field (sent in plain) to make it deterministic, to allow the attackers to distinguish the victim TLS traffic in real-time.
Then, using the attackers’ assumed active Monster-in-the-Middle (MITM) capabilities, they can respond to the traffic and pretend to be the original server (say, Google) by using a fake certificate and using the malware to inject an appropriate fake certificate (or any certificate within its certification path, such as a rogue CA certificate) on the client side.
In our talk, we showed that the attackers were capable of passively eavesdropping. The bad randomness induced by attackers (into the DH parameters see below), does not only mark them, but also make their encrypted network traffic readable to an eavesdropper.
To illustrate this issue we created a vulnerable client (shared as open source https://github.com/ZenGo-X/Bad_randomness_tls_client_handshake_pure_python ) and exploit code that can recreate the session master key (shared as open source https://github.com/ZenGo-X/TLS-masterkey-recovery) that can decrypt that traffic.
We also shared a demo video to show a full exploitation allowing an eavesdropper to passively decrypt such traffic:
Technical Review: A deeper dive into deterministic DH parameters attack
Note: This section is technical; readers who are interested in a more high-level description should skip to the below section.
Earlier versions of the SSL/TLS protocol supported encryption of traffic using session keys that were directly derived from the Server’s long term private key. Consequently, if such a long-term key is exposed, then all past traffic can be decrypted.
To prevent that, modern versions of the TLS protocol support the Perfect Forward Secrecy (PFS) trait in which session keys are not a function of the Server’s long-term private key.
According to Wikipedia, Forward Secrecy is defined as : ”In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.”
Simply put, using PFS in TLS, disables attackers from passively reading the encrypted traffic, even if they obtained the server private key / certificate.
In TLS, this is realized by performing a Diffie-Hellman (DH) exchange within the TLS handshake to create such “Ephemeral” session keys, hence DHE for “Diffie-Hellman Ephemeral”. In case this is done by using Elliptic Curve (EC) cryptography, this protocol is called ECDHE.
Using DHE, the intermediate premaster secret and the resulting session key are created as a function of “Ephemeral” parameters only, mainly the DH parameters created on the server and client.
Since premaster secret is a function (amongst others) of at least one of the private ephemeral DH parameters (Client or Server) that never leave the memory of the device they were created on, passive eavesdropper attackers that do not have access to the memory only to the traffic are unable to passively decrypt the traffic, even if they have access to the (non-ephemeral) private key of the Server.
However, if one of these DH secrets is leaked, it allows the attacker to fully decrypt the relevant session’s traffic, even without access to the Server’s long term private key.
This is exactly what the Reductor attackers achieved. By observing the marked traffic by their malware they gain knowledge of the malware chosen DH parameter value too and can passively decrypt the traffic.
As a side note, this case demonstrates the fact that security is not a unidimensional value. As shown above, in some scenarios TLS with DHE is “worse” than the classic TLS, although DHE is considered “better” because it supports “Forward Secrecy”.
A better approach: MPC = better randomness
In order to solve the issue of bad randomness, we suggest a more robust distributed security architecture. In cryptography, this technology is called Multi-Party Computation (MPC).
Zengo was launched on the premise of creating a secure non-custodial crypto wallet that has no single-point-of-failure (SPOF). By leveraging Multi-Party Computation (MPC) cryptography, Zengo launched the first consumer MPC crypto wallet in 2019. To date, this distributed system has secured over 1 million Zengo wallets, with zero instances of hacks, wallets drained, or accounts taken over.
Using a 2-of-2 Multi-Party Computation (MPC) framework, each of the two Zengo parties (Zengo Server and Zengo app on the user device) independently generate their own “Secret Share” during the wallet creation process. The share randomly generated on the user’s device is called the Personal Share, is tied to the user’s device hardware, and leverages the device’s hardware based random generator (TRNG) where applicable. The share randomly generated on Zengo’s remote server is called the Remote Share. Only the Personal share can initialize and sign transactions, all of which are verified by the device’s hardware (Secure Enclave or Trusted Execution Environment). Learn more here.
Using MPC, these two “Secret Shares” are able to compute their corresponding public key and make sure the process was done in a secure manner.
To sign transactions and effectively spend the cryptoassets, the parties engage in a multi-staged protocol to mutually sign the transaction without revealing their shares to one another.
This elegant architecture solves many SPOF vulnerabilities associated with traditional crypto wallets, such as:
- The SPOF of the private key is solved by ensuring that private key generation is shared by two parties in two locations using two different methods
- The SPOF of the private key for daily transactions is solved by requiring the two secret shares to compute together, each of which are protected and secured in different and orthogonal ways
- The SPOF of seed phrase recovery is solved by Zengo’s 3-factor Secure Recovery feature
Most importantly for this topic of randomness, Zengo’s process solves the SPOF of random number generation: Since each of the secret shares is distributively generated it means that even if the random number generation of one of the parties is faulty or even abused by malware, the randomness of the other party compensates for that, such that the overall randomness of the private key is sufficient.
More technically speaking, since MPC security is proven against a fully malicious party, it is by definition protected against a somewhat malicious party that its maliciousness is limited to the random number generation phase.
It should be noted that other projects, such as Drand, are harnessing the power of distributed computing with MPC to solve the issue of randomness generation SPOF, for non cryptocurrency-related use cases.
Summing it up: Trust MORE (parties) – not less
The topic of crypto wallet private key generation (and generally all cryptographic parameters) has been largely overlooked by most users, but proves to be an issue that keeps haunting wallets and causing great losses.
Since a private key cannot be generated by the users themselves, but also cannot be proven to be random, users do not have a way to validate the randomness of their key and must trust their wallet for it.
This issue is yet another manifestation of the greater core issue of relying on a single party for a wallet. In order to solve this core issue along with the specific randomness issue, we must accept the fact that users need to trust some external entities and switch to a more robust architecture that strives to reduce the trust in each involved party by increasing the number of parties.
Adding parties reduces the required trust in each and makes the system more robust (See https://zengo.com/vires-in-numeris-why-adding-more-parties-boosts-security/)
Zengo’s unique MPC architecture allows users to avoid many Single Points of Failure (SPOFs) including this specific issue of randomness.
- Learn more and dive into our open-source MPC library on our Github: www.zengo.com/research
- Follow us @Zengo
- Reach out at [email protected] with questions.
