Key Management for Space Missions Daniel Fischer, ESA / Uni Luxembourg CCSDS Meeting January 2007 Colorado Springs, CO, USA

General Key Management Requirements and Procedures Agenda Motivation Scenarios General Key Management Requirements and Procedures Key Types Key Infrastructures Cryptoperiods Space Link Key Management Suggestions/ Recommendations Discussion Daniel Fischer 29 June 2006

Motivation & Scenarios Resulting study documentation will be submitted to the security working group for approval and shall be treated as ESA internal documents. System level overview shall also be provided. Daniel Fischer 29 June 2006

Motivation A Key Management document was planned to supplement the Security Architecture document (Gavin Kenny) Decision taken in the Rome meeting It should address key management in the ground and space segment and between them Without a mature key management system, the best cryptographic operations cannot provide their full security (weakest link principle) Daniel Fischer 29 June 2006

Approach The most important basis for the general content was NIST Special Publication 800-57 However, only the main ideas where taken and the document is referenced in order to reduce size of the key management book Special properties of space link communication where investigated and a key management solution suggested Solution should be compatible with CCSDS Packet TM/TC on the space link and SLE / IP based infrastructure in the ground network Daniel Fischer 29 June 2006

Scenario 1: Science Point-to-Point Standard science mission with basic security requirements TC authentication, TM payload encryption End-to-End security between spacecraft and control centre Pre-Launch Master Key (MK) Sharing Directly use MK for encryption and authentication Use MK for session key upload encryption Use MK for session key derivation Packet TM/TC SLE Extension End-to-End Security Pre-Launch Key Sharing Daniel Fischer 29 June 2006

Scenario 2: Ground dissemination req. Secure ground data dissemination to customers, science institutions, universities etc. is required Key management system must be able to satisfy this key distribution requirements Keys must be flavored to allow access control, security level classification and identification of users Key infrastructure must be deployed (PKI or SKI) SLE Extension Packet TM/TC Key Infrastructure Terrestrial Link Terrestrial Link End User Facility End User Facility Sub Customers Daniel Fischer 29 June 2006

Scenario 3: Constellations Constellations represent a cascade of the normal mission data infrastructure Two possibilities: Each spacecraft is controlled independently  simply multiple instances of the single mission scenario Key Management may be handled individually Constellation control Much higher complexity Back-up control centers that need to be synchronized Multiple ground stations Inter-satellite communication Very high requirements to key management Do we need to cover the second possibility right now? Daniel Fischer 29 June 2006

Scenario 3: Constellations Sync OCC 1 OCC 2 (Backup) End-to-End Security Daniel Fischer 29 June 2006

General Key Management Requirements Based on NIST 800-57 Resulting study documentation will be submitted to the security working group for approval and shall be treated as ESA internal documents. System level overview shall also be provided. Daniel Fischer 29 June 2006

Keys can be categorized into different flavors Key Flavors 1 Keys can be categorized into different flavors The flavor of a key defines several properties Application purpose Security Sensitivity Confidentiality Requirements Integrity Requirements Lifespan (crypto period) Storage and recovery properties Generation principles Destruction principles A key should be only used for ONE purpose which is defined through its flavor Daniel Fischer 29 June 2006

Signing Keys /Signature Verification Keys Key Flavors 2 Signing Keys /Signature Verification Keys Public/Private key pairs for digital signatures Signing (Private) keys require confidentiality and integrity protection Signature Verification Keys require integrity protection Secret authentication keys Symmetric keys for authentication (MACs etc) Require confidentiality and integrity protection Public authentication keys Public keys for authentication algorithms Require integrity protection Daniel Fischer 29 June 2006

Long Term Data Encryption Keys Key Flavors 3 Long Term Data Encryption Keys Symmetric keys with long lifespan Require confidentiality and integrity protection Must be kept available and associated with the data Short Term Data Encryption Keys Symmetric keys with short lifespan, “Session keys” Secure destruction required after usage Master Keys Symmetric, key wrapping and derivation subtypes Must remain available for key recovery Daniel Fischer 29 June 2006

Initialization Vectors Shared Secrets Seeds Intermediate Results Other keying material Domain Parameters Required for key pair generation Initialization Vectors Required for some cipher modes Shared Secrets Used as basics for secret keys Seeds E.g. used for pseudorandom number generation Intermediate Results Key Control Information E.g. a key ID Daniel Fischer 29 June 2006

Access to plaintext keys strictly controlled Key Establishment 1 Key Establishment is the generation and distribution of keys and other cryptographic material Key Generation Validated (Pseudo) Random Number generator Generation Policies Well-established key generation algorithm Access to plaintext keys strictly controlled Security Policies Key wrapping Daniel Fischer 29 June 2006

Distribution of other non-key material Key Establishment 2 Key Agreement Schemes Keys are established using information contributed by each party Example: Diffie-Hellman Identity knowledge is very important If this is not guaranteed, man-in-the-middle attacks become possible Distribution of other non-key material Always distributed Domain params, Initialization vectors Sometimes distributed Seeds, Key Information Never distributed: Shared Secrets, Intermediate Results Daniel Fischer 29 June 2006

