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

Anders Rundgren <anders.rundgren@telia.com> Thu, 28 July 2011 09:54 UTC

Return-Path: <anders.rundgren@telia.com>
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 7BB4821F8C66 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
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 23+6IhZ6H5D6 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8952121F8C63 for <tls@ietf.org>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0080B529; Thu, 28 Jul 2011 11:54:01 +0200
Message-ID: <4E3131AA.5010703@telia.com>
Date: Thu, 28 Jul 2011 11:53:46 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Stefan Winter <stefan.winter@restena.lu>
References: <mailman.1209.1311842548.23921.tls@ietf.org> <4E31299F.6060400@restena.lu>
In-Reply-To: <4E31299F.6060400@restena.lu>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
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:54:04 -0000

http://www.hbci-kernel.de/fints.htm

I'm happy that none the banks I have talked have any interests
in such crap.

The usage level of the German eID is hardly measurable either.

/A

On 2011-07-28 11:19, Stefan Winter wrote:
> 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.
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls