3

I have deployed a Quorum network on Azure Block chain service to be used by specific invited members of a consortium. I have not yet explored the privacy features provided by Quorum on top of Ethereum. But i notice certain behaviors that make me wonder about how is authorization handled in any Ethereum based blockchain.

  1. Anyone on the internet who knows the RPC URL(HTTPS Access Key) of any node in the network and has a deployed contract's address & ABI, can create an account on their laptop using web3.eth.accounts.create() and start sending signed messages to read the state variables and execute any functions of any smart contract deployed on the network.

  2. Anyone on the internet who knows the RPC URL(HTTPS Access key) of any node in the network and has a deployed contract's address & ABI, can read state variables and execute get functions of any smart contract deployed on the network without the need for signing, by using the accounts stored on the geth node itself.

Is the authorization done by hardcoding the authorized accounts into the contract and checking them within every function? If so, what happens when the account's private key is lost? Does the smart contract become unusable?

3

Azure provides an RPC security layer that enforces access control to the network. In order to provide authentication to your RPC interface you can use basic authentication, certificate based authentication or you can link to your identity provider.

After you are part of the network (rpc auth passe) you have Quorum state authorization layer (what is called the permissioning model) this authorization layer will enforce the separation between the private and public state (easier to understand by saying private vs public contract). However this layer does not enforce authorization beyond the separation between private and public state.

currently its up for the smart contract developer to provide a function based authorization model that suits their application (most commonly used one is "owner pattern"),

To put it in perspective; RPC Security -> Quorum state authorization layer -> custom built smart contract authorization layer.

Quorum Smart Contract based Permissioning framework provides a versatile way of managing a permissioned network, however it operates at the private/public state authorization layer not the smart contract function level.

Anyone on the internet who knows the RPC URL of any node in the network and has a deployed contract's address & ABI, can create an account on their laptop using web3.eth.accounts.create() and start sending signed messages to read the state variables and execute any functions of any smart contract deployed on the network.

If your RPC interface is insecure (no authentication required and binded to 0.0.0.0) then yes anyone will be able to interact with the network and interrogate the network, but that doesn't mean they will be able to interact with private state. that will happen only and only if the node exposed is part of the private circuit of an specific contract.

Anyone on the internet who knows the RPC URL of any node in the network and has a deployed contract's address & ABI, can read state variables and execute get functions of any smart contract deployed on the network without the need for signing, by using the accounts stored on the geth node itself.

No, the accounts has to be unlocked, and in order to unlock the accounts you need the password.

Is the authorization done by hardcoding the authorized accounts into the contract and checking them within every function?

Yes if using "owner pattern"

happens when the account's private key is lost? Does the smart contract become unusable?

if you lose private key of an account and you have a resource that depends on the signature from that account then its a game over.

I would recommend you to read the following:

http://docs.goquorum.com/en/latest/Security/Framework/Overview/ https://solidity.readthedocs.io/en/v0.4.24/common-patterns.html#restricting-access https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/

| improve this answer | |
  • 1
    Thank you, i am not clear on what you are referring to when you mention the RPC security layer provided by Azure. If you are referring to the Firewall rules defined for the transaction node, it made no difference when i removed the single default entry(AllowAll from 0.0.0. to 255.255.255.255). I was still able to interact with the smart contract using just the RPC URL, ABI and contract address without any kind of authentication/authorization. I could not see any option on the portal to enforce basic or certificate based authentication. – faizal Jan 22 at 17:07
  • 1
    And when you say "No, the accounts has to be unlocked, and in order to unlock the accounts you need the password.", i am able to read the state variables or execute get functions even though the account is locked as long as i have the RPC URL, ABI and contract address – faizal Jan 22 at 17:08
  • I got an answer from the slack channel : go-quorum.slack.com/archives/C825QTQ1Z/p1579792781037600. Essentially, the access key in the RPC URL serves the same purpose as a password. If compromised, it should be regenerated from the portal, which will invalidate the earlier Access key immediately. – faizal Jan 23 at 15:55
3

You are correct - anyone with the address & ABI can call a public contract. The only way to prevent this is to have code within the contract that checks for calls from authorized addresses.

If a private key is lost then the contract would need to be updated to replace that authorized address.

I suggest you take a look at Quorum's smart contract based permission model.

| improve this answer | |
  • When you say the contract needs to be updated, that would entail a contract deployment to a new contract address with the state from the original contract not carrying forward.. so essentially a new contract? – faizal Jan 22 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.