google crypto?

2003-06-29 Thread Don Davis
does anyone know anything about AP's claim that Google
encrypts credit-card numbers?  specifically, which
cipher and what kind of key management do they use?

- don davis, boston


-
From:  Google puts new gadgets in browser
Friday, June 27, 2003

http://www.cnn.com/2003/TECH/internet/06/27/google.gadgets.ap/index.html


  The new software out Thursday for the [Google] toolbar
   includes ... a program that automatically fills out
   Internet forms seeking a customer's name and address.

  The function that fills in forms offers an option to
   store credit card numbers too, but the information
   is encrypted on the hard drive of a user's computer
   instead of Google's computers, for security and
   privacy reasons.









-

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Attacking networks using DHCP, DNS - probably kills DNSSEC

2003-06-29 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Bill Stewart writes:
Somebody did an interesting attack on a cable network's customers.
They cracked the cable company's DHCP server, got it to provide a
Connection-specific DNS suffic pointing to a machine they owned,
and also told it to use their DNS server.
This meant that when your machine wanted to look up yahoo.com,
it would look up yahoo.com.attackersdomain.com instead.

This looks like it has the ability to work around DNSSEC.
Somebody trying to verify that they'd correctly reached yahoo.com
would instead verify that they'd correctly reached
yahoo.com.attackersdomain.com, which can provide all the signatures
it needs to make this convincing.

So if you're depending on DNSSEC to secure your IPSEC connection,
do make sure your DNS server doesn't have a suffix of echelon.nsa.gov...


No, that's just not true of DNSsec.  DNSsec doesn't depend on the 
integrity of the connection to your DNS server; rather, the RRsets are 
digitally signed.  In other words, it works a lot like certificates, 
with a trust chain going back to a magic root key.  I'm not saying that 
there can't be problems with that model, but compromised DNS servers 
(and poisoned DNS caches) are among the major threat models it was 
designed to deal with.  If nothing else, the existence of caching DNS 
servers, which are not authoritative for the information they hand out, 
makes a transmission-based solution pretty useless.



--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of Firewalls book)



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Attacking networks using DHCP, DNS - probably doesn't kill DNSSEC

2003-06-29 Thread Bill Sommerfeld
One key point though: even if DNSSEC was deployed from the root, and a
trusted copy of the root key was the client, the search path/default
domain must *also* come from a trusted source.

Currently, default domain/search path often comes from DHCP, and for
nomadic laptops where the relationship to the local network is often
casual at best, this is likely to be a mistake.

- Bill


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Attacking networks using DHCP, DNS (Updated news)

2003-06-29 Thread Sidney Markowitz
It turned out that the ISP, Charter, was not compromised. The user had 
some nasty spyware install itself on his computer. Here are the details:

http://ask.slashdot.org/comments.pl?cid=6260281sid=68266tid=172

 -- sidney



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Attacking networks using DHCP, DNS - probably kills DNSSEC

2003-06-29 Thread Bill Stewart
At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Bill Stewart writes:
This looks like it has the ability to work around DNSSEC.
Somebody trying to verify that they'd correctly reached yahoo.com
would instead verify that they'd correctly reached
yahoo.com.attackersdomain.com, which can provide all the signatures
it needs to make this convincing.

So if you're depending on DNSSEC to secure your IPSEC connection,
do make sure your DNS server doesn't have a suffix of echelon.nsa.gov...
No, that's just not true of DNSsec.  DNSsec doesn't depend on the
integrity of the connection to your DNS server;
rather, the RRsets are digitally signed.
In other words, it works a lot like certificates,
with a trust chain going back to a magic root key.
I thought about that, and I think this is an exception,
because this attack tricks your machine into using the
trust chain yahoo.com.attackersdomain.com., which it controls,
instead of the trust chain yahoo.com., which DNSSEC protects adequately.
So you're getting a trustable answer to the wrong query.
I'm less sure of the implementation issues of the
Connection-specific DNS suffix, and I've seen conflicting documentation.
If the resolver looks up domain.suffix before domain,
then the attacker's DNS doesn't need to control the DNS access,
and only needs to provide the attacker's certificates,
but if the resolver looks up domain before domain.suffix,
then the attacker also needs to make sure that the lookup of domain fails,
which is most easily done by telling the DHCP client to use
the attacker's DNS server along with telling it the suffix.
(That doesn't add any extra work to the attack, but does make it
a bit easier to trace the attacker after the fact;
if you're not replacing the attacker's DNS server entry,
then all you need is a legitimate-looking server for
*.attackersdomain.com.  In either case, somebody who can
pull off this kind of an attack probably uses a compromised machine
to run the DNS server on anyway.)
I'm not saying that
there can't be problems with that model, but compromised DNS servers
(and poisoned DNS caches) are among the major threat models it was
designed to deal with.  If nothing else, the existence of caching DNS
servers, which are not authoritative for the information they hand out,
makes a transmission-based solution pretty useless.
DNSSEC seems to do a pretty thorough job of making sure that
if you look up the correct domain name, you'll get the correct answer,
in spite of attackers trying to prevent it.
But this attack tricks you into looking up the wrong domain name,
and DNSSEC makes sure that you get the correct answer for the wrong name,
which isn't the result you want.




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Attacking networks using DHCP, DNS - probably kills DNSSEC

2003-06-29 Thread Simon Josefsson
Bill Stewart [EMAIL PROTECTED] writes:

 At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Bill Stewart writes:
 This looks like it has the ability to work around DNSSEC.
 Somebody trying to verify that they'd correctly reached yahoo.com
 would instead verify that they'd correctly reached
 yahoo.com.attackersdomain.com, which can provide all the signatures
 it needs to make this convincing.
 
 So if you're depending on DNSSEC to secure your IPSEC connection,
 do make sure your DNS server doesn't have a suffix of echelon.nsa.gov...

No, that's just not true of DNSsec.  DNSsec doesn't depend on the
integrity of the connection to your DNS server;
rather, the RRsets are digitally signed.
In other words, it works a lot like certificates,
with a trust chain going back to a magic root key.

 I thought about that, and I think this is an exception,
 because this attack tricks your machine into using the
 trust chain yahoo.com.attackersdomain.com., which it controls,
 instead of the trust chain yahoo.com., which DNSSEC protects adequately.
 So you're getting a trustable answer to the wrong query.

No, I believe only one of the following situations can occur:

* Your laptop see and uses the name yahoo.com, and the DNS server
  translate them into yahoo.com.attackersdomain.com.  If your laptop
  knows the DNSSEC root key, the attacker cannot spoof yahoo.com since
  it doesn't know the yahoo.com key.  This attack is essentially a
  man-in-the-middle attack between you and your recursive DNS server.

* Your laptop see and uses the name yahoo.com.attackersdomain.com.
  You may be able to verify this using your DNSSEC root key, if the
  attackersdomain.com people have set up DNSSEC for their spoofed
  entries, but unless you are using bad software or judgment, you will
  not confuse this for the real yahoo.com.

Of course, everything fails if you ALSO get your DNSSEC root key from
the DHCP server, but in this case you shouldn't expect to be secure.
I wouldn't be surprised if some people suggest pushing the DNSSEC root
key via DHCP though, because alas, getting the right key into the
laptop in the first place is a difficult problem.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]