HIP22: DIY Concentrators

[jamiew]

Author(s): @georgica, @lthiery, @Carniverous19 (para1)
Initial PR: #91
Start Date: 2020-11-16
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0022-diy-concentrators.md

Summary:

This proposal side-steps the inherent lack of trust in gateways by creating a special LoRa concentrator module that we can trust. Whereas today, RSSI, SNR and GPS timestamps cannot be inherently trusted, reports from these "Anchor Gateways" will be a root of trust for physical information on the network.

[lthiery]

@georgica I can work on specifying more clearly in the HIP, but I think that the "Golden Gateway" from a hardware specification boils down to a concentrator card that is RAK2287/RAK2247 compatible at its core. Do you agree with that?

The reason I think its important is that it may allow for eventual retrofits for operators who have any of the currently on-chain gateways.

[georgica]

@lthiery I agree with that it has to be integrated in the concentrator it's self. Like i stated in the HIP some modifications need to be done in order to ensure that it is un-temperable.
Since RAK2287/RAK2247 are clones of Semtech's reference design with few additions, I have already started work on this board.

[lthiery]

@georgica great, I thought we were aligned on that but I just wanted to make we were before trying to do a PR to the HIP :)

[ctchadwick]

I am a new comer to Helium, but I really see the promise of the technology. While it is good to expand the growth and deployment of the network, I do see the transient and speculative aspects of those acquiring hotspots simply for the mining rewards without any regard for the integrity of the network. I'm a property owner with a longer horizon with regard to infrastructure, so I'd like to participate in the Anchor beacon part of the network. Are there more details on this, perhaps some sort of registration/verification or list to get on for becoming an Anchor? I apologize if this is not the place to address this.

[lthiery]

@ctchadwick Welcome to the community!

It's great to hear that the concept of this Helium Improvement Proposal (HIP) makes sense to you. However, as its name implies, the idea here is merely a proposal so far. At this phase, we are debating the proposal and trying to figure out if its policy we wish to adopt. Or if it may be improved from its current state to become policy we wish to adopt.

Therefore, there is no registration/verification; in fact, the methods proposed herein are attempts to provide trust without registration/verification but instead with a secure hardware and firmware provisioning process.

That being said, buy-in from users like you who express that they wish to deploy such anchors to help the network is helpful feedback!

[ctchadwick]

@lthiery Thanks for the welcome.

[eek]

Hi everyone! I'm new here as well, just chatted a bit with angrybear & wolfenhawke on Discord, I like what Helium is building, but I also dislike the fact that there can only be pre-approved 3rd party hardware devices and no DIY raspberry PIs with LoRaWAN hats or similar stuff. Since DIY would have helped accelerate like crazy the 27k router deployments, which are now to millions...

And was curious if there couldn't also be custom keys on DIY hardware that could only get rewards if they're nearby pre-approved routers in the vicinity that can verify and validate their requests... The DIY hardware miners can also share a bit of the reward with the "official" routers that validate them.

And I was pointed here, which makes sense, if there are Anchor Gateways that are trusted, they can validate untrusted DIY nearby hardware as well, hence being able to expand the network quite fast 🤔

---- later-edit:

I see there's also the work in progress of "Light Hotspots" that might allow any DIY hardware to join? will enable just about any LoRaWAN gateway to join the Helium Network, provide coverage, and mine HNT.

[lthiery]

Welcome, @eek !

DIY hardware that could only get rewards if they're nearby pre-approved routers in the vicinity that can verify and validate their requests

The fundamental problem here is that one legitimate hotspot could like about others, thus one could spin up hundreds of virtual gateways around a single real one. The point of this HIP is to greatly increase the difficulty in doing so, making it so that spoofing would have to occur at the hardware/RF layer.

if there are Anchor Gateways that are trusted, they can validate untrusted DIY nearby hardware as well

Unfortunately, I'm personally not 100% convinced that anchor gateways as described herein is enough to enable this. I do believe this to be a step in the right direction, but there are still RF level attack vectors allowing one to virtualize many other hotspots.

That being said, I am reworking this HIP currently to make the case that as long as a DIY (or non-HIP19 approved gateway) includes the "secure concentrator" outlined herein, then it could be allowed on the network. I'll be sure to ping this issue when I'm done with that.

[timcooijmans]

While I think it's a good idea to allow DIY-concentrators I object to the claim that:

these are provably more honest witnesses

Running a normal "hotspot" could be as-secure as in fact it uses a very comparable architecture.

If you replace your "secure middleman" by a "secure processor" and replace the "PCIe goldfinger" by "internet" you have the current HIP19-approved setup. It's exactly the same security-architecture, but with a different components.

[lthiery]

Running a normal "hotspot" could be as-secure as in fact it uses a very comparable architecture.

Sure, it could be. But the fact of the matter is that the security requirements of HIP22 exceed those of HIP19.

[lthiery]

@eek and anyone else possible following, I've updated the HIP in #160 to describe the intent to enable DIY

[timcooijmans]

Running a normal "hotspot" could be as-secure as in fact it uses a very comparable architecture.

Sure, it could be. But the fact of the matter is that the security requirements of HIP22 exceed those of HIP19.

What requirements? There's a specification of a single solution, no generic set of requirements like you would see in FIPS 140-2/3 or CC EAL.

And that's exactly my point;
I think this is a great idea to get the DIY community back on board, but if you want to tinker with rewards because it could be more secure, (but I think we established it's not provably more secure because it can be as secure) make these security requirements SMART and put it in another HIP.

[lthiery]

What requirements? There's a specification of a single solution, no generic set of requirements like you would see in FIPS 140-2/3 or CC EAL.

Wow - I never heard of FIP140-2/3 before. Agreed - this does not compare to "a U.S. government computer security standard used to approve cryptographic modules".

When I contrast the security standard, I contrast it to HIP19.

make these security requirements SMART

I'm sorry you think this proposal is DUMB. I have no idea what your actual constructive feedback is here.