1 / 21

SDLS Key Management Extended Procedures

SDLS Key Management Extended Procedures. Daniel Fischer, Ignacio Aguilar Sanchez CCSDS Fall Meetings 2012 Oct 2012. Context. In Darmstadt it was decided that Key Management Extended Procedures for SDLS shall be drafted Agreed in Darmstadt:

sierra-patel
Download Presentation

SDLS Key Management Extended Procedures

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. SDLS Key Management Extended Procedures Daniel Fischer, Ignacio Aguilar SanchezCCSDS Fall Meetings 2012 Oct 2012

  2. 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 SDLS Ext. Procedures Symmetric Key MM Blue Book

  3. Status of theKM 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

  4. Agreed Key Management Procedures • Enter Key DB Officer Role Optional (TBD – Action Craig) (Require explicit auth. before enabling KM) • Exit Key DB Officer Role Optional (TBD – Action Craig) • Key DB Status Request Mandatory (General module status information) • Key DB Self-Test Mandatory (Typical startup tests – known answer, e.g.) • Verify Key Mandatory (Request MAC verification & read-back (MAC over the key or CRC)) • Revoke Key Mandatory (Mark key as unusable) • Erase Key Mandatory, if OTAR is used (Destroy a single key) • ZeroizeOptional (Wipe entire key DB) • Convert Key Red–>Black OptionalMaybe needed for missions without OTAR • Convert Key Black–>Red Optional Maybe needed for missions without OTAR • Generate Key Optional (Requires a master key) • Load Master Key / KEK Optional (Replace an existing master key / KEK) • Unload Master Key / KEK Optional • Key Upload (OTAR) Mandatory, if OTAR is used (Uploads Keys(s) to SC) • Activate KeyMandatory(Activates/Arms a Key)

  5. Extended ProceduresURD 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

  6. Assumptions necessary to define for KM Procedures

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

  8. Assumptions to be discussed 2/3 Payload Payload Sec Unit Packets Packets KM Directives SDLSFrames S/C Platform S/C Platform Sec Unit SDLS Frames/ Segments KM Directives SDLS Frames/ Segments PayloadControl Sec Unit Ground Control Sec Unit Ground Control Sec Unit

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

  10. KM Procedure Service Interface with SDLS

  11. 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? AOS/TC Backend(Key DB, Key Gen.) KM Handling(VCA Service) VCA_PDU / Segment Ground Only User Interface AOS/TM VCA_PDU

  12. 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 proceduresshould be handled under a specific Security Association and will also need to be at least authenticatedOpen 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?

  13. Keys Setup and KM Procedures

  14. 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 Active Deactivated/ Revoked Destroyed Compromised CompromisedDestroyed

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

  16. Data Fields and Structures • Main structure is Key Management PDU (=VCA_PDU or TC Segment) • KM Procedure Header • KM Procedure Data Field KM PROCEDURE PROTOCOL DATA UNIT KM PROCEDURE HEADER KM PROCEDURE DATA FIELD 16 Variable

  17. Example 1:Key DB Status Request • Abstract Procedure Flow Step 2 (R): Reception of status request message Initiator Recipient Step 1 (I): Status Request Creation and transmission Status Request Step 3 (R): KEB DB Status Query and Response Creation Status Request Step 5 (I): Status Response Reception and Extraction Status Response Status Response Step 4 (R): Status Response Transmission

  18. Example 1:Key DB Status Request • Key DB Status Procedure Data Field Structures KEY DB STATUS REQUEST STRUCTURE (1,1) KEY DB STATUS REQUEST 00 (2 bit) KEY DB STATUS RESPONSE STRUCTURE (1,2) KEY DB STATUS 4 bit

  19. Example 2:OTAR Initiator Recipient Step 3 (R): Reception of encrypted session keys Step 1 (I): Encryption of session keys Set of session keys Set of encrypted session keys Set of encrypted session keys Step 4 (R): Decryption of encrypted session keys Step 2 (I): Transmission of encrypted session keys Set of session keys

  20. Example 2:OTAR • OTAR Procedure Data Field Structure KEY UPLOAD STRUCTURE (6,1) EPHEMERAL KEY n META-INFO EPHEMERAL KEY 1 META-INFO EPHEMERAL KEY n EPHEMERAL KEY 1 managed managed managed managed

  21. 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) KEY DB STATUS RESPONE SUB PROCEDURE ID (2) 4 bit 4 bit

More Related