ioag8 esa security authenticate briefing

Data Security and Authentication E. M. Soerensen OPS-ONV21st July 2005: 

Data Security and Authentication E. M. Soerensen OPS-ONV 21st July 2005

CCSDS STANDARDS: 

CCSDS STANDARDS There are no approved standards for authentication or encryption at the CCSDS Data link Layer There are no approved standards for key management and distribution.

TC Authentication – Centralised : 

TC Authentication – Centralised

TC Authentication – Centralised: 

TC Authentication – Centralised Only CLTU service can be supported Security requirements and implementation is transparent to the cross supporting agency. There is no need to distribute the security key to the cross supporting agency The supporting agency does not require any knowledge of the security keys and security algorithms. This architecture would not require any changes to the current implementation already in place for cross support and should also not compromise spacecraft security requirements.

TC Authentication – De-centralised : 

TC Authentication – De-centralised

TC Authentication – De-centralised: 

TC Authentication – De-centralised All forward SLE transfer services are available for cross support like the Forward Space Packer Service and Forward CLTU All missions and ground station requiring for the cross support services must implement authentication units to a common specification. In particular, they most use the same authentication algorithm and use the same key length. As each mission will use a different key, the SLE service management must therefore ensure that the appropriate key is loaded for proper execution of the SLE forward data service.

The Problem isKEY MANAGEMENT: 

The Problem is KEY MANAGEMENT

Key Management (1): 

Key Management (1) Key generation - The requirements should identify the key production facility and the method of key generation. Key randomness - Key generation should be a random process. Lack of randomness effectively reduces the size of the key space. Key encryption algorithm - The requirements should identify the algorithm used for key encryption. Ideally, this should not be the same algorithm that is used for encryption of data. If the same algorithm is used it should be used in a different mode. Key transfer – The requirements should defined how the keys are to be distributed within the networks. This includes the key protocol and key updating. Note that if key material must be double encrypted if it is sent over untrusted networks or links that can be intercepted.

Key Management (2): 

Key Management (2) Key Period – The requirements should define the period of use for each key type. Key Storage – The requirements shall define how keys are to be stored within the system. Key Compromise – The requirements should define how the system is to recover from key compromise. Key Destruction – The requirements for key destruction must be specified. Keys must be destroyed securely. Key Re-use – Under normal operations a key should not be re-used after its period of use has expired. Key Roll-over – The change from a current key to the next key should be accomplished without interrupting any services.

Conclusion: 

Conclusion Cross support using SLE has been validated and is already in place for a number of missions. This cross support is based on the three basic services Forward CLTU for commanding and Return RAF and Return RCF for telemetry. The use of a centralised architecture for implementing security makes the use of these existing services transparent to the security implementation and security can be support today using the existing operational cross support systems.