Disallow operations on the network with server side stored private key

[sichen1234]

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]

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]

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]

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]

@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]

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]

The Wallet interface with private key is loaded around here from the server on the sign in page

blockchain-carbon-accounting/app/frontend/react-app/src/pages/sign-in.tsx

Line 68 in 17f46b5

const rslt = await signInUser(form.email, form.password);

blockchain-carbon-accounting/app/frontend/react-app/src/pages/sign-in.tsx

Line 71 in 17f46b5

if (wallet.address && wallet.private_key) {

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]

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]

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 <#638 (comment)>, 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]

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]

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]

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 <#638 (comment)>, 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]

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]

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]

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 <#638 (comment)>, 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>