🐛 [BUG] - SA Create Does Not Set/Update Local IV Length (`iv_len`)

Description

Description

In the SA Create handler inside
src/sa/internal/sa_interface_inmemory.template.c, the code that parses the incoming
SA-Create PDU uses temp_sa->shivf_len (the Security Header IV Field length, i.e. the
transmitted portion of the IV) both to store the parsed byte and to drive the IV-copy
loop:

// BUGGY (v1.4.2, ~line 1466)
temp_sa->shivf_len = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
for (x = 0; x < temp_sa->shivf_len; x++)
{
    temp_sa->iv[x] = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
}

However, the full IV length used by the cryptographic backend for nonce validation
and replay-window checks is stored in temp_sa->iv_len — a separate field. Because
iv_len is never written during SA Create, it remains at its default value of 0 as
confirmed by the output log:

iv_len = 0   ← never updated despite shivf_len = 12

Any code that subsequently reads sa->iv_len will
treat the IV as zero-length. This makes related sanity checks to fail during ProcessSecurity calls that refer to the specific SA.

Status on dev/main (as of 2026-03-31): The fix (temp_sa->iv_len = ... / loop on
iv_len) does not appear in the current dev branch. This issue should be considered
unpatched in the current dev branch.

---

Branch / Affected Version

• Affected: v1.4.2 (src/sa/internal/sa_interface_inmemory.template.c, ~line 1466)
• Latest tested dev commit: dev branch as of 2026-03-31

---

Reproduction Steps

Packet 1 – Key OTAR

002c104c000000000102000000000000000000000000000000719405af7fcd82f5c1073e5c81455b28e37b2e8b4cada60ec40bd3eea8585e2fb2e22726654fed87b83a4a912feffdf35b9c1422

Packet 2 – Key Activate

002c100e0000000002001000828a33

Packet 3 – SA Create (SPI 20, AES-GCM, shivf_len=12, stmacf_len=16)

002c1046000000001101d00014cc001001010c00000000000000000000000001010020000000000000000000000000000000000000000000000000000000000000000000002384

1. Send Packets 1–3.
2. After Packet 3, inspect the SA dump printed to the log.
3. Observe, in the debug logs, that shivf_len = 12 is set correctly, but iv_len = 0 — it was never
   populated by the SA Create code.

---

Expected Behaviour

temp_sa->iv_len should be set to the same value read from the PDU (12 in this case), so
that anti-replay and nonce-handling logic operates correctly on the full IV length.

Actual Behaviour

The SA dump after creation shows:

shivf_len  = 12   ← correctly set
iv_len     = 0    ← never updated; anti-replay is effectively disabled

---

Logs

SA Create
spi = 20
SA status:
     spi        = 20
     sa_state   = 0x1
     est        = 0x1
     ast        = 0x1
     shivf_len  = 12
     ...
     iv_len     = 0      ← BUG: should be 12
     iv         =
     ...
Status code: 0

---

Proposed Fix

In src/sa/internal/sa_interface_inmemory.template.c, replace the IV-parsing block
(~line 1466 in v1.4.2):

*** 1466,1473 ****
  {
      temp_sa->ecs = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
  }
! temp_sa->shivf_len = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
! for (x = 0; x < temp_sa->shivf_len; x++)
  {
      temp_sa->iv[x] = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
  }
--- 1478,1485 ----
  {
      temp_sa->ecs = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
  }
! temp_sa->iv_len = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
! for (x = 0; x < temp_sa->iv_len; x++)
  {
      temp_sa->iv[x] = ((uint8_t)sdls_frame.tlv_pdu.data[count++]);
  }

Note: This also corrects the loop variable from shivf_len to iv_len, ensuring the
IV bytes are copied according to the full IV length rather than only the transmitted
portion. shivf_len should be set separately if needed.

---

References

• CCSDS 355.0-B-2 – Space Data Link Security Protocol, §4.1.3 (IV / anti-replay
  requirements)
• CCSDS 355.2-B-1 – SDLS Extended Procedures, §3.3.1 (SA Create PDU format)

---

Environment

• OS: Linux (Ubuntu 22.04 / tested in Docker)
• CryptoLib version: v1.4.2
• Crypto backend: LibGcrypt 1.4.1 (internal SA/Key)
• Build flags: TC_PROCESS_SDLS_PDUS_TRUE, CRYPTO_EPROC=1

Branch Name

v.1.4.2 and dev

Reproduction steps

**Packet 1 – Key OTAR**

002c104c000000000102000000000000000000000000000000719405af7fcd82f5c1073e5c81455b28e37b2e8b4cada60ec40bd3eea8585e2fb2e22726654fed87b83a4a912feffdf35b9c1422

**Packet 2 – Key Activate**

002c100e0000000002001000828a33

**Packet 3 – SA Create (SPI 20, AES-GCM, shivf_len=12, stmacf_len=16)**

002c1046000000001101d00014cc001001010c00000000000000000000000001010020000000000000000000000000000000000000000000000000000000000000000000002384

 
1. Send Packets 1–3.
2. After Packet 3, inspect the SA dump printed to the log.
3. Observe, in the debug logs, that `shivf_len = 12` is set correctly, but `iv_len = 0` — it was never
   populated by the SA Create code.

Screenshots

Logs

OS

Linux

Start in src/sa/internal/sa_interface_inmemory.template.c at the SA Create IV-parsing block around line 1466, then inspect the SA fields used by subsequent ProcessSecurity checks. Reproduce with the three packets from the issue and inspect the SA dump. Done means the created SA reports iv_len as 12 and its IV bytes are handled according to that length, with the relevant checks passing.