SDLS Key Management Extended Procedures
Purpose and Rational for SDLS Key Management Extended Procedures
The SDLS protocol provides encryption, authentication, or authenticated encryption for data link layer
services of the TC, TM, and AOS protocols. Key Management extended procedures are necessary in
order to support the management and distribution of cryptographic material that is required for the
cryptographic operations within the SDLS protocol.
3. Service Definition
3.1 Overview
This Section provides the service definition for the SDLS key management extended procedures. The
procedures are described in an abstract, sequential step-by-step procedure. They represent an abstract
model of the logical exchange of data and control information between the key management procedure
initiator and the recipient. The definition of primitives is independent of specific implementation
approaches.
3.2 Key Management Service
The Key Management Extended Procedures for the SDLS protocol are specified as an extension of the
CCSDS Symmetric Key Management Recommended Practise [AD-KM]. Thus terminology from this
recommended practise is used within this specification. The SDLS Key Management Procedures are an
instantiation of the generic key management procedures specified in [AD-KM]. More concrete, they
replace the generic data structure specifications with concrete service data units and put the procedures
into context with the established Security Associations.
The baseline SDLS Key Management Procedures are built around a two-level key hierarchy (see below)
and an over-the-air-rekeying (OTAR) principle. Thus the OTAR related mandatory key management
procedures specified in [AD-KM] apply.
3.2.1 Service Parameters
3.2.2 Service Directives
3.2.2.1 Key DB Status Request
3.2.2.2 Key DB Self-Test
3.2.2.3 Verify Key (Key Verification)
The procedure allows the verification of a set of active ephemeral keys on the spacecraft. This gives
confirmation to the ground segment that the keys are not corrupted or modified and fully operational. It
should be noted that this procedure may not be executed for ephemeral or static keys associated with
pre-activation state since this would imply a transition to active state.
3.2.2.4 Revoke Key (Key Deactivation)
The deactivation (or revocation) procedure deactivates a set of previously uploaded ephemeral keys at
both end of the communication channel so that these keys are assigned the Deactivated State and
subsequently cannot be used for cryptographic operations anymore. However, the keys are not (yet)
destroyed.
3.2.2.5 Erase Key (Key Destruction)
3.2.2.6 Zeroize
3.2.2.7 Generate Key
3.2.2.9 Load Master Key / KEK
3.2.2.10 Unload Master Key / KEK
3.2.2.11 Key Upload (OTAR Rekeying)
3.2.2.12 Activate Key (Key Activation)
3.3 Security Associations Management Service
3.4 SDLS Monitoring & Control Service
4 Interface with SLP & SDLS Protocols
The Key Management Handler is the entity responsible for the management of the key management
procedures. It communicates with the Space Data Link Protocols in the role of a Virtual Channel Access
and the data exchanged is in the form of VCA_PDUs in case of TM and AOS and VCA_PDUs or segments
in the case of TC.
Backend
(Key DB, Key Gen.)
User Interface
KM Handling
(VCA Service)
VCA_PDU /
Segment
VCA_PDU
AOS/TC
AOS/TM
This section defines the Key Management Procedures in the form of procedural tasks to be executed
either by the Initiator or the Recipient. For each procedure this recommended standard specifies a
precondition to execute the procedure.
5 Procedures Definition
5.1 Key Management Procedures
The following Key Management Procedures shall be supported:







Key DB Status Request
Key DB Self-Test
Verify Key
Revoke Key
Erase Key
Key Upload (OTAR)
Activate Key
The following Key Management Procedures are optional:






Zeroize
Generate Key
Load Master Key/KEK
Unload Master Key/ KEK
Convert Key Red-> Black
Convert Key Black-> Red
5.1.1 Procedures Specification
The following section describes on a procedural level, the key management extended procedures.
5.1.1.1 Key DB Status Request
The DB Status Request procedure shall be an instantiation of Section 4.1.1. of [AD-KM].
5.1.1.1.1 Description
This procedure allows the initiator to request a status report concerning the key DB status on the
recipient side.
5.1.1.1.2 Pre-Conditions for the Procedure
This procedure has no pre-conditions.
5.1.1.1.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
5)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Status Report Creation; Role: Recipient
VCA_PDU Creation and transmission to Initiator; Role: Recipient
VCA_PDU reception and extraction; Role: Initiator
Figure xx – Key DB Status Request Procedure Visualization
5.1.1.1.4 Step 1: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 1 shall have the following input:

None
The step 1 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 1.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 1 processing:


The KM handler creates a Procedure 1.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler provides the Procedure 1.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.1.5 Step 2: VCA_PDU/TC Segment reception and extraction
The step 2 shall have the following input:

VCA_PDU or TC segment carrying Procedure 1.1 protocol data unit
The step 2 shall have the following output:

Key DB Status Request Information
The step 2 processing:


The KM handler receives a Procedure 1.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler parses the Procedure 1.1 data unit and extracts the Key DB Status Request
information
5.1.1.1.6 Step 3: Status Report Creation
Step 3 is an internal process on the recipient side and does not involve a communication channel.
The step 3 shall have the following input:

Key DB Status Request Information
The step 3 shall have the following output:

Key DB Status Request Response
The step 3 processing:
1. The KM handler shall request the key DB status information from the Key DB
2. The KM handler shall create a Key DB Request Response
5.1.1.1.7 Step 4: VCA_PDU Creation and transmission to Initiator
The step 4 shall have the following input:

Key DB Status Request Response
The step 4 shall have the following output:

VCA_PDU containing Procedure 1.2 data structure delivered to Initiator Space Data Link Protocol
Instance
The step 4 processing:
1. The KM handler shall encode the Key DB Status Response in a Procedure 1.2 data structure
2. The KM handler shall create a VCA_PDU containing the Procedure 1.2 data structure
3. The KM handler shall deliver the VCA_PDU to the Space Data Link Protocol via the Virtual
Channel Access Service.
5.1.1.1.8 Step 5: VCA_PDU reception and extraction
The step 5 shall have the following input:

VCA_PDU carrying Procedure 1.2 protocol data unit
The step 5 shall have the following output:

Key DB Status Request Response
The step 5 processing:
1. The KM handler receives a Procedure 1.2 protocol data unit from the Virtual Channel Access
Service in the form of a VCA_PDU.
2. The KM handler parses the Procedure 1.2 data unit and extracts the Status Request Response
information
Mmh, does the KM handler need to be able to parse the information it received to see which service is
actually used at the moment?
5.1.1.2 Key DB Self-Test
The service primitives for this service are
5.1.1.3 Verify Key
The Verify key procedure shall be an instantiation of Section 4.1.3 of [AD-KM].
5.1.1.3.1 Description
The procedure allows the verification of a set of active ephemeral keys at the recipient. This gives
confirmation to the initiator that the keys are not corrupted or modified and fully operational.
5.1.1.3.2 Pre-Conditions for the Procedure
Both entities shall have an identical set of ephemeral keys associated with active state.
5.1.1.3.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
5)
6)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Computation of Challenge Responses; Role: Recipient
VCA_PDU Creation and transmission to Initiator; Role: Recipient
VCA_PDU reception and extraction; Role: Initiator
Verification of Challenge Responses; Role: Initiator
7) Figure xx – Key DB Status Request Procedure Visualization
5.1.1.3.4 Step 1: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 1 shall have the following input:


Random Number Generator output or fixed function output (challenge seed)
Key IDs of keys to be verified
The step 1 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 3.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 1 processing:


The KM handler creates a Procedure 3.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler provides the Procedure 3.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.3.5 Step 2: VCA_PDU/TC Segment reception and extraction
The step 2 shall have the following input:

VCA_PDU or TC segment carrying Procedure 3.1 protocol data unit
The step 2 shall have the following output:

Set of Key IDs and Challenges
The step 2 processing:


The KM handler receives a Procedure 3.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler parses the Procedure 3.1 data unit and extracts the set of Key IDs and
Challenges
5.1.1.3.6 Step 3: Computation of Challenge Responses; Role: Recipient
Step 3 is an internal process on the recipient side and does not involve a communication channel.
The step 3 shall have the following input:

Set of Key IDs and a challenge (bit pattern)
The step 3 shall have the following output:

Set of Key ID and challenge response bit patterns
The step 3 processing:
1. The KM handler shall, for Key ID id_i, identify the key associated with the key ID and compute an
encrypted version of the challenge, enc_i
2. The KM handler shall create a set of (Key ID, enc_i) pairs.
5.1.1.3.7 Step 4: VCA_PDU Creation and transmission to Initiator
The step 4 shall have the following input:

Set of (Key ID, enc_i) pairs
The step 4 shall have the following output:

