Uncrackable WEP.

I'm currently deploying a wireless network around my house.

To eliminate the vanishingly small possibility of someone coming round
and sitting outside for a few hours while I'm watching movies over it,
and cracking the WEP key, I'd like to change the keys frequently.

What's the worst case proportion of weak packets, or in other words
the minimum number of packets that need to be sniffed to get the ~3000
weak ones?

Automatically changed of course, not manually.

--
http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian Stirling.
---------------------------+-------------------------+--------------------------
Q: What do you call a train that doesn't stop at stations?
A: Thomas the Bastard. -- Ben

There are more like 9000 weak IVs. The AirSnort homepage claims that it
needs between 5 and 10 million packets to bust the actual WEP key, using all
methods including weak IVs.

That sounds like a lot, but the actual number required is going to depend
heavily on what kind of data you are receiving, average packet size, and so
on. It can take as little as a half an hour to crack the key, if you are
generating a lot of traffic. If the hacker knows you're receiving video, I'm
sure that opens a whole new bag of specialized tricks. The video data is
sent in frames with a predictable structure, and a burst of fast updates can
provide several packets with different IVs where the plaintext data is
almost identical. All of that makes it much easier to crack the key.

You'd have to change keys on the router and on the client, and since these
actions are neither slow nor synchronized, you'd have an interruption in
service every half hour, if you *really* want some security.

Bottom line is that WEP is not adequate to the task. It will shut out casual
hackers looking for easy marks, but anyone with a good tool and a very small
amount of patience will be able to break your key, unless you're willing to
put up with frequent interruptions of service. In any case, you should
probably be more concerned with internet service hijackers than with video
eavesdroppers.

I'd suggest using MAC filtering to allow only your hosts to associate with
the AP. I'd also turn off SSID broadcast, and use open authentication.
Shared-key authentication just provides WEP crackers with a side-by-side
comparison of plain and encrypted text to help them crack your key.

"Ian Stirling" <(E-Mail Removed)> wrote in message
news:bm43vi$8hj$1$(E-Mail Removed)...
> I'm currently deploying a wireless network around my house.
>
> To eliminate the vanishingly small possibility of someone coming round
> and sitting outside for a few hours while I'm watching movies over it,
> and cracking the WEP key, I'd like to change the keys frequently.
>
> What's the worst case proportion of weak packets, or in other words
> the minimum number of packets that need to be sniffed to get the ~3000
> weak ones?
>
> Automatically changed of course, not manually.
>
> --
> http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian
Stirling.
> ---------------------------+-------------------------+--------------------
------
> Q: What do you call a train that doesn't stop at stations?
> A: Thomas the Bastard. --
Ben

gary <(E-Mail Removed)> wrote:
> There are more like 9000 weak IVs. The AirSnort homepage claims that it
> needs between 5 and 10 million packets to bust the actual WEP key, using all
> methods including weak IVs.
>
> That sounds like a lot, but the actual number required is going to depend
> heavily on what kind of data you are receiving, average packet size, and so
> on. It can take as little as a half an hour to crack the key, if you are
> generating a lot of traffic. If the hacker knows you're receiving video, I'm
> sure that opens a whole new bag of specialized tricks. The video data is
> sent in frames with a predictable structure, and a burst of fast updates can
> provide several packets with different IVs where the plaintext data is
> almost identical. All of that makes it much easier to crack the key.
>
> You'd have to change keys on the router and on the client, and since these
> actions are neither slow nor synchronized, you'd have an interruption in
> service every half hour, if you *really* want some security.

Actually, as I'm running stuff on the router (a linksys WRT54G), then
I think half a second accuracy in key-change should be quite possible,
even without going to actually compile a binary for the router.

If a device can recieve a packet which decryts with any of the four
keys, without notifying the other end, then something utterly trivial that
simply changes a key every minute (from a pre-generated list) on the
reciever to keep a rolling window may be the simplest way, with
absolutely no dead-time.
Something I need to check.
A years worth of keys is only a few meg, hardly a big issue.

<snip>
> I'd suggest using MAC filtering to allow only your hosts to associate with
> the AP. I'd also turn off SSID broadcast, and use open authentication.
> Shared-key authentication just provides WEP crackers with a side-by-side
> comparison of plain and encrypted text to help them crack your key.

MAC filtering only keeps the ones that are stumped when there is no
box to enter it into out.
Looking at the linux driver of the card I'm using (atmel) I believe the
MAC is (as it is with wired) put in by the driver, not the card, so
it's relatively trivial to change.
Worst-case, it'd require a tiny bit of editing of the loadable firmware.

--
http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian Stirling.
---------------------------+-------------------------+--------------------------
"An enemy will usually have three courses open to him. Of these he will
select the fourth." -- Helmuth von Moltke

<snip>
"Ian Stirling" <(E-Mail Removed)> wrote in message
news:bm4gb9$ibq$1$(E-Mail Removed)...
>
> Actually, as I'm running stuff on the router (a linksys WRT54G), then
> I think half a second accuracy in key-change should be quite possible,
> even without going to actually compile a binary for the router.
>
> If a device can recieve a packet which decryts with any of the four
> keys, without notifying the other end, then something utterly trivial that
> simply changes a key every minute (from a pre-generated list) on the
> reciever to keep a rolling window may be the simplest way, with
> absolutely no dead-time.
> Something I need to check.
> A years worth of keys is only a few meg, hardly a big issue.

Well, if you are using a keylist then the key index in the list is
transmitted in clear with the IV. So the hacker knows for each 24-bit IV
which key is associated. The problem is now identical to cracking four
separate one-key lists. If half an hour is best time for one key, then 2
hours should be best time for 4. If you change the contents of the router's
keylist, you have to change the client, and that will result in a temporary
loss of service at least every two hours.

>
> <snip>
> > I'd suggest using MAC filtering to allow only your hosts to associate
with
> > the AP. I'd also turn off SSID broadcast, and use open authentication.
> > Shared-key authentication just provides WEP crackers with a side-by-side
> > comparison of plain and encrypted text to help them crack your key.
>
> MAC filtering only keeps the ones that are stumped when there is no
> box to enter it into out.
> Looking at the linux driver of the card I'm using (atmel) I believe the
> MAC is (as it is with wired) put in by the driver, not the card, so
> it's relatively trivial to change.
> Worst-case, it'd require a tiny bit of editing of the loadable firmware.

Live and learn. I was unaware that a global MAC address could be modified on
a wifi card. I've worked on drivers for several Ethernet chips, and I don't
remember that being possible. You could download a locally-administered
address, which has a bit set that clearly identifies it as a local address,
but you could not as I recall it download a true global address with
embedded manufacturer's id.

I found a whitepaper on MAC spoofing which agrees with my notion that it is
not possible with 802.3-compliant Ethernet chipsets. So, this appears to be
an issue only for WiFi chipsets. I cannot understand why it would be
allowed. If you really need to change a MAC address, locally-administered
addresses should be good enough for any purpose.

>
> --
> http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian
Stirling.
> ---------------------------+-------------------------+--------------------
------
> "An enemy will usually have three courses open to him. Of these he will
> select the fourth." -- Helmuth von
Moltke

In article <I0qhb.793$(E-Mail Removed)>,
gary <(E-Mail Removed)> wrote:
:I found a whitepaper on MAC spoofing which agrees with my notion that it is
:not possible with 802.3-compliant Ethernet chipsets. So, this appears to be
:an issue only for WiFi chipsets. I cannot understand why it would be
:allowed.

It's not uncommon in Unix systems for the MAC to be configurable.
Not uncommon, just not well known.

Ethernet specs do not say that MAC must be globally unique.
Ethernet specs say that the MAC must be unique per segment.

A number of routers use the same MAC for virtual interfaces for each
VLAN (i.e., unique per machine, but on that machine, the same one
for each VLAN.)

Being able to change the MAC is important for failover schemes, and
for some forms of load balancing.

Being able to change the MAC is important for taking part in DECnet.

And Sun Solaris uses the same MAC for all interfaces. Seems that the
specs never say that different interfaces on the same machine must
use different MACs, so Sun decided it would be a good idea for some
reason or other. I am not aware of any other vendor that does that.

--
"WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG"
WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG. (GEB)

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:bm5cdn$3vq$(E-Mail Removed)...
> In article <I0qhb.793$(E-Mail Removed)>,
> gary <(E-Mail Removed)> wrote:
> :I found a whitepaper on MAC spoofing which agrees with my notion that it
is
> :not possible with 802.3-compliant Ethernet chipsets. So, this appears to
be
> :an issue only for WiFi chipsets. I cannot understand why it would be
> :allowed.
>
> It's not uncommon in Unix systems for the MAC to be configurable.
> Not uncommon, just not well known.

I knew about locally-administered address configuration, was just unaware
that even 802.3 firmware does not always enforce the locally-administered
bit.

