Subject: [pkix] EST-02 smart card question

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Aug 2011 08:41:46 +0200

Lets say you run a small Windows-only enterprise using the latest server and client versions.

Now, assume that you want to use smart cards instead of passwords.

Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who knows all about drivers and cards.  Only government agencies would ever
/considering /buying into that.

How does EST relate to this scenario?

Anders

---

From: Max Pritikin <[email-masked]>
Date: Fri, 19 Aug 2011 11:28:16 -0600

Response inline,

On Aug 19, 2011, at 12:41 AM, Anders Rundgren wrote:

> Oops! You also need to purchase a $25 000 Forefront Identity Manager and then hire a really pricey smart card consultant who       knows all about drivers and cards.  Only government agencies would ever considering buying into that.
> 

This doesn't strike me as a technical discussion -- Microsoft's licensing/pricing policy is not based on technical protocol details. I don't work for Microsoft and am not in a good position to hypothesize about their business decisions nor do I think this is this the appropriate forum for that discussion. 

We could have an interesting discussion about the role of a consistent message from the standards community in driving interoperability amongst vendors. But that isn't technical in nature either.

The best I can offer is the observation that Microsoft's current offerings include a undocumented(?) profile of CMC combined with a non-RFC5273 related transport. Additionally Microsoft's new work includes a newer MS-WSTEP SOAP based enrollment protocol which is interesting but is also proprietary and includes dependencies on SOAP, WS-Security and WS-Trust that I think is overkill. Similarly VerSign has a web services api which is consistent with Microsoft's ideas but is not interoperable.  

Broadly, I argue that EST provides clarify regarding the existing CMC and CMC Transport options in a way that meets the requirements exposed by those non-standards based implementations and drives interoperability. I would like to work more closely with both Microsoft and Versign on their recent efforts in this area and have appreciated the conversations I've had with them about these technologies. Their input has been valuable in forming my personal opinions which helped shape the EST drafts. (Albeit with continued gaps regarding the SOAP/WS stack).  

I continue to hope that EST helps drive greater interoperability which I believe will address some of your non-technical concerns. I believe that our focus, in this forum, is to move the IETF PKIX standards forward. It is interesting to compare and understand our efforts in regards to proprietary solutions from various vendors -- and I strongly believe in working together as a community -- but ultimately some product teams are going to explore their own non-standards based solutions and we can't let ourselves be too distracted by that. 

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Aug 2011 21:02:58 +0200

Max,
You skipped the core of subject line.  How is smart card enrollment supported by EST?

Since EST-02 does not mention words like Browser, Middleware, and Tokens it is hard to believe that these items have gotten much consideration during the design.  This is nothing to get hung about
because it applies to all PKIX enrollment schemes.

However, as a person involved in smart card deployments, I don't see the point hoping that somebody else will take care of the mess created by leaving half of the enrollment infrastructure undefined.

Anders

---

From: Max Pritikin <[email-masked]>
Date: Fri, 19 Aug 2011 13:55:29 -0600

On Aug 19, 2011, at 1:02 PM, Anders Rundgren wrote:

> Max,
> You skipped the core of subject line.  

My apologies. I was unaware that you had hidden your question in the subject line and that the body of your message was extraneous. :)

> How is smart card enrollment supported by EST?

Obviously EST depends on existing cryptographic primitives which are be provided by common smartcard APIs. As such it is trivial to show that a keypair contained on a smartcard can be used in an EST exchange. As an expert in this area I suspect you are very familiar with these APIs and their capabilities so my assumption is that you have a different concern. 

I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern?

If email as a communication medium isn't working for this conversation I'd be happy to host a webex conference call with any interested attendees. Or I'd be happy to unicast my phone number to you for an offline conversation. 

- max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 19 Aug 2011 22:34:29 +0200

On 2011-08-19 21:55, Max Pritikin wrote:

> I'm wondering if your underlying concern is how the CA server can determine
> that the key is actually on the smartcard. Is this correct? Is this your concern?

