1. Key Management V 0.4 Discussion of document revision SeaSec Intermediary Meeting, Heppenheim, October 07 Daniel Fischer Uni Lux SECAN-Lab / ESA OPS-GDA 04 October 2007

2. Daniel Fischer 04 th 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

3. Daniel Fischer 04 th October 2007 3 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

4. Daniel Fischer 04 th October 2007 4 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

5. Daniel Fischer 04 th October 2007 5 Document Split Green Book (contd) Space Link Key Management Data Fields Key Management Security Commands Ground Segment Key Management Key Management in Future Missions

6. Daniel Fischer 04 th October 2007 6 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

7. Daniel Fischer 04 th October 2007 7 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

8. Daniel Fischer 04 th October 2007 8 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

9. Daniel Fischer 04 th October 2007 9 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?

10. Daniel Fischer 04 th October 2007 10 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?

11. Daniel Fischer 04 th October 2007 11 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

12. Daniel Fischer 04 th October 2007 12 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

13. Daniel Fischer 04 th October 2007 13 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.

14. Daniel Fischer 04 th October 2007 14 Discussion