linux-wpan.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Cc: linux-wpan - ML <linux-wpan@vger.kernel.org>, koen@bergzand.net
Subject: Re: iwpan with LLSEC - attribute type 1 has an invalid length
Date: Sun, 18 Oct 2020 19:20:53 -0400	[thread overview]
Message-ID: <CAB_54W5VgY+DeqdjiQ7BJsmXw-G=POwGE7tzYuwAwYixe6y9XQ@mail.gmail.com> (raw)
In-Reply-To: <20201018170934.2c03c9e3@rechenknecht2k11>

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

  reply	other threads:[~2020-10-18 23:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-18 15:09 iwpan with LLSEC - attribute type 1 has an invalid length Benjamin Valentin
2020-10-18 23:20 ` Alexander Aring [this message]
2020-10-19  6:07   ` Benjamin Valentin
2020-10-19 19:54     ` Alexander Aring
2020-10-19 20:13       ` Benjamin Valentin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAB_54W5VgY+DeqdjiQ7BJsmXw-G=POwGE7tzYuwAwYixe6y9XQ@mail.gmail.com' \
    --to=alex.aring@gmail.com \
    --cc=benjamin.valentin@ml-pa.com \
    --cc=koen@bergzand.net \
    --cc=linux-wpan@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).