Security specificities

When building a device app, certain implementation patterns can introduce security vulnerabilities. This page describes the most common insecure patterns encountered across cryptocurrency integrations and explains how to mitigate them. Understanding these risks will help you write safer APDU handlers and protect your users’ funds.

This page complements the security requirements and the cryptography guidelines.

Security concerns

This section describes possibly insecure patterns found in specific cryptocurrencies, and how to handle them.

Be wary of untrusted input

Some cryptocurrencies do not have explicit fees encoded in the transaction. In such cases, the app cannot rely on the fee value sent from the host. Instead, it should receive previous UTxOs and check their output amounts. Note that this usually needs to be done in a separate step due to memory constraints. Check the BTC app design for this.

Properly protect data you cache on the host computer

Sometimes your app needs to compute over more data than it can fit inside memory. Taking an example from the previous section, it might not be easy to store all UTxOs in the device memory. As such, you might break computation into multiple steps and, for example, verify each UTxO separately and let the host computer cache a “certified summary”. If you do this, be aware that:

If the information you want the host to cache is public, you still need to attach a signature to it so that the host cannot send some other value later. This could be done with a standard HMAC digest. We recommend using a temporary (per session) key for this — a per-session HMAC allows you to truncate the digest size (for example, you do not need an HMAC that withstands years of brute-force attack; instead, you can balance the digest size against some reasonable upper bound on how long the session lives, such as one month).
If the information is not public, you need to both encrypt it and provide a signature. Notably, it is not enough to “scramble” the data by XORing with a random key, as this would still allow an attacker to tamper with the values (or even break the scrambling if you reuse the same key).

Instead:
- Encrypt the information with a sufficiently strong cipher.
- Provide a digest to prevent tampering with the value.

Do not allow the host to freely manipulate key pairs

Some cryptocurrencies (notably Monero) need to perform extensive calculations with (public, private) key pairs spread over multiple APDU exchanges. If you need to do the same, do not allow the attacker to step out of the protocol. Allowing the attacker to freely perform key manipulation (such as group multiplications or exponentiations) could undermine your app security even if the private key never leaves the device. In general, keep an explicit protocol state machine during the computation. Also, consult with cryptography experts to check for implications if you deviate from the protocol.

Summary

The main security principles for Ledger device apps are:

Never trust fee or amount values sent from the host; verify them from raw transaction data whenever possible.
If your app caches sensitive data on the host computer, always sign it and, if the data is private, encrypt it. XOR scrambling is not sufficient.
Maintain explicit protocol state machines for multi-step APDU exchanges to prevent attackers from injecting unexpected operations.