From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Trent Piepho <trent.piepho@igorinstitute.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH 1/5] common: machine_id: support /chosen/barebox, machine-id-path override
Date: Wed, 15 Sep 2021 12:55:25 +0200 [thread overview]
Message-ID: <68fd60fe-cc3c-c015-b6dd-48e9d93e179a@pengutronix.de> (raw)
In-Reply-To: <CAMHeXxMyCUfcoriS--bLCeqAkOWjG_0nRZmh_nREfJGKbgfbXQ@mail.gmail.com>
Hi,
On 30.06.21 22:13, Trent Piepho wrote:
> On Wed, Jun 30, 2021 at 3:27 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> On 28.06.21 21:50, Trent Piepho wrote:
>>> On Sun, Jun 27, 2021 at 11:41 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>
>>> On a board I did before Barebox had machine-id support, we used two
>>> sources of serial number to generate the machine id. One was the imx7
>>> unique id and the other was a serial number in a i2c security chip.
>>>
>>> The imx id is predictable, so even hashed one can predict the
>>> machine-id exactly.
>>
>> We happen to have stm32mp1 twins with consecutive MAC addresses.
>> I compared their serial numbers and while they clearly didn't start
>> at zero, all bytes were the same, except for two nibbles that were
>> one apart. So yes, if the i.MX UID follows a similar scheme, you
>> may be able to guess the machine-id of other devices in the same
>> batch if you already have the machine-id of one of them.
>>
>>> We didn't really like that, so we combined two
>> sources.
>>
>> Is your issue one of privacy or security?
>
> Both. We didn't like it being guessable for fishing attempts.
> Security was more on the cloud side, having the machine-ids guessable
> was not a good idea. Yes, machine id is not to be used for access
> control, it is not a password. But one does not want an attacker to
> have a list of every valid username even if the password is still
> secret.
Fair enough.
>> My understanding is that the machine id is not disclosed as matter
>> of privacy, so it's harder to track a device by manner of the unique
>> IDs embedded in its outgoing communication.
>>
>>> It seems like there is no way to do that with this design?
>>
>> You can write a driver that collects multiple sources and offers
>> a single NVMEM cell for consumption.
>
> I suppose this could be done, but it certainly seems complex. I think
> one would need:
> Write code in board init function to get imx id, data from additional
> chip, put in global buffer.
> Add barebox specific device tree node, compatible =
> "mycompany,myboard-unique-data"
> Write small nvmem driver that exports the global buffer as nvmem device.
>
> I suppose the latter driver could be common if needing to create nvmem
> devices to hold data becomes commonly needed.
Yes. I think using a nvmem cell as an interface here is a good
trade off. It works for most and it's straight forward to extend
in future.
>> A user would expect a machine-id-path property to point at all info
>> used for determining the machine-id, not some of them.
>
> One could have a special name in the path, "internal" or something,
> that indicates data that code in Barebox will create.
>
>>> Or /chosen/barebox,machine-id could be a _list_ of paths, to be used
>>> in order. But that requires a nvmem driver for each source.
>>
>> That's fine by me and could be added in future. I can add a property
>> size check, so we leave open this avenue without breaking users.
>>
>> The root device tree node already has a device in barebox, so board
>> could use that to offer custom info.
>
> If a property was created that simply contained the data directly,
> I.e. of_set_property(root, "extra-id-data", data, 8),
> would there be a way for barebox,machine-id to point to it?
Nope. But who would fix up such a property? If you get data
from a previous boot stage, you could put a nvmem-romem on top.
>>> The security chip wouldn't have worked for a nvmem driver.
>>
>> Why not? Check out nvmem-rmem with just exports a memory region
>> as read-only nvmem device. You can do likewise. There are also
>> helpers to get a nvmem device out of a (i2c) regmap.
>
> To get the id, one needs to construct a command and then parse the
> response format to extract the data. It is not as simple as some
> register contents.
>
>>> I'll also point out that just hashing the data is not a good idea to
>>> make a UUID. Anyone who hashes the imx unique id will get the exact
>>> same UUID. So it is not very universally unique!
>>
>> The i.MX unique ID is unique across i.MX processors. Yes, it would
>> collide with an attacker that guess the ID, but is that really
>> a threat? Anyhow, there are boards using it like this already in the
>
> It comes up if some other software on the same board creates a UUID by
> hashing the imx id. Anything that does this will get the same UUID.
> Suppose the board is not imx and has no unique built-in id other than
> a MAC address. Anyone who hashes the mac address gets the same UUID
> and they collide. It is not a security issue exactly, but a failure
> of the universally unique property of the UUID.
The alternative is not to have a default at all. So we provide
a default that works for most and if you need more than that,
you can extend it.
>> field. So this won't change, but for the new binding introduced here,
>> I can address issues that are raised.
>
>>> This is already a known issue when generating UUIDs that are not
>>> purely random. See RFC4122 §4.3 for generating UUIDs in a namespace.
>
>> Users can do that, barebox will hashh it to get the format the OS expects.
>> It's probably a good idea to hint at RFC4122 for users interested in
>> generating their own material for use with the machine-id.
>
> I don't know what you mean by the format the OS expects. The output
> of the §4.3 algorithm is a standard UUID. It works perfectly well to
> pass it as a machine id and then systemd will use it as it is. Since
> 2011, when systemd generates a machine id it follows RFC4422 §4.4 for
> random UUIDs.
systemd expects a 32 character lower case ID that's not all zeroes.
Newer systemd versions apparently generate machine IDs that qualify
as v4 UUIDs, but barebox doesn't and I just want to streamline the
existing implementation here. I don't intend to make the machine-id
UUID-compatible (although I don't mind extending the functionality
into that direction).
Cheers,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2021-09-15 10:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 6:40 Ahmad Fatoum
2021-06-28 6:40 ` [PATCH 2/5] ARM: stm32mp: migrate to barebox,machine-id-path Ahmad Fatoum
2021-06-28 6:40 ` [PATCH 3/5] common: machine_id: deprecate machine_id_set_hashable Ahmad Fatoum
2021-06-28 9:50 ` Bastian Krause
2021-06-28 10:12 ` Ahmad Fatoum
2021-06-28 6:40 ` [PATCH 4/5] sandbox: dts: populate $global.machine_id Ahmad Fatoum
2021-06-28 6:40 ` [PATCH 5/5] ARM: dts: stm32mp: retire barebox, provide-mac-address in favor of NVMEM Ahmad Fatoum
2021-06-28 9:28 ` [PATCH 1/5] common: machine_id: support /chosen/barebox,machine-id-path override Ahmad Fatoum
2021-06-28 9:35 ` [PATCH 1/5] common: machine_id: support /chosen/barebox, machine-id-path override Bastian Krause
2021-06-28 10:11 ` Ahmad Fatoum
2021-06-28 20:20 ` Sascha Hauer
[not found] ` <CAMHeXxOT__KBUKG6GkNAEkqz4tMBBzuZ7OgnKa0_OX5hz-JEig@mail.gmail.com>
2021-06-30 10:27 ` Ahmad Fatoum
2021-06-30 20:13 ` Trent Piepho
2021-09-15 10:55 ` Ahmad Fatoum [this message]
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=68fd60fe-cc3c-c015-b6dd-48e9d93e179a@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=trent.piepho@igorinstitute.com \
/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