* iwpan with LLSEC - attribute type 1 has an invalid length
@ 2020-10-18 15:09 Benjamin Valentin
2020-10-18 23:20 ` Alexander Aring
0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Valentin @ 2020-10-18 15:09 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: iwpan with LLSEC - attribute type 1 has an invalid length 2020-10-18 15:09 iwpan with LLSEC - attribute type 1 has an invalid length Benjamin Valentin @ 2020-10-18 23:20 ` Alexander Aring 2020-10-19 6:07 ` Benjamin Valentin 0 siblings, 1 reply; 5+ messages in thread From: Alexander Aring @ 2020-10-18 23:20 UTC (permalink / raw) To: Benjamin Valentin; +Cc: linux-wpan - ML, koen 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iwpan with LLSEC - attribute type 1 has an invalid length 2020-10-18 23:20 ` Alexander Aring @ 2020-10-19 6:07 ` Benjamin Valentin 2020-10-19 19:54 ` Alexander Aring 0 siblings, 1 reply; 5+ messages in thread From: Benjamin Valentin @ 2020-10-19 6:07 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan - ML, koen 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iwpan with LLSEC - attribute type 1 has an invalid length 2020-10-19 6:07 ` Benjamin Valentin @ 2020-10-19 19:54 ` Alexander Aring 2020-10-19 20:13 ` Benjamin Valentin 0 siblings, 1 reply; 5+ messages in thread From: Alexander Aring @ 2020-10-19 19:54 UTC (permalink / raw) To: Benjamin Valentin; +Cc: linux-wpan - ML, koen 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: iwpan with LLSEC - attribute type 1 has an invalid length 2020-10-19 19:54 ` Alexander Aring @ 2020-10-19 20:13 ` Benjamin Valentin 0 siblings, 0 replies; 5+ messages in thread From: Benjamin Valentin @ 2020-10-19 20:13 UTC (permalink / raw) Cc: linux-wpan - ML, koen 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-19 20:13 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-18 15:09 iwpan with LLSEC - attribute type 1 has an invalid length Benjamin Valentin 2020-10-18 23:20 ` Alexander Aring 2020-10-19 6:07 ` Benjamin Valentin 2020-10-19 19:54 ` Alexander Aring 2020-10-19 20:13 ` Benjamin Valentin
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).