802.11/crypto questions

802.11/crypto questions

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Hi,

Since there's been lots of talk about multi-STA or multi-BSSID devices
(more than one client, more than one AP on the same PHY) and I was just
looking into some crypto stuff on bcm43xx, it got me wondering.

The bcm43xx has an elaborate group key matching thingie which will be
useful if it's all WPA2, but if it's say just plain WEP, then that is a
problem since you'd either need to use the same keys or disable the
bcm43xx crypto hardware.

Hence, I suppose the question really is -- does the dscape stack allow
changing the 'sw crypto needed' flag on the fly?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: 802.11/crypto questions

[Jouni Malinen]

On Tue, Aug 01, 2006 at 07:40:52AM +0200, Johannes Berg wrote:

> Since there's been lots of talk about multi-STA or multi-BSSID devices
> (more than one client, more than one AP on the same PHY) and I was just
> looking into some crypto stuff on bcm43xx, it got me wondering.
> 
> The bcm43xx has an elaborate group key matching thingie which will be
> useful if it's all WPA2, but if it's say just plain WEP, then that is a
> problem since you'd either need to use the same keys or disable the
> bcm43xx crypto hardware.
> 
> Hence, I suppose the question really is -- does the dscape stack allow
> changing the 'sw crypto needed' flag on the fly?

Depends on what exactly you mean with "on the fly". We have indeed
changed between doing software and hardware crypto for some cases, e.g.,
when enabling another BSS while one BSS is using static WEP (which would
need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for
the receive case. Not all configuration changes are yet supported with
minimal modification, i.e., hostapd may end up having to disconnect all
stations and start over with such a change, but still, the driver should
be prepared on dynamically changing the key configuration and this can
include moving some keys from hwaccel to software.

If it can be done without major effort, I would recommend making the
low-level drivers quite flexible as far as configuring keys to hardware
accelaration is concerned. Depending on the hardware design, there may
be multiple different ways of doing this and some multi-BSS
configurations are likely to require changes in how the keys are used
between hardware and software.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 802.11/crypto questions

[Johannes Berg]

Jouni Malinen wrote:
> Depends on what exactly you mean with "on the fly". We have indeed
> changed between doing software and hardware crypto for some cases, e.g.,
> when enabling another BSS while one BSS is using static WEP (which would
> need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for
> the receive case. 
Yeah, that's basically what I was thinking of.

Also, if we add a monitor if, does it disable hw crypto so we can see 
the undecrypted frames?

johannes

Re: 802.11/crypto questions

[Jouni Malinen]

On Tue, Aug 08, 2006 at 01:35:22PM +0200, Johannes Berg wrote:
> Jouni Malinen wrote:
> >Depends on what exactly you mean with "on the fly". We have indeed
> >changed between doing software and hardware crypto for some cases, e.g.,
> >when enabling another BSS while one BSS is using static WEP (which would
> >need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for
> >the receive case. 

> Also, if we add a monitor if, does it disable hw crypto so we can see 
> the undecrypted frames?

I haven't looked at the current implementation (if this has been
modified), but it would be nice to have an option for doing this. This
gets a bit complex, but if having such an option is not going to slow
down the normal case (i.e., monitor mode disabled), being able to select
whether frames are decrypted in monitor interface could be useful. This
would, of course, require that hwaccel is disabled for normal data
packets when this kind of mode is enabled.

Because of quite large CPU load difference, I would expect there to be
valid use cases for both allowing hardware to continue decrypting frames
(and monitor interface would show whatever was received from hardware,
i.e., some frames may be decrypted, some not based on whether a key was
configured) and stopping hardware acceleration and delivering unmodified
frames into the monitor interface (and if a normal data connection is
active at the same time, doing software decryption for frames before
they are delivered to data interface).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: 802.11/crypto questions

[Ivo van Doorn]

On Tuesday 08 August 2006 17:57, Jouni Malinen wrote:
> On Tue, Aug 08, 2006 at 01:35:22PM +0200, Johannes Berg wrote:
> > Jouni Malinen wrote:
> > >Depends on what exactly you mean with "on the fly". We have indeed
> > >changed between doing software and hardware crypto for some cases, e.g.,
> > >when enabling another BSS while one BSS is using static WEP (which would
> > >need default WEP keys in hwaccel) in one BSS, we may disable hwaccel for
> > >the receive case. 
> 
> > Also, if we add a monitor if, does it disable hw crypto so we can see 
> > the undecrypted frames?
> 
> I haven't looked at the current implementation (if this has been
> modified), but it would be nice to have an option for doing this. This
> gets a bit complex, but if having such an option is not going to slow
> down the normal case (i.e., monitor mode disabled), being able to select
> whether frames are decrypted in monitor interface could be useful. This
> would, of course, require that hwaccel is disabled for normal data
> packets when this kind of mode is enabled.
> 
> Because of quite large CPU load difference, I would expect there to be
> valid use cases for both allowing hardware to continue decrypting frames
> (and monitor interface would show whatever was received from hardware,
> i.e., some frames may be decrypted, some not based on whether a key was
> configured) and stopping hardware acceleration and delivering unmodified
> frames into the monitor interface (and if a normal data connection is
> active at the same time, doing software decryption for frames before
> they are delivered to data interface).

Would also depend on the hardware itself I would think.
Looking at the Legacy drivers from Ralink code for hardware encryption
it would be quite possible for having hardware decryption enabled
while also working in monitor mode. This is because the driver
will first receive the encrypted frame (at this time the driver could pass
it to the monitor interface) and then  signals the hardware encryption
machine to encrypt the frame after which the unencrypted frame can go through
the normal RX handling routines.
Only downside here, is that the receiving in this case should be specifically be done
to the monitor interface otherwise all frames would be send to the ieee80211 rx handler twice.

Note however that this is currently not possible with rt2x00 since that
has not yet implemented hardware encryption.

Ivo