Comodo Says Two More RAs Compromised
David E. Ross
<http://it.slashdot.org/story/11/03/30/1325230/Comodo-Says-Two-More-RAs-Compromised>.
I now agree with those who advocate banning the use of external,
third-party RAs.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Jean-Marc Desperrier
> See the news item at
> <http://it.slashdot.org/story/11/03/30/1325230/Comodo-Says-Two-More-RAs-Compromised>.
>
> I now agree with those who advocate banning the use of external,
> third-party RAs.
Couldn't Comodo have stopped to consider if the "solution" they were
considering made sense ? Two factor authentication can be efficient to
secure a third party RA *only* if each request is *manually* approved.
If that's not the case, then it's just snake oil : When an attacker
compromises the RA, he also get access to the authentication hardware,
and can request it to approve any of his fraudulent requests.
In the relevant attack scenario, the fact that the two factors will
restrain him from copying the authentication information and using it
later is not important, the harm will be done already.
Ben Wilson
Could you clarify what you mean when you say "Two factor authentication can
be efficient to secure a third party RA *only* if each request is *manually*
What do you mean when you say "efficient to secure a third party RA", "each
request", and "manually approved"?
I'd like to understand your position and reasoning a little more.
Thanks,
Ben
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Jean-Marc Desperrier
Sent: Wednesday, March 30, 2011 9:49 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Comodo Says Two More RAs Compromised
David E. Ross wrote:
> See the news item at
>
<http://it.slashdot.org/story/11/03/30/1325230/Comodo-Says-Two-More-RAs-Comp
romised>.
>
> I now agree with those who advocate banning the use of external,
> third-party RAs.
Couldn't Comodo have stopped to consider if the "solution" they were
considering made sense ? Two factor authentication can be efficient to
secure a third party RA *only* if each request is *manually* approved.
If that's not the case, then it's just snake oil : When an attacker
compromises the RA, he also get access to the authentication hardware,
and can request it to approve any of his fraudulent requests.
In the relevant attack scenario, the fact that the two factors will
restrain him from copying the authentication information and using it
later is not important, the harm will be done already.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Andy Isaacson
> Jean-Marc,
> Could you clarify what you mean when you say "Two factor
> authentication can be efficient to secure a third party RA *only* if
> each request is *manually* approved."? What do you mean when you say
> "efficient to secure a third party RA", "each request", and "manually
> approved"? I'd like to understand your position and reasoning a
> little more. Thanks,
> Ben
Ben,
I'm not Jean-Marc, but I think I agree with his position, so I'll
explain what I mean by those words. :)
By "two factor authentication" I assume we're talking about a Gemalto or
SecurID or similar token, plus a password known only to an individual
human. If the password is recorded somewhere in the client (RA, in this
case) computer, then we're not discussing a two-factor system anymore.
By "manually approve each request" I mean that the two-factor individual
will personally and specifically review each CSR submitted via his RA
channel, performing a two-factor authentication step for each CSR. They
cannot be batched into multiple requests per two-factor authentication,
because the RAs have demonstrated that they are incapable of operating a
secure computing facility, and an attacker would simply compromise the
batching facility to insert the desired attack CSRs.
This doesn't prevent a compromised RA computing system from displaying
one CSR for review but sending another to the CA authentication
facility, but there are several administrative systems that can be used
to mitigate this risk. (For example, the CA might deploy a secure
terminal such as the "Chip and PIN" POS terminals used in the UK; these
have recently been shown to be insecure in the POS use case by Ross
Anderson et al, but the RA use case inherently mitigates most of those
attacks.)
By contrast, here are several cost-reduced versions of the above that
trivially fail to defend against ComodoHacker:
- the two-factor system consists of an electronically readable token.
- the CSR review process is automated and multiple CSRs are approved by
a single two-factor authentication.
- the password component of the two-factor system is known to anyone or
any system other than a single human.
The system I'm describing above starts to look a lot like the "notary
public" system used in the US for legal documents that need attestation
but aren't valuable enough to employ a specialist.
-andy
Kai Engert
> Jean-Marc,
> Could you clarify what you mean when you say "Two factor authentication can
> be efficient to secure a third party RA *only* if each request is *manually*
> approved."?
> What do you mean when you say "efficient to secure a third party RA", "each
> request", and "manually approved"?
> I'd like to understand your position and reasoning a little more.
> Thanks,
The RA had encoded username/password in software.
Those credentials were sufficient for getting a cert issued.
A proposal is to require two factor authentication.
The second factor should live in a hardware token.
Here's my understanding of Jean-Marc's concerns:
If the hardware token is permanently attached and logged in,
because it is part of an automated processing system,
then it doesn't provide any additional protection,
because the hacker can readily use it, too.
In order to get increased protection against a hacker,
the second factor authentication should require manual human interaction
(e.g. reading from a one-time-password-token, and typing it manually).
In other words, systems that run fully automated, cannot benefit from
requiring multiple factor authentication, because all of them can be hacked.
Kai
Ben Wilson
that the process should not only require secure manual approval by human
eyes, but that you are also opposed to certain forms of automation where the
automated system lacks human intervention by someone who authenticates with
their own personal token. Do you oppose all RA-to-CA system components,
even if they have IP address filtering and asymmetric-key-based cross-trust
built between the CA and RA components?
-----Original Message-----
From: Andy Isaacson [mailto:a...@hexapodia.org]
Sent: Wednesday, March 30, 2011 10:33 AM
To: Ben Wilson
Cc: 'Jean-Marc Desperrier'; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Comodo Says Two More RAs Compromised
On Wed, Mar 30, 2011 at 10:04:10AM -0600, Ben Wilson wrote:
> Jean-Marc,
> Could you clarify what you mean when you say "Two factor
> authentication can be efficient to secure a third party RA *only* if
> each request is *manually* approved."? What do you mean when you say
> "efficient to secure a third party RA", "each request", and "manually
> approved"? I'd like to understand your position and reasoning a
> little more. Thanks,
Ben Wilson
need in RA system design to include the employment of trustworthy, aware
individuals who are individually accountable on a certificate-by-certificate
issuance basis (through the use of hardware tokens configured with
inactivity timeouts). I think that ties in to the risk mitigation strategy
for CAs to use when relying on RAs--maybe also adding the requirement for a
second approval by someone else. I'm just trying to query in my own mind
whether there are any use cases where this method won't work for SSL/TLS
certificates.
-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Kai Engert
Sent: Wednesday, March 30, 2011 10:41 AM
To: Ben Wilson
Cc: 'Jean-Marc Desperrier'; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Comodo Says Two More RAs Compromised
On 30.03.2011 18:04, Ben Wilson wrote:
> Jean-Marc,
> Could you clarify what you mean when you say "Two factor authentication
can
> be efficient to secure a third party RA *only* if each request is
*manually*
> approved."?
> What do you mean when you say "efficient to secure a third party RA",
"each
> request", and "manually approved"?
> I'd like to understand your position and reasoning a little more.
> Thanks,
The RA had encoded username/password in software.
Those credentials were sufficient for getting a cert issued.
A proposal is to require two factor authentication.
The second factor should live in a hardware token.
Here's my understanding of Jean-Marc's concerns:
If the hardware token is permanently attached and logged in,
because it is part of an automated processing system,
then it doesn't provide any additional protection,
because the hacker can readily use it, too.
In order to get increased protection against a hacker,
the second factor authentication should require manual human interaction
(e.g. reading from a one-time-password-token, and typing it manually).
In other words, systems that run fully automated, cannot benefit from
requiring multiple factor authentication, because all of them can be hacked.
Kai
Eddy Nigg
> Thanks, Kai. I think these kinds of questions heighten awareness of the
> need in RA system design to include the employment of trustworthy, aware
> individuals who are individually accountable on a certificate-by-certificate
> issuance basis (through the use of hardware tokens configured with
> inactivity timeouts). I think that ties in to the risk mitigation strategy
> for CAs to use when relying on RAs--maybe also adding the requirement for a
> second approval by someone else. I'm just trying to query in my own mind
> whether there are any use cases where this method won't work for SSL/TLS
> certificates.
Guys, of course good security at the RA and good authentication at the
CA are helpful including entering passwords into memory only. If there
is a process from machine to machine instead of a user to the machine
directly, this presents obviously some challenge.
However you are missing the main issue I believe. If domain control
validation is performed, the likelihood to obtain a certificate for a
domain another entity doesn't own (and being it a hacker) is mitigated
greatly. That's at least as secure as any other domain control validation.
Would Comodo had performed the domain control validation as we thought
and knew since the 2008/9 debacle exclusively through their systems, the
fraudulent certificates would not have been obtained that easily.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kyle Hamilton
On Wed, Mar 30, 2011 at 10:11 AM, Ben Wilson <b...@digicert.com> wrote:
> Thanks, Andy. So you, Jean-Marc, and others (I assume) are basically saying
> that the process should not only require secure manual approval by human
> eyes, but that you are also opposed to certain forms of automation where the
> automated system lacks human intervention by someone who authenticates with
> their own personal token.
> Do you oppose all RA-to-CA system components,
> even if they have IP address filtering and asymmetric-key-based cross-trust
> built between the CA and RA components?
Asymmetric cross-trust is useless if the cross-trusted asymmetric key is kept online.
So, for my own self:
I do not oppose all RA-to-CA systems or components. The two mitigation measures presented, though, fail to adequately protect the system.
-Kyle H
> To: Ben Wilson
> Cc: 'Jean-Marc Desperrier'; mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Comodo Says Two More RAs Compromised
>
>> Jean-Marc,
>> Could you clarify what you mean when you say "Two factor
>> authentication can be efficient to secure a third party RA *only* if
>> each request is *manually* approved."? What do you mean when you say
>> "efficient to secure a third party RA", "each request", and "manually
>> approved"? I'd like to understand your position and reasoning a
>> little more. Thanks,
Andy Isaacson
Sorry for my delay in responding.
On Wed, Mar 30, 2011 at 11:11:27AM -0600, Ben Wilson wrote:
> Thanks, Andy. So you, Jean-Marc, and others (I assume) are basically saying
> that the process should not only require secure manual approval by human
> eyes,
I'm a bit torn. If I were that person, I am sure that I would make
validation errors, especially after years and years of green-lighting
entries. The validation needs to be largely automated, simply because
humans are bad at reliably doing the same thing day after day. But
automated systems are ripe for exploitation. It's a bit of a catch-22.
> but that you are also opposed to certain forms of automation where the
> automated system lacks human intervention by someone who authenticates with
> their own personal token.
I'm not entirely sure that I'm opposed to automation to help the
Authorized Human perform their validation job better. I think the
evidence is clear that fully automated systems, with no human in the
loop, are ripe for exploitation by bored teenagers.
Also, it's an abuse of terminology to say "two factor authentication"
if the system being proposed does not actually have two factors. Two
factor means *TWO*. Today's most common implementations are "something
you know" plus "something you have". If you combine those into a single
automated system, it's not two factor anymore.
(Imagine a system where the "two factor" is implemented as
1. a password known only to the Authorized Human
2. a SecurID token, owned and operated by the AH.
Now as a cost saving measure hardcode the password into a DLL, and point
a webcam with OpenCV OCR at the token. Depending on how the audit
is set up, this might even pass audit. But congratulations, you've just
set yourself up to be owned ComodoHacker style.)
> Do you oppose all RA-to-CA system components, even if they have IP
> address filtering and asymmetric-key-based cross-trust built between
> the CA and RA components?
I'm afraid I don't understand the system you're describing, what's an
"RA-to-CA system component" and what does "cross-trust" mean? But it
sounds like you're not mitigating the core vulnerability.
It's quite dishonest of Comodo to point at the sanctity of their CA key
material, when the inputs to the signing process are controlled by
completely automated systems implemented with hardcoded authentication
tokens on systems outside of their controls. Why did their auditors
sign off on this? What requirements should Mozilla place on CA audit
reports to ensure that this kind of obviously insecure system doesn't
pass muster in the future?
-andy
Jean-Marc Desperrier
> By contrast, here are several cost-reduced versions of the above that
> trivially fail to defend against ComodoHacker:
>
> - the two-factor system consists of an electronically readable token.
> - the CSR review process is automated and multiple CSRs are approved by
> a single two-factor authentication.
> - the password component of the two-factor system is known to anyone or
> any system other than a single human.
Actually, if the two-factors system doesn't use an OTP or a secure PIN
entry device, it's probably also fails to defend against ComodoHacker :
http://pastebin.com/kkPzzGKW
"I even installed keylogger on their server and I was monitoring
administrators who logged in, keylogger was mine which bypasses all AV
and Firewalls (including Kaspersky heuristic engine to Comodo Internet
Security)."
Michael Ströder
> On 03/30/2011 07:26 PM, From Ben Wilson:
>> Thanks, Kai. I think these kinds of questions heighten awareness of the
>> need in RA system design to include the employment of trustworthy, aware
>> individuals who are individually accountable on a
>> certificate-by-certificate
>> issuance basis (through the use of hardware tokens configured with
>> inactivity timeouts). I think that ties in to the risk mitigation
>> strategy
>> for CAs to use when relying on RAs--maybe also adding the requirement
>> for a
>> second approval by someone else. I'm just trying to query in my own mind
>> whether there are any use cases where this method won't work for SSL/TLS
>> certificates.
>
> Guys, of course good security at the RA and good authentication at the
> CA are helpful including entering passwords into memory only. If there
> is a process from machine to machine instead of a user to the machine
> directly, this presents obviously some challenge.
Challenge? Eddy, are you serious? If a CA company is not capable of
establishing such an authc/authz infrastructure (based on PKI I'd suggest)
they should move to some other business.
Ciao, Michael.
Michael Ströder
> Thanks, Andy. So you, Jean-Marc, and others (I assume) are basically saying
> that the process should not only require secure manual approval by human
> eyes, but that you are also opposed to certain forms of automation where the
> automated system lacks human intervention by someone who authenticates with
> their own personal token. Do you oppose all RA-to-CA system components,
> even if they have IP address filtering and asymmetric-key-based cross-trust
> built between the CA and RA components?
Yes! Count me to "others" too.
Ciao, Michael.
Michael Ströder
> Thanks, Kai. I think these kinds of questions heighten awareness of the
> need in RA system design to include the employment of trustworthy, aware
> individuals who are individually accountable on a certificate-by-certificate
> issuance basis (through the use of hardware tokens configured with
> inactivity timeouts). I think that ties in to the risk mitigation strategy
> for CAs to use when relying on RAs--maybe also adding the requirement for a
> second approval by someone else. I'm just trying to query in my own mind
> whether there are any use cases where this method won't work for SSL/TLS
> certificates.
I really wonder what's so new about Kai's thoughts (without wanting to lower
the importance of his statements). IMO every CA should be through thinking
about all this stuff and already have security effective measurements in
place. That's simply their trust business and all this is known since over 10
years. If a CA does not have sufficient security measurements, like Comodo, it
must be kicked out of business by removing the CA certs from all pre-installed
software (web browsers etc.). It's simply like that.
Ciao, Michael.
P.S.: My observation is that many CAs usually fail to use PKI technology for
securing their own systems.
Eddy Nigg
> Challenge? Eddy, are you serious? If a CA company is not capable of
> establishing such an authc/authz infrastructure (based on PKI I'd suggest)
> they should move to some other business.
Probably, no disagreement at all.
Peter Gutmann
>Challenge? Eddy, are you serious? If a CA company is not capable of
>establishing such an authc/authz infrastructure (based on PKI I'd suggest)
>they should move to some other business.
That was another thing that amused me about Comodo (and not just Comodo but a
number of other CAs as well), they're claiming to be *authorities*, which
presumably means they're supposed to be authoritative on PKI, but they can't
figure out how to use PKI themselves to authenticate their own processes. Do
as I say, not as I do (and pay me money in the process).
Peter.
Jean-Marc Desperrier
I missed that one.
IP address filtering and asymmetric-key-based cross-trust is a great way
to build a trusted RA-to-CA *connection*, and I'm putting that sort of
things in place all the time.
It doesn't remove anything about the need for the RA itself to be trusted.
If the RA itself is not secure, it's a matter of fact that having a very
secure link between it and the CA brings you nothing at all.
How do we make the RA secure ? They are various way, but it can't be a
miracle that happens simply by way of pluging a USB PKI token to it.
Eddy Nigg
> How do we make the RA secure ? They are various way, but it can't be a
> miracle that happens simply by way of pluging a USB PKI token to it.
A human being at the CA must perform a manual review of the certificate
request and all details before issuing a certificate. It doesn't imply
that the CA must perform another verification, it's however a sanity
check in addition to measurement of the performance of the RA (by
randomly sampling some of their requests).