Hi Tim,
comments-in-line.
PIV issuers use complete token management systems; it's impossible to
get away from if you read the requirements in FIPS 201.
Yes, it will be fairly interesting to see how the US government
intends to deal with secure mobile device applications which
(at least for practical purposes) are incompatible with FIPS 201.
PIN policies are enforced by the on-card applications, not the
middleware. Or they can be, at any rate.
This is how it has been so far; KeyGen2 is about to change this
by offering remote secure issuance including dynamically setting
PIN policies in an issuer-specific way. Even issuer PUKs
will be possible to set. The enforcement may be in the secure
container but it may be in the middleware as well depending
on how much the market is prepared to spend on secure
containers. This is also subject to Moore's law that makes
the future look very good.
Getting back to the original issue, the problem that the described
solution as well as the TCG counterpart tries to solve is really mainly
related to the local software environment. Secure channels are
great but do not address malware since the channel's client endpoint
is typically megabytes (of middleware code) away from the actual
hardware container.
That's not how the token secure channel works. The secure channel is a
direct encrypted link between the token's processor and the token
management system, using a key known only to both. The host where the
token is inserted is locked out of this communication, as is all its
software. A compromised issuance station can refuse to carry the secure
channel, but it can't inspect the channel without breaking that encryption.
Thank you for clarifying this! It is pretty obvious that such a scheme
only works for one issuer who own (have bought) the tokens.
The KeyGen2 protocol is intended for usage by multiple issuers who
share a secure container with the user.
Anders