Key Management for Space Missions

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

2. Agenda • Motivation • Scenarios • General Key Management Requirements and Procedures • Key Types • Key Infrastructures • Cryptoperiods • Space Link Key Management • Suggestions/ Recommendations • Discussion

3. Motivation & Scenarios

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

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

6. Scenario 1: Science Point-to-Point Pre-Launch Key Sharing End-to-End Security Packet TM/TC SLE Extension • 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

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

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

9. Scenario 3: Constellations End-to-End Security Sync OCC 2 (Backup) OCC 1

10. General Key Management Requirements Based on NIST 800-57

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

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

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

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

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

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

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

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

19. Public Key Infrastructures 2 • PKI Architectures • Mesh Based • PGP • Hierarchy Based • X.509

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

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

22. P/SKI Key Management Phases • Pre-operational • Operational • Post-operational • Destroyed Pre- Activation Pre- Operational Active Operational Post- Operational Compromised Deactivated Destroyed Compromised Destroyed Destroyed

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

24. Space Link Management Requirements

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

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

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

28. 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 SC OCC Protected Key Reception Status Report

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

30. Suggestions/ Recommendations

31. 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) SecurityModule Protected by Ground Segment Security Key Generation Facility

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

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

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

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

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

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

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

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

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

41. DISCUSSION

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

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