Deterministic Signing Key Generation - Using GitHub User ID with a Server-Side Secret

[0x4007]

Using GitHub User ID with a Server-Side Secret

Overview:

• Every GitHub user has a unique User ID (an integer). While the username can change, the User ID remains constant.
• User IDs are public information.

Approach:

• Combine the User ID with a Server-Side Secret to generate a unique, consistent, and secure salt.

Steps:

1. Server-Side Secret: Generate a random secret key (app_secret) for your application.
2. Salt Derivation: On the server, compute a salt using HMAC with app_secret and the user's GitHub User ID.
   • salt = HMAC_SHA256(app_secret, github_user_id)
3. Provide Salt to Client: Send the derived salt securely to the client upon authentication.
4. Key Generation on Client: Use the salt to derive the private key in the browser.

Security Considerations:

• Secret Protection: app_secret must remain confidential on the server.
• Salt Transmission: Transmit the salt securely over HTTPS.
• Public User ID: Since the User ID is public, using HMAC with a secret ensures the salt remains secure.

Advantages:

• Consistency: The salt remains the same for the user across devices.
• Security: Even though the User ID is public, HMAC with a secret ensures the salt cannot be derived by an attacker.

Implementing Device-Specific Keys:

• Include Device Identifier:
  • Generate a device-specific identifier (device_id) on the client (e.g., a UUID stored locally).
• Derive a device-specific salt:
  • device_salt = HMAC_SHA256(salt, device_id)
• Key Generation:
  • Use device_salt to derive the private key using a KDF like PBKDF2 or Argon2.

Conclusion:

• Viable Solution: This method provides a secure, consistent way to derive keys using GitHub data and a server-side secret.

Implementation Steps

1. Server-Side Setup:

   • Generate and securely store an app_secret.
   • Implement an API endpoint for authentication that:
     • Authenticates the user via GitHub OAuth.
     • Retrieves the user's GitHub User ID.

2. Salt Derivation:

   • Compute salt = HMAC_SHA256(app_secret, github_user_id) on the server.
   • Send the salt to the client securely over HTTPS.

3. Client-Side Key Generation:

   • Device Identifier:
     • Generate a persistent device_id on the client (e.g., UUID stored in local storage).
     • Optionally, allow users to name their devices for easier management.
   • Device-Specific Salt:
     • Compute device_salt = HMAC_SHA256(salt, device_id)
   • Private Key Derivation:
     • Use a KDF like Argon2 or PBKDF2 with device_salt to derive the private key.
     • Ensure the derived key is suitable for ECDSA on the secp256k1 curve used by Ethereum.

4. Gnosis Safe Integration:

   • Initial Setup:
     • On first login, create a Gnosis Safe wallet for the user if they don't already have one.
     • Set the master owner as a key derived from salt without the device_id (i.e., the master key).
   • Adding Device Keys:
     • Add the device-specific public keys as additional owners/signers to the Gnosis Safe.
     • Set the threshold according to your security model.

5. Claiming Rewards:

   • When a user completes a task and a payment permit is generated:
     • The user logs in with GitHub on their device.
     • The device-specific key is used to sign the transaction to claim the reward.
     • The transaction is executed via the Gnosis Safe, ensuring funds are securely managed.

6. User Experience Enhancements:

   • Seamless Authentication: Users only need to log in with GitHub; key generation happens behind the scenes.
   • Device Management: Provide a dashboard where users can see and manage their devices (e.g., revoke access if a device is lost).
   • Recovery Options: Since the master key is derived from salt, users can recover access by logging in with GitHub on a new device.

Security Considerations

• Protecting app_secret:
  • Must remain confidential on the server.
  • Rotate the secret periodically and manage salts accordingly.
• Transmission of Salt:
  • Ensure all communications are over HTTPS.
  • Implement additional security headers (e.g., HSTS, CSP).
• Client-Side Storage:
  • Store device_id and derived keys securely.
  • Consider using secure storage options like the Web Crypto API.
• Device Loss or Data Clearing:
  • If a user loses a device or clears their browser data:
  • They can re-authenticate with GitHub on a new device.
  • A new device_id is generated, and the device key is added to their Gnosis Safe.
  • Note: They may need to use the master key (derived from salt without device_id) to add the new device key as an owner if the Safe's threshold requires it.
• Preventing Unauthorized Access:
  • Implement robust session management.
  • Use anti-CSRF tokens.
  • Monitor for suspicious activity.

[0x4007]

@whilefoo maybe you can set up a Cloudflare Worker to be the backend for this idea? I have the client code almost ready

[whilefoo]

Since we know the app_secret and the user's ID, I think an additional password would ensure that even we can't access their wallet. For example the user calls the API endpoint which generates a salt (hash), then the user's browser/app derives a new salt using the previous salt and user's password. Using this method also ensures that if the app_secret ever gets leaked, the attackers can't access the users' wallets.

Protecting app_secret:

• Must remain confidential on the server.
• Rotate the secret periodically and manage salts accordingly.

We can't rotate the secret otherwise we will effectively generate a new wallet for all users and they will lose access to their previous wallet.

• Compute salt = HMAC_SHA256(app_secret, github_user_id) on the server.

HMAC_SHA256 is not suitable for this since it's meant to be used for message signature and verification, a plain SHA256 will do.

What's the intended flow after the user claims the reward? Since this is intended for users that are not familiar with crypto, how will they off-ramp the reward?

[0x4007]

Off ramp in the near future: payment cards

Mid term: some hacks using stripe/paypal etc

In the long term: we can offer fiat banking, leveraging a partnership of some sort, but it seems like that comes with a ton of strings attached so we will see where we are at connections wise and financially.

[whilefoo]

Do you have a repo for it? This issue seems to be in the wrong repo

[0x4007]

https://github.com/0x4007/ubiquity-rpc-provider/pull/2