🐛 [BUG] - Key Activation Succeeds on Non-Provisioned Keys

Description

Bug Report: Key Activation Succeeds on Non-Provisioned Keys

Summary

Field	Value
Product	NASA CryptoLib (SDLS Protocol Implementation)
Version	1.4.2
Component	src/core/crypto_key_mgmt.c — Crypto_Key_update
Issue	Key activation command succeeds for keys that were never provisioned
Impact	Incorrect key state; potential use of zero-value key material

---

Description

The Crypto_Key_update function (used by Crypto_Key_Activate) allows activating any key ID in the range [0, NUM_KEYS) regardless of whether that key was ever actually provisioned via OTAR or any other key transport mechanism.

This occurs because:

1. The key ring is initialized with all keys having key_state = 0, which corresponds to KEY_PREACTIVE (crypto_config.h:88).
2. The get_key function (src/key/internal/key_interface_internal.template.c:42) returns a valid pointer for any key_id < NUM_KEYS (currently 256), without checking whether the key was actually loaded.
3. The state transition check in Crypto_Key_update (crypto_key_mgmt.c:350) only verifies ekp->key_state == (state - 1), so transitioning from KEY_PREACTIVE (0) to KEY_ACTIVE (1) always succeeds.

The result is that a non-provisioned key with all-zero key material (32 bytes of 0x00) is marked as KEY_ACTIVE and can subsequently be used for cryptographic operations.

Affected Code

src/core/crypto_key_mgmt.c, lines 322–372 (Crypto_Key_update):

// Update Key State
for (x = 0; x < pdu_keys; x++)
{
    // ...
    ekp = key_if->get_key(packet.kblk[x].kid);
    if (ekp == NULL)
    {
        return CRYPTO_LIB_ERR_KEY_ID_ERROR;
    }

    if (ekp->key_state == (state - 1))
    {
        ekp->key_state = state;  // Succeeds for any unprovisioned key (state 0 -> 1)
    }
    // ...
}

There is no check for whether the key was actually provisioned (e.g., via a provisioned flag or non-zero key material check).

PoC

A single TC frame containing an EP Key Activation command for key ID 130 (0x0082), which is not provisioned in the default key ring configuration:

002c100e0000000002001000828a33

Expected behavior: Return an error code indicating the key does not exist or has not been provisioned.

Actual behavior: Returns CRYPTO_LIB_SUCCESS (0). Key ID 130 transitions to KEY_ACTIVE state with all-zero key material.

Suggested Fix

Add a mechanism to distinguish provisioned keys from uninitialized key ring slots. For example:

• Add a provisioned boolean field to crypto_key_t and check it before allowing state transitions.
• Alternatively, verify that key_len > 0 before allowing activation.

---

Discovered using the StratoFuzz protocol fuzzing framework.

Branch Name

No response

Reproduction steps

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Screenshots

![DESCRIPTION](LINK.png)

Logs

OS

Linux

Start with src/core/crypto_key_mgmt.c around Crypto_Key_update and trace get_key in src/key/internal/key_interface_internal.template.c. Check crypto_config.h:88 and reproduce the key ID 130 activation with the supplied TC frame. Done means activation of an unprovisioned key returns an error and does not mark zero-value key material active.