Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use Ethereum wallet to create and access a profile #300

Open
felicio opened this issue Jul 22, 2022 · 4 comments
Open

Use Ethereum wallet to create and access a profile #300

felicio opened this issue Jul 22, 2022 · 4 comments
Assignees
@felicio
Labels
E:Web Communities Protocol status-js status-react

Comments

@felicio
Copy link
Collaborator

felicio commented Jul 22, 2022 •
edited

What

How (for example)

Prerequisities

  • Community is embedded in another dapp
  • Wallet account was already pre/generated or imported in those multiple environments
  • Identity is not the one created by native Status apps (i.e. desktop or mobile)
  • No seed phrase or private key is requested from the user
@felicio
Copy link
Collaborator Author

felicio commented Jul 22, 2022 •
edited

My notes

How

  • Create a new account in wallet and use exported private key as the profile
  • Create private key within the app and import it into a wallet
  • Status browser extension
  • Use a signature generated by the wallet to always create same private key within the app
  • TBD

@felicio felicio self-assigned this Jul 22, 2022
@felicio
Copy link
Collaborator Author

felicio commented Aug 3, 2022 •
edited

Proposals

Table

Status: draft
Disclaimer: now only in theory and without research and security teams' review
Disclaimer: grades are subjective

  In-app key generation In-app key generation from wallet signature In-app key generation with wallet encryption and decentralized backup In-wallet key generation returned as value In-extension key generation with RPC methods for per-session signing and encrypting In-native key generation with Vac protocol pairing In-app key generation with password manager import via <input> In-native key generation via RCP method and WalletConnect protocol pairing
ID 0 1 2 3 4 5 6 7
Status Stable Stable Stable Idea Idea Idea Stable Idea
Estimation XS S L L XL M S L
Supported wallets -       - - -
Exposes private key No Yes No No No Yes Yes Yes
Preserves identity across in-house clients No No No No Yes Yes No Yes
Domain binding/origin checking No No No Yes Yes -
Backed up - Yes No No - No
Recoverable Yes Yes Yes Yes - No
Exposes wallet account No Yes No No No No
Encryption       AES-256-GCM, ECIES (secp256k1)    
Key generation ECDSA (secp256k1), Crypto.getRandomValues(new Uint8Array(40)) (hash)       ECDSA (secp256k1)    
Key derivation path       BIP43, EIP-1581    
Signing       ECDSA (secp256k1), PBKDF2, SHA-3-256 (keccak256)    
Key exchange - - - Return value - X3DH, 35/WAKU2-NOISE, 37/WAKU2-NOISE-SESSIONS -
Identity encoding       base58    
Security grade B B B A B C
Usability grade B     A    
Ecosystem fit grade A B C A B C
Ecosystem outlook adoption grade A B C - A C
Signing message format       EIP-712    
Derived from a user seed phrase No No Yes Yes Yes No
Deterministic key generation Yes - Yes Yes - -
References EIP-2224, EIP-712, EIP-4361   EIP-1775 2/ACCOUNT, 26/WAKU-PAYLOAD    
Demo            
Review            
Personal inclination at the moment (see last edited date)       ☝️    

Notes

Keywords

key management, private, public, secret, account, sign, log, auth, origin, identity, federated authentication, backup, webauthn, passkey, sync, verification code, issuer, phishing, domain binding, password, cryptographic key pairs, end-to-end encryption, phishing resistance, cross-platform, public key cryptography, credentials, proximity proof, local key agreement, CTAP operation, factors, scope, cookies, secure context

We should value privacy more

https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475

  • Mixers
  • Keep wallet software stateless
  • For every dapp a separate account
  • Deterministic scheme
  • so we would use different BIP-32 paths for each dApp.
Waku Key Management

https://specs.status.im/spec/10#keys-management

  • The protocol requires a key (symmetric or asymmetric) for the following actions
    • signing & verifying messages (asymmetric key)
    • encrypting & decrypting messages (asymmetric or symmetric key).
  • Solve Key Management waku-org/js-waku#73 (comment)
    • DID as identifier, not chat keys
  • https://discord.com/channels/864066763682218004/892839110073520128/915558795533496331
    • [@]cammellos so I had a chat with [@]John_ and I think there is an important detail that impact the discussion above. The aim for mobile/web sync'ing is mainly to onboard users on the Status mobile app FROM a DappConnect Chat website. E.g., a user uses the uniswap trollbox (built with DappConnect Chat SDK) and setup their profile and has some good fun. As they want to troll on the go,they install the Status chat app and sync their web profile to the status chat app.
EIP-191: Signed Data Standard

https://eips.ethereum.org/EIPS/eip-191

EIP-712: Typed structured data hashing and signing

https://eips.ethereum.org/EIPS/eip-712 https://ethereum-magicians.org/t/eip-712-eth-signtypeddata-as-a-standard-for-machine-verifiable-and-human-readable-typed-data-signing/397/6

  • We are seeing growing adoption of off-chain message signing as it saves gas and reduces the number of transactions on the blockchain. Currently signed messages are an opaque hex string displayed to the user with little context about the items that make up the message.
  • Just encoding structs is not enough. It is likely that two different DApps use identical structs. When this happens, a signed message intended for one DApp would also be valid for the other. The signatures are compatible. This can be intended behaviour, in which case everything is fine as long as the DApps took replay attacks into consideration. If it is not intended, there is a security problem.
    • The way to solve this is by introducing a domain separator, a 256-bit number. This is a value unique to each domain that is ‘mixed in’ the signature. It makes signatures from different domains incompatible. The domain separator is designed to include bits of DApp unique information such as the name of the DApp, the intended validator contract address, the expected DApp domain name, etc. The user and user-agent can use this information to mitigate phishing attacks, where a malicious DApp tries to trick the user into signing a message for another DApp.
  • [WIP] Add eth_signTypedData as a standard for machine-verifiable and human-readable typed data signing with Ethereum keys ethereum/EIPs#712 (comment)
EIP-2224: Automatic Authentication Signatures For Web3

https://ethereum-magicians.org/t/automatic-authentication-signature/2429 https://medium.com/@wighawag/automatic-authentication-signatures-for-web3-dcbcbc64d6b5 https://medium.com/@wighawag/3-proposals-for-making-web3-a-better-experience-974f97765700

  • Authorization fatigue
  • Origin checks
  • This means another application could request the same signature. Hence the fully automatic authorization signature scheme mentioned here can’t be used since a malicious application would simply request the same signature without requiring user approval. A proper implementation would indeed require the user’s vigilance to not sign such message on a malicious application. This leads to a potential vulnerability against authorization fatigue (especially if you can’t rely on a web browser to store your signed-seed, in which case you would need to request signature for every session), similarly to what I mentioned about cryptokitties.
  • Unsafe signing rpc: eth_sign Contract interaction and Signature request transaction types status-mobile#8909 (comment)
  • Of course as mentioned such scheme is not for everything since it relies on the user trusting the application’s front-end in question
EIP-1581: Non-wallet usage of keys derived from BIP-32 trees

https://eips.ethereum.org/EIPS/eip-1581

  • https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817
    • Using keys under the BIP32 tree for these purposes would allow the user to migrate the whole identity from one software to the other using the BIP39 mnemonic alone, since everything else would be derived from there.
    • Key types should be generic. “Instant messaging” is a good example whereas “Whisper” is not. The reason is that you want to be able to use the same identity across different services.
    • Implies that access to a dApp specific private key is given to the dApp. I believe this is not ideal as it means the dApp now needs to properly handle the private key.
    • Another solution would be to provide a generic API that supports several encryption. An idea would be to use CryptoSubtle as the API reference and assume that in the Browser world, some of the encryption supported by Crypto Subtle should be supported by the Wallet API.
EIP-1775: App keys, application specific wallet accounts

https://eips.ethereum.org/EIPS/eip-1775

EIP-2844: Add DID related methods to the JSON-RPC

https://eips.ethereum.org/EIPS/eip-2844

EIP-1024: Cross-client Encrypt/Decrypt

https://ethereum-magicians.org/t/eip-1024-cross-client-encrypt-decrypt/505 https://ethereum-magicians.org/t/the-ux-of-eip-1024-encrypt-decrypt/1243 ethereum/EIPs#1098

EIP-4361: Sign-In with Ethereum

