New Encryption System Design that works with wireless drivers.

Robert Denier denier
Sat Feb 19 11:02:02 PST 2005


On Sat, 2005-02-19 at 10:33 -0800, Jouni Malinen wrote:
> On Sat, Feb 19, 2005 at 12:11:56PM -0600, Robert Denier wrote:
> > On Sat, 2005-02-19 at 09:44 -0800, Jouni Malinen wrote:
[snip]
> 
> > 2) In general, Its impossible even to determine who is sending packets
> > to whom.  (Note as soon as you add a mac address, even the fake ones
> > this uses, then this point is severly weakened, but it has to work on
> > real hardware that exists.)
> 
> Well, in case of IEEE 802.11 you do need to use the correct source MAC
> address (which could be randomized, though) to get ACK packets working
> correctly, so I don't see much difference here.

I didn't read this carefully before, so I didn't add to this part.

My design is based around the concept of paths.  The fact that MAC
addresses are still involved in the system is purely a necessary evil to
get a test system working on hardware that actually exists.

Paths are just some random number that is negotiated in secret with the
ECC encryption and as such never available to anyone but the parties
involved.  Sure you can see path 0x1234ab23 in the stream but you have
no way of associating it with an IP or mac or whatever.  Only the
destination of the path and the routers along the way need to be able to
recognize that path.  Keys are linked to paths so that decryption is
handled automatically.

Fake mac address help obfuscate things a little, but in reality they
just don't get the job done since things like dhcp packets link it
all together.  (My design uses a fixed key for broadcast communications
which one must assume will not be kept securely by someone, so broadcast
communications must be assumed to be of lower security.)

(I get the feeling that by the time I release the documentation I will
have covered a lot of points, but oh well.)








More information about the Hostap mailing list