Hedera Account Service (HAS) System Contract

[mgarbs]

Opening up discussion for hip: Hedera Account Service (HAS) System Contract

[bguiz]

👋 Hi, I've just created a draft HIP that proposes an additional function within the Hedera Account Service system contract:
HIP-792: Extend isAuthorized to process current transaction in HAS System Contract

[bguiz]

❓ Do HIP-632's isAuthorised and isAuthorizedRaw methods take into account smart contract invocation flows into its authorisation checks?

If this is indeed supported, I think it should be mentioned in the text, specifically in the "isAuthorized(address, messageHash, signatureBlob) Function Usage" section, as well as in the "User stories" section.

Specifically:

• if an account has a complex key, which includes a smart contract ID,
• and that smart contract is invoked, which in turn invokes the HAS system contract's isAuthorized function,
• will that fact that the invocation was done via the smart contract whose ID is contained within the account's complex key be considered?

---

Details:

isAuthorized(address, messageHash, signatureBlob) Function Usage

This function is used for Hedera account (non Ethereum) signature validation. It handles the more complex signature types which are available with Hedera accounts. One or more signatures will be encoded in protobuf format into the signatureBlob. The precompile function will look up the keys for the account and determine if the signatures passed in via the signatureBlob satisfy the signing requirements for the account. For example, if the account has a threshhold key of needing 3 out of 4 signatures,the precompile function will sign the messageHash with each key on the account and determine if at least 3 signatures in the signatureBlob matches.

This part reads like authorisation checks are based only on signature validation.
And the sentence "The precompile function will look up the keys for the account and determine if the signatures passed in via the signatureBlob satisfy the signing requirements for the account." makes it seem like it is exclusively based on signatures.

However, following this in the section defining the protocol buffers, there is a contract field:

...
    oneof signature {
        /**
         * smart contract virtual signature (always length zero)
         */
        bytes contract = 2;
...

The same protocol buffer definition also includes RSA_3072 and ECDSA_384, so it is unclear whether contract is used, or only present with backward compatibility with the Key, KeyList, and ThresholdKey protocol buffer definitions (to maintain positional order of this same set of fields).

[MrValioBg]

I have a suggestion regarding HIP-632. As described, isAuthorizedRaw, provides a useful out-of-the-box function for verifying signatures. However, when using ECDSA, we encounter a specific issue that could be addressed.

ECDSA, by design, is malleable, meaning a second value of s can be found that results in ecrecover returning the correct address. If a transaction is executed with such a signature, and the smart contract only tracks whether a specific signature has been used, we could end up in a scenario where a replay attack is feasible by the attacker generating a second valid s value.
This risk, of course, varies by use case and could be mitigated by including a nonce in the signature and tracking it.

However, there are use cases where an alternative solution than nonce might be preferable. For instance, OpenZeppelin has implemented a solution in their ECDSA contract, which ensures the s value is in the upper range.

Perhaps it would be useful to include it as an optional functionality, that could probably be turned on/off via a boolean flag or something similar.
I suggest that it should be optional as the solution requires the s-values to be in the upper range, thus requiring the off-chain apps' cooperation for generating signatures them correctly.

[david-bakin-sl]

See, e.g., here ECDSA Malleability blog post.

Also see EIP-2 which disallows high-s values for transactions but keeps ECRECOVER unchanged. (Stated reason: "usefui e.g. if a contract recovers old Bitcoin signatures" - wonder if that ever happens?)