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

"Timothy J. Miller" <> Mon, 22 September 2008 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 935BC28C0CF for <>; Mon, 22 Sep 2008 06:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQEhTCsEOXpk for <>; Mon, 22 Sep 2008 06:11:22 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f04:392::2]) by (Postfix) with ESMTP id 25A043A688C for <>; Mon, 22 Sep 2008 06:11:21 -0700 (PDT)
Received: from (localhost []) by (8.14.2/8.14.2) with ESMTP id m8MCnDI6011430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 05:49:13 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id m8MCnDOU011429; Mon, 22 Sep 2008 05:49:13 -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 m8MCn1ON011411 for <>; Mon, 22 Sep 2008 05:49:12 -0700 (MST) (envelope-from
Received: from (localhost.localdomain []) by (8.13.1/8.13.1) with ESMTP id m8MCn0nx012896 for <>; Mon, 22 Sep 2008 08:49:01 -0400
Received: from imchub2.MITRE.ORG ( []) by (8.13.1/8.13.1) with ESMTP id m8MCn03P012888; Mon, 22 Sep 2008 08:49:00 -0400
Received: from [] ( by imchub2.MITRE.ORG ( with Microsoft SMTP Server (TLS) id; Mon, 22 Sep 2008 08:49:00 -0400
Message-ID: <>
Date: Mon, 22 Sep 2008 07:48:56 -0500
From: "Timothy J. Miller" <>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Anders Rundgren <>
Subject: Re: Subject Key Attestation Evidence "light" - Invention Disclosure
References: <00e101c91a2b$e2481320$82c5a8c0@arport2v> <> (added by <024501c91a6b$fd73d720$82c5a8c0@arport2v> <> <02bf01c91a76$91ac48a0$82c5a8c0@arport2v>
In-Reply-To: <02bf01c91a76$91ac48a0$82c5a8c0@arport2v>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms020304030604030106000105"
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

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