1. CCSDS october 2008 meeting – Berlin 1 Space Data Link Security BOF SEA/SLS October 14, 2008 meeting

2. CCSDS october 2008 meeting – Berlin 2 Meeting Objectives ■ Main objectives of meeting :  Review and finalize requirements for TM/TC/AOS Data Link Security protocol  Converge on a WG charter for the development of a recommendation for a Data Link Security protocol  Discuss agencies’ proposal(s) for the Data Link Security protocol implementation within CCSDS data link formats

3. CCSDS october 2008 meeting – Berlin 3 Agenda ItemApprox. time 1 - Return of experience by agencies on past or on-going development of TM/TC link layer security. 9H -10H 2 - Review and build-up of link security protocol user requirement document.10H -12H 3 - Review of FIPS and CCSDS recommended authentication / encryption algorithms together with associated constraints with respect to CCSDS link security layer. 13H -14H 4 - Review of NASA (and other ?) proposal for the implementation of the security layer within the CCSDS data link formats. 14H -16H 5 - Develop charter for the data link security WG16H -17H

4. CCSDS october 2008 meeting – Berlin 4 Review of actions ■ From march meeting :  AI 1 : For each agency, to provide examples of security functions insertion into CCSDS protocol stack (associated with the data link layer) for existing or planned mission (objective : illustrate the variability of solutions available to insert authentication and/or encryption) NASA/JSCNASA/JPLESACNES - The International Space Station S-band forward link uses CCSDS AOS and link-layer encryption : use the insert zone to carry security ancillary information, full data field encrypted, fully CCSDS AOS compatible + application layer security function for time window validation of commands No TM/TC link layer security implemented sofar - ESA-PSS-04-107 - ATV - METOP - GALILEO - GMES - Telecom 2 - SPOT - HELIOS - PROTEUS (Jason, COROT, SMOS, …) - PLEIADES-HR

5. CCSDS october 2008 meeting – Berlin 5 Review of actions ESA CNES ProjectSecurity function(s)Remarks ESA Packet TC Decoder (PTD) ASICOptional TC Authentication as per ESA PSS-04- 107 / 151 Outline description found in section A1 of CCSDS-350-0-G-2. ATVTC Encryption with Time AuthenticationOutline description found in section A5 of CCSDS-350-0-G-2. MetOpTC Authentication and TM EncryptionTC Authentication follows ESA PSS-04-107 TM Encryption details are provided in attachment. GALILEOTC Authentication/Encryption TM Authentication/Encryption Outline description provided in attachment. GMES SentinelsTC AuthenticationSee below for details ProjectSecurity function(s)Remarks Telecom 2TC Authentication - Authentication of TC frames content - TC standard used : ESA-PSS-45 (old PCM std) SPOTP/L TM encryption - Outline description found hereafter - Civilian system HELIOSTC Authentication/Encryption TM Authentication/Encryption - Bulk encryption - Defense classified system PROTEUS (Jason, COROT, SMOS, …)TC authenticationAccording to ESA-PSS-04-107. Uses CCSDS TC space data link protocol PLEIADES-HRTC encryption and authentication P/L TM encryption - uses CCSDS TC and AOS space data link protocols but security function insertion is not CCSDS compatible - Dual-use system

6. CCSDS october 2008 meeting – Berlin 6 Review of actions ■ From march meeting :  AI 2 : For each agency, to check that security and operational constraints (derived for example from security policy or other policy) will not prevent agreement on a common internationally agreed open solution. Also, for each agency, to list general constraints applicable to a future CCSDS security protocol standards (e.g. : selection and strength of crypto algorithm, …) NASA/JSCNASA/JPLESACNES - Constraint : United States government agencies (including NASA) that implement cryptographic systems must comply with Federal Information Processing Standards (FIPS). Other additional requirements apply to systems designated as national security systems or those that handle classified information. Item still in work ?-The ESA Security Policy does not prevent agreements on internationally agreed open solutions to protect specific contexts. - no a priori constraints on the selection of the algorithms providing they give the appropriate level of security to the mission -CNES has no security policy that would prevent the usage, on civilian missions (excluding defense and dual-use missions), of an international open standard - choice of algos/parameters should be left open to projects to select according to security level requirements.

7. CCSDS october 2008 meeting – Berlin 7 Review of actions ■ From march meeting :  AI 3 : For each agency, to express support within the list of potential security protocols that could be developed by the WG, the list being the following :TC authentication, TC encryption, TM authentication, TM encryption ; combined with : TC space data link protocol, TM space data link protocol, AOS downlink, AOS uplink, Prox-1. Known need dates if available for each supported protocol NASA/JSCNASA/JPLESACNES -Authentication & encryption of AOS frames - both uplink and downlink - willing to propose a solution that will work for all CCSDS data link layer protocols -Authentication & encryption of uplink - TC space data link - willing to propose a solution that will work for all CCSDS data link layer protocols -No support for Prox-1 link security. - By order of priority : -TC authentication - TC encryption (if support from other agencies) - AOS based TM encryption (for P/L TM) - conventional TM encryption -By order of priority : - TC authentication - AOS TM encryption - TC encryption

8. CCSDS october 2008 meeting – Berlin 8 Review of actions ■AI 3 : For each agency, to express support within the list of potential security protocols that could be developed by the WG.  Synthesis :  Support for both authentication and encryption  Support for taking care of : TC, TM and AOS (Prox-1 not a concern) ■AI 4 : provide User Requirement Document (URD) template :  Closed by CNES proposal ■AI 5 : contact JAXA for potential participation  Done : JAXA could participate in WG providing URD and charter meet JAXA needs

