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

Thierry Moreau thierry.moreau at connotech.com
Sun Oct 14 11:43:27 EDT 2012

Hi Ian!

Thanks for this thoughtful feedback.

Your first and explicit question (about application security requirement 
assumptions) deserves an answer. I respond to it (and a few more) and 
postpone replies to other feedback.

ianG wrote:
> Hi Thierry,
> On 14/10/12 01:21 AM, Thierry Moreau wrote:
>> 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.

In actual consulting assignments, I had to care for business model 
expansion: the operating division will get authorization from IT 
security staff with a very entry-level set of functionalities and quick 
and dirty client authentication techniques, and later expand the 
application with transactions having significant impacts.

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

Ah! Good question. Browsers are in every computing device, so it is very 
tempting to use it where a virus-immune device would be more 
appropriate. We live in the real world.

You already use a browser to configure network devices and to update the 
DNS records that sets the connectivity to your million dollar 
transaction application. (With DNSSEC, the DNS record management 
application is becoming more critical.)

The HTTPS session in these high impact applications should be very 
simple, basic HTML with little or no client-side processing (so that the 
service operator is confident about session integrity) and the user 
should be trained to expect a very stable user dialog. I keep in mind 
the retail payment PIN entry devices where the user is trained to input 
the PIN only on a terminal that has the look-and-feel of a certified 
banking device (this translate to application data input in the 
critical-app-in-the-browser, not to the private key usage at the outset 
of the HTTPS session).

Obviously, the client browser may accept fraudulent certificates if the 
list of root CAs is according to current practice. I guess the only cure 
to this is to use a custom-configured browser when using the 
critical-app-in-the-browser. See for instance "Lightweight Portable 
Security" http://www.spi.dod.mil/lipose.htm as an initiative in this 
direction (but don't trust *their* list of root CAs !!) (also, review 
their true entropy source ...) (this is open software based, at least 
some of it GPL, I would like to have their kernel, OS, and bootable 
media scripts in source code -- where should I ask??).

So yes, browsers as a substitute to a dumb terminal are so cost 
competitive that it is very difficult to avoid them.

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

I am not, but isn't it the case for the PKI-based authentication schemes 
run by governments. Anyway, you and I are discussing the other scenario 
where the certificate is essentially devoid of privacy-sensitive data.

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

Ah! The technological issue we face here is that there is no mechanism 
for preventing me from doing it, e.g. while following the instructions 
in the context of a social engineering attack.


- 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