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

Thierry Moreau thierry.moreau at connotech.com
Sat Oct 13 10:21:40 EDT 2012


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.

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.

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?

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?

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?

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?

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)?

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).

Thanks in advance for sharing your views.


-- 
- 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