RE: FCS_COP and FCS_CKM interdependency

["Janardhana Pulugurtha" <jpulugurtha@corsec.com>]

Hello All,

Let me share my thoughts on our view of FMT_MSA.2 dependency on FCS_CKM.1.

Key Generation - MSA.2 dependency:
----------------------------------

FMT_MSA.2 talks about the "Secure Security Attributes".
"Secure security attributes ensures that values assigned to security
attributes are valid with respect to the secure state. The definition of what "secure" means is left to the TOE guidance and the TSP model. "

"An example could be that if a user account is created, it should have a non-trivial password."

On Similar lines if a Key is created it should be non-trivial. In other words taking another look at FCS_CKM.1:
" FCS_CKM.1 Cryptographic key generation requires cryptographic keys to be
generated in accordance with a specified algorithm and key sizes which can be based on an assigned standard."

Here the parameters for SECURE VALUES FOR SECURITY ATTRIBUTES  could be 
only a particular algorithm set or a minimum key size etc. A more specific example could be that a TOE should not accept less than key size of 512 
( secure value ) for a particular algorithm ( secure value ).

More examples of Secure Value attributes could include a subset of key type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption, key agreement, data encryption).

>>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.


Secondly FMT_MSA.2 dependency on either an access control
---------------------------------------------------------
or information flow policy:
---------------------------

I personally feel that a dependency creep should be followed only until a certain point where it would make more sense (i.e. case by case (dependency by dependency) basis considering the origin of the dependency).



>>"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."

I totally agree with you on this.

If the same product undergoing CC validation uses a crypto module for its crypto operations that has  FIPS 140-2 cert and is operated in a FIPS mode then I feel FCS_COP.1, FCS_CKM.1, FCS_CKM.4 and also FMT_MSA.2 are taken care of.

-Sai

----------------------
Sai Pulugurtha
Corsec Security Inc.
10340 Democracy Lane
Suite 201
Fairfax, VA 22030

Tel (703) 267-6050 x119
Fax (703) 267-6810
http://www.corsec.com
 

-----Original Message-----
From: Arnold, James L. Jr. [mailto:JAMES.L.ARNOLD.JR@saic.com] 
Sent: Tuesday, February 24, 2004 9:05 AM
To: Multiple recipients of list
Subject: RE: FCS_COP and FCS_CKM interdependency



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).

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.
Rather, I think this is a case for a considered management requirement as
opposed to a dependency.

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.

> -----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
> >
> >
> >
> >
> 
> 
>