DSC-iTC / cPP

Dedicated Security Components cPP & SD
MIT License
3 stars 3 forks source link

Critical Security Parameters #263

Open jvdsn opened 4 months ago

jvdsn commented 4 months ago

In the cPP, a "Security Data Element" is defined as "A Critical Security Parameter, such as a cryptographic key or authorization token." This seems to imply that they are synonyms. However, on the last call @slpotte mentioned that they are not synonyms, but that one term is more general (I don't exactly remember which).

I don't think it is desirable to introduce too much technology which may confuse readers. Currently, the term "SDE" is used far more throughout the cPP and the SD than the term "CSP". "CSP" is not used at all in the SD (though it is defined in the glossary). Perhaps it should be considered to replace the occurrences of "CSP" and "Critical Security Parameter" with more generic terminology, like "sensitive data". Below are the current occurences:

"Key Reference Model" section:

Such a protocol of challenges and responses may generate and use ephemeral authorization tokens, which would be one form of critical security parameter (CSP). The DSC may have to switch session contexts in and out of the DSC to external temporary storage, which necessitates the protection of these CSPs. Such a session context is one type of SDO.

This cPP covers several different types of storage locations for keys and critical security parameters (CSPs) such as authentication tokens. Some DSCs may have a generous amount of protected storage internal to themselves, which allows it to accommodate all keys and CSPs in operational use, whether the DSC is performing operations to administer itself or operations on behalf of users. Other DSCs may have a minimal amount of protected storage locations with just enough to accommodate root keys along with a limited number of operational keys and CSPs for user authorized sessions.

For those cases in which the DSC relies on storage external to itself to accommodate all the keys and CSPs on which applications expect it to operate, it will either have to support secure channels to another DSC with a more generous allocation of protected storage locations, or use a series of wrapping keys to protect private keys and CSPs while outside of the DSC.

In the previous section on protected storage locations, a DSC may have to use storage external to itself. In these cases, an SDO of a wrapped key may contain a number of important attributes, such as a pointer to its parent, authorization values, and other indications of the functions allowed (encrypt vs. sign). Alternatively, some or all attributes may be implied, which means that only the keys or CSPs themselves exist outside the DSC. In either case, the sensitive values, such as private keys, secret keys, and CSPs, should be encrypted when outside the DSC. The parent of these objects are either intermediate wrapping keys, or encrypting root keys.

FCS_CKM.6.2:

... [.underline]#[_assignment: some value that does not contain any CSP_]],#

... [.underline]#single overwrite consisting of [selection: zeroes, ones, pseudo-random pattern, a new value of a key of the same size, [_assignment: some value that does not contain any CSP_]],#

_Some selections allow assignment of "some value that does not contain any CSP." This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBGEXT requirements, and not being any of the particular values listed as other selection options. The point of the phrase "does not contain any sensitive data" is to ensure that the overwritten data is carefully selected, and not taken from a general pool that might contain data that itself requires confidentiality protection.

Note that the last paragraph is inconsistent (emphasis).

Glossary:

(As defined by [GP_ROT]) The RoT for Integrity maintains shielded locations for the purpose of storing and protecting the integrity of non-secret critical security parameters and platform characteristics. Critical security parameters include, but are not limited to, authorization values, public keys, and public key certificates.

Possible suggestions for replacing the terminology, if so desired: "SDE" (where it makes sense) or "sensitive data".

@woodbe pointed out that "GP_ROT document should also be consulted for the CSP definition as we are using that definition for RoT straight from their reference."

slpotte commented 4 months ago

Joachim,

I understand your concern about introducing new terms. However, FCS_CKM.6.2 is maintained by the FDE ITC. This wording is used in the CCDB CWG crypto catalog. I'm agreeable to changing it in all the other places. Please send feedback to the FDE ITC and CCDB CWG.

Stan


From: Joachim Vandersmissen @.> Sent: Sunday, April 14, 2024 10:29 PM To: DSC-iTC/cPP @.> Cc: Stanley Potter (GOV) @.>; Mention @.> Subject: [DSC-iTC/cPP] Critical Security Parameters (Issue #263)

In the cPP, a "Security Data Element" is defined as "A Critical Security Parameter, such as a cryptographic key or authorization token." This seems to imply that they are synonyms. However, on the last call @slpottehttps://github.com/slpotte mentioned that they are not synonyms, but that one term is more general (I don't exactly remember which).

I don't think it is desirable to introduce too much technology which may confuse readers. Currently, the term "SDE" is used far more throughout the cPP and the SD than the term "CSP". "CSP" is not used at all in the SD (though it is defined in the glossary). Perhaps it should be considered to replace the occurrences of "CSP" and "Critical Security Parameter" with more generic terminology, like "sensitive data". Below are the current occurences:

"Key Reference Model" section:

Such a protocol of challenges and responses may generate and use ephemeral authorization tokens, which would be one form of critical security parameter (CSP). The DSC may have to switch session contexts in and out of the DSC to external temporary storage, which necessitates the protection of these CSPs. Such a session context is one type of SDO.

This cPP covers several different types of storage locations for keys and critical security parameters (CSPs) such as authentication tokens. Some DSCs may have a generous amount of protected storage internal to themselves, which allows it to accommodate all keys and CSPs in operational use, whether the DSC is performing operations to administer itself or operations on behalf of users. Other DSCs may have a minimal amount of protected storage locations with just enough to accommodate root keys along with a limited number of operational keys and CSPs for user authorized sessions.

For those cases in which the DSC relies on storage external to itself to accommodate all the keys and CSPs on which applications expect it to operate, it will either have to support secure channels to another DSC with a more generous allocation of protected storage locations, or use a series of wrapping keys to protect private keys and CSPs while outside of the DSC.

In the previous section on protected storage locations, a DSC may have to use storage external to itself. In these cases, an SDO of a wrapped key may contain a number of important attributes, such as a pointer to its parent, authorization values, and other indications of the functions allowed (encrypt vs. sign). Alternatively, some or all attributes may be implied, which means that only the keys or CSPs themselves exist outside the DSC. In either case, the sensitive values, such as private keys, secret keys, and CSPs, should be encrypted when outside the DSC. The parent of these objects are either intermediate wrapping keys, or encrypting root keys.

FCS_CKM.6.2:

... [.underline]#[assignment: some value that does not contain any CSP]],#

... [.underline]#single overwrite consisting of [selection: zeroes, ones, pseudo-random pattern, a new value of a key of the same size, [assignment: some value that does not contain any CSP]],#

Some selections allow assignment of "some value that does not contain any CSP." This means that the TOE uses some specified data not drawn from an RBG meeting FCS_RBG_EXT requirements, and not being any of the particular values listed as other selection options. The point of the phrase "does not contain any sensitive data" is to ensure that the overwritten data is carefully selected, and not taken from a general pool that might contain data that itself requires confidentiality protection.

Note that the last paragraph is inconsistent (emphasis).

Glossary:

(As defined by [GP_ROT]) The RoT for Integrity maintains shielded locations for the purpose of storing and protecting the integrity of non-secret critical security parameters and platform characteristics. Critical security parameters include, but are not limited to, authorization values, public keys, and public key certificates.

Possible suggestions for replacing the terminology, if so desired: "SDE" (where it makes sense) or "sensitive data".

@woodbehttps://github.com/woodbe pointed out that "GP_ROT document should also be consulted for the CSP definition as we are using that definition for RoT straight from their reference."

— Reply to this email directly, view it on GitHubhttps://github.com/DSC-iTC/cPP/issues/263, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AXWW7PPBQCFS5NVAW2LLGI3Y5M3QBAVCNFSM6AAAAABGGOMXA2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2DENJWHA3TIMI. You are receiving this because you were mentioned.Message ID: @.***>