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 hardware wallet 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.

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'"

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 prefixes is crucial, as it limits the amount of damage an attacker can cause if they manage to compromise an application. If a vulnerability is exploited on a poorly written or backdoored application, an attacker should not be able to exploit it to extract private keys from other apps, such as Bitcoin or Ethereum keys.