HIP19: Approval Process For Third-Party Manufacturers

[jamiew]

Authors: @jamiew (jamiedubs), @georgica, @philltran
Initial PR: #86
Start Date: 2020-11-14
Category: Governance (Meta)

Rendered view:
https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md

Summary:

This proposal seeks to lay out requirements for new third-party manufacturers to be approved by the community, and a process by which onboarding keys can be issued by Helium, Inc to those manufacturers.

[shawaj]

Would be very interested in this for use with balenaCloud and Pi Supply / Nebra gateways 👍

[PaulVMo]

I would really like to see more detail in the HIP on what minimum security requirements will be. I don't think this goes far enough and could lead to more, easily exploitable hotspots similar to RAK. Put another way, this does not seem to preclude RAKspots which are currently leading to significant growth in gaming. The HIP talks about favoring security but does not actually spell out any requirements as to what that means (e.g., hardware keys, non-removable storage, secure firmware).

Down the line if and when there is better anti-gaming and/or different classes of gateways (e.g., "light gateways") this may be an acceptable set of requirements. However, those things do not current exist. At this point, I would prefer not to approve more manufacturers that are as insecure as the current generation of hotspots. To me, this does not provide enough clarity on those requirement and thus leaves the door open to more untrustworthy hotspots which are detrimental to the growth of the Helium network.

[georgica]

The way i see it is:

1. lock down the firmware as much as you can
2. Better to encrypt the key folder on the SD card (you can't really copy encrypted folders)
3. Make sure the decryption key/passphrase is hard to obtain
4. firmware should authenticate hardware to ensure it is running on specific hardware.

[philltran]

I agree with @georgica. We should only require due diligence in securing the hardware.

[georgica]

to add to the above:

• Root user should not be accessible
• Malicious devices cannot be plugged in, USB or otherwise
• If you do allow HID devices make sure user/root password cannot be reset easily.
  (One example being using a flavor of linux booting into single user mode and resetting root password)

[jamiew]

Baking some of the requirements mentioned here into the HIP in #90 (WIP)

[shawaj]

@ryanteck and I were discussing this earlier today.

Given that an ATECC608B is only $0.65 ish and is presumably already supported in software from the original product would it not, in the long term at least, be a reasonable suggestion to include this secure element chip in all designs?

For the price of a chocolate bar it adds a lot. Even a TPM would be only around $2 but for the application is potentially overkill and would require building support for which would not be trivial.

In theory you could retroactively add these to existing devices although perhaps it would be a logistical nightmare to do so.

The other suggestions by @georgica and others are also definitely worth doing though.

[georgica]

@shawaj Problem with ATECC608B is that it provides "fake" security as you can still "game" with it easily, so not much difference.

[shawaj]

@georgica do you mean that you could move it from one system to another? Or that you could fake the radio traffic?

I thought the idea behind using the atecc on the original design was just to store the swarm keys?

[georgica]

@shawaj i mean you could convert it into a DIY quite easy and turn attach it to virtual cluster

[ryanteck]

@georgica Just looking over some of the points that you're talking about above.

Better to encrypt the key folder on the SD card (you can't really copy encrypted folders) I'm fairly sure this is incorrect, encrypted folders can be easily copied in their encrypted state.

Make sure the decryption key/passphrase is hard to obtain But wouldn't the decryption passphrase have to be known by the owner to essentially unlock the folder for the miner to operate?

Firmware should authenticate hardware to ensure it is running on specific hardware. How extreme do you mean by specific hardware? Do you mean the hardware combination (So likely in our case it'd be RPi Compute Module, Ethernet chip is a certain brand) or per device combination (So then checking the S/erial number and mac address is the same).

Malicious devices cannot be plugged in, USB or otherwise Quite literally to what extent, our current gateway has a USB port to be able let the user connect a USB Wi-Fi adaptor for connectivity. However while we could remove that a malicious party could potentially solder onto the pins where the port was, and even if we remove it entirely they could just solder directly onto the pins of the modules directly.

Overall some of the suggestions of requirements almost would require a purpose built gateway where the device is encased in resin and possibly contain chips that would self destruct if they sense light and other methods. However the issue with this and some of the requests above is that these would make the device irreparable and possibly e-waste if they went faulty which wouldn't be environmentally friendly and potentially against newer regulations coming into force encouraging repair ability.

Essentially the above would also be a concern as if the software recommendation changes to using the gateway-rs method (https://github.com/helium/gateway-rs) then the owner would want to be able to convert their gateway to use this and some of the above security wishes would prevent the owner from doing this. So unless there was guarantees that the software that would run for now is supported for X years then it would be an issue.

Secondly it seems almost as if you want an "unhackable" box, but also from the owner themselves which would require much more significant time and investment to do as originally when I was reading I thought it was securing against the rare chance of somebody having physical access to the miner that's not the owner.

The thing with it being "unhackable" is that nothing really is unhackable and it's just a matter of time before it can be hacked, a favourite example of mine to refer to is games consoles as many of these attempt to be unhackable but always eventually get hacked. (The most notable being the PS3).

Third, essentially I would question why new gateways have to be so much more secure when there's essentially already over 13,000 gateways which are now being deemed unsecure? Small things such as adding a chip to secure keys is quite easy to do but some of the above proposed requests are talking about specific hardware to be designed for new miners.