Anders Rundgren wrote:
I believe that on-line (remote) key-provisioning as featured in
existing standards has a long way to go before it can be used
for example for PIV issuance (which may be infeasible for other
less technical reasons as well). None of the existing systems
available in Internet browsers like Mozilla's generateCRMFRequest
support even the most humble functionality like setting PIN
code policies.
PIV issuers use complete token management systems; it's impossible to
get away from if you read the requirements in FIPS 201.
PIN policies are enforced by the on-card applications, not the
middleware. Or they can be, at any rate.
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.
Now, if own the token management *service* is compromised then yes, the
game is over. But I warrant you have bigger problems at that point. :)
-- Tim
smime.p7s
Description: S/MIME Cryptographic Signature