Improving proof of CPID ownership --> Beacon security improvement brainstorming

[grctest]

We could potentially significantly simplify the beacon mechanism if we were able to integrate a private/public key generator within the BOINC web server, then get all whitelisted projects to update to include said functionality.

We currently rely on users providing their email address as a form of CPID ownership verification, but an email is not private information, it's effectively a public key that is shared with many web services (and many BOINC projects).

If there was an option to generate a private and public key from within your BOINC profile, then we could verify a broadcast beacon (signed with private key) against your CPID's public key to prove account ownership.

With such a defence, the next level of risk would be if accounts were compromised via phishing or if projects/services are hacked (leading to account compromise) the attacker would have access to the required information. It's still more secure than an email though.

If we also signed the beacon (which contains the above key usage) with an address within the user's Gridcoin client, we would prevent theft of cpids as readvertising the beacon would require ownership of the wallet address. This could potentially result in an inaccessible beacon registration if the user's wallet.dat is lost though. Perhaps this could be an optional additional layer of security..

---

Potential problem: User generates keys, successfully advertises beacon, stakes block w/ beacon details, changes key in BOINC project resulting in key mismatch upon block verification at a later date (if we were extracting these keys from the project every day).

Could we reject beacon transactions based on a check against the BOINC project web server for this key?

---

Any thoughts?

Know of a good PHP key generation library?

Anyone fancy trying to implement this in the BOINC web server then submit a pull request?

[grctest]

Alternatively to creating a public/private key mechanism, we could simply enforce a mandatory requirement to publish a Gridcoin address within your BOINC account, said address would be used to sign your CPID & the network would check the broadcast beacon against the Address listed in the user's BOINC profile.

Rather than utilizing an existing field (profile, username, etc) we could potentially investigate integrating cryptocurrency address fields into the BOINC web server so that it's an available feature in new projects (and any project which is capable of performing such an update).

If we were also able to get a new statistics xml created which contained <GRCAddress, RAC, CPID> and did not contain entries for accounts without a populated GRCAddress (in their profile) then we could scrape this data instead of the users.xml.gz file potentially drastically reducing the amount of data that the Gridcoin network downloads from each BOINC project.

A positive effect of reducing the data downloaded from BOINC projects would be that we could potentially remove the mandatory team requirement without making significant changes to the neural network, as one of the main concerns was the bandwidth drain the Gridcoin network would have placed upon projects when downloading the users.xml.gz files.

This would prove account ownership without the need to supply email address nor prove local account ownership, as if you're able to place a GRCAddress in your BOINC account it's a fact that you have full ownership of the account.

Potentially getting a simple 2FA such as https://www.twilio.com/two-factor-authentication integrated into BOINC would further prevent CPID squatting via phishing.

Thoughts?

[grctest]

A couple users in IRC mentioned the fact that it might be difficult to get BOINC projects to integrate such changes into their project.

If it's an objection to inclusion of Gridcoin or cryptocurrency in general, we should schedule an interview with them to understand why they object to Gridcoin inclusion in the first place.

If many projects don't want a crypto-specific field, it may be more plausible to go the Asymmetric encryption route of generating pub/private keys within the BOINC project.

If projects can't inherit such a change because they are incapable of upgrading their BOINC environment then this raises a serious red flag for increased project whitelist status scrutiny; if they can't do an upgrade, have they properly secured the project in the first place?

[nateonthenet]

Rather than asking projects to add crypto-specific fields, you might be better off asking them to add a single generic field where users can paste arbitrary XML or JSON-formatted data. This would be much more useful / flexible and probably politically more palatable, since it provides the potential to work alongside all sorts of third-party software that might want to associate with the user profile and not only Gridcoin / cryptos.

[grctest]

Possibly, but what length? The BOINC project wouldn't be able to perform validation against an unknown block of data so it could be open to abuse.

