1. Space Data Link Security BOF SEA/SLS October 14, 2008 meeting

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

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/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
ATV
METOP
GALILEO
GMES
Telecom 2
SPOT
HELIOS
PROTEUS (Jason, COROT, SMOS, …)
PLEIADES-HR

5. Review of actions CNES ESA Project Security function(s) Remarks
ESA Packet TC Decoder (PTD) ASIC
Optional TC Authentication as per ESA PSS / 151
Outline description found in section A1 of CCSDS G-2.
ATV
TC Encryption with Time Authentication
Outline description found in section A5 of CCSDS G-2.
MetOp
TC Authentication and TM Encryption
TC Authentication follows ESA PSS
TM Encryption details are provided in attachment.
GALILEO
TC Authentication/Encryption
TM 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/Encryption
TM Authentication/Encryption
- Bulk encryption
- Defense classified system
PROTEUS (Jason, COROT, SMOS, …)
TC authentication
According to ESA-PSS Uses CCSDS TC space data link protocol
PLEIADES-HR
TC encryption and authentication
- uses CCSDS TC and AOS space data link protocols but security function insertion is not CCSDS compatible
- Dual-use system

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

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/JSC
NASA/JPL
ESA
CNES
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
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
AOS TM encryption
TC encryption

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. 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 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. Return of Experience on past or on-going development
ESA :
PTD (ESA-PSS /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. Return of Experience on past or on-going development
NASA :
ISS :
uplink and down link encryption of AOS frames data fileds
any REX ?

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

13. Review of CCSDS authentication and encryption recommendations
Recommended Practice for symmetric encryption :
Draft red book : 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 A)
128-bit block based algorithm
key size recommended : 128 bits –
CTR mode (counter mode as defined in NIST special publication A)
no padding to 128-bit block needed
for combined authentication with AES encryption :
GCM (NIST special publication D)
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. Review of CCSDS authentication and encryption recommendations
Recommended Practice for symmetric authentication :
Draft red book : 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 D)
CMAC (NIST SP B)
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. Review of proposals for security layer insertion within CCSDS data link protocols
NASA integrated proposal
other proposals ?
Way forward ?

16. Chartering the SDL Security WG
cf. proposed charter