Re: [TLS] HTTPS client-certificate-authentication in browsers

Stefan Winter <stefan.winter@restena.lu> Thu, 28 July 2011 09:19 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A621F8C79 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.451
X-Spam-Level:
X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, GB_ABOUTYOU=0.5, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3iH227MkUu9 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:19:30 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A521F8C71 for <tls@ietf.org>; Thu, 28 Jul 2011 02:19:29 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4BD19109FC for <tls@ietf.org>; Thu, 28 Jul 2011 11:19:28 +0200 (CEST)
Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2EEFF107C2 for <tls@ietf.org>; Thu, 28 Jul 2011 11:19:28 +0200 (CEST)
Message-ID: <4E31299F.6060400@restena.lu>
Date: Thu, 28 Jul 2011 11:19:27 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.1209.1311842548.23921.tls@ietf.org>
In-Reply-To: <mailman.1209.1311842548.23921.tls@ietf.org>
X-Enigmail-Version: 1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B113A623DF3CA2908555D93"
X-Virus-Scanned: ClamAV
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 09:19:30 -0000

Hi,

>>> Lots of banks wants to use CCA for their users.
>> > 
>> > That is a non sequitur.
>> > 
>> > Banks (here in Germany) have abandoned tradtional TANs based on
>> > the unconditional presumption that client PCs are infested with
>> > malware, and most banks in Germany are currently replacing indexed TANs (iTAN)
>> > presumably based on the perception that malware on clients (trojans/phishing)
>> > has caught up with iTAN procedure complexity.
>> > 
>> > At this point, with the presumption that all client PCs are
>> > thoroughly infested with malware, going for a Single Sign-On
>> > mechanism would be completely braindead and irresponsible.
> So using client certificates for authentication is such a bad idea that
> there is no point in looking into issues on how to make it better?
>
> How is the German e-card supposed work then?

Just trolling around on this list every now and then, but can't resist
to comment because I got my new eID card and also HBCI access recently.

eID: The electronic identity card contains lots of personal details
about you in some credential storage. It must be put into a whitelisted,
EAL-whatever certified hardware device, connected via USB. There is one
well-defined application on your computer which can ask the reader to
retrieve a *subset* of the personal information stored. Other
applications on the computer talk to this one application via an API.
Your card reader will present the name of the application which wants
the data, the pieces of data it wants to have from your card, and will
ask for your authorisation to reveal that personal data. That is done
via display+PIN directly on the card reader; no secret information ever
leaks the card reader unless authorized directly on the device by the
user. [1]

This exhibits a property of the system which plain presentation of a
X.509 certs won't allow: send only a subset of the stored information.

It was refreshing to see this in action when I got my reader last week:
my car insurance website signalled they need my real name, birthdate and
birthplace to log me in to manage my insurance contract - not the rest
of "me" that the card stores as well. Did that, logged into their
website, no need to even create a username/password combo.

Note that I didn't use the term "client certificate" at all - the system
does involve PKI, but it's invisible to the user; all he has is a
hardware token and a PIN.

Sure: you need the card reader. Joe Sixpack can manage to go to a shop
and put money on the shelf to get it, I assume - he does that same thing
when buying a TV. Joe doesn't even have to know or care about how to get
a "certificate" - he just gets all the stuff piggybacked on his usual
plastic ID card.

Banking: These days, TAN lists are going away. Alternatively, several
approaches come into use:

a) cell phone transaction numbers: enter transaction details on website,
website generates a TAN for this very transaction, sends it along with
the input it received from you to your (pre-registered) cell phone, you
enter the number from the cell phone into the website. - A second,
independent channel makes sure that even if the PC's comms channel is
compromised, harm is prevented.

b) offline generated transaction numbers. You get a hardware device,
branded to your bank account (provisioned secrets). Its only interface
to the outside world is a black&white camera to read a bar code; and a
display to show a resulting TAN. Workflow is: you enter your transaction
details on the web site, they generate $SOMEDATA from it (which includes
the transaction details). $SOMEDATA is signalled to the hardware device
via barcode scan, which uses it to generate a TAN based on the
pre-provisioned secrets and $SOMEDATA. Bank does the same computation,
TANs must match. Again, a second channel comes to the rescue even if the
PC is compromised.

c) HBCI - Home Banking Computer Interface. There is no browser at
all(!). An application uses the HBCI API to talk to bank servers. Client
authenticates with a smart card to be put into a card reader. All crypto
again happens on the card reader. Joe sixpack gets the smart card+PIN by
checking a box on his bank acocunt application and doesn't need to know
anything more.

None of these use Client Certificates in a browser. All of them survive
if the PC is malware-infested. But yes, there are still attacks on these
- they are not the cure-all.

Greetings,

Stefan Winter

[1] There are also readers without a keyboard. If you use these, too bad
for you, because then your infested PC will log your PIN and so on.
Because of that, the system got quite some beating when introduced.

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473