[cryptography] phishing/password end-game (Re: Why anon-DH ...)

Thierry Moreau thierry.moreau at connotech.com
Thu Jan 17 10:17:28 EST 2013


dan at geer.org wrote:
>  > To clarify:  I think everyone and everything should be identified by 
>  > their public key,...
> 
> Would re-analyzing all this in a key-centric model rather than
> a name-centric model offer any insight?  (key-centric meaning
> that the key is the identity and "Dan" is an attribute of that
> key; name-centric meaning that Dan is the identity and the key
> is an attribute of that name)
> 

Since you ask the question,

First, replace "client certificate" by client PPKP (public-private
key pair) and be ready for a significant training exercise. The
more the trainee knows about X.509, the greater challenge for the
trainer.

Second, replace PKI (for the server relying party) by the "first
party certification paradigm".

Third, an enrollment process becomes a necessity. Here is BASC
(from the initial project name, bootstrapping an authenticated
session configuration).

======
The BASC enrollment process requires the use of the client private
key and allows a remote service provider to acquire trust in the
end-user control of the PPKP according to the first party
certification paradigm. The BASC enrollment process must be
repeated for independent service providers, but the end-user can
(and should) use a single PPKP with multiple independent service
providers.

The overall picture of the BASC enrollment process can be
explained in following 6 points. Points B-C make a ceremonious

utility that is run as a first step in a BASC enrollment instance

which encompasses points B-C-D-E.

A - PPKP Provisioning

     The end-user gets a PPKP which can be used in a browser
software and for adhoc message signatures.

B - Contact the Service Provider Enrollment Server

     This connection is required once within the ceremonious
utility, and then with a browser session using the client PPKP
for authentication (point D below).

C - Sign and Send a Proof Of Possession

     In BASC, the proof of possession includes something trivial
and circumstantial (a one-time phrase and/or photograph which are
later reported back to the end-user to let her determine that she
connected to the correct service provider). The signed proof of
possession is sent to the service provider securely during the
ceremonious utility execution.

D - Online Enrollment Form

     In a secure web browser session, the end-user fills in a form
with information relevant to enrollment purposes. The session
security rests on the HTTPS protocol using the client PPKP, plus
the server demonstration that it knows the end-user by displaying
her trivial and circumstantial data.

E - Enrollment Approval

     Enrollment can not be complete just based on the end-user
having fulfilled the above formalities. Some verifications by the
service provider are required. Even if those occur behind the
scene, they are in intrinsic part of enrollment.

F - Routine PPKP Usage

     Once enrolled, the end-user authenticates herself with the
PPKP when connecting to the service provider web servers for
applications secured by the HTTPS protocol. It is an application
design issue to have the server demonstrating its knowledge of the
end-user details before the end-user provides any sensitive input.
======

Fourth, the "bad bad boy" versus the "good bad boy" dilemma --
it's a marginal example of a fundamental property of any security
scheme devoid of bypass for special circumstances having little
prospect of deployment and use. (In technical audits of security
systems, follow the thread of exceptional procedures for the
scheme management organization and you will quickly reveal that
the participants' security is ineffective in the first place
against the bad bad boys.) I don't have any answer beyond a
suggestion to deploy first for security-critical distributed
applications (those would typically not be browser-based).

Regards,

-- 
- Thierry Moreau

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

Tel. +1-514-385-5691



More information about the cryptography mailing list