A seperate page which had many crypto fields would be more preferable, however projects such as WCG may outright refuse (as you say because of the politics) ... might be a tough sell to remove WCG from the whitelist, haha!

[tomasbrod]

I have an idea for secure cpid ownership. Force the user to change cpid :) External cpid is formed by server. Internal _cross_projectid is randomly assigned by server, but is changed by client as part of cpid merging procedure.

external_cpid := MD5( hex( cross_project_id ) + email_address )

So we replace _cross_projectid with hash of user public key and send it to boinc. On next project update servers use this _cross_projectid to generate _externalcpid which we can calculate too and verify. Other user hosts may undo our trick (oldest _cross_projectid has authority) so they must detach all other hosts and re-attach after the change. To prevent this process from repeating every 6 months, beacon keys should be generated only once. And stored in the wallet as other secret keys not in the config.

cross_project_id := SHA256/128( beacon_pubkey )
external_cpid == MD5( hex( SHA256/128( beacon_pubkey )) + email_address )

[grctest]

Interesting idea @tomasbrod , would this cause an user's statistics to split on boincstats though?

If we did implement such a change, all current owed balances would become inaccessible due to the user's CPID changing, so it's something that would have to be well coordinated.

Other user hosts may undo our trick (oldest cross_project_id has authority) so they must detach all other hosts and re-attach after the change.

This could be a nightmare supporting users in IRC though,

---

After the recent interview with the TN-Grid project administrator, I don't think we'd be able to get all BOINC projects to integrate a cryptocurrency page if there was any manual involvement required, as many projects might hesitate to add the field due to financial/regulatory concerns.

The TN-Grid admin put it well - "The payment of the users is entirely out of his hands" - where as if the projects were involved in the proof of CPID ownership (through adding cryptocurrency address fields) they would be directly enabling the payment of their users..

Potentially we wouldn't need to get all projects to add this field though, if a few projects added the field then we could prove CPID ownership with several sources.

I think the most agreeable solution for projects which fear regulations/finances would be the private/public key generation within the BOINC project, this could be used for proving CPID ownership for anything, not just crypto.

---

Some further thoughts:

• Generic asymmetric public key field integrated into BOINC web server. This is crypto neutral.
• We generate a private and public key within the Gridcoin client.
• The user is instructed to paste the public key into the new field in each BOINC project.
• If there are multiple unique public keys detected across projects:
  • The legitimacy of public key should be based upon the potential magnitude (not in NN yet). This prevents theft/squatting of CPIDs by fraudulently registering using your email on more whitelisted projects than the user is legitimately crunching.
  • Downside: If an attacker's mag outweighs the victim's mag this mechanism will have been detrimental to this cause.
  • Account age should be taken into account, preventing many recent sign-ups (which have high mag) from outweighing old legit accounts with low mag.
  • If we can get an 'email verified' field exposed for scraping, we could disqualify non-verified accounts. This would be another hurdle because few projects have email verification implemented.
• The user advertises their beacon, signing their CPID with their private key, the clients look up the public key and decrypt proving CPID ownership.

[tomasbrod]

Yes changing CPID would break user stats just like a split cpid. On the other hand staseb.fr allows you to merge cpids and boincstats should show your total credit right. User balance wont be affected, only the owed amount. A solution is to pay all owed before the change becomes mandatory. Testing is called for.

[grctest]

A solution is to pay all owed before the change becomes mandatory.

Easier said than done, no individual is in control of GRC reward distribution - users are themselves responsible for staking on a timely basis.

It's possible that we could perform some kind of bail-out from foundation funds for lost 'owed' balances, but that would assume that every Gridcoin user was to make the switch at the same time and without the old-cpid reversal issue occurring afterwards (further increasing lost owed GRC for ongoing computation).

It would also have a couple day fall-out whilst the CPID merges across all projects, which we wouldn't hear the end of in IRC haha!

This migration would only be possible whilst the network is small, if we removed the team requirement and had to perform this for say 50k users it would be a complete nightmare.

