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 protected] [mailto:[email protected]] 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 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 protected] [mailto:[email protected]] 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, 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 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 protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
