Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key Mapping #198

Closed
jlucas9 opened this issue Sep 11, 2023 · 4 comments
Closed

Key Mapping #198

jlucas9 opened this issue Sep 11, 2023 · 4 comments
Assignees
Labels
cmp NASA GSFC CMP

Comments

@jlucas9
Copy link
Collaborator

jlucas9 commented Sep 11, 2023

Should a single key only map to a specific security association?
Document this per the standard as well as how it's currently implemented.

@jlucas9 jlucas9 added the cmp NASA GSFC CMP label Sep 11, 2023
@jlucas9 jlucas9 self-assigned this Sep 11, 2023
@rjbrown2
Copy link
Member

rjbrown2 commented Oct 6, 2023

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-The�Air-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.

@rjbrown2
Copy link
Member

rjbrown2 commented Oct 6, 2023

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.

@rjbrown2
Copy link
Member

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?

@rjbrown2
Copy link
Member

This is now setup, and able to be enabled, but is off by default. May require one more pass in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmp NASA GSFC CMP
Projects
Archived in project
Development

No branches or pull requests

2 participants