[tomasbrod]

User sends beacon in the new format signed by both the old and new beacon keys while the old one is still active. The new beacon includes reference to old cpid and requires cpid to be derived in a way described in my previous message. User then starts mining with the new cpid signed by new beacon keys. The network internally merges RAC, Mag and Owed until the old beacon expires. As a side effect the network will preserve owed amount when user changes his email or other unfortunate event happens that cause his cpid to be changed.

Edit: made a dev wiki to collect datils for this scheme. https://github.com/gridcoin/Gridcoin-Research/wiki/DEV-CPID-Ownership Correct me if I am mistaken but all users should have write access to the wiki?

[ghost]

I'm not sure if this is feasible but I think we should forget about the idea of using the CPID for anything. I like the idea @grctest proposed about generating a private/public key and modifying the BOINC web server to store a public key.

Here's my initial thoughts on what we could do about the CPID.

First we remove the requirement of BOINC being needed on the same machine as the wallet by requiring each project to be added to the wallet through a UI in the wallet. This has the following benefits.

• Makes the wallet more secure as it can be installed on a machine seperate from BOINC.
• Allows us to prove ownership of each users BOINC account through the wallet.
• Since we're not relying on the CPID we can prevent theft of the BOINC users' stats.

The Verification Process

1. Create a BOINC UI that lets you add projects to the wallet. This would require you to select a project from the whitelist and then enter your project BOINC email and password to authenticate.
2. On successful auth a private/public key would be generated for the project and the public key would be stored in the public key field on the web server (adding the public key to the users BOINC account could be done by the wallet if we modify the web API).
3. A beacon would be sent which contains the public key, the project id and user id (BOINC user Id for the project).
4. The process would repeat for each BOINC project the user adds to the wallet.

I'm not sure why beacons expire but If possible I would make the beacon last forever or until the user tries to attach the project again to a new wallet.

Now the Neural Network would use the project url, the user id and public key to track statistics and verify ownership.

The benefit of not using the CPID and verifying each BOINC project individually would be that the problem @grctest mentioned about CPID theft would be prevented. However it would introduce some new issues like aggregating the users data and potential scaleability issues with the amount of beacons being stored.

Regarding the issue of BOINC projects not allowing us to change the web API. We could potentially store the public key in the user profile. However, it's not ideal because there is no Web API method to retrieve the user profile. We would need to scrape the HTML which is far from ideal and storing it in the profile is less professional.

[tomasbrod]

@tonemackay: Eliminatin the CPID from reward mechanism sounds good. It is insecure MD5 after all. How do you want to assiciate and verify association of beacon public key and boinc project user ID?

• Include beacon keys into exported stats
  • requires modification of all project servers
  • would add 253MiB to SETI user.xml and 79MiB to WCG
• Include beacon keys on public boinc user page
  • requires modification of all project servers
  • requires one request per beacon per project by all neural network nodes

[ghost]

@tomasbrod I'm not sure what the best option would be. Maybe option 2 would be better because the client only needs to query the user id's it knows are in the network.

If we could modify the show_user.php method so it returned it in the XML

<user>
    <id>123</id>
    <cpid>fe0b2753a355b17864ec061eb1b9e8de</cpid>
    <create_time>918948493</create_time>
    <name>Joe Smith</name>
    <country>United States</country>
    <total_credit>3806.869739</total_credit>
    <expavg_credit>200</expavg_credit>
    <expavg_time>1110833427.64028</expavg_time>
    <teamid>114322</teamid>
    <url>example.com</url>
    <has_profile>1</has_profile>
    <public_key>NEW FIELD</public_key>
</user>

If we fail to get a pull request and can't get projects to get on board we could scrape the public key from the user profile HTML page (providing every project has option for user profile).

Example http://gene.disi.unitn.it/test/view_profile.php?userid=1025

Storing in the user profile is not ideal but if we could automate it in the auth process in the wallet and maybe make it look neater users might not mind.

