Subject: Re: [cicm] Logical Model, PKCS#11 & FIPS-140-2

From: "Ludovic JACQUIN" <[email-masked]>
Date: Tue, 4 May 2010 16:32:13 +0200

Hello,

A few comments concerning your high assurance environment example,
and based on our experience on the domain:

** Concerning point 2:
It is possible for the cryptographic module to neither return to the
calling application nor to send it to a remote peer. For instance
entity A can ask the cryptographic module to perform encryption, this
module will pass the result to B (without A knowing it) which will
finally send it to the remote peer. That's for the outgoing flow.
This is the most general case we can imagine, other cases are
particular instantiations (e.g. with the classic API, A and B are
the same entity).

Of course, the case of the incoming flow is a little bit different,
but still involves the same A, B and the cryptographic module.

** Concerning point 3:
Yes, there are several applications, some of them focusing on
end-to-end administrative aspects (setup of the communication channel
with the peer), or local administrative aspects (initialization of
the cryptographic device, and to let the device inform the supervising
application of its state), and others on the actual data flow
operations (encryption/decryption).

** Another comment. Domain separation is preferably done at the
hardware level: plaintext and ciphertext are sent on different
buses, stored on different memories, processed by different processing
units (CPUs or FPGA). If not possible, this separation can be done
logically, within the OS, using different security domains, with
the drawback of introducing additional security risks.

Cheers,

   Ludovic and Vincent

> During the discussion at IETF 77, the following point was raised several
> times:
>
> Why can't we use PKCS#11? Alternatively: In what way does the model of a
> high assurance environment differ from the model put forth by FIPS-140-2
> and used by PKCS#11?
>
> First, it seems that FIPS-140-2 does not specify any sort of logical
> model, rather it mandates the use of certain algorithms and different
> levels of tamper resistance/evidence. Moreover, PKCS#11 never references
> FIPS-140-2.
>
> ** Is that a correct reading of FIPS-140-2 & PKCS#11?
>
> Nonetheless, it appears that FIPS-140-2 would be a good informative
> reference for terminology and SHOULD be referenced throughout CICM
> (perhaps in the -01 draft).
>
> ** Are there any downsides to doing that? Does anyone know of other
> documents (perhaps from other countries) that we could use that define
> similar terminology?
>
> Second, I'm working on a short, informative document to try and capture
> how the model of a high assurance environment differs from existing
> models, but, for now, here's a brief notional example:
>
> 1. Existing APIs (e.g., PKCS#11, Microsoft CAPI, etc.) assume that an
> application uses a cryptographic device to perform a cryptographic
> operation and that the results of that operation are returned directly to
> the calling application.
>
> 2. While this remains true for high assurance environments, it is a rare
> use case. More commonly, an application uses a device to perform a
> cryptographic operation where the results of that operation are sent
> directly to a remote peer (with whom a connection was previously
> established).
>
> 3. It should be noted that, occasionally, the responsibilities between (A)
> configuring the device (i.e. establishing the connection and which
> operation should be performed) and (B) performing the operation are
> accomplished by two different applications.
>
> Note that uses 2 & 3 reflect the notion of domain separation that figures
> prominently in high assurance environments, specifically, in a large class
> of existing devices that are unlikely to change in the foreseeable future.
>
> ** Does this capture domain separation accurately? What are other
> fundamental differences?
>
> Lev
> _______________________________________________
> cicm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cicm
>

---

From: "Novikov, Lev" <[email-masked]>
Date: Sat, 15 May 2010 23:34:19 -0400

Ludovic & Vincent,

Thanks for your comments. I just wanted to reflect on your last point:

> Domain separation is preferably done at the hardware level...

Indeed, that is a critical component of domain separation. However,
since CICM doesn't specify hardware requirements (it's a software 
interface), perhaps we should only mention that in passing when
dealing with the logical model.

* Is that sufficient, does anything else need to be specified?

Thanks,
Lev

---

From: Ludovic Jacquin <[email-masked]>
Date: Wed, 19 May 2010 10:57:36 +0200

Hello Lev,

> * Is that sufficient, does anything else need to be specified?

Yes, we agree and maybe it can be mentioned in an introductory/context
part. As we concentrate on high assurance and interface definition, this
kind of discussion may contain a TODO  and a NOT TODO list for developers
because bad implementations or usage can significantly weaken the whole
system.

Another point: Charles recently highlighted the fact that having a single
large IDL file was not recommended. There's another motivation, beyond
dead code considerations. Because of our domain separation constraint,
we largely prefer to have separate subsets of functionalities.
In our case, the cryptographic module is at the boundary between the
black domain (that manages ciphered packets, in the unsafe area) and
the red domain (that manages cleartext packts, in the safe area). And
the two security domains cannot communicate with each other directly
since the cryptographic module creates a breaking point between them.
Therefore the API (and thus the IDL) should be divided into parts that
represent the subsets of functionalities required by each security
domain.

Cheers,

    Ludovic and Vincent

---

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 21 May 2010 14:21:38 -0400

> represent the subsets of functionalities required by each security

Indeed. We accomplish this by putting each set of functionality in 
a separate namespace. (For an interactive list see: 
http://www.mitre.org/tech/cicm/html/namespaces.html)

So the suggestion, as I understand it, is to
put each namespace into its own IDL file. Correct?