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.
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
