Key Management for Space Missions Daniel Fischer ESA

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

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 2

Motivation & Scenarios Daniel Fischer 29 June 2006 3

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 4

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 5

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 Pre-Launch Key Sharing End-to-End Security Packet TM/TC SLE Extension Daniel Fischer 29 June 2006 6

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 Terrestrial Link End User Facility Daniel Fischer 29 June 2006 Key Infrastructure Sub Customers Packet TM/TC Terrestrial Link End User Facility 7

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 8

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

General Key Management Requirements Based on NIST 800 -57 Daniel Fischer 29 June 2006 10

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 11

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 12

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” • Require confidentiality and integrity protection • Secure destruction required after usage • Master Keys • Symmetric, key wrapping and derivation subtypes • Require confidentiality and integrity protection • Must remain available for key recovery Daniel Fischer 29 June 2006 13

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 14

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 15

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 16

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 17

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 18

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

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 Daniel Fischer 29 June 2006 20

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 21

P/SKI Key Management Phases 1. 2. 3. 4. Pre-operational Operational Post-operational Destroyed Pre. Activation Active Pre. Operational Post- Operational Deactivated Compromised Destroyed Daniel Fischer 29 June 2006 22

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 23

Space Link Management Requirements Daniel Fischer 29 June 2006 24

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 25

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 26

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 27

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 Protected Key SC OCC Reception Status Report Daniel Fischer 29 June 2006 28

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 29

Suggestions/ Recommendations Daniel Fischer 29 June 2006 30

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

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 32

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 33

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 34

Ground Segment Setup • Core 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 35

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 36

Certificate based IKE Phase 1 1. 2. 3. 4. 5. 6. 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 37

Secret key based IKE Phase 1 1. 2. 3. 4. 5. 6. 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 38

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 39

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 40

DISCUSSION Daniel Fischer 29 June 2006 41

• 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 42

• 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 43