Unlike the regular hacks suffered by centralized platforms such as cryptocurrency exchanges—through which at least 282.6M USD was stolen in 2019 (cf. Chainalysis (1))—very little is known about the global magnitude of losses incurred as a result of successful attacks on other wallet owners, such as users of third-party wallets which provide ownership of the private keys.
However, with the ruckus these attacks cause on social media, one can only assume that the total amount stolen exceeds that lost as a result of attacks on centralized platforms. As we will now see, the narrative behind these attacks is usually remarkably consistent from case to case, and can be avoided using simple security measures.
This is why we felt it was important to cover some of the most common threats businesses operating a digital asset business can be exposed to when they interact with sensitive data, and discuss how a Trusted User Interface (TUI) can be used to mitigate operational risks.
When transacting with critical digital assets, businesses typically need to handle or provide sensitive data as part of the transaction creation process. This step presents the easiest attack point for hackers, since it is often a relatively simple task to display falsified information to the wallet end user or simulate user input to create an unauthorized transaction.
In the context of managing digital assets, the attacker can leverage several spoofing threat vectors, and it's paramount to have a trusted display to mitigate spoofing threats. But first, let’s take a look at the most common spoofing threats leveraged by hackers:
Typically the most trivial attack vector to exploit, spoofing the recipient address can allow an attacker to dupe a victim into sending funds to an unexpected address. The attack flow usually goes something like this:
Alice, an asset manager at a crypto trading firm, wants to transfer a large amount of Bitcoins she currently stores on behalf of a client to a crypto exchange to make a trade. She carefully verifies the BTC wallet address on the exchange before sending the Bitcoins.
On an untrusted display, the attacker (let’s call her Eve) is able to switch the address to which the funds are actually sent, despite displaying the correct address to Alice. As such, while Alice thinks he is sending funds to the exchange, the funds are actually sent to Eve, the attacker.
This kind of spoofing attack can be trivial to implement on a desktop computer or mobile wallet app and there is no reliable way to protect against this kind of attack without the use of a trusted display. Instead, the usual way to detect and prevent such an attack is with a penny test—sending a small amount to the receiving address before making a larger transaction.
However, this would only prevent a systematic address swap attack, since a clever attacker could decide to only swap the address in the second transaction.
The principle behind this attack resembles the previous one—except the target is Alice, the asset manager, this time.
In this case, Alice wants to receive funds from Bob, her client, and sends him a bitcoin wallet address controlled by her crypto trading firm. Sharing the wallet address securely poses a challenge in and of itself, since it can often be intercepted and changed throughout this process.
Likewise, in a context where an attacker controls Alice’s wallet, malware could be used to swap Alice’s actual receiving address to one owned by the attacker, which Alice would then send to Bob thinking it was the trading firm’s own address—since it was seemingly generated by his own wallet.
This attack vector can be mitigated by always using the same address, but this can raise privacy concerns since anybody can monitor the address on the public ledger, while some blockchains simply do not support address reuse.
Digital asset custody solutions that lack a trusted display are generally prime targets for attackers, since they can often be manipulated to trick the user in a variety of ways.
Among these, it can be possible to spoof the authorization of transactions, change the addresses associated with wallet contacts, and even bypass additional security measures.
Although approval requests can be spoofed by a variety of malware types, this most commonly occurs after downloading malware-laden wallet apps or through the unwitting installation of a remote administration tool (RAT).
Other attacks seek to leverage user inputs to trick organizations into revealing potentially sensitive information or authorizing actions that they are not aware of. Clickjacking is one of the most common methods used to accomplish this.
The principle behind clickjacking is simple. The attacker modifies or authors a user interface (UI) that a target interacts with and uses this to trick the target into clicking or interacting with something either disguised as something else or invisible to the user (an overlay).
This can cause users to unknowingly give consent to actions, download malware, or even provide their password or other sensitive credentials to the attacker.
These threat vectors are considered low hanging fruits for attackers since they are simple to implement and can scale easily. On the other hand, mitigating these attacks is no easy task.
The need for a Trusted User Interface
Our team developed a unique hardware-based trusted user interface that enables digital asset businesses to be absolutely certain that their critical operations have not been tampered with prior to authorization.
A trusted user interface (UI) provides a path between the user and the application that is unambiguously free from any form of manipulation. In practice, TUI enables customers to:
In order to ensure a user interface is truly trusted, one must rely on something known as a secure execution environment.
This secure execution environment provides two fundamental security features: confidentiality and integrity of the code flow.
Confidentiality is essential when interacting with critical digital assets, since it allows the system to protect the cryptographic secrets, while integrity ensures that the code running on the device is the one intended by the developer.
In this article, we have emphasised the importance of a trusted display and discussed how it relies on a secure execution environment to provide the security guarantees necessary to safely manage cryptographic keys.
In a future post, I will discuss secure execution environments in more depth and address some of the pitfalls seen in alternative implementations. Stay tuned!