1 / 16

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

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

arleen
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Space Data Link Security BOFSEA/SLSOctober 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

  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)

  5. Review of actions ESA CNES

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

  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

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

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

More Related