Key States and Transitions A key is used different depending on the state of its lifecycle (crypto period) Pre-activation state: Key has been generated but is not yet in usage Active State: Main state where key is used for performing cryptographic operations Deactivated State: Key is no longer in operations but still exists in memory Destroyed State: Key is destroyed and cannot be recovered Compromised Sate: The key has been disclosed or corrupted by unauthorized entities Destroyed Compromise State: Key is destroyed after a compromise or a key is destroyed and later found to be compromised Daniel Fischer 29 June 2006

Public Key Infrastructures 1 PKIs bind the identity of public keys to their owners (certificate principle) and help distributing and managing those certificates in large environments Basic PKI components are Public Key Certificate: Electronic record that bind the identity of a user to his public key Certificate Revocation List (CRL): Manages all certificates that have been revoked Certification Authority (CA): A trusted entity that issues and revokes public key certificates and certificate revocation lists Registration Authority (RA): An entity that is trusted by the CA to register or vouch for the identity of users to a CA Certificate Directory (DIR): An electronic site that holds certificates and CRLs Daniel Fischer 29 June 2006

Public Key Infrastructures 2 PKI Architectures Mesh Based PGP Hierarchy Based X.509 Daniel Fischer 29 June 2006

Public Key Infrastructures 3 Security Policies Good integrity and security requirements and their enforcement through policies are crucial for all PKI components CA is the most critical part of a PKI and has to be protected by strong sec. policies Reaction plans in case of a key compromise Interoperability Different PKI implementations need standardized ways to communicate with each other Maybe not that important for space missions unless they are a joined effort GSAW and RGSGSO abstracts will be prepared and submitted Daniel Fischer 29 June 2006

Secret Key Infrastructures (SKIs) Key infrastructures using secret keys only A trusted base is required for sharing the secret keys that are highest in the hierarchy SKIs lack some important properties No identity binding  no non-repudiation No authentic key revocation list SKIs can be easier to realize in small infrastructures However, they scale badly when the system gets bigger At the moment this is the approach used in space missions Daniel Fischer 29 June 2006

P/SKI Key Management Phases Pre-operational Operational Post-operational Destroyed Pre- Activation Pre- Operational Active Operational Post- Operational Deactivated Compromised Destroyed Destroyed Compromised Destroyed Daniel Fischer 29 June 2006

Key distribution possibilities Central Key Generation Keys are produced at a central instance and then distributed in the network Electronically Manually Key Negotiation Two nodes negotiate a key using a key establishment scheme such as IKE Master key derivation Keys are derived from previously distributed master keys Daniel Fischer 29 June 2006

Space Link Management Requirements Resulting study documentation will be submitted to the security working group for approval and shall be treated as ESA internal documents. System level overview shall also be provided. Daniel Fischer 29 June 2006

SL Management Req Introduction Space Link Key Management discusses the differences and variations to the classical topic addressed in NIST 800-57 The space-link only structure is much simpler than general NIST 800-57 As space link infrastructures are normally completely agency internal, no special authorization and access control schemes are required although confidentiality, authentication and integrity are issues Based on an SKI Daniel Fischer 29 June 2006

SL Key Management Entities Only three types of entities exist: Spacecraft Ground Station(s) Operational Control Centre Ground Station(s) normally not involved in key management This would violate end-to-end concept Synchronization arise for multiple ground stations OCC acts as central key generation and distribution instance Daniel Fischer 29 June 2006

Key Types and Generation Two basic key types Master Keys (for key wrapping or derivation) Session Keys (for authentication and encryption) OCC is responsible for key generation Pre-shared keys must be stored using a highly secure storage device Not specified here Validated key generation and management module Generation and distribution of session keys must be automated Daniel Fischer 29 June 2006

Key Exchange and Revocation Session key exchange must only be possible under master key encryption (wrapping) Uploaded keys must be unilaterally confirmed before they can be used Confirmation is still protected by the old key Therefore no synchronization issues arise  Key upload is realized through a simple two-way protocol OCC SC Protected Key Reception Status Report Daniel Fischer 29 June 2006

Alternative to Key Confirmation At the moment the requirement for key confirmation is required especially with multiple keys that are in operation in parallel It has to be investigated, whether the confirmation step can be skipped E.g.: Just start operating the new key and if the security operations (e.g. authentication) fails, expect failure in key upload and restart procedure This suggestion is based on the usage of key confirmation Daniel Fischer 29 June 2006

Suggestions/ Recommendations Resulting study documentation will be submitted to the security working group for approval and shall be treated as ESA internal documents. System level overview shall also be provided. Daniel Fischer 29 June 2006

Space Segment Key Management Basic Diagram Spacecraft KEK Encryption Authentication Keys Encryption Keys (KEKs) Key Exchange Confirmation Messages (HKT) Control Centre Ground Station(s) Key Exchange Confirmation Messages (HKT) Security Module Protected by Ground Segment Security Key Generation Facility Daniel Fischer 29 June 2006

