Re: [IPsec] PAKE selection: PACE
"Dan Harkins" <dharkins@lounge.org> Fri, 04 June 2010 23:09 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA9428B23E for <ipsec@core3.amsl.com>; Fri, 4 Jun 2010 16:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_60=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 4tbPaNzpXvJ0 for <ipsec@core3.amsl.com>; Fri, 4 Jun 2010 16:09:14 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C35593A6989 for <ipsec@ietf.org>; Fri, 4 Jun 2010 16:09:10 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A95AD1022404C; Fri, 4 Jun 2010 16:08:56 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 4 Jun 2010 16:08:56 -0700 (PDT)
Message-ID: <18f85715daf1245213a6d392f84dcd39.squirrel@www.trepanning.net>
In-Reply-To: <201006011519.36069.dennis.kuegler@bsi.bund.de>
References: <201005261337.14090.dennis.kuegler@bsi.bund.de> <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> <201006011519.36069.dennis.kuegler@bsi.bund.de>
Date: Fri, 04 Jun 2010 16:08:56 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Dennis Kügler <dennis.kuegler@bsi.bund.de>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: ipsec@ietf.org
Subject: Re: [IPsec] PAKE selection: PACE
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2010 23:09:16 -0000
Hi Dennis, On Tue, June 1, 2010 6:19 am, Dennis Kügler wrote: > Hi Dan, >> Hi Dennis, >> >> I have read the PACE submission. I believe claim 1 of the SPEKE >> patent, >> US 6,792,533, covers this protocol. If you do think otherwise, please >> explain why. > > This is very simple. The password is only temporarily used to protect a > nonce > sent to the other party. The key derivation step is completely independent > of > the password. The "temporary" use of a password has nothing to do with anything in claim 1 of US 6,792,533. And the key derivation does rely on the password. Without knowledge of the password it is not possible to derive the key. That is the whole point of running your protocol. Let me provide a more detailed look into PACE's infringement on the SPEKE patent using a paper entitled "Security Analysis of the PACE Key Agreement Protocol" by J. Bender, M. Fischlin, and you, Dennis Kugler. I'll refer to this as "the PACE paper". The SPEKE patent says that "a function of the password determines parameters of a public-key distribution system, such as a Diffie-Hellman ('DH') key exchange." In particular, it chooses a generator, g, based on a function of the password, f(S) g = f(S) which is then used in the public-key distribution system, such as a Diffie-Hellman. The patent says, "We will show at least two public-key distributions systems that work with SPEKE", and it does. It shows SPEKE with the plain-jane Diffie-Hellman and the Modified Diffie-Hellman. So if you create a password-based parameter, like a generator, to the Diffie-Hellman or the Modified Diffie-Hellman key exchange, and then use that password-based parameter in the Diffie-Hellman (or Modified Diffie-Hellman) then you're basically doing SPEKE. Does PACE create a generator based on the password? Yes. The generator in a Diffie-Hellman key exchange is an element in the group. And the PACE paper defines a problem in its number theoretic assumptions section called the PACE-DH problem: the "PAssword-based Chosen-Element (PACE) DH problem". The security of PACE is based on using a password ("password-based") to choose a generator ("element") in which to do a Diffie-Hellman. According to the PACE paper it's doing g = f(S) and f(S) is based on the PACE-DH assumption. Does PACE use that chosen element, that generator, based on the password in a Diffie-Hellman exchange? Yes, it does. The paper says, "This generator is subsequently used to run a Diffie-Hellman key agreement to derive a common key K." It looks like PACE is SPEKE. The PACE paper describes the exchange in phases. It says, "In the first phase the chip sends a random nonce s encyrpted with the password to the terminal. In the second phase both parties execute an interactive protocol Map2Point, mapping the nonce to a random generateor G of a group, e.g. an elliptic curve (the group parameters are provided by the chip and authenticated by a governmental authority). In the third phase the two parties run a Diffie-Hellman (DH) key agreement on the agreed-upon generator G and use the DH key to derive the actual keys for subsequent use." It goes on to mention a "final authentication step" to "derive an ephemeral MAC key K'mac as K'mac = H(K || 3) and use this key for authentication." (Note: K is the result of the Diffie-Hellman and H is a hash function). Let's map that into the first independent claim from the SPEKE patent, the one that claims "A cryptographic method for providing authentication, comprising:" SPEKE patent: "providing a password-based value to a first party and a second party" PACE paper: "In the first phase the chip sends a random nonce s encrypted with the password to the terminal." Discussion: an encrypted nonce is a value and it is based on the password since the password was used to encrypt it. It's a password-based value and it's being provided. SPEKE patent: "selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques" PACE paper: "In the second phase both parties execute an interactive protocol Map2Point, mapping the nonce to a random generator G of a group, e.g. an elliptic curve" Discussion: the parameter defining one of a plurality of unauthenticated key distribution techniques is a generator for a Diffie-Hellman protocol. PACE computes a generator based on the nonce which was encrypted with the password. In other words, it selects a generator, a parameter, based on the aforementioned password-based value, the nonce. To use the terminology from the PACE paper, it does PAssword-based Chosen Element Diffie-Hellman (PACE-DH). SPEKE patent: "generating by said first party, in cooperation with said second party, a cryptographic key based on said one of the plurality of unauthenticated key distribution techniques, wherein said second party cooperates in generating said cryptographic key by using said one of the plurality of unauthenticated key distribution techniques defined by said first value" PACE paper: "In the third phase the two parties run a Diffie-Hellman (DH) key agreement on the agreed-upon generator G and use the DH key to derive the actual keys for subsequent use." Discussion: the two parties, in cooperation with each other, do one of the plurality of unauthenticated key distribution techniques that the aformentioned parameter is for. In other words, they do a Diffie-Hellman with the agreed-upon generator. And they generate "a cryptographic key", aka "the DH key." SPEKE patent: "providing authentication of said first party to said second party based on said cryptographic key" PACE paper: "derive an ephemeral MAC key K'mac as K'mac = H(K || 3) and use this key for authentication." Discussion: the key K is "said cryptographic key", it's the result of the Diffie-Hellman. And K'mac is definitely "based on" K since it's the output of a hash function to which K has is an input. And K'mac is used for authentication. So it provides authentication based on (a derivative of) the K, "said cryptographic key". There is a step-by-step match between the description of the PACE protocol from a paper describing it and the SPEKE patent. Quite obviously, PACE is SPEKE. Any "temporary" use of the password is really irrelevant, and, as your paper notes, the PAssword-based Chosen Element is used in a Diffie-Hellman to create a key, K. So the key can only be derived by knowing the password. regards, Dan.
- [IPsec] PAKE selection: PACE Dennis Kügler
- Re: [IPsec] PAKE selection: PACE Dan Harkins
- Re: [IPsec] PAKE selection: PACE Dennis Kügler
- Re: [IPsec] PAKE selection: PACE Dan Harkins
- Re: [IPsec] PAKE selection: PACE Dan Harkins