Skip to content

Confusing behavior between NervesKey, TPM and SharedSecret #365

@lawik

Description

@lawik

We just had a report of an issue where someone configured shared secret credentials but left the configurator implicit (which is the usual thing and what the docs indicate). But he had added nerves_key as a dependency. So NervesHubLink went for the NervesKey configurator.

The NervesKey chip was there but not provisioned. It all boiled down to {:error, :execution_error} popping out of the NervesKey. And the Shared Secret was never tried or used.

The order of how the choice of configurator is made seems like it could be better.

  • Log which configurator we are using.
  • Setting the shared_secret key of nerves_hub_link config seems more explicit than having added the nerves_key dep. And maybe that could take precedence. At the very least we can log that it was overridden as a warning.
  • Checking NervesKey.provisioned?/1 would help mitigate attempts to use unprovisioned NervesKeys. It would seem a legit case to prefer the NervesKey if provisioned but fall back to a shared secret in development or something to that effect.

Similar issue would probably occur with an unprovisioned TPM. Haven't tried.

So some fairly simple things can be done to improve this. And then there are some more nuanced decisions as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions