Proof of BOINC UserID ownership using public key cryptography

in boinc •  3 months ago

Proof of BOINC UserID ownership using public key cryptography

Transparency/Background

  • Original 'project-rain' cryptocurrency field issue: The PR was rejected in accordance with the PMC's policies against the explicit inclusion of (and reference to) virtual currency related code within the core BOINC repo (still possible on an individual project basis).
  • Single user-data field: A scaled back version of 'project-rain' with no explicit reference to virtualcurrencies (implied use, not explicit intended use). Several legitimate risks to BOINC projects were identified during the 2017 workshop, such as painting a massive target on BOINC projects (externally/internally) to hackers monetarily motivated (since projects would have been storing the data being scraped by 3rd party systems).

Purpose

To prove within any external system that you are the owner of an UserID for an individual BOINC project, without storing external system data within the BOINC project's servers.

Proposed steps within BOINC

  • Introduce an additional openssl public/private key pair for this feature, keeping the existing keys separate and safe. Storing the public key in a scrape-able location (perhaps alongside the stats dumps).
  • Introduce a link to the user's profile, taking them to a separate php page for generating the signed message.
  • Within the new page there would be:
    • Some explanation text.
    • An input textbox (external system data for full handshake).
    • A button for executing the message signing function.
    • An output textbox where the output data will temporarily be displayed.
  • The message signing function will:
    • Require:
      • A minimum RAC before enabling the function - reducing the ease of claiming idle account ownership.
      • A verified email account (unless the project doesn't use email verification).
    • Use:
      • openssl_sign to sign the message "$UserID $External_System_Key"
      • External_system_key to provide full handshake, preventing extraction of master UserID from one network for replay on another.
    • Limit the length and accepted characters for $External_System_Key.
    • Potentially be limited to once an hour, if computationally expensive.
      • Downside being the requirement for an additional SQL table.
    • Output the signature and original message to the in-page output textbox. It will not store this data on the BOINC server (message is temporary).

Proposed use within external system

Pre-req: External system downloads the public-keys (used solely for this function, not the existing keys) from each of the involved projects.

  • User manually inputs their UserID signatures generated within each individual BOINC project.
    • If OAuth2 is implemented, streamline this process to improve user experience.
  • Broadcast registration transactions for for each project, including the generated encrypted messages.
  • Peers upon receiving the registration transaction:
    • Attempt to verify the signed message (contained within broadcast registration transaction) with the appropriate project public key.
      • If successful:
        • Attempt to verify that the contained $External_System_Key matches the user's beacon key (perform same check for UserID).
          • If keys & Ids match: Approve ownership of UserID.
          • Else: Reject ownership of UserID.
      • If unsuccessful:
        • Reject ownership of UserID.

Advantages over a single user-data field

It's more difficult for an attacker to claim external system rewards if a MinRAC and Email Verification is required. Offsets the risk of account compromise on a large scale for the purpose of claiming rewards (concern raised within the workshop).

If a project wishes to cut off external systems from rewarding new users they can remove the public key from the scrape-able location, however an external system may cache the keys which would enable all currently registered users to continue earning rewards. If at any point a project administrator/owner doesn't want their volunteer userbase rewarded they should contact representatives of the external systems for streamlined removal (not a problem on the GRC network).

An upside of using UserID over CPID is that external system functionality wouldn't be interrupted by a CPID change (either accidental or malicious). A disadvantage of UserID is that each user will need to advertise a registration operation for each individual project (an external system's burden, not boinc's problem).

If an UserID registration is ever stolen on an external system, or if a hacker breaks into their account and issues a new registration transaction, the user just needs to log back in (change their password), generate a new message and advertise a new beacon. No more need for a centralized entity responsible for maintaining the registered userbase (improved decentralization).

Affected code

  • Profile: Link to new PHP page. Alternatively: propose a better link location?
  • New PHP page for this function:
  • schema.sql: Potentially require introduction of an additional sql table to prevent dos of server resources by spamming the key generation.
  • Make_Project scripts:
    • Generating an additional openssl public/private key pair.
    • Difficult: Introducing an additional MISC option to enable this functionality at build time.
  • Additional openssl public/private key pair.

Issue changelog

  • Changed the openssl function section - It was identified that I used incorrect terminology (sign/verify private key signed message, not decryption of private key encrypted data).
  • Changed advantages to be more accurate.

Thoughts?

Any suggestions/constructive-criticism would be greatly appreciated, thus far I have not begun to implement this however I don't believe it will be that difficult.

Suggestions for alternatives to openssl? (Related article)

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  trending

First, I am happy that you @cm-steem, started working on the issue of CPID/UserID Ownership.
Website boinc signature, requires boinc account authenticator to prove ownership. As authenticator grants full control of the account, this is obviously out of question.

What you propose, is for a project to maintain signing key-pair and a api/form to sign UserID + custom data with the project key. Then this signature proves that the user has access to the boinc account.

... decrypt message with project's public key

In your article, you used said project server encrypts the message with project private key and peers then decrypt it with the public part. I assume you mean sign and verify, because one does not decrypt with public key. (encrypt with public, decrypt with private, sign with private, verify with public)

I don't know if you realize the effects, but with this proposal, gridcoin nodes will not need to make a single request to the project server to verify the association! The project public key can be included into the project beacon.

Timestamp to prevent replay attack within a network.

Can you elaborate on what replay attack is possible without this timestamp? If it was not there, attacker could capture an re-send the registration, but it would be essentially a no-op, as it would simply associate the same External_System_Key with the UserID.

If a project wishes to cut off external systems from rewarding their users, they can simply change or remove the public key.

This claim is false. As the key will remain cached in the external system.

It's more difficult for an attacker to claim external system rewards if they aren't able to just include an address in their profile & they need to run a wallet per UserID they claim.

This is again false. If attacker can gains access to boinc account to edit profile, he can as easily use the message signing form. And one wallet will suffice for claiming multiple UserIDs, if they are attackers, they can edit the source.

Advantages:

  • verify association without contacting server
  • better than current state, obviously
  • independent of CPID

Disadvantages:

  • requires (non-trivial) modification to boinc server software
  • project admins must maintain yet another key-pair
  • user must perform registration of every project

And Last, current state it's issues and some research on the topic is available on CPID Ownership wiki.

·

First, I am happy that you @cm-steem, started working on the issue of CPID/UserID Ownership.

Thanks, it's a natural progression from the last few issues & rain related projects. Hopefully this research can be used by many external systems (not just gridcoin).

Website boinc signature, requires boinc account authenticator to prove ownership. As authenticator grants full control of the account, this is obviously out of question.

Wow, that's pretty bad!

On the upside, during the BOINC workshop Marius from cosmology@home began working on the removal of the account key web-authentication, so the account key effectively becomes a weak auth key.

... decrypt message with project's public key

In your article, you used said project server encrypts the message with project private key and peers then decrypt it with the public part. I assume you mean sign and verify, because one does not decrypt with public key. (encrypt with public, decrypt with private, sign with private, verify with public)

Whoops - misuse of terminology & under-specification as a result.

If the message being verified (signed with private key) is not encrypted, then we'll need to hash the message prior to signing the hash on the BOINC server, then within the Gridcoin client recreate the hash using the same original message data ("$UserID $External_System_Key $Current_Time") for comparison, right?

So perhaps the output text box should include:

Plaintext: $UserID $External_System_Key $Current_Time
Signed_Hash: function_output

To which we then paste (one project at a time) into the Gridcoin client, which hashes the plaintext and performs the signature verification.

Sound better? Or additional areas for improvement?

I don't know if you realize the effects, but with this proposal, gridcoin nodes will not need to make a single request to the project server to verify the association! The project public key can be included into the project beacon.

Indeed, the client will only need to maintain an updated list of project public keys for beacon verification, there would be zero need for providing the gridcoin client an email address too (since with this proposal you establish full proof of account ownership).

Additionally, given that UserID's don't change (unlike CPID) we could move towards permanent beacons, especially if we were to utilize burn addresses (instead of looking back 6 months of blocks).

Timestamp to prevent replay attack within a network.

Can you elaborate on what replay attack is possible without this timestamp? If it was not there, attacker could capture an re-send the registration, but it would be essentially a no-op, as it would simply associate the same External_System_Key with the UserID.

If the 'External_System_Key' was the address used to register the beacon, then sure the timestamp wouldn't play any serious role & in fact it should be removed to improve simplicity of generating the hash of the originally signed message.

If the 'key' was simply GRC/ETH/ETC (ticker term instead of address) then the timestamp would play a role in preventing replay of the beacon within a network and upon external networks.

I think you're right that the timestamp could be phased out entirely, in favour of just $UserID & $External_System_Key.

If a project wishes to cut off external systems from rewarding their users, they can simply change or remove the public key.

This claim is false. As the key will remain cached in the external system.

It would cut off new registrations, but you're right that anyone that had successfully proven their UserID ownership with the project's public keys cached would continue earning rewards despite the key being removed from the BOINC server.

This would be grounds from removal from the whitelist. If we didn't bundle these keys within the gridcoin client, then on first boot if the keys weren't present the superblock mechanism may experience instability as some may simply not recognize the project's beacons as legit.

It's more difficult for an attacker to claim external system rewards if they aren't able to just include an address in their profile & they need to run a wallet per UserID they claim.

This is again false. If attacker can gains access to boinc account to edit profile, he can as easily use the message signing form. And one wallet will suffice for claiming multiple UserIDs, if they are attackers, they can edit the source.

You're possibly right that a modified client could potentially register one beacon per address, and never attempt to stake across UserIDs (flagging to the rest of the network a duplicate UserID registration), which would reduce the cost of registering many accounts.

I proposed a couple additional security measures to make hackers lives harder:

Require:

  • A minimum RAC before enabling the function - reducing the ease of claiming idle account ownership.
  • A verified email account (unless the project doesn't use email verification).

Disadvantages:

requires (non-trivial) modification to boinc server software

If accepted in the main repo, and enabled perhaps with an MISC build option then only projects which have heavily modified the web server implementation would have difficulties implementing the new functionality (WCG, Einstein).

Otherwise, it's a rather simple chunk of code to develop, especially if we're just using openssl instead of an alternative public key cryptography library.

project admins must maintain yet another key-pair

This is true, however it's not as critical as the other key-pairs.

Currently, project admins are advised to take private keys offline or move to a more secure location, we'll possibly need to investigate securing the private key for hot use (instead of cold storage).


Thanks for the reply, much appreciated.

Best regards,
CM.

·

I've updated the original post with your input in mind.

I really don't understand the techical detials, but I am a fan of Gridcoin which is obviously a close relative to BOINC.

Advertised BOINC in my last beer tasting post. Hope it gets you more visibility and clicks!

Cheers

hi @cm-steem, read it once and read it twice, i think it would make sense to go down this road, especially for the decentralisation part. It really does not seem to be that difficult but most likely theres a detail that i did not see yet. Transition needs to be planned thoroughly...

it looks like these are some improvement in Boinc project, i hope these developments improve boinc alot, thanks for sharing.

The implementation indeed doesnt seem that hard. But what are you planing for the transition?

This system has almost endless possibilities IF applied properly. Good luck with it!

nice presentation, full of information, thanks for sharing.

Boinc Rocks <3

·

best of luck <3

This BOINC project looks very promising. We hope all the very best for its future.

nice@cm-steem, improvising about your project and it will developed boinc alot, thanks.

Steemit Bank invested in your post.

Follow Steemit Bank

Support the project by upvoted the this comment.

a very good post thanks for sharing my story I wanted to share a good story but I have not been able to! success is always friends

Reblogged — let’s promote quality content!

Really nice post.....I enjoyed reading

very informative article
sir i want to ask something sir i write very informative article about steemit but its doesn't earn why sir i am confuse can you help me if you have time sir

·

sir i want to ask something sir i write very informative article about steemit but its doesn't earn why sir i am confuse can you help me if you have time sir

Just keep posting articles of good quality.

·
·

Sir if you have time then see my article is that value able or not . is this right way which i choose

good posting

@cm-steem, this is very interesting reading! I love steemit, as I did not even think this stuff was possible, until i try reading blogs like this!

I am working with the #promo-uk team and @stephenkendal to promote steemit on a UK tour around 22 universities during freshers week! As a promonent UK steemian, we would like to ask for your support and if you have time, even to come and join us for whatever time you can spare at your nearest university!

The tour started in Manchester today, does a trip around the country and ends up in Lancaster on 07th Oct.

THIS link will show you the tour route, meeting times and meet up locations.

THIS link shows you our success around Manchester today!

It would be really great if you could make it to one of these promotional events to have some fun talking Steemit and letting people know how great it is!!

We are also presenting at the London investors fair on 20th October. We plan to get together with some steemians in a London bar after the event for some drinks (which we will put 150 GBP behind the bar for)
HERE is a summary of our last meetup

Please reply to this or contact me in steemit.chat if you are interested to take part or support our work!