>
> Ethernet specs do not say that MAC must be globally unique.
> Ethernet specs say that the MAC must be unique per segment.

True, and 802.1d only says the address needs to be unique across the bridged
LAN. However, the 802/2001 document is pretty clear in clauses 9.1 and 9.2
that the global address containing manufacturer's OUI is intended to be
unique in the entire world. It requires manufacturers to assign unique
numbers within a given OUI block, and get a new OUI when that space is
exhausted. The local administration bit is intended for situations where a
private net needs to reassign the MAC, and provides an address that cannot
be confused with the burned-in global address.

>
> A number of routers use the same MAC for virtual interfaces for each
> VLAN (i.e., unique per machine, but on that machine, the same one
> for each VLAN.)
>
> Being able to change the MAC is important for failover schemes, and
> for some forms of load balancing.
>
> Being able to change the MAC is important for taking part in DECnet.

At first glance, it seems like all of these problems could be resolved using
the locally-administered address. I admit spoofing the burned-in address is
probably more convenient (say, when changing Ethernet adapters on a system
using Flexlm licenses).

>
> And Sun Solaris uses the same MAC for all interfaces. Seems that the
> specs never say that different interfaces on the same machine must
> use different MACs, so Sun decided it would be a good idea for some
> reason or other. I am not aware of any other vendor that does that.

Wow. Well, the MAC was never intended to be an authentication device, but
this seems like an unnecessary exposure, especially given that IEEE went to
the trouble to provide for an alternate configurable address scheme.

>
> --
> "WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG"
> WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG. (GEB)

gary <(E-Mail Removed)> wrote:
> "Walter Roberson" <(E-Mail Removed)> wrote in message
> news:bm5cdn$3vq$(E-Mail Removed)...
>> In article <I0qhb.793$(E-Mail Removed)>,
>> gary <(E-Mail Removed)> wrote:
>> :I found a whitepaper on MAC spoofing which agrees with my notion that it
> is
>> :not possible with 802.3-compliant Ethernet chipsets. So, this appears to
> be
>> :an issue only for WiFi chipsets. I cannot understand why it would be
>> :allowed.
>>
>> It's not uncommon in Unix systems for the MAC to be configurable.
>> Not uncommon, just not well known.
>
> I knew about locally-administered address configuration, was just unaware
> that even 802.3 firmware does not always enforce the locally-administered
> bit.

