Re: [cryptography] Social engineering attacks on client certificates (Was ... crypto with a twist)
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
Re: [cryptography] Social engineering attacks on client certificates (Was ... crypto with a twist)
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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Social engineering attacks on client certificates (Was ... crypto with a twist)
On Sun, Oct 14, 2012 at 4:21 AM, ianG i...@iang.org wrote: 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? [SNIP] 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. Bingo! Usability issues aside, the browser (HTML/CSS/JavaScript based applications) can only handle low value data. http://www.google.com/#q=webkit+site:nvd.nist.gov. Well written native applications on mobile devices can usually handle about medium value data (some hand waiving). Another thing that folks don't want to accept: mobile devices can't handle high value data that is to be available offline. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Social engineering attacks on client certificates (Was ... crypto with a twist)
On 2012-10-14 12: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. 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#12format 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. Because humans cannot themselves perform cryptographic operations, nor remember public keys as names of entities, the user interface becomes part of the security problem. It is typically the unsecured part of a secured channel, the weak link in the chain. Thus a security proposal needs to be described with a description centered on its user interface and perceived behavior. The security behavior should reflect the user interface - it should behave as the user expects. Many of the problems you describe arise because the email interface is inconsistent with its actual security properties: An email that appears to come from Bank Alice does not necessarily come from Bank Alice. Thus general security requires a secure name system, Zooko's triangle, which requires not just a bunch of cryptographic algorithms, but a bunch of tools for managing and sharing information about names - requires a whole lot of secure user interface. Your browser bookmark list, and your various contacts lists /almost/ support Zooko's triangle, and /almost/ have Zooko like behavior, but have various small subtle deviations in their behavior that make
