DotHacks Application

[dothacks]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants at the time of submission.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[mmagician]

@dothacklab Thanks for the application. In general the idea of bug-bounties is very useful, though I'm pretty sure we can't leverage the already existing code. Are you aware of the bounty functionality in the treasury-pallet? See:
paritytech/substrate#5715 & https://wiki.polkadot.network/docs/en/learn-treasury#bounties-spending
I understand that the scope of this is slightly different:

• only the Polkadot council can approve the bounty
• a single resolver can be awarded from one bounty (unlike possibly multiple white hat hackers in your proposal?)

If I'm not mistaken, the first point should be resolvable by including the treasury pallet in your parachain, which has its own council. This should work in a manner similar to that outlined in your proposal.
The second point is a bit more tricky under the current state of the treasury module - it would either require creating multiple bounties or by allowing the curator to choose only one best solution.

A possible extension to the module - partial bounty payout to multiple addresses - could solve the second problem, if indeed it is that grave. I would rather argue it is not a major problem (as you can always launch a second bounty after receiving a first successful report).It turns out that there's already a bounty for developing a "sub-bounty" feature which might be useful for you: https://kusama.polkassembly.io/bounty/2. It actually would allow for multiple payout addresses.

---

Regarding your other points: ensuring report's privacy should be rather simply and doesn't require "sharding" as proposal in your solution. Instead, you can encrypt the report data with curator's Public Key, upload that to IPFS & off you go.

---

DotHacks uses randomness for an arbitration committee election to improve fairness.

The assumption here is that the proposing committee is trusted by the white hacker and acts with the goal of getting its vulnerabilities fixed. Therefore, selecting a random arbitrator from among the committee is an ungrounded complication, in my opinion.

---

[dothacks]

Thank you for your reply.

Only the Polkadot council can approve the bounty, the first point should be resolvable by including the treasury pallet in your parachain, which has its own council. This should work in a manner similar to that outlined in your proposal.

In the architecture of DotHacks cybersecurity response platform, its blockchain based bug-bounty system is operated automatically and independently.

1. A Bug-bounty program is initiated by vendors on chain, then whitehats can participate in the program and submit vulnerability reports. The process does not require approvals from role like Polkadot council in treasury pallet.
2. When there is no dispute, whitehat communicates with the vendor point-to-point, and the vulnerability report is not exposed to any third party. Only when there is a dispute, the arbitrator nodes will be elected and get involved.
3. The role of vendor and arbitrator should be separated, instead of being combined into a concil, because:
   3.1 The roles of arbitrator and concil are different: an arbitrator node can be any organization or individual that has cyber-security knowledge and meets the requirements of the application, and is only responsible for verification, evaluation, and voting. There will be a vulnerability evaluation standard jointly developed by the community for arbitrator nodes to comply.
   3.2 The roles of vendor and concil are different. If having only one concil pallet: we can't have different vendors with different bug bounty programs and different budgets. If having multiple concil pallet: the number of vendors is unknown beforehand. Having the design in DotHacks enables such a flexibility.

A single resolver can be awarded from one bounty(unlike possibly multiple white hat hackers in your proposal?), the second point is a bit more tricky under the current state of the treasury module - it would either require creating multiple bounties or by allowing the curator to choose only one best solution.

In the architecture of DotHacks, Vendor will release a bug-bounty program on blockchain, with a clearly definition of what network assets are available for penetration testing. There are several significant differences between design of DotHacks and treasury pallet.

In our view, Treasury bounty is more like a fixed task, and its bounty will be paid when the task is completed. However, bug-bounty program for vulnerabilities is continuous. This is because the number and type of potential vulnerabilities are unknown to vendors.
Each program may contain a large number of completely different vulnerabilities from different network assets. Therefore, Vendors will pay different amounts of bounty to different whitehats.
The bug-bounty for security vulnerabilities is not a separable task, and there will never be one best solution in vulnerability bounty program. The vendors will issue reward only according to value of each vulnerability submitted by the whitehats.

Ensuring report's privacy should be rather simply and doesn't require "sharding" as proposal in your solution. Instead, you can encrypt the report data with curator's Public Key, upload that to IPFS & off you go.

Encryption without fragmentation ("sharding") does not have the ability to connect and verify different fragments of the vulnerability report. Therefore, fragment-then-encrypt is necessary. IPFS can be a choice for storage, if with "sharding" and encryption. In the original proposal, we try to avoid relying on such a third-party service. But this is flexible.

The assumption here is that the proposing committee is trusted by the white hacker and acts with the goal of getting its vulnerabilities fixed.

