1 CCSDS Security Working Group Spring Meeting Colorado Springs Security Architecture January 19 th 2007

2 Agenda Changes since Rome A recap on the use of the Views The Security Architecture CCSDS Security Core Suite Some examples Emergency Commanding Next Steps Q&A

3 Changes since Rome Removal of in-depth discussions on –Authentication –Algorithm types –Key Management These are now discussed in greater detail in other books, to which the Security Architecture refers. Extended discussions to encompass more than scientific missions The architecture was always designed to be flexible and extensible, this has been brought out more in the document. Removal of File based encryption as a mandated part of the architecture, it is still available as an optional plugin for large delay and non-continuous communications. Emergency Commanding has been updated to allow for a range of options which can be selected by mission planners, there is no mandated solution for this as there is little need to interoperability in this area. Ground systems, from discussions in Rome it was felt that the Security Architecture should concentrate on Space Solutions, ground systems will use best-of-breed terrestrial technology and can be changed as the need arises.

4 The Views – A Summary Enterprise View – Tells us what inter-agency policies need to be developed Connectivity View – Tells us to consider Threats due to HOW elements communicate –RF in Space, non-continuous, QoS –Ground systems, use of the Internet, need for VPNs Functional View – Tells us the high level shape of the System Security Architecture –What functions does the mission need that the Security Architecture should support? Information View – Tell us the detail of the System Security Architecture –Where is the data, how is it stored, how is it transmitted, how should it be protected.

5 Proposed Architecture Based on a layered and expandable model Use of security formats, which can be used together or individually. –Transport Layer Encryption –Network Layer Encryption The use of Link Layer or Payload specific encryption is also accommodated by the architecture

6 CCSDS Security Core Suite Use of a Core suite of algorithms to allow reuse where missions do not need the complexity of bespoke solutions Mandated to ensure all CCSDS missions are interoperable Two layers, Network and Transport, can either be used together or separately Choice of recommended algorithms and configurations to be decided in other security books

7 Core Suite Configurations NetworkTransportComment 00 No encryption from Core Suite, suitable if a mission specific encryption suite is being used instead or there is no need for encryption such as in deep space. 10 Network only encryption, suitable for point to point encryption, very efficient. 01 Transport only encryption, suitable for when intermediate nodes are being used in the communications link. 11 Both Transport and Network encryption are being used, this would occur when a payload control centre is talking securely to it’s payload, over the secure communications the mission control centre has set up using network layer encryption.

8 Extending the Security Architecture The Core suite is not intended to solve all mission problems Missions are free to develop their own solutions as plug-ins to the architecture Note use of Link and Payload Security Agencies are free to develop their own security suites as plug- ins of the Security Architecture Core Suite supplies interoperability

9 Simple solutions

10 Emergency Commanding Agreement from Rome that this could not be a binary YES/NO for Security Therefore proposed a range of solutions –In Safe Mode but CPU online - use normal authentication –In Safe Mode, CPU offline- Watchdog drops need for authentication –Not in Safe Mode, CPU offline- Watchdog drops need for authentication –Tumbling- Watchdog drops need for authentication In the above cases the Watchdog is looking for certain events to reliably happen, if they do not it can drop the need for authentication Main aim is to keep the Watchdog very simple and robust Up to Missions Planners to decide which combination to choose, or whether to take the risk and not have authentication on emergency commands Little need for interoperability so recommend it is not a mandated part of the security architecture.

11 Next Steps We need to develop a set of missions profiles to be used as examples for each of the 5 missions types. –Manned Space –Weather –Communications –Scientific –Navigation It would be good to have input from the agencies with specific experiences of these mission types to ensure a good quality result. However we need to be clear that these are examples only, the main message must be to use the different views to examine each mission on its own merits and ensure that all the correct Polices, infrastructure and architecture are in place, for that mission.

12 AoB Questions?