Re: security of limits in mondex (Re: Spending velocity limit implementation in smart cards)

2002-11-13 Thread R. A. Hettinga

--- begin forwarded text


Status: RO
Sender: <[EMAIL PROTECTED]>
Date: Tue, 12 Nov 2002 13:31:49 -0500
From: IanG <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: Adam Back <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED],  Digital Bearer Settlement List
 <[EMAIL PROTECTED]>
Subject: Re: security of limits in mondex (Re: Spending velocity limit
 implementation in smart cards)

Adam Back wrote:

> I was wondering about this recently to do with mondex.  They claim as
> you say have limits on transaction uploads, so the user could hide
> some transactions.  Indeed the user need never reconnect to the bank,
> always refilling via other users and spending to other users.
> Although they could if they chose implement something on the card to
> force it to connect within some maxium interval to the bank.
>
> And yet I thought they claimed to be able to have some liability
> limiting factors such as limits on card spending per month, and
> perhaps card spending ever.
>
> And the card itself is just a tamper resistant counter, and signed
> receipts are exchanged between cards to add to the counter (received
> payment) and subtract from the counter (send payment)>.
>
> But I think these claims are contradictory unless the limiting factors
> are implemented on the card, in which case they offer limited
> protection against someone extracting private keys from the card.
>
> So are they really uploading everything to bank via other cards even
> in peer to peer, or perhaps enough information (value, but not user or
> transaction description) to notice imbalances (corresponding to hacked
> bottomless cards)?  Or is it that the limits in fact implemented on
> card and their likely effectivness in combatting fraud from tampered
> cards exaggerated?

It's a real mess.  The first thing to realise is that
all the smart card money players practice security by
obscurity.  Mondex is particularly bad, as even people
trying to help them get slammed with NDAs that slow
down the information;  working with Mondex is like
swimming in molasses, it smells sweet, and you can do
it for a year without leaving the side of the pool.

What happens then is that actually, very few people
within the organisation know how it works.  And, those
that do are constrained to not reveal.  So what results
is a case of institutional cognitive dissonance, that
is, the various parts of the organisation holding
contradictory beliefs at the same time.

Do you recall when the Power Analysis thing was published
in America?  I was working in such a company at the time.
I didn't sign an NDA, but I won't reveal their name.

I took the work over to the security people and asked
them about it.  To my surprise, they knew all about it.
It turns out that all that stuff that had been published
had been known of in the European smart card industry,
all along.  But it was secret.  I saw the slides of the
presentations from TNO people where they listed the
attacks that the tests that they used on smart cards.
The didn't use the same words at TNO, but you could
match up the dots and draw the same picture.  These
slides were 5 years old at the time.

It was that work that got the security guys to admit
- to me - that the smart cards were defeatable.  Up
until then, they hadn't admitted it.  But, the rest
of the organisation remained convinced the cards were
undefeatable.

Why?  Because all the security was subject to a NDA or
secrecy order.  Which allowed all sorts of problems to
arise.

I have no internal knowledge of Mondex, but I see the
same process.  Those that know can't say, and those
that don't know (the truth) don't tell you they don't
know the truth.

It is for reasons similar to this (but not precisely
the same issues) that I don't think smart card money
has a chance.  Some disagree.  Notably, Dave B is a
loyal pundit of the chip card.  Also, Rachel has
tramped that path for 7 long years.  If you ever need
to see proof that smart card money is doomed, look at
Intertrader.  For all that time, they demonstrated
that smart cards could be used as money over the net.

Mondex remain blithely ignorant of this, in an
institutional sense.  Sure, 100 meetings later, the
names are all known, but are they aware, in a sentient
sense?  No.  My observations have led me to believe,
that, like Mars, there is no possibility of useful
life in smart card companies.

PS: I know I haven't answered the real question, as to
how Mondex does it.  the following is speculative:

There are 10 slots on the card for transactions, and
it is possible for the oldest ones to be wiped by
inserting new transactions.  Those transactions can
be read off by another card, if so organised, hence,
when doing an upload to the "bank", it can read off
the transactions.  Now, if the "bank" detects that
some of the transactions have been wiped, it can issue
a freeze command.

Here's where the cognitive dissonance comes in:  all
of the above is configurable.  That is, one Mondex
issue might do it that way, or it 

security of limits in mondex (Re: Spending velocity limit implementation in smart cards)

2002-11-13 Thread R. A. Hettinga

--- begin forwarded text


Status: RO
Date: Mon, 11 Nov 2002 19:32:54 +
From: Adam Back <[EMAIL PROTECTED]>
To: IanG <[EMAIL PROTECTED]>
Cc: "R. A. Hettinga" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
   Digital Bearer Settlement List <[EMAIL PROTECTED]>
Subject: security of limits in mondex (Re: Spending velocity limit
 implementation in smart cards)
User-Agent: Mutt/1.2.2i
Sender: <[EMAIL PROTECTED]>

On Mon, Nov 11, 2002 at 12:55:24PM -0500, IanG wrote:
> [...] If you are talking about the system, then simply go to
> the backends and do some statistics on the backend data
> base.  Even Mondex uploads transactions, so you would
> be able to do the numbers.  (From memory, Mondex uploads
> the last 10 transactions when you plug it into certain
> terminals.  Although, this "feature" is contraversial,
> as the company has never released sufficient details to
> know for sure.)

I was wondering about this recently to do with mondex.  They claim as
you say have limits on transaction uploads, so the user could hide
some transactions.  Indeed the user need never reconnect to the bank,
always refilling via other users and spending to other users.
Although they could if they chose implement something on the card to
force it to connect within some maxium interval to the bank.

And yet I thought they claimed to be able to have some liability
limiting factors such as limits on card spending per month, and
perhaps card spending ever.

And the card itself is just a tamper resistant counter, and signed
receipts are exchanged between cards to add to the counter (received
payment) and subtract from the counter (send payment)>.

But I think these claims are contradictory unless the limiting factors
are implemented on the card, in which case they offer limited
protection against someone extracting private keys from the card.

So are they really uploading everything to bank via other cards even
in peer to peer, or perhaps enough information (value, but not user or
transaction description) to notice imbalances (corresponding to hacked
bottomless cards)?  Or is it that the limits in fact implemented on
card and their likely effectivness in combatting fraud from tampered
cards exaggerated?

Adam
--
http://www.cypherspace.net/

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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



Re: DOS attack on WPA 802.11?

2002-11-13 Thread Arnold G. Reinhold
At 11:40 PM +0100 11/11/02, Niels Ferguson wrote:

At 12:03 11/11/02 -0500, Arnold G. Reinhold wrote:
[...]

One of the tenets
of cryptography is that new security systems deserve to be beaten on
mercilessly without deference to their creator.


I quite agree.


I hope you won't mind another round then.


>2. Refresh the Michael key frequently. This proposal rests on WPA's
[...]

This has no effect on the best attack we have so far. The attack is a
differential attack, and changing the key doesn't change the probabilities.


Tell me if I understand this attack correctly. Bob intercepts a 
packet he knows contains a certain message, even though it is WPA 
encrypted, say "Transfer one hundred dollars from Alice's account to 
Bob's account. Have a nice day."  (Maybe he know what time it was 
sent, or the length, whatever.) Because WPA uses a stream cipher, Bob 
can create a message that will decrypt with the same key to "Transfer 
one million dollars from Alice's account to Bob's account. Have a 
nice day."  This was one of the problems with WEP.

WPA is designed to prevent this kind of forgery by adding a 64-bit 
MIC. Even so, I could send lots of packets containing the million 
dollars message but with random stuff in the MIC field (or in the 
"Have a nice day" part that Bob knows nobody reads) and if I do this 
enough times I will accidently create a packet with a valid MIC.  If 
MIC were really strong, this would take about 2**64 tries, a big 
enough number not to worry about.  But because Michael is puny, you 
were able to find some clever tricks for picking the randomizing data 
so that only about 2**29 (aka half a billion) tries are needed. 
Furthermore, you are worried that there might be a way that requires 
only 2**20 (about a million) tries.  And because we are trying MIC 
codes at random, the MIC key in use at the moment doesn't matter. 
Eventually Bob gets lucky and the packet goes through.

The logic behind your countermeasure is that forgery attempts are 
very easy to detect and by shutting down for a minute after 2 forgery 
attempts within one second, Bob needs an average of half a million 
minutes to get his packet through, or about one year. And that's an 
acceptable risk.

If I got this right, here are a couple of observations. Assume for a 
moment WPA as is, but with your time out countermeasure turned off.

1. Bob only gets that one packet through.  If he wants another packet 
he has to start all over with another million or more attempts. So 
that packet had better be worth the effort.

2. This forgery only affects the 802.11 layer. If the "Transfer one 
million dollars" message has an electronic signature or another layer 
of protection, this attack does nothing to defeat that.

3. The network will get and detect hundreds of thousands of copies of 
the forged message before a valid one gets through. If Bob is 
tampering with the MIC code, they will all be identical. If Bob is 
munging an unimportant section of the message, they will still be 
highly correlated. So we will have hours, maybe days of warning that 
someone is attacking our system and exactly what Bob is trying to do. 
Even if we were asleep and he succeeds, we would know about the 
attack and what message he was trying to send.

4. Bob has to do a lot of transmitting and we will have hours or days 
of warning to track him down with direction finding equipment.


This is not a very attractive attack from Bob's point of view.  He 
must find a single packet so valuable it is worth all risk and time 
involved in mounting this attack. He telegraphs his scheme well in 
advance of its success. He risks being caught in the act and he 
leaves a trail of evidence that can be used to catch him, say when he 
cleans out that bank account. It sounds like a Woody Allen movie 
scenario. ("What does this note mean 'I have a bun'?" "It says 'gun'" 
"Hey Charlie does this look like a 'b' or a 'g' to you?")

Furthermore, if I got this right, a filter could be turned on that 
simply blocked the packet Bob is attempting to send when it finally 
gets a valid MIC. For extra credit, you could do the following: 
automatically detect forgery attempts and devise a filter for them 
(say, look for the constant region of the forgeries). When a valid 
packet comes through that matches the filter, reject it and force a 
key change.  The transport layer will request a retry. If, by chance, 
the packet was legit, the station that sent it can send it again and 
the Internet goes on. Bob on the other hand, needs another million 
tries, after which the same thing will happen.

Any security hole is a matter for concern, but if my understanding is 
correct, I am more convinced that a valid alternative to your time 
out countermeasure is for WPA to tell us we are under attack and let 
us log the forgery attempts verbatim, which I suggested in my first 
message.


Regardless of whether my understanding of the differential attack is 
correct, I think the nub of our 

Public Key Addressing?

2002-11-13 Thread Hadmut Danisch
Hi,

maybe someone can give me a hint to explain something:


Someone was writing an article in context of 
communication and network security. The article
contained a chapter about the need to distinguish
between the payload and informations needed to 
provide the service, such as addresses etc.
The chapter started with a few lines of introduction, where
the author said something like

  "When doing a phone call, phone numbers must be
  transmitted, and signals about the state of the
  connection as well."


Now a german professor of computer science, who
claims to be a cryptographer, denied this in 
a way which I translate to english like this:

  "This is a wrong statement about the technical details.
  It is wrong to claim, that, when doing phone
  calls, phone numbers must be transmitted. The author
  seems to take only the currently practiced ISDN protocols
  into consideration and ignored that, e.g. in particular
  for Packet Switched Networking with Public Key Addressing,
  as researched by Donald Davies as the original fundament 
  for the introduction of Packet Switched Networks, especially 
  this problem was to be bypassed/avoided."
  

He must obviously have confused something. It is commonly
known that the old analog phones had a dial as well. 
Public Key Cryptography (since he is talking in context of
cryptography, I presume that "Public Key Addressing" is
supposed to mean anything with Public Key Cryptography)
was invented in the seventies, while Packet Switched
Networks were developed in the sixties. Until now, 
I couldn't find any hint what Donald Davies could have
done which could be called Public Key Adressing.

The professor himself refuses any statement.

Does anybody have any idea, even an absurd one, what could
the professor have driven to this conclusion and what he
could have meant with Public Key Addressing?


regards
Hadmut




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



Re: DOS attack on WPA 802.11?

2002-11-13 Thread Niels Ferguson

We've gone through all the main argument here, and I think it is clear we
don't agree. I started writing a detailed reply to your last message, but
most of it was just argueing that we need authentication on 802.11 packets.
TGi had a limited brief: improve the security for 802.11, and that includes
providing authentication. 

Many of your arguments depend on properties of other parts of the system. A
few forged packets won't cause too much danger. We can DF the transmitter,
and then do something about it. We can catch Bob when he collects the
money. We can detect the attack and let the humans respond to it. We can
implement alternative countermeasures in the form of a filter. 

You can't assume that any of these are true. We can't tell our customers
something like: "Here is the security upgrade for your existing hardware,
but you need to buy DF equipment, staff your wireless network security
office 24*7, re-design all your applications such that a few forged packets
do not do too much harm, buy new APs with enough memory to implement the
new filter functions, and establish a world-wide police system to arrest
Bob at any bank in the world when he tries to collect the money." 

Our job is to secure 802.11, nothing more, but certainly nothing less. That
means that we have to provide authentication for all packets. The only
sensible measure of how well we do that is how much effort it takes an
attacker to forge a single message. 

I will therefore restrict myself to the issue of securing 802.11, and not
go into any of the other aspects of the system.

[...]
>Tell me if I understand this attack correctly. Bob intercepts a 

The 2^-29 probability comes from carefully choosing a particular difference
pattern in the message. For certain carefully chosen difference patterns
the MIC value does not change. Alternatively, you can use carefully chosen
difference patterns in the message and a related chosen difference in the
MIC value. The probability here is taken over all possible Michael keys.

[...]
>The logic behind your countermeasure is that forgery attempts are 
>very easy to detect and by shutting down for a minute after 2 forgery 
>attempts within one second, Bob needs an average of half a million 
>minutes to get his packet through, or about one year. And that's an 
>acceptable risk.

Yes. That seems more work for Bob than breaking into the office and tapping
directly into the Ethernet cables, which is the original security goal of WEP.


[...]
>There are three important differences between the Michael 
>countermeasure DOS attack and the packet canceling attack you 
>described earlier. First, the Michael attack is much easier to 
>program, hence more likely to happen. Second, since it is new and 
>specific to the touted WPA, it will be especially attractive to 
>hackers, while at the same time more damaging to WPA's reputation.

We all know it only takes one smart programmer to program it, and then the
attack becomes just a tool. My DOS attack is also a super-slick one. You
can think up many other ones that are much simpler to program, like
disturbing the beacon or sending false beacons. 

Besides, I don't understand where you want to go with this argument. You
argue for a configuration switch to switch of the countermeasures. The
basic forgery attack still exists, so now the attacker can do the DOS
attack and get the countermeasures switched off. Are you saying that
Michael without countermeasures is secure enough?

>Third, the countermeasure attack is inherently very hard to detect 
>while I believe there are defenses against the packet cancelling 
>attack that force the attacker to make lots of transmissions. As I 
>mentioned, TCP/IP packets can be encapsulated in a layer above 
>802.11. Also two stations on the same wireless network that also had 
>a wired link could collude to force the attacker into transmitting 
>more.  These aren't great defenses, but they could be developed 
>fairly quickly if packet cancelling attacks became a problem.

Not if you cancel the ARP packets for new stations. And the attacker would
detect these collusing stations and ignore their packets anyway. And I can
think of several more DOS attacks against 802.11, but I don't have the time
now to work out the details.


>Then why not have two levels of strength, one what is now proposed 
>and the second with a stronger MIC, perhaps Michael with more rounds 
>as you suggest, and let the user choose?  And why not insist that 
>802.11a use the stronger mode? Because it is just coming out, 802.11a 
>has no installed base and there is less crud on its 5 GHz band. It is 
>also much faster so it will require more powerful processors anyway 
>and any forgery attack will take much less time.
>
>I sense a shift in argument here from "We had to retrofit existing 
>systems and did the best we could," which I can buy for 802.11b but 
>not in the 802.11a case, to "We don't care about DOS attacks, so we 
>won't increase hardware cost a dime to 

ADMIN: list will have delays during the next week

2002-11-13 Thread Perry E. Metzger

I'll be on line only sporadically for some days because of a family
emergency.  I'll try to deal with moderation duties when I can, but
don't be surprised if it is a few days between message batches.

Perry

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