Well, my #1 concern is how you can create a smart card enrollment system that
allows you to buy an empty card, insert it, go to a CA with a browser, authenticate (in
some way) and then get certificates provisioned including things like issuer-defined
PIN-codes etc.

As it appears you indeed need a smart card expert and tons of proprietary software.
Existing middleware like PKCS #11 does not support on-line provisioning so basically
the whole thing is toast unless you go far outside of the protocol.  This is probably
unacceptable to you and PKIX, which to some extent explains why there is a virtual
army of companies writing smart card middleware [primarily] for governments.

My take on this, is creating a complete system where all interfaces are defined:

                   CA => Browser => Protocol => Middleware => Container

Yes, there are User interfaces as well in layer 2-4.

Although this may look very "cardish", the design is actually targeting smart
key-stores including enhanced "soft tokens".

Will this be a "standard"?  I leave that to the market to decide :-)

Anders

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Aug 2011 17:17:52 -0400

Hi Anders - Comments in line

>some way) and then get certificates provisioned including things like issuer-defined

Generally, an empty card won't get you much.  You have to load the card with the appropriate applet or buy the card already provisioned with such applet (e.g. the CAC or PIVII applet comes with a few different cards, there's also coolkey and musclecard).

Alternately, you can get a generic card understood by a token management system that knows how to load the applet and provision the card - for something in open source, see Dogtag - the open source version of the Red Hat PKI stuff.

>the whole thing is toast unless you go far outside of the protocol.  

Strange - I've actually been able to use PKCS11 in conjunction with things like browsers to do on-line provisioning.  It really just depends on the protocol or interface you need to use to talk to the card.  Firefox for example let's you add PKCS11 drivers as security modules to the browser.  You can then use various tools to create keys and certs on the card.  For the open source play pen here I recommend Muscle and its assorted plugins including the PKCS11 musclecard driver.

Continuing on, there's a whole body of open standards on provisioning the card with applets - check out www.globalplatform.org.

To be honest, the hardest part is finding card vendors willing to sell in quantities less than 1K.

And continuing on even further - there's always PKCS15.

>This is probably

I'm really not convinced this is a PKIX issue.   It's possible that something like the Java Card 3.0 Connected spec's might actually already fit most of the bill though.

Later, Mike

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

---

From: Max Pritikin <[email-masked]>
Date: Fri, 19 Aug 2011 15:24:34 -0600

> some way) and then get certificates provisioned including things like issuer-defined

We are of course assuming that the browser/client supports EST and the smartcard itself. In which case I see no major impediment to what you describe. At most I see an issue with the distribution of policy (e.g. "issuer-defined PIN-codes") but I'm sure we can discuss appropriate methods for that.

Apparently I see the world like this:

EST Server (e.g. CA) => EST protocol => EST Client (e.g. Browser) => Smartcard

In my prototype I've focussed on the use of a general purpose web server as the server interface and am very interested in Browser support for the client. The flexibility of the browser UI as a client is of course as compelling here as it is for so many other  solutions. Still to some extent we are only defining the EST protocol so it would be extremely helpful if we could focus this conversation on protocol requirements. 

What is it about this model you've described that requires something different in the protocol? And what differences are you looking for?

>                   CA => Browser => Protocol => Middleware => Container

You appear to use a different ordering than I do and I'm not understanding your proposed stack. Are you proposing that the protocol is run on the local client and communicates between the web browser and some middleware/driver for the smartcard? I'm not seeing how that perspective helps us.

- max

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 20 Aug 2011 07:19:06 +0200

On 2011-08-19 23:24, Max Pritikin wrote:
<snip>
> EST Server (e.g. CA) => EST protocol => EST Client (e.g. Browser) => Smartcard

A problem with EST is that achieving *true end-to-end security* (which IMO is
a prerequisite), seems to require that the crypto module/smart card/etc runs
the entire protocol.

AFAICT, none of the "contenders" have such requirements.

