Cryptnox Docs

Derive Key

Introduction

The Derive Key administration command allows you to generate new cryptographic keys from existing seeds or key pairs. This methodology has the following key features:

  • Seed-Based Key Derivation: The command allows you to derive the keys from existing seeds, ensuring that the original seed remains secure.
  • Support for Multiple Cryptographic Purposes: Derived keys can be used for various applications, including digital signatures and data encryption.
  • Enhanced Security: By generating keys from existing seeds, the risk of exposing sensitive information is minimized, as the original seeds are not directly used in cryptographic operations.

Derivation And Keys System

The following points describe some important things about the derivation and keys system in the Derive Key command:

  1. The card applet fully supports BIP32 with the 256k1 curve and SLIP10 with the NIST 256r1 curve. However, the maximum depth for key derivation from the master key is limited to 8 levels. A command to extract the extended keys is currently being developed.

  2. The card keeps the current key pair (and its parent) used for signing. You can change this key pair using the Derive command by specifying either a relative path (from the current or parent key pair) or an absolute path (from the master key). Starting the derivation from the parent keys makes it easier and faster to switch between different keys that are related.

  3. The card only keeps the immediate parent key cached, which means it can’t go back up the key hierarchy. To make things easier, you can derive keys from the root master node key (the starting point) each time the card is started, or even before signing a transaction. However, this process takes time. For efficiency, it is recommended to store hashes of the intermediate public keys and track which key is currently in use.

    If no valid parent key is available, the command will respond with a 0x6B00 status code. For example, when the current key pair is the master root.

    📘

    Note

    This complex key management off the card isn't necessary if the card is signing fewer than 1,000 transactions per day.

  4. The card supports two different elliptic curve types for key generation: 256k1 (used for "crypto") and 256r1 (used for "NIST"). A flag in the DERIVE, EXPORT, or SIGN commands allows you to select which curve to use.

  5. There are two separate key trees in the card: one for 256r1 and one for 256k1. These trees are linked together but separate, both stemming from the same initial seed. For more details, refer to the DERIVE and SIGN commands.

Command Specifications

Derive Key Command

The Derive Key command enables you to generate the new cryptographic keys from existing seeds or key pairs. This functionality is essential for creating keys tailored to specific cryptographic operations. This includes things like signing or encryption, without exposing the original master keys. By deriving keys in this manner, you can maintain a high level of security and flexibility in their cryptographic processes.

The following code snippet outlines the Python object for this command:

def derive_key(key_type: KeyType, path: str = "m/44'/0'/0'/0/0"):
    card.derive(key_type, path)

For example, derive_key(KeyType.BIP32, "m/44'/0'/0'/0/0").

📘

Notes

  • This command is used before a signing session to generate a private key according to the BIP32 and SLIP10 specifications. The generated key is used for all subsequent SIGN sessions.

    The BIP32 specifications define a few checks which must be performed on the derived keys. If these fail, mostly using r1 curve, there is a looping mechanism described by the SLIP10 proposal, enforced by the card. In such cases, you can perform a Get Status command to get the current key path and resume derivation using a different path.

  • The ability to start derivation from the parent keys allows you to efficiently switch between children of the same key.

Application Protocol Data Unit (APDU) Components

The following table outlines the components of the Application Protocol Data Unit (APDU).

📘

Prerequisites:

  • The secure channel must be open.
  • PIN or challenge-response must be validated.
  • Extended keyset (seed) must be loaded .

Field

Description

Value

CLA

This field specifies the class of the instruction.

0x80

INS

This field specifies the particular command or operation that the smart card or secure element should execute.

0xD1

P1

First parameter of the instruction that specifies the details about the operation being requested.

Derivation options.

See the table below for more information.

P2

First parameter of the instruction that specifies additional details about the operation being requested.

0x00

Data

Key data

A sequence of 32-bit integers (most significant byte first).

Keep this empty if you are using the master key.

The following table outlines the values for the P1 field within the ADPU components based on some conditions:

P1 Bit

Value

0

LSB 0x01

0-3

Reserved bits

4

0 use 256k1 EC1 use 256r1 EC

5

Reserved bit

6 and 7

  • 00: Derive from master keys.
  • 01: Derive from parent keys.
  • 10: Derive from current keys.
  • 11: Reserved

7

MSB 0x80

Response

The following table outlines the possible responses that you will receive:

Response CodeDescription
0x9000Success
0x6A80Invalid format.
0x6B00Derivation from parent keys is selected but no valid parent key is cached. For example, the master root is the current key pair set.
0x6985There is no seed loaded on the card or the PIN is not verified.