VCA_PDU containing Procedure 3.2 data structure delivered to Initiator Space Data Link Protocol
Instance
The step 4 processing:
1. The KM handler shall encode the set of (Key ID, enc_i) pairs in a Procedure 3.2 data structure
2. The KM handler shall create a VCA_PDU containing the Procedure 3.2 data structure
3. The KM handler shall deliver the VCA_PDU to the Space Data Link Protocol via the Virtual
Channel Access Service.
5.1.1.3.8 Step 5: VCA_PDU reception and extraction
The step 5 shall have the following input:

VCA_PDU carrying Procedure 3.2 protocol data unit
The step 5 shall have the following output:

Set of (Key ID, enc_i) pairs
The step 5 processing:
1. The KM handler receives a Procedure 3.2 protocol data unit from the Virtual Channel Access
Service in the form of a VCA_PDU.
2. The KM handler parses the Procedure 3.2 data unit and extracts the set of (Key OD, enc_i) pairs.
5.1.1.3.8 Step 6: Verification of Challenge Responses
The step 6 shall have the following input:

Set of (Key ID, enc_i) pairs.
The step 6 shall have the following output:

Set of (Key ID, ver_i) pairs.
The step 6 processing:
1. The KM handler computes a decrypted version (Key ID, dec_i) for each (Key ID, enc_i) received
from the previous step, where dec_i is the decrypted text from enc_i under the key associated
with the Key ID parameter
2. For each Key ID, the KM handler compares dec_i to the challenge bit pattern. If they match,
ver_i is set to true, otherwise its set to false
5.1.1.4 Revoke Key
The Revoke key procedure shall be an instantiation of Section 4.1.4 of [AD-KM].
5.1.1.4.1 Description
The deactivation (or revocation) procedure deactivates a set of previously uploaded ephemeral keys at
both end of the communication channel so that these keys are assigned the Deactivated State and
subsequently cannot be used for cryptographic operations anymore. However, the keys are not (yet)
destroyed.
5.1.1.4.2 Pre-Conditions for the Procedure
Both entities shall have an identical set of ephemeral keys associated with active state.
5.1.1.4.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
Deactivation of the set of ephemeral keys; Role: Initiator
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Deactivation of the set of ephemeral keys; Role: Recipient
Figure xx – Revoke Key Procedure Visualization
5.1.1.4.4 Step 1: Revocation the set of ephemeral keys
The step 1 shall have the following input:

Key IDs of keys to be revoked
The step 1 shall have the following output:

Revocation confirmation for all keys the set of Key IDs to be revoked
The step 1 processing:


For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status DECATIVATED.
A revocation confirmation shall be produced.
5.1.1.4.4 Step 2: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 2 shall have the following input:

Key IDs of keys to be revoked
The step 2 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 4.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 2 processing:

The KM handler creates a Procedure 4.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:

1. VCA_PDU
2. TC Segment without segment header
The KM handler provides the Procedure 4.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.4.5 Step 3: VCA_PDU/TC Segment reception and extraction
The step 3 shall have the following input:

VCA_PDU or TC segment carrying Procedure 4.1 protocol data unit
The step 3 shall have the following output:

Set of Key IDs associated with the keys to be revoked.
The step 3 processing:


The KM handler receives a Procedure 4.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
3. VCA_PDU
4. TC Segment without segment header
The KM handler parses the Procedure 4.1 data unit and extracts the set of Key IDs
5.1.1.4.6 Step 4: Revocation the set of ephemeral keys Role: Recipient
The step 4 shall have the following input:

Key IDs of keys to be revoked
The step 4 shall have the following output:

None
The step 4 processing:

For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status DEACTIVATED.
5.1.1.5 Erase Key
The Erase key procedure shall be an instantiation of Section 4.1.5 of [AD-KM].
5.1.1.5.1 Description
The destruction (or zeroing) procedure destroys a set of previously deactivated ephemeral keys at both
end of the communication channel so that these keys are assigned the Destroyed State and
subsequently are not available anymore.
5.1.1.5.2 Pre-Conditions for the Procedure
Both entities shall have an identical set of ephemeral keys associated with deactivated state.
5.1.1.5.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
Destruction of the set of ephemeral keys; Role: Initiator
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Destruction of the set of ephemeral keys; Role: Recipient
Figure xx – Erase Key Procedure Visualization
5.1.1.5.4 Step 1: Revocation the set of ephemeral keys
The step 1 shall have the following input:

Key IDs of keys to be destroyed
The step 1 shall have the following output:

Destruction confirmation for all keys the set of Key IDs to be revoked
The step 1 processing:


For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status DESTROYED.
A destruction confirmation shall be produced.
5.1.1.5.4 Step 2: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 2 shall have the following input:

Key IDs of keys to be destroyed
The step 2 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 5.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 2 processing:


The KM handler creates a Procedure 5.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler provides the Procedure 5.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.5.5 Step 3: VCA_PDU/TC Segment reception and extraction
The step 3 shall have the following input:

VCA_PDU or TC segment carrying Procedure 5.1 protocol data unit
The step 3 shall have the following output:

Set of Key IDs associated with the keys to be destroyed.
The step 3 processing:

The KM handler receives a Procedure 5.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
5. VCA_PDU

6. TC Segment without segment header
The KM handler parses the Procedure 5.1 data unit and extracts the set of Key IDs
5.1.1.5.6 Step 4: Revocation the set of ephemeral keys Role: Recipient
The step 4 shall have the following input:

Key IDs of keys to be destroyed
The step 4 shall have the following output:

None
The step 4 processing:

For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status DESTROYED.
5.1.1.6 Key Upload (OTAR)
The Erase key procedure shall be an instantiation of Section 4.1.6 of [AD-KM].
5.1.1.6.1 Description
Over-the-air-rekeying (OTAR) addresses the transmission of ephemeral keys over a communication
channel between two communication entities. It is assumed that the communication channel is an
untrusted/insecure link. More concrete, the attacker is able to intercept messages send on the link.
5.1.1.6.2 Pre-Conditions for the Procedure
Both entities shall share a set of static keys. At least one static key of this set shall be in pre-activation
state and selected by both entities for OTAR purposes.
The initiator of the OTAR procedures shall have available the set of ephemeral keys that is to be
transmitted during the procedure. These keys shall be in pre-activation state.
5.1.1.6.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
Encryption of the set of ephemeral keys; Role: Initiator
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Decryption of the set of ephemeral keys; Role: Recipient
Figure xx – Key Upload (OTAR) Procedure Visualization
5.1.1.6.4 Step 1: Encryption the set of ephemeral keys
The step 1 shall have the following input:


Key IDs of keys to be encrypted
Key ID of the encryption key enc_key
The step 1 shall have the following output:

Set of (Key ID, key_i_enc) pairs
The step 1 processing:


For each Key ID compute a pair (Key ID, key_i_enc) with key_i_enc = encrypt (enc_key, Key ID)
where Key ID specifies the ephemeral key to be encrypted
Transition of the status of enc_key to ACTIVE
5.1.1.6.4 Step 2: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 2 shall have the following input:


Set of (Key ID, key_i_enc) pairs to be uplinked
Key ID of enc_key
The step 2 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 6.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 2 processing:


The KM handler creates a Procedure 6.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:
1. VCA_PDU
2. TC Segment without segment header
The KM handler provides the Procedure 6.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.6.5 Step 3: VCA_PDU/TC Segment reception and extraction
The step 3 shall have the following input:

VCA_PDU or TC segment carrying Procedure 6.1 protocol data unit
The step 3 shall have the following output:

Set of (Key ID, key_i_enc) pairs
The step 3 processing:


The KM handler receives a Procedure6.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
7. VCA_PDU
8. TC Segment without segment header
The KM handler parses the Procedure 6.1 data unit and extracts the Set of (Key ID, key_i_enc)
pairs
5.1.1.6.6 Step 4: Decryption the set of ephemeral keys
The step 4 shall have the following input:


Set of (Key ID, key_i_enc)
Key ID of enc_key
The step 4 shall have the following output:

None
The step 4 processing:



For each (Key ID, key_i_enc) pair compute a pair (Key ID, key_i_plain) with key_i_plain = decrypt
(enc_key, key_i_enc)
Each key_i_plain is stored in the memory slot identified by its key ID in status PRE-ACTIVATED.
The memory slot of enc_key is transitioned to ACTIVE.
5.1.1.7 Activate Key
The Activate key procedure shall be an instantiation of Section 4.1.7 of [AD-KM].
5.1.1.7.1 Description
The activation procedure activates a set of previously uploaded ephemeral keys at both end of the
communication channel so that these keys can subsequently be used for cryptographic operations in the
context of the parent security association.
5.1.1.7.2 Pre-Conditions for the Procedure
Both entities shall have an identical set of ephemeral keys associated with pre-activation state.
5.1.1.7.3 Procedural Steps and Roles for the Procedure
This procedure shall have the following steps and associated roles.