Contracted by Ethereum Foundation and ENS to an org called Spruce in an open "tender", funded with 40M+ USD by many investor, to do... https://eips.ethereum.org/EIPS/eip-4361 https://ethereum-magicians.org/t/eip-4361-sign-in-with-ethereum/7263

  • Already, many services support workflows to authenticate Ethereum accounts using message signing, such as to establish a cookie-based web session which can manage privileged metadata about the authenticating address. This is an opportunity to standardize the sign-in workflow and improve interoperability across existing services, while also providing wallet vendors a reliable method to identify signing requests as Sign-In with Ethereum requests for improved UX.
  • Both the wallet and relying party have to implement this specification for improved security to the end user. Specifically, the wallet MUST confirm that the message is for the correct domain or provide the user means to do so manually (such as instructions to visually confirming the correct domain in a TLS-protected website prior to connecting via QR code or deeplink), otherwise the user is subject to phishing attacks.
  • In some implementions of wallet sign-in workflows, the server first sends parameters of the message to the wallet. Others generate the message for signing entirely in the client side (e.g., dapps). The latter approach without initial server interaction SHOULD be preferred when there is a user privacy advantage by minimizing wallet-server interaction. Often, the backend server first produces a nonce to prevent replay attacks, which it verifies after signing. Privacy-preserving alternatives are suggested in the next section on preventing replay attacks.
  • Prior to signing, the wallet MAY consult the user for preferences, such as the selection of one address out of many, or a preferred ENS name out of many.
  • Wallets MUST check that the domain matches the actual signing request source.
  • This value SHOULD be checked against a trusted data source such as the browser window or over another protocol.
  • If any resources specified in resources change, the server SHOULD invalidate sessions appropriately. However, the interpretation of resources is out of scope of this specification.
  • https://blog.spruceid.com/sign-in-with-ethereum/
  • https://blog.spruceid.com/sign-in-with-ethereum-proposed-architecture/
    • provide a direct form of authentication to Web2 services using message-signing and claims aggregation directly from a user’s Web3 wallet and ENS, rather than a traditional intermediary
    • using newly derived Ethereum addresses on a per-interaction basis, or incorporating zero-knowledge techniques to reduce correlation.
  • https://blog.spruceid.com/ethereum-identity-review-of-eips-over-time/
    • Additionally, signed_data could never be an Ethereum transaction, because it cannot be one RLP-structure, but a 1-byte RLP payload followed by something else. (EIP-191)
    • This EIP was a response to EIP-725, due to EIP-725 requiring the creation of a smart contract and not being free for the end-user. The specification additionally accounts for key rotation without changing the primary identifier of the identity. (EIP-1056)
  • https://blog.spruceid.com/spruce-raises-7-5-million-to-speed-the-development-of-user-controlled-id-and-data/
    • We will be scaling up efforts on SpruceID, our open source toolkit for decentralized identity, and Kepler, our decentralized and permissioned storage solution.
  • https://blog.spruceid.com/sign-in-with-ethereum-wallet-support-eip-191-vs-eip-712/
  • https://blog.spruceid.com/from-sign-in-with-ethereum-to-session-keys/
    • One solution is autosigning, which allows applications to automatically use the user’s keys for certain actions without the wallet displaying a confirmation prompt. This approach has been considered previously by the WalletConnect protocol and several wallet providers, but it has since been discouraged due to its potential for gross overreach of permissions. There is a high potential for abuse if not implemented carefully.
    • Other approaches that require the user to input their seed phrases or private keys into the browser window have been categorically deemed by the community to create unacceptable levels of risk. The browser DOM is by far a less secure environment than hardware wallets and browser extensions, readily vulnerable to common cross-site scripting (XSS) attacks and weak content security policies.
    • Mirror offers users session keys in the form of their “Signing Keys” which authorizes a key to sign on the user’s behalf to avoid wallet interactions. After signing, the user isn’t prompted again to sign for any action they perform on the platform:
    • https://twitter.com/lindseywinder1/status/1480919369395933189?s=20&t=Qq4dBALwJo2bebsXqKbrLA
      • I think it's a copy issue. If you said "import wallet" instead of "sign up using seed" I'd look at this the same way I do when using metamask or trust. "Sign up" makes the user think you're storing it like an email address
    • The browser DOM is by far a less secure environment than hardware wallets and browser extensions, readily vulnerable to common cross-site scripting (XSS) attacks and weak content security policies.
  • https://blog.spruceid.com/sign-in-with-ethereum-is-a-game-changer-part-1/
    • For full transparency, the specification states that the entire message and fields must still be made available in additional sub-interfaces (such as a detail view).
    • The specification also introduces additional security requirements for wallets, such as domain binding to prevent phishing attacks
    • and nonces to prevent replay attacks,
  • https://blog.spruceid.com/spruce-completes-first-security-audit-from-trail-of-bits/
EIP-1056: Ethereum Lightweight Identity

https://eips.ethereum.org/EIPS/eip-1056

  • it must also be possible to rotate keys without changing the primary identifier of the identity.
  • The identity system should be fit to use off-chain as well as on-chain.
Extensible crypto for wallets

https://ethereum-magicians.org/t/extensible-crypto-for-wallets/2546

Misc.
Code

@felicio
Copy link
Collaborator Author

felicio commented Aug 16, 2022 •
edited

Reasons

Status: draft

See table above for detailed comparison, following only lists main reasons which I think should help with picking a proposal.

Proposal 1

Pros

Cons

Proposal 2

Cons

  • Exposes wallet addresses as users of the dapp
  • Even though encrypted, represent an additional service that can be targeted for denying service or obtaining private keys without user consent
Proposal 3

Cons

  • Requires all major wallets to implement a standard which has been in "stagnant" state for years
Proposal 4

Pros

  • Doesn't require us to wait for other providers to agree and implement the solution
  • Preserves user identity across all platforms
  • Protects user from a modified source code trying to obtain a private key
  • Through our official channels we can communicate to users that only our native app and the extension can and should be used to manage seed phrase or private keys
  • Spreads org's awareness through visibility (in App Store, Web Store) and differentiability from other wallets (by separation)

Cons

  • Larger effort
  • Unknowns in regards to providing and securing access to only relevant pages without prompting user all the time on refresh or reopen
  • Unknowns in regards to generating same private/chat key despite provided seed phrase
    • Chat keys (at least on mobile) seem to be generated randomly, not in order
    • Number and performance needed to generate all possible private keys until matched with provided public key

@felicio
Copy link
Collaborator Author

felicio commented Aug 16, 2022 •
edited

Questions

Status: draft

Product

  • What's the actual product spec?
  • Shouldn't throwaway profiles be labeled as such (e.g. field in waku message)?
  • Shouldn't throwaway profiles be removed from Community's members list after a while (TTL)?
    • When?
    • Why not have it valid only for 24h, for example? In which case it could be preserved in browser storage even unencrypted, I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@felicio felicio

Labels
E:Web Communities Protocol status-js status-react
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@felicio @prichodko