iwpan with LLSEC - attribute type 1 has an invalid length

iwpan with LLSEC - attribute type 1 has an invalid length

[Benjamin Valentin]

Hi,

I'm trying to use the Linux WPAN stack with link-layer security.
I checked out the nl802154_llsec branch of wpan-tools and enabled the
IEEE802154_NL802154_EXPERIMENTAL config option.

I followed the steps outlined in [0], but configuring the seclevel
would always fail with

> netlink: 'iwpan': attribute type 1 has an invalid length.

in dmesg.
I followed the commands from the GitHub wiki:

KEY="c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf"
WPAN=wpan0

PANID=$(iwpan     dev $WPAN info | grep pan_id        | head -1 | awk '{print $2}')
SHORTADDR=$(iwpan dev $WPAN info | grep short_addr    | head -1 | awk '{print $2}')
EXTADDR=$(iwpan   dev $WPAN info | grep extended_addr | head -1 | awk '{print $2}')

iwpan dev $WPAN set security 1 # works fine
iwpan dev --debug $WPAN key add 2 $KEY 0 $PANID 3 $EXTADDR # works fine

-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 112
    .type = 24 <0x18>
    .flags = 5 <REQUEST,ACK>
    .seq = 1603033315
    .port = 1971323733
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 23
    .version = 0
    .unused = 0
  [PAYLOAD] 92 octets
    08 00 03 00 03 00 00 00 54 00 25 00 05 00 02 00 ........T.%.....
    02 00 00 00 14 00 04 00 c0 c1 c2 c3 c4 c5 c6 c7 ................
    c8 c9 ca cb cc cd ce cf 34 00 01 00 28 00 03 00 ........4...(...
    06 00 01 00 23 00 00 00 08 00 02 00 03 00 00 00 ....#...........
    06 00 03 00 00 ab 00 00 0c 00 04 00 8f d7 0c a1 ................
    9c 41 04 92 08 00 01 00 00 00 00 00             .A..........
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq = 1603033315
    .port = 1971323733
  [ERRORMSG] 20 octets
    .error = 0 "Success"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 24 <0x18>
    .flags = 5 <REQUEST,ACK>
    .seq = 1603033315
    .port = 1971323733
---------------------------  END NETLINK MESSAGE   ---------------------------

iwpan --debug dev $WPAN seclevel add 0xff 2 0 # dmesg says attribute type 1 has an invalid length.

-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 56
    .type = 24 <0x18>
    .flags = 5 <REQUEST,ACK>
    .seq = 1603033355
    .port = 1535116138
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 32
    .version = 0
    .unused = 0
  [PAYLOAD] 36 octets
    08 00 03 00 03 00 00 00 1c 00 22 00 08 00 01 00 ..........".....
    ff 00 00 00 08 00 02 00 02 00 00 00 05 00 04 00 ................
    00 00 00 00                                     ....
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 36
    .type = 2 <ERROR>
    .flags = 256 <ROOT>
    .seq = 1603033355
    .port = 1535116138
  [ERRORMSG] 20 octets
    .error = 0 "Success"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 24 <0x18>
    .flags = 5 <REQUEST,ACK>
    .seq = 1603033355
    .port = 1535116138
---------------------------  END NETLINK MESSAGE ---------------------------

I then continue with

iwpan dev $WPAN device add 0 $PANID $SHORTADDR $EXTADDR 0 0
iwpan dev $WPAN set out_level 0x05
iwpan dev $WPAN set out_key_id 0 $PANID 2 $SHORTADDR 3 $EXTADDR

But I can not receive encrypted frames nor can I send any - instead I get

[  502.970528] ieee802154 phy0 wpan0: encryption failed: -126
[  503.972415] ieee802154 phy0 wpan0: encryption failed: -126

in dmesg.

iwpan dev wpan0 info gives:

Interface wpan0
	ifindex 3
	wpan_dev 0x1
	extended_addr 0x9204419ca10cd78f
	short_addr 0xffff
	pan_id 0x0023
	type node
	max_frame_retries 3
	min_be 3
	max_be 5
	max_csma_backoffs 4
	lbt 0
	ackreq_default 0
	security 1
	out_level 5
	out_key_id
		mode implicit
		pan_id 0x0023
		addr_mode 2
		short_addr 0xffff
	frame_counter 0x00000000

Is LLSEC broken or am I configuring it wrong?

Best,
Benjamin

[0]
https://github.com/linux-wpan/wpan-tools/wiki/Guide:-Contiki-%E2%86%94-Linux,-with-llsec#linuxiwpan-configuration

Re: iwpan with LLSEC - attribute type 1 has an invalid length

[Alexander Aring]

Hi,

On Sun, 18 Oct 2020 at 11:48, Benjamin Valentin
<benjamin.valentin@ml-pa.com> wrote:
>
> Hi,
>
> I'm trying to use the Linux WPAN stack with link-layer security.
> I checked out the nl802154_llsec branch of wpan-tools and enabled the
> IEEE802154_NL802154_EXPERIMENTAL config option.
>
> I followed the steps outlined in [0], but configuring the seclevel
> would always fail with
>
> > netlink: 'iwpan': attribute type 1 has an invalid length.
>
> in dmesg.
> I followed the commands from the GitHub wiki:
>
> KEY="c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf"
> WPAN=wpan0
>
> PANID=$(iwpan     dev $WPAN info | grep pan_id        | head -1 | awk '{print $2}')
> SHORTADDR=$(iwpan dev $WPAN info | grep short_addr    | head -1 | awk '{print $2}')
> EXTADDR=$(iwpan   dev $WPAN info | grep extended_addr | head -1 | awk '{print $2}')
>
> iwpan dev $WPAN set security 1 # works fine
> iwpan dev --debug $WPAN key add 2 $KEY 0 $PANID 3 $EXTADDR # works fine
>
> -- Debug: Sent Message:
> --------------------------   BEGIN NETLINK MESSAGE ---------------------------
>   [NETLINK HEADER] 16 octets
>     .nlmsg_len = 112
>     .type = 24 <0x18>
>     .flags = 5 <REQUEST,ACK>
>     .seq = 1603033315
>     .port = 1971323733
>   [GENERIC NETLINK HEADER] 4 octets
>     .cmd = 23
>     .version = 0
>     .unused = 0
>   [PAYLOAD] 92 octets
>     08 00 03 00 03 00 00 00 54 00 25 00 05 00 02 00 ........T.%.....
>     02 00 00 00 14 00 04 00 c0 c1 c2 c3 c4 c5 c6 c7 ................
>     c8 c9 ca cb cc cd ce cf 34 00 01 00 28 00 03 00 ........4...(...
>     06 00 01 00 23 00 00 00 08 00 02 00 03 00 00 00 ....#...........
>     06 00 03 00 00 ab 00 00 0c 00 04 00 8f d7 0c a1 ................
>     9c 41 04 92 08 00 01 00 00 00 00 00             .A..........
> ---------------------------  END NETLINK MESSAGE   ---------------------------
> -- Debug: Received Message:
> --------------------------   BEGIN NETLINK MESSAGE ---------------------------
>   [NETLINK HEADER] 16 octets
>     .nlmsg_len = 36
>     .type = 2 <ERROR>
>     .flags = 256 <ROOT>
>     .seq = 1603033315
>     .port = 1971323733
>   [ERRORMSG] 20 octets
>     .error = 0 "Success"
>   [ORIGINAL MESSAGE] 16 octets
>     .nlmsg_len = 16
>     .type = 24 <0x18>
>     .flags = 5 <REQUEST,ACK>
>     .seq = 1603033315
>     .port = 1971323733
> ---------------------------  END NETLINK MESSAGE   ---------------------------
>
> iwpan --debug dev $WPAN seclevel add 0xff 2 0 # dmesg says attribute type 1 has an invalid length.
>

2 is ack frame, I think you mean 1.

> -- Debug: Sent Message:
> --------------------------   BEGIN NETLINK MESSAGE ---------------------------
>   [NETLINK HEADER] 16 octets
>     .nlmsg_len = 56
>     .type = 24 <0x18>
>     .flags = 5 <REQUEST,ACK>
>     .seq = 1603033355
>     .port = 1535116138
>   [GENERIC NETLINK HEADER] 4 octets
>     .cmd = 32
>     .version = 0
>     .unused = 0
>   [PAYLOAD] 36 octets
>     08 00 03 00 03 00 00 00 1c 00 22 00 08 00 01 00 ..........".....
>     ff 00 00 00 08 00 02 00 02 00 00 00 05 00 04 00 ................
>     00 00 00 00                                     ....
> ---------------------------  END NETLINK MESSAGE   ---------------------------
> -- Debug: Received Message:
> --------------------------   BEGIN NETLINK MESSAGE ---------------------------
>   [NETLINK HEADER] 16 octets
>     .nlmsg_len = 36
>     .type = 2 <ERROR>
>     .flags = 256 <ROOT>
>     .seq = 1603033355
>     .port = 1535116138
>   [ERRORMSG] 20 octets
>     .error = 0 "Success"

Success? Like above? Can you tell me the command line error message
please? What does tell you "type 1 has an invalid length"

>   [ORIGINAL MESSAGE] 16 octets
>     .nlmsg_len = 16
>     .type = 24 <0x18>
>     .flags = 5 <REQUEST,ACK>
>     .seq = 1603033355
>     .port = 1535116138
> ---------------------------  END NETLINK MESSAGE ---------------------------
>
> I then continue with
>
> iwpan dev $WPAN device add 0 $PANID $SHORTADDR $EXTADDR 0 0
> iwpan dev $WPAN set out_level 0x05
> iwpan dev $WPAN set out_key_id 0 $PANID 2 $SHORTADDR 3 $EXTADDR
>
> But I can not receive encrypted frames nor can I send any - instead I get
>
> [  502.970528] ieee802154 phy0 wpan0: encryption failed: -126
> [  503.972415] ieee802154 phy0 wpan0: encryption failed: -126
>

It tells you -ENOKEY, the whole thing has an ACL and somehow the
lookup cannot find a key (if sec is enabled).

> in dmesg.
>
> iwpan dev wpan0 info gives:
>
> Interface wpan0
>         ifindex 3
>         wpan_dev 0x1
>         extended_addr 0x9204419ca10cd78f
>         short_addr 0xffff
>         pan_id 0x0023
>         type node
>         max_frame_retries 3
>         min_be 3
>         max_be 5
>         max_csma_backoffs 4
>         lbt 0
>         ackreq_default 0
>         security 1
>         out_level 5
>         out_key_id
>                 mode implicit
>                 pan_id 0x0023
>                 addr_mode 2
>                 short_addr 0xffff
>         frame_counter 0x00000000
>
> Is LLSEC broken or am I configuring it wrong?

It's been a long time since I worked with it, it's good to have the
802.15.4 standard right beside you, the implementation is very close
to that structure that they describe.

There are known issues:

 - Don't trust wireshark, you will not see exactly what's sending out
on the wire. We just do the encryption on the wrong layer, but moving
it was causing other problems. I recently stumbled over something
which maybe can help us there, but didn't look closely at that, some
subsystems have special handling for tcpdump/wireshark things.
 - The frame_counter thing that you see above needs to be synchronized
on all nodes, if nodes join with a zero value you can do replay
attacks. 802.15.4 doesn't solve that on the link layer for peer to
peer, MLE can do that in a way to just make the attack window smaller.
 - When the fame_counter overflows you need a new key, means key
management and key exchange. Biggest problem :-) I was talking with
Koen about that once... he showed me some interesting stuff, forgot
the name..

Please dump more:

iwpan dev $WPAN_DEV seclevel dump
iwpan dev $WPAN_DEV device dump
iwpan dev $WPAN_DEV devkey dump
iwpan dev $WPAN_DEV key dump

- Alex

Re: iwpan with LLSEC - attribute type 1 has an invalid length

[Benjamin Valentin]

On Sun, 18 Oct 2020 19:20:53 -0400
Alexander Aring <alex.aring@gmail.com> wrote:

> 2 is ack frame, I think you mean 1.

Same error with 1
 
> Success? Like above? Can you tell me the command line error message
> please? What does tell you "type 1 has an invalid length"

dmesg tells me that when I enter that command:

[  156.899429] netlink: 'iwpan': attribute type 1 has an invalid length.

So I assume that's why encryption fails.

>  - Don't trust wireshark, you will not see exactly what's sending out
> on the wire. We just do the encryption on the wrong layer, but moving
> it was causing other problems. I recently stumbled over something
> which maybe can help us there, but didn't look closely at that, some
> subsystems have special handling for tcpdump/wireshark things.

Would that cause interoperability issues with other implementations? 

>  - The frame_counter thing that you see above needs to be synchronized
> on all nodes, if nodes join with a zero value you can do replay
> attacks. 802.15.4 doesn't solve that on the link layer for peer to
> peer, MLE can do that in a way to just make the attack window smaller.
>  - When the fame_counter overflows you need a new key, means key
> management and key exchange. Biggest problem :-) I was talking with
> Koen about that once... he showed me some interesting stuff, forgot
> the name..

Urgh this just came up again in https://github.com/RIOT-OS/RIOT/pull/15150
Does the standard suggest anything here?
How does Thread solve this?

> Please dump more:
> 
> iwpan dev $WPAN_DEV seclevel dump

iwpan dev $WPAN_DEV seclevel add 0xff 1 0 

> iwpan dev $WPAN_DEV device dump

iwpan dev $WPAN_DEV device add 0x00000000 0x0023 0xffff 0x82b989a7f0d5decb 0 0 

> iwpan dev $WPAN_DEV devkey dump

[nothing]

> iwpan dev $WPAN_DEV key dump

iwpan dev $WPAN_DEV key add 0x02 c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf 0 0x0023 3 0x82b989a7f0d5decb 
 
> - Alex

Thank you for your help,
Benjamin

Re: iwpan with LLSEC - attribute type 1 has an invalid length

[Alexander Aring]

Hi,

On Mon, 19 Oct 2020 at 02:07, Benjamin Valentin
<benjamin.valentin@ml-pa.com> wrote:
>
> On Sun, 18 Oct 2020 19:20:53 -0400
> Alexander Aring <alex.aring@gmail.com> wrote:
>
> > 2 is ack frame, I think you mean 1.
>
> Same error with 1
>
> > Success? Like above? Can you tell me the command line error message
> > please? What does tell you "type 1 has an invalid length"
>
> dmesg tells me that when I enter that command:
>
> [  156.899429] netlink: 'iwpan': attribute type 1 has an invalid length.