<snip>

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 20 Aug 2011 08:26:10 +0200

On 2011-08-19 23:17, Michael StJohns wrote:

Michael, before jumping into the specifics you need to know what I'm into:

  "A universal on-line provisioning system running in browsers where
   the target keystore may reside in an external smart card, be embedded
   in (phone) hardware, or just be a part of the client platform OS"

The issuers may be banks, governments, employers, etc.  They want
to maintain their security policies also over the Internet.

Most important: the users (consumer/citizen/employee) are non-tech-savvy.

> Generally, an empty card won't get you much.  You have to load the card with the
> appropriate applet or buy the card already provisioned with such applet
> (e.g. the CAC or PIVII applet comes with a few different cards, there's also
> coolkey and musclecard).
> 
> Alternately, you can get a generic card understood by a token management system 
> that knows how to load the applet and provision the card - for something in
> open source, see Dogtag - the open source version of the Red Hat PKI stuff.

I know.  How would this help EST and/or the platform vendors?

> Strange - I've actually been able to use PKCS11 in conjunction with things like browsers 
> to do on-line provisioning.

Me too.  After having "formatted" and prepared PIN-codes etc. This has very little
in common with a scheme for end-users who have no interest/knowledge in this tech.

Anyway, PKCS #11 does not support end-to-end security for on-line provisioning so
it is (from my perspective NB...) not even a candidate.

> It really just depends on the protocol or interface you need
> to use to talk to the card.  Firefox for example let's you add PKCS11 drivers as security 
> modules to the browser.  You can then use various tools to create keys and certs on the
> card.  For the open source play pen here I recommend Muscle and its assorted plugins
> including the PKCS11 musclecard driver.

See earlier comments.

> Continuing on, there's a whole body of open standards on provisioning the 
> card with applets - check out www.globalplatform.org.

GlobalPlatform have had EONs of time coming up with something like a universal
driver, protocol, etc.; they have not.

> To be honest, the hardest part is finding card vendors willing to sell in quantities

Most of them also requires you to sign NDAs as well which is why I had to turn to
Open Hardware.  I wasn't even allowed publishing my code!!!

> I'm really not convinced this is a PKIX issue.

You are right, it has historically been delegated to the card industry.

Having worked there myself I know the mantra: "Whatever we do, tokens
must never be a commodity".

But the truth is that PKI tokens are simple electronic devices that
unlike disk drives exhibit a very variant set of interfaces, in spite
of the fact that they all in the end do exactly the same thing!

> It's possible that something like 
> the Java Card 3.0 Connected spec's might actually already fit most of the bill though.

Java Card 3.0 was an attempt keeping prices up.  The vision has failed
and IMO the whole concept is wrong.

I'm more into adding smart card capability to for example USB memory
sticks which would only increase end-use price with $1.

Mr. Obama's NSTIC program won't go 1 mm based on the current smart card tech
since the private sector isn't interested in paying the $500 / seat that small
government agencies typically have to pay to become smart card enabled.

Another example of related (ridiculous) smart card tech:
http://us.blackberry.com/ataglance/security/products/smartcardreader

Currently banks in the EU and Asia create their own on-line provisioning
software since the ones in current browsers doesn't meet their requirements.
This was and still is my primary motivation.

Anders

---

From: Max Pritikin <[email-masked]>
Date: Mon, 22 Aug 2011 14:58:59 -0600

Anders, 

Previously I asked this question:
I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern?

From your discussion I'm thinking this is the underlying protocol issue you are concerned with, but you haven't confirmed it directly. Is this the issue?

- max

---

From: Max Pritikin <[email-masked]>
Date: Mon, 22 Aug 2011 15:02:39 -0600

Focusing on one thing you said inline,

> it is (from my perspective NB...) not even a candidate.

By 'end-to-end' security do you mean that the server in the protocol exchange can determine that the key's being enrolled exist on the smartcard rather than within the OS?

