key management v 0.4 discussion of document revision seasec intermediary meeting, heppenheim,...

Key Management V 0.4Discussion of document revision

SeaSec Intermediary Meeting, Heppenheim, October 07

Daniel FischerUni Lux SECAN-Lab / ESA OPS-GDA

04 October 2007

Daniel Fischer04th October 2007 2

Agenda

• Actions from Leatherhead

• Document Split• Key Management Magenta Book• Key Management Green Book

• Description of modified sections

• Description of new sections

• Further work

• Discussion


Actions

• Done• Document Split • Addition of Sections SKIs• Timestamps• Key Management Data Fields• Security Control Commands

• Still missing• Key Generation Section (tog. with Howie)• Next generation networks


Document Split

• Magenta Book• Recommended Practice for Space Link Key Management• Recommended Practice for Ground Segment Key

Management• Key Revocation?

• Green Book• Introduction to Key Management• Cryptographic Keys (Lifetime, Applications, etc)• Key Infrastructures

• Public Key Infrastructure• Secret Key Infrastructure

• Security Policies• Key Management Guidance


Document Split

• Green Book (contd)• Space Link Key Management• Data Fields• Key Management Security Commands

• Ground Segment Key Management• Key Management in Future Missions


MAG: Key Revocation

• Key Revocation is an essential part of key management• We did not discuss this in detail before, is it part of the magenta

or more the green book (or both)?• Space Link

• Revocation happens via security control command from the ground and requires confirmation by the spacecraft• Ground still keeps the keys for backwards compatibility on data archives• Key is deleted onboard the spacecraft

• Mechanism that not the same key is used twice or two keys from different hierarchy levels are identical

• Autonomous revocation procedure?• Local policy decision Not in the magenta book, but mention the options

(requirements)(options in MB, examples and problem solving in the GB)

• Ground Segment• Key Revocation managed by PKI within the core GS• Key Revocation enforced by policies in the communication with the

external ground segment; key changes therefore forced by the core ground segment onto the external ground segment


GR: Secret Key Infrastructure

• Section on SKI was added• Use a key hierarchy on three different levels• Master Keys• Key Encryption Keys• Traffic Protection Keys

• Special Key Generation and Distribution Requirements• Initial Secret (External Channel)• Classification Issues

• SKI Trade-Off• External Channel Requirement• Scalability• Identity Binding


GR: Space Link Key Management

• Addition of key management data structure descriptions and control commands was decided in Leatherhead

• Key Management Data Structure Fields• Encrypted Keys • Key Identification Number (Key ID)• Spacecraft Identifier (SPID)

• May already be provided by transfer frame header if applicable

• If a global key management system applies, keys can be directly addressed by SPID + Key ID

• Timestamp• Clock synchronization issues?

• Signature


GR: Space Link Key Management

• Security Control Commands• Those include:• Upload of a new key [Traffic Protection Key / KEK]

• Encrypted Key• Key revocation [Traffic Protection Key / KEK / MK]

• Key Reference• Key switch [Traffic Protection Key / KEK / MK]

• Key Reference• Combine switch and revocation but keep option to destroy a

key• General discussion in the GB but the primitives should show

up the MB as well• Key inventory []• Those commands require a working reporting mechanism

• Part of the green book?


GR: Timestamps

• Timestamps may help in the synchronization between the space and the ground segment• Key Management Commands• Example: Key Switch Command: Spacecraft must

accept commands protected with the old key until switch confirmation has reached the ground. Those can then be identified by a timestamp window

• Is this discussion really appropriate here or should we not have a separate anti-replay / timestamping discussion

• How good is ground / space time sync?


GR: GSAKMP

• Group Security Association Key Management Protocol• Group controllers (GC) • Group Members (GM)

• Three kinds of security associations• SA1 For the registration of new members, establishment of

SA2s• SA2 Control Messages from the GC to GM (also

establishment of SA3s)• SA3 Communication between GMs

• I fail to see real application scenarios for present infrastructures• Space Segment• Ground Segment


GR: Future Key Management

• Some information collected but this is still in early draft status• Key Management in real spacecraft constellations

• Synchronization• If the OCC is responsible for the key management facility, its backups must

always be in the same state• Solutions exist here which can be adapted• Of course, those need also to be protected• Same for ground stations

• Routing• Ground Stations must be able to take a routing decision for the key

management control commands and key uploads• Likely to be done the same way as for the other data

• Routing in the space network will also become an issue e.g. Mars Telecommunications Orbiter

• Multiple Ground Stations• The best way to come around this problem is to make the GS unaware of the

security end-to-end• Key Management still central?

• Distributed key and identity management protocols may perform better at some point


GR: Future Key Management

• Key management for real spacecraft constellations currently lacks solutions for central questions• How does a satellite network topology look like, what properties does it

have?• What kind of network infrastructure will be used?• How high is the level of node autonomy?• Will there be multi-purpose constellations (e.g. military / civilian)?• Will there be nodes that are not under direct control of an agency (e.g.

another agency, customers, …• Key management gets a lot more complex

• Key management protocols build on top of those solutions. So they cannot be proposed before the solutions are on the table

• Some of those points induce or address real open research questions. Therefore I recommend not to include that in the green book at the moment but wait for results. Maybe a short section addressing the problems is appropriate.


Discussion

key management v 0.4 discussion of document revision seasec intermediary meeting, heppenheim,...

Documents