[cryptography] Social engineering attacks on client certificates (Was ... crypto with a twist)

ianG iang at iang.org
Sun Oct 14 04:21:41 EDT 2012


Hi Thierry,

On 14/10/12 01:21 AM, Thierry Moreau wrote:
> ianG wrote:
>> On 10/10/12 23:44 PM, Guido Witmond wrote:
>>
>>> 2. Use SSL client certificates instead;
>>
>>
>> Yes, it works.  My observations/evidence suggests it works far better
>> than passwords because it cuts out the disaster known as "I lost my
>> password...."
>>
>> It is what we do over at CAcert, [...]
>
> Sorry for the long digression below, the overall concern bugs me somehow.
>
> There is no doubts that the CAcert usage of client certificates is an
> interesting experiment/deployment.
>
> However, the limited value (of the CAcert activities enabled by a valid
> client certificate) for attackers reduces the conclusions that can be
> drawn from the deployment.
>
> When reviewing a security scheme design for a client organization, I had
> to ask myself what a potential attacker would attempt if the system was
> protecting million dollar transactions.


Yes.  We have to first figure out the business model.  Then extract from 
that a model of threats, and finally come up with a security model to 
mitigate the threats while advancing the business model.

If your business is dealing with million dollar transactions, can I ask 
if you are using browsers at all in that scenario?  If so, isn't there 
something wrong with this scenario?


In the alternate, if we are protecting lesser sums, and *we have assumed 
browsers as the client side tool* then I'd say off-the-cuff that client 
certificates do a better job overall than passwords.  Circumstances may 
change this, of course.


> Currently, one US bank usage of client certificates is attacked
> (http://www.adp.com/about-us/trust-center/security-alerts.aspx,
> "Fraudulent Emails Appearing to Come from ADP with Subject Line: ADP
> Generated Message: First Notice - Digital Certificate Expiration").
>
> I have serious reservations about the vulnerability of "client
> certificate" usage to such social engineering attacks. Here are some of
> the questions.

Yes - this is phishing.  This is why I question the use of the browser 
at all.  Phishing first started up in 2003 and gradually evolved as an 
industrial-scale parasite on all of online banking.

The question isn't really whether client certificates can or can't be 
phished -- of course they can be because they are browser oriented. 
Rather, the question is why the banks did not deal with phishing at the 
browser level?  If they had, then they'd find it easy to deal with 
client cert social engineering.


> If we teach the user a long story about the *certificate* rules, how can
> we expect him/her to pay attention to the *private*key*?
>
> Can't the user become confused as to PK data elements (certificate,
> private key, public key, local decryption password, key pair, digital
> signatures), their respective origin, their look-and-feel in the user
> dialogs?
>
> Given this unavoidable state of confusion, how can the user defend
> himself/herself against ill-intentioned guidance?


Right, we can't.  Same with passwords - education has failed to stop 
users entering passwords into the wrong site.

> If the user is given a genuine certificate containing privacy sensitive
> subject name data, how do you expect him/her to react to the information
> that the basic Internet protocol (TLS) exposes such data in the clear to
> eavesdroppers? How can you expect him/her to protect the private key
> once the certificate privacy lesson has been found bogus?


Why are you putting that detail into the certificate?  The certificate 
works regardless of the contents - it's just an enrollment process like 
any other, something that a bank is well familiar with.

Perhaps I should underscore a point here - the use of a CA-signed 
certificate is completely unrequired here.  Indeed I'm not sure it can 
be accepted or mandated at all, because the semantics and availability 
of a CA-signed certificate mitigate against security in this context.

Instead, we should see the client-certificate system as an available, 
in-browser cryptographic handshake.  It's all in there, waiting to be 
used.  Use whatever cert you want to get it up and going.

And think about the proper cert rollover procedure.  Indeed, an 
assumption that can be challenged is whether the cert expires at all? 
Whether the user is in control of the cert at all?  Why can't the 
enrollment site trigger the creation of the cert, and enroll that single 
cert, all at once?


> If the user is given a certificate devoid of privacy sensitive subject
> name data (e.g. self-signed, auto-issued, or obtained from
> https://www.ecca.wtmnd.nl/ -- the proof of concept in the original
> post), how do you expect him/her to pay any attention to protecting
> anything?

Indeed.  But the comparison is with passwords - not in isolation.

> Can anyone tell me (I am the user now) which software component and
> which computing environment I need to trust to be confident about the
> strength of the RSA key generated for me when I got a certificate from
> https://www.ecca.wtmnd.nl/? Actually I would like to know how could I
> learn by myself how the RSA key was generated for me? What is
> security-critical in this certificate granting process?


No - long experience has taught us that we should not involve the user 
in any such details.  We should instead move the system to a point where 
there is only one mode, and it is secure.  Details are for technical 
people to worry about.

This is how it is already done in the browser world with certificates. 
Every root-signed certificate that is seen by the browser is accepted, 
regardless.  The browser works hard to hide the details, because any 
time such details pop up, the confusion outweighs any plastic security 
claims.  And now that we are moving to HTTPS-everywhere, it is becoming 
more essential - if you've got one of those plugins that check and 
verify certs with the user directly, you'll know that connecting to a 
google site causes a barrage of popups for outrageously silly names...

The starting point of a strong system -- the goal -- is that the user 
does not participate in the security model at all.  Better known by 
Kherckhoffs' 6th principle,

"Finally, it is necessary, given the circumstances that command its 
application, that the system be easy to use, requiring neither mental 
strain nor the knowledge of a long series of rules to observe."


> Given that I exported the certificate obtained from
> https://www.ecca.wtmnd.nl/ and I used openssl pkcs12 and open pkcs8
> utilities to "look under the hood" of the RSA private key, at which
> point in the enrollment process should I have been warned against these
> steps (or equivalent actions suggested in a social engineering attack)?


No, never, please :)  You shouldn't even be able to do that.  The user 
should be told that the enrolment process is with the bank, the bank 
sorts it all out.

What you're now likely to question is whether the browser is a secure 
enough container to stop attacks from other vectors?  It's not.  Which 
is why browsers shouldn't be used for online payments of significant 
value.  At all.  But it is the browser that is at fault here, and its 
failure to protect the user is orthogonal to the question of passwords 
versus client-certs.

> As a concluding remark, I am nonetheless confident about the public key
> techniques potential for improvements over the password-based
> authentication paradigm. But I have difficulty with this widespread
> abuse of language that equates client certificates with client
> public-private key pairs. I'm afraid many security experts would even
> have difficulty in clarifying the two notions. The fact that the
> PKCS#12    format encryption covers both the private key and the
> certificate does not help (you need to enter the private key access
> password for accessing the certificate or even just the public key in a
> PKCS#12 file).


Oh absolutely agreed!  The language of PKI is designed to spread a 
particular architectural view.  But we can easily deal with that;  PKI 
won't work for this application.  Instead, client certs should simply be 
seen as overly-complicated containers which contain the ability to do 
private key secured logins.  Ignore all the container issues, and ignore 
all the business about language.


> Thanks in advance for sharing your views.
>
>


iang



More information about the cryptography mailing list