- max

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 23 Aug 2011 08:35:07 -0400

> I'm wondering if your underlying concern is how the CA server can determine that the key is actually on the smartcard. Is this correct? Is this your concern?

Based on previous discussions with Anders and my own cursory review of Keygen2, that is indeed a core concern of his.  It's a valid concern, but IMHO there's no solution without a prearranged exchange of keys (i.e., exactly what a TMS does).

The protocol is important for fungibility of devices, but without an out-of-band enrollment ceremony, no attestation arrangement really carries any meaning.

-- T

---

From: Max Pritikin <[email-masked]>
Date: Tue, 23 Aug 2011 12:21:28 -0600

> The protocol is important for fungibility of devices, but without an out-of-band enrollment ceremony, no attestation arrangement really carries any meaning.

Ok then. I think we can agree this is an interesting concern. I don't think any of our current approaches addresses this issue. Below I lay out my thoughts and then provide stream-of-thought discussion of how I might approach solving this. 

[How we fail to solve this today:]

I don't see that Keygen2 or an out-of-band enrollment ceremony solves this problem. Lets use my simple diagram of the elements:
Server (e.g. CA) => protocol => Client (e.g. OS/Software/Browser) => Smartcard

In an out-of-band-enrollment ceremony the User interfaces with the Browser or OS/Software/Browser and provides the out-of-band information such as symmetric keys or key hashes or whatnot. Since the OS/Software/Browser now knows all this data it can present any of it to the Server in any form and thus the server 
CAN NOT determine if the Smartcard is where the keys are stored. Unless the device prevents unauthorized software this doesn't buy us any assurance of where the keys are stored. 

Similarly for KeyGen2. The client's response is signed by the "private key which only the client has access to" (see slide 8 of KeyGen2 Short Presentation) but there is nothing specifically enforcing that this client key is stored within a specific container (that I see in the docs). Again, unless the device prevents unauthorized software this doesn't buy us any assurance of where the keys are stored.

Ander's stated in his off list reply:
"That is, the CA recognizes [device] containers based on the
device certificate.  The [device] implementation makes
the CA know that the key is in the [device].  There is no need
for pre-arranged keys; either you trust [the manufacturer] or you don't."

Which is also an accurate description of the EST model described for requirement A3 (see section 2) wherein "this capability allows a client who has a certificate issued by a 3rd party, such as a certificate issued by a device manufacturer, to leverage that credential during initial enrollment" to perform exactly what Ander's is talking about. 

What is harder to solve is a situation where the device manufacturer does not provide a wall garden and where the OS/Software/Browser installed on a device might _not_ also be trusted. In other words: Where the Device and the smartcard are considered independent. We'd need to ensure that the Smartcard does something in the protocol exchange that that OS/Software/Browser couldn't itself do. And because all user input to the smartcard are through these software components this means out-of-band exchanges are out so lets focus on manufacturing installed credentials within the smartcard.

[Thinking about how we might solve it:] 

(ok, this is weak. I'm just getting the point across). 

1. Assume the smartcard has a manufacturing installed credential.
2. Assume the smartcard has a general purpose interface for leveraging any contained keys. Something like:
	Sign_this_digestInfo (keyindex, externallycomputeddigest);
3. Obviously the OS/Software/Browser can use this interface to implement the RSA-SHA1 etc. 
	The OS/Software/Browser can leverage these keys such that the Server can't tell if it is the smartcard or the general device.
4. What we need is a signature method that is NOT ACCESSIBLE from the interface.

For example if the above "Sign_this_digestinfo" interface REFUSED to sign the SHA1 hash of the public key then we'd know that particular signature could only be generated by the smartcard via some other interface. For example if the interface included an extra function like:
	Generate_a_CSR_with_extensionX (keyindex)
Where "extensionX" is a signature of the public key of exactly the form not accessible by the generic interface.

That would allow the CA to determine that for a given smartcard containing a manufacturer installed credential if "extensionX" is included in the CSR then the request refers to a keypair the smartcard contains internally (and that the smartcard generated the CSR via the alternate interface). 

This would require the following:
	A) An independent RFC defining this extension within the CSR
	B) A Protocol Implementation Conformance Statement type document for the device (e.g. out of scope)
	C) The exact same protocol methods we use today

Such a solution seems possible but is not, to my mind, something we'd address in the enrollment protocol. Rather it would be a distinct document extending the CSR.
I'm only thinking out loud and won't be offended if somebody points out a gap in my logic,

- max

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 23 Aug 2011 20:44:55 +0200

On 2011-08-22 22:58, Max Pritikin wrote:

> I'm wondering if your underlying concern is how the CA server
> can determine that the key is actually on the smartcard.
> Is this correct? Is this your concern?

Indeed it is, but I prefer describing it in another way:

Although people involved in USG security tend to claim that
"this will never happen", I believe that pure economics,
convenience and "coolness" will make virtualized PIV and CAC
credentials in mobile devices enrolled in *self-service*
processes using your original card as "bootstrap", the norm.

However, this can only be realized if the self-enrolled credentials
are stored in containers that exhibit (and can *securely attest* during
enrollment), the same technical strength (like FIPS 140 certification)
as the original.  For more details regarding the process see [1].

Exactly the same considerations apply to virtualized EMV and SIM
cards.

During the design of KeyGen2/SKS [2], I found the E2ES-mechanism
in GlobalPlatform quite powerful and decided "borrowing" the concept.
In fact, it had several uses beyond what GP exploits, like a fully
transaction-based provisioning process.

Transactions are IMO fundamental for achieving the robustness
required by a BILLION-headed mainly non-tech-savvy user-base.

The only question that worried me was how this would affect systems
where E2ES isn't possible or required.  The PoC showed that this
was a no-issue; "soft tokens" or firmware keystores can use
exactly the same API protocol and with zero drawbacks since the
additional crypto container code is close to trivial.

Nope, there are no cards out there that supports this API and protocol.
I consider that a minor "snag" :-)

Browsers and operating systems are much more important than cards
and can therefore "dictate" how tokens should be designed!

I can't imagine that Google or Mozilla would be interested in
qualifying a gazillion cards and drivers that differ for no
valid reasons at all except for supporting vendor lock-in.

One Protocol, One API, One Middleware Driver/Platform, and One set
of Test Suites begin to look like a rather simple project actually :-)

Regards,
Anders

[1] http://www.ietf.org/mail-archive/web/pkix/current/msg29490.html

[2] http://webpki.org/auth-token-4-the-cloud.html

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 23 Aug 2011 21:29:26 +0200

Max,

I'm sorry that I have mislead you by not deleting my 2008 KeyGen2 short
presentation.  Early 2009 I did a complete rethink and designed a
system based on sessions which are very much like a dedicated TLS.

An early reviewer asked : Why don't you use TLS?  Because it is much
smarter using a proxy for the "heavy lifting" and keeping the container
simple.  In addition, TLS client-certificate-authentication with the
container as "end-point" is incompatible with user interaction.

If you read the core document

    http://webpki.org/papers/keygen2/sks-api-arch.pdf

you will see that the attestation key has no use except for creating
provisioning sessions.  Otherwise it would indeed be easy to trick
this system.  Note: ETSI did the ground-work.  I just made it useful :-)
by throwing out 20Y+ old ISO-7816 standards.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Aug 2011 16:40:16 -0400

>processes using your original card as "bootstrap", the norm.

The CAC and PIVs have approval processes associated with accreditation
of devices. So, unless the cognizant gov agencies decide that market
forces are more important than security concerns, virtualization is
unlikely to occur.

In the commercial sector, where cost considerations always trump
secruity, ...

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 23 Aug 2011 23:46:17 +0200

> forces are more important than security concerns, virtualization is

I'm pretty sure that Google, Apple and Microsoft together with
silicon vendors (one day) will receive the necessary certification.

