search

hyperledger-labs / blockchain-carbon-accounting

This project implements blockchain applications for climate action and accounting, including emissions calculations, carbon trading, and validation of climate claims. It is part of the Linux Foundation's Hyperledger Climate Action and Accounting SIG.
https://wiki.hyperledger.org/display/CASIG/Carbon+Accounting+and+Certification+WG
Apache License 2.0
195 stars 104 forks source link

Disallow operations on the network with server side stored private key #638

Closed sichen1234 closed 1 year ago

sichen1234 commented 2 years ago

Just watched the video of signing with users wallet

I think this feature should not be allowed so that we're not passing the private key from the server to the client.

The consumer or operator could request a transaction, but then it should be stored in the database and routed to an auditor.

We can also set it up so that auditor roles can only be granted to users without a server stored private key.

brioux commented 2 years ago

Restricting all token creations operation to auditors makes sense. Even if it is to just initialize a request. See comment in issue637 for handling new carbon tracker requests from an oil & gas operator.

brioux commented 2 years ago

Not sure we need to limit transactions to accounts that have opted to store their keys on the server side when signing up.

It is better practice for accounts to hold keys directly, in line with the principles of web3.0 transaction. But an auditor may prefer to use a key management service.

Server side key management was introduced to the user sign-up function to help with onboarding of consumers that don't have the experience operating a server side wallet.

Should NET provide its own internal cloud key management for signing transactions? It already does in the referenced video, but with limited security.

sichen1234 commented 2 years ago

What do you think of signing the transaction on the server, instead of transferring the private key to the client and signing it there?

brioux commented 2 years ago

@sichen1234 I was just writing this up...

Here are some ideas for improving security.

Private keys never leave the server side to sign transactions, only when exporting keys and permanently deleting it from the server. This is structurally different from what was shown in the referenced video. Transaction messages could be sent encrypted to the server (using the public key) where the message is decrypted and signed. However, this requires creating a secure communication line between the client and server for a given signing session ....

brioux commented 2 years ago

Use the window.Crypto object (a secure way to use javascript to access the DOM) to store privateKeys in the client browser when receiving them from the server during sign in.

brioux commented 2 years ago

The Wallet interface with private key is loaded around here from the server on the sign in page https://github.com/hyperledger-labs/blockchain-carbon-accounting/blob/17f46b56a5b9303685c51cac19f9fb8875b8ed2b/app/frontend/react-app/src/pages/sign-in.tsx#L68 https://github.com/hyperledger-labs/blockchain-carbon-accounting/blob/17f46b56a5b9303685c51cac19f9fb8875b8ed2b/app/frontend/react-app/src/pages/sign-in.tsx#L71 The private key should be sent by the server to the client's Wallet interface encrypted by a public key address generated by the clients window.Crypto object.

brioux commented 2 years ago

As discussed at the end of this older post a variety of modern browser features can be used to securely store the keys with the client -- this is basically what browser extensions like Metamask achieve

sichen1234 commented 2 years ago

This makes the dApp implement a metamask-like wallet. What is the advantage of doing this, versus just signing the transaction on the server? I feel more comfortable if the private key does not leave the server.

Si Chen Open Source Strategies, Inc.

Why open source and blockchain for carbon accounting? Video https://www.youtube.com/watch?v=eNM7V8vQCg4 and Blog Post https://www.opensourcestrategies.com/2022/06/01/why-open-source-carbon-accounting/

On Tue, Oct 25, 2022 at 10:58 AM Bertrand Rioux @.***> wrote:

At discussed at the end of this older post https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi a variety of modern browser features can be used to securely store the keys with the client -- this is basically what browser extensions like Metamask achieve - with the keys stored in the browser

— Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/638#issuecomment-1290944149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4KEF2TTXBJBUAKYUVDWFANTVANCNFSM6AAAAAARNKUKTM . You are receiving this because you were mentioned.Message ID: <hyperledger-labs/blockchain-carbon-accounting/issues/638/1290944149@ github.com>

brioux commented 2 years ago

both require similar security development.

Keeping keys on the server limits attack vectors to server breaches. The benefit of moving the signing to the client is probably the legal context in how the server uses the private keys.

If the server is setup to sign transactions on behalf of the client, but used in a malicious transaction, the company operating the server could be held accountable.

The user agrees to the terms associated with the key management service provided by the client interface. Assuming the server provider makes all precautions to deliver the key securely, the clients are accountable for signing transactions.

brioux commented 2 years ago

A secure and legally sound client application should have baked in client key gen and storage (e.g., electron or mobile app). Both of the above are patchy solutions at best.

sichen1234 commented 2 years ago

OK, I see your point and it makes sense.

Something like this would take more time to develop.

Meanwhile for security purposes we'll remove the passing of private keys to the client side for signing transactions.

Si Chen Open Source Strategies, Inc.

Why open source and blockchain for carbon accounting? Video https://www.youtube.com/watch?v=eNM7V8vQCg4 and Blog Post https://www.opensourcestrategies.com/2022/06/01/why-open-source-carbon-accounting/

On Tue, Oct 25, 2022 at 11:32 AM Bertrand Rioux @.***> wrote:

A secure and legally sound application should have baked in client key gen and storage (e.g., electron or mobile app). Both are patchy solutions at best.

— Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/638#issuecomment-1290979638, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4IBHEFDSYTX56NY4N3WFARSPANCNFSM6AAAAAARNKUKTM . You are receiving this because you were mentioned.Message ID: <hyperledger-labs/blockchain-carbon-accounting/issues/638/1290979638@ github.com>

brioux commented 2 years ago

Agree.

As long as the signed in user is only received retired tokens, no need to access the privateKey.

Minimize key management to the bare minimum, and rely on third party wallet party providers and custom built client applications.

Suggest putting private keys into a separate write only schema, with read access limited to key export and deletion.

Once transferable tokens are issued to the user (e.g., offset credits or carbon trackers), the keys must be exported to access the tokens.

Another more secure option is to instruct the server to use the keys once to transfer the tokens to a new public address generated by the users external wallet. This eliminates security risk from potential breach of the original private keys - but would come with additional transaction costs.

brioux commented 2 years ago

Question, if a client has connected their external wallet to NET, is there a form they can use to register information about their public address with the Postgres server - e.g. organization, name, email... ?

I have started a separate discussion on handling user information using Distributed identity management tools. A topic of discussion for future development.

sichen1234 commented 2 years ago

Right now not. We can add a form for the user to update that and sign it to submit. That should be pretty simple.

The bigger question is how the whole process of user identity should be handled. We can discuss that over time.

Si Chen Open Source Strategies, Inc.

Why open source and blockchain for carbon accounting? Video https://www.youtube.com/watch?v=eNM7V8vQCg4 and Blog Post https://www.opensourcestrategies.com/2022/06/01/why-open-source-carbon-accounting/

On Tue, Oct 25, 2022 at 3:35 PM Bertrand Rioux @.***> wrote:

Question, if a client has connected their external wallet to NET, is there a form they can use to register information about their public address with the Postgres server - e.g. organization, name, email... ?

I have started a separate discussion on managing user information using separate Distributed identity management tools. A topic of discussion as feature for future development.

— Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/638#issuecomment-1291212255, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4PIXJQ4BFOUGH3GIPTWFBOBPANCNFSM6AAAAAARNKUKTM . You are receiving this because you were mentioned.Message ID: <hyperledger-labs/blockchain-carbon-accounting/issues/638/1291212255@ github.com>