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

"Anders Rundgren" <anders.rundgren@telia.com> Mon, 22 September 2008 13:37 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 5D99C3A69B4 for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 TQDw-rgQ3qQy for <ietfarch-smime-archive@core3.amsl.com>; Mon, 22 Sep 2008 06:37:02 -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 3B2523A6963 for <smime-archive@ietf.org>; Mon, 22 Sep 2008 06:37:02 -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 m8MDFB92013667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 06:15:11 -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 m8MDFBPX013666; Mon, 22 Sep 2008 06:15:11 -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 pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m8MDF0IB013640 for <ietf-smime@imc.org>; Mon, 22 Sep 2008 06:15:11 -0700 (MST) (envelope-from anders.rundgren@telia.com)
Received: from arport2v (81.232.45.215) by pne-smtpout1-sn2.hy.skanova.net (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 <anders.rundgren@telia.com>
To: "Timothy J. Miller" <tmiller@mitre.org>
Cc: ietf-smime@imc.org
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> <48D79438.40304@mitre.org>
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
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>

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