Derive Key
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 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.
- 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.
- 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.
- 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.
- 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”).
📘 Note
- 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).
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 | Second 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 |
|
7 | MSB 0x80 |
📘 Prerequisites
- The secure channel must be open.
- PIN or challenge-response must be validated.
- Extended keyset (seed) must be loaded .
Response
The following table outlines the possible responses that you will receive:
Response Code | Description |
0x9000 | Success |
0x6A80 | Invalid format |
0x6B00 | Derivation from parent keys is selected but no valid parent key is cached. For example, the master root is the current key pair set. |
0x6985 | There is no seed loaded on the card or the PIN is not verified. |