Re: FCS_COP and FCS_CKM interdependency

["Dr.Ir. D.J. Out" <out@itsef.tno.nl>]

> Now that the topic has been brought up, I believe that the dependencies for
> the FCS class of requirements are not correct. 
> 
> In particular, dependency on secure security attributes (FMT_MSA.2)
> certainly has nothing to do with key destruction (FCS_CKM.4) and it also
> isn't necessary for most cryptographic operations (FCS_COP). I am also not
> sure that key generation (FCS_CKM.1) should depend on FMT_MSA.2 since the
> generated keys aren't necessarily based on the acceptance of "secure
> attributes" but rather could be based on random or other pre-existing data. 
> Note that the FMT_MSA.2 dependencies of all of the FCS class components
> yield a problem in that FMT_MSA.2 is dependent on either an access control
> or information flow policy. However, encryption seems valid without either
> policy (e.g., encrypting the backing store to prevent scavenging or
> encrypting tunnels to prevent disclosure of flows without actually control
> the flow of information). It is also not clear why key generation
> (FCS_CKM.1) or cryptographic operations (FCS_COP) are dependent on key
> destruction (FCS_CKM.4).

This also ties in with the issue:
- do you consider the keys in your TOE to be user data (in which case 
access control on them and secure attributes seem in order)
- or TSF data (in which case it is also misty, since it is unclear to me 
how you specify the "access control" on TSF data using CC part 2)

and this distinction (user data or TSF data) completely depends on what 
your TOE is using the cryptography for: services to users or internal stuff

> I tend to think generally that key generation has no dependencies and
> cryptographic operations and key destruction depend only on key generation.
> If it is believed that key generation needs some support, then FMT_MSA.2 is
> not it; especially since that requirement is problematic in itself since it
> doesn't support an assignment to narrow the scope of applicable attributes.

Additionally FMT_MSA.2 is circular:
- It has a dependency on ADV_SPM
- SPM should therefore tell you "What is secure"
- But SPM is a model of the TSP
- The TSP is the sum of all SFRs (which include FMT_MSA.2)

> Furthermore, the dependencies in class FCS are generally more extensive and
> less obviously related that most of the other CC Part 2-defined
> dependencies. For example, other requirements include only direct
> dependencies while these requirements appear to include some indirect
> dependencies.

 > The point is that all of the dependencies in the FCS class should be
 > revisited. They should really be necessary and they should be consistent
 > with the rest of the dependencies in Part 2.
 >

Applying Occam's Razor "Why improve something when you can also delete it?"

I have severe doubts on whether FCS should be in Part 2 at all.

The COP requirements are very implementation dependent. They tell you to 
"use this algorithm". All other SFRs are implementation-independent. 
They tell you "What gets done" rather than "How to do it"

FCS_COP does not fit in well there. Additionally, there are sufficient 
implementation-independent requirements to specify "Why you are using 
crypto" instead of "which crypto to use".

For "I need to encrypt between A and B" you should use FDP_UCT
For "I need to encrypt internally, FDP_ITT"
For "I need to use hashes to store my stuff, FDP_SDI"
For "I need to sign stuff, FDP_DAU"
etc.

The CKM components are superfluous to others in Part 2
- FCS_CKM.1 is basically a variant of FIA_SOS.2
- FCS_CKM.2  and 3 can be modelled though FDP_ACC plus dependencies
- FCS_CKM.4 can be handled by FDP_RIP or FDP_ETC

All that remains is "How do I then specify that the TOE needs to do 3DES 
and not AES", but this is the same question as "How do I specify that my 
TOE does TCP/IP instead of X.25" or "How do I specify that my TOE runs 
on 110V instead of 220V" and the answer to that is "assessing compliance 
with external standards is not done through CC"

I think that the FCS criteria have a special status from history (back 
from the days when "security equals cryptography") Right now they do not 
fit very well in Part 2.

Dirk-Jan

>>-----Original Message-----
>>From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of Nir Naaman
>>Sent: Tuesday, February 24, 2004 7:46 AM
>>To: Multiple recipients of list
>>Subject: RE: FCS_COP and FCS_CKM interdependency
>>
>>
>>It is.
>>Dependencies for FCS_COP.1 are listed in CC Part 2 as:
>>
>>Dependencies: [FDP_ITC.1 Import of user data without security 
>>attributes or FCS_CKM.1 Cryptographic key generation]
>>	          FCS_CKM.4 Cryptographic key destruction
>>                      FMT_MSA.2 Secure security attributes
>>
>>    Nir
>>
>>
>>>-----Original Message-----
>>>From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
>>>Magos×'nyi Ö±rp×'d
>>>Sent: Tuesday, February 24, 2004 1:29 PM
>>>To: Multiple recipients of list
>>>Subject: FCS_COP and FCS_CKM interdependency
>>>
>>>
>>>
>>>Hi!
>>>
>>>Isn't FCS_COP dependent on FCS_CKM?
>>>How can one use crypto securely without managing the keys?
>>>
>>>--
>>>GNU GPL: csak tiszta forrásból
>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



-- 
TNO ITSEF BV
P.O. Box 96864          tel +31 70 374 0304
2509 JG The Hague       fax +31 70 374 0651
The Netherlands         www.commoncriteria.nl