App permissions

Every application has a set of permissions. These range from system permissions, such as modifying the system configuration or requesting user PIN verification, to signer functions, such as deriving keys that only a specific app can access.

The following sections describe how Ledger grants these permissions. Follow the principle of least privilege: each application must use only the permissions necessary for its operation.

Application flags

An application’s privileges or permissions are defined in its Makefile.

The 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 user PIN verification or query the number of attempts remaining before the signer erases its memory.
• HAVE_APPLICATION_FLAG_LIBRARY: The application can act as a library and export functions that other applications can access.

A common use of HAVE_APPLICATION_FLAG_BOLOS_SETTINGS is to enable the BLE channel on Ledger Nano X, Ledger Flex, and Ledger 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 generally not used.

You must justify the use of any flag other than HAVE_APPLICATION_FLAG_BOLOS_SETTINGS in the Makefile. Otherwise, Ledger will not sign the application.

Restrict apps to coin-specific BIP32 prefixes

Ledger signers are hierarchical deterministic wallets. They can derive as many keys as necessary from a single seed, as defined in BIP-0032 . The seed generates the master node of a tree of subkeys. Although these trees can have different structures, they should follow established standards. The first level in the subkey hierarchy should always correspond to a ‘purpose’, as described in BIP-0043 .

All coins must follow the logic defined in BIP-0044 . If a coin is registered in SLIP-0044 , its application must derive keys only in the registered subtree. If the coin is not registered, choose a subtree, or ‘path’, that does not conflict with a subtree used by another application.

Set the PATH_APP_LOAD_PARAMS property in the app Makefile to restrict the derivation path.

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

PATH_APP_LOAD_PARAMS += "44'/60'"

Use the wildcard symbol * to derive all purposes for a specific coin type:

PATH_APP_LOAD_PARAMS += "*/0'"

Use the CURVE_APP_LOAD_PARAMS property to restrict derivation to a specific curve. Supported curves are secp256k1, secp256r1, ed25519, and bls12381g1.

You can configure several curves and paths at the same time. For example, if your app must derive keys on paths 44’/535348’, 13’, and 17’ with the Ed25519 and prime256r1 curves, add the following to the Makefile:

CURVE_APP_LOAD_PARAMS += ed25519 prime256r1

Rationale

Application-specific BIP32 prefixes provide defense in depth. A unique, hardened derivation prefix gives each application a separate cryptographic namespace, even when applications share the same master seed. If an attacker exploits a vulnerable or backdoored application, they cannot use it to extract private keys from other apps, such as Bitcoin or Ethereum.

For example:

• A Bitcoin application may be restricted to the hardened prefix

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

• An Ethereum application may be restricted to

m / 44' / 60' / …

These apps do not share keys and are therefore isolated from each other.

At least one component of each prefix must be hardened. Unhardened derivation steps are forbidden at the application boundary. If an application could 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 disclose the master key or higher-level keys, break isolation, and enable cross-application key extraction.

With hardened prefixes, even a fully compromised or malicious application can derive keys only within its assigned subtree. Moving upward in the derivation hierarchy or laterally into another application’s subtree is cryptographically infeasible. Examples include the Bitcoin subtree (m / * / 0’) and Ethereum subtree (m / 44’ / 60’) above.

Application-specific hardened BIP32 prefixes create a strict isolation boundary at the key-derivation layer. They limit the scope of a compromise, prevent master key leakage, and prevent a vulnerable or backdoored application from accessing other applications’ private keys.