1)
2)
3)
4)
The procedure is only completed once all steps have been carried out by their associated roles
in the order specified by the procedure.
All steps are mandatory.
Activation of the set of ephemeral keys; Role: Initiator
VCA_PDU/TC Segment Creation and transmission to Recipient ; Role: Initiator
VCA_PDU/TC Segment reception and extraction; Role: Recipient
Activation of the set of ephemeral keys; Role: Recipient
Figure xx – Key Activation Procedure Visualization
5.1.1.7.4 Step 1: Encryption the set of ephemeral keys
The step 1 shall have the following input:

Key IDs of keys to be activated
The step 1 shall have the following output:

Activation confirmation for all Key IDs
The step 1 processing:


For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status ACTIVE.
An activation confirmation shall be produced.
5.1.1.7.4 Step 2: VCA_PDU/TC Segment Creation and transmission to Recipient
The step 2 shall have the following input:


Set of (Key ID, key_i_enc) pairs to be uplinked
Key ID of enc_key
The step 2 shall have the following output:

VCA_PDU/ TC Segment containing Procedure 7.1 data structure delivered to Initiator Space Data
Link Protocol Instance
The step 2 processing:


The KM handler creates a Procedure 7.1 protocol data unit. Two data units shall be supported
depending on the Space Link Protocol in use:
3. VCA_PDU
4. TC Segment without segment header
The KM handler provides the Procedure 7.1 data unit created to the Space Data Link Protocol
interface. Two interfaces shall be supported:
1. Virtual Channel Access Service (for VCA_PDU)
2. MAP Access Service (for TC Segments)
5.1.1.7.5 Step 3: VCA_PDU/TC Segment reception and extraction
The step 3 shall have the following input:

VCA_PDU or TC segment carrying Procedure 7.1 protocol data unit
The step 3 shall have the following output:

Set of Key IDs associated with the keys to be activated.
The step 3 processing:


The KM handler receives a Procedure6.1 protocol data unit from the Virtual Channel Access
Service. Two data units shall be supported depending on the Space Link Protocol in use:
9. VCA_PDU
10. TC Segment without segment header
The KM handler parses the Procedure 6.1 data unit and extracts the Set of Key IDs
5.1.1.7.6 Step 4: Decryption the set of ephemeral keys
The step 4 shall have the following input:

Key IDs of keys to be activated
The step 4 shall have the following output:

None
The step 4 processing:

For each key identified by a key ID in the set of Key IDs provided, the associated key shall be
transitioned to status ACTIVE.
5.1.2 Procedures Specification
5.1.2.1 Key Types and Lifecycle
The SDLS key management extended procedures are based on a two-level key hierarchy, one level for
static keys (called master keys in the SDLS context) and one level for ephemeral keys (called session keys
in the SDLS context).
All recommendations from [AD-KM] Section 3.1 (Key Types) apply to the key hierarchy used for the
SDLS protocol extended procedures.
All recommendations from [AD-KM] Section 3.2 (Key Life Cycle) apply to the key hierarchy used for
the SDLS protocol extended procedures. The Suspended State shall not be used. Figure xx shows the
applicable key life cycle.
Figure xx – Key Life Cycle for SDLS Extended Procedures for Key Management
Keys are managed as bit fields. The length of the bit fields is dependent on the selected cryptographic
algorithm as specified in [AD-CRYPTO]. However, the length of all keys shall fixed a specific Security
Association. For the purpose of key management, each key is amended with meta information
describing specific properties of the key. The following meta-information is associated with each key:

