Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using NervesKey, device identifier becomes manufacturer_sn even if boardid.config specifies otherwise #56

Closed
psteininger opened this issue Dec 7, 2020 · 4 comments

Comments

@psteininger
Copy link

It appears that as soon as NervesKey is successfully configured, the identifier for the device becomes the manufacturer_sn provisioned into the board, even though /etc/boardid.config specifies otherwise:

iex(10)> cat "/etc/boardid.config"
# boardid.config

# Please consider using an ATECCx08 or NervesKey rather than storing serial
# numbers in U-Boot environment blocks. Override this file in your project's
# rootfs_overlay directory and uncomment the following line if you go this
# route:
# -b nerves_key -f /dev/i2c-1

# Read the serial number from the U-boot environment block. The variable
# "nerves_serial_number" is the desired variable to use. "serial_number" is
# checked as a backup.
-b uboot_env -u nerves_serial_number
-b uboot_env -u serial_number

# Last resort: use 4 digits of the RPi's unique ID as the serial number
-b rpi -n 4

There seems to be no way to override this behavior. When I remove the nerves_key dependency, the device reports to have a different identifier.

So either we need to update the documentation and specify that manufacturer_sn will be the identifier or we need code that uses boardid.config

@mobileoverlord
Copy link
Contributor

If you are using NervesKey, you can provide your own boardid.config file in your rootfs_overlay with the section for using nerves_key uncommented.

# Please consider using an ATECCx08 or NervesKey rather than storing serial
# numbers in U-Boot environment blocks. Override this file in your project's
# rootfs_overlay directory and uncomment the following line if you go this
# route:
-b nerves_key -f /dev/i2c-1

Where i2c-1 is the bus name where your nerves_key is located.

@fhunleth
Copy link
Contributor

fhunleth commented Dec 7, 2020

I'm not sure if this is obvious, but once you program the ATECCx08A with a manufacturer_sn, that manufacturer_sn is effectively the device's ID from then on out. The reason is that the manufacturer_sn is in the X.509 certificates that are presented to NervesHub, AWS IoT, etc., and since the certificates are cryptographically signed, you can't change it.

Fwiw, here's my boardid.config:

-b nerves_key -f /dev/i2c-1
-b force -f unprovisioned

@psteininger
Copy link
Author

psteininger commented Dec 7, 2020

@mobileoverlord and @fhunleth thanks for responding. The issue here is that I did not expect nerves_hub_link and nerves_keys to work this way out of the box, because what the documentation suggests is that I need to explicitly configure boardid.config in order to use manufacturer_sn as the identifier, which is not the case.

I understand the rationale behind using manufacturer_sn provisioned on the chip and in the certificate based on @fhunleth's comment. The only downside I see is in the web UI on the list of devices. Having even one item with a cryptic identifier is confusing. This can be solve by improving the UI. I have a couple of ideas and I am happy to submit a PR once I get set up with local environment.

I think the best way forward regarding this issue is to update the documentation and maybe give the different setup options more isolated clarity, as in "these are the 3 setups, pick you path and follow". I will take a stab at updating the docs first and submit a PR.

@psteininger
Copy link
Author

@fhunleth @mobileoverlord I opened up an issue in the nerves-hub/documentation to track the changes for the docs. I will create a PR when I have something decent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants