ccsds october 2008 meeting – berlin 1 space data link security bof sea/sls october 14, 2008...

1CCSDS october 2008 meeting – Berlin

Space Data Link Security BOF

SEA/SLS

October 14, 2008 meeting


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


Agenda

Item Approx. 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 WG 16H -17H


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/JSC NASA/JPL ESA CNES

- 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


Review of actionsESA

CNESProject Security function(s) Remarks

ESA Packet TC Decoder (PTD) ASIC Optional TC Authentication as per ESA PSS-04-107 / 151

Outline description found in section A1 of CCSDS-350-0-G-2.

ATV TC Encryption with Time Authentication Outline description found in section A5 of CCSDS-350-0-G-2.

MetOp TC Authentication and TM Encryption TC Authentication follows ESA PSS-04-107TM Encryption details are provided in attachment.

GALILEO TC Authentication/EncryptionTM Authentication/Encryption

Outline description provided in attachment.

GMES Sentinels TC Authentication See below for details

Project Security function(s) Remarks

Telecom 2 TC Authentication -Authentication of TC frames content-TC standard used : ESA-PSS-45 (old PCM std)

SPOT P/L TM encryption -Outline description found hereafter-Civilian system

HELIOS TC Authentication/EncryptionTM Authentication/Encryption

- Bulk encryption- Defense classified system

PROTEUS (Jason, COROT, SMOS, …) TC authentication According to ESA-PSS-04-107. Uses CCSDS TC space data link protocol

PLEIADES-HR TC encryption and authenticationP/L TM encryption

- uses CCSDS TC and AOS space data link protocols but security function insertion is not CCSDS compatible- Dual-use system


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, …)


- 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.


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


-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


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


Return of Experienceon 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.



■ 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



■ NASA :

ISS : uplink and down link encryption of AOS frames data fileds any REX ?


Review and build-up of data link security protocol URD

■ Outline of document : 1 INTRODUCTION 2 PURPOSE AND SCOPE 3 REFERENCE DOCUMENTS 4 APPLICABLE DOCUMENTS 5 REQUIREMENTS

5.1 OVERVIEW 5.2 CONVENTIONS 5.3 COMPATIBILITY WITH CCSDS DATA LINK PROTOCOLS

– 5.3.1 TM SPACE DATA LINK– 5.3.2 TC SPACE DATA LINK– 5.3.3 PROXIMITY-1 SPACE LINK PROTOCOL– 5.3.4 AOS SPACE DATA LINK PROTOCOL– 5.3.5 COP-1

5.4 SECURITY REQUIREMENTS– 5.4.1 SECURITY FUNCTIONS– 5.4.2 CONFIDENTIALITY– 5.4.3 INTEGRITY– 5.4.4 AUTHENTICATION– 5.4.5 ANTI-REPLAY (TC ONLY)

5.5 MODES OF OPERATION– 5.5.1 PROTOCOL VERSATILITY– 5.5.2 SECURITY SESSIONS– 5.5.3 MULTI USER SPACELINKS– 5.5.4 CLEAR MODE

5.6 CRYPTOGRAPHIC ALGORITHMS– 5.6.1 ALGORITHM AND PROTOCOL DEPENDENCY

5.7 KEY MANAGEMENT– 5.7.1 FIXED KEYS / PROGRAMMABLE KEYS– 5.7.2 ON-BOARD KEY MANAGEMENT– 5.7.3 KEY UPLOADING

6 ANNEX


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 ?


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?


Review of proposals for security layer insertion within CCSDS data link protocols

■ NASA integrated proposal

■ other proposals ?

■ Way forward ?


Chartering the SDL Security WG

■ cf. proposed charter

ccsds october 2008 meeting – berlin 1 space data link security bof sea/sls october 14, 2008...

Documents