Key ID: The Key ID uniquely identifies a given key. It is split into two ranges:, one for master keys
and one for session keys
The key meta-information follows, without gap, each key. All key meta-information are managed
parameters within the SA.
Master Key Roles: Each master key can be associated one of the following specific roles:
o
o
Key Encryption Key
Bypass-Mode Authentication Key
NOTE: Master Keys must not be assigned the role of Key Generation Key since key derivation is
not used by the SDLS protocol key management extended procedure.
4.1.1.1 Key Types and Lifecycle Managed Parameters
The following managed parameters must be specified by the KM SA:
o
o
Key Length: The length (in bits) of the cryptographic keys
Key ID Field Length: The length (in bits) of the key ID field
NOTE: To be clarified: if the KM SA is responsible for all other SAs then all keys and key ID fields
used in all other SAs must have the same length. Otherwise this parameters must become
unmanaged.
5.1.2.2 Key Management Procedure Protocol Data Unit (KM_PDU)
The presence or absence of the Key Management Procedure Protocol Data Unit shall remain constant
during a mission phase.
NOTE: The presence of the Key Management Procedure Protocol Data Unit specifies that a given
VC or MAP is used for Key Management Procedures.
The Key Management Procedure Protocol Data Unit consists of two mandatory data structures:
1. Key Management Procedure Header (8 bits; mandatory)
2. Key Management Procedure Data Field (variable length; mandatory)
NOTE: The structure of the Key Management Procedure Protocol Data Unit is shown in Figure xx below.
NOTE: While the primary communication interface for the key management extended procedures is the
data-link layer, an application layer interface could also be used. The data structures defined in the
following sections can be used without modification.
Figure xx – Key Management Procedure Protocol Data Unit
5.1.2.1.1 Key Management Procedure Header
The presence or absence of a Key Management Procedure Header shall remain constant during a
mission phase.
The Key Management Procedure Header is mandatory on a virtual channel if the channel is used be the
Key Management Handler.
The Key Management Procedure Header shall consist of one mandatory field:

