Hi,
On Sun, 18 Oct 2020 at 11:48, Benjamin Valentin
<benjamin.valentin@xxxxxxxxx> 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