I can speak with certainty for wired ethernet, as I've looked into it in
more depth.
Few cards enforce the MAC.
The rest all have a MAC in an eeprom, and the driver reads this on boot.
This is then passed to the networking stack, which assembles ethernet packets
with this MAC address, and then passes them to the card.
The card then simply sends the packets it's given.
To take linux for example, with a few cards you can load the driver module
with a "mac=" parameter.
For most of them, you would have to add some way to alter the MAC,
(I'm not aware of any way to generally do this, I may have missed it)
but this is not a big job.
I'd guess perhaps 20-30 lines of code.

--
http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian Stirling.
---------------------------+-------------------------+--------------------------
"Give a man a fire, and he's warm for a day. Set him on fire, and he's warm
for the rest of his life" -- Terry Pratchett-Jingo

gary <(E-Mail Removed)> wrote:
> <snip>
> "Ian Stirling" <(E-Mail Removed)> wrote in message
> news:bm4gb9$ibq$1$(E-Mail Removed)...
>>
>> Actually, as I'm running stuff on the router (a linksys WRT54G), then
>> I think half a second accuracy in key-change should be quite possible,
>> even without going to actually compile a binary for the router.
>>
>> If a device can recieve a packet which decryts with any of the four
>> keys, without notifying the other end, then something utterly trivial that
>> simply changes a key every minute (from a pre-generated list) on the
>> reciever to keep a rolling window may be the simplest way, with
>> absolutely no dead-time.
>> Something I need to check.
>> A years worth of keys is only a few meg, hardly a big issue.
>
> Well, if you are using a keylist then the key index in the list is
> transmitted in clear with the IV. So the hacker knows for each 24-bit IV
> which key is associated. The problem is now identical to cracking four
> separate one-key lists. If half an hour is best time for one key, then 2
> hours should be best time for 4. If you change the contents of the router's
> keylist, you have to change the client, and that will result in a temporary
> loss of service at least every two hours.

Not quite what I meant.
Take a list of a years worth of randomly generated keys.

At the start of every minute:
Set transmit key to that minutes key.
Replace key added 4 minutes ago with the one for 2 minutes ahead.

So, each transmit key is only used for 1 minute, and never reused, and
clocks can drift by a couple of minutes before things stop working.

And each key is used for at the most 300000 packets (54G, very small
packets)

<snip - answered in other post>

--
http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian Stirling.
---------------------------+-------------------------+--------------------------
Prosperity and ruin issue from the power of the tongue.
Therefore, guard yourself against thoughtless speech.

Still sounds like you are modifying the router's keylist once a minute. Even
if you are replacing keys in the list, so IV key indexes you have previously
used don't get reused for 4 minutes, at the end of 4 minutes you have
completely changed the router's keylist and so the client list must also be
changed, resulting in a service blip every 4 minutes because the changes are
not simultaneous.

If you can do this without a service interruption, with only a hack to the
router, more power to you. When you get it implemented, I'd like to know how
it works. Would be nice if key distribution were built into WEP, but we have
to wait for WPA or 802.11i for that.

"Ian Stirling" <(E-Mail Removed)> wrote in message
news:bm6hnp$n62$1$(E-Mail Removed)...
> gary <(E-Mail Removed)> wrote:
> > <snip>
> > "Ian Stirling" <(E-Mail Removed)> wrote in message
> > news:bm4gb9$ibq$1$(E-Mail Removed)...
> >>
> >> Actually, as I'm running stuff on the router (a linksys WRT54G), then
> >> I think half a second accuracy in key-change should be quite possible,
> >> even without going to actually compile a binary for the router.
> >>
> >> If a device can recieve a packet which decryts with any of the four
> >> keys, without notifying the other end, then something utterly trivial
that
> >> simply changes a key every minute (from a pre-generated list) on the
> >> reciever to keep a rolling window may be the simplest way, with
> >> absolutely no dead-time.
> >> Something I need to check.
> >> A years worth of keys is only a few meg, hardly a big issue.
> >
> > Well, if you are using a keylist then the key index in the list is
> > transmitted in clear with the IV. So the hacker knows for each 24-bit IV
> > which key is associated. The problem is now identical to cracking four
> > separate one-key lists. If half an hour is best time for one key, then 2
> > hours should be best time for 4. If you change the contents of the
router's
> > keylist, you have to change the client, and that will result in a
temporary
> > loss of service at least every two hours.
>
> Not quite what I meant.
> Take a list of a years worth of randomly generated keys.
>
> At the start of every minute:
> Set transmit key to that minutes key.
> Replace key added 4 minutes ago with the one for 2 minutes ahead.
>
> So, each transmit key is only used for 1 minute, and never reused, and
> clocks can drift by a couple of minutes before things stop working.
>
> And each key is used for at the most 300000 packets (54G, very small
> packets)
>
> <snip - answered in other post>
>
> --
> http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian
Stirling.
> ---------------------------+-------------------------+--------------------
------
> Prosperity and ruin issue from the power of the tongue.
> Therefore, guard yourself against thoughtless speech.

gary <(E-Mail Removed)> wrote:
> Still sounds like you are modifying the router's keylist once a minute. Even
> if you are replacing keys in the list, so IV key indexes you have previously
> used don't get reused for 4 minutes, at the end of 4 minutes you have
> completely changed the router's keylist and so the client list must also be
> changed, resulting in a service blip every 4 minutes because the changes are
> not simultaneous.
>
> If you can do this without a service interruption, with only a hack to the
> router, more power to you. When you get it implemented, I'd like to know how
> it works. Would be nice if key distribution were built into WEP, but we have
> to wait for WPA or 802.11i for that.

I'll be trying to get it working tonight.
It hinges on if you can replace a given key, rather than it just acting
as a FIFO.
It's a rather trivial script, if it works, I'll post it.

If this is so, then the key that gets the blip is the one that is now
2 minutes old, and is being replaced by one for 2 minutes in the future.
So, nobody should be using it.

--
http://inquisitor.i.am/ | private.php?do=newpm&u= | Ian Stirling.
---------------------------+-------------------------+--------------------------
The fight between good and evil, an epic battle. Darth vader and Luke,
suddenly in the middle of the fight, Darth pulls Luke to him, and whispers
"I know what you'r getting for christmas!" Luke exclaims "But how ??!?"
"It's true Luke, I know what you'r getting for christmas" Luke tries to ignore
this, but wrenches himself free, yelling "How could you know this?",
Vader replies "I felt your presents" -- The Chris Evans breakfast show ca. 94