CCSDS march 2008 meeting – Crystal City 1 TC/TM space links security SEA / SLS cross area meeting

CCSDS march 2008 meeting – Crystal City 2 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

CCSDS march 2008 meeting – Crystal City 3 TC/TM space links security Overview presentation

CCSDS march 2008 meeting – Crystal City 4 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

CCSDS march 2008 meeting – Crystal City 5 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

CCSDS march 2008 meeting – Crystal City 6 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

CCSDS march 2008 meeting – Crystal City 7 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 ?

CCSDS march 2008 meeting – Crystal City 8 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)

CCSDS march 2008 meeting – Crystal City 9 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

CCSDS march 2008 meeting – Crystal City 10 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 ?

CCSDS march 2008 meeting – Crystal City 11 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

CCSDS march 2008 meeting – Crystal City 12 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

CCSDS march 2008 meeting – Crystal City 13 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

CCSDS march 2008 meeting – Crystal City 14 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

CCSDS march 2008 meeting – Crystal City 15 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