Subject: [pkix] Secure Messaging in PKIX enrollment protocols

From: Anders Rundgren <[email-masked]>
Date: Sat, 02 Apr 2011 20:06:12 +0200

Since PIN deployment to issued credentials to my surprise apparently
already is fully featured in existing PKIX protocols (although nobody has
bothered with providing a reference), I continue with the next important
feature:  Secure Messaging.

For those who are not yet up to speed on this topic, Secure Messaging
was pioneered by ISO in 7816, and later enhanced by Global Platform.

http://www.opensc-project.org/opensc/wiki/SecureMessaging

The principle is quite simple: The issuer and the cryptographic container
in some way establish a shared session secret which is used in an arbitrary
number of subsequent steps to MAC and/or encrypt data in both directions.

The power of this concept are plentiful:
- You know that the generated keys actually reside in the crypto module

- You can through use of a session perform a multi-step enrollment
  as a transaction.  It either succeeds or leave the crypto module intact.

- It becomes very simple to exchange secret data like PIN-codes or
  perform backup of private keys.

So, is secure messaging also supported by CMP or CMC?

Anders

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 13:39:24 -0400

>http://www.opensc-project.org/opensc/wiki/SecureMessaging

According to the home page "OpenSC provides a set of libraries and 
utilities to work with smart cards."  So, this terminology is smart 
card-specfic.

>So, is secure messaging also supported by CMP or CMC?

CMC and CMP were not targeting smart cards. They did meet a 
requirement to support staged delivery communication with an issuer, 
as that was viewed as
an important requirement.  Thus it seems unlikely that they would offer a model
that relies on realtime communications with an issuer.

Steve

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 12:38:55 -0600

> So, is secure messaging also supported by CMP or CMC?

CMC uses message layer security and does not directly support this concept.

The EST draft uses a TLS session to protect all traffic. This is effectively what
you describe -- if the cryptographic container has an appropriate credential for 
establishing the TLS connection "shared session secret" then any subsequent 
communication is protected by this secret. It sounds like you are concerned that the
cryptographic container be what establishes this connection -- in which case TLS
would be a reasonable protocol to be implemented by the cryptographic container. 

- max

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

---

From: max pritikin <[email-masked]>
Date: Mon, 4 Apr 2011 12:58:48 -0600

- max

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 4 Apr 2011 16:06:08 -0400

"Secure Messaging" is an unfortunate choice of terms, since the concept described in the wiki ...

    •Provide a possibility of different SM session initialization modes and SM session lifetimes 
        ◦initialized at card connection, valid until card is disconnected 
        ◦initialized when SM protected ACL is encountered, valid during the small number of transactions

... is "session".  The concept of secure sessions didn't originate with Global Platform; the whole idea behind SSL/TLS and IPSec is to establish session keys that are used to protect data exchanged within that session.

Messaging involves discrete messages (APDUs) that may be, but are not necessarily, carried within a single session.  The assumption is that they are not, as in SMTP, S/MIME, or http://www.disa.mil/nces/m2m.html: "Its guaranteed delivery to disconnected applications ensures that messages are delivered."

Secure Messaging should provide security for messages.  Since Global Platform SM addresses only the simple (connected) case and ignores the more difficult (connectionless) case, that technology should be qualified as "GP SM" or "Session-based SM" when the context is messaging in general.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 04 Apr 2011 22:39:39 +0200

On 2011-04-04 20:58, max pritikin wrote:
<snip>

> would be a reasonable protocol to be implemented by the cryptographic container. 

At a 50000 ft level this sounds reasonable; at the ground level
it looks quite different.  In *my* take on secure messaging a
"semi-trusted proxy" does all the "heavy lifting" as well as
allowing user interaction.  The latter would be impossible
in a true TLS session and the former would be a poor use of
"trusted silicon".  By using a "TLS-inspired" scheme the net
result became a simple but still quite capable crypto container:

http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/sks/test/SKSReferenceImplementation.java

