This series provides support for HW encryption for 4965.
TKIP in iwlwifi requires that for TX rekeying is computed in
software and also phase1 rekeying for RX is computed by
software. mac80211 encryption infrastracture is utilized for
this.
[PATCH 1/5] mac80211: allows driver to request a Phase 2 key
[PATCH 2/5] mac80211: allows driver to request a Phase 1 RX key
[PATCH 3/5] iwlwifi-2.6: Cleans up set_key flow
[PATCH 4/5] iwlwifi-2.6: enables HW TKIP security
[PATCH 5/5] iwlwifi-2.6: RX status translation to old scheme
Thanks
Reinette
> Also sort of wrong; there are plenty of situations where the AP can be
> put into essentially Dynamic WEP mode (I actually test this quite often
> since there are a lot of people who use it) where it is still backed by
> RADIUS but uses only WEP as the cipher and does _NOT_ broadcast WPA/RSN
> information elements at all.
>
> The _only_ guarantee you have for Dynamic WEP is that the privacy bit is
> set to 1. Here's an iwlist dump for such a configuration, taken with an
> ipw2200, so it would be reporting WPA/RSN IEs if there were any, but
> there aren't:
>
> Cell 30 - Address: 00:1A:xx:xx:xx:xx
> ESSID:"foobar"
> Protocol:IEEE 802.11bg
> Mode:Master
> Frequency:2.422 GHz (Channel 3)
> Encryption key:on
> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
> 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
> 48 Mb/s; 54 Mb/s
> Quality=82/100 Signal level=-16 dBm
> Extra: Last beacon: 35ms ago
>
> Looks like static WEP, but it's actually a Cisco AIR-AP1131AG backed by
> RADIUS using EAP-TLS.
>
> Unfortunately for dynamic WEP, as a user you simply have to _know_ that
> the AP is using one of:
>
> - Open System auth
> - Shared Key auth
> - WEP 104
> - WEP 40
> - LEAP
> - Dynamic WEP
>
> since it doesn't beacon, you're just fucked unless your sysadmin tells
> you what the AP is doing. Yay for WEP.
>
I think we are addressing different problems. First of all our focus
is on mac80211 interpretation of WEP setting through WEXT rather then
how use know what security setting to chose. Currently even when user
now how to configure the security setting a driver under mac80211 was
not able to distinguish what is static and what is dynamic WEP it was
blurred by mac80211.
The problem of distributing and guessing wireless profiles is a
different problem. Unfortunately the whole wireleess stack is burden
by coexistence with legacy systems.
Tomas
> Dan
>
>
> >
> > >
> > > > Other difference while there can be 4 static key installed that the
> > > > same time possible switching between indexes There can be only one
> > > > dynamic key per station if you also consider mcast/bcast station to be
> > > > an entity. (TKIP actally uses different key index for bcast but
> > > > that's just little execption)
> > > > The terminology which is used is also wrong and I guess this is just
> > > > wrong interpretation of old implementation - 'default key' is used
> > > > for static key. Key mapping key is used for dynamic keys.
> > >
> > > I don't think I understand the last paragraph?
> >
> > Nothing imporatant just that term 'default key' is used usually on in
> > context of static/legacy WEP key
> > while term 'key mapping key' is used for what I call dynamic key.
> >
> > >
> > > In any case, actual TX key selection is done by mac80211 anyway, so
> > > you're never interested in that. Only RX key selection is interesting to
> > > the driver, and as far as I can tell it ought to work if you simply
> > > always use the broadcast address key when it's WEP, and otherwise the
> > > pairwise keys and/or the broadcast key for bc/mc frames.
> >
> > Nothing to add to just that the assumption about WEP and broadcast is wrong.
> >
> > > Note that there's another case in AP mode where bc/mc keys are TX-only,
> > > those are added with a zeroed MAC address.
> >
> > I would prefer also in this case a clear flag rather then playing with
> > ambiguity of destination address.
> >
> > > johannes
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
T24gTW9uLCBNYXIgMTcsIDIwMDggYXQgNTowNCBQTSwgSm9oYW5uZXMgQmVyZwo8am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4KPiAgPiBUaGlzIGlzIG9ubHkgaW4gUlggc2lkZS4g
RWFjaCBBQyAoYWNjZXNzIGNhdGVnb3J5KSBxdWV1ZSB0cmFuc21pdCBpbgo+ICA+IGl0J3Mgb3du
IHJhdGUuIEZvciBleGFtcGxlIFZPIHRyYXNtaXR0cyBtb3JlIHBhY2tldHMgdGhlbiBCRS4gU28g
eW91Cj4gID4gbWlnaHQgZ2V0IGludG8gY2FzZSBpbiByZWNlaXZlIHNpdGUgdGhhdCBWTyBwYWNr
ZXRzIGFyZSBhbHJlYWR5IG9uCj4gID4gd3JhcGFyb3VuZCBzaWRlIHdoaWxlIEJFIGFyZSBzdGls
bCB1c2luZyAnb2xkJyBwaGFzZTEuCj4gID4gQmVzdCByZW1lZHkgaXMgdG8ga2VlcCBwaGFzZTEg
cGVyIGVhY2ggQUMuCj4gID4KPiAgPiA+ICBidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0b28gaW1w
b3J0YW50IGFzCj4gID4gPiAgbm9uLW1hdGNoaW5nIHdpbGwganVzdCBiZSBkb25lIGluIHNvZnR3
YXJlLgo+ICA+Cj4gID4gQ29ycmVjdCwgdGhpcyBzaG91bGQgaGFwcGVuIG9ubHkgZm9yIHNob3J0
IHBlcmlvZCBvZiB0aW1lIHRoYXQgcGgxCj4gID4gZG9lc24ndCBtYXRjaCBmb3IgZWFjaCBBQyBx
dWV1ZS4KPgo+ICBSaWdodCwgaW4gc29mdHdhcmUgd2UgY2FuIGtlZXAgYSBwaGFzZTEgcGVyIEFD
IGJ1dCB3ZSBkb24ndCBuZWVkIHRvIGluCj4gIGhhcmR3YXJlIHNpbmNlIHRoYXQncyBqdXN0IHRo
ZSBvcHRpbWlzYXRpb24uCgpDb3JyZWN0LCBJJ20ganVzdCBub3Qgc3VyZSBob3cgaXQncyBkb25l
IGZvciBiY29tIGNhcmRzLgo+Cj4gID4gPiAgSG93ZXZlciwgYmNvbSBmaXJtd2FyZSB3YW50cwo+
ICA+ID4gIHRvIGhhdmUganVzdCB0aGUgcGhhc2UgMSBrZXksIGFuZCBhcyBmYXIgYXMgSSBjYW4g
dGVsbCB0aGUgZHJpdmVyIGNhbid0LAo+ICA+ID4gIGV2ZW4gd2l0aCB5b3VyIHBhdGNoZXMsIG9i
dGFpbiBhIHBoYXNlIDEga2V5IGZvciBUWC4KPiAgPgo+ICA+IE5vdCBzdXJlIHRoZXNlIGNhc2Vz
IGFyZSBzeW1tZXRyaWMuIFlvdSBoYXZlIHRvIGhhdmUgcGhhc2UxIHJlYWR5IGluCj4gID4gSFcg
YmVmb3JlIHlvdSB0cmFuc21pdCB0aGUgcGFja2V0Cj4gID4gUGhhc2UxIG5lZWQgdG8gYmUgYWRo
ZXJlZCB0byBhIHBhY2tldCB0aGF0IGNhdXNlcyB3cmFwYXJvdW5kIHVubGlrZSBSWAo+ICA+IHRo
YXQgeW91IGNhbiBmYWxsIGJhY2sgdG8gU1cgZGVjcnlwdGlvbgo+ICA+IEluIFRYIHRoZXJlIGlz
IG5vIHdheSBiYWNrLgo+Cj4gIEdvb2QgcG9pbnQuIFNvIHRoZW4gZm9yIEJyb2FkY29tIHdlIGFj
dHVhbGx5IG5lZWQgdG8gdXBkYXRlIHBoYXNlMSBpbgo+ICBoYXJkd2FyZSB3aGVuIGl0IGNoYW5n
ZXMgb24gVFggYW5kIG5vdCBib3RoZXIgd2l0aCBSWCBhdCBhbGwsIHdlJ2xsIGZhbGwKPiAgYmFj
ayB0byBzb2Z0d2FyZSBpbiB0aGF0IGNhc2UuCgpFdmVudHVhbGx5IHlvdSB3YW50IHRvIHVwZGF0
ZSBSWCBwaGFzZTEga2V5IGludG8gSFcgc28geW91IGdldCB5b3VyCkNQVSB1dGlsaXphdGlvbiB3
aGVyZSBpdCBoYXZlIHRvIGJlLCByaWdodD8KCj4KPiAgPiA+ICA+ID4gIEhvdyBhYm91dCBpbnN0
ZWFkIHdlIGFkZCBhIG5ldyAidXBkYXRlX3RraXBfa2V5KCkiIGNhbGxiYWNrIHRoYXQgdGFrZXMK
PiAgPiA+ICA+ID4gIGV4YWN0bHkgdGhlIHJlcXVpcmVkIHBhcmFtZXRlcnM/IEl0IHNob3VsZCBh
bHNvIGdpdmUgdGhlCj4gID4gPiAgPiA+ICBoYXJkd2FyZS1rZXktaW5kZXggc28gdGhhdCB0aGUg
ZHJpdmVyIGhhcyBsZXNzIHdvcmsgdG8gZG8uCj4gID4gPiAgPgo+ICA+ID4gID4gSXQncyB2aWFi
bGUgYnV0IEkgYWN0dWFsbHkgcHJlZmVyIG5vdCBvcGVuaW5nIHRvbyBtYW55IGludGVyZmFjZXMu
Cj4gID4gPiAgPiBQbGVhc2UgZ2l2ZSBtZSBzb21lIG1vcmUgZGV0YWlsZWQgc2tldGNoIGhvdyBk
byB5b3Ugc2VlIHRoYXQgYW5kIHdlCj4gID4gPiAgPiBzdXJlIGdldCB0byBzb21lIGFjY2VwdGFi
bGUgc29sdXRpb24uCj4gID4gPgo+ICA+ID4gIFllcywgSSB3b3VsZCBwcmVmZXIgbm90IGhhdmlu
ZyB0aGF0IG1hbnkgaW50ZXJmYWNlcyBhcyB3ZWxsLCBidXQgSSBkb24ndAo+ICA+ID4gIHRoaW5r
IHNob2Vob3JuaW5nIGl0IGludG8gdGhlIHNldF9rZXkoKSBjYWxsYmFjayBpcyBhIGdvb2QgaWRl
YSBiZWNhdXNlCj4gID4gPiAgIChhKSB5b3UgYWRkIGZpZWxkcyB0byB0aGUga2V5IGNvbmYgc3Ry
dWN0dXJlIHRoYXQgYXJlIG9ubHkgdXNlZCBmb3IKPiAgPiA+ICAgICAgdGhlIHRraXAgc3R1ZmYg
YW5kIG9ubHkgdmFsaWQgaW4gc29tZSBjYWxscwo+ICA+ID4gICAoYikgdGhlIHBhdGNoIGJyZWFr
cyB0aGUgc2V0X2tleSgpIGludGVyZmFjZSdzIHN5bW1ldHJ5Cj4gID4gPgo+ICA+ID4gIEEgbmV3
IGNhbGxiYWNrIHVwZGF0ZV90a2lwX2tleSBjb3VsZCBsb29rIGxpa2UgdGhpczoKPiAgPiA+Cj4g
ID4gPiAgdm9pZCB1cGRhdGVfdGtpcF9waGFzZTFrZXkoaHcsIGtleWNvbmYsIGl2MzIsIHAxa2V5
KQo+ICA+Cj4gID4gV2hhdCBhYm91dAo+ICA+IGVudW0gdGtpcF91cGRhdGVfZmxhZ3Mgewo+ICA+
ICAgIFRLSVBfUEgxX1RYX0tFWQo+ICA+ICAgIFRLSVBfUEgxX1JYX0tFWQo+ICA+ICAgIFRLSVBf
UEgyX1RYX0tFWQo+ICA+ICAgIFRLSVBfUEgyX1JYX0tFWSAtLSBhY3R1YWxseSBubyBuZWVkIGZv
ciBhbnkgZHJpdmVyLgo+ICA+IH0KPiAgPiAgIHVwZGF0ZV90a2lwX2tleShodywga2V5Y29uZiAs
IGl2MzIsICBmbGFnLCBrZXkpCj4gID4KPiAgPiBCdXQgSSdtIG5vdCBzdXJlIGFib3V0IHRoaXMu
Li4gc2VlIGFib3ZlL2JlbG92ZQo+ICA+Cj4gID4gPiAgVGhlIO+7v0lFRUU4MDIxMV9LRVlfRkxB
R19US0lQX1BIQVNFMV9WQUxJRCBmbGFnIHdvdWxkIGdvIGF3YXksIGFuZCB0aGUKPiAgPiA+ICBu
ZXcgY2FsbGJhY2sgd291bGQgYmUgaW52b2tlZCByaWdodCBmcm9tIHdoZXJlIHRoZSBwaGFzZTEg
a2V5IGlzCj4gID4gPiAgY2FsY3VsYXRlZC4KPiAgPgo+ICA+IFN1cmUgYWdhaW4gSSdtIG5vdCBz
dXJlIHRoaXMgaXMgc3ltbWV0cmljIC0gRm9yIFRYIGl0IHdvdWxkIGJlIHNhZmVyCj4gID4gdG8g
ZG8gcHVsbCBtb2RlIG90aGVyd2lzZSBpdCBjYW4gZ2V0IG91dCBvZiBzeW5jLgo+Cj4gIFRydWUu
IEhlbmNlLCBzaW5jZSBwaGFzZTJyeCBpcyBub3QgcmVhbGx5IHVzZWZ1bCwgd2UgZG9uJ3QgYWN0
dWFsbHkgbmVlZAo+ICBhbnkgc29ydCBvZiB1cGRhdGUgZmxhZ3Mgd2hlbiB3ZSBkbyB0aGUgVFgg
a2V5cyBpbiBwdWxsIG1vZGUsIHdoaWNoIEkKPiAgcHJlZmVyIGFueXdheS4KPgo+Cj4gID4gPiAg
SSdtIG5vdCBleGFjdGx5IHN1cmUgd2hldGhlciBvbmUgbmVlZHMgYSBwaGFzZTEga2V5IGZvciBS
WCBhbmQgb25lIGZvcgo+ICA+ID4gIFRYIHJpZ2h0IG5vdywgYnV0IGlmIHNvIGEgZGlyZWN0aW9u
IGZsYWcgc2hvdWxkIGJlIGFkZGVkPwo+ICA+Cj4gID4gUGhhc2UxIGZvciBUWCBhbmQgUlggYXJl
IG5vdCB0aGUgc2FtZSwgYWdhaW4gYmVjYXVzZSBvZiB0aGUgc2ltcGxlCj4gID4gcmVhc29uZSB0
aGF0IG51bWJlciBvZiB0cmFuc21pdHRlZCBhbmQgcmVjZWl2ZWQgcGFja2V0IGlzIG5vdCB0aGUK
PiAgPiBzYW1lLgo+Cj4gIEhtLCByaWdodC4gQnV0IGlmIHdlIGdvIGZvciBwdWxsIG1vZGUgZm9y
IFRYLCB3ZSBvbmx5IG5lZWQgdG8gaGF2ZSBwdXNoCj4gIG1vZGUgZm9yIHRoZSBwaGFzZTEgcngg
a2V5IHdoZW4gdGhhdCBjaGFuZ2VzLCBubz8KCkVtbWFudWVsIGhhcyBwcmVwYXJlZCBwYXRjaGVz
IGZvciBUWCBwdWxsIG1vZGUgIChwaGFzZTIgb25seSBmb3Igbm93KSAuCklmIHRoaXMgT0sgd2lp
dGggSSB3aWxsIHJlc2VuZCB0aGUgd2hvbGUgVEtJUCBzZXJpZXMgd2l0aCB0aGlzIGNoYW5nZSwK
bGVhdmluZyBSWCBpbiBwdWxsIG1vZGUuCldlIGNhbiBkbyBsaXR0bGUgZWZmb3J0IHRvIGFkZCBw
dWxsaW5nIHBoYXNlMSBvbmx5IGJ1dCB3ZSBjYW5ub3QgcmVhbGx5IHRlc3QgaXQuCgpUaGFua3MK
VG9tYXMK
> > > This is actually quite a bug in mac80211. There is substantial
> > > difference between dynamic and static key.
> > > While static key is used for crypto of all stations in BSS. Dynamic
> > > key is also called pairwise key and is generated for 'pair'
> >
> > Gee, can you then please stick to terminology used in the spec so other
> > people can understand it?
>
> What spec. ieee80211i. WPA, WPA2? .
Preferably one that is actually readable to mere mortals (unlike WPA...)
> > Actually, you're making it look like a much larger problem than it is.
> > If you assume anything WEP is a "static key" and everything else is a
> > "dynamic key" (using your terminology), the only problem will be with
> > dynamic WEP, and even then it's not really a problem because as far as I
> > understand even dynamic WEP doesn't distinguish between group and
> > pairwise keys.
>
> This is incorrect. WPA enable using WEP as dynamic key and this
> setting is very common.
> WEP key is enabled for legacy stations this force also broadcast to be
> WEP. This setup is still quite common.
I have no idea about WPA's non-IEEE modes. I don't seem to be able to
find such a thing in the IEEE spec so you'll have to actually elaborate
on this.
> > In any case, actual TX key selection is done by mac80211 anyway, so
> > you're never interested in that. Only RX key selection is interesting to
> > the driver, and as far as I can tell it ought to work if you simply
> > always use the broadcast address key when it's WEP, and otherwise the
> > pairwise keys and/or the broadcast key for bc/mc frames.
>
> Nothing to add to just that the assumption about WEP and broadcast is wrong.
> > Note that there's another case in AP mode where bc/mc keys are TX-only,
> > those are added with a zeroed MAC address.
>
> I would prefer also in this case a clear flag rather then playing with
> ambiguity of destination address.
Yes, that would indeed help. Except that WEXT can't actually give you
the distinction so discussing these points right now is pretty moot when
we can't even do it properly as far as I can tell. Might be possible to
infer the information with the key management enabled flag thing...
johannes
> iwlwifi firmware also derive phase2 in RX path by itself since this is
> not really possible to do in host level.
Right. I just wonder why then it needs the host to derive the phase 2
key for TX, that seems pretty strange. Seems to me a bit like a "what
can we do" design decision rather than "what makes sense".
> However in case of non
> matching iv32 such as wraparound it passes packet up unencrypted.
That makes sense.
> Therefore HW decryption
> have to be always backed up by SW one.
Obviously, yes.
> Wraparound of Iv32 is reliable only if decryption of a the packet that
> triggers it is correct. If this is not done and phase1 is advanced by
> mistake it breaks traffic till the next wraparound actually it will
> effectively cause disconnection.
Good point. But let's not overload set_key() for it this way. This way,
the driver needs to look up the key etc. and the semantics get quite
mangled up. Also, your approach doesn't work for Broadcom hardware that
only needs phase 1 keys for both RX and TX.
How about instead we add a new "update_tkip_key()" callback that takes
exactly the required parameters? It should also give the
hardware-key-index so that the driver has less work to do.
johannes
On Sat, Mar 15, 2008 at 9:11 PM, Johannes Berg
<[email protected]> wrote:
>
> On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> > From: Emmanuel Grumbach <[email protected]>
> >
> > This patch makes mac80211 able to send a phase1 key for TKIP decryption.
> > This is needed for drivers that don't do the rekeying by themselves
> > (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
> > decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
>
>
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
> > * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
> > * the driver for a TKIP key if it requires a phase2 TX key generation
> > * in SW. The key will be attached to each packet.
> > + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
> > + * for a TKIP key if it requires phase 1 key generation in software.
> > + * The phase 1 key will be sent in the same context as Rx.
> > + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
> > + * IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
> > + * fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
>
> This really breaks the set_key() model of having always one set_key()
> call to add the key and another one to remove it again.
>
> I think it would be much more appropriate to handle this in the driver
> by exporting an appropriate phase1 mixing function that takes the
> key_conf, iv16, RX vs. TX flag, and for RX the queue number as
> arguments. The RX vs. TX flag could be used by the b43 driver since that
> hardware can actually derive the phase2 key by itself.
iwlwifi firmware also derive phase2 in RX path by itself since this is
not really possible to do in host level. However in case of non
matching iv32 such as wraparound it passes packet up unencrypted. And
there are some more esoteric cases when packet when SW decryption is
more efficient such as very short packets. Therefore HW decryption
have to be always backed up by SW one.
Wraparound of Iv32 is reliable only if decryption of a the packet that
triggers it is correct. If this is not done and phase1 is advanced by
mistake it breaks traffic till the next wraparound actually it will
effectively cause disconnection. Your suggestion will requires to
move also decryption into driver levelm not only phase1 generation. So
it's rather no go solution
> I think for advanced features like crypto hardware acceleration or
> similar we should deviate from the "push" model mac80211 has for most
> things (and which you also implemented here) so we don't end up creating
> special flags for all possible different hardware. A "pull" model is
> much more scalable here.
I agree in general but in this specific case this will cause much more
data movement than few flags.
Thanks
Tomas
> johannes
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ipw3945-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>
> >
> > > BSS defines security setting which defined by key management for
> > > pairwise and group key + cipher method for both .
> > > You can run multiple SSIDs over single single BSSID. This is done
> > > using VLANs
> >
> > Actually, we don't support that in mac80211.
> Last time I worked on AP project it worked. It was older mac hopefully
> it's not totally broken
>
> And the way I understand
> > VLANs they are simply done by negotiating different group keys with
> > different groups of stations each forming a VLAN.
>
> We are saying the same. That's okay.
Well, you were suggesting the use of multiple SSIDs, which we don't
support, we only support VLANs within a BSS/single SSID. Not that I've
been able to test it, hostapd needs radius stuff set up for VLANs...
> > > So you can maintain multiple security settings in for one
> > > AP. However this is not possible when using static WEP since the key
> > > is global and the key is not attached to any address.
> > >
> > > There are more details into it I'm sorry if I'm not 100 clear here.
> > > The bottom line is that you don't need more 4 WEP keys both in AP and
> > > station mod. Same you need to maintain only one pairwise key for
> > > station both in AP and STA mode. In AP mode you need to maintain also
> > > one group key for each station because of the case of multiple SSIDs.
> >
> > Except the group keys don't really matter for an AP since they're TX
> > only, which is why we add them with a zeroed MAC address and can only
> > select them for TX
> .
> Zero address again :)
>
> >
> >
> > > Nop. Still you can have <WEP, WEP> for <pairwise,group key> valid
> > > setting - This is not static key. The two keys may differ. Under your
> > > assumption the group key will override pairwise key
> >
> > Hm, ok. So I suppose the only way to determine "static" right now would
> > be to check that no pairwise keys are configured at all.
>
> I'm not sure if I follow here but I think the simples way to determine
> if static key is set is to set static_key flag to 1. I don't see any
> reason this can be directly detected from the configuration.
Right. I was just saying that the way it currently is I think you could
detect it that way. b43 simply assumes WEP keys are always 'static'
which seems to mostly work well in practice.
I suppose then set_key needs a new argument key_type:
enum ieee80211_key_type {
KEY_TYPE_PAIRWISE,
KEY_TYPE_GROUP,
KEY_TYPE_TXONLY, /* group key in an AP */
KEY_TYPE_STATIC,
}
where the MAC address pointer would only be non-NULL when the key type
is PAIRWISE, and STATIC can only be used for WEP keys.
johannes
On Sat, Mar 15, 2008 at 4:38 PM, Johannes Berg
<[email protected]> wrote:
>
> On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> > From: Emmanuel Grumbach <[email protected]>
> >
> > This patch makes the mac80211 able to send a ready phase2 key to the low
> > level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
> > encrypt TX packets in HW.
>
>
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -287,6 +287,7 @@ struct ieee80211_tx_control {
> > u8 iv_len; /* length of the IV field in octets */
> > u8 queue; /* hardware queue to use for this frame;
> > * 0 = highest, hw->queues-1 = lowest */
> > + u8 tkip_key[16]; /* generated phase2/phase1 key for hw TKIP */
>
> I have to admit that I'm rather uncomfortable with adding this code to
> the stack. Not only because that is a rather large field that most other
> drivers will not use, but also because it doesn't cover the use case the
> Broadcom driver needs (only phase 1 key generated). Also, I don't think
> we should take the "push" model to the extreme, that will just
> complicate things in the future.
>
> As for the transmit path here, we can trivially export
> ieee80211_tkip_gen_rc4key() and, because key_conf is embedded in struct
> ieee80211_key, give it a key_conf parameter that the driver knows about
> from set_key(). That way, the driver can call that function for each
> packet instead of having the stack do that, it only has to keep track of
> the keys which it will most likely anyway.
You might be right here we are investigating whether there are no
holes in this.
> Also, looking at what you do here, I found this comment:
> /* FIXME: need to differenciate between static and dynamic key
> * in the level of mac80211 */
> static_key = !iwl4965_is_associated(priv);
>
> I think that is pretty bogus because there isn't really a distinction
> between dynamic and static keys, what's the reason for differentiating
> in the driver? Also, the driver will do rather odd things when
> * associate
> * set a key
> * disassociate
> * delete the key
>
This is actually quite a bug in mac80211. There is substantial
difference between dynamic and static key.
While static key is used for crypto of all stations in BSS. Dynamic
key is also called pairwise key and is generated for 'pair'
Currently mac80211 set static key with broadcast address which iis
wrong cause driver cannot distinguish whether this key is
multicast/broadcast dynamic key or a static key. Shell it use it for
all traffic or only for mcast/bcast? Who can tell?
Other difference while there can be 4 static key installed that the
same time possible switching between indexes There can be only one
dynamic key per station if you also consider mcast/bcast station to be
an entity. (TKIP actally uses different key index for bcast but
that's just little execption)
The terminology which is used is also wrong and I guess this is just
wrong interpretation of old implementation - 'default key' is used
for static key. Key mapping key is used for dynamic keys.
Thanks
Tomas
> johannes
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ipw3945-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>
From: Emmanuel Grumbach <[email protected]>
This patch makes mac80211 able to send a phase1 key for TKIP decryption.
This is needed for drivers that don't do the rekeying by themselves
(i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
include/net/mac80211.h | 10 ++++++++++
net/mac80211/tkip.c | 19 +++++++++++++++++--
net/mac80211/tkip.h | 1 +
net/mac80211/wpa.c | 12 ++++++++++++
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a0c7cd7..3b5d57c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -590,12 +590,20 @@ enum ieee80211_key_alg {
* @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
* the driver for a TKIP key if it requires a phase2 TX key generation
* in SW. The key will be attached to each packet.
+ * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
+ * for a TKIP key if it requires phase 1 key generation in software.
+ * The phase 1 key will be sent in the same context as Rx.
+ * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
+ * IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
+ * fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_WMM_STA = 1<<0,
IEEE80211_KEY_FLAG_GENERATE_IV = 1<<1,
IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY = 1<<3,
+ IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY = 1<<4,
+ IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID = 1<<5,
};
/**
@@ -619,6 +627,8 @@ struct ieee80211_key_conf {
u8 flags;
s8 keyidx;
u8 keylen;
+ u16 tkip_p1k[5];
+ u8 tkip_iv32;
u8 key[0];
};
diff --git a/net/mac80211/tkip.c b/net/mac80211/tkip.c
index 18a3fb0..f61f1dd 100644
--- a/net/mac80211/tkip.c
+++ b/net/mac80211/tkip.c
@@ -171,7 +171,7 @@ u8 *ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key)
return pos;
}
-static void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta,
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta,
u8 *rc4key)
{
/* Calculate per-packet key */
@@ -263,7 +263,8 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
return TKIP_DECRYPT_REPLAY;
}
- if (only_iv) {
+ if (only_iv &&
+ !(key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY)) {
res = TKIP_DECRYPT_OK;
key->u.tkip.rx_initialized[queue] = 1;
goto done;
@@ -275,6 +276,14 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
/* IV16 wrapped around - perform TKIP phase 1 */
tkip_mixing_phase1(ta, &key->conf.key[ALG_TKIP_TEMP_ENCR_KEY],
iv32, key->u.tkip.p1k_rx[queue]);
+ if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY) {
+ /* The driver needs a phase 1 key, provide it */
+ memcpy(&key->conf.tkip_p1k,
+ &key->u.tkip.p1k_rx[queue],
+ sizeof(key->conf.tkip_p1k));
+ key->conf.tkip_iv32 = iv32;
+ key->conf.flags |= IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID;
+ }
#ifdef CONFIG_TKIP_DEBUG
{
int i;
@@ -294,6 +303,12 @@ int ieee80211_tkip_decrypt_data(struct crypto_blkcipher *tfm,
#endif /* CONFIG_TKIP_DEBUG */
}
+ if (only_iv) {
+ res = TKIP_DECRYPT_OK;
+ key->u.tkip.rx_initialized[queue] = 1;
+ goto done;
+ }
+
tkip_mixing_phase2(key->u.tkip.p1k_rx[queue],
&key->conf.key[ALG_TKIP_TEMP_ENCR_KEY],
iv16, rc4key);
diff --git a/net/mac80211/tkip.h b/net/mac80211/tkip.h
index 662354b..9a07102 100644
--- a/net/mac80211/tkip.h
+++ b/net/mac80211/tkip.h
@@ -14,6 +14,7 @@
#include "ieee80211_key.h"
u8 * ieee80211_tkip_add_iv(u8 *pos, struct ieee80211_key *key);
+void ieee80211_tkip_gen_rc4key(struct ieee80211_key *key, u8 *ta, u8 *rc4key);
void ieee80211_tkip_encrypt_data(struct crypto_blkcipher *tfm,
struct ieee80211_key *key,
u8 *pos, size_t payload_len, u8 *ta);
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index ee9c5cf..478251b 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -324,6 +324,18 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
return RX_DROP_UNUSABLE;
}
+ if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+ u8 bcast[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+ u8 *sta_addr = rx->sta->addr;
+
+ if (is_multicast_ether_addr(hdr->addr1))
+ sta_addr = bcast;
+
+ rx->local->ops->set_key(local_to_hw(rx->local),
+ SET_KEY, rx->dev->dev_addr, sta_addr, &key->conf);
+ key->conf.flags &= ~IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID;
+ }
+
/* Trim ICV */
skb_trim(skb, skb->len - TKIP_ICV_LEN);
--
1.5.3.4
On Mon, 2008-03-17 at 14:49 +0100, Johannes Berg wrote:
> > > Huh ok. But how would the WEP legacy station be able to determine that?
> >
> > Legacy user get the key written on 'positit' yellow paper :).
>
> Heh yeah.
>
> > > Or does it just try to use WEP and succeed? TBH, I was unaware that this
> > > existed, this does make it a bit more of a problem than I thought then.
> > >
> >
> > > >
> > > > On second thought is that AP has only TX group key while STA has only
> > > > RX group key so I
> > > > m not seeing here any need for flag.
> > >
> > > Hm, well, I didn't really want to require the driver to keep track of
> > > the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
> > > for the group keys.
> >
> > Isn't if on integer faster then comparing 6 bytes?
>
> Probably. Does it matter though? Setting keys isn't going to be
> performance critical in any way.
>
> > > Is that really done though? I mean, does wpa_supplicant not also use
> > > encodeext for WEP keys?
> > >
> > Unfortunately yes.
>
> So that doesn't really help us either way, no?
>
> > First of all we don't need 4 keys per station but for the whole
> > system.
>
> Not sure I understand this. You need pairwise (per-station) keys as well
> as four default keys, no?
>
> > Even in AP mode with multiple SSID meaning multiple security
> > setting you cannot distinguish between networks in static WEP key
> > setting so 4 is enough.
>
> Not sure I get what you're thinking here.
>
> > Beside that you need place holder for group key. They might be
> > multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
> > doesn't support it in HW but in general it is possible.
>
> Well, no, because we can add multiple keys with a zeroed MAC address,
> since we have the local MAC address in there as well. Also, in an AP,
> these are only used for TX so it doesn't matter since mac80211 does the
> key selection completely on its own.
>
> > We need a flag in set_key which says whether the WEP key is static or not.
>
> Let's actually try to gather all the cases first.
>
> Is this it?
>
> * TKIP/CCMP/WEP group or pairwise key
> * WEP legacy ('static') key
So the problem with this is, how does Dynamic WEP work here? Dynamic
WEP uses 802.1x/EAP to rekey stations periodically just like
WPA[2]-Enterprise, but of courses uses WEP only. It's not "static" WEP
as you guys have been talking about it (you could call static WEP
"WEP-PSK" if you like).
The problem here is that with WEXT, there's not a good way to
distinguish between the two. Both static & dynamic WEP might look the
same to the driver when the call comes through SIWENCODE/SIWENCODEEXT.
So you've got to be careful here classifying all WEP key requests as
static.
Dan
> where the first is completely covered by what we have now and the
> assumption is that if only WEP keys are present then it'll be a legacy
> WEP key?
>
> johannes
T24gTW9uLCBNYXIgMTcsIDIwMDggYXQgMzoxMyBQTSwgSm9oYW5uZXMgQmVyZwo8am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldD4gd3JvdGU6Cj4KPiAgPiA+ICBHb29kIHBvaW50LiBCdXQgbGV0J3Mg
bm90IG92ZXJsb2FkIHNldF9rZXkoKSBmb3IgaXQgdGhpcyB3YXkuIFRoaXMgd2F5LAo+ICA+ID4g
IHRoZSBkcml2ZXIgbmVlZHMgdG8gbG9vayB1cCB0aGUga2V5IGV0Yy4gYW5kIHRoZSBzZW1hbnRp
Y3MgZ2V0IHF1aXRlCj4gID4gPiAgbWFuZ2xlZCB1cC4gQWxzbywgeW91ciBhcHByb2FjaCBkb2Vz
bid0IHdvcmsgZm9yIEJyb2FkY29tIGhhcmR3YXJlIHRoYXQKPiAgPiA+ICBvbmx5IG5lZWRzIHBo
YXNlIDEga2V5cyBmb3IgYm90aCBSWCBhbmQgVFguCj4gID4KPiAgPiBDYW4geW91IGVsYWJvcmF0
ZSB3aHkgaXQgZG9lc24ndCBjb3ZlciBiY29tIGNhc2U/Cj4KPiAgSSBkb24ndCBxdWl0ZSB1bmRl
cnN0YW5kIHRoZSBwaGFzZSAxIGtleSBkZXJpdmF0aW9uIGFuZCB3aHkgaXQgaXMgZG9uZQo+ICBm
b3IgZWFjaCBETUEgcXVldWUsClRoaXMgaXMgb25seSBpbiBSWCBzaWRlLiBFYWNoIEFDIChhY2Nl
c3MgY2F0ZWdvcnkpIHF1ZXVlIHRyYW5zbWl0IGluCml0J3Mgb3duIHJhdGUuIEZvciBleGFtcGxl
IFZPIHRyYXNtaXR0cyBtb3JlIHBhY2tldHMgdGhlbiBCRS4gU28geW91Cm1pZ2h0IGdldCBpbnRv
IGNhc2UgaW4gcmVjZWl2ZSBzaXRlIHRoYXQgVk8gcGFja2V0cyBhcmUgYWxyZWFkeSBvbgp3cmFw
YXJvdW5kIHNpZGUgd2hpbGUgQkUgYXJlIHN0aWxsIHVzaW5nICdvbGQnIHBoYXNlMS4KQmVzdCBy
ZW1lZHkgaXMgdG8ga2VlcCBwaGFzZTEgcGVyIGVhY2ggQUMuCgpidXQgSSB0aGluayB0aGlzIGlz
IG5vdCB0b28gaW1wb3J0YW50IGFzCj4gIG5vbi1tYXRjaGluZyB3aWxsIGp1c3QgYmUgZG9uZSBp
biBzb2Z0d2FyZS4KCkNvcnJlY3QsIHRoaXMgc2hvdWxkIGhhcHBlbiBvbmx5IGZvciBzaG9ydCBw
ZXJpb2Qgb2YgdGltZSB0aGF0IHBoMQpkb2Vzbid0IG1hdGNoIGZvciBlYWNoIEFDIHF1ZXVlLgoK
IEhvd2V2ZXIsIGJjb20gZmlybXdhcmUgd2FudHMKPiAgdG8gaGF2ZSBqdXN0IHRoZSBwaGFzZSAx
IGtleSwgYW5kIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBkcml2ZXIgY2FuJ3QsCj4gIGV2ZW4g
d2l0aCB5b3VyIHBhdGNoZXMsIG9idGFpbiBhIHBoYXNlIDEga2V5IGZvciBUWC4KCk5vdCBzdXJl
IHRoZXNlIGNhc2VzIGFyZSBzeW1tZXRyaWMuIFlvdSBoYXZlIHRvIGhhdmUgcGhhc2UxIHJlYWR5
IGluCkhXIGJlZm9yZSB5b3UgdHJhbnNtaXQgdGhlIHBhY2tldApQaGFzZTEgbmVlZCB0byBiZSBh
ZGhlcmVkIHRvIGEgcGFja2V0IHRoYXQgY2F1c2VzIHdyYXBhcm91bmQgdW5saWtlIFJYCnRoYXQg
eW91IGNhbiBmYWxsIGJhY2sgdG8gU1cgZGVjcnlwdGlvbgpJbiBUWCB0aGVyZSBpcyBubyB3YXkg
YmFjay4KCj4KPiAgPiA+ICBIb3cgYWJvdXQgaW5zdGVhZCB3ZSBhZGQgYSBuZXcgInVwZGF0ZV90
a2lwX2tleSgpIiBjYWxsYmFjayB0aGF0IHRha2VzCj4gID4gPiAgZXhhY3RseSB0aGUgcmVxdWly
ZWQgcGFyYW1ldGVycz8gSXQgc2hvdWxkIGFsc28gZ2l2ZSB0aGUKPiAgPiA+ICBoYXJkd2FyZS1r
ZXktaW5kZXggc28gdGhhdCB0aGUgZHJpdmVyIGhhcyBsZXNzIHdvcmsgdG8gZG8uCj4gID4KPiAg
PiBJdCdzIHZpYWJsZSBidXQgSSBhY3R1YWxseSBwcmVmZXIgbm90IG9wZW5pbmcgdG9vIG1hbnkg
aW50ZXJmYWNlcy4KPiAgPiBQbGVhc2UgZ2l2ZSBtZSBzb21lIG1vcmUgZGV0YWlsZWQgc2tldGNo
IGhvdyBkbyB5b3Ugc2VlIHRoYXQgYW5kIHdlCj4gID4gc3VyZSBnZXQgdG8gc29tZSBhY2NlcHRh
YmxlIHNvbHV0aW9uLgo+Cj4gIFllcywgSSB3b3VsZCBwcmVmZXIgbm90IGhhdmluZyB0aGF0IG1h
bnkgaW50ZXJmYWNlcyBhcyB3ZWxsLCBidXQgSSBkb24ndAo+ICB0aGluayBzaG9laG9ybmluZyBp
dCBpbnRvIHRoZSBzZXRfa2V5KCkgY2FsbGJhY2sgaXMgYSBnb29kIGlkZWEgYmVjYXVzZQo+ICAg
KGEpIHlvdSBhZGQgZmllbGRzIHRvIHRoZSBrZXkgY29uZiBzdHJ1Y3R1cmUgdGhhdCBhcmUgb25s
eSB1c2VkIGZvcgo+ICAgICAgdGhlIHRraXAgc3R1ZmYgYW5kIG9ubHkgdmFsaWQgaW4gc29tZSBj
YWxscwo+ICAgKGIpIHRoZSBwYXRjaCBicmVha3MgdGhlIHNldF9rZXkoKSBpbnRlcmZhY2UncyBz
eW1tZXRyeQo+Cj4gIEEgbmV3IGNhbGxiYWNrIHVwZGF0ZV90a2lwX2tleSBjb3VsZCBsb29rIGxp
a2UgdGhpczoKPgo+ICB2b2lkIHVwZGF0ZV90a2lwX3BoYXNlMWtleShodywga2V5Y29uZiwgaXYz
MiwgcDFrZXkpCgpXaGF0IGFib3V0CmVudW0gdGtpcF91cGRhdGVfZmxhZ3MgewogICBUS0lQX1BI
MV9UWF9LRVkKICAgVEtJUF9QSDFfUlhfS0VZCiAgIFRLSVBfUEgyX1RYX0tFWQogICBUS0lQX1BI
Ml9SWF9LRVkgLS0gYWN0dWFsbHkgbm8gbmVlZCBmb3IgYW55IGRyaXZlci4KfQogIHVwZGF0ZV90
a2lwX2tleShodywga2V5Y29uZiAsIGl2MzIsICBmbGFnLCBrZXkpCgpCdXQgSSdtIG5vdCBzdXJl
IGFib3V0IHRoaXMuLi4gc2VlIGFib3ZlL2JlbG92ZQoKPiAgVGhlIO+7v0lFRUU4MDIxMV9LRVlf
RkxBR19US0lQX1BIQVNFMV9WQUxJRCBmbGFnIHdvdWxkIGdvIGF3YXksIGFuZCB0aGUKPiAgbmV3
IGNhbGxiYWNrIHdvdWxkIGJlIGludm9rZWQgcmlnaHQgZnJvbSB3aGVyZSB0aGUgcGhhc2UxIGtl
eSBpcwo+ICBjYWxjdWxhdGVkLgoKU3VyZSBhZ2FpbiBJJ20gbm90IHN1cmUgdGhpcyBpcyBzeW1t
ZXRyaWMgLSBGb3IgVFggaXQgd291bGQgYmUgc2FmZXIKdG8gZG8gcHVsbCBtb2RlIG90aGVyd2lz
ZSBpdCBjYW4gZ2V0IG91dCBvZiBzeW5jLgoKPiAgSSdtIG5vdCBleGFjdGx5IHN1cmUgd2hldGhl
ciBvbmUgbmVlZHMgYSBwaGFzZTEga2V5IGZvciBSWCBhbmQgb25lIGZvcgo+ICBUWCByaWdodCBu
b3csIGJ1dCBpZiBzbyBhIGRpcmVjdGlvbiBmbGFnIHNob3VsZCBiZSBhZGRlZD8KClBoYXNlMSBm
b3IgVFggYW5kIFJYIGFyZSBub3QgdGhlIHNhbWUsIGFnYWluIGJlY2F1c2Ugb2YgdGhlIHNpbXBs
ZQpyZWFzb25lIHRoYXQgbnVtYmVyIG9mIHRyYW5zbWl0dGVkIGFuZCByZWNlaXZlZCBwYWNrZXQg
aXMgbm90IHRoZQpzYW1lLgoKPiAgam9oYW5uZXMKPgo=
On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> From: Emmanuel Grumbach <[email protected]>
>
> This patch makes the mac80211 able to send a ready phase2 key to the low
> level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
> encrypt TX packets in HW.
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -287,6 +287,7 @@ struct ieee80211_tx_control {
> u8 iv_len; /* length of the IV field in octets */
> u8 queue; /* hardware queue to use for this frame;
> * 0 = highest, hw->queues-1 = lowest */
> + u8 tkip_key[16]; /* generated phase2/phase1 key for hw TKIP */
I have to admit that I'm rather uncomfortable with adding this code to
the stack. Not only because that is a rather large field that most other
drivers will not use, but also because it doesn't cover the use case the
Broadcom driver needs (only phase 1 key generated). Also, I don't think
we should take the "push" model to the extreme, that will just
complicate things in the future.
As for the transmit path here, we can trivially export
ieee80211_tkip_gen_rc4key() and, because key_conf is embedded in struct
ieee80211_key, give it a key_conf parameter that the driver knows about
from set_key(). That way, the driver can call that function for each
packet instead of having the stack do that, it only has to keep track of
the keys which it will most likely anyway.
Also, looking at what you do here, I found this comment:
/* FIXME: need to differenciate between static and dynamic key
* in the level of mac80211 */
static_key = !iwl4965_is_associated(priv);
I think that is pretty bogus because there isn't really a distinction
between dynamic and static keys, what's the reason for differentiating
in the driver? Also, the driver will do rather odd things when
* associate
* set a key
* disassociate
* delete the key
johannes
>
> You mean "RX in push mode" I think. Could you change that to a new
> callback or so then as we discussed?
Yes
> johannes
>
From: Emmanuel Grumbach <[email protected]>
This patch cleans up the set_key flow. Rxon with hw encryption bit set is
not sent upon each call to set_key. Separation is made between global key
(WEP) and dynamic key (TKIP + CCMP and WEP in some cases).
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl-4965-commands.h | 1 +
drivers/net/wireless/iwlwifi/iwl4965-base.c | 159 ++++++++++++++-------
2 files changed, 107 insertions(+), 53 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
index 1025ffe..085d813 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
@@ -741,6 +741,7 @@ struct iwl4965_qosparam_cmd {
/* wep key in STA: 5-bytes (0) or 13-bytes (1) */
#define STA_KEY_FLG_KEY_SIZE_MSK __constant_cpu_to_le16(0x1000)
#define STA_KEY_MULTICAST_MSK __constant_cpu_to_le16(0x4000)
+#define STA_KEY_MAX_NUM 8
/* Flags indicate whether to modify vs. don't change various station params */
#define STA_MODIFY_KEY_MASK 0x01
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index 396940e..d47941d 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -815,6 +815,17 @@ out:
return ret;
}
+static void iwl4965_set_rxon_hwcrypto(struct iwl_priv *priv, int hw_decrypt)
+{
+ struct iwl4965_rxon_cmd *rxon = &priv->staging_rxon;
+
+ if (hw_decrypt)
+ rxon->filter_flags &= ~RXON_FILTER_DIS_DECRYPT_MSK;
+ else
+ rxon->filter_flags |= RXON_FILTER_DIS_DECRYPT_MSK;
+
+}
+
int iwl4965_send_cmd(struct iwl_priv *priv, struct iwl4965_host_cmd *cmd)
{
if (cmd->meta.flags & CMD_ASYNC)
@@ -1180,6 +1191,7 @@ static int iwl4965_commit_rxon(struct iwl_priv *priv)
le16_to_cpu(priv->staging_rxon.channel),
print_mac(mac, priv->staging_rxon.bssid_addr));
+ iwl4965_set_rxon_hwcrypto(priv, iwl4965_param_hwcrypto);
/* Apply the new configuration */
rc = iwl4965_send_cmd_pdu(priv, REPLY_RXON,
sizeof(struct iwl4965_rxon_cmd), &priv->staging_rxon);
@@ -1392,33 +1404,36 @@ int iwl4965_send_add_station(struct iwl_priv *priv,
return rc;
}
-static int iwl4965_update_sta_key_info(struct iwl_priv *priv,
+static int iwl4965_set_ccmp_dynamic_key_info(struct iwl_priv *priv,
struct ieee80211_key_conf *keyconf,
u8 sta_id)
{
unsigned long flags;
__le16 key_flags = 0;
- switch (keyconf->alg) {
- case ALG_CCMP:
- key_flags |= STA_KEY_FLG_CCMP;
- key_flags |= cpu_to_le16(
- keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
- key_flags &= ~STA_KEY_FLG_INVALID;
- break;
- case ALG_TKIP:
- case ALG_WEP:
- default:
- return -EINVAL;
- }
+ key_flags |= (STA_KEY_FLG_CCMP | STA_KEY_FLG_MAP_KEY_MSK);
+ key_flags |= cpu_to_le16(keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
+
+ if (sta_id == priv->hw_setting.bcast_sta_id)
+ key_flags |= STA_KEY_MULTICAST_MSK;
+
+ keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+ keyconf->hw_key_idx = sta_id;
+
+ key_flags &= ~STA_KEY_FLG_INVALID;
+
spin_lock_irqsave(&priv->sta_lock, flags);
priv->stations[sta_id].keyinfo.alg = keyconf->alg;
priv->stations[sta_id].keyinfo.keylen = keyconf->keylen;
+
memcpy(priv->stations[sta_id].keyinfo.key, keyconf->key,
keyconf->keylen);
memcpy(priv->stations[sta_id].sta.key.key, keyconf->key,
keyconf->keylen);
+
+ priv->stations[sta_id].sta.key.key_offset
+ = (sta_id % STA_KEY_MAX_NUM);/*FIXME*/
priv->stations[sta_id].sta.key.key_flags = key_flags;
priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
@@ -1426,8 +1441,15 @@ static int iwl4965_update_sta_key_info(struct iwl_priv *priv,
spin_unlock_irqrestore(&priv->sta_lock, flags);
IWL_DEBUG_INFO("hwcrypto: modify ucode station key info\n");
- iwl4965_send_add_station(priv, &priv->stations[sta_id].sta, 0);
- return 0;
+ return iwl4965_send_add_station(priv,
+ &priv->stations[sta_id].sta, CMD_ASYNC);
+}
+
+static int iwl4965_set_tkip_dynamic_key_info(struct iwl_priv *priv,
+ struct ieee80211_key_conf *keyconf,
+ u8 sta_id)
+{
+ return -EOPNOTSUPP;
}
static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
@@ -1447,6 +1469,46 @@ static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
return 0;
}
+static int iwl4965_set_dynamic_key(struct iwl_priv *priv,
+ struct ieee80211_key_conf *key, u8 sta_id)
+{
+ int ret;
+
+ switch (key->alg) {
+ case ALG_CCMP:
+ ret = iwl4965_set_ccmp_dynamic_key_info(priv, key, sta_id);
+ break;
+ case ALG_TKIP:
+ ret = iwl4965_set_tkip_dynamic_key_info(priv, key, sta_id);
+ break;
+ case ALG_WEP:
+ ret = -EOPNOTSUPP;
+ break;
+ default:
+ IWL_ERROR("Unknown alg: %s alg = %d\n", __func__, key->alg);
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int iwl4965_remove_static_key(struct iwl_priv *priv)
+{
+ int ret = -EOPNOTSUPP;
+
+ return ret;
+}
+
+static int iwl4965_set_static_key(struct iwl_priv *priv,
+ struct ieee80211_key_conf *key)
+{
+ if (key->alg == ALG_WEP)
+ return -EOPNOTSUPP;
+
+ IWL_ERROR("Static key invalid: alg %d\n", key->alg);
+ return -EINVAL;
+}
+
static void iwl4965_clear_free_frames(struct iwl_priv *priv)
{
struct list_head *element;
@@ -2265,17 +2327,6 @@ static int iwl4965_scan_initiate(struct iwl_priv *priv)
return 0;
}
-static int iwl4965_set_rxon_hwcrypto(struct iwl_priv *priv, int hw_decrypt)
-{
- struct iwl4965_rxon_cmd *rxon = &priv->staging_rxon;
-
- if (hw_decrypt)
- rxon->filter_flags &= ~RXON_FILTER_DIS_DECRYPT_MSK;
- else
- rxon->filter_flags |= RXON_FILTER_DIS_DECRYPT_MSK;
-
- return 0;
-}
static void iwl4965_set_flags_for_phymode(struct iwl_priv *priv,
enum ieee80211_band band)
@@ -7566,8 +7617,9 @@ static int iwl4965_mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
{
struct iwl_priv *priv = hw->priv;
DECLARE_MAC_BUF(mac);
- int rc = 0;
- u8 sta_id;
+ int ret = 0;
+ u8 sta_id = IWL_INVALID_STATION;
+ u8 static_key;
IWL_DEBUG_MAC80211("enter\n");
@@ -7580,44 +7632,45 @@ static int iwl4965_mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
/* only support pairwise keys */
return -EOPNOTSUPP;
- sta_id = iwl4965_hw_find_station(priv, addr);
- if (sta_id == IWL_INVALID_STATION) {
- IWL_DEBUG_MAC80211("leave - %s not in station map.\n",
- print_mac(mac, addr));
- return -EINVAL;
- }
+ /* FIXME: need to differenciate between static and dynamic key
+ * in the level of mac80211 */
+ static_key = !iwl4965_is_associated(priv);
- mutex_lock(&priv->mutex);
+ if (!static_key) {
+ sta_id = iwl4965_hw_find_station(priv, addr);
+ if (sta_id == IWL_INVALID_STATION) {
+ IWL_DEBUG_MAC80211("leave - %s not in station map.\n",
+ print_mac(mac, addr));
+ return -EINVAL;
+ }
+ }
iwl4965_scan_cancel_timeout(priv, 100);
switch (cmd) {
- case SET_KEY:
- rc = iwl4965_update_sta_key_info(priv, key, sta_id);
- if (!rc) {
- iwl4965_set_rxon_hwcrypto(priv, 1);
- iwl4965_commit_rxon(priv);
- key->hw_key_idx = sta_id;
- IWL_DEBUG_MAC80211("set_key success, using hwcrypto\n");
- key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
- }
+ case SET_KEY:
+ if (static_key)
+ ret = iwl4965_set_static_key(priv, key);
+ else
+ ret = iwl4965_set_dynamic_key(priv, key, sta_id);
+
+ IWL_DEBUG_MAC80211("enable hwcrypto key\n");
break;
case DISABLE_KEY:
- rc = iwl4965_clear_sta_key_info(priv, sta_id);
- if (!rc) {
- iwl4965_set_rxon_hwcrypto(priv, 0);
- iwl4965_commit_rxon(priv);
- IWL_DEBUG_MAC80211("disable hwcrypto key\n");
- }
+ if (static_key)
+ ret = iwl4965_remove_static_key(priv);
+ else
+ ret = iwl4965_clear_sta_key_info(priv, sta_id);
+
+ IWL_DEBUG_MAC80211("disable hwcrypto key\n");
break;
default:
- rc = -EINVAL;
+ ret = -EINVAL;
}
IWL_DEBUG_MAC80211("leave\n");
- mutex_unlock(&priv->mutex);
- return rc;
+ return ret;
}
static int iwl4965_mac_conf_tx(struct ieee80211_hw *hw, int queue,
--
1.5.3.4
From: Emmanuel Grumbach <[email protected]>
This patch adds translation for the RX status of an incoming packet.
The incoming status has to be translated to the old scheme in order to know
if the decryption has been done, MIC failure has occured, TTAK is valid etc...
This translation is mandatory for all RX packets when using 5300 and for
all HT packets using 4965.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl-4965-commands.h | 9 +++
drivers/net/wireless/iwlwifi/iwl-4965.c | 66 ++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl4965-base.c | 6 ++
3 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
index 085d813..5107100 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-4965-commands.h
@@ -890,6 +890,10 @@ struct iwl4965_rx_frame_hdr {
#define RX_RES_STATUS_SEC_TYPE_WEP (0x1 << 8)
#define RX_RES_STATUS_SEC_TYPE_CCMP (0x2 << 8)
#define RX_RES_STATUS_SEC_TYPE_TKIP (0x3 << 8)
+#define RX_RES_STATUS_SEC_TYPE_ERR (0x7 << 8)
+
+#define RX_RES_STATUS_STATION_FOUND (1<<6)
+#define RX_RES_STATUS_NO_STATION_INFO_MISMATCH (1<<7)
#define RX_RES_STATUS_DECRYPT_TYPE_MSK (0x3 << 11)
#define RX_RES_STATUS_NOT_DECRYPT (0x0 << 11)
@@ -897,6 +901,11 @@ struct iwl4965_rx_frame_hdr {
#define RX_RES_STATUS_BAD_ICV_MIC (0x1 << 11)
#define RX_RES_STATUS_BAD_KEY_TTAK (0x2 << 11)
+#define RX_MPDU_RES_STATUS_ICV_OK (0x20)
+#define RX_MPDU_RES_STATUS_MIC_OK (0x40)
+#define RX_MPDU_RES_STATUS_TTAK_OK (1 << 7)
+#define RX_MPDU_RES_STATUS_DEC_DONE_MSK (0x800)
+
struct iwl4965_rx_frame_end {
__le32 status;
__le64 timestamp;
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index b2ea4d4..1030f17 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -3345,6 +3345,65 @@ static void iwl_update_rx_stats(struct iwl_priv *priv, u16 fc, u16 len)
priv->rx_stats[idx].bytes += len;
}
+static u32 iwl4965_translate_rx_status(u32 decrypt_in)
+{
+ u32 decrypt_out = 0;
+
+ if ((decrypt_in & RX_RES_STATUS_STATION_FOUND) ==
+ RX_RES_STATUS_STATION_FOUND)
+ decrypt_out |= (RX_RES_STATUS_STATION_FOUND |
+ RX_RES_STATUS_NO_STATION_INFO_MISMATCH);
+
+ decrypt_out |= (decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK);
+
+ /* packet was not encrypted */
+ if ((decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) ==
+ RX_RES_STATUS_SEC_TYPE_NONE)
+ return decrypt_out;
+
+ /* packet was encrypted with unknown alg */
+ if ((decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) ==
+ RX_RES_STATUS_SEC_TYPE_ERR)
+ return decrypt_out;
+
+ /* decryption was not done in HW */
+ if ((decrypt_in & RX_MPDU_RES_STATUS_DEC_DONE_MSK) !=
+ RX_MPDU_RES_STATUS_DEC_DONE_MSK)
+ return decrypt_out;
+
+ switch (decrypt_in & RX_RES_STATUS_SEC_TYPE_MSK) {
+
+ case RX_RES_STATUS_SEC_TYPE_CCMP:
+ /* alg is CCM: check MIC only */
+ if (!(decrypt_in & RX_MPDU_RES_STATUS_MIC_OK))
+ /* Bad MIC */
+ decrypt_out |= RX_RES_STATUS_BAD_ICV_MIC;
+ else
+ decrypt_out |= RX_RES_STATUS_DECRYPT_OK;
+
+ break;
+
+ case RX_RES_STATUS_SEC_TYPE_TKIP:
+ if (!(decrypt_in & RX_MPDU_RES_STATUS_TTAK_OK)) {
+ /* Bad TTAK */
+ decrypt_out |= RX_RES_STATUS_BAD_KEY_TTAK;
+ break;
+ }
+ /* fall through if TTAK OK */
+ default:
+ if (!(decrypt_in & RX_MPDU_RES_STATUS_ICV_OK))
+ decrypt_out |= RX_RES_STATUS_BAD_ICV_MIC;
+ else
+ decrypt_out |= RX_RES_STATUS_DECRYPT_OK;
+ break;
+ };
+
+ IWL_DEBUG_RX("decrypt_in:0x%x decrypt_out = 0x%x\n",
+ decrypt_in, decrypt_out);
+
+ return decrypt_out;
+}
+
static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
int include_phy,
struct iwl4965_rx_mem_buffer *rxb,
@@ -3358,6 +3417,7 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
__le32 *rx_end;
unsigned int skblen;
u32 ampdu_status;
+ u32 ampdu_status_legacy;
if (!include_phy && priv->last_phy_res[0])
rx_start = (struct iwl4965_rx_phy_res *)&priv->last_phy_res[1];
@@ -3394,6 +3454,12 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
ampdu_status = le32_to_cpu(*rx_end);
skblen = ((u8 *) rx_end - (u8 *) & pkt->u.raw[0]) + sizeof(u32);
+ if (!include_phy) {
+ /* New status scheme, need to translate */
+ ampdu_status_legacy = ampdu_status;
+ ampdu_status = iwl4965_translate_rx_status(ampdu_status);
+ }
+
/* start from MAC */
skb_reserve(rxb->skb, (void *)hdr - (void *)pkt);
skb_put(rxb->skb, len); /* end where data ends */
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d9df2b0..5bd98f5 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -3044,6 +3044,12 @@ void iwl4965_set_decrypted_flag(struct iwl_priv *priv, struct sk_buff *skb,
IWL_DEBUG_RX("decrypt_res:0x%x\n", decrypt_res);
switch (decrypt_res & RX_RES_STATUS_SEC_TYPE_MSK) {
case RX_RES_STATUS_SEC_TYPE_TKIP:
+ /* The uCode has got a bad phase 1 Key, pushes the packet.
+ * Decryption will be done in SW. */
+ if ((decrypt_res & RX_RES_STATUS_DECRYPT_TYPE_MSK) ==
+ RX_RES_STATUS_BAD_KEY_TTAK)
+ break;
+
if ((decrypt_res & RX_RES_STATUS_DECRYPT_TYPE_MSK) ==
RX_RES_STATUS_BAD_ICV_MIC)
stats->flag |= RX_FLAG_MMIC_ERROR;
--
1.5.3.4
On Mon, 2008-03-17 at 12:20 +0200, Tomas Winkler wrote:
> On Mon, Mar 17, 2008 at 11:58 AM, Johannes Berg
> <[email protected]> wrote:
> >
> > > > Also, looking at what you do here, I found this comment:
> > > > /* FIXME: need to differenciate between static and dynamic key
> > > > * in the level of mac80211 */
> > > > static_key = !iwl4965_is_associated(priv);
> > > >
> > > > I think that is pretty bogus because there isn't really a distinction
> > > > between dynamic and static keys, what's the reason for differentiating
> > > > in the driver? Also, the driver will do rather odd things when
> > > > * associate
> > > > * set a key
> > > > * disassociate
> > > > * delete the key
> > > >
> > >
> > > This is actually quite a bug in mac80211. There is substantial
> > > difference between dynamic and static key.
> > > While static key is used for crypto of all stations in BSS. Dynamic
> > > key is also called pairwise key and is generated for 'pair'
> >
> > Gee, can you then please stick to terminology used in the spec so other
> > people can understand it?
>
> What spec. ieee80211i. WPA, WPA2? .
>
> >
> > > Currently mac80211 set static key with broadcast address which iis
> > > wrong cause driver cannot distinguish whether this key is
> > > multicast/broadcast dynamic key or a static key. Shell it use it for
> > > all traffic or only for mcast/bcast? Who can tell?
> >
> > Actually, you're making it look like a much larger problem than it is.
> > If you assume anything WEP is a "static key" and everything else is a
> > "dynamic key" (using your terminology), the only problem will be with
> > dynamic WEP, and even then it's not really a problem because as far as I
> > understand even dynamic WEP doesn't distinguish between group and
> > pairwise keys.
>
> This is incorrect. WPA enable using WEP as dynamic key and this
> setting is very common.
> WEP key is enabled for legacy stations this force also broadcast to be
> WEP. This setup is still quite common.
Also sort of wrong; there are plenty of situations where the AP can be
put into essentially Dynamic WEP mode (I actually test this quite often
since there are a lot of people who use it) where it is still backed by
RADIUS but uses only WEP as the cipher and does _NOT_ broadcast WPA/RSN
information elements at all.
The _only_ guarantee you have for Dynamic WEP is that the privacy bit is
set to 1. Here's an iwlist dump for such a configuration, taken with an
ipw2200, so it would be reporting WPA/RSN IEs if there were any, but
there aren't:
Cell 30 - Address: 00:1A:xx:xx:xx:xx
ESSID:"foobar"
Protocol:IEEE 802.11bg
Mode:Master
Frequency:2.422 GHz (Channel 3)
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Quality=82/100 Signal level=-16 dBm
Extra: Last beacon: 35ms ago
Looks like static WEP, but it's actually a Cisco AIR-AP1131AG backed by
RADIUS using EAP-TLS.
Unfortunately for dynamic WEP, as a user you simply have to _know_ that
the AP is using one of:
- Open System auth
- Shared Key auth
- WEP 104
- WEP 40
- LEAP
- Dynamic WEP
since it doesn't beacon, you're just fucked unless your sysadmin tells
you what the AP is doing. Yay for WEP.
Dan
>
> >
> > > Other difference while there can be 4 static key installed that the
> > > same time possible switching between indexes There can be only one
> > > dynamic key per station if you also consider mcast/bcast station to be
> > > an entity. (TKIP actally uses different key index for bcast but
> > > that's just little execption)
> > > The terminology which is used is also wrong and I guess this is just
> > > wrong interpretation of old implementation - 'default key' is used
> > > for static key. Key mapping key is used for dynamic keys.
> >
> > I don't think I understand the last paragraph?
>
> Nothing imporatant just that term 'default key' is used usually on in
> context of static/legacy WEP key
> while term 'key mapping key' is used for what I call dynamic key.
>
> >
> > In any case, actual TX key selection is done by mac80211 anyway, so
> > you're never interested in that. Only RX key selection is interesting to
> > the driver, and as far as I can tell it ought to work if you simply
> > always use the broadcast address key when it's WEP, and otherwise the
> > pairwise keys and/or the broadcast key for bc/mc frames.
>
> Nothing to add to just that the assumption about WEP and broadcast is wrong.
>
> > Note that there's another case in AP mode where bc/mc keys are TX-only,
> > those are added with a zeroed MAC address.
>
> I would prefer also in this case a clear flag rather then playing with
> ambiguity of destination address.
>
> > johannes
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> At least the original d80211 design supported multiple SSIDs per BSS and
> yes, as far as kernel code is concerned, this was done in the identical
> way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
> virtual interface is added for both cases and STAs are bound to the
> specific virtual interface based on MLME/RADIUS results.
>
> However, I do not think I ever merged multi-SSID support into the open
> source version of hostapd, so it is quite possible that only the
> RADIUS-based VLAN assignment is currently used since multi-SSID support
> is inferior to multi-BSS support for number of reasons. Anyway, that
> does not change what mac80211 would support should one ever really want
> to enable multi-SSID support with a single BSS. I don't see much need
> for that, though, if one can use virtual BSSes.
Ah. I guess that requires hiding the SSID though?
johannes
On Mon, 2008-03-17 at 21:12 +0200, Tomas Winkler wrote:
> > >
> > > Isn't if on integer faster then comparing 6 bytes?
> >
> > Probably. Does it matter though? Setting keys isn't going to be
> > performance critical in any way.
>
> Yes but at least you do IF on something that is real not hacking with address.
True. Does it matter much though? I'm open to changing it but don't
think it matters too much.
> > > > Is that really done though? I mean, does wpa_supplicant not also use
> > > > encodeext for WEP keys?
> > > >
> > > Unfortunately yes.
> >
> > So that doesn't really help us either way, no?
>
> What is happening in case of static WEP is that IW_AUTH_CIPHER_NONE
> IW_ENCODE_ALG_WEP are set.
> Which is enough.
Indeed, that should be enough.
> You need only one unicast key for pairwise key. 4 keys are used only
> for static WEP key.
> For pairwise/dynamic WEP and TKIP you use key index in the packet but
> it changes only when supplicant change the key it self. You don't have
> the key alive in driver.
No, that's not true, due to rekeying concerns you actually can have more
than one group key at the same time in the driver/hardware.
> BSS defines security setting which defined by key management for
> pairwise and group key + cipher method for both .
> You can run multiple SSIDs over single single BSSID. This is done
> using VLANs
Actually, we don't support that in mac80211. And the way I understand
VLANs they are simply done by negotiating different group keys with
different groups of stations each forming a VLAN.
> So you can maintain multiple security settings in for one
> AP. However this is not possible when using static WEP since the key
> is global and the key is not attached to any address.
>
> There are more details into it I'm sorry if I'm not 100 clear here.
> The bottom line is that you don't need more 4 WEP keys both in AP and
> station mod. Same you need to maintain only one pairwise key for
> station both in AP and STA mode. In AP mode you need to maintain also
> one group key for each station because of the case of multiple SSIDs.
Except the group keys don't really matter for an AP since they're TX
only, which is why we add them with a zeroed MAC address and can only
select them for TX.
> Nop. Still you can have <WEP, WEP> for <pairwise,group key> valid
> setting - This is not static key. The two keys may differ. Under your
> assumption the group key will override pairwise key
Hm, ok. So I suppose the only way to determine "static" right now would
be to check that no pairwise keys are configured at all.
johannes
On Mon, Mar 17, 2008 at 12:57 PM, Johannes Berg
<[email protected]> wrote:
> > > Actually, you're making it look like a much larger problem than it is.
> > > If you assume anything WEP is a "static key" and everything else is a
> > > "dynamic key" (using your terminology), the only problem will be with
> > > dynamic WEP, and even then it's not really a problem because as far as I
> > > understand even dynamic WEP doesn't distinguish between group and
> > > pairwise keys.
> >
> > This is incorrect. WPA enable using WEP as dynamic key and this
> > setting is very common.
> > WEP key is enabled for legacy stations this force also broadcast to be
> > WEP. This setup is still quite common.
> I have no idea about WPA's non-IEEE modes. I don't seem to be able to
> find such a thing in the IEEE spec so you'll have to actually elaborate
> on this.
Actually I've misled you a bit. This is defined by IEEE 802.11i in
section TSN Transition Security Network. Where legacy WEP-only STA and
RSN-enabled station can coexists. In this case Legacy stations use
static WEP key and RSN enabled station uses more advanced security
setting. RSN enabled station will be configured with WEP as a group
cipher (spec name)
Here is a quote from the spec.. there is much more about it it's a bit
spread in the spec.
3.123 Transition Security Network (TSN): A Security Network which
allows the creation of Pre-Robust
Security Network Associations as well as Robust Security Network
Associations. A TSN can be identified
by the indication in the RSN IE of Beacons that the group cipher suite
in use is WEP.
>
> > > Note that there's another case in AP mode where bc/mc keys are TX-only,
> > > those are added with a zeroed MAC address.
> > I would prefer also in this case a clear flag rather then playing with
> > ambiguity of destination address.
On second thought is that AP has only TX group key while STA has only
RX group key so I
m not seeing here any need for flag.
>
> Yes, that would indeed help. Except that WEXT can't actually give you
> the distinction so discussing these points right now is pretty moot when
> we can't even do it properly as far as I can tell. Might be possible to
> infer the information with the key management enabled flag thing...
You have encode ioctl which is called only for static/legacy WEP or
you use CIPHER_NONE for when using encodeext
For WEP in Pairwise and Group Key you use WEP40/104
/* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
#define IW_AUTH_CIPHER_NONE 0x00000001
#define IW_AUTH_CIPHER_WEP40 0x00000002
#define IW_AUTH_CIPHER_TKIP 0x00000004
#define IW_AUTH_CIPHER_CCMP 0x00000008
#define IW_AUTH_CIPHER_WEP104 0x00000010
It's not well defined in wext but we can at least define the interface
from mac80211 point of view.
Thanks
Tomas
On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> From: Emmanuel Grumbach <[email protected]>
>
> This patch makes mac80211 able to send a phase1 key for TKIP decryption.
> This is needed for drivers that don't do the rekeying by themselves
> (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
> decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
> * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
> * the driver for a TKIP key if it requires a phase2 TX key generation
> * in SW. The key will be attached to each packet.
> + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
> + * for a TKIP key if it requires phase 1 key generation in software.
> + * The phase 1 key will be sent in the same context as Rx.
> + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
> + * IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
> + * fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
This really breaks the set_key() model of having always one set_key()
call to add the key and another one to remove it again.
I think it would be much more appropriate to handle this in the driver
by exporting an appropriate phase1 mixing function that takes the
key_conf, iv16, RX vs. TX flag, and for RX the queue number as
arguments. The RX vs. TX flag could be used by the b43 driver since that
hardware can actually derive the phase2 key by itself.
I think for advanced features like crypto hardware acceleration or
similar we should deviate from the "push" model mac80211 has for most
things (and which you also implemented here) so we don't end up creating
special flags for all possible different hardware. A "pull" model is
much more scalable here.
johannes
> > You need only one unicast key for pairwise key. 4 keys are used only
> > for static WEP key.
> > For pairwise/dynamic WEP and TKIP you use key index in the packet but
> > it changes only when supplicant change the key it self. You don't have
> > the key alive in driver.
>
> No, that's not true, due to rekeying concerns you actually can have more
> than one group key at the same time in the driver/hardware.
I wasn't aware of this race in rekeying. I will investigate this.
Anyhow rekeying can also happing also for unicast keys.
>
> > BSS defines security setting which defined by key management for
> > pairwise and group key + cipher method for both .
> > You can run multiple SSIDs over single single BSSID. This is done
> > using VLANs
>
> Actually, we don't support that in mac80211.
Last time I worked on AP project it worked. It was older mac hopefully
it's not totally broken
And the way I understand
> VLANs they are simply done by negotiating different group keys with
> different groups of stations each forming a VLAN.
We are saying the same. That's okay.
>
> > So you can maintain multiple security settings in for one
> > AP. However this is not possible when using static WEP since the key
> > is global and the key is not attached to any address.
> >
> > There are more details into it I'm sorry if I'm not 100 clear here.
> > The bottom line is that you don't need more 4 WEP keys both in AP and
> > station mod. Same you need to maintain only one pairwise key for
> > station both in AP and STA mode. In AP mode you need to maintain also
> > one group key for each station because of the case of multiple SSIDs.
>
> Except the group keys don't really matter for an AP since they're TX
> only, which is why we add them with a zeroed MAC address and can only
> select them for TX
.
Zero address again :)
>
>
> > Nop. Still you can have <WEP, WEP> for <pairwise,group key> valid
> > setting - This is not static key. The two keys may differ. Under your
> > assumption the group key will override pairwise key
>
> Hm, ok. So I suppose the only way to determine "static" right now would
> be to check that no pairwise keys are configured at all.
I'm not sure if I follow here but I think the simples way to determine
if static key is set is to set static_key flag to 1. I don't see any
reason this can be directly detected from the configuration.
Tomas
> johannes
>
> >
> > Isn't if on integer faster then comparing 6 bytes?
>
> Probably. Does it matter though? Setting keys isn't going to be
> performance critical in any way.
Yes but at least you do IF on something that is real not hacking with address.
>
> > > Is that really done though? I mean, does wpa_supplicant not also use
> > > encodeext for WEP keys?
> > >
> > Unfortunately yes.
>
> So that doesn't really help us either way, no?
What is happening in case of static WEP is that IW_AUTH_CIPHER_NONE
IW_ENCODE_ALG_WEP are set.
Which is enough.
>
> > First of all we don't need 4 keys per station but for the whole
> > system.
>
> Not sure I understand this. You need pairwise (per-station) keys as well
> as four default keys, no?
You need only one unicast key for pairwise key. 4 keys are used only
for static WEP key.
For pairwise/dynamic WEP and TKIP you use key index in the packet but
it changes only when supplicant change the key it self. You don't have
the key alive in driver.
>
> > Even in AP mode with multiple SSID meaning multiple security
> > setting you cannot distinguish between networks in static WEP key
> > setting so 4 is enough.
>
> Not sure I get what you're thinking here.
BSS defines security setting which defined by key management for
pairwise and group key + cipher method for both .
You can run multiple SSIDs over single single BSSID. This is done
using VLANs So you can maintain multiple security settings in for one
AP. However this is not possible when using static WEP since the key
is global and the key is not attached to any address.
There are more details into it I'm sorry if I'm not 100 clear here.
The bottom line is that you don't need more 4 WEP keys both in AP and
station mod. Same you need to maintain only one pairwise key for
station both in AP and STA mode. In AP mode you need to maintain also
one group key for each station because of the case of multiple SSIDs.
>
> > Beside that you need place holder for group key. They might be
> > multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
> > doesn't support it in HW but in general it is possible.
>
> Well, no, because we can add multiple keys with a zeroed MAC address,
> since we have the local MAC address in there as well. Also, in an AP,
> these are only used for TX so it doesn't matter since mac80211 does the
> key selection completely on its own.
See above. anyhow still don't like the trick with invalid address.
>
> > We need a flag in set_key which says whether the WEP key is static or not.
>
> Let's actually try to gather all the cases first.
>
> Is this it?
>
> * TKIP/CCMP/WEP group or pairwise key
> * WEP legacy ('static') key
That's correct
> where the first is completely covered by what we have now
Yes
and the
> assumption is that if only WEP keys are present then it'll be a legacy
> WEP key?
Nop. Still you can have <WEP, WEP> for <pairwise,group key> valid
setting - This is not static key. The two keys may differ. Under your
assumption the group key will override pairwise key
Tomas
> johannes
>
> Actually I've misled you a bit. This is defined by IEEE 802.11i in
> section TSN Transition Security Network. Where legacy WEP-only STA and
> RSN-enabled station can coexists. In this case Legacy stations use
> static WEP key and RSN enabled station uses more advanced security
> setting. RSN enabled station will be configured with WEP as a group
> cipher (spec name)
>
> Here is a quote from the spec.. there is much more about it it's a bit
> spread in the spec.
>
> 3.123 Transition Security Network (TSN): A Security Network which
> allows the creation of Pre-Robust
> Security Network Associations as well as Robust Security Network
> Associations. A TSN can be identified
> by the indication in the RSN IE of Beacons that the group cipher suite
> in use is WEP.
Huh ok. But how would the WEP legacy station be able to determine that?
Or does it just try to use WEP and succeed? TBH, I was unaware that this
existed, this does make it a bit more of a problem than I thought then.
> > > > Note that there's another case in AP mode where bc/mc keys are TX-only,
> > > > those are added with a zeroed MAC address.
>
> > > I would prefer also in this case a clear flag rather then playing with
> > > ambiguity of destination address.
>
> On second thought is that AP has only TX group key while STA has only
> RX group key so I
> m not seeing here any need for flag.
Hm, well, I didn't really want to require the driver to keep track of
the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
for the group keys.
> > Yes, that would indeed help. Except that WEXT can't actually give you
> > the distinction so discussing these points right now is pretty moot when
> > we can't even do it properly as far as I can tell. Might be possible to
> > infer the information with the key management enabled flag thing...
>
> You have encode ioctl which is called only for static/legacy WEP or
> you use CIPHER_NONE for when using encodeext
> For WEP in Pairwise and Group Key you use WEP40/104
Is that really done though? I mean, does wpa_supplicant not also use
encodeext for WEP keys?
> /* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
> #define IW_AUTH_CIPHER_NONE 0x00000001
> #define IW_AUTH_CIPHER_WEP40 0x00000002
> #define IW_AUTH_CIPHER_TKIP 0x00000004
> #define IW_AUTH_CIPHER_CCMP 0x00000008
> #define IW_AUTH_CIPHER_WEP104 0x00000010
>
> It's not well defined in wext but we can at least define the interface
> from mac80211 point of view.
True. So what change do we need?
johannes
On Mon, Mar 17, 2008 at 10:04 PM, Johannes Berg
<[email protected]> wrote:
>
> > >
> > > > BSS defines security setting which defined by key management for
> > > > pairwise and group key + cipher method for both .
> > > > You can run multiple SSIDs over single single BSSID. This is done
> > > > using VLANs
> > >
> > > Actually, we don't support that in mac80211.
> > Last time I worked on AP project it worked. It was older mac hopefully
> > it's not totally broken
> >
> > And the way I understand
> > > VLANs they are simply done by negotiating different group keys with
> > > different groups of stations each forming a VLAN.
> >
> > We are saying the same. That's okay.
>
> Well, you were suggesting the use of multiple SSIDs, which we don't
> support, we only support VLANs within a BSS/single SSID. Not that I've
> been able to test it, hostapd needs radius stuff set up for VLANs...
I think it's transparent since it's handled by MLME in hostapd so
multiple SSID is supported
Maybe we did some minor changes in mac to support that.. Will check again.
I think it's always done by means of VLANs
> Right. I was just saying that the way it currently is I think you could
> detect it that way. b43 simply assumes WEP keys are always 'static'
> which seems to mostly work well in practice.
> I suppose then set_key needs a new argument key_type:
>
> enum ieee80211_key_type {
> KEY_TYPE_PAIRWISE,
> KEY_TYPE_GROUP,
> KEY_TYPE_TXONLY, /* group key in an AP */
Can we drop it? Hm still not sure why you like it so much.
> KEY_TYPE_STATIC,
> }
>
> where the MAC address pointer would only be non-NULL when the key type
> is PAIRWISE, and STATIC can only be used for WEP keys.
>
Do you know anything about mesh security are we breaking here anything?
Thanks
Tomas
> johannes
>
> > Huh ok. But how would the WEP legacy station be able to determine that?
>
> Legacy user get the key written on 'positit' yellow paper :).
Heh yeah.
> > Or does it just try to use WEP and succeed? TBH, I was unaware that this
> > existed, this does make it a bit more of a problem than I thought then.
> >
>
> > >
> > > On second thought is that AP has only TX group key while STA has only
> > > RX group key so I
> > > m not seeing here any need for flag.
> >
> > Hm, well, I didn't really want to require the driver to keep track of
> > the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
> > for the group keys.
>
> Isn't if on integer faster then comparing 6 bytes?
Probably. Does it matter though? Setting keys isn't going to be
performance critical in any way.
> > Is that really done though? I mean, does wpa_supplicant not also use
> > encodeext for WEP keys?
> >
> Unfortunately yes.
So that doesn't really help us either way, no?
> First of all we don't need 4 keys per station but for the whole
> system.
Not sure I understand this. You need pairwise (per-station) keys as well
as four default keys, no?
> Even in AP mode with multiple SSID meaning multiple security
> setting you cannot distinguish between networks in static WEP key
> setting so 4 is enough.
Not sure I get what you're thinking here.
> Beside that you need place holder for group key. They might be
> multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
> doesn't support it in HW but in general it is possible.
Well, no, because we can add multiple keys with a zeroed MAC address,
since we have the local MAC address in there as well. Also, in an AP,
these are only used for TX so it doesn't matter since mac80211 does the
key selection completely on its own.
> We need a flag in set_key which says whether the WEP key is static or not.
Let's actually try to gather all the cases first.
Is this it?
* TKIP/CCMP/WEP group or pairwise key
* WEP legacy ('static') key
where the first is completely covered by what we have now and the
assumption is that if only WEP keys are present then it'll be a legacy
WEP key?
johannes
On Tue, Mar 18, 2008 at 10:18:00AM +0100, Johannes Berg wrote:
> > At least the original d80211 design supported multiple SSIDs per BSS and
> > yes, as far as kernel code is concerned, this was done in the identical
> > way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
> > virtual interface is added for both cases and STAs are bound to the
> > specific virtual interface based on MLME/RADIUS results.
> Ah. I guess that requires hiding the SSID though?
Not necessarily. The AP can advertise one SSID in Beacon frames and then
reply with Probe Response to multiple SSIDs (well, these other SSIDs
would of course be "hidden" in the sense that they are not broadcast in
Beacon frames). This works relatively well with most clients as long as
the security policy with the main SSID (the one advertised in the Beacon
frames) and the secondary ones (the ones that are only visible in Probe
Response frames) are identical. If they are different (e.g., open vs.
WPA), problems are to be expected with many client implementations since
this does not exactly match with the standard..
--
Jouni Malinen PGP id EFC895FA
> > Right, in software we can keep a phase1 per AC but we don't need to in
> > hardware since that's just the optimisation.
>
> Correct, I'm just not sure how it's done for bcom cards.
I'm not entirely sure right now either.
> Eventually you want to update RX phase1 key into HW so you get your
> CPU utilization where it have to be, right?
Yeah, you would :) But that's something we're addressing anyway since
iwlwifi needs it too.
> > > Phase1 for TX and RX are not the same, again because of the simple
> > > reasone that number of transmitted and received packet is not the
> > > same.
> >
> > Hm, right. But if we go for pull mode for TX, we only need to have push
> > mode for the phase1 rx key when that changes, no?
>
> Emmanuel has prepared patches for TX pull mode (phase2 only for now) .
> If this OK wiith I will resend the whole TKIP series with this change,
> leaving RX in pull mode.
You mean "RX in push mode" I think. Could you change that to a new
callback or so then as we discussed?
johannes
> > Also, looking at what you do here, I found this comment:
> > /* FIXME: need to differenciate between static and dynamic key
> > * in the level of mac80211 */
> > static_key = !iwl4965_is_associated(priv);
> >
> > I think that is pretty bogus because there isn't really a distinction
> > between dynamic and static keys, what's the reason for differentiating
> > in the driver? Also, the driver will do rather odd things when
> > * associate
> > * set a key
> > * disassociate
> > * delete the key
> >
>
> This is actually quite a bug in mac80211. There is substantial
> difference between dynamic and static key.
> While static key is used for crypto of all stations in BSS. Dynamic
> key is also called pairwise key and is generated for 'pair'
Gee, can you then please stick to terminology used in the spec so other
people can understand it?
> Currently mac80211 set static key with broadcast address which iis
> wrong cause driver cannot distinguish whether this key is
> multicast/broadcast dynamic key or a static key. Shell it use it for
> all traffic or only for mcast/bcast? Who can tell?
Actually, you're making it look like a much larger problem than it is.
If you assume anything WEP is a "static key" and everything else is a
"dynamic key" (using your terminology), the only problem will be with
dynamic WEP, and even then it's not really a problem because as far as I
understand even dynamic WEP doesn't distinguish between group and
pairwise keys.
> Other difference while there can be 4 static key installed that the
> same time possible switching between indexes There can be only one
> dynamic key per station if you also consider mcast/bcast station to be
> an entity. (TKIP actally uses different key index for bcast but
> that's just little execption)
> The terminology which is used is also wrong and I guess this is just
> wrong interpretation of old implementation - 'default key' is used
> for static key. Key mapping key is used for dynamic keys.
I don't think I understand the last paragraph?
In any case, actual TX key selection is done by mac80211 anyway, so
you're never interested in that. Only RX key selection is interesting to
the driver, and as far as I can tell it ought to work if you simply
always use the broadcast address key when it's WEP, and otherwise the
pairwise keys and/or the broadcast key for bc/mc frames.
Note that there's another case in AP mode where bc/mc keys are TX-only,
those are added with a zeroed MAC address.
johannes
> > Good point. But let's not overload set_key() for it this way. This way,
> > the driver needs to look up the key etc. and the semantics get quite
> > mangled up. Also, your approach doesn't work for Broadcom hardware that
> > only needs phase 1 keys for both RX and TX.
>
> Can you elaborate why it doesn't cover bcom case?
I don't quite understand the phase 1 key derivation and why it is done
for each DMA queue, but I think this is not too important as
non-matching will just be done in software. However, bcom firmware wants
to have just the phase 1 key, and as far as I can tell the driver can't,
even with your patches, obtain a phase 1 key for TX.
> > How about instead we add a new "update_tkip_key()" callback that takes
> > exactly the required parameters? It should also give the
> > hardware-key-index so that the driver has less work to do.
>
> It's viable but I actually prefer not opening too many interfaces.
> Please give me some more detailed sketch how do you see that and we
> sure get to some acceptable solution.
Yes, I would prefer not having that many interfaces as well, but I don't
think shoehorning it into the set_key() callback is a good idea because
(a) you add fields to the key conf structure that are only used for
the tkip stuff and only valid in some calls
(b) the patch breaks the set_key() interface's symmetry
A new callback update_tkip_key could look like this:
void update_tkip_phase1key(hw, keyconf, iv32, p1key)
The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the
new callback would be invoked right from where the phase1 key is
calculated.
I'm not exactly sure whether one needs a phase1 key for RX and one for
TX right now, but if so a direction flag should be added?
johannes
On Mon, Mar 17, 2008 at 10:27:53PM +0200, Tomas Winkler wrote:
> On Mon, Mar 17, 2008 at 10:04 PM, Johannes Berg
> <[email protected]> wrote:
> > Well, you were suggesting the use of multiple SSIDs, which we don't
> > support, we only support VLANs within a BSS/single SSID. Not that I've
> > been able to test it, hostapd needs radius stuff set up for VLANs...
>
> I think it's transparent since it's handled by MLME in hostapd so
> multiple SSID is supported
> Maybe we did some minor changes in mac to support that.. Will check again.
> I think it's always done by means of VLANs
At least the original d80211 design supported multiple SSIDs per BSS and
yes, as far as kernel code is concerned, this was done in the identical
way for both multi-SSID and dynamic-VLAN (RADIUS assigned). A new
virtual interface is added for both cases and STAs are bound to the
specific virtual interface based on MLME/RADIUS results.
However, I do not think I ever merged multi-SSID support into the open
source version of hostapd, so it is quite possible that only the
RADIUS-based VLAN assignment is currently used since multi-SSID support
is inferior to multi-BSS support for number of reasons. Anyway, that
does not change what mac80211 would support should one ever really want
to enable multi-SSID support with a single BSS. I don't see much need
for that, though, if one can use virtual BSSes.
--
Jouni Malinen PGP id EFC895FA
>
> So the problem with this is, how does Dynamic WEP work here? Dynamic
> WEP uses 802.1x/EAP to rekey stations periodically just like
> WPA[2]-Enterprise, but of courses uses WEP only. It's not "static" WEP
> as you guys have been talking about it (you could call static WEP
> "WEP-PSK" if you like).
>
> The problem here is that with WEXT, there's not a good way to
> distinguish between the two. Both static & dynamic WEP might look the
> same to the driver when the call comes through SIWENCODE/SIWENCODEEXT.
> So you've got to be careful here classifying all WEP key requests as
> static.
Yes this two are not enough you need also specify the the key management method
via SIWEAUTH .
Tomas
From: Emmanuel Grumbach <[email protected]>
This patch add support for TKIP in HW.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl4965-base.c | 63 +++++++++++++++++++++++----
1 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d47941d..d9df2b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -1449,7 +1449,58 @@ static int iwl4965_set_tkip_dynamic_key_info(struct iwl_priv *priv,
struct ieee80211_key_conf *keyconf,
u8 sta_id)
{
- return -EOPNOTSUPP;
+ unsigned long flags;
+ __le16 key_flags = 0;
+ int i, ret = 0;
+
+ keyconf->flags |= IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY;
+ keyconf->flags |= IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY;
+ keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
+ keyconf->flags |= IEEE80211_KEY_FLAG_GENERATE_MMIC;
+ keyconf->hw_key_idx = sta_id;
+
+ key_flags |= (STA_KEY_FLG_TKIP | STA_KEY_FLG_MAP_KEY_MSK);
+ key_flags |= cpu_to_le16(keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
+ key_flags &= ~STA_KEY_FLG_INVALID;
+
+ if (sta_id == priv->hw_setting.bcast_sta_id)
+ key_flags |= STA_KEY_MULTICAST_MSK;
+
+ spin_lock_irqsave(&priv->sta_lock, flags);
+
+ priv->stations[sta_id].keyinfo.alg = keyconf->alg;
+ priv->stations[sta_id].keyinfo.keylen = 16;
+
+ /* This copy is acutally not needed: we get the key with each TX */
+ memcpy(priv->stations[sta_id].keyinfo.key, keyconf->key, 16);
+
+ memcpy(priv->stations[sta_id].sta.key.key, keyconf->key, 16);
+
+ priv->stations[sta_id].sta.key.key_offset = (sta_id%8);/*FIXME!!!*/
+ priv->stations[sta_id].sta.key.key_flags = key_flags;
+ if (keyconf->flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+ priv->stations[sta_id].sta.key.tkip_rx_tsc_byte2 =
+ (u8) keyconf->tkip_iv32;
+ for (i = 0; i < 5; i++)
+ priv->stations[sta_id].sta.key.tkip_rx_ttak[i] =
+ cpu_to_le16(keyconf->tkip_p1k[i]);
+ } else {
+ priv->stations[sta_id].sta.key.tkip_rx_tsc_byte2 = 0xff;
+ }
+
+ priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
+ priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
+
+ /* Don't send an incomplete key: a key w/o valid TTAK */
+ if (keyconf->flags & IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID) {
+ IWL_DEBUG_INFO("hwcrypto: modify ucode station key info\n");
+ ret = iwl4965_send_add_station(priv,
+ &priv->stations[sta_id].sta, CMD_ASYNC);
+ }
+
+ spin_unlock_irqrestore(&priv->sta_lock, flags);
+
+ return ret;
}
static int iwl4965_clear_sta_key_info(struct iwl_priv *priv, u8 sta_id)
@@ -2484,15 +2535,9 @@ static void iwl4965_build_tx_cmd_hwcrypto(struct iwl_priv *priv,
break;
case ALG_TKIP:
-#if 0
cmd->cmd.tx.sec_ctl = TX_CMD_SEC_TKIP;
-
- if (last_frag)
- memcpy(cmd->cmd.tx.tkip_mic.byte, skb_frag->tail - 8,
- 8);
- else
- memset(cmd->cmd.tx.tkip_mic.byte, 0, 8);
-#endif
+ memcpy(cmd->cmd.tx.key, ctl->tkip_key, keyinfo->keylen);
+ IWL_DEBUG_TX("tx_cmd with tkip hwcrypto\n");
break;
case ALG_WEP:
--
1.5.3.4
On Mon, Mar 17, 2008 at 11:58 AM, Johannes Berg
<[email protected]> wrote:
>
> > > Also, looking at what you do here, I found this comment:
> > > /* FIXME: need to differenciate between static and dynamic key
> > > * in the level of mac80211 */
> > > static_key = !iwl4965_is_associated(priv);
> > >
> > > I think that is pretty bogus because there isn't really a distinction
> > > between dynamic and static keys, what's the reason for differentiating
> > > in the driver? Also, the driver will do rather odd things when
> > > * associate
> > > * set a key
> > > * disassociate
> > > * delete the key
> > >
> >
> > This is actually quite a bug in mac80211. There is substantial
> > difference between dynamic and static key.
> > While static key is used for crypto of all stations in BSS. Dynamic
> > key is also called pairwise key and is generated for 'pair'
>
> Gee, can you then please stick to terminology used in the spec so other
> people can understand it?
What spec. ieee80211i. WPA, WPA2? .
>
> > Currently mac80211 set static key with broadcast address which iis
> > wrong cause driver cannot distinguish whether this key is
> > multicast/broadcast dynamic key or a static key. Shell it use it for
> > all traffic or only for mcast/bcast? Who can tell?
>
> Actually, you're making it look like a much larger problem than it is.
> If you assume anything WEP is a "static key" and everything else is a
> "dynamic key" (using your terminology), the only problem will be with
> dynamic WEP, and even then it's not really a problem because as far as I
> understand even dynamic WEP doesn't distinguish between group and
> pairwise keys.
This is incorrect. WPA enable using WEP as dynamic key and this
setting is very common.
WEP key is enabled for legacy stations this force also broadcast to be
WEP. This setup is still quite common.
>
> > Other difference while there can be 4 static key installed that the
> > same time possible switching between indexes There can be only one
> > dynamic key per station if you also consider mcast/bcast station to be
> > an entity. (TKIP actally uses different key index for bcast but
> > that's just little execption)
> > The terminology which is used is also wrong and I guess this is just
> > wrong interpretation of old implementation - 'default key' is used
> > for static key. Key mapping key is used for dynamic keys.
>
> I don't think I understand the last paragraph?
Nothing imporatant just that term 'default key' is used usually on in
context of static/legacy WEP key
while term 'key mapping key' is used for what I call dynamic key.
>
> In any case, actual TX key selection is done by mac80211 anyway, so
> you're never interested in that. Only RX key selection is interesting to
> the driver, and as far as I can tell it ought to work if you simply
> always use the broadcast address key when it's WEP, and otherwise the
> pairwise keys and/or the broadcast key for bc/mc frames.
Nothing to add to just that the assumption about WEP and broadcast is wrong.
> Note that there's another case in AP mode where bc/mc keys are TX-only,
> those are added with a zeroed MAC address.
I would prefer also in this case a clear flag rather then playing with
ambiguity of destination address.
> johannes
>
> This is only in RX side. Each AC (access category) queue transmit in
> it's own rate. For example VO trasmitts more packets then BE. So you
> might get into case in receive site that VO packets are already on
> wraparound side while BE are still using 'old' phase1.
> Best remedy is to keep phase1 per each AC.
>
> > but I think this is not too important as
> > non-matching will just be done in software.
>
> Correct, this should happen only for short period of time that ph1
> doesn't match for each AC queue.
Right, in software we can keep a phase1 per AC but we don't need to in
hardware since that's just the optimisation.
> > However, bcom firmware wants
> > to have just the phase 1 key, and as far as I can tell the driver can't,
> > even with your patches, obtain a phase 1 key for TX.
>
> Not sure these cases are symmetric. You have to have phase1 ready in
> HW before you transmit the packet
> Phase1 need to be adhered to a packet that causes wraparound unlike RX
> that you can fall back to SW decryption
> In TX there is no way back.
Good point. So then for Broadcom we actually need to update phase1 in
hardware when it changes on TX and not bother with RX at all, we'll fall
back to software in that case.
> > > > How about instead we add a new "update_tkip_key()" callback that takes
> > > > exactly the required parameters? It should also give the
> > > > hardware-key-index so that the driver has less work to do.
> > >
> > > It's viable but I actually prefer not opening too many interfaces.
> > > Please give me some more detailed sketch how do you see that and we
> > > sure get to some acceptable solution.
> >
> > Yes, I would prefer not having that many interfaces as well, but I don't
> > think shoehorning it into the set_key() callback is a good idea because
> > (a) you add fields to the key conf structure that are only used for
> > the tkip stuff and only valid in some calls
> > (b) the patch breaks the set_key() interface's symmetry
> >
> > A new callback update_tkip_key could look like this:
> >
> > void update_tkip_phase1key(hw, keyconf, iv32, p1key)
>
> What about
> enum tkip_update_flags {
> TKIP_PH1_TX_KEY
> TKIP_PH1_RX_KEY
> TKIP_PH2_TX_KEY
> TKIP_PH2_RX_KEY -- actually no need for any driver.
> }
> update_tkip_key(hw, keyconf , iv32, flag, key)
>
> But I'm not sure about this... see above/belove
>
> > The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the
> > new callback would be invoked right from where the phase1 key is
> > calculated.
>
> Sure again I'm not sure this is symmetric - For TX it would be safer
> to do pull mode otherwise it can get out of sync.
True. Hence, since phase2rx is not really useful, we don't actually need
any sort of update flags when we do the TX keys in pull mode, which I
prefer anyway.
> > I'm not exactly sure whether one needs a phase1 key for RX and one for
> > TX right now, but if so a direction flag should be added?
>
> Phase1 for TX and RX are not the same, again because of the simple
> reasone that number of transmitted and received packet is not the
> same.
Hm, right. But if we go for pull mode for TX, we only need to have push
mode for the phase1 rx key when that changes, no?
johannes
>
> Huh ok. But how would the WEP legacy station be able to determine that?
Legacy user get the key written on 'positit' yellow paper :).
> Or does it just try to use WEP and succeed? TBH, I was unaware that this
> existed, this does make it a bit more of a problem than I thought then.
>
> >
> > On second thought is that AP has only TX group key while STA has only
> > RX group key so I
> > m not seeing here any need for flag.
>
> Hm, well, I didn't really want to require the driver to keep track of
> the current operating mode, so that's why I used 00:...:00 vs. FF:...:FF
> for the group keys.
Isn't if on integer faster then comparing 6 bytes?
>
> Is that really done though? I mean, does wpa_supplicant not also use
> encodeext for WEP keys?
>
Unfortunately yes.
>
> > /* IW_AUTH_PAIRWISE_CIPHER and IW_AUTH_GROUP_CIPHER values (bit field) */
> > #define IW_AUTH_CIPHER_NONE 0x00000001
> > #define IW_AUTH_CIPHER_WEP40 0x00000002
> > #define IW_AUTH_CIPHER_TKIP 0x00000004
> > #define IW_AUTH_CIPHER_CCMP 0x00000008
> > #define IW_AUTH_CIPHER_WEP104 0x00000010
> >
> > It's not well defined in wext but we can at least define the interface
> > from mac80211 point of view.
>
> True. So what change do we need?
>
First of all we don't need 4 keys per station but for the whole
system. Even in AP mode with multiple SSID meaning multiple security
setting you cannot distinguish between networks in static WEP key
setting so 4 is enough.
Beside that you need place holder for group key. They might be
multiple groups key in case of multiple SSIDs in AP mode, iwlwifi
doesn't support it in HW but in general it is possible.
We need a flag in set_key which says whether the WEP key is static or not.
Actually second items is currently the show stopper for me the first
Item is just a cleanup.
Thanks
Tomas
> johannes
>
> > Well, you were suggesting the use of multiple SSIDs, which we don't
> > support, we only support VLANs within a BSS/single SSID. Not that I've
> > been able to test it, hostapd needs radius stuff set up for VLANs...
>
> I think it's transparent since it's handled by MLME in hostapd so
> multiple SSID is supported
> Maybe we did some minor changes in mac to support that.. Will check again.
> I think it's always done by means of VLANs
Oh, hm, could be true.
> > Right. I was just saying that the way it currently is I think you could
> > detect it that way. b43 simply assumes WEP keys are always 'static'
> > which seems to mostly work well in practice.
> > I suppose then set_key needs a new argument key_type:
> >
> > enum ieee80211_key_type {
> > KEY_TYPE_PAIRWISE,
> > KEY_TYPE_GROUP,
> > KEY_TYPE_TXONLY, /* group key in an AP */
>
> Can we drop it? Hm still not sure why you like it so much.
Well, we don't want an AP to actually decrypt things, so we need to
distinguish between these things so that the driver doesn't somehow try
to use that key for decryption.
> > KEY_TYPE_STATIC,
> > }
> >
> > where the MAC address pointer would only be non-NULL when the key type
> > is PAIRWISE, and STATIC can only be used for WEP keys.
> >
>
>
> Do you know anything about mesh security are we breaking here anything?
No, Javier, any comments? I think basically you have peer links that are
encrypted, which is just pairwise keys.
johannes
From: Emmanuel Grumbach <[email protected]>
This patch makes the mac80211 able to send a ready phase2 key to the low
level driver for TKIP encryption. Iwlwifi needs to get a phase2 key to
encrypt TX packets in HW.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
include/net/mac80211.h | 5 +++++
net/mac80211/wpa.c | 3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5ab6a35..a0c7cd7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -287,6 +287,7 @@ struct ieee80211_tx_control {
u8 iv_len; /* length of the IV field in octets */
u8 queue; /* hardware queue to use for this frame;
* 0 = highest, hw->queues-1 = lowest */
+ u8 tkip_key[16]; /* generated phase2/phase1 key for hw TKIP */
int type; /* internal */
};
@@ -586,11 +587,15 @@ enum ieee80211_key_alg {
* @IEEE80211_KEY_FLAG_GENERATE_MMIC: This flag should be set by
* the driver for a TKIP key if it requires Michael MIC
* generation in software.
+ * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
+ * the driver for a TKIP key if it requires a phase2 TX key generation
+ * in SW. The key will be attached to each packet.
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_WMM_STA = 1<<0,
IEEE80211_KEY_FLAG_GENERATE_IV = 1<<1,
IEEE80211_KEY_FLAG_GENERATE_MMIC= 1<<2,
+ IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY = 1<<3,
};
/**
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index db6b72b..ee9c5cf 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -224,6 +224,9 @@ static int tkip_encrypt_skb(struct ieee80211_tx_data *tx,
/* hwaccel - with preallocated room for IV */
ieee80211_tkip_add_iv(pos, key);
+ if (key->conf.flags & IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY)
+ ieee80211_tkip_gen_rc4key(key, hdr->addr2,
+ tx->control->tkip_key);
tx->control->key_idx = tx->key->conf.hw_key_idx;
return 0;
}
--
1.5.3.4
On Mon, Mar 17, 2008 at 1:39 PM, Johannes Berg
<[email protected]> wrote:
>
> > iwlwifi firmware also derive phase2 in RX path by itself since this is
> > not really possible to do in host level.
>
> Right. I just wonder why then it needs the host to derive the phase 2
> key for TX, that seems pretty strange. Seems to me a bit like a "what
> can we do" design decision rather than "what makes sense".
The reason is solely engineering. It can be done safely in host so
it's done there.
> > However in case of non
> > matching iv32 such as wraparound it passes packet up unencrypted.
>
> That makes sense.
>
>
> > Therefore HW decryption
> > have to be always backed up by SW one.
>
> Obviously, yes.
>
>
> > Wraparound of Iv32 is reliable only if decryption of a the packet that
> > triggers it is correct. If this is not done and phase1 is advanced by
> > mistake it breaks traffic till the next wraparound actually it will
> > effectively cause disconnection.
>
> Good point. But let's not overload set_key() for it this way. This way,
> the driver needs to look up the key etc. and the semantics get quite
> mangled up. Also, your approach doesn't work for Broadcom hardware that
> only needs phase 1 keys for both RX and TX.
Can you elaborate why it doesn't cover bcom case?
> How about instead we add a new "update_tkip_key()" callback that takes
> exactly the required parameters? It should also give the
> hardware-key-index so that the driver has less work to do.
It's viable but I actually prefer not opening too many interfaces.
Please give me some more detailed sketch how do you see that and we
sure get to some acceptable solution.
Thanks
Tomas
> johannes
>