ieee802154: MAC security procedure minus CCM*

[bbbert]

This PR implements the incoming and outgoing frame security procedures, save for the actual calls to CCM* encryption/decryption. That will have to wait for CBC encryption to be in mainline. Along the way, it also does the following things:

• Update the userspace code using the radio. I think some of the tiny changes (offsets and lengths and the way they are passed between kernel and userspace) must have gotten lost when the test files were moved.
• Mirror the imixv1 initialization code over to the imix initialization code.
• Remove unnecessary config callback logic from capsules::mac: it turns out the radio already does this.
• When parsing headers of secured frames, we must be careful not to try to parse payload IEs. This is accomplished by a flag into the decode function.
• Two hilarious bugs in the ieee802154 parsing code: AddressMode#from_mode and seq_suppressed in Header#decode. Thanks @ptcrews.

Here's a few notes on the incoming security procedure: When a secured frame arrives, the process in this PR parses the header portion of the frame, unsecures it, and then re-parses the full header (including payload IEs). One could conceivably store the parts of the header that were already parsed and update them after unsecuring, but I chose not to do that because parsing is relatively fast (it's only a few bytes). Secondly, we expose plaintext frames to the user without removing the auxiliary security header. Technically, the IEEE 802.15.4 spec says that the unsecuring process should also remove this auxiliary security header and update the "Security present" bit, but this would prevent the user from ever knowing if the frame was secured. While this currently makes no difference, I think there might be a use-case for checking if the frame had link-layer security and performing some kind of business logic.

[niklasad1]

I have not looked very closely at the 802.15.4 standard but it looks like the following security modes exist:

1. AES-CBC-MAC-X   | Data authenticity is validated. |  
2. AES-CTR   | Data is encrypted |  
3. AES-CCM-X   | Data is encrypted. Data authenticity is validated. |  

According to the datasheet of SAM4L the following modes of AES are supported:
• Electronic Code Book (ECB)
• Cipher Block Chaining (CBC)
• Output Feedback (OFB)
• Cipher Feedback (CFB)
• CTR: Counter

That is bad it means that you have implement both CBC-MAC and CCM on top of plain AES?

I know that nRF51 support AES-CCM in hardware if you can utilize that chip it would facilitate

Do we need all modes?
If I would choose one mode I would use AES-CCM because it is authenticated encryption.

[alevy]

@niklasad1 there is already some work in progress for implementing the necessary modes, but at a high level, both CBC-MAC and CCM* can be implemented using the SAM4L's CBC and CTR modes: CBC-MAC is encrypting in CBC mode and using the last block as the tag, and CCM is a CTR mode encryption of the CBC-MAC of the plaintext concatenated to the plaintext.

[bbbert]

Right. The only part of the 802.15.4 standard that I think we need is the AES-CCM mode (actually, CCM*, which is CCM with more options for MAC lengths), since that is what is required by Thread. I already have code that implements this. It's not yet a PR because the exact implementation details will depend on how the SAM4L's CBC and CTR modes are exposed as an interface.

On a side note, I didn't realize that imixv1 was removed. I'll rebase soon.

[alevy]

@bbbert looks great! I fine merging this now, but I'd like to read it more carefully so I have chance to follow along. So if it's not a blocker for you to wait until tomorrow, I'll wait. If it is a blocker, fine merging now too.

[bbbert]

@alevy Thanks! Take your time, I can always work off a local branch.