[FAQ's top

Q: What is the scope of the protection provided by the SCPS Security Protocol?

The SCPS Security Protocol (SCPS-SP) provides end-to-end security services and resides between OSI layers three (network) and four (transport). SCPS-SP provides confidentiality (encryption), integrity, and authentication services. Access control is provided as a by-product of confidentiality and authentication. Protocol data units (PDUs) can use confidentiality and integrity independent of one another, or combined. Authentication must be used with either integrity, confidentiality, or both. Confidentiality ensures that the data is protected from eavesdropping from its source to its destination. Integrity prevents unauthorized modification of the data while it is in transit from its source to its destination. Authentication provides assurance to the receiver that the data actually came from the claimed source.

Q: Why can't we just use link encryption?

Link encryption is a powerful security mechanism but can only be applied on a hop-by-hop basis. If there are multiple communication hops involved between a source and a destination, then link encryption devices are required between each hop and the data must be decrypted when received and then re-encrypted for transmission onward, potentially exposing the data to those who should not have access to it, or to undetectable modification or corruption.

For example, if data is to be sent from an instrument control facility, to a spacecraft control facility, to a ground station, and across a space link to a spacecraft, then link encryption devices would be required on each end of the communications circuit between the instrument control facility and the spacecraft control facility. Additional link encryption devices would be required on the communications link between the spacecraft control facility and the ground station. Finally, additional link encryption devices would be required on the space link - in the ground station and aboard the spacecraft. However, the data would be decrypted (and then re-encrypted) at the spacecraft control facility and at the ground station. Therefore, the data is potentially available to those who should not see it, and also exposed to potential corruption.

Link encryption provides total obscurity of the information on the link whereas all of the header information in the layers below SCPS-SP is openly available when using SCPS-SP. If prevention of traffic analysis or data interception is required, only link encryption can provide these protection services. A combination of SCPS-SP (to provide end-to-end protection) and link encryption (on selected vulnerable links) provides the most secure solution.

Q: Can't these security protocols lock me out of my own spacecraft?

No, not if the spacecraft was designed for use with the Security Protocol. All spacecraft potentially have the problem that on-board resources (e.g., an on-board computer) may not operate correctly resulting in control and operations problems. In order to ensure emergency control of the spacecraft, the hardware command decoder should execute several critical functions directly in its own hardware (e.g., critical actuators, on-board computer re-initialization) rather than relying on other upstream spacecraft resources. In this manner, emergency commanding will be performed by a hardware function directly behind the spacecraft's radio receiver and before any other on-board computer resources. However, from a security perspective, this results in a potential vulnerability to the spacecraft unless the emergency commands are protected in some manner. A tradeoff must made by the designers between spacecraft emergency safety and overall spacecraft security.

[FAQ's top