Re: Subject Key Attestation Evidence "light" - Invention Disclosure

"Anders Rundgren" <> Mon, 22 September 2008 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D99C3A69B4 for <>; Mon, 22 Sep 2008 06:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TQDw-rgQ3qQy for <>; Mon, 22 Sep 2008 06:37:02 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f04:392::2]) by (Postfix) with ESMTP id 3B2523A6963 for <>; Mon, 22 Sep 2008 06:37:02 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m8MDFB92013667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 06:15:11 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id m8MDFBPX013666; Mon, 22 Sep 2008 06:15:11 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id m8MDF0IB013640 for <>; Mon, 22 Sep 2008 06:15:11 -0700 (MST) (envelope-from
Received: from arport2v ( by (7.3.129) (authenticated as u18116613) id 48A144C500AD6178; Mon, 22 Sep 2008 15:14:59 +0200
Message-ID: <00f901c91cb5$397d2190$82c5a8c0@arport2v>
From: Anders Rundgren <>
To: "Timothy J. Miller" <>
References: <00e101c91a2b$e2481320$82c5a8c0@arport2v> <> (added by <024501c91a6b$fd73d720$82c5a8c0@arport2v> <> <02bf01c91a76$91ac48a0$82c5a8c0@arport2v> <>
Subject: Re: Subject Key Attestation Evidence "light" - Invention Disclosure
Date: Mon, 22 Sep 2008 15:15:03 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1933
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Hi Tim,

>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.