A short guide to Nano S firmware 1.3 features

We just released the Nano S firmware 1.3, which contains mostly new security features for both end users and developers as well as UX improvements.

Overview

4–8 digits PIN code
change PIN option
auto-lock after delay
on device passphrase management
plausible deniability PIN
temporary passphrase
quick wipe of device
keep seed on firmware update
PIN request on unsigned applications installation
unsigned applications information
developer certificate
application attestation

Please refer to our firmware upgrade FAQ entry for instructions about how your can update your Nano S to the latest firmware.

Note that this update is optional, and that you will need to re-enter your seed after flashing (make sure you have your 24 words backup before starting the update process).

Longer 4–8 digits PIN

Your PIN can now be up to 8 digits — nothing much to explain here, and is created when you set up the device. The PIN entry UX has been updated to take into account the larger number of digits.

Note that the UI doesn’t reveal the number of digits you have set. You’ll have to select the ✓ symbol and press both buttons to validate your PIN.

Changing your PIN

You can now change your PIN code without reinitializing the device in Settings/Security/Change PIN.

Auto-lock after delay

You can set up a device security timeout (default being 10 minutes) in Settings/Security/Auto-lock. After this inactivity period, the device will prompt you to enter your PIN again to unlock it.

Plausible deniability with secure passphrase entry

The plausible deniability feature has been fully redesigned to support multiple BIP 39 identities and a secure passphrase entry on device.

To use it, you can select a passphrase in Settings/Security/Passphrase, type it securely on the device then either use it for the current session or attach it to a secondary PIN. When attached to a PIN, entering this PIN will use the common seed derived by the BIP 39 passphrase, for every PIN entry (this means that if you enter for instance your secondary PIN when unlocking the device, the passphrase will be activated).

Each PIN is using its own independent counter and the PIN comparison is done in constant time — this makes it highly unlikely for an unsuspecting sophisticated attacker to guess that a second PIN is enabled, providing that you give the first PIN to the attacker, and not possible to brute force one PIN knowing another one.

You can also enter the passphrase on a host computer, select a different BIP 39 word list for each PIN or for the temporary identity, and initially onboard the device in Recovery mode (mostly for developers) by using the ledgerblue.hostOnboard Python script.

Note: the ledgerblue.derivePassphrase script is now obsolete and only usable on previous firmware versions.

Quick wipe

You can wipe the device immediately on Settings/Device/Reset All followed by your PIN code rather than by entering 3 wrong PINs in a row.

Hassle free firmware update

Last but not least, from this firmware on you’ll be able to keep your device configuration in all cases when upgrading, even if the upgrade process is interrupted for any reason (sorry, you’ll still have to restore your device when upgrading to 1.3 though) — installation of a new firmware is secured by your PIN entry (to make sure that a physical attacker cannot force an update), and installing an unexpected firmware (not following the standard upgrade path we defined) will still wipe the user configuration for security purposes.

Developers also have some interesting new security features available :

PIN request on unsigned applications installation

Installing an unsigned application now requires a PIN entry, to avoid the installation of malicious applications if a physical attacker gets access to the device after it is unlocked.

Unsigned applications information

When an unsigned application is started, you can review its SHA-256 hash before confirming its execution, allowing you to quickly test an application but still check its origin when compiling it yourself.

Developer certificate

You can enroll a secp256k1 developer public key into the device and use it to open secure channels to the device ( — rootPrivateKey option of the administration scripts) or sign applications, which will then install them without prompting for the user PIN and not display the “Genuine Application” warning.

For more details about this feature, you can check the following Python scripts :

ledgerblue.genCAPair to create a secp256k1 keypair on a secure host (we’ll also provide soon a Nano S application to let you create and use a developer certificate on another Nano S if you wish to do so)
ledgerblue.signApp to sign an application with the developer certificate on a secure host
ledgerblue.setupCustomCA to enroll a new developer certificate to the device (requires a PIN entry).
ledgerblue.resetCustomCA to remove an existing developer certificate from the device (requires a PIN entry).

A device application can also verify a signature issued by the developer certificate with the new os_customca_verify system call (for example to enable secure end-to-end provisioning use cases)

Application attestation

The attestation scheme described in our previous Medium post is available for Nano S firmware 1.3