search

gridcoin-community / Gridcoin-Tasks

Gridcoin community tasks repository
https://gridcoin.us
MIT License
24 stars 5 forks source link

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

Closed skcin closed 4 years ago

skcin commented 6 years ago

Issue by grctest Thursday Apr 06, 2017 at 01:07 GMT Originally opened as https://github.com/Erkan-Yilmaz/Gridcoin-tasks/issues/101

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?

skcin commented 6 years ago

Comment by grctest Thursday Apr 06, 2017 at 14:10 GMT

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?

skcin commented 6 years ago

Comment by grctest Saturday Apr 08, 2017 at 17:21 GMT

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?

skcin commented 6 years ago

Comment by nateonthenet Monday Apr 10, 2017 at 15:21 GMT

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.

skcin commented 6 years ago

Comment by grctest Monday Apr 10, 2017 at 17:16 GMT

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!

skcin commented 6 years ago

Comment by tomasbrod Tuesday Apr 11, 2017 at 07:21 GMT

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 )
skcin commented 6 years ago

Comment by grctest Thursday Apr 13, 2017 at 21:59 GMT

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:

skcin commented 6 years ago

Comment by tomasbrod Thursday Apr 13, 2017 at 22:35 GMT

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.

skcin commented 6 years ago

Comment by grctest Thursday Apr 13, 2017 at 22:42 GMT

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.

skcin commented 6 years ago

Comment by tomasbrod Friday Apr 14, 2017 at 08:21 GMT

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?

skcin commented 6 years ago

Comment by 3ullShark Thursday Apr 20, 2017 at 08:24 GMT

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.

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.

skcin commented 6 years ago

Comment by tomasbrod Thursday Apr 20, 2017 at 12:33 GMT

@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?

skcin commented 6 years ago

Comment by 3ullShark Thursday Apr 20, 2017 at 13:44 GMT

@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.

skcin commented 6 years ago

Comment by tomasbrod Thursday Apr 20, 2017 at 13:56 GMT

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.

skcin commented 6 years ago

Comment by grctest Thursday Apr 20, 2017 at 15:15 GMT

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.

skcin commented 6 years ago

Comment by 3ullShark Thursday Apr 20, 2017 at 15:41 GMT

@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.

skcin commented 6 years ago

Comment by tomasbrod Friday Apr 21, 2017 at 17:44 GMT

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.

skcin commented 6 years ago

Comment by grctest Friday Apr 21, 2017 at 19:07 GMT

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?

skcin commented 6 years ago

Comment by tomasbrod Friday Apr 21, 2017 at 19:56 GMT

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.

skcin commented 6 years ago

Comment by 3ullShark Saturday Apr 22, 2017 at 08:32 GMT

@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?

skcin commented 6 years ago

Comment by Erkan-Yilmaz Saturday Apr 22, 2017 at 09:23 GMT

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

skcin commented 6 years ago

Comment by tomasbrod Saturday Apr 22, 2017 at 10:30 GMT

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.

skcin commented 6 years ago

Comment by tomasbrod Sunday Apr 23, 2017 at 10:01 GMT

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

skcin commented 6 years ago

Comment by Erkan-Yilmaz Sunday Apr 23, 2017 at 10:18 GMT

changing cpid will be again like this:

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.

skcin commented 6 years ago

Comment by grctest Saturday Apr 29, 2017 at 12:56 GMT

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

skcin commented 6 years ago

Comment by grctest Sunday Apr 30, 2017 at 19:50 GMT

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.

skcin commented 6 years ago

Comment by tomasbrod Sunday Apr 30, 2017 at 20:52 GMT

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" :)

skcin commented 6 years ago

Comment by Erkan-Yilmaz Sunday May 14, 2017 at 15:35 GMT

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

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

skcin commented 6 years ago

Comment by tomasbrod Tuesday Aug 29, 2017 at 15:30 GMT

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.

skcin commented 6 years ago

Comment by tomasbrod Wednesday Aug 30, 2017 at 15:32 GMT

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

skcin commented 6 years ago

Comment by 3ullShark Wednesday Aug 30, 2017 at 15:52 GMT

@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.

grctest commented 6 years ago

https://github.com/BOINC/boinc/pull/2134 https://github.com/BOINC/boinc/issues/2118