Waiting for that moment to arrive before taking action is essentially
what the industry has done to date.  It was a baaaaaaaaaaaaaad idea :-)

> In the commercial sector, where cost considerations always trump

That's true, they don't generally buy into the "at any cost" thing,
they'd rather wait until something affordable and useful comes around.
That's essentially what all this fuzz is about.

R.I.P.

Regards,
Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Aug 2011 14:56:11 +1200

Max Pritikin <[email-masked]> writes:

>Although people involved in USG security tend to claim that "this will never
>happen", I believe that pure economics, convenience and "coolness" will make
>virtualized PIV and CAC credentials in mobile devices enrolled in *self-
>service* processes using your original card as "bootstrap", the norm.

It's actually already happened, several years ago.  See "Remote Desktop
Protocol: Smart Card Virtual Channel Extension", Microsoft Corporation, 7
February 2008.  So the key is still in the smart card, but the smart card may
be on the other side of the planet.  This pretty much epitomises the problem
with smart cards, having the key locked into a device that does anything an
untrusted remote system tells it to is little better than having the key on
the untrusted system.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Aug 2011 15:00:56 +1200

Stephen Kent <[email-masked]> writes:

>The CAC and PIVs have approval processes associated with accreditation of
>devices. So, unless the cognizant gov agencies decide that market forces are
>more important than security concerns, virtualization is unlikely to occur.

See my previous post, it already has, several years ago (unless the RDP smart
card virtualisation detects when it's talking to a CAC and refuses to proxy
it, which seems unlikely).

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 24 Aug 2011 12:17:25 +0200

> it, which seems unlikely).

You are of course perfectly right about that.  However, the situation where
you provide the key container and the issuer provides the key, is a step
further away on this path and will take some time to get general acceptance.
But first it must be *implemented* otherwise we have nothing to argue about :-)

Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 24 Aug 2011 08:52:58 -0400

WARNING: contains banned part

Subject: RE: [pkix] EST-02 smart card question
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Date: Wed, 24 Aug 2011 08:52:58 -0400

Note: I apologize in advance if somebody's firewall turns this text
message into a "banned attachment".

>From: Stephen Kent
> The CAC and PIVs have approval processes associated with
> accreditation of devices. So, unless the cognizant gov
> agencies decide that market forces are more important
> than security concerns, virtualization is unlikely to occur.

Steve,

The USG is not immune to market forces :-).  Technologies such as TI's
OMAP make it conceivable that mobile devices could one day provide
"approvable" security. While critical applications will always require
certified devices, we are attempting to define a "commercial solutions
for classified" process to support accreditation of systems that employ
multiple layers of approved commercial protection.

Our mobility architecture includes a two-stage provisioning process -
central provisioning provides a hands-on enrollment ceremony to load
approved firmware, configurations and device keys, and field
provisioning personalizes a fungible device into its user-specific and
usable state.  Given appropriate protocols and systems, it appears
possible for the user to personalize a device to a CAC at an unattended
kiosk (e.g., a controlled client/browser), though probably not through
an uncontrolled client/browser.

Dave

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 24 Aug 2011 09:07:37 -0400

I see the comment.

But, is this really anything new?

We all know that any hardware crypto module is at the mercy of the host invoking it.  If the host has a Trojan or is misconfigured, the crypto module as secret and private keys in it can be misused.

Isn't that is why we have multitude to tools in the security toolbox, if one cares to use  them?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Tuesday, August 23, 2011 11:01 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] EST-02 smart card question

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Aug 2011 01:30:14 +1200

>But, is this really anything new?

It seems to come as a considerable surprise to people who expect that smart-
card-auth guarantees some high level of assurance that the holder of the card
directly authorised the transaction, rather than having the card stuck 24/7 in
a reader in a server room connected via virtual USB ports to half a dozen
workstations throughout the building, saving the users the hassle of dealing
with smart cards and the IT admins the hassle of dealing with users failing to
deal with smart cards.  Think of it as passwords written on whiteboards, but
with the illusion of security because smart cards are involved.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Aug 2011 14:14:54 -0400

A
>...

Gee, can I get a rebate on my federal taxes (equal to the % spent
on bad ideas like this, when applied to the classified context :-)?

>an uncontrolled client/browser.

The provisioning process you describe could preclude a virtualized
CAC, because the device that is initialized during the first step
contains a known key (or key pair) and that could be used to distinguish
a CAC from a non-CAC.  Thus the issue is one of whether the issuer wants to
allow virtualization, in the name of convenience and cost savings, or 
to preclude it, in the name of security.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Aug 2011 14:15:26 -0400

>untrusted remote system tells it to is little better than having the key on

I was not aware of this "feature" of Windows.  Makes me even happier to be
a Mac user :-).

I especially like these quotes from the current (June 2011) version 
of the MS-RDPSEC document:

5 Security
This protocol has no security aspects and relies on the underlying 
transport for any security.

5.1 Security Considerations for Implementers
None.
5.2 Index of Security Parameters
None.

Still, I interpreted Anders's comments re virtualization as referring 
to use of a device that holds credentials, issued by a variety of CAs 
in a non-cooperative fashion, with each CA believing that the device 
is controlled by the CA in question. The doc you cite shows that use 
of a smart card does not imply that
the user is in physical possession of the card, in this case. Smart card
systems that require use of an external device for signing, with 
human PIN/data entry are presumably not subject to the MS remote 
desktop hack. So, there are technical means of addressing this 
concern, if people really care.

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 25 Aug 2011 16:49:20 +1200

>I was not aware of this "feature" of Windows.  Makes me even happier to be

Works just as well under Linux (and, presumably, OS X, although I've never 
really seen that used on corporate desktops outside art/graphics departments 
so that's by extrapolation from the Linux/Unix situation) using virtual USB 
port redirection.  It's actually even less secure than the Windows version 
because Windows at least uses RDP security while Linux just does USB-over-TCP,
and I'm not aware of anyone considering it worth tunnelling over SSH.

>Smart card systems that require use of an external device for signing, with
>human PIN/data entry are presumably not subject to the MS remote desktop hack. 

Where I've seen it used it's used for authentication rather than long-term 
signing (that is, the card performs a sig.op, but only on ephemeral data).  So 
the IT folks plug in the card and enter the PIN to unlock, and then the auth 
gets proxied to wherever it's needed over the network.  Since the card is 
never unplugged, it always remains unlocked via the PIN.  As you say, it 
doesn't work for a PIN-per-signature application.

Peter.

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 25 Aug 2011 11:07:28 +0300 (EEST)

> doesn't work for a PIN-per-signature application.

Do you see any problems when this scenario is implemented on a dedicated
1:1 or 1:n communication channel?
Thanks,

M.D.
cell: +370-699-26662

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Aug 2011 15:21:22 -0400

At 4:49 PM +1200 8/25/11, Peter Gutmann wrote:
>>desktop hack.

Agreed.

Also, for the CAC case, there are other considerations that make this seem
an unlikely scenario. CACs are often THE Giv issued photo ID for their holders,
so one is not likely to go far away from a machine that is holding one's CAC.
In some contexts, the CAC is intended to be used for physical access control
too, which means that one might not be able to go very far, physically, w/o
one's CAC.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Aug 2011 15:22:50 -0400

>1:1 or 1:n communication channel?

I don't know how to interpret your comment.  can you provide 
additional context?

Steve

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 26 Aug 2011 10:48:35 +1200

Stephen Kent <[email-masked]> writes:
>I don't know how to interpret your comment.  can you provide additional 
>context?

That was going to be my reply as well: Which scenario, what problem are you
trying to solve, and what's the threat model?

Peter.

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Fri, 26 Aug 2011 04:05:31 +0300

On 8/26/2011 1:48 AM, Peter Gutmann wrote:
> Stephen Kent<[email-masked]>  writes:
The scenario: I've a remote http server with his key pair stored on a 
secure device (eToken). The server can be accessed only through an 
authenticated vpn connection. I was asking do you see any problem if the 
eToken on the server remains unlocked for further sessions after once 
entering the PIN (cached password etc.)?

Thenks,
M.D.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Aug 2011 09:09:33 -0400

See also:

D. Balfanz and E. Felton, “Hand-Held Computers Can Be Better Smart Cards,” in Proceedings of USENIX Security ’99, Washington, D.C., 1999.

B. Schneier and A. Shostack, “Breaking Up Is Hard To Do: Modeling Security Threats For Smart Cards,” Presented at the USENIX Workshop on Smartcard Technology, Chicago, IL, 1999.

Yes, I actually keep those references handy. :)

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Aug 2011 09:11:27 -0400

> We all know that any hardware crypto module is at the mercy of the host invoking it.  If the host has a Trojan or is misconfigured, the crypto module as secret and private keys in it can be misused.

Trusted activation pathways are possible, but tend to be more expensive than just "dumb reader, smart card."

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Aug 2011 09:17:45 -0400

> and I'm not aware of anyone considering it worth tunnelling over SSH.

Sun implemented USB redirection into the rdesktop distributed with the commercial version of VirtualBox, so a UNIX implementation of USB/RDP is technically available (but not open source).

IIRC, ssh-agent can be made to redirect smart card based credentials, but it's been forever since I toyed with it.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Aug 2011 09:18:35 -0400

> too, which means that one might not be able to go very far, physically, w/o

Except for the user at home.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 26 Aug 2011 12:26:36 -0400

Security is still a function of the end machine and security of trusted path/channel.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Friday, August 26, 2011 9:11 AM
To: Santosh Chokhani
Cc: Peter Gutmann; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] EST-02 smart card question

-- T

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 26 Aug 2011 19:48:54 +0200

> Security is still a function of the end machine and security of trusted path/channel.

Sort of related.  The stuff described in

http://www.ietf.org/mail-archive/web/pkix/current/msg29682.html

is also intended to support "ACLs" for keys so that an issuer can
discriminate access to keys residing in a common key-store.

This mechanism obviously depends on that the OS is "healthy".

The problem is really finding a universally useful way of expressing
this so that issuers do not have to know everything about the client
platform.  Signed apps seems like a prerequisite.

I doubt that PCs will ever be able to use this, but in mobile
phones it should be possible.  A slight crux is the frequent use of
non-native code like Java which makes the trusted path a bit fuzzy.

Bank people have explained that this feature is a "SHOULD" while
token PINs and associated policies are a "MUST".

Anders

---

From: Stephen Kent <[email-masked]>
Date: Sat, 27 Aug 2011 09:18:01 -0400

At 4:05 AM +0300 8/26/11, Moudrick M. Dadashov wrote:
>>Stephen Kent <mailto:[email-masked]><[email-masked]> writes:
>>
>The scenario: I've a remote http server with his key pair stored on 
>a secure device (eToken). The server can be accessed only through an 
>authenticated vpn connection. I was asking do you see any problem if 
>the eToken on the server remains unlocked for further sessions after 
>once entering the PIN (cached password etc.)?
>
>Thenks,
>M.D.

Thanks for the clarification.  In this scenario, if the token is being used to
protect the private key of the server, not a person accessing the server, then
there is no issue. if the key in the token represents a user, then there might
be concerns, oin a broader secruity context.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sat, 27 Aug 2011 09:24:00 -0400

>Except for the user at home.

Just remember the Amex slogan: "Don't leave home without the card."

Steve

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Sun, 28 Aug 2011 01:09:21 +0300

On 8/27/2011 4:18 PM, Stephen Kent wrote:
>>> Stephen Kent <[email-masked]> <mailto:[email-masked]>writes:
Yes, the eToken holds server's private key in this case.

Thanks,
M.D.