9. CCSDS october 2008 meeting – Berlin 9 Return of Experience on past or on-going development ■ CNES :  Pleiades-HR :  Dual-use system : requires full frame encryption preventing traffic analysis, requires secret algorithm  Full frame encryption induces non compatibility with CCSDS SLE and TC data link protocol, implying costly modification of multi-mission TM/TC comms infastructure.  Proteus :  based on ESA TC authentication protocol (ESA-PSS-04-151 becoming historical ?)  implemented on board inside PTD  seldom used operationnaly on scientific missions  Commercial telecom satellites :  use of CENTURION/CARIBOU plugs for S/L used for US government services –Provides uplink protection : encryption, authentication –Algorithm confidential (triple-DES for CENTURION) –Proprietary solution, only one provider : L3Com, ITAR  need for a solution based on an open standard for TC encryption and authentication  encryption / authentication of frame data field is sufficient. Should preserve compatibility with CCSDS TC data link protocol.

10. CCSDS october 2008 meeting – Berlin 10 Return of Experience on past or on-going development ■ ESA :  PTD (ESA-PSS-04-107/151) :  implemented on all PTD  any REX ?  ATV :  TC encryption  3-DES implemented at segment layer  METOP :  TC authentication (ESA-PSS), TM encryption (triple DES)  CCSDS compatible : implemented at TC segment and TM frame data field level  GALILEO :  TC and TM authentication / encryption  Dual-use mission : full frame protection  not CCSDS compliant, sec. header in front of frames  GMES :  TC authentication (algo CMAC)  at segment level, similar to ESA-PSS

11. CCSDS october 2008 meeting – Berlin 11 Return of Experience on past or on-going development ■ NASA :  ISS :  uplink and down link encryption of AOS frames data fileds  any REX ?

12. CCSDS october 2008 meeting – Berlin 12 Review and build-up of data link security protocol URD ■ Outline of document :  1INTRODUCTION  2PURPOSE AND SCOPE  3REFERENCE DOCUMENTS  4APPLICABLE DOCUMENTS  5REQUIREMENTS  5.1OVERVIEW  5.2CONVENTIONS  5.3COMPATIBILITY WITH CCSDS DATA LINK PROTOCOLS –5.3.1TM SPACE DATA LINK –5.3.2TC SPACE DATA LINK –5.3.3PROXIMITY-1 SPACE LINK PROTOCOL –5.3.4AOS SPACE DATA LINK PROTOCOL –5.3.5COP-1  5.4SECURITY REQUIREMENTS –5.4.1SECURITY FUNCTIONS –5.4.2CONFIDENTIALITY –5.4.3INTEGRITY –5.4.4AUTHENTICATION –5.4.5ANTI-REPLAY (TC ONLY)  5.5MODES OF OPERATION –5.5.1PROTOCOL VERSATILITY –5.5.2SECURITY SESSIONS –5.5.3MULTI USER SPACELINKS –5.5.4CLEAR MODE  5.6CRYPTOGRAPHIC ALGORITHMS –5.6.1ALGORITHM AND PROTOCOL DEPENDENCY  5.7KEY MANAGEMENT –5.7.1FIXED KEYS / PROGRAMMABLE KEYS –5.7.2ON-BOARD KEY MANAGEMENT –5.7.3KEY UPLOADING  6ANNEX

13. CCSDS october 2008 meeting – Berlin 13 Review of CCSDS authentication and encryption recommendations ■ Recommended Practice for symmetric encryption :  Draft red book : 353.0-R-0, september 2008, should start soon agency review  a single recommended algorithm and its parameters :  AES (as defined in FIPS Publication 197 and NIST special publication 800-38A)  128-bit block based algorithm  key size recommended : 128 bits – 196 - 256  CTR mode (counter mode as defined in NIST special publication 800-38A) –no padding to 128-bit block needed  for combined authentication with AES encryption : –GCM (NIST special publication 800-38D)  unspecified parameters ? Questions ?  size of IV, size of anti-replay counter for AES ? for GCM ?, crypto period ? …  Can’t AES cyphering provide authentication of sender as well ?

14. CCSDS october 2008 meeting – Berlin 14 Review of CCSDS authentication and encryption recommendations ■ Recommended Practice for symmetric authentication :  Draft red book : 352.0-R-0, september 2008, has been delivered to editor. Should start agency review before end 2008.  several recommended algorithms and their parameters :  HMAC (FIPS 198-1)  GMAC (RFC 4543 or NIST SP 800-38D)  CMAC (NIST SP 800-38B)  DSS (FIPS 186-2)  asymmetric not applicable  DSA + ECDSA (FIPS 186-2)  asymmetric not applicable  unspecified parameters ? Questions ?  Are all those algorithms : clear text with appended signature ? Do they all provide anti-replay ? Are they all block-based ?  Are they all equally suitable for US govt systems ?  Do we have a baseline or preferred solution to point implementers/projects at ?  Size of blocks ? Size of ICV/signature ? Size of anti-replay counter ? Need of an IV?

15. CCSDS october 2008 meeting – Berlin 15 Review of proposals for security layer insertion within CCSDS data link protocols ■ NASA integrated proposal ■ other proposals ? ■ Way forward ?

16. CCSDS october 2008 meeting – Berlin 16 Chartering the SDL Security WG ■ cf. proposed charter