Key Management Procedure Identification Field (8 bits; mandatory)
The Key Management Procedure Header shall consist of exactly 8 bits.
NOTE: Presence or absence of the Key Management Procedure Header on a VC or MAP for a given
mission phase is a managed parameter.
5.1.2.1.1.1 Key Management Procedure Identification Field
The Key Management Procedure identification field specifies the Key Management Procedure as
follows:
Field Value
00000001
00000010
00000100
00001000
00010000
00100000
01000000
Procedure
Key DB Status Request
Key DB Self-Test
Verify Key
Revoke Key
Erase Key
Key Upload (OTAR)
Activate Key
5.1.2.1.2 Key Management Procedure Data Field
The presence or absence of a Key Management Procedure Data Field shall remain constant during a
mission phase.
The flexibility of the length of the Key Management Procedure Data Field shall be as follows:
1. Flexible length for TC frames and Segments
2. Fixed length for TM and AOS frames
NOTE: In the case of a fixed length, idle data will be inserted into the Key Management Procedure Data
Unit following without gap the Key Management Procedure Data Field.
The content of the Key Management Procedure Data Field shall be specified by the Key Management
Procedure used.
5.1.2.3 Key DB Status
The Procedure 1: Key DB Status Request shall support two Key Management Procedure Data Field
Structures:
1. Key DB Status Request Structure (1,1)
2. Key DB Status Structure (1,2)
5.1.2.3.1 Key DB Status Request Structure (1,1)
The Key DB Status Request Structure (1,1) shall be associated with Steps 1 and 2 of the Key DB Status
Request Procedure as defined in Section 3.2.3.1.
The Key DB Status Request Structure (1,1) shall be associated with a TC Segment (without Header) or a
AOS VCA_PDU.
The Key DB Status Request Structure (1,1) shall consist of one mandatory field:
1. Key DB Status Request (2 bit (00); mandatory)
NOTE: The structure of the Key DB Status Request Structure (1,1) is shown in Figure xx below.
The Key DB Status Request field is always set to 00.
NOTE: No additional parameters are expected for the Key DB Status Request (1,1) structure.
5.1.2.3.2 Key DB Status Response Structure (1,2)
The Key DB Status Response Structure (1,2) shall be associated with Steps 4 and 5 of the Key DB Status
Request Procedure as defined in Section 3.2.3.1.
The Key DB Status Response Structure (1,2) shall be associated with a TC Segment (without Header) or a
AOS VCA_PDU.
The Key DB Status Response Structure (1,2) shall consist of two mandatory fields:
1. Key DB Status Response Status (4 bit; mandatory)
NOTE: The structure of the Key DB Status Response Structure (1,2) is shown in Figure xx below.
The Key DB Status field shall contain the following values:
Field Value
0000
1111
…
Implication
DB Status OK
DB Status Offline
…
5.1.2.4 Key DB Self-Test
The service primitives for this service are
5.1.2.5 Verify Key
The Procedure Verify Key shall support two Key Management Procedure Data Field Structures:
1. Verify Key Request Structure (3,1)
2. Verify Key Response Structure (3,2)
5.1.2.5.1 Verify Key Request Structure (1,1)
The Verify Key Request Structure (3,1) shall be associated with Steps 1 and 2 of the Verify Key Procedure
as defined in Section 3.2.3.1.
The Verify Key Request Structure (3,1) shall be associated with a TC Segment (without Header) or a AOS
VCA_PDU.
The Verify Key Request Structure (3,1) shall consist of at least two mandatory fields:
1. A challenge (managed size)
2. Field of n Key ID entries
NOTE: The structure of the Verify Key Request Structure (3,1) is shown in Figure xx below.
Figure xx: Verify Key Request Structure (3,1)
5.1.2.5.2 Verify Key Response Structure (3,2)
The Verify Key Response Structure (3,2) shall be associated with Steps 4, 5 and 6 of the Verify Key
Procedure as defined in Section 3.2.3.1.
The Verify Key Response Structure (3,2) shall be associated with a TC Segment (without Header) or a
AOS VCA_PDU.
The Key DB Status Response Structure (3,2) shall consist of two mandatory fields:
1. Verify Key Response Status (4 bit; mandatory)
NOTE: The structure of the Verify Key Response Structure (3,2) is shown in Figure xx below.
Figure xx: Verify Key Response Structure (3,2)
5.1.2.6 Revoke Key
The Procedure Revoke Key shall support one Key Management Procedure Data Field Structure:
1. Revoke Key Structure (4,1)
5.1.2.6.1 Revoke Key Structure (4,1)
The Revoke Key Structure (4,1) shall be associated with Steps 1 through 4 of the Revoke Key Procedure
as defined in Section 3.2.3.1.
The Revoke Key Structure (4,1) shall be associated with a TC Segment (without Header) or a AOS
VCA_PDU.
The Revoke Key Structure (4,1) shall consist of n mandatory fields:
1. Key ID n (managed)
NOTE: The structure of the Revoke Key Structure (4,1) is shown in Figure xx below.
Figure xx: Revoke Key Structure (4,1)
5.1.2.7 Erase Key
The Procedure Erase Key shall support one Key Management Procedure Data Field Structure:
1. Erase Key Structure (5,1)
5.1.2.7.1 Erase Key Structure (5,1)
The Erase Key Structure (5,1) shall be associated with Steps 1 through 4 of the Erase Key Procedure as
defined in Section 3.2.3.1.
The Erase Key Structure (5,1) shall be associated with a TC Segment (without Header) or a AOS
VCA_PDU.
The Erase Key Structure (5,1) shall consist of n mandatory fields:
2. Key ID n (managed)
NOTE: The structure of the Erase Key Structure (5,1) is shown in Figure xx below.
Figure xx: Erase Key Structure (5,1)
5.1.2.8 Key Upload (OTAR)
5.1.2.8.1 Key Upload (OTAR) Structure (6,1)
The Key Upload (OTAR) (6,1) shall be associated with Steps 1 through 4 of the Key Upload (OTAR)
Procedure as defined in Section 3.2.3.1.
The Key Upload (OTAR) Structure (6,1) shall be associated with a TC Segment (without Header) or a AOS
VCA_PDU.
The Key Upload (OTAR) Structure (6,1) shall consist of a set of 2 mandatory fields:
1. Ephemerial Key I (encrypted bit field, managed)
2. Ephemerial Key I Meta-Information (managed)
NOTE: The structure of the Key Upload (OTAR) Structure (6,1) is shown in Figure xx below.
Figure xx: Key Upload (OTAR) Structure (6,1)
5.1.2.9 Activate Key
5.1.2.9.1 Activate Key Structure (7,1)
The Activate Key Structure (7,1) shall be associated with Steps 1 through 4 of the Activate Key Procedure
as defined in Section 3.2.3.1.
The Activate Key Structure (7,1) shall be associated with a TC Segment (without Header) or a AOS
VCA_PDU.
The Activate Key Structure (7,1) shall consist of n mandatory fields:
1. Key ID n (managed)
NOTE: The structure of the Activate Key Structure (7,1) is shown in Figure xx below.
Figure xx: Activate Key Structure (7,1)
4.1.2 Managed Parameters
-
Key Length
Key ID field length
Presence of the Key Management Procedure Header