Subject: [cicm] Moving Packets and Storing Identifiers (was RE: CICM Questions)

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 27 May 2011 15:46:32 -0400

Hi Girish,

On 2011-05-27 at 14:50, Girish Nanjundiah wrote:
> 1. When the function encrypt() sends a packet to the Crypto, it emerges on 
> the black side encrypted and decrypt() is expected to decrypt this encrypted
> packet. In order for the packet to be decrypted, there needs to be some 
> function that echoes the encrypted packet back through the black side. Since
> this echoing back seems to be more of an application level function than a 
> driver function, what part of the code should be responsible for echoing the
> encrypted packet back through the Crypto?

Another way of asking this question is: What functions move data from the 
remote (unprotected) side of a crypto into the local (protected) side?

See also:
"Does CICM only provide (specify) the "red" side API in a multilevel system?"
http://www.ietf.org/mail-archive/web/cicm/current/msg00014.html
http://www.ietf.org/mail-archive/web/cicm/current/msg00028.html

You correctly point out that this is not a driver-level function. In fact,
CICM does not define functions for simply moving data into the crypto. 
Therefore, you are free to use whatever transport mechanism works for you 
(e.g., POSIX socket).

> 2. When create_en/decrypt_conduit is finished executing, it needs to store 
> an identifier (just a number really) to identify the conduit it has created 
> with the Crypto. Since both of these functions only return a status and a 
> CICM::En/Decrypt::Conduit pointer, the only way to store the identifier for 
> the conduit to use is to add it as a member variable to the Conduit class. 
> If the variable is to be private, we would also need a simple public member 
> function to access it. Is there a way to update the CICM API so that we can 
> store the conduit's identifier in one of the ways I listed?

This is an interesting suggestion. We define KeyId for key identifiers, but 
we do not define a ChannelId for channel identifiers. This is because there
isn't currently a way to lookup a channel by its identifier (like there is 
for keys, modules, and tokens).

This is going to require some discussion. Normally, vendor-specific attributes
are defined by extending the CICM base object and adding those properties. 
However, it seems like a common operation to store a vendor-specific 
identifier in a CICM object to make it easy to reference the underlying object
later on.

** What do people think about extending the API to allow vendors to store a 
   single numeric value to uniquely identify the objects to the underlying 
   system?
   
Lev

---

From: "Nanjundiah, Girish" <[email-masked]>
Date: Fri, 27 May 2011 15:34:43 -0700

Hi Lev,

Thanks for the answers. In regards to the answer to the first question,
while we can define the actual mechanism to reflect back the packets
outside of the driver, the driver still needs to call the
function/mechanism that we define within its decrypt() function before
it can expect the packet to appear. Technically, this is still not
completely separated from the driver functionality. Is this still an
appropriate place to echo back black packets?

Thanks,
-Girish 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Friday, May 27, 2011 12:47 PM
To: CICM Discussion List
Subject: [cicm] Moving Packets and Storing Identifiers (was RE:
CICMQuestions)

Hi Girish,

> encrypted packet back through the Crypto?

Another way of asking this question is: What functions move data from
the 
remote (unprotected) side of a crypto into the local (protected) side?

See also:
"Does CICM only provide (specify) the "red" side API in a multilevel
system?"
http://www.ietf.org/mail-archive/web/cicm/current/msg00014.html
http://www.ietf.org/mail-archive/web/cicm/current/msg00028.html

You correctly point out that this is not a driver-level function. In
fact,
CICM does not define functions for simply moving data into the crypto. 
Therefore, you are free to use whatever transport mechanism works for
you 
(e.g., POSIX socket).

> store the conduit's identifier in one of the ways I listed?

This is an interesting suggestion. We define KeyId for key identifiers,
but 
we do not define a ChannelId for channel identifiers. This is because
there
isn't currently a way to lookup a channel by its identifier (like there
is 
for keys, modules, and tokens).

This is going to require some discussion. Normally, vendor-specific
attributes
are defined by extending the CICM base object and adding those
properties. 
However, it seems like a common operation to store a vendor-specific 
identifier in a CICM object to make it easy to reference the underlying
object
later on.

