[feature] Core BLIP 802.15.4 security support

[GoogleCodeExporter]

The attached patch introduces support for standards-compliant 802.15.4 security 
with a network-wide key. Link-specific keys are not supported at this stage. 
All modes from "NONE" up to "CCM128" are supported.

The implementation conceptually consists of two parts - a newly introduced 
tos/lib/encryption/ lib which provides an implementation of the CCM* algorithm 
used by the 802.15.4 standard as well as a generic BlockCipher abstraction, and 
the second part comprises modifications to BLIP (and unfortunately, rfxlink 
layers) to handle the security header and actual encryption/signing.

The CCM* implementation must be wired to a component providing the new 
BlockCipher interface. Typically this would be an AES128 implementation (if you 
want to be standards compliant), but it is a generic component so it can work 
with any block cipher. The attached patch does not provide an AES128 component 
as we're using the on-chip AES module of the xmega256 in our custom-built 
motes. I know that the RF212 chip has an AES module that could be used if it 
was exposed, but this is left as an exercise for the reader (sorry).

Most of the BLIP layer encryption support/changes are found in 
support/sdk/c/blip/lib6lowpan/ieee154_encryption.c, though a substantial number 
of modifications went into support/sdk/c/blip/lib6lowpan/lib6lowpan.c as well. 
In particular, the address compression had to be updated to be more standards 
compliant (rfc6282). This also touched IPNeighborDiscoveryP in regard to 
context matching.

Key management and mode-selection are not included; a user is expected to 
provide the four functions 
blip_ccm_encode/blip_ccm_decode/blip_ccm_security_mode/blip_ccm_accepted_modes. 
These functions form the "glue" between BLIP and the CCM* implementation. Given 
BLIP is pure C and can't be wired to directly, this approach seemed the best 
compromise. An example of these four functions is included in the second patch 
(CCM_Thunk.nc), but is specific to our application. Wiring would typically look 
something like:
  components new CcmStarC(cipherblock128_t,nx_uint16_t);
  components Aes128C;
  components Ccm_ThunkC;

  CcmStarC.BlockCipher -> Aes128C;
  Ccm_ThunkC.CcmStar -> CcmStarC; 

Known deficiencies:

- Due to the architecture of TinyOS BLIP, we had to put the encryption layer 
high up in the stack, rather than right above the radio layer where it would 
sit better (and allow for offloading to the radio chip where the chip provides 
such functionality). With BLIP packing its own raw 15.4 frames rather than 
using e.g. a more full-featured Ieee154PacketLayer (see issue 30 for a start on 
this), we had no choice as we didn't have the time nor man-power to do a large 
stack/layer rewrite.

- As a result of the position of the encryption layer, we had to move/replicate 
the UniqueLayer and SoftwareAckLayer functionality of assigning the sequence 
number and setting of the ACK flag, as otherwise these layers would change 
header values which had already been signed (and hence, break decryption). The 
UniqueLayer change is a horrid hack, but we see no way around it. It should 
probably be wrapped in an if-using-blip #define, however.

- We piggy-backed the frame counter and security control data on the frame_addr 
parameter, as it was already passed through to the places we needed those new 
values. It really should be split out into its own security_attrs parameter 
though.

- The frame counter should be stored in nvram for standards compliance. Our 
implementation resets it on boot. This weakens the security somewhat (I'm not 
qualified to say by how much).

- The 802.15.4 standard appears to make no provision for using security 
together with short addresses. Our implementation does not impose this 
restriction, but simply zero-expands a short address before feeding it in to 
the nonce-generator.

- The existing bit_range_zero() implementation appears incorrect as written, 
but as the address compression no longer uses it, we left it alone to avoid 
potentially breaking the other uses of it. See FIXME comments in said function.

- FYI: Wireshark doesn't implement address decompression properly either, which 
made it a pain to verify the over-the-air packets. Hacking of 
epan/dissectors/packet-6lowpan.c is needed to compensate.

- As-is, this patch enables security support unconditionally. Before adoption 
into the TinyOS tree, it should be suitably #ifdef'd to allow conditional 
inclusion.

- Finally, these patches are off the internal DiUS TinyOS-2.x source tree. Our 
last merge with trunk was at r5884. Patches may have some fuzz. We submit this 
in the hope that the TinyOS community will find it useful and adapt it for the 
regular TinyOS platforms.

Original issue reported on code.google.com by jmatts...@dius.com.au on 10 Feb 2012 at 12:08

Attachments:

• tinyos-154-encryption.patch
• tinyos-154-encryption-thunk.patch

[GoogleCodeExporter]

Thanks for the patch.

It looks to me like this would be something that would best live in contrib/ 
for the time being that's the place we have for contributed code.  We can get 
you set up there if you don't have an account.  I tend to agree that we need to 
move to a better Ieee154Layer type of interface.

Original comment by sdh...@gmail.com on 15 Feb 2012 at 8:04

• Changed state: WontFix

[GoogleCodeExporter]

Sure, that could be good. I'm about to move off this project now, but I'd like 
to open the atxm256/LSR-modflex support before I do so, even if it's not up to 
a sufficient standard for mainline inclusion. Contrib/ might be just the place 
for it.

Original comment by jmatts...@dius.com.au on 17 Feb 2012 at 12:52