1CCSDS march 2008 meeting – Crystal City

TC/TM space links security

SEA / SLS cross area meeting

2CCSDS march 2008 meeting – Crystal City

Meeting agenda

■ Main objectives of meeting : Discuss among SEA-Security and SLS specialists the opportunity to

embark on the CCSDS standardization of security protocols for CCSDS TM/TC protocol stack and more specifically at data link layer

Eventually agree on a cross-area BOF charter to start the process

■ Proposed agenda : Overview presentation (CNES) Security WG status report (H.Weiss) Link layer security implementation (BNSC/QinetiQ) CCSDS Link layer Security proposal (NASA/JPL) Wrap-up : agreement on BOF charter

3CCSDS march 2008 meeting – Crystal City

TC/TM space links security

Overview presentation

4CCSDS march 2008 meeting – Crystal City

Outline

■ Context of TM/TC link security■ Opportunity for CCSDS to standardize security at data link layer■ Types of missions to be covered■ Security functions to be developed as standard protocol(s)■ CCSDS data link protocols to be covered■ What kind of security protocol should be used :

symmetric / asymmetric

■ Adequacy of CCSDS recommended algorithms for authentication and encryption

■ Decision on cross-area BOF creation : charter, workplan, participating agencies

5CCSDS march 2008 meeting – Crystal City

Context of TM/TC link security

■ Defense missions : authentication / encryption / anti-jamming on the uplink and downlink usually bulk encryption, non interoperable secret algorithms not suited for international open standardization

■ Dual-use missions : authentication/encryption on the uplink, encryption on the downlink Usually data link layer authentication/encryption preserving

compatibility with civilian CCSDS compliant ground segment used by the civilian part of the mission

defense stakeholders usually impose confidentiality on the algorithm & protocol

not suited for international open standardization

6CCSDS march 2008 meeting – Crystal City

Context of TM/TC link security

■ Commercial missions : authentication and optionally encryption on the uplink no security or encryption on the downlink (for P/L TM only) usually using public algorithms (open standards – e.g. AES, DES) & open

protocols (CCSDS). Symmetric systems. Security based on secret keys shared by SCC and S/L.

for US & non US commercial telecom S/L operators who want to provide telecom services to US government necessity to use plug-in CENTURION/CARIBOU

confidential algorithm and protocol (TBC) suited for international open standardization (apart from telecom S/L doing

business with US government)

■ Science missions, earth observation : no security so far emerging requirement : TC authentication as a minimum international open standard would be welcomed because it would facilitate

interoperability for cooperative missions between agencies

■ Manned missions

7CCSDS march 2008 meeting – Crystal City

Context of TM/TC link security

■ Potential constraints : Is there any constraints (for each CCSDS participating agency) on the

selection of authentication or encryption algorithms & protocols ? in particular, is an open international standard specifying protocol & algorithm

acceptable for civilian (e.g. science) missions ? In other word, is security relying entirely on secret keys sufficient for all or some space agencies ?

Is there a rationale for a CCSDS TC authentication/encryption protocol ?

8CCSDS march 2008 meeting – Crystal City

Opportunity for CCSDS to standardize security at data link layer

■ Security Architecture draft 1.8 recommends implementing security at network or application layer :

rationale provide end-to-end security instead of hop by hop link layer security

Drawback spreads security functions on-board

■ Nevertheless, for simple missions with only one hop, link layer security is attractive because :

it provides in that case end-to-end security the security functions are centralized both on-board (in the TC

decoder) and on-ground (in the control center) and not spread in all the sources and destinations of TC/TM packets

■ Several options for insertion of security function at data link layer: Between channel coding sublayer and frame layer At frame layer At segment layer (for TC)

9CCSDS march 2008 meeting – Crystal City

Type of missions to be covered

■ Governmental & commercial missions with no defense-related security constraints :

science missions, … commercial (non US telecom) missions

■ Rationale : provide a standard industry supported solution for minimal security

(TC authentication) to project with no expertise on security and (almost) no budget for security

enable interoperability between agencies on security functions for cooperative missions :

agencies would have to agree on key management only

security based on open standardized algorithms should be acceptable for this kind of missions

10CCSDS march 2008 meeting – Crystal City

Security functions to be developed as standard protocol(s)

■ TC authentication providing : originator authentication integrity

■ TC encryption : confidentiality

■ TM authentication providing : originator authentication integrity

■ TM (P/L-TM or HK-TM) encryption : confidentiality

■ TM/TC anti-jamming : denial of service mitigation

■ Priority in terms of development ?

11CCSDS march 2008 meeting – Crystal City

CCSDS link layer protocols to be compatible with ?

■ For uplink : TC space data link protocol AOS space data link protocol

■ For downlink : TM space data link protocol AOS space data link protocol

12CCSDS march 2008 meeting – Crystal City

What kind of security protocols should be considered ?

■ Authentication : clear text with appended Message Authentication Code security based on secret keys shared by source and destination

(symmetric system) anti-replay protection unauthenticated mode (e.g. for emergency mode) multiple LAC (Logical Authentication Channels)

■ Encryption : security based on secret keys shared by source and destination

(symmetric system) anti-replay protection unciphered mode multiple LEC (Logical Encryption Channels)

■ Key management reloadable keys

13CCSDS march 2008 meeting – Crystal City

Adequacy of CCSDS recommended algorithms for authentication and encryption

■ CCSDS security WG in the process of recommending a set of algorithms for :

clear text with appended signature authentication based on symmetric secret keys :

(HMAC + SHA256) or GMAC (AES based) or CMAC (AES based) 256-bit down to 128-bit signature

fixed size block encryption based on symmetric secret keys (XOR of information message with encryption sequence) :

AES CTR mode (GCM) 128, 256 bits keys

■ CCSDS recommended algorithms (magenta books) can be used for link layer security

■ Link layer protocols should be modular wrt auth & encryp algorithms so that change of algos can be done easily if state of the art algos need to be introduced later

14CCSDS march 2008 meeting – Crystal City

Creation of cross-area BOF for TC(TM) link security protocol(s) ?

■ Charter perimeter ? :

TC authentication, TC encryption, TM encryption TC space data link protocol, TM space data link protocol, AOS downlink, AOS

uplink

objectives ? : review existing CCSDS compatible link layer security implementations check that respective agencies security and operational constraints will not

prevent agreement on a common internationally agreed open solution establish Users Requirements Document (URD) for those protocols selected in the

perimeter establish WG charter for standard(s) development

15CCSDS march 2008 meeting – Crystal City

Creation of cross-area BOF for TC(TM) link security protocol(s) ?

■ Workplan fall 2008 CCSDS meeting (Berlin) :

Existing implementations review, agencies security constraints check completed, first draft for sec protocol URD(s)

spring 2009 CCSDS meeting (Colorado) : final sec protocol URD(s) WG charter

■ Participating agencies and key personnel