I think there is potential but for now I would say that is outside the scope of NervesHub. One of the biggest benefits of certificate auth is when it is combined with a TPM, like NervesKey, which may required physical changes to previously deployed devices. The path to migrate could be very specific depending on the situation and I would generally recommend doing so without your own firmwares and code first.

from nerves_hub_web.

I tend to agree with @jjcarstens here. Right now there is nothing stopping you from using both Certs and Shared Secrets in the same Product, but in the medium term I would expect us to limit a Product from using one auth strategy, which is selected upon creation of the Product.

I think the preferred way of achieving what you have asked is creating a new Product which is set to use Cert auth, and then moving/migrating the devices to the new Product.

These are just thoughts and ideas right now, and your question is great indirect feedback of some of the use cases we should take into account. Thank you!

from nerves_hub_web.

Documenting some offline discussion:

Idea 1 - Access ID + Secret

Sometimes referred to as Pre-shared Identity (PSI) & Pre-shared Key (PSK)

Core idea is that a PSI and PSK are generated for each device which is supposed to be saved to device "securely" (This is up to the user, but typically just manually including in the firmware).

• PSK is not to be transmitted
• PSI is included with the request. NervesHub will use the PSI to lookup the corresponding PSK
• NervesHub calculates the expected salt based on specific headers and then verifies it with the found PSK
• The verified signature will result in the device identifier being decoded

##
# Generated from NervesHub
access_id = "nhd_123456789abcdefghijklmnop"
secret = "I-am-super-secret!-don't-share!!"

key_digest = :sha256
key_iterations = 1000
key_length = 32
signed_at = System.system_time(:second)

headers =
  [
    {"x-nh-key-digest", "NH1-HMAC-#{String.upcase(to_string(key_digest))}"},
    {"x-nh-key-iterations", to_string(key_iterations)},
    {"x-nh-key-length", to_string(key_length)},
    {"x-nh-access-id", access_id},
    {"x-nh-time", to_string(signed_at)}
  ]

headers_salt =
  headers
  # Ensure headers are always sorted
  |> Enum.sort_by(fn {k, _} -> k end)
  |> Enum.map_join("\n", fn {k, v} -> "#{k}=#{v}" end)

salt = """
NH1:device:token:connect

#{headers_salt}
"""

opts = [
  key_digest: key_digest,
  key_length: key_length,
  key_iterations: key_iterations,
  signed_at: signed_at,
  cache: nil # Only when run on device - no need to cache single key and prevents start failures
]

identifier = "poser"

signature = Plug.Crypto.sign(secret, salt, identifier, opts)
[{"x-nh-signature", signature} | headers]

JITP

To allow for convenience, JITP can be supported by using a project access ID and secret. If authenticated with this,
a device access ID and secret would be generated and transmitted to the device. Device would store this and use for all subsequent connections. Transmitting of these values should be signed by the product secret

• Device access ID/secret generated with this will be linked to the product access ID used
• If product secret compromised
  • Disable product ID
  • all linked device credentials should be marked (potentially in penalty box?)
  • On device connect, a new product ID can be transmitted, signed by device credentials
• If device secret compromised
  • Place device in penalty box
  • Issue command to remove current access ID/secret
  • Use product credentials to sign new credentials and send to device
    • Optionally wait for device next connect attempt which would JIT
• If product and device secret compromised
  • Penalty box device
  • Probably need a human to manually fix the device
  • Wish you would've used device certificates with TPMs

from nerves_hub_web.

Perhaps it's outside the scope of this initial version but is there a viable path to switching from PKS to certs?

I can imagine myself having a PoC rollout with 10-50 devices out there using PKS and then, if things work out as intended, to want to migrate these to a proper certificate infrastructure.

from nerves_hub_web.

🎉 This has been merged in 🎉

from nerves_hub_web.