Instead, we avoid such an assumption by introducing randomness. And because whitehats, vendors and arbitrators don't know who will be elected, they cannot collude: neither whitehats or vendors can bribe the arbitrators, nor arbitrators can collude to learn the full report detail.

In general, DotHacks is designed to be a cybersecurity response platform based on a public blockchain, to ensure that DotHacks' business operates in a completely transparent, fair, and privacy-protected manner.

[mmagician]

I understand your viewpoint regarding the flexibility of the bug-bounty pallet vs the treasury pallet and see that there could indeed be some advantages.
Regarding your further points:

First, if you check the implementation of the bounty feature, you'll find that there is a role of a curators, which works just like your arbitrator. While this is a party that's trusted by the elector (in the case, the council), having multiple random arbitrators with domain-specific knowledge doesn't solve the problem, as someone trusted still needs to verify that they indeed have that kind of skillset (a very hard problem in itself).

Second:

Encryption without fragmentation ("sharding") does not have the ability to connect and verify different fragments of the vulnerability report.

But why, and how would you verify a fragment of an encrypted report? The way I understand it, one needs to read a full report in order to assess its viability, no? Unless you have some powerful automated logic for checking reports (which, arguably, is still a very human task) and you are able to run that logic on partial, encrypted data - which requires some powerful homomorphic encryption schemes - this won't serve of much use, in my opinion.

Lastly:

And because whitehats, vendors and arbitrators don't know who will be elected, they cannot collude

Vendors have little or no incentive to collude with anyone - otherwise they wouldn't post the bounty in the first place. Regarding the trust placed in arbitrators, see my previous points.

While I haven't worked on the implementation of the treasury pallet, my thought is that perhaps the best approach would be to try & extend it rather than building a separate new pallet (maintenance overhead). I'm looping in @rrtti who could perhaps share some of his thoughts.

[rrtti]

Thanks @mmagician - @dothacklab do you want to have a call to talk more about this? I'd like to understand the complete mechanism.

[dothacks]

hi @rrtti ! yeah it would be great if we can schedule a call.
What time will it be convenient for you? Maybe we can discuss the time via email?
Are you using raul at parity.io? Ours is dothacks.official at protonmail.com

[rrtti]

Perfect, sending you an email now.

[dothacks]

@mmagician @rrtti
First of all, thanks so much for pointing that we can make use of curator codes. This seems could indeed save us a lot of efforts. We would still like to keep randomness in curators election and have some qualification mechanism in election (we would explain later). But it's nice that we can extend and try to build on top of curators codes.

Regarding "vendors have little or no incentive to collude with anyone". In fact, they do. This happens during dispute resolving, when vendors and whitehats have different Severity Level ratings for a vulnerability. For example, a vendor thinks it's a low-impact one, but a whitehat thinks it's a severe one, a vendor may try to collude with arbitrators to get them rate it as low-impact, so that the vendor can pay fewer rewards. Vice versa, a whitehat may wanna collude with arbitrators to get them rate it as severe.

---

Regarding "an arbitrator may wanna collude with other arbitrators", this is the most interesting part, and this can answer both "trust placed in arbitrators" and "how a fragment of an encrypted report can be verified". In fact, the detailed workflow works as follows. Say a report is fragmented by a whitehat into 3 parts. He then also extracts a common stage conclusion A drawn from fragment 1, which is also used in fragment 2. For example, he gets the database password in the first fragment part, but to conduct further attacks described in fragment 2, let's say, getting operation system password, , he will need such a database password. If an arbitrator node knows such a stage conclusion, i.e., the database password, and the fragment 2, the arbitrator node then knows that the logic in fragment 2 makes sense. If fragment 2 logic makes sense, and other people veriy that fragment 3 logic make sense, and all other fragments logic make sense, then it mean the full report logic makes sense.

Common stage conclusions and fragments need to be asymmetrically encrypted and need to be sent to corresponding arbitrator nodes, so that nodes receiving fragment 3 won't know fragment 2. This mechanism mitigate risks, because an arbitrator node still don't know the full vulnerability details, but only a part of the vulnerability, and cannot run the attack on his own.

These are all processed in layer 2. Once an arbitrator node, corresponding to his public key, is elected, a fragment and an associated stage conclusion is assigned and sent to him encrypted using an asymmetric ephemeral key. The fragment ephemeral key is derived from arbitrator node public key and report id, so only he can decrypt it. Message digests of the original text of common stage conclusions and fragments also need to be broadcasted or be registered onto state channel network smart contract, so that arbitrator can check whether the whitehat is cheating during the dispute, for example, saying password is "111" as stage conclusion A in fragment 1, but using password is "222" as stage conclusion B in fragment 2; or sending different informations to arbitrators in a same group.

