Proof of UserID ownership using public key cryptography

[grctest]

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.

Github links

• Pull request #2134
• BOINC Issue "Proof of UserID ownership using public key cryptography #2118"

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?
• 2 new PHP files:
  • html/user/openssl_sign_action.php
  • html/user/openssl_sign_form.php
• 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.
• Changed the 'affected code' to reflect the changes to the pull request. It's now just 2 new files, an optional hyperlink and a newly generated openssl key pair.

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)

[grctest]

Mirrored this issue on steemit for more attention/input. It was identified that I used incorrect terminology (sign/verify private key signed message, not decryption of private key encrypted data) - I'll need to review how the original message & signed message will be displayed to the user.

Edit: I've updated the original post - see the 'issue changelog' for more info.

[grctest]

I've been working on this the last couple days and have now submitted a pull request: #2134

There's a row "UserID auth | Generate signature" under 'account keys' in the user's account page now, it links to a dedicated page which requires the user inputs a message & is returned an xml file download containing:

<boinc_user_id_verification>
 <master_url>http://ip.ip.ip.ip/boincserver/</master_url>
 <userid>1</userid>
 <user_data>12345qwertASDFG</user_data>
 <msg>1 12345qwertASDFG</msg>
 <signature>yU11FhU3yAWvlkDDmIKbfkGU3xGUsL6GyCgnW7Ti/MLFmaa240l7uQRrEAqX/gE7EoMDhILk5BYY8B7liKiDIWoqshikD92sEX9M1MqDk6zmXoBfP3ruZCpD/3NeZCDlClYpSd5sQIbusFgGetinw9CGZU5TFBnKewpPU47xF7lTsiVuz4+5ucdybE2nVkD7VOb/mZW+G7IWDIeKOec6yFEOmqfgXhLrXwGzmBVZTQIIKbYwP63sPUbgQRDYlGsqyxF2Z/PpBEV3gq/j7Tnqtib6YIfzx95+L6UAymXDCYu93RDcL3ko72FLJtgHXrlQfmbPGXk5DWCSTx10yi8XDg==</signature>
</boinc_user_id_verification>

[davidpanderson]

Weak authenticators could potentially be used for this purpose. We'd need to add an RPC for validating a weak auth.

[grctest]

Hey David, Do you mean signing a message using the weak authenticator? If you mean just using the weak authenticator for proof of account ownership, then anyone could extract the advertised weak auth from public system A and fraudulently claim the account's ownership on public system B, or rebroadcast on system A if the original registration is invalidated. The authentication proof needs to be public so that peers can verify account ownership. Fair enough you can change your password to change the weak auth, but we could see reoccurring short term account ownership theft attempts (especially against users with significant compute power). Likewise, given that account managers (and pools) hold these weak auth keys it could place additional risk on their servers storing now important information. An few advantages of using openssl public key cryptography: * Since the external system can verify a registration with the projects public key, there is no need to interact with the project server to prove ownership (reduced server load & no new api). * Replay protection both within and across external public systems - The project signs a message which contains the UserID and an external system message/key (for two way handshake). If you rebroadcast within a system you cannot change the key (thus you cannot steal ownership), if you rebroadcast a registration across external systems the key won't match thus the account ownership claim is invalid. * Openssl is a standard library within most operating systems, it's part of the BOINC server environment and it'd be trivial to perform hash verification within external systems. * Opting out of this functionality could be as simple as deleting the 2 php files (and the hyperlink). Ideally it could be an optional build flag, however my past attempt at this (when working on absolute/relative hyperlinks) was not successful. A downside of the openssl route is that an additional openssl key pair must be generated, and the public key made downloadable. Currently the PR is in a near-production state and just needs peer reviewed. I've additionally helped uplift the docker container's openssl version as a result of this undertaking. Further steps to harden the projects from abuse could be to require email verification to approve issuing a new hash. Marius began working on improving the password recovery mechanism (not using the account key) which could be extended to critical profile functionality (something I'll help with when I've got some free time between my studies hopefully). Best regards, CM. .

[grctest]

Gridcoin community has been discussing this recently

[grctest]

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:

• Navigate to the test BOINC server
• Create an account
• Go to your profile (if you're not already there)
• Click the "Generate signature" link beside 'UserID auth' within the 'Account information' section.
• Once there, enter whatever you want into the field & click submit.
• A download prompt should appear, accept the download.
• Verify its contents.

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

I look forwards to any suggestions/issues.

Cheers 👍

[grctest]

Anyone had any success/failure using the test server? Any suggestions for change?

[AenBleidd]

Looks like it is fixed via #2965. @grctest, please correct me if I'm wrong