[tomasbrod]

Bear in mind @tonemackay that the checks must be performed by all network nodes, not only the sender. Othervise someone with modified wallet could cheat the system and steal/squat CPIDs.

• verify before accepting beacon into block
  • Every staker receiving a New beacon must make a request to the project website.
• verify all beacons in NN
  • requires one request per every beacon per project by all NN nodes
• verify new beacons in NN
  • requires one request per New beacon per project by all NN nodes

[grctest]

Create a BOINC UI that lets you add projects to the wallet. This would require you to select a project from the whitelist and then enter your project BOINC email and password to authenticate.

This would certainly accelerate the inclusion of the public key in such a field, however it comes at the cost of logging into a 3rd party website through the Gridcoin client as opposed to having the users input the public key into the new field.

First we remove the requirement of BOINC being needed on the same machine as the wallet by requiring each project to be added to the wallet through a UI in the wallet.

We could already do this if we were to rely on a public key being present in the user's profile. If we were to go the route of changing the user's CPID then we may need to require that the BOINC client is present.

Since we're not relying on the CPID we can prevent theft of the BOINC users' stats. ... The benefit of not using the CPID and verifying each BOINC project individually would be that the problem @grctest mentioned about CPID theft would be prevented.

In order to steal one's CPID you need full access to the users account, in which case you would also be able to steal their earnings if relying on the userid (if their beacon wasn't registered).

However it would introduce some new issues like aggregating the users data and potential scaleability issues with the amount of beacons being stored.

An advantage of using CPID is that it's identical across projects where as userid is unique per project.

---

• Include beacon keys into exported stats
  • requires modification of all project servers
  • would add 253MiB to SETI user.xml and 79MiB to WCG

Ideally, if we were able to push changes to the exported stats we could get our own stats file created which simply contained CPID:PublicKey:RAC (reducing amount of data downloaded). With new exported stats we could also push for an alternative data format such as JSON.

[ghost]

@grctest I was under the impression that all you needed to steal a CPID was to know the users email address since the CPID is a hash of the email? If that is the case, then it would not be too hard. I have already given my email to third-parties related to Gridcoin.

[tomasbrod]

I traced how the beacon "contract" is created and added the info to wiki. Bacically it is a function of boinc internal cross_project_id, boinc email and some random salt. The CPID is then MD5( hex( cross_project_id ) + boinc_user_email ). To send any beacon, you must provide email and cross_project_id that produces your desired CPID. So the security of the beacon depends on cross_project_id being secret.

[grctest]

So the security of the beacon depends on cross_project_id being secret.

It relies on email being secret, not cpid. But this is still insecure (not as immediately insecure as you suggest, unless you can easily derive the email from the md5?). Additional CPID ownership is required.

Edit: Wait, you make a good point.. can I just clone the data from a transaction then send it again without worrying about email/cpid data from my address to claim the beacon? That would be stupid..

Any replay attack would have to wait until the users beacon was expired though, so it's a rare window. That said, we've got ~2k in NN & 12k in team.. perhaps several opportunities?

[tomasbrod]

It relies on email being secret, not cpid.

It depends on email andor cross_project_id being secret. Don't forget that cross_project_id is not cpid. If email address is leaked then you are safe by the cross_project_id. It is kind of secure.

The MagicFunction that transforms email,cross_project_id,blockhash to CPIDv2 look like MD5. In fact the beginning of output is equal to MD5(cross_project_id+email) but there is some woodoo appended to it. It wont be suprise if that extended output reveals more of the input than it should. cpid.cpp needs to be documented. It looks highly suspicious that the file is so obfuscated.

[ghost]

@tomasbrod @grctest is the cross_project_id generated on the project server unique to the BOINC user or is it generated as a global ID for the project? If it is unique to the user then it should be secure but if it is per project then all someone needs to do is have a different account for that project to determine the cross_project_id.