** What do people think about extending the API to allow vendors to
store a 
   single numeric value to uniquely identify the objects to the
underlying 
   system?
   
Lev
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Krishnamurthy, Hema - ES" <[email-masked]>
Date: Tue, 31 May 2011 11:21:48 -0400

I think providing a means to specify the channel ID would be useful.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Friday, May 27, 2011 12:47 PM
To: CICM Discussion List
Subject: [cicm] Moving Packets and Storing Identifiers (was RE: CICM Questions)

Hi Girish,

See also:

Lev

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

---

From: [email-masked]
Date: Tue, 31 May 2011 11:43:10 -0400

Lev (and group), 

I'm implementing the CICM driver here at L3. I'd support the concept of
extending the API to allow vendors to store a conduit identifier as a
numeric value, such as channel ID.  This allows vendors to link the
conduits created through the API to their own internal hardware-specific
attributes for the conduits.

Regards,
  Steve DiMedio
  L-3 Communications
  856-338-4204

but 
there
is 
attributes
properties. 
object
store a 
underlying

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 31 May 2011 09:37:15 -0700

All, 

This question is interesting an esoteric way, as it illustrates a point
about CICM support for high assurance (HA*).  Encrypted objects possess
security properties that are not compatible with unencrypted (or
decrypted) objects.  There are numerous other examples of objects in a
generic SDR that have security properties that are not compatible with
other objects.  

To ensure secure operation (in general) I know of at least two
alternatives.  1. Trust the application software to do right (whatever
that is), and this is repeatedly debunked, (but we still pursue it
anyway) and 2. Define "secure behavior" in a Security Policy and enforce
it by a HA OE from beneath the application SW (the only way that has
really ever really worked for HA in practice).  

Alternative 2 above implies objects with compatible security properties
need to be grouped in security domains and isolated from other
incompatible security domains by a HA OE, and the HA OE must prevent
some of the flow in some directions between some of these domains,
(allowable flow being defined by a Security Policy) including precluding
some of the "echoing" suggested by the question.  I claim there exist a
structure for security domains in generic secure SDRs that does not
require harmful flow (obviating the need to "bend rules" with CDS
guards) among security domains and this structure is required for secure
behavior.  We have a science that produces this structure.  Furthermore,
I claim guards that "sanitize" objects are not logically sound in these
cases.  (These admittedly controversial claims are supported in an IEEE
paper "On The Architecture of Secure SDRs"
<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04753440>. ) 

It seems to me our APIs support flow that we do not need in a securely
structured SDR and should not really be allowable in secure SDR OE,
whether or not it is HA.  (*HA is just a term that implies a
successfully enforced security policy.)  My concern is that when we
assume the HW view of a crypto, that is red side / black side, we lack
enough "sides" to get the SDR job done without bending the rules.  It
worked in HW cryptos that connected physically isolated functions with
physical wires but when we emulate that in SW along with additional
radio functions with APIs, we really do need APIs that bend rules.  This
gives rise to questions like this.  I am still hoping to propose a
"guidance" section for CICM on how to structure an SDR to avoid these
issues.  

So that is my opinion. 
Thanks, 
John  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nanjundiah, Girish
Sent: Friday, May 27, 2011 3:35 PM
To: CICM Discussion List
Subject: Re: [cicm] Moving Packets and Storing Identifiers (was
RE:CICMQuestions)

Hi Lev,

Thanks,
-Girish 

-----Original Message-----

Hi Girish,

See also:

This is an interesting suggestion. We define KeyId for key identifiers,
but we do not define a ChannelId for channel identifiers. This is
because isn't currently a way to lookup a channel by its identifier
(like there is for keys, modules, and tokens).

This is going to require some discussion. Normally, vendor-specific
attributes are defined by extending the CICM base object and adding
those properties. However, it seems like a common operation to store a
vendor-specific identifier in a CICM object to make it easy to reference
the underlying object later on.

Lev