There are recent changes to netlink to "validate" more netlink policy
and I think we are doing it wrong in kernel or user.

Try wpan-tools:

diff --git a/src/security.c b/src/security.c
index 1659699..8062608 100644
--- a/src/security.c
+++ b/src/security.c
@@ -299,7 +299,7 @@ static int print_seclevel_handler(struct nl_msg
*msg, void *arg)
        if (tb[NL802154_ATTR_SEC_LEVEL]) {
                struct nlattr *tb_seclevel[NL802154_SECLEVEL_ATTR_MAX + 1];
                static struct nla_policy
seclevel_policy[NL802154_SECLEVEL_ATTR_MAX + 1] = {
-                       [NL802154_SECLEVEL_ATTR_LEVELS] = { .type = NLA_U32 },
+                       [NL802154_SECLEVEL_ATTR_LEVELS] = { .type = NLA_U8 },
                        [NL802154_SECLEVEL_ATTR_FRAME] = { .type = NLA_U32 },
                        [NL802154_SECLEVEL_ATTR_CMD_FRAME] = { .type =
NLA_U32 },
                        [NL802154_SECLEVEL_ATTR_DEV_OVERRIDE] = {
.type = NLA_U8 },
@@ -400,7 +400,7 @@ static int handle_seclevel_add(struct
nl802154_state *state, struct nl_cb *cb,
        if (!seclevel_msg)
                return -ENOMEM;

-       NLA_PUT_U32(seclevel_msg, NL802154_SECLEVEL_ATTR_LEVELS, levels);
+       NLA_PUT_U8(seclevel_msg, NL802154_SECLEVEL_ATTR_LEVELS, levels);
        NLA_PUT_U32(seclevel_msg, NL802154_SECLEVEL_ATTR_FRAME, frame);
        if (frame == NL802154_FRAME_CMD)
                NLA_PUT_U32(seclevel_msg,
NL802154_SECLEVEL_ATTR_CMD_FRAME, cmd_id);


That should fix it.

> So I assume that's why encryption fails.
>
> >  - Don't trust wireshark, you will not see exactly what's sending out
> > on the wire. We just do the encryption on the wrong layer, but moving
> > it was causing other problems. I recently stumbled over something
> > which maybe can help us there, but didn't look closely at that, some
> > subsystems have special handling for tcpdump/wireshark things.
>
> Would that cause interoperability issues with other implementations?
>

No, just use a monitor interface to see what the on air traffic is.
Don't trust local captures.

- Alex

Re: iwpan with LLSEC - attribute type 1 has an invalid length

[Benjamin Valentin]

On Mon, 19 Oct 2020 15:54:30 -0400
Alexander Aring <alex.aring@gmail.com> wrote:

> That should fix it.

Thank you, that fixed it indeed!

Well, insofar that I don't get any netlink errors anymore during setup.
I still get

[  331.928242] ieee802154 phy0 wpan0: encryption failed: -126
[  332.971098] ieee802154 phy0 wpan0: encryption failed: -126

when trying to send packets. No plaintext traffic is sent either, the
radio just remains silent.
Receiving encrypted frames (from RIOT) also doesn't work (I assumed that mrf24j40
bug was fixed by now)

My complete setup script is

KEY="c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf"
WPAN=wpan0

PANID=$(iwpan     dev $WPAN info | grep pan_id        | head -1 | awk '{print $2}')
SHORTADDR=$(iwpan dev $WPAN info | grep short_addr    | head -1 | awk '{print $2}')
EXTADDR=$(iwpan   dev $WPAN info | grep extended_addr | head -1 | awk '{print $2}')

iwpan dev $WPAN set security 1
iwpan dev $WPAN key add 2 $KEY 0 $PANID 3 $EXTADDR
iwpan dev $WPAN seclevel add 0xff 1 0
iwpan dev $WPAN device add 0 $PANID $SHORTADDR $EXTADDR 0 0
iwpan dev $WPAN set out_level 0x05
iwpan dev $WPAN set out_key_id 0 $PANID 2 $SHORTADDR 3 $EXTADDR

> > >  - Don't trust wireshark, you will not see exactly what's sending
> > > out on the wire. We just do the encryption on the wrong layer,
> > > but moving it was causing other problems. I recently stumbled
> > > over something which maybe can help us there, but didn't look
> > > closely at that, some subsystems have special handling for
> > > tcpdump/wireshark things.  
> >
> > Would that cause interoperability issues with other implementations?
> >  
> 
> No, just use a monitor interface to see what the on air traffic is.
> Don't trust local captures.

Don't worry, I'm using a CC2531 dongle with whsniff, only looking at
traffic that's actually on the air.

Best,
Benjamin