supported by a rather nice high-level protocol:

http://webpki.org/papers/keygen2/sks-api-arch.pdf#page=31

GlobalPlatform haven't released their enrollment specs yet,
only the API (APDUs).

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Apr 2011 18:44:51 +1200

Stephen Kent <[email-masked]> writes:

>CMC and CMP were not targeting smart cards.

They aren't?  Two of my major (known) users of CMP are using it to provision
crypto devices.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 06 Apr 2011 09:35:54 +0200

> They aren't?  Two of my major (known) users of CMP are using it to provision

This is where things get confusing since both statements are correct
depending on what you actually mean by an "enrollment protocol".

Existing PKIX enrollment protocols are indeed used for deploying
credentials to smart cards.  However, card management systems only
use the enrollment protocols for the certificate part which is just
one step in a card personalizing process.  Things like PIN deployment
(in another lingo: setting the user's PIN in the token) is usually
dealt with through entirely proprietary methods and software.

The (maybe fluffy term) "Secure Messaging" is a way to do *all*
card/token operations though a protocol.

Secure Message is great but requires very detailed knowledge
of the container since *every low-level API method must have a
direct counterpart in the protocol*.  Due to this I as well as
TrustedComputingGroup have found that the only reasonable way
to succeed with Secure Messaging is defining a standard token
and associated protocols down to the bit-level.

IMO, this part is the one which will be the biggest hurdle
since a protocol that supports both the the "old" (established)
and the "new" (promising) way will make CMP look quite simple :-)

Anyway, I haven't heard (it is in fact my line of work..) that
card management systems actually *need* a new system while mobile
devices and consumer tokens do.  Secure Messaging is the way the
smart card industry is going.

Anders

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 6 Apr 2011 01:05:43 -0700 (Pacific Daylight Time)

Use PKIX-structured (though not current PKIX-policy) certificates as containers for both (1) the issuer's requirements and entropy-provision for the supplicant's key generation process, and (2) the token's assertion of the generation circumstances of the key in the included CSR, including a hash of the entropy that the issuer provided and the protection characteristics of the private key.

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 11:10:51 -0400

>They aren't?  Two of my major (known) users of CMP are using it to provision

the fact that these protocols are useable with smart cards, today, does
not contradict my comment. When these protocols were developed (2000) 
smart cards were pretty wimpy in terms of processor and memory 
capabilities. We
did not try to create protocols, or profiles thereof, that were likely to
be easy to implement in such constrained environments.

Steve

---

From: max pritikin <[email-masked]>
Date: Thu, 7 Apr 2011 16:40:44 -0700

Anders,

I'm not convinced, but then I'm not sure what you are asking yet. It is possible to put this into the form of (P)roposed requirement:

P1) Are you suggesting that the certificate enrollment protocol also support a method for the secure distribution of arbitrary message/policy objects? For example some form of "here is the generic policy blob that goes with this credential"?

If so are you suggesting that the encoding of this blob is in scope? Or is it sufficient to simply offer a delivery channel?

Does it matter if this blob is sent *before* the PKCS#10/CRMF is formed or is it independent? 

Or do you mean something else?

Thanks,

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 08 Apr 2011 07:36:24 +0200

On 2011-04-08 01:40, max pritikin wrote:
> 
> Anders,
> 
> I'm not convinced, but then I'm not sure what you are asking yet.

Max,

I'm basically listing various enrollment protocol options.
SM is a diametrically different take on the entire enrollment
issue.  SM has as most technical solutions pros and cons.

Pro - Supports secure (and robust) *multiphase* processes
Con - Requires 1-2-1 correspondence between protocol and API

In *my* project which is targeting the billion+ users of mobile
devices as well as "tokens", I recently slashed the original
Y2007 design and replaced it with a scheme based on SM.

The "Con" is IMO a "Pro" because it will make interoperability
much easier and cheaper.  It will also enable the "White label"
token concept that IMO is a prerequisite for large-scale use of
strong authentication like NSTIC.

