HIP22: DIY Concentrators
jamiew opened this issue · comments
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.
@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.
@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.
@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 :)
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.
@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!
@lthiery Thanks for the welcome.
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.
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.
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.
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.
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.
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.
@timcooijmans I apologize for not realizing that you meant SMART as in the acronym and not an emphasis. I thought the tone was uncharacteristic of you and then I realized I should google the acronym. Now that I see the results, I know I've seen it around before.
Regarding you actual point of "Specific, Measurable, Achievable, Realistic, and Timely", I still take issue. There's a literal example implementation of the concept and a vendor implementing it... so I believe we cover S, A, R and T.
No worries!
Yes I have to deal with these standards every day, that's also why I was triggered.
What I was trying to say is that I would like to see a list of requirements that are required to be an anchor (I use this term for a more trustworthy hotspot). These requirements shouldn't assume a solution but solely list the generic requirements. We don't want to discuss every design that tries to do something like this, but have a set of requirements that can be to validate a design.
At the moment it's very focused on putting a certain "trusted" processor on the concentrator module PCB. I understand this from the DIY perspective but from the anchor perspective this is opinionated in terms of solution. I mean the way I see it you have described a light-hotspot-on-concentrator-module setup and it's 100% the same as a light-hotspot with three new requirements that may already be present on existing hardware:
- It has a non-removable connection between the processor and SX130x. There are other ways to achieve this besides placing it on the same PCB
- It has a way of running only verified code. Again there are multiple solutions for this
- It tries to protect against simulating the SX130x by using buried traces, but since SX130x is not a BGA you can still tinker quite easy because all the pins are available without desoldering on the outside of the IC. So in my opinion in this case buried traces add no security.
So great solution for DIY. But I would leave it at this. No additional compensation, just equal to a HIP19 hotspot.
Also note that this attributes to gateway shortages because there are manufacturers now (including myself) and having this change on the horizon that will differentiate in earnings is quite a thing. The market is very ROI/earnings focused. For example we reduced our production runs for the full hotspot because there will be the cheaper light-hotspot that will earn the same and nobody wants the full hotspots once they are live. Now this proposal comes along and we would have the same issue again, nobody wants a light-hotspot if a anchor hotspot that has the same price earns more. It makes it impossible to meet market demand because you can't plan ahead.
@timcooijmans Thanks for expanding on your point - I understand your feedback much better.
First off, I agree with your point that we should essentialize the HIP22 characteristics into a spec and perhaps only after that, explain how Syncrobit's proposal fits the spec.
I do believe alternate designs should be submitted and approved, but what I think is powerful about Syncrobits implementation is that its modular enough to be introduced into almost every gateway already on the market. Not to mention, it's already been implemented and the hardware is currently being tested. Furthermore, it is my understanding from @georgica that he would be okay open-sourcing or transferring the IP to DeWi, allowing for anyone to manufacture their own.
I would consider punting on the compensation angle so that we can at least get the gears turning on this module to enable DIY.
However, I do fundamentally believe that its better for the network if we switch to this over time. It's hard to say where we are at with gaming at this point; it appears to have gotten much better over the last few months. Alternately, perhaps the gamers are just more subtle. It's really hard to say.
What I can say is that I'd be more confident if we started standardizing on modules with these characteristics and with trust originating in the SX130x firmware loaded by a trusted DeWi agent. In addition, while I do not believe that any manufacturers in particular are bad actors, our current HIP19 configuration does leave us vulnerable to attacks from manufacturers. Not to mention, it is my opinion that setting up a controlled provisioning flow will ultimately be less overhead for DeWi than managing the increasing amount of vendors we have under HIP19.
I understand the inability to forecast, but if we agree this is better for the network, how do we migrate existing vendors to this increased security model in a reasonable way?
Hi folks, there are ways that @timcooijmans items can be done in hardware only. I have worked on IOT systems and will describe a system often used for trusted gateways. This info is not proprietary manufacturing secret.
The process involves getting a manufacturer on board. Generally a 'module manufacturer' unless the silicon manufacturer already has module capabilities or the processor has a built-in trusted environment.
The module has a secure chip (SE) or trusted environment in the CPU along with a PUF (physical inclonable function). Alternately, a serialized code is programmed into each SE. A central authority would manage this serial list (i.e. Helium) and dole out the codes to a manufacturer (the module manufacturer). When authenticating to the system a first boot step would be to validate with Helium that the hardware is on the list.
The module manufacturer is incentivized because all modules are bought from them (one or more manufacturers). This is similar to all LoRa radios coming from SemTech so it's not too much of a stretch or centralization.
DIY are supported because they could also purchase these modules to plug into whatever platform the form factor will support (RPI, Arduino, whatever).
If a single module gets compromised you will know because you will get more than one boot time request for it - at that point you could quarantine ONLY that code, so you have mitigated spread, though you will disable that single code even if it is a legitimate unit that was hacked. A good trade-off.
So yes I propose two HIPs:
HIP X+1:
Define the generic requirements for a trusted concentrator design (and don't forget processes around it) and a vetting process of such proposals (there could/should be multiple) by DeWi. I would encourage to allow only open-source hardware/software designs because it will benefit the system as a whole and the designs should not rely on security by obscurity anyway.
Concentrators using this design are allowed to be used to build a DIY concentrator directly after approval (but earn the same).
I'm still wrapping my head around the secure-provisioning part however, running all concentrators through a facility contracted by DeWi doesn't seem very scalable solution, it would cause challenges with assembly, supply-chains and taxes to name a few. I think I would propose to keep it at the (trusted) manufacturers, because I cannot think of a scalable, controllable, usable alternative. (But yes that means placing trust in manufacturers).
HIP X+2:
Compensating miners using a trusted concentrator more. I'm against this change and I don't think it's necessary. But if it would be decided to do so I would propose a 5-6 month lead time after the first open-source hardware design has been implemented to allow all manufacturers to switch over (as this requires FCC/CE/xxx recertification for all gateways on the market wanting to switch for sure).
I'll plan on splitting the proposal for now so we can at least make easy progress on the non-contentious elements.
I would propose to keep it at the (trusted) manufacturers, because I cannot think of a scalable, controllable, usable alternative. (But yes that means placing trust in manufacturers).
I could see this being viable, provided the manufacturers had ran at least one validator. Perhaps the quantity they can produce of these would relate to number of validators 🤷
Comments:
For HIP X+1: we still need a centralized authority (Helium?) to authenticate during the provisioning. The reasons are:
- manufacturers don't want to get into this SAAS, they will already be required to add a special serialization step (which they will do if convinced of volume)
- having the central authority + manufacturer prevents a manufacturing employee of spoiling the seeds
NOTE: this secure mechanism doesn't allow for full open source hardware, but mostly open source with the purchase of a special compute module. As noted earlier, this is probably ok, as the LoRa radio is also not open source but proprietary.
For HIP X+2: a little nit, but if the RF path is not modified in the gateway and a pre-certified module is used for the RF (both should apply to Helium hotspots) then the manufacturers can get a variant without going through full FCC cert. Most may have gotten family cert anyway. This is how linksys, netgear, etc. come out with variants very quickly of their Wi-Fi routers (if you look at the FCC cert for the product it is for a family and not a specific model number).
Manufacturers have to program the IC anyway, so generating a private key and signing it in a certificate with a manufacturer specific private key is a small effort. I propose a public-key infrastructure with revocable per manufacturer keys that are stored in HSMs at the manufacturer to protect against disclosure.
Regarding FCC/CE testing: The plan was to fit it on the miniPCIe of the concentrator itself. I assumed this requires significant modifications to the concentrator PCB containing the RF-path.
The HSM route is problematic if the manufacturer doesn't already have. They are expensive to be done properly. But all else, or a simplified path for the manufacturer is do-able.
Agreed, that kind of PCB change is likely to be significant.
Generic FIPS 140-2 Level 3 (=very secure) HSMs are 10-30k USD, so I think this is acceptable. Yubico is even seeking FIPS 140-2 Level 3 certification for their 650 USD HSM 2.
Manufacturers have to program the IC anyway, so generating a private key and signing it in a certificate with a manufacturer specific private key is a small effort. I propose a public-key infrastructure with revocable per manufacturer keys that are stored in HSMs at the manufacturer to protect against disclosure.
I like this proposal a lot, but perhaps it could be a standalone HIP for which could apply to not onyl HIP22 but perhaps HIP19. In my opinion, HIP22 already accomplishes enough on its own:
- proposes a hardware security configuration that improves upon the requirements of HIP19
- enables the development and deployment of hobbyist scale (DIY) gateways while simultaneously improving security on the network
Has there been any considerations about consulting a Semtech field application engineer with the issue/challenge? This could be a great way to get some useful input. I happen to know 1 or 2 that I have been consulting in other applications.
Has there been any considerations about consulting a Semtech field application engineer with the issue/challenge? This could be a great way to get some useful input. I happen to know 1 or 2 that I have been consulting in other applications.
@maziarzamani It would be great to get similar properties directly from the Semtech IC itself. In my opinion, that would fall under the alternate implementation of the same "DIY concentrator" definition specified herein.
It might take more time to get that from Semtech, however, which is why I would encourage review of Syncrob.it's existing implementation. Amongst other things, I believe we can use Sycnrob.it's implementation with open firmware as a way to harden the enhanced "host processor <-> concentrator" interface, as I believe it would be difficult to expect an open firmware implementation from Semtech. Handing off a hardened spec, on the other hand, seems much more viable.
Has there been any considerations about consulting a Semtech field application engineer with the issue/challenge? This could be a great way to get some useful input. I happen to know 1 or 2 that I have been consulting in other applications.
@maziarzamani It would be great to get similar properties directly from the Semtech IC itself. In my opinion, that would fall under the alternate implementation of the same "DIY concentrator" definition specified herein.
It might take more time to get that from Semtech, however, which is why I would encourage review of Syncrob.it's existing implementation. Amongst other things, I believe we can use Sycnrob.it's implementation with open firmware as a way to harden the enhanced "host processor <-> concentrator" interface, as I believe it would be difficult to expect an open firmware implementation from Semtech. Handing off a hardened spec, on the other hand, seems much more viable.
Makes a lot of sense. Is there any mechanical tamper protection suggested anywhere? I see a lot of focus on signals, but creating a mechanical case combined in the heatsink could add an extra layer of protection, however won't do much against tampering the RF frontend via coax.
I see a lot of focus on signals, but creating a mechanical case combined in the heatsink could add an extra layer of protection, however won't do much against tampering the RF frontend via coax.
I've left mechanical prevention rather handwavy at the moment, more or less intentionally. Fundamentally, I think this HIP does a good job of enhancing security vs HIP19 while also enabling custom gateway builds (DIY) to be derived from this one component. I'd be afraid that additional specifications would lead to further debate, while also reducing the flexibility of this component for DIY builds. But if you have specific suggestions, I'd be all ears.
I could very well see a more locked down device being derivative of these concentrators. It could be used in mobile auditing efforts for example. Then perhaps impacting rewards with these types devices would be warranted.
Let's not get too crazy on physical protection, it will drive-up costs and will offer little additional security benefits.
@lthiery Could you clarify the piece around provisioning and firmware a bit?
- Is the only way to "produce" DIY concentrators to provide firmware to DeWi and stake 5 validators? It's written like provisioning concentrators as a manufacturer is optional, but what are the alternatives?
- Is DeWi actually capable of reviewing such firmware (and hardware) at the moment? Should we wait for them before approving this HIP?
I don't get the staking requirement. What does it solve? It requires manufacturers to put possibly more than 1 M USD on stake before they can sell anything. That's a huge investment and certainly for DIY that will drive up the costs of DIY-concentrators.
I think an unanswered question should be added in terms of on-boarding-keys and key distribution process in general.
@timcooijmans thanks again for the great feedback. I've expanded upon provisioning and onboarding it in the pending PR.
I don't get the staking requirement. What does it solve?
The point of the staking requirement is to secure the provisioning step which is the where trust must begin if we are to afford greater trust in these DIY concentrators. In other words, the entity responsible for loading the firmware will have a substantial stake in the network (5 validators) and have a vested interest in this operation being accomplished with integrity.
Following your feedback though, I've made it explicit that any third party with such a stake could do this task on behalf of the manufacturer. In my opinion, this provides flexibility to manufacturers who cannot make the investment at that time and allows us to maintain a relatively high threshold of 5 validators.
The number of 5 is relatively arbitrary, but its a quantity that makes me personally feel "this person is significantly invested in the network". 1 validator is not nothing, but in the case of bad actors trying to turn a profit by abusing this process, 1 validator almost feels affordable.
Is DeWi actually capable of reviewing such firmware (and hardware) at the moment? Should we wait for them before approving this HIP?
In my opinion, DeWi would engage a third-party to do the initial audit. Thereafter, I hope that firmware upgrades would be fairly infrequent and minimal enough that they could review changes and deem whether a follow-up audit is necessary.
Long-term, I think migrating HIP19 approvals to this type of system would actually lower the complexity of the oversight required by DeWi, although just to be clear, that is not the subject of this HIP at this time, but instead, a topic that I would encourage the HIP19 Working Group to consider.
Anyway, I'd be interested to hear their feedback on today's call (@jamiew @Scottsigel @chrisabruce).
@lthiery any third party seems fair in terms of staking. However the devil is in the details: Is such third-party allowed to outsource this provisioning process? To what extent should this entity be responsible/in charge/under control? It seems impossible to restrict. But it will give some additional benefit having two parties involved.
So for an audit, there are currently only two "hard" requirements:
- provide a hardware key store, guaranteeing that a key generated within may not be extracted (similar to the ECC608)
- provide secure boot features, guaranteeing that only firmware signed by DeWi may executed (unlike ECC608, which does not execute firmware)
I propose some changes to those requirements (feel free to rephrase) :
- provide a tamper-proof hardware key store, guaranteeing that a key generated within may not be extracted (similar to the ECC608)
- provide secure boot features, guaranteeing that only firmware signed by DeWi may executed (unlike ECC608, which does not execute firmware)
- provide authentication of received packets from the SX130x by using the trusted firmware and tamper-proof hardware. Only actually received packets should receive a valid signature using the key stored.
- provide a tamper-resistant non-removable binding of the secure processor to the SX130x such that simulating the RF-side is only possible by soldering or destruction.
The two requirements added are already implicit in the document I think, but not explicit.
We can have some discussion about the level tamper-resistance required. But I wouldn't go too far, the aim is to produce (light-)gateways and DIY-concentrators at a fair price-point, not to make the most secure solution I think.
@timcooijmans thanks for those suggestions. added them to the doc
What I'm missing currently from the HIP is more requirements/details of the provisioning part. I see three phases:
1: We accept HIP22 concentrators created by HIP19 manufacturers after light hadware/software security review by DeWi (a bit like HIP19 devices). DeWi is not involved in firmware signing/provisioning. This could be the solution for DIY and allows for new non-HIP19 manufacturers using HIP22 concentrators (that's basically just like DIY). I'm ok with this today.
2: The provisioning of HIP22 concentrators is stricter controlled (to avoid manufacturer cheating). DeWi verifies and signs firmware and staker (either manufacturer or 3rd-party) provisions the DeWi public-key irreversible on the secure MCU. In theory this is a nice improvement, but I don't see how this would work in practice. In practice manufacturers will "hire" a staker to hire an assembly company to do the provisioning (possibly even the same company doing PCBA for the manufacturer). Is this acceptable @lthiery?
3: Adjusting rewards for HIP22-based hotspots. As said before, I would only agree to do so after at least 6 months of lead time. If not you will probably bankrupt any manufacturer that already committed to production of non-HIP22 concentrators and is doing refunds of unshipped orders.
I am fairly good with these changes and the scope change from an "anchor gateway" to a "DIY gateway" that is allowed to participate in PoC.
I think more clarity is needed on how the packets coming out of the concentrator are signed. For example its important that all PUSH_DATA rxpk packets are only valid if signed. This would require a decent amount of software changes within blockchain core to know how to verify signatures from secure concentrators. You cant have the MAX32510 just act as a ECC chip and sign whatever json data is forwarded to it. Since the DIY code is very open source it would be easy to throw in additional PUSH_DATA packets created on the RPI to the secure element to sign (ie this isnt a normal concentrator with an ECC chip epoxied on it, its more secure than that).
Ideally (and to ease implementation) an API should be defined for interacting with the secure concentrators and a corresponding customized packet forwarder defined and preferably written to interact with the concentrator and the miner.
We had some discussions about this in the last DeWi call. I expected indeed that changes to the blockchain are required to verify such secure-concentrator signatures. @lthiery said that he thinks it could work within the current blockchain-core setup.
This means that data-processing of RF-packets to ECDSA signatures or ECDH decryptions should happen on the secure-concentrator itself.
This is possibly for another HIP but is there any objection to having a requirement for all HIP19 approved vendors to have open source hardware/software or to use a HIP22 concentrator if they want the rest of their design to be closed?
I don't think "ideally" open source is sufficient personally. The vast majority will entirely ignore that.
Given the semtech reference design is essentially open, I don't see that this would be an issue.
Perhaps if there is an objection to "true" open source, the minimum requirement could be a "non commercial" license. So the source is available to view but not necessarily to use?
Lastly, as well as the validator requirement, I think a minimum of DeWi Operating Member would be a reasonable expectation for a HIP22 concentrator provider.
Yes, we would object to open-sourcing "everything".
We have several hardware and software features that we developed internally with our partners that we are not able (due to NDA's or non-public licenses) to and/or willing (due to competitive reasons) to share publicly.
We are of course willing to share anything to the DeWi or the party executing the reviews under a NDA
For the HIP22 concentrator itself, it's a bit of a different story. I could see that DeWi open-sources a design to aid the grow of the network.
This is absolutely astonishing to see in action. Thanks jamiew for your input on all this, definitely needs a couple lookovers but overall this is IMO is the right direction to be moving towards.
I'm not a technical person, I'm a financial guy, while I can basically follow all the tech stuff I don't see any consideration to ways that ownership of a DIY unit could be restricted to say 1 unit per wallet. Perhaps some form of KYC could be considered to solve the spoofing issue & verify the location. Just a thought, if this kind of thing can be achieved technically then I'm happy to offer more suggestions.
Yes, we would object to open-sourcing "everything".
@timcooijmans I'm talking specifically about HIP22 DIY concentrators. I think this should be an absolute requirement for both the hardware and firmware of any HIP22 DIY concentrator.
The software and hardware side beyond that - sure keep it private if you want - but it seems to me to be essential that the DIY concentrators are openly available for peer review from any parties. This also is in keeping with the spirit of the Helium Network and DeWi in general IMO.
Yes, we would object to open-sourcing "everything".
@timcooijmans I'm talking specifically about HIP22 DIY concentrators. I think this should be an absolute requirement for both the hardware and firmware of any HIP22 DIY concentrator.
The software and hardware side beyond that - sure keep it private if you want - but it seems to me to be essential that the DIY concentrators are openly available for peer review from any parties. This also is in keeping with the spirit of the Helium Network and DeWi in general IMO.
I understand that, and support it, but it also means that all security-ICs (like MAX32510) are out of the question as they have a SDK that is under NDA and you cannot open-source code without violating the NDA.
And as a result the security requirements in this HIP22 need to be lowered (a bit).
I have a DIY gateway and I'm using it to mornitor my CO2 data. Just want to make sure the encryption of RSSI, SNR, GPS mentioned here is only for Gateway beacons to prevent cheating, so data from my sensors will be transfered AS-IS, right? Helium Network is a public network, I think it shouldn't prevent people using their data, like a private network.
@oosui that's correct, this would have no impact on folks running DIY gateways/packet forwarders like yourself. This is strictly for devices that want to join the blockchain and earn HNT rewards
@oosui that's correct, this would have no impact on folks running DIY gateways/packet forwarders like yourself. This is strictly for devices that want to join the blockchain and earn HNT rewards
👍 Thanks! Will all the RF data be encrypted when using the new concentrator? Or only the PoC RF data will be encrypted? Is it possible to allow my gateway to mine HNT if I use the special LoRa concentrator without buying a new one from Makers? Since I'm using the gateway to transfer sensor data to my local server using pkt log, if all RF data are encrypted, I'll be not able to use my current solutions anymore.
While this should solve the issue of allowing DIY builds once again, it appears as though the problem of gamers who spoof location and attenuate RF through physical means (DIY faraday cage, or external RF module) is still an issue.
I realize that this is probably out of scope for this HIP now, but I thought it was worth mentioning anyway since it appears that one of the problem were solving for previously with anchor gateways (preventing gaming) has been dropped to some degree.
There is a lot of great pro Bono work going on in the #mappers channel to validate signal coverage. I was wondering if there’s a world where this effort could be incentivized monetarily on the network? The rough idea I was thinking was some sort of mobile anchor gateway that folks who are willing to travel with would use to map out actual RF signal and compare that to the onchain data.
I understand that something like this was proposed previously, but I couldn’t find the that HIP. It also seemed apparent that the biggest issue with this mobile gateway idea is that GPS is relatively easy to manipulate. However, there are modules like AIM+ that are able to filter out GPS signal tampering quite well, and I would be curious to know how well this could be implemented to be tamper proof.
As a side note, I believe there are many motorcyclists that would be more than happy to place these devices on their bikes to drive around to more remote areas (where they are often driving anyway and where gamers are known to place groupings of their devices) to validate their network, if there were some kind of monetary incentive.
Again please feel free to point me in a better direction for providing this feedback. Thank you!
Hi everyone, I discovered this beautiful project a few days ago and it fascinates me a lot, here in Italy we are still at the beginning but slowly it is filling up with hotspots. Following this thread, did I realize that I can no longer build myself a DIY hotspot? my opinion? In my opinion the producers are making big bucks, selling the hotspots on $ 600 and I think they have a 400% profit margin. And the content is the same as DIY. So in summary, can't I DIY today? Why am I not approved and therefore cannot mine helium? A thousand thanks
I'm not sure the historical record of the DIY alpha exists anywhere in any written form, but the TL;DR is that there were security issues that could lead to large-scale rewards manipulation & fraud ("gaming") and no sufficiently "trustless" solution could be determined, so the program was suspended indefinitely until this issue could be addressed.
In the meantime, HIP-19 has been created as a living document that outlines the evolving onboarding requirements the community has set for anyone looking to manufacture hotspots that can join the network. This gives some basic level of due diligence & scrutiny to developers so as to prevent said rewards gaming.
This HIP (22) seeks to address the security vulnerabilities described and would [in theory] result in the ability to re-open DIY gateway onboarding.
I find all this absolutely absurd. Some do cheats and scams, and what do you do? Remove all diy hotspots instead of looking for how to fix the problem. Not everyone can afford a $ 700 hotspot, but the idea of DIY was also open source. Helium is just business, business for third-party companies that make big money and mostly fulfill orders after 6 months with untraceable payments in crypto, the real scam is them, but no one asks. You have given the whole project to third-party companies to make money and maybe make scams. All this is inconceivable. Sorry for the outburst but all this makes me angry.
Please re-read my comment above, I addressed all of the questions you're asking about. We all understand the frustration, trust me (I personally participated in the DIY alpha -- this did not go over well at the time, either), but revisiting the issue with a clear mind and removing the emotional aspect, the approach makes perfect reasonable sense.
When there is a known vulnerability you don't just continue to leave it open and invite in all of the malicious actors with open arms...you close the vulnerability while you determine a solution.
@jamiew would the recent grant application for an open-source secure concentrator resolve this or at least seriously propel it forward? Not sure if I'm drawing a connection where there isn't one, but as soon as I saw that grant go in it shot straight to the top of the list for me personally, lol.
Curious if there is any recent insight there that is able to be shared publicly via DeWi...?
Great news, I can't wait to be part of it. Thanks a lot to everyone
@cvolkernick @lthiery in light of the grant application you mention, I'd like to nominate this HIP to be marked approved if there are no other issues
Why can the data from today's concentrators not be trusted?
To me, it sounds like a conspiracy that is going on in the community...
Can someone here please explain this further
@lthiery is this still active? How do you feel about this? There is a new PR for 'Secure Concentrators' that you should check out if you have not already.
@lthiery Let me know if we can close or link this HIP to be resolved by HIP 73. If this new HIP does not resolve HIP 22, then let's make sure we are surfacing those issues and looking to integrate your solutions. I likely see Secure/DIY concentrators coming to a vote in the short term and want to make sure we captured your great work.
@vincenzospaghetti I believe Secure Concentrators is a good successor to this HIP. In my opinion, it absorbs some of the foundational ideas from HIP22 while being more detailed and proposing some concrete adjustments to PoC incentives.