Transcript Colloques
Space Data Link Security BOF
SEA/SLS October 14, 2008 meeting
CCSDS october 2008 meeting – Berlin
1
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 CCSDS october 2008 meeting – Berlin
2
Agenda
Item
1 - Return of experience by agencies on past or on-going development of TM/TC link layer security.
Approx. time
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.
5 - Develop charter for the data link security WG 14H -16H 16H -17H
CCSDS october 2008 meeting – Berlin
3
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 - 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
-
ESA-PSS-04-107
-
ATV
-
METOP
-
GALILEO
-
GMES CCSDS october 2008 meeting – Berlin CNES
-
Telecom 2
-
SPOT
-
HELIOS
-
PROTEUS (Jason, COROT, SMOS, …)
-
PLEIADES-HR
4
Project
ESA Packet TC Decoder (PTD) ASIC ATV MetOp GALILEO GMES Sentinels
Project
Telecom 2 SPOT HELIOS PROTEUS (Jason, COROT, SMOS, …) PLEIADES-HR
Review of actions
ESA
Security function(s)
Optional TC Authentication as per ESA PSS-04 107 / 151 TC Encryption with Time Authentication TC Authentication and TM Encryption
Remarks
Outline description found in section A1 of CCSDS-350-0-G-2.
Outline description found in section A5 of CCSDS-350-0-G-2.
TC Authentication follows ESA PSS-04-107 TM Encryption details are provided in attachment.
Outline description provided in attachment.
TC Authentication/Encryption TM Authentication/Encryption TC Authentication
CNES
See below for details
Security function(s)
TC Authentication P/L TM encryption TC Authentication/Encryption TM Authentication/Encryption TC authentication TC encryption and authentication P/L TM encryption
Remarks
Authentication of TC frames content TC standard used : ESA-PSS-45 (old PCM std) Outline description found hereafter Civilian system - Bulk encryption - Defense classified system According to ESA-PSS-04-107. Uses CCSDS TC space data link protocol - uses CCSDS TC and AOS space data link protocols but security function insertion is not CCSDS compatible - Dual-use system
CCSDS october 2008 meeting – Berlin
5
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/JSC NASA/JPL ESA CNES - 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.
CCSDS october 2008 meeting – Berlin
6
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/JSC NASA/JPL ESA CNES
-
Authentication & encryption of AOS frames
-
both uplink and downlink
-
Authentication & encryption of uplink TC space data link
-
willing to propose a solution that will work for all CCSDS data link layer protocols
-
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 CCSDS october 2008 meeting – Berlin
7
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 CCSDS october 2008 meeting – Berlin
8
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.
CCSDS october 2008 meeting – Berlin
9
Return of Experience on past or on-going development
■
ESA :
ATV :
TC encryption 3-DES implemented at segment layer
PTD (ESA-PSS-04-107/151) :
implemented on all PTD any REX ?
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 front of frames not CCSDS compliant, sec. header in
GMES :
TC authentication (algo CMAC) at segment level, similar to ESA-PSS
CCSDS october 2008 meeting – Berlin
10
Return of Experience on past or on-going development
■
NASA :
ISS :
uplink and down link encryption of AOS frames data fileds any REX ?
CCSDS october 2008 meeting – Berlin
11
Review and build-up of data link security protocol URD
■
Outline of document :
1 INTRODUCTION
2 3 4 5 PURPOSE AND SCOPE REFERENCE DOCUMENTS APPLICABLE DOCUMENTS REQUIREMENTS
5.1
5.2
OVERVIEW CONVENTIONS COMPATIBILITY WITH CCSDS DATA LINK PROTOCOLS 5.3
– 5.3.1
– 5.3.2
– 5.3.3
– 5.3.4
– 5.3.5
TM SPACE DATA LINK TC SPACE DATA LINK PROXIMITY-1 SPACE LINK PROTOCOL AOS SPACE DATA LINK PROTOCOL COP-1 SECURITY REQUIREMENTS 5.4
– 5.4.1
– 5.4.2
– 5.4.3
– 5.4.4
– 5.4.5
SECURITY FUNCTIONS CONFIDENTIALITY INTEGRITY AUTHENTICATION ANTI-REPLAY (TC ONLY) MODES OF OPERATION 5.5
– 5.5.1
– 5.5.2
– 5.5.3
– 5.5.4
PROTOCOL VERSATILITY SECURITY SESSIONS MULTI USER SPACELINKS CLEAR MODE 5.6
– 5.6.1
CRYPTOGRAPHIC ALGORITHMS ALGORITHM AND PROTOCOL DEPENDENCY 5.7
– 5.7.1
– 5.7.2
– 5.7.3
KEY MANAGEMENT FIXED KEYS / PROGRAMMABLE KEYS ON-BOARD KEY MANAGEMENT KEY UPLOADING
6 ANNEX – Berlin
12
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 ?
CCSDS october 2008 meeting – Berlin
13
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?
CCSDS october 2008 meeting – Berlin
14
Review of proposals for security layer insertion within CCSDS data link protocols
■
NASA integrated proposal
■
other proposals ?
■
Way forward ?
CCSDS october 2008 meeting – Berlin
15
Chartering the SDL Security WG
■
cf. proposed charter CCSDS october 2008 meeting – Berlin
16