Inescapable public key property of secret key transport?

Thierry Moreau Thierry.Moreau at Connotech.com
Mon Dec 8 17:40:16 EST 2003


Subject: Inescapable public key property of secret key transport?

In the massive effort to secure the open networks, personal
computers and software trustworthiness, I wonder how the
following two security properties for a secret key transport
scheme has been addressed.

For the purpose of this post, a secret key transport scheme is
defined as the server processing of a key establishment packet
(cryptogram) that brings to the *server* the knowledge of a
secret key value that is assumed to be shared with a legitimate
*entity* (that is, we focus on the server perspective).

The two security properties are

(1) Inescapable public key property

     An outcome of the secret key transport is the assurance
     gained by the server that the secret key can only be
     (initially) shared with an entity that used a given public
     key (the server public key) when applying the exact public
     key primitive in the secret key transport specification.
     Otherwise, the secret key can only be (initially) shared
     with an entity that knows the server private key.

(2) Inescapable secret key processing rules

     An outcome of the secret key transport is the assurance
     gained by the server that the secret key can only be
     (initially) shared with an entity that followed the secret
     key preprocessing rules in the secret key transport
     specification.

     Note:     The qualification (initially) refers to the fact
               that the server can't assume that the remote
               entity will indeed preserve the secret key
               confidentiality over time.

Note that the naive assumption that the remote entity uses a
"trusted software" is a convenient way to circumvent the security
properties.

These two properties are present in the PEKE cryptosystem
(Probabilistic Encryption Key Exchange). The references are
     Moreau, Thierry, Probabilistic Encryption Key Exchange,
     Electronics Letters, Vol. 31, number 25, 7th December 1995,
     pp 2166-2168.,or
     http://www.connotech.com/PEKEMAP.HTM.

In order to spare the reader the learning time associated with
the PEKE cryptosystem, here is a possible equivalent
implementation with the RSA primitive (caveat: this scheme is a
draft, I whish to learn if and how equivalent precautions are
done by fielded secret key transport implementations):

(A)  a legitimate entity selects a random secret S;

(B)  it sends the key establishment packet (cryptogram)
     C=Encr(S||Hash(S||PubK)) where

          Encr is the RSA encryption function with the public key
          PubK, and

          Hash is a secure hash function;

(C)  the key transported is K=Hash(S||PubK).

Accordingly, the server performs the following operations upon
receiving some C from an unknown entity:

     D=Decr(C);
     if D does not look like S'||Hash(S'||PubK), reject the key
     transport operation;
     else use K'=Hash(S'||PubK) as the transported key.

Note:     This prevents the following attack where the key
          transport is simply based on Encr(K):

     The hacker modifies the legitimate entity's Pubk to his own,
     PubK" (with encryption function Encr" and decryption
     function Decr").

     The legitimate entity inadvertently sends Encr"(K) instead
     of Encr(K). The hacker intercepts Encr"(K), recovers
     K=Decr"(Encr"(K)), and sends Encr(K) to the server on behalf
     of the legitimate entity.

The "inescapable secret key processing rules" security property
intuitively refers to the fact that the step K=Hash(S||PubK)
prevents the remote entity from selecting an hidden pattern or
property in the transported key.

So, the questions is how are the two properties ("inescapable
public key property" and "inescapable secret key processing
rules") addressed in the existing key establishment protocols?

Thanks in advance!

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

e-mail: thierry.moreau at connotech.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list