netdev - Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Feb 2017 21:47:15 +0000
From:   "Malinen, Jouni" <jouni@....qualcomm.com>
To:     "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>
CC:     "johannes@...solutions.net" <johannes@...solutions.net>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On Fri, Feb 03, 2017 at 07:25:53PM +0000, Ard Biesheuvel wrote:
> The mac80211 aes_cmac code reimplements the CMAC algorithm based on the
> core AES cipher, which is rather restrictive in how platforms can satisfy
> the dependency on this algorithm. For instance, SIMD implementations may
> have a considerable setup time, which cannot be amortized over the entire
> input when calling into the crypto API one block at a time. Also, it prevents
> the use of more secure fixed time implementations, since not all AES drivers
> expose the cipher interface.
> 
> So switch aes_cmac to use a cmac(aes) shash. This requires a preparatory
> patch so that we can remove the open coded implementation, which it shares
> with the fils aead driver. That driver could receive the same treatment, in
> which case we could replace patch #1 with one that carries it over first.
> 
> Note that this is an RFC. I have no idea how I would go about testing this
> code, but I am on a mission to remove as many dependencies on the generic
> AES cipher as I can.

Neither the BIP nor FILS cases have any real speed requirements taken
into account how rarely they end up being used in practice (there is
really no use case for BIP today and FILS is used only once per
association). That said, there should be no issues with moving these to
a more generic mechanism assuming one is available now (I don't think
that was the case when I was working on BIP and I was too lazy to figure
out how to convert it or the newer FILS implementation)..

mac80211_hwsim show allow some of the testing to be done with wlantest
confirming the results in user space (*). I think that would cover all
of BIP (net/mac80211/aes_cmac.c), but not FILS. For FILS, we do not
currently have a convenient mechanism for running two different
instances of kernel or even just mac80211 in the setup, so that would
likely need testing with real WLAN hardware. I don't currently have a
good setup for testing this (was using Backports-based solution in the
past instead of full kernel build and Backports is a bit behind the
current state..), but I guess I'll need to build something functional
for this eventually.. Once that's in working condition on two devices,
it would be straightforward to run a test (snapshot of hostap.git build
to enable FILS functionality and go through one FILS authentication
round)..

Another alternative would be to extend wlantest to decrypt/validate FIPS
AEAD use case based on keys exposed from hostapd or wpa_supplicant.
There has not been sufficient use case for that so far and I have not
bothered working on it yet.

By the way, FILS AEAD uses SIV mode and I'm not sure it is supported in
the current crypto code, so that would be one additional piece to take
care of when considering net/mac80211/fils_aead.c conversion.

(*)
http://buildbot.w1.fi/hwsim/
http://w1.fi/cgit/hostap/tree/tests/hwsim/vm/example-vm-setup.txt

-- 
Jouni Malinen                                            PGP id EFC895FA