App Permissions

Every application has an associated set of permissions, ranging from system-related permissions such as the ability to modify system configuration or being able to request user PIN verification, to signer functionalities like the ability to derive specific keys only accesible to one particular app.

The following sections details how those permissions are granted. It is crucial to uphold the principle of least priviledge: each application must use permissions only absolutely necessary to its execution.

Application flags

Priviledges or permissions of an application are defined within its Makefile.

Most notable flags are:

HAVE_APPLICATION_FLAG_BOLOS_SETTINGS : the application can read and modify system parameters such as the device’s name.
HAVE_APPLICATION_FLAG_GLOBAL_PIN : the application can request a user PIN verification or query the number of tries left before the device erases its own memory.
HAVE_APPLICATION_FLAG_LIBRARY : the application behaves (or rather can also behave) as a library and exports functions that can be reached from other applications.

A common use of the HAVE_APPLICATION_FLAG_BOLOS_SETTINGS is for using BLE channel on Nano X, Flex and Stax:

ifeq ($(ENABLE_BLUETOOTH), 1)
ifeq ($(TARGET_NAME),$(filter $(TARGET_NAME),TARGET_NANOX TARGET_STAX TARGET_FLEX))
    HAVE_APPLICATION_FLAG_BOLOS_SETTINGS = 1
    DEFINES += HAVE_BLE BLE_COMMAND_TIMEOUT_MS=2000 HAVE_BLE_APDU
    DEFINES += BLE_SEGMENT_SIZE=32
    SDK_SOURCE_PATH += lib_blewbxx lib_blewbxx_impl
endif
endif

Other flags are in general not used at all.

Any use of a flag other than HAVE_APPLICATION_FLAG_BOLOS_SETTINGS must be justified in the Makefile otherwise Ledger will not sign the application.

Restrict Apps to Coin-Specific BIP32 Prefix

Ledger devices are Hierarchical Deterministic wallets, which means they can derive as many keys as necessary from a single seed as defined in BIP-0032. The seed is similar to the master node of a tree of subkeys. The way those trees are constructed can be arbitrary but it is recommended it follows a few standards. First, we recommended the first level in this hierarchy of subkeys be always tied to a “purpose” as described in BIP-0043.

Next, all coins must follow the logic defined in BIP-0044. If a coin is already registered in SLIP-0044 then its associated application must derive keys in the registered subtree only. If it is not already registered then a subtree or “path” must be chosen and not be in conflict with any other application that might be using this subtree already.

⚠️

Ledger will not sign apps whose BIP32 prefixes have not been properly set.

Restricting the derivation path can be done by setting the PATH_APP_LOAD_PARAMS property in the app Makefile.

For example, if your application derives keys on the hardened path 44’/60’, specify in your Makefile:

PATH_APP_LOAD_PARAMS += "44'/60'"

It is also possible to derive all purposes for a specific coin type using the wildcard symbol *:

PATH_APP_LOAD_PARAMS += "*/0'"

⚠️

The value 0x7fffffff is used to encode the wildcard symbol and is therefore forbidden.

Derivation can also be restricted to a specific curve using the CURVE_APP_LOAD_PARAMS property. Supported curves are secp256k1, secp256r1, ed25519 and bls12381g1.

Several curves and paths can be configured at the same time. For example, if your app must derive keys on paths 44’/535348’, 13’ and 17’, on curves Ed25519 and prime256r1, the Makefile should contain:

CURVE_APP_LOAD_PARAMS += ed25519 prime256r1

Rationale

Setting application-specific BIP32 prefixes is crucial for defense-in-depth. By enforcing a unique, hardened derivation prefix per application, each app operates within its own cryptographic namespace, even when sharing the same master seed. If a vulnerability is exploited on a poorly written or backdoor-ed application, an attacker won’t be able to exploit it to extract private keys from other apps, such as Bitcoin or Ethereum.

For instance:

A Bitcoin application may be restricted to the hardened prefix

m / * / 0' / …
m / 45' / ...

An Ethereum application may be restricted to

m / 44' / 60' / …

Those apps are not sharing any key. Therefore, they’re considered isolated from each other.

At least one component of each prefix is required to be hardened. Unhardened derivation steps are explicitly forbidden at the application boundary. This restriction is critical: if an application was allowed to derive or expose an unhardened child private key together with its extended public key, an attacker could recover the parent private key. In the worst case, this could lead to disclosure of the master key or higher-level keys, completely breaking isolation and enabling cross-application key extraction.

By enforcing hardened prefixes, even a fully compromised or malicious application can only derive keys within its assigned subtree. It is cryptographically infeasible to move upward in the derivation hierarchy or laterally into another application’s subtree, such as Bitcoin (m / * / 0’) and Ethereum (m / 44’ / 60’) in our example.

In effect, application-specific hardened BIP32 prefixes act as a strict isolation boundary at the key-derivation layer. They limit the blast radius of a compromise, prevent master key leakage, and ensure that a single vulnerable or backdoor-ed application cannot escalate its access to other applications’ private keys.

Developing tools overview Cryptography API