> It is possible to put this into the form of (P)roposed requirement:

Here we get into some specifics and the only thing I can do is
really describe what I have done and why.  Other efforts must do
their choices.

> P1) Are you suggesting that the certificate enrollment 
> protocol also support a method for the secure distribution
> of arbitrary message/policy objects?

That is the cool thing with SM; you can transfer whatever you
feel appropriate under a common security context requiring
very little overhead.  In a typical KeyGen2/SKS enrollment you
typically perform seven(!) distinct signature/MAC operations.

> For example some form of "here is the generic policy blob
> that goes with this credential"?

In SKS a there are PIN and PUK policy objects.  To the key
creation method there is a bunch of policy attributes like
endorsed algorithms, export options etc.

> If so are you suggesting that the encoding of this blob
> is in scope? Or is it sufficient to simply offer a delivery channel?

Since my proposal is not about creating a protocol, but about
creating a complete token ecosystem, I have defined policy down
to the bit-level.  However, there is an option for "opaque"
typed blobs that could be used for policy although my intention
was really providing credential attribute data like VPN
configuration, Information Card support, and through a variant
of the attribute blob scheme, Logotypes.

> formed or is it independent?

In my proposal all data "hangs" on the key and certificate so
all but the PIN and PUK policy objects must be sent *after*.

Note that SKS does not use CSRs, it creates container-attested
keys on the issuer's request.  Nothing prevents you from making
a container-attested PKCS #10, I just didn't see the point.

If I were to upgrade this scheme to for example making it a
better fit to routers, I would insert (in the protocol) the
router-originated data *before* the actual SM process was
invoked.  In an SM scheme, client-originated certification
data shouldn't be created by the container; it only should
only vouch for things is actually *knows* and do the crypto.

> Or do you mean something else?

I have already said too much :-)

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 08 Apr 2011 09:09:01 +0200

Max,
I have given this topic a bit more thought and here is
what I'm *considering*:

Issuer request.  Unmodified:

<KeyCreationRequest Algorithm="http://xmlns.webpki.org/keygen2/1.0#algorithm.sks.k1"  …  >
  <KeyEntry ID="Key.1" AppUsage="authentication" MAC="gSg4chh ... H2BEE7=">
    <RSA KeySize="2048"/>
  </KeyEntry>
</KeyCreationRequest>

Client (container) response.  Original:

<KeyCreationResponse  …  >
  <PublicKey ID="Key.1" Attestation="TbergHftrm8rRL … wyTvPX2XoMunJ==">
    <ds:RSAKeyValue>
      <ds:Modulus>ALhBpUjJK/mSjPAe/ … fXG8z1V3mVDZTBM7eZ</ds:Modulus>
      <ds:Exponent>AQAB</ds:Exponent>
    </ds:RSAKeyValue>
  </PublicKey>
</KeyCreationResponse>

Client (container) response with "PKCS #10-like" certification data option:

<KeyCreationResponse  …  >
  <PublicKey ID="Key.1" Attestation="TbergHftrm8rRL … wyTvPX2XoMunJ==">
    <ds:RSAKeyValue>
      <ds:Modulus>ALhBpUjJK/mSjPAe/ … fXG8z1V3mVDZTBM7eZ</ds:Modulus>
      <ds:Exponent>AQAB</ds:Exponent>
    </ds:RSAKeyValue>
  <CertificationData SubjectDN="CN=I'm a router">
     <CertificateAttribute TBD/>
  </CertificationData>
  </PublicKey>
</KeyCreationResponse>

A die-hard PKIXer would probably reject this arrangement but it
works just fine while keeping all the goodies of the SM scheme.
Note that Attestation still only covers the key, not CertificationData .

Anyway, the whole KeyCreationResponse message could in this case be
signed by an external SM-signature which is already a part of SKS.
There is no need for using private keys for this purpose.
As a "bonus" you get rid of awkward PIN requests during enrollment
as well as the s.c. "misuse" of encryption keys.

Anders