Re: [PATCH] ath5k: add support of HW encryption in management frames

[Jouni Malinen <j@w1.fi>]

On Tue, Sep 04, 2012 at 05:28:40PM +0800, Yeoh Chun-Yeow wrote:
> Hi, Johannes
> 
> > _How_ did you test this? Did you test that management frames are
> > properly encrypted using AES CCM, and not mangled when decrypted?
> 
> I have setup the two mesh nodes using the secured mesh with the
> following key installation:
> 
> /* key to encrypt/decrypt unicast data AND mgmt traffic to/from this peer */
> install_key(&nlcfg, peer, CIPHER_CCMP, NL80211_KEYTYPE_PAIRWISE, 0, mtk);
> 
> I confirm that the hardware key for CCMP is set and
> IEEE80211_KEY_FLAG_SW_MGMT is not enabled in mac80211-ops.c. Both
> nodes are able to ping each others. Is this enough?

Depends on what those nodes were.. If they were both using the same
ath5k implementation, then no, that would not be enough. If the CCMP
processing is done incorrectly, they could both mangle the results in
the same way to hide the issue. It should also be noted that there has
been key cache changes between hardware revisions, so working with
AR2414 or even AR5213 does not necessarily mean that this would work
with AR5210, AR5211, or AR5212.

You would need to test an ath5k-based device with another device that is
known to handle unicast robust management frame protection correctly. If
you do not have a suitable other device for this, it should be possible
to force one of the devices to use software encryption for everything
(i.e., make sure it does not configure any CCMP keys in the hardware key
cache) and then run a test that exchanges robust unicast management
frames (both TX and RX using the modified ath5k driver). I would also
verify that unicast data frames get processed in hardware and robust
management frames in software.

-- 
Jouni Malinen                                            PGP id EFC895FA