1) CCSC : {Knew, IDKnew}KEKx, IDKnew Proposed Protocol 1) CCSC : {Knew, IDKnew}KEKx, IDKnew 2) SCCC: {Confirmation_ IDKnew } Kold 3) CC switch keys Knew :New session key, Knew :Old session key IDKnew :New session key ID KEKx :Key Encryption Key x Confirmation_ IDKnew : Confirmation message for session key Knew Daniel Fischer 29 June 2006

Possible future evolution The current SL key management scheme is very simple Key wrapping provides only indirect OCC authentication No SC authentication In the future more sophisticated protocols might be required E.g. based on Needham-Schröder-Lowe or other key exchange mechanisms with strong mutual authentication Daniel Fischer 29 June 2006

GS Key Management Scheme Proposal based on existing security techniques IP based infrastructure is assumed Ground segment is partitioned in two areas Core ground segment: All agency owned and trusted parts of the network External ground segment: Untrusted or partially trusted networks and nodes e.g. the internet, customer nodes and networks, science institutions etc. External Ground Segment Core Ground Segment Daniel Fischer 29 June 2006

Ground Segment Setup Core ground segment External ground segment Well established agency internal PKI Each node is issued an (attributed) certificate External ground segment Assumed not to be part of the agency PKI If non-repudiation is wanted, a PKI that is trusted by the agency PKI is required (mesh based connection or trusted third CA (hierarchy approach)) Session keys All data traveling between nodes in the GS is protected by session keys Life time, key lengths and other properties must be defined in security policies Policies must be negotiated with the nodes in the external ground segment (security associations) and means to enforce them must be found Daniel Fischer 29 June 2006

Key Negotiation GS key negotiation suggestion is based on the Internet Key Exchange (IKE) protocol Although IKE is part of IPSec the negotiated keys can also be used for other security schemes such as TLS Phase 1 IKE in the core ground segment is using main mode certificate based authentication Phase 1 key negotiation in the external ground segment is using main mode shared master keys We do not specify how the keys are pre-shared Phase 2 key negotiation is using quick mode based on the keys exchanged in phase 1 Daniel Fischer 29 June 2006

Certificate based IKE Phase 1 The initiator sends one ore more proposals for an SA The responder chooses the most secure SA he supports The initiator sends his public Diffie-Hellman key and a nonce The responder sends his public Diffie-Hellman key and a nonce Now both parties compute die DH key which is used to derive the encryption and authentication keys for phase 2 This step authenticates the steps 1-4 by means of certificate based signatures that are calculated over hashes that contain the negotiated key, session cookies and other security association related information Daniel Fischer 29 June 2006

Secret key based IKE Phase 1 The initiator sends one ore more proposals for an SA The responder chooses the most secure SA he supports The initiator sends his public Diffie-Hellman key and a nonce The responder sends his public Diffie-Hellman key and a nonce Now both parties compute die DH key which is used to derive the encryption and authentication keys for phase 2 This step authenticates the steps 1-4 by means of secret key based MACs that are calculated over hashes that contain the negotiated key, session cookies and other security association related information Daniel Fischer 29 June 2006

Phase 2 Quick Mode The complete communication in phase 2 is encrypted and authenticated by the means of the keys that have been negotiated in phase 1 Phase 2 repeats steps 1-4 of the phase 1 in order to completely decouple the resulting session key from the information that is used in phase 1 Daniel Fischer 29 June 2006

Hybrid Key Management Scheme In some missions it might be desirable to provide end-to-end key exchange or negotiation between an (possibly external) entity and a spacecraft (subsystem) without the operating agency being able to access these keys Exchanged keys are used for payload TM encryption Procedure is similar to the space link key exchange suggestion Master keys are being burned into a specially secured area of the payload module before launch The module can only be accessed with properly encrypted command sequences for access control More than one possibility here: Challenge-Response can be one but this does not need to be standardized Key Exchange is “tunneled” across the agency network In the GS part of the tunnel, the security is suggested to be amended with GS security features Therefore the external entity must run two key management processes, one for the GS and one for the space link Daniel Fischer 29 June 2006

DISCUSSION Resulting study documentation will be submitted to the security working group for approval and shall be treated as ESA internal documents. System level overview shall also be provided. Daniel Fischer 29 June 2006

Public Keys on spacecrafts? Extension of the PKI over the spacelink? General scope of the document…point-to-point and ground data dissemination only or also spacecraft constellations? Public Keys on spacecrafts? Extension of the PKI over the spacelink? Daniel Fischer 29 June 2006

Use of aggressive mode for quicker key exchange Use of aggressive mode for quicker key exchange? (no integrity of DH params) Do we really need IKE or are secret keys issued on request by the node that also contains the CA? Perhaps IKE only between external nodes and core nodes or between external nodes only and straightforward key distribution in core network Daniel Fischer 29 June 2006