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

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

Return-Path: <owner-ietf-smime@mail.imc.org>
X-Original-To: ietfarch-smime-archive@core3.amsl.com
Delivered-To: ietfarch-smime-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935BC28C0CF for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQEhTCsEOXpk for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:11:22 -0700 (PDT)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 25A043A688C for <smime-archive@ietf.org>; Mon, 22 Sep 2008 06:11:21 -0700 (PDT)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (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 owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m8MCnDOU011429; Mon, 22 Sep 2008 05:49:13 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8MCn1ON011411 for <ietf-smime@imc.org>; Mon, 22 Sep 2008 05:49:12 -0700 (MST) (envelope-from tmiller@mitre.org)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m8MCn0nx012896 for <ietf-smime@imc.org>; Mon, 22 Sep 2008 08:49:01 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m8MCn03P012888; Mon, 22 Sep 2008 08:49:00 -0400
Received: from [129.83.200.24] (129.83.200.24) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.278.0; Mon, 22 Sep 2008 08:49:00 -0400
Message-ID: <48D79438.40304@mitre.org>
Date: Mon, 22 Sep 2008 07:48:56 -0500
From: "Timothy J. Miller" <tmiller@mitre.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren@telia.com>
CC: ietf-smime@imc.org
Subject: Re: Subject Key Attestation Evidence "light" - Invention Disclosure
References: <00e101c91a2b$e2481320$82c5a8c0@arport2v> <48B6B19801185BEB@pne-smtpin1-sn2.hy.skanova.net> (added by postmaster@pne.skanova.net) <024501c91a6b$fd73d720$82c5a8c0@arport2v> <48D3D002.7030108@mitre.org> <02bf01c91a76$91ac48a0$82c5a8c0@arport2v>
In-Reply-To: <02bf01c91a76$91ac48a0$82c5a8c0@arport2v>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms020304030604030106000105"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=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