Getting the email address is easy. How many users would have used the same email for their BOINC project as signing up for a pool (pool owner knows it)? How many would have used it to sign up for the usecore.net newsletter for the free GRC?

[Erkan-Yilmaz]

Getting the email address is easy. How many users would have used the same email for their BOINC project as signing up for a pool (pool owner knows it)? How many would have used it to sign up for the usecore.net newsletter for the free GRC?

... or team founders (even if we have now a "correct" teamfounder somewhere, in the past another teamfounder had access to emails): https://github.com/Erkan-Yilmaz/Gridcoin-tasks/issues/55

[tomasbrod]

Is the cross_project_id generated on the project server unique to the BOINC user or is it generated as a global ID for the project?

This cross_project_id is equal across all projects user is attached to. It is generated by all project server when creating account and sent to boinc client in rpc response. Boinc client selects the oldest cross_project_id and uses that in all rpc requests.

If you attach to pool, you know their cross_project_id and email_hash, which is cross_project_id=22652bdfeb1b5e1ecedc2ac35427542d, email_hash=0557706d8b8c556d367566d1e0952738=MD5("admin@grcpool.com"). If we use the CPID equation, $(echo -n "22652bdfeb1b5e1ecedc2ac35427542dadmin@grcpool.com" |md5sum) is 7d0d73fe026d66fd4ab8d5d8da32a611, which is their cpid 7d0d73fe026d66fd4ab8d5d8da32a611. Also if you attach to pool, or any account manager, they already know strong authenticators to all your projects.

[tomasbrod]

What our crunchers think about changing their CPID in order to continue crunching for gridcoin? Let them vote! @Erkan-Yilmaz what do you think?

[Erkan-Yilmaz]

changing cpid will be again like this:

• many ignore/might not see and wonder what went wrong (and complain)

So, if the "new cpid"-system can coexist with the old for a certain time (6 months? b/c that is the time of beacon renewal anyways), this would be ideal.

• who does not switch to the "new cpid"-system is in danger of his cpid being stolen, and it's her own fault then for not reading important places

[grctest]

https://github.com/gridcoin/Gridcoin-Research/issues/289

[grctest]

What our crunchers think about changing their CPID in order to continue crunching for gridcoin? Let them vote! @Erkan-Yilmaz what do you think?

I think it's too early to put this to a vote, it needs further discussion & alternative options explored. Changing the CPID could be a massive headache for users if they don't do it properly or if they add an old project to their account manager & it merges to the old CPID. Though, if this new mechanism was able to retire the current beacon deletion process which involves RTMoney it may be less of a headache?

Perhaps the CPID merging process could be in scope for improvement?

I'll raise the topic of improving proof-of-cpid during the BOINC workshop if it occurs this summer.

[tomasbrod]

I found a flaw in my proposal, it is way there and obvious in the equations (email is not public). Actually I prefer @tonemackay idea. It just needs more work. I knew changing the cpid of users is too intense I just wanted to hear "No how dare you to touch the cpid, it will mess up my boinc stats" :)

[Erkan-Yilmaz]

We talked about this also in our 8th interview (series: "talking with BOINC admins"):

• making a future field neutral (not especially for Gridcoin) and thus other teams could use it also for saving info they'd need for their wishes could help lower the "resistance"

when you will listen to the interview, you will see that the BOINC admin was willing to add an extra table, but needs to ask with colleagues and so first

[tomasbrod]

I would juat like to let you know, that tere is now a wiki page, collecting proposals forr cpid ownership. I added a new Secure Account Association proposal or SAAp. It leaves the job of verifying account ownership to Neural Network nodes or Witnesses.

[tomasbrod]

I forgot to add, that SAAp combines and extends ideas by @grctest and @3ullShark.

[ghost]

@tomasbrod what are your thoughts on having the key set in the BOINC project via a UI in the wallet that makes you input your BOINC email and password.

[tomasbrod]

That would be great for user experience. But may pose security challenge.