ESA UNCLASSIFIED – For Official Use

SDLS Key Management Extended Procedures

Daniel Fischer, Ignacio Aguilar SanchezCCSDS 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

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

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 Role Optional (TBD – Action Craig) (Require explicit auth. before enabling KM)

2. Exit Key DB Officer Role Optional (TBD – Action Craig)

3. Key DB Status Request Mandatory (General module status information)

4. Key DB Self-Test Mandatory (Typical startup tests – known answer, e.g.)

5. Verify Key Mandatory (Request MAC verification & read-back (MAC over the key or CRC))

6. Revoke Key Mandatory (Mark key as unusable)

7. Erase Key Mandatory, if OTAR is used(Destroy a single key)

8. Zeroize Optional (Wipe entire key DB)

9. Convert Key Red–>Black Optional Maybe needed for missions without OTAR

10. Convert Key Black–>Red Optional Maybe needed for missions without OTAR

11. Generate Key Optional (Requires a master key)

12. Load Master Key / KEK Optional (Replace an existing master key / KEK)

13. Unload Master Key / KEK Optional

14. Key Upload (OTAR) Mandatory, if OTAR is used (Uploads Keys(s) to SC)

15. Activate Key Mandatory (Activates/Arms a Key)

Daniel Fischer, Ignacio Aguilar Sanchez | CCSDS Fall Meetings 2012 | Oct 2012 | HSO | Slide 5

ESA UNCLASSIFIED – For Official Use

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

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

Sec Unit

KMDirectives

S/C Platform

Ground Control

SDLS Frames/Segments

Payload

Packets

Sec Unit

KMDirectives

PayloadControl

Sec Unit

SDLSFrames

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

UserInterface

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

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

CompromisedDestroyed

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 FIELDKM

PROCEDURE HEADER

KM PROCEDURE PROTOCOL DATA UNIT

16 Variable

Field Value Procedure00000001 Key DB Status Request00000010 Key DB Self-Test00000100 Verify Key00001000 Revoke Key00010000 Erase Key00100000 Key Upload (OTAR)01000000 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

Initiator Recipient

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

Initiator Recipient

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

EPHEMERALKEY 1

KEY UPLOAD STRUCTURE (6,1)

managed

EPHEMERALKEY 1

META-INFO

managed

EPHEMERALKEY n

EPHEMERALKEY n

META-INFO

managed 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

SUBPROCEDURE ID

(2)

4 bit