key management for space missions

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


Motivation

&

Scenarios


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)


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


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


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


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?


Scenario 3: Constellations

Sync

OCC 1 OCC 2

(Backup)

End-to-End

Security


General Key Management

Requirements

Based on NIST 800-57


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


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


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


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


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


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


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


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



• PKI Architectures• Mesh Based

• PGP

• Hierarchy Based• X.509



• 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


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


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


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


Space Link Management

Requirements


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


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


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


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


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


Suggestions/

Recommendations


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)


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


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


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


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


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


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


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


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


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


DISCUSSION


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


• 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

key management for space missions

Documents