Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system?

From: "Fitton, John" <[email-masked]>
Date: Wed, 16 Jun 2010 14:35:37 -0400

>From a security design perspective one can envision the need to protect all control functions which would seem to favor "red side" control. However in the software radio world some of the waveform (air interface) applications need to have some of the control  API's present on the "black side" and others on the "red" with others on both sides. While most control functions are unclassified, some may need to handle classified configuration data.

 From my experience base, I believe that the API functions should be agnostic as to whether or not they are red or black side because typically they will be on the side that needs them and this is a function of the security architecture.  I think the model to consider is as follows because it eliminates red/black terminology which is typically misused. 

 Consider a MILS (Multiple Independent Levels of Security) environment using a high assurance separation kernel in which all domains share the same processor, each in their own partition, and the OS maintains the required separation between the partitions.  One of the partitions could even be a 100% software based crypto. The system would include "Reference Monitor" functions to support cross domain communications to the extent that these are required and allowed. In this environment, the terms red and black are indeed meaningless from an API perspective. 

In a high assurance environment which employs machine interpretable explicit security policy statements, the security policy for a given application/waveform could define the rule set that specifies which API's are available in what is typically the "plaintext" space vs. the "cipher text" space.

  I use the word "typically" because the in the JTRS Software Communications Architecture Security Services API (note: the API was subsequently withdrawn from the SCA), if you recall, supported encrypting data and returning the cipher text back to the same side from which the plaintext was submitted.  There is also an interesting notion that one could take unclassified data and store it in a protected "red side" database containing classified data by encrypting it from "black to red" and when retrieving it siply decrypt it from "red to black".  This process completely avoids the need for bypass and write-up/down operations which are typically hard to do in this kind of situation.

John Fitton

Harris Fellow, Senior Scientist

Harris RF Communications

---

From: "Lanz, Dan" <[email-masked]>
Date: Wed, 16 Jun 2010 16:05:25 -0400

John,

I tend to agree.  My concern is that whatever allocation of specific functions to either the "red" or "black" sides we devised would inevitably result in choices that would not work for certain architectures. I think realistically we would have to allocate a large proportion of the functions to "both" sides, significantly reducing the value of the allocation exercise.

As I stated in an earlier post, I think there is a good compromise here.  The CICM specification requires a crypto vendor shipping a CICM-conformant library to list those functions that were implemented to a medium level of granularity (see the CICM "Conformance" section).  The compromise is to make the following changes: 1) increase the granularity of the functions listed in the conformance section so every CICM function is listed and 2) require that, in addition to stating whether the function is implemented or not, state whether the function is available on the red, black, or both sides.

Does this seem reasonable? 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fitton, John
Sent: Wednesday, June 16, 2010 2:36 PM
To: [email-masked]
Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system?

John Fitton

Harris RF Communications

_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Linn, Charles" <[email-masked]>
Date: Tue, 22 Jun 2010 14:10:57 -0400

Hopefully not to get hung up on a technicality, but... Is CICM
specifying a) an API, b) a set of APIs or c) a component?  Coming at
things from the JTRS world, APIs themselves are not designated to a
"side".  Rather, a component, which is itself resident in a security
enclave implements (supports) one or more APIs.  JTRS specifies APIs,
and leaves it to particular platforms to determine how components are
structured to use those APIs.  Perfect? No.  Compromise?  Yes.
Practical - I think so.

This brings up a challenge for CICM, due to its OO nature, including the
ability to (through iteration) get a large number of manipulation
ability though base interfaces, e.g. CryptoModule.  This potentially
flies in the face, or at least requires some creativity, to apply
least-privilege principles.  For example, lets say you want to give a
given component ability to encrypt, but not perform other functions - we
need to think about how this could be done, if not in the API, than in
runtime behavior.

I agree with others that you cannot "pin" any given functions to a red,
black, or (any color, ha ha) side.  This is going to be a function of
the security requirements for any given platform.  The best you can do
is to provide a reasonable set of groupings of functions.  In this way,
individual implementations can support different combinations at
different security levels (including the same interface present in
multiple locations) as they see fit, while maintaining reasonable
least-privilege access limitations.

Hope this helps,
Chuck Linn