netdev - Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK-6q+g9TxtEpELW1GXchBjPq2HD85CAv06VhDKSHjrQmXPCKA@mail.gmail.com>
Date:   Mon, 23 Jan 2023 08:50:29 -0500
From:   Alexander Aring <aahringo@...hat.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     Alexander Aring <alex.aring@...il.com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        linux-wpan@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        David Girault <david.girault@...vo.com>,
        Romuald Despres <romuald.despres@...vo.com>,
        Frederic Blain <frederic.blain@...vo.com>,
        Nicolas Schodet <nico@...fr.eu.org>,
        Guilhem Imberton <guilhem.imberton@...vo.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH wpan-next 0/2] ieee802154: Beaconing support

Hi,

On Mon, Jan 23, 2023 at 7:49 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> Hi Alexander,
>
> > > btw: what is about security handling... however I would declare this
> > > feature as experimental anyway.
> >
> > I haven't tested the security layer at all yet, would you have a few
> > commands to start with, which I could try using eg. hwsim?
>
> Using the dev_queue_xmit() doest not bypasses the whole stack anymore,
> the beacons got rejected by the llsec layer. I did just hack into it
> just to allow unsecure beacons for now:
>

Stupid questions: do the beacon frames need to be encrypted? Because
we bypass llsec always with those mlme functionality.

btw: there is currently an issue with the llsec hooks. You will not
see the transmit side being encrypted via wireshark (so far I
remember) because the capture is before encryption...

> -       if (hlen < 0 || hdr.fc.type != IEEE802154_FC_TYPE_DATA)
> +       if (hlen < 0 ||
> +           (hdr.fc.type != IEEE802154_FC_TYPE_DATA &&
> +            hdr.fc.type != IEEE802154_FC_TYPE_BEACON))
>                 return -EINVAL;
>
> I believe that would be enough as a first step, at least for merging
> beacons support for now.
>

ok.

> However I'll have to look at the spec about security stuff and
> beaconing to know how to handle this properly if security was required,
> but could you drive me through useful resources were I could quickly
> grasp how all that works? Did you make any presentation of it? Perhaps
> just a blog post or something alike? Or even just a script showing its
> use?
>

I am pretty sure I have something... you need to construct an ACL
there and there exist different methods to do a key lookup. Some are
very easy and some are more difficult to set up. I will look later...
or just do a setup again with hwsim with should work (but again don't
trust wireshark/tcpdump).

Also note: currently there exists practical issues on 802.15.4 stack
(but star topology kind of solves it, so far I understood) to
synchronize security parameters e.g. frame counter.

> While I was looking at linux-wpan.org, I realized we should both
> contribute to it with some examples about security stuff and
> beaconing/scanning?
>

yes, that would be nice... I am pretty sure there are some examples on
the mailinglist archive.

- Alex