So to conclude, to start a dispute, he must fragment the report and extract some common stage conclusions; and we can see from the workflow that, if no encryption on the report, or arbitrators know each others, then arbitrators can learn the full report detail, and try to run the attack on their own.

---

Regarding "needs domain-specific knowledge".
Yes, at the begining, we might prefer to cooperate with other DID solutions in Polkadot ecosystem, and only elect from those certificated security experts. But in the future, as there is a ranking system in dothacks, whitehats get ranking scores by bug bounty programs, we can elect randomly from high-rank whitehats, while their identity can still be kept anonymous.

[mmagician]

@dothacklab Thanks for explaining your proposal in greater depth. After discussing internally with @rrtti, we agreed that rather than creating a separate pallet, the substrate ecosystem would benefit more by extending the current treasury pallet to include some of your proposed features. The goal would be to merge your code upstream to the substrate repo's pallet-treasury upon successful completion. In particular we would you like to focus on:

1. Choosing a curator at random from a pre-agreed list of curators that applied for a specific bounty (needs some kind of verification of experience & Sybil resistance)
2. Submitting a private report, so as not to expose any security vulnerabilities to the public.

If this sounds like a good idea to you, let me propose two paths for pursuing this: continue via the Open Grants Program; or submit a proposal on-chain (and in the end apply via the existing bounty feature). It might make a bit more sense to apply on-chain, as the process would be transparent start-to-end for the substrate developers - and eventually they are the ones to accept your upstream PR.
For either of these paths, I recommend first getting hands-on experience & familiarise yourself extensively with the current state of pallet-treasury. Then, you would submit a detailed technical proposal for the two above features.

Please let me know which would be your preferred option so we can help you throughout the process.

[dothacks]

Thanks for your advice. We agree that this approach could be more beneficial to the substrate ecosystem. In our idea, DotHacks will run as an independent project, where its pallet can be implemented by extending the existing treasury pallet according to your requirements, so we will choose the first option and make this part of work as our millstone in the modified open grant application. We don’t know if our idea meets the goals you gave. If it does, we will begin to prepare the proposal. Looking forward to your reply.

[rrtti]

If in the future you decide to apply for treasury funds, happy to walk you through the process.

[mmagician]

@dothacklab I propose you start with simply extending the treasury pallet and try to get the new features merged upstream.
If that is successful, then we would be happy to support evolution of your DotHacks project - but I see these as two independent goals. If that makes sense, feel free to start working on the extension proposal.

[dothacks]

After reading the code related to the treasury pallet, we have few thoughts on a new solution.

The treasury module stores funds collected from transaction fees, slashing, etc, and it is managed by the council. We believe that the purpose of the treasury pallet is to make Council use the funds more effectively. So by extending treasury pallet, Council will be able to use these funds in aspects of cybersecurity response.

In our previous application, DotHacks is a public crowdsourced cybersecurity platform as Polkadot parachain, and the funds are deposited by external vendors participating in DotHacks's business. In other words, external multiple vendors will pay for their own cybersecurity services to the whitehats on DotHacks. It may not be consistent with the design intent of the treasury pallet if we add external vendors to make it public.

For the new plan, we will give priority to extend the treasury pallet by adding a new spending instrument named Bug-bounty. Bug-bounty instrument will be independent of the existing instrument of Proposal, Tipping, and Bounty. After implementing the Bug-bounty Instrument, the Polkadot Council, or any other Substrate blockchain Council, will be able to create a private cybersecurity response center respectively, by publishing bug-bounty programs, receiving vulnerability reports and issuing bug-bounty reward for its own assets through the treasury.

We will give more details about our plan in the new open grant application based on the above scheme.

[mmagician]

In other words, external multiple vendors will pay for their own cybersecurity services to the whitehats on DotHacks. It may not be consistent with the design intent of the treasury pallet if we add external vendors to make it public.

You're absolutely right. I think it's best to think of these new features as a separate project for now.
That said, I believe that after modifying the treasury pallet with the bug-bounty feature, it will be relatively easy for you to take the developed code and still pursue the other direction of external vendors in the DotHacks idea.

[dothacks]

Sorry for the late response, our team were preparing for a conference in last few days. Now the new version of the application has been submitted. The link is as follows: #306
If there is any question please feel free to contact us.