[riot-users] CC2538DK board and encryption in the "default" example

Stuart Longland stuartl at vrt.com.au
Fri May 19 08:00:49 CEST 2017


On 19/05/17 10:20, Stuart Longland wrote:
> Host here is Gentoo Linux.  If there is something I've neglected to
> supply here, please tell me… I don't expect you all to be mind readers,
> but I am not one myself.
> 
> About the only clue I seem to have is in sys/shell/commands/sc_netif.c
> there's this code (lines 869-874):
> 
>>     else if (strcmp("encrypt", key) == 0) {
>>         return _netif_set_encrypt(dev, NETOPT_ENCRYPTION, value);
>>     }
>>     else if (strcmp("key", key) == 0) {
>>         return _netif_set_encrypt_key(dev, NETOPT_ENCRYPTION_KEY, value);
>>     }
> The only reference I see to this is here:
> 
>> $ grep -Rl NETOPT_ENCRYPTION *
>> drivers/xbee/xbee.c
>> sys/include/net/netopt.h
>> sys/net/crosslayer/netopt/netopt.c
>> sys/shell/commands/sc_netif.c
> Am I to understand then by this that IEEE 802.15.4 link-layer encryption
> is only supported on XBee hardware?

Okay, further digging.  I actually downloaded the IEEE 802.15.4-2015
spec.  Section 9 covers security and Annex C gives some worked examples.

In the frame header within the Frame Control Field byte, there is a
single bit, Security Enabled, that decides whether there is security
involved.  Then there's the auxiliary security header.

The first byte in the ASH is the ASH control field, which contains
sub-fields for:

- 3 bits: Security Level which defines how the frame is authenticated
and encrypted.
	Bit 2 turns encryption on/off
	Bits 1 & 0 specify the authentication type:
		0 = no authentication
		1 = MIC 32
		2 = MIC 64
		3 = MIC 128
	Mode 100b (encryption without authentication) is "deprecated"
	in the 802.15.4-2015 standard and is marked as "reserved".
- 2 bits: Key ID mode
	0 = Implicit: there is no key ID
	1 = Key ID stores just the key index (1 byte)
	2 = Key ID stores 4-byte key source and 1-byte key index
	3 = Key ID stores 8-byte key source and 1-byte key index
- and some other control fields.

I see no reference to the above anywhere in the RIOT-OS sources.

Given the XBee seems to just have two commands that map directly to
those two functions above, I would guess they use implicit mode (so Key
ID mode = 0).  *Clearly* they use one of the encrypted key modes, so 4,
5, 6 or 7 or else it'd be blatant false advertising.

In the interests of being compatible with this implementation of IEEE
802.15.4, and to minimise the changes needed to RIOT-OS, it'd be worth
looking at adding some code that does frame payload encryption and can
optionally take a third parameter that chooses the authentication mode.

This would in theory allow interoperability with such devices.  It does
look though that the features will need to be *added*, it isn't possible
with RIOT-OS out-of-the-box.

Sadly, in the interests of expediency with my project, it does look like
I need to look elsewhere.
-- 
     _ ___             Stuart Longland - Systems Engineer
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au


More information about the users mailing list