RE: [TLS] Please discuss: draft-housley-evidence-extns-00

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Kyle,

You bring up at least two good points: 

1) Aren't all keys/secrets known and potentially leaked by the sysadmin who
makes them? 
2) If the attacker compromises the keys, he can further the attack by
setting up a fraudulent web site, with all the trimmings.

Was I too quick to say, approximately, that TLS Evidence can deal with the
(catastrophic!) event of both keys being compromised on the server (the TLS
authentication key and the TLS Evidence signing key, considered as separate
even if they could be the same)?  I'm not convinced yet.

1) One good method for handling keys is to use a FIPS 140 hardware crypto
module.  Not just for algorithm acceleration, but specifically to generate
and store keys, especially keypairs.  The design for good key secrecy using
a FIPS 140 device is to generate the keypair on the device and then sign the
PKC request using the FIPS box.  Then all subsequent signatures should be
performed by the FIPS box.  The goal is to never have a human know the
secret key.  This is compatible and recommendable for both TLS
implementations and with the EAL6 separation kernel protection profile.

So, no, the sysadmin doesn't always know nor have the ability to compromise
the keys.  Just follow best practices, i.e., use FIPS 140 hardware crypto
well.

2) If both private keys are stored in the TLS implementation, and the
attacker compromises both (here we pretty much assume that FIPS 140 hardware
is not in use...), how effectively can he set up a rival web shop and
leverage these keys to commit fraud?

First, he's got DNS to deal with.  After all, the PKC bound to the stolen
key is bound to a DNS name.  So browsers that attend the fraudulent site
have to deal with the name mismatch between the cert and the URL.  Let's say
the browser's user blows off the warning and proceeds.  Let's say the user
sends in his/her credit card number etc. to the fraudulent site to make a
payment.  Let's say that the user actually got to the fraudulent site in the
first place (phishing implied?  Hack the links on the website?).

Next, the TLS Evidence (assuming the minimum, say that it's turned on only
for the POST of the final page) will show the URL and domain name used.
That's in the application data.  It will also show the certs used by the TLS
server, that's in the TLS handshake & TLS Evidence data.  TLS Evidence will
show the mismatch here.  

Hijacking DNS is an option for the attacker.  However, it's kinda slow, and
it definitely rings the front doorbell at the organization that lost its
keys and identity.  Most organizations start contacting the ISP that is
hosting the attacker at this point...FBI is another place to go...next it's
a public announcement (unless you're in CA, in which case you'd announce
immediately).

Finally, the attacker has to cash the check, so to speak.  Perhaps they just
happen to have an account with a payment processor -- but they know the
browser is holding evidence to their fraud.  Perhaps they just want the
credit card number & data.  Maybe they plan to sell the info on the black
market, or plan to make fraudulent card-not-present purchases.

Even when granted all these assumptions for bad things to happen in the
attacker's favor, it's a catastrophe yes, but it doesn't seem like the TLS
Evidence either causes it or exacerbates it.

In the end, the big worry is that the browser's user gave out his credit
card number to an attacker.  I think less-immediate actions on the user's
part like making promises to the attacker don't pose much risk.  The
attacker can't hold the victim to the promises, not in court.  The TLS
Evidence actually proves the fraud, so it's not an accomplice.  I think the
attacker would be better off to turn off TLS Evidence and not even use this
stolen key -- it can only hurt him.  

I still think that in comparison to a stolen TLS authentication key, a
stolen TLS Evidence key is relatively harmless.  In this kind of failure
analysis (catastrophic key compromise), failing safe is about the best you
can hope for.

And I still think that keeping private keys exclusively on FIPS 140
hardware, or an EAL6 box, is a "best practices" way to avoid a lot of this.

--mark
> -----Original Message-----
> From: Kyle Hamilton [mailto:aerowolf@xxxxxxxxx]
> Sent: Thursday, January 04, 2007 12:03 PM
> To: Mark Brown
> Cc: martin.rex@xxxxxxx; tls@xxxxxxxx
> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00
> 
> On 1/4/07, Mark Brown <mark@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Why?  Because no one can generate TLS Evidence by compromising only the
> > server's private keys.  TLS EvidenceResponse structures are only valid
> after
> > both TLS client and TLS server have signed them.  So for your scenario
> to
> > generate valid TLS Evidence you need the attacker to have compromised
> the
> > TLS server's authentication key and evidence key (they may be one and
> the
> > same though) and to have possession of the client's authentication key
> and
> > evidence key (they may be one and the same).  This is not very feasible
> > unless the attacker is the client.
> 
> Isn't the entire point of an attack to harm the attacked?  Motives
> differ for attacks.  The motives for attacks help describe/define what
> attack is going to be carried out, and how.
> 
> As an example, let's look at the "disgruntled employee" concept.
> Sysadmin, disgruntled, has possession of the traffic and
> signature-evidence keys, as he's responsible for making sure they get
> into the correct place and are used in the correct manner.
> 
> Owner or CFO or whathaveyou overlook this during employment/contract
> termination.  (Which is ASTOUNDINGLY easy to do.)
> 
> Bingo, you suddenly have an attack against your business's legal
> existence.
> 
> > The attacker knows that just about anyone could check the TLS Evidence
> > later.  So the attacker needs to make some hard choices.  Should the
> > attacker get the dummy client PKC signed by a CA?  Should the dummy
> client
> > PKC be signed by a CA that the TLS server trusts -- perhaps a CA that
> > charges money for its PKCs, or perhaps a CA operated by the TLS server's
> > organization?  Perhaps the app server shows the last 4 digits of a
> credit
> > card number used to pay for the ticket on all real receipts -- should
> the
> > attacker use a real credit card number in the app data sent in the lab?
> Now
> > that credit card info is part of the TLS Evidence record.  Or perhaps
> the
> > app server requires the buyer to send in his/her name to be printed on
> the
> > ticket receipt -- should the attacker use a real name?  Etc.
> 
> Should the attacker put an alternate server up, make it look like the
> real thing, be authenticable as it... and let others connect to it
> without realization that it's fake?
> 
> > The attacker would have to be pretty bold to use a PKC with his real
> name
> > and/or embed a real credit card number into the app data signed by TLS
> > Evidence.  If a credit card number was used, a suspicious third party
> could
> > check to see if the charge actually went through.  In a dispute, a third
> > party might ask for secondary identification -- show me the credit card,
> > show me your driver's license -- if forgery was suspected (the attacker
> did
> > grab both private keys from the TLS server by force...).
> 
> Or, be bold enough to let others do it.  Every one of the transactions
> is individually actionable, and that can cripple a business with legal
> fees.
> 
> > On the other hand, you could buy a server certified at EAL6+ to do the
> TLS
> > and TLS Evidence for you, and that would make the foregoing discussion
> moot
> > by today's standards.  Key compromise of an EAL6+ box is supposed to be
> > pretty hard to do.
> 
> ...except by people who have access regardless.
> 
> > In any case, TLS Evidence makes no guarantees about the law / legality,
> or
> > that it prevents crime, etc.  What it does is to use cryptography to
> make
> > forgery more difficult.  This could be useful to applications.
> 
> This is not something that can be solved at the network layer.  It's
> an application issue, and needs to be dealt with as such.
> 
> -Kyle H


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls