nasa
Key Mapping
Should a single key only map to a specific security association? Document this per the standard as well as how it's currently implemented.
3 KEY TYPES AND KEY LIFECYCLE 3.1 KEY TYPES 3.1.1 GENERAL All symmetric key management instances that are used in CCSDS missions shall use only two categories of cryptographic keys: a) Master Keys; and b) Session Keys. 3.1.2 MASTER KEYS 3.1.2.1 Master Keys shall be used for the following purposes: a) encryption or authenticated encryption of Session Keys for the purpose of Over-TheAir-Rekeying (OTAR) or Session Key generation; b) encryption or authenticated encryption and authorization of specific on-board crypto unit commands and procedures. NOTE – The specification of algorithms and procedures for the protection of Session Keys and for authentication or authenticated encryption of on-board crypto units is outside the scope of this Recommended Practice. 3.1.2.2 A specific Master Key shall be used for only one of the above purposes during its lifetime. NOTE – Master Keys are also called static keys or key encryption keys. 3.1.2.3 The crypto period of a Master Key should not exceed one use of the key. 3.1.3 SESSION KEYS 3.1.3.1 Session Keys shall be used for the following purposes: a) authentication of information or data to be protected; b) encryption of information or data to be protected; c) authenticated encryption of information or data to be protected. NOTES 1 Session Keys are also called traffic-protection keys or traffic-encryption keys. DRAFT CCSDS RECOMMENDED PRACTICE FOR SYMMETRIC KEY MANAGEMENT CCSDS 354.0-R-1 Page 3-2 June 2018 2 The specification of algorithms and procedures for authentication, encryption, and authenticated encryption is outside the scope of this Recommended Practice. 3.1.3.2 A specific Session Key shall be used for only one of the above purposes during its lifetime. 3.1.3.3 Session Keys shall not be used for the protection of other Session Keys or information that contains unprotected Session Keys.
https://public.ccsds.org/Lists/CCSDS%203540R1/354x0r1.pdf - Section 3 https://public.ccsds.org/Pubs/355x1b1.pdf
Between the two books above. It appears that a security association should have up to two keys associated within. Encryption/Authentication. These keys should follow typical initialization methods, and should only be associated with one security association. There are several should suggestions as to their use not exceeding specific lifetimes, but is not a "shall" enforce.
TLDR: Keys are associated with specific security associations, and shall not be reused for anything outside of their initial setup. After this lifecycle, keys should be decommissioned and destroyed. New keys can be uploaded through the use of a Master Key.
Currently no controls to restrict this in the SA, or Key management. Should this be something that SA's control, or should there be a new parameter that is added to the keys for associations?
This is now setup, and able to be enabled, but is off by default. May require one more pass in the future.