grctest commented 6 years ago

I've created a test server with the latest pull request implemented: http://209.250.242.113/boincserver/

I'd greatly appreciate trying out the PR's functionality, following the below instructions.

Note: No SSL implemented, do NOT use username/password credentials you use elsewhere (use garbage test username/password).

How to test:

You have full permission to try and break/hack this specific proposed feature.

I look forwards to any suggestions/issues.

Cheers 👍

barton2526 commented 6 years ago

Bug: Entering </userdata> into the Generate Signature field creates bad XML output. You should sanitize the inputs for tag escapes.

grctest commented 6 years ago

@barton2526 Can generating bad XML output be an attack vector against the BOINC server? The same effect can be created by changing the XML in notepad manually prior to submitting to a 3rd party app.

barton2526 commented 6 years ago

the problem is the xml file cannot be properly parsed at all in this case and the signature is malformed as a result. I can supply more examples if needed.

grctest commented 6 years ago

@barton2526 Third party services will need to be able to reject malformed XML, besides it's not a problem you can impose on others only your own 3rd party app CPID verification attempts.

Your example outputs the following XML:

<boinc_user_id_verification>
 <master_url>http://209.250.242.113/boincserver/</master_url>
 <userid>8</userid>
 <user_data>test</userdata></user_data>
 <msg>8 test</userdata></msg>
<signature>OWCJZDJGKMJyuz0ogTMjAfQ1OQtvfNxdEKcDizDcbFszE++Va2vOGoa+fbQn+k3/WLrY13ORXlt4AGj9RIRWZNm76zOQq3v5d6PShlH2+j9LGh0XKtp6j8xuUud32wlaJ73k8Kk2eLL7IquOb1D9LDnrKymLSFkKI4ysGryju/th2d0k7zrQEyfMMyhZGpFHiLGzgXIPAll5glGj2aFhdmu52WJq0YNdsMbQAu15lDDH60lLtSCoFKZruv7IflrsuiECIQ1XUUzPA0fvKkqZ9M4y4Risft8W+qnC6stpRjZmDlyV9rM8ixHz/bZVy8GXWlAVPJuilnYD5LlIYtK0Wg==</signature>
</boinc_user_id_verification>

compared to:

<boinc_user_id_verification>
 <master_url>http://209.250.242.113/boincserver/</master_url>
 <userid>8</userid>
 <user_data>test</user_data>
 <msg>8 test</msg>
 <signature>ggk3QTh2NJvqxkHhgugcC35Vhc2+A7U0JjqSlgZXLFtbnrqM6w0gHwQUXZlaYejjUSy7waORUHsOgIwN+BqFA3wKgr6B91O9pICuRIizMHNFGqrYrIkUzuKI995TdJSuXeiIs+9gxEV26r/wdR3tW1szsYnbOrKgw8OGxOSIR0RmQAiKJuRqGqpwWbDknx45KzqnpiGJukkCKgyHxE+QmwrT5/txDaZ2DTcAWQ4JX3RfmxOQirI+eiwUqnjnmeJsWkEJoEpF+EkzujnR7wts/jJ+ZhX6nxlAla4da6lrr5YaSTHRJhIs87DHcgI/CtsoRV4SFcFKZlUOTLEMVDiHkQ==</signature>
</boinc_user_id_verification>

Open-SSL has signed 8 test</userdata>, so it's not disrupted the openssl signing operation. The same XML malformation effect can be achieved by manually editing the file before submitting it for verification within the external application.

Perhaps there are 3rd party signatures which would contain tags?

tomasbrod commented 6 years ago

The output Barton is getting is O.K.. You put bad data in, you get bad data out. Integrity of the server is not compromised. All functions on the data path are specified as binary-safe, as well as the signature (hash) function. The input length is limited. The application should be responsible and it it wants a valid xml, should not provide input with < in it. The argument against escaping the input string on the server side is that, it introduces a degree of unpredictability. Signature of 'xy<' will not match signature of 'xy<'. Also the escaping function might mangle unknown multi-byte sequences, producing invalid signature. What could be done, is to make sure the input string is a well-formed XML and throwing error otherwise. But passing the string to a XML validator can IMHO cause more problems than it solves eg: speed.