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

[VissaMoutafis]

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