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)