ieee802154: add types for link-layer security

The added structures match 802.15.4-2011 link-layer security PIBs as
closely as is reasonable. Some lists required by the standard were
modeled as bitmaps (frame_types and command_frame_ids in *llsec_key,
802.15.4-2011 7.5/Table 61), since using lists for those seems a bit
excessive and not particularly useful. The DeviceDescriptorHandleList
was inverted and is here a per-device list, since operations on this
list are likely to have both a key and a device at hand, and per-device
lists of keys are shorter than per-key lists of devices.

For the mac802154 implementation of llsec, we mostly need only containers with
a little management info for the ieee802154* versions of these structs.
The one exception is they key struct, which requires one AEAD transform
for encryption and decryption per authsize and a CTR transform for
unauthenticated encryption/decryption. If we had a CCM* mode, which is
just like CCM but also supports authsize == 0, this would be less hacky.

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: update Kconfig

Link-layer security requires AES CCM for authenticated modes and AES CTR
for the unauthenticated encryption mode.

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec init/destroy and parameter access functions

Per-llsec hashes and lists can be safely initialized here, but delay adding
cleanup code for those lists and hashes while their element accessors do
not yet exists. llsec keys and devices require special cleanup code.

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec key management functions

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec device management functions

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec device key management functions

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec security level management functions

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec encryption method

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec decryption method

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: integrate llsec with wpan devices

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add dgram sockopts for security control

Allow datagram sockets to override the security settings of the device
they send from on a per-socket basis. Requires CAP_NET_ADMIN or
CAP_NET_RAW, since raw sockets can send arbitrary packets anyway.

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: add llsec configuration functions

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
mac802154: propagate device address changes to llsec

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add netlink interfaces for llsec parameter configuration

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add netlink interfaces for llsec key table configuration

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add netlink interface for llsec device table configuration

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add netlink interface for llsec devkey table configuration

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154: add netlink interface for llsec seclevel table configuration

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
ieee802154, mac802154: implement devkey record option

The 802.15.4-2011 standard states that for each key, a list of devices
that use this key shall be kept. Previous patches have only considered
two options:

 * a device "uses" (or may use) all keys, rendering the list useless
 * a device is restricted to a certain set of keys

Another option would be that a device *may* use all keys, but need not
do so, and we are interested in the actual set of keys the device uses.
Recording keys used by any given device may have a noticable performance
impact and might not be needed as often. The common case, in which a
device will not switch keys too often, should still perform well.

Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>