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

From: "Novikov, Lev" <[email-masked]>
Date: Thu, 15 Apr 2010 10:05:08 -0400

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

---

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 23 Apr 2010 13:02:30 -0400

Joe,

I looked at:

- ISO/IEC 27000 "Information technology - Security techniques -

  Information security management systems - Overview and vocabulary"

- NIST SP 800-12 "An Introduction to Computer Security: The NIST Handbook"

- NIST SP 800-33 "Underlying Technical Models for Information Technology Security"

While the first two define security-related terms, they don't exactly address the notion of a logical model, per se. (Unless I'm misunderstanding something.)

** Was there a different ISO 27000 document to which you were referring?

SP 800-33 has a model, but it relates the desired types system services (e.g., identification, confidentiality) to their roles (prevent, recover, support).

Nonetheless, it does have define "security domain," so it may be relevant.

** Anybody know of other documents that define logical models for crypto devices?

Lev

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

From: [email-masked] [mailto:[email-masked]]

Sent: Thursday, April 15, 2010 12:56 PM

To: Novikov, Lev; [email-masked]; IETF-CICM

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

ISO 27000 and NIST-800 give FIPS 140-2 comrehensive IA scope, particularly the IA architecture of 27k.  -2 predates 27k and in some sense motivated it, so I would want to extract the architecture context from 27k and base an axiomatic framework on that.

  Neither 27k nor -800 is ideal since they don't specify hardware properties comprehensively enough to base a logical model on it and don't treat computing-communications as interwoven threads of what really is a whole cloth comput-ications fabric.

  But its a better starting point than 140-2 (which is being replaced by -3)

- joe

Distinguished Professor Joseph Mitola III, Fellow of the IEEE

Stevens Institute of Technology