Space Data Link Security – Extended Procedures

“The purpose of the SDLS Extended Procedures is to provide a standardized set of auxiliary services that are necessary to operate an implementation of the SDLS protocol.” The three types of services are detailed in the following sections. In addition to these three, a Frame Security Report (FSR) is also specified. This report provides insight into the current state of the Cryptography Library and alternates in the OCF with the CLCW. All of these services build upon the core protocol.

a.Key Management Service

“The proper management of cryptographic keys is essential to the effective use of cryptography in security. Keys are analogous to the combination of a safe. If an adversary knows a safe combination, the strongest safe provides no security against penetration. Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with the keys, and the protection afforded to the keys. All keys need to be protected against unauthorized
disclosure. Key Management provides the foundation for the secure generation, storage, distribution, use and destruction of keys.” Two types of keys exist in the standard, Master and session keys. Master keys are used only for the uploading of new session keys via the over-the-air-rekeying (OTAR) procedure. Session keys are to beutilized for all other applications. Both types of keys follow the same lifecycle as shown in Figure 1. A key can be reset to the Pre-Activation state via an OTAR command from any previous state allowing for re-use of the memory space in which a key is located. Additional transition rules are detailed in the standard.

Figure 1 – Cryptographic Key Lifecyc

Figure 1 – Cryptographic Key Lifecycle

Additional states such as suspended and compromised are optional and not included in Figure 1 above, as these states are mission-specific and have not been included in the initial release of the Cryptography Library. Additional functions such as key verification and status request are expanded upon in the standard.

b.Security Association Management Service

The SA management service provides the bare necessities for complex mission operations to “command the configurable Security Association parameters of a remote system’s SDLS implementation into a state suitable for operations”. A complex mission would include those that need to create new associations and re-key them once on orbit. Not all missions will be complex, but long duration missions may need this feature. The state machine for SAs is captured in Figure 2.

Figure 2 - Variable State Model for Security

Figure 2 – Variable State Model for Security

SAs are mapped to Global Virtual Channel and/or Global MAP IDs. An SA can be mapped to multiple GVCIDs, but a single GVCID can only map to one SA. This mapping occurs in the SA Start function, changing the current SA state from keyed to operational.

c.SDLS Monitoring and Control Service

The SDLS monitoring and control service allows for logging, reporting, and determining of the current status of the Cryptography Library. This service also provides a means to debug errors that occurred and reset alarms that have been triggered “allow(ing) for complete control/command of the on-board security processor(s)”

d.Extended Procedures Payload Data Unit

The SDLS-EP services can be accessed via utilization of the PDU in Figure 3. Note that this message is contained in the data field of an SPP packet, defined in Section f, and includes the extended procedures tag, length, and value, or TLV. This TLV formula is interpreted for each of the commands accepted by the Cryptography Library to allow for the determination of the data. Specifically, the T or Tag in TLV is broken down into four sub-fields shown in Figure 3. The first bit contains the type field which defines if the packet is a command or a reply, while the second bit is used as a user flag to allow additional commands not dictated by the standard to be implemented. The service group decides which of the three services the packet relates to while the procedure identifier (PID) specifies the exact item. The listings for all defined, non-user, PIDs is captured in Table 3.

Figure 3 - Extended Procedures PDU

Figure 3 – Extended Procedures PDU


Table 1 - EP Key Service Identifications

Table 1 – EP Key Service Identifications


Table 2 – EP SA Service Identifications

Table 2 – EP SA Service Identifications


Table 3 – EP MC Service Identifications

Table 3 – EP MC Service Identifications

e.Frame Security Report

“This Frame Security report contains information about the status of the security unit and about the security processing (e.g. indicating a recent authentication failure).” The alarm field is flagged upon any error occurring. Additional fields are included to quickly determine the type of error that occurred. These flags are not cleared until the receipt of an alarm reset command. The Frame Security Report (FSR), as seen in Figure 4, also includes the last SPI and sequence number or initialization vector utilized in order to sync the spacecraft and the ground station in the event of RF link failure.

Figure 4 - Frame Security Report

Figure 4 – Frame Security Report

f.Space Packet Protocol

“The Space Packet Protocol is designed to meet the requirements of space missions to efficiently transfer space application data of various types and characteristics over a network that involves a groundto- space or space-to-space communications link” The efficiency and dual purpose is the reason this protocol is the base layer wrapped up by both the TC and TM protocols.