Key Management for Space Missions Daniel Fischer, ESA / Uni Luxembourg CCSDS Meeting January 2007 Colorado Springs, CO, USA
Dec 18, 2015
Key Management for Space Missions
Daniel Fischer, ESA / Uni Luxembourg
CCSDS Meeting January 2007
Colorado Springs, CO, USA
Daniel Fischer29 June 2006 2
Agenda
• Motivation• Scenarios• General Key Management Requirements and
Procedures• Key Types• Key Infrastructures• Cryptoperiods
• Space Link Key Management• Suggestions/ Recommendations• Discussion
Daniel Fischer29 June 2006 3
Motivation
&
Scenarios
Daniel Fischer29 June 2006 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)
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 6
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 Fischer29 June 2006 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)
Terrestrial Link
End User
Facility
Packet TM/TCSLE Extension
Terrestrial Link
Sub
Customers
End User
Facility
Key Infrastructure
Daniel Fischer29 June 2006 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?
Daniel Fischer29 June 2006 9
Scenario 3: Constellations
Sync
OCC 1 OCC 2
(Backup)
End-to-End
Security
Daniel Fischer29 June 2006 10
General Key Management
Requirements
Based on NIST 800-57
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 19
Public Key Infrastructures 2
• PKI Architectures• Mesh Based
• PGP
• Hierarchy Based• X.509
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 22
P/SKI Key Management Phases
1. Pre-operational
2. Operational
3. Post-operational
4. Destroyed
Pre-Activation
Pre-Operational
Active
Deactivated Compromised
DestroyedDestroyed
Compromised
Operational
Post- Operational
Destroyed
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 24
Space Link Management
Requirements
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
OCC SC
Protected Key
Reception
Status Report
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 30
Suggestions/
Recommendations
Daniel Fischer29 June 2006 31
Space Segment Key Management
• Basic Diagram
KEK Encryption
Control Centre
Security Module
KeyGeneration
Facility
GroundStation(s)
Spacecraft
Protected byGround Segment
Security
•Authentication Keys•Encryption Keys•(KEKs) Key Exchange
ConfirmationMessages
(HKT)
Key ExchangeConfirmation
Messages(HKT)
Daniel Fischer29 June 2006 32
Proposed Protocol
1) CCSC : {Knew, IDKnew}KEKx, IDKnew
2) SCCC: {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 Fischer29 June 2006 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
Daniel Fischer29 June 2006 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.
CoreGround
Segment
External Ground Segment
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 37
Certificate based IKE Phase 1
1. The initiator sends one ore more proposals for an SA2. The responder chooses the most secure SA he supports3. The initiator sends his public Diffie-Hellman key and a nonce4. The responder sends his public Diffie-Hellman key and a
nonce5. Now both parties compute die DH key which is used to derive
the encryption and authentication keys for phase 26. 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 Fischer29 June 2006 38
Secret key based IKE Phase 1
1. The initiator sends one ore more proposals for an SA2. The responder chooses the most secure SA he supports3. The initiator sends his public Diffie-Hellman key and a nonce4. The responder sends his public Diffie-Hellman key and a
nonce5. Now both parties compute die DH key which is used to derive
the encryption and authentication keys for phase 26. 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 Fischer29 June 2006 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
Daniel Fischer29 June 2006 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
Daniel Fischer29 June 2006 41
DISCUSSION
Daniel Fischer29 June 2006 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?
Daniel Fischer29 June 2006 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