ESA UNCLASSIFIED – For Official Use SDLS Key Management Extended Procedures Daniel Fischer, Ignacio Aguilar Sanchez CCSDS Fall Meetings 2012 Oct 2012

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 2 ESA UNCLASSIFIED – For Official Use Context In Darmstadt it was decided that Key Management Extended Procedures for SDLS shall be drafted Agreed in Darmstadt:  SDLS Key Management Procedures will be based on the generic Key Management Procedures specified in the Symmetric Key Management Blue Book  Key Management Procedures required to support SDLS Symmetric Key MM Blue Book SDLS Ext. Procedures

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 3 ESA UNCLASSIFIED – For Official Use Status of the KM Blue Book Draft Symmetric Key Management Blue Book has been updated Current Draft: 0.8 Section 4 contains now all mandatory key management procedures Procedures have been re-organised that renamed to fit what was agreed in the Darmstadt Meetings Information about the way how the standard is to be used has been integrated Next Phase Alignment of the book with the SDLS extended procedures Clean-up and another internal review

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 4 ESA UNCLASSIFIED – For Official Use Agreed Key Management Procedures 1.Enter Key DB Officer RoleOptional (TBD – Action Craig)(Require explicit auth. before enabling KM) 2.Exit Key DB Officer Role Optional (TBD – Action Craig) 3.Key DB Status RequestMandatory(General module status information) 4.Key DB Self-Test Mandatory(Typical startup tests – known answer, e.g.) 1.Verify Key Mandatory(Request MAC verification & read-back (MAC over the key or CRC)) 2.Revoke KeyMandatory(Mark key as unusable) 3.Erase KeyMandatory, if OTAR is used(Destroy a single key) 4.Zeroize Optional(Wipe entire key DB) 5.Convert Key Red–>BlackOptional Maybe needed for missions without OTAR 6.Convert Key Black–>RedOptional Maybe needed for missions without OTAR 7.Generate KeyOptional(Requires a master key) 8.Load Master Key / KEK Optional(Replace an existing master key / KEK) 9.Unload Master Key / KEK Optional 10.Key Upload (OTAR)Mandatory, if OTAR is used(Uploads Keys(s) to SC) 11.Activate KeyMandatory(Activates/Arms a Key)

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 5 ESA UNCLASSIFIED – For Official Use Extended Procedures URD Review General Requirements (Sec 6.2) state that the Extended Procedures shall be compatible with TM/TC/AOS SLE Problem: For TC this limits the SLE options to F_CLTU should the VCA approach be taken for the Key Management Procedures, TM no problems (R_AF) Key Management (Section 6.3) States that the extended procedures shall support not only the OTAR scenario, but also the Key Generation scenario  Key Generation should not be an optional procedure  Inconsistent with the list of procedures at the end of the section For generation, it is mentioned that it shall be possible to upload a non-secret seed. There is currently no procedure for this. The URD does not mention how the procedures should be integrated into the data-link layer interface

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 6 ESA UNCLASSIFIED – For Official Use Assumptions necessary to define for KM Procedures

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 7 ESA UNCLASSIFIED – For Official Use Assumptions to be discussed 1/3 Assumption 1: Ground will always be the initiator of key management procedures  Command link carries KM procedure requests Assumption 2: Data-Link Layer services will be used to communicate KM procedures  KM transmissions are embedded into frames and/or segments data fields Disclaimer: In this first step, only traditional command/ control links have been taken into account for key management i.e. we are looking at spacecraft platform security. If agreed by the WG, special setups for payload security could be investigated as well…this would have an influence on Assumption 2.

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 8 ESA UNCLASSIFIED – For Official Use Assumptions to be discussed 2/3 S/C Platform Ground Control SDLS Frames/ Segments Payload Packets Sec Unit KM Directives S/C Platform Ground Control SDLS Frames/ Segments Payload Packets Sec Unit KM Directives Payload Control Sec Unit SDLS Frames Sec Unit

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 9 ESA UNCLASSIFIED – For Official Use Assumptions to be discussed 3/3 Assumption 3: The use of SDL protocols for communication of KM directives is as following AOS/ TC may be used for uplinking KM frames/ segments AOS/ TM may be used for downlinking KM frames The final setup is then a combination of one uplink protocol and one downlink protocol (e.g. TC for uplink, AOS for downlink).

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 10 ESA UNCLASSIFIED – For Official Use KM Procedure Service Interface with SDLS

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 11 ESA UNCLASSIFIED – For Official Use Ground Only KM Procedures as VCA Service? A KM Handling entity manages the proper execution of the KM Procedures (stateful?) Interface with the TC/TM/AOS protocols happens in the role of a VCA service/ MAP access service No additional changes in SDLS required No processing through the application layer required  Allow application layer implementation as well? KM Handling (VCA Service) VCA_PDU VCA_PDU / Segment AOS/TC AOS/TM Backend (Key DB, Key Gen.) User Interface

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 12 ESA UNCLASSIFIED – For Official Use Identification of KM directives Key Management (and possibly SA management and SDLS management) procedures need to be distinguished from “normal” communication without impacting the TC/TM/AOS standards This should happen my means of a security association using the protocol routing functions (i.e. TC MAP/VC Id, TM VC Id, AOS VC Id) Key management procedures should be handled under a specific Security Association and will also need to be at least authenticated Open Questions:  How to handle the SA management of this control channel?  One management SA per standard SDLS SA, or one management SA for all productive SAs?

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 13 ESA UNCLASSIFIED – For Official Use Keys Setup and KM Procedures

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 14 ESA UNCLASSIFIED – For Official Use Key Management – Key Types and Lifecycle Symmetric KM BB specifies two types of keys: Ephemeral Keys (Session Keys) Static Keys (Master Keys) Both are used for SDLS KM in a tow-tier hierarchy Symmetric KM BB specifies key life cycle: Applies to SDLS KM. The optional state “Suspended” will not be used. Pre- Activation Compromised Deactivated/ Revoked DestroyedActive Compromised Destroyed

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 15 ESA UNCLASSIFIED – For Official Use KM Procedures Specification The KM BB specifies the protocol/set of steps for each of the required KM procedures Roles involved (Initiator/ Recipient) Specification of pre-condition to start the procedure Specification of each step necessary to complete the procedure Processing Steps (e.g. encryption) Communication Steps (e.g. send/receive messages)  SDLS KM Extended Procedures concretise the abstract specification for the procedures that are required to support SDLS Procedure Specification (Extension of KM BB specification) Description of protocol interface (probably generic to other procedures) Data Fields and Structures Specification (new)

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 16 ESA UNCLASSIFIED – For Official Use Data Fields and Structures Main structure is Key Management PDU (=VCA_PDU or TC Segment)  KM Procedure Header  KM Procedure Data Field KM PROCEDURE DATA FIELD KM PROCEDURE HEADER KM PROCEDURE PROTOCOL DATA UNIT 16 Variable Field ValueProcedure Key DB Status Request Key DB Self-Test Verify Key Revoke Key Erase Key Key Upload (OTAR) Activate Key

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 17 ESA UNCLASSIFIED – For Official Use Example 1: Key DB Status Request Abstract Procedure Flow InitiatorRecipient Status Request Step 1 (I): Status Request Creation and transmission Status Request Step 2 (R): Reception of status request message Status Response Step 3 (R): KEB DB Status Query and Response Creation Step 5 (I): Status Response Reception and Extraction Status Response Step 4 (R): Status Response Transmission

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 18 ESA UNCLASSIFIED – For Official Use Example 1: Key DB Status Request Key DB Status Procedure Data Field Structures KEY DB STATUS REQUEST KEY DB STATUS REQUEST STRUCTURE (1,1) 00 (2 bit) KEY DB STATUS KEY DB STATUS RESPONSE STRUCTURE (1,2) 4 bit

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 19 ESA UNCLASSIFIED – For Official Use Example 2: OTAR InitiatorRecipient Set of session keys Set of encrypted session keys Step 1 (I): Encryption of session keys Step 2 (I): Transmission of encrypted session keys Set of encrypted session keys Step 3 (R): Reception of encrypted session keys Set of session keys Step 4 (R): Decryption of encrypted session keys

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 20 ESA UNCLASSIFIED – For Official Use Example 2: OTAR OTAR Procedure Data Field Structure EPHEMERAL KEY 1 KEY UPLOAD STRUCTURE (6,1) managed EPHEMERAL KEY 1 META-INFO managed EPHEMERAL KEY n EPHEMERAL KEY n META-INFO managed

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 21 ESA UNCLASSIFIED – For Official Use KEY DB STATUS RESPONE Open Issues Do we need a procedure/step identification for each procedure data structure (similar to the subservice in PUS)? Related to the following:  Is the KM Handler stateful?  Do we assume no synchronisation problems? KEY DB STATUS RESPONSE STRUCTURE (1,2) 4 bit SUB PROCEDURE ID (2) 4 bit