Standard Message Authentication Method for Actors (FIP-0044)

[arajasek]

Update: FIP PR #424

Note: Heavily based on EIP-1271

One-line Summary

Standardize an AuthenticateMessage (name TBD) method across actors, that gets invoked in place of ValidateSignature calls to the runtime. This allows entities besides externally-owned accounts (secp & BLS keys) to authenticate messages.

Background

Currently, only externally-owned accounts can sign messages with their associated private keys. Today, this restricts some functionality (for example, a multisig actor being a storage client), but isn't a major issue. Withe the planned introduction of user-programmable actors to the Filecoin network, however, the scope of innovation blocked by this restriction will grow.

There are already proposals to work around this problem -- FIP-0035 is a concrete example of this. It introduces three new messages (along with their associated types) in order to allow actors to function as built-in storage market clients.

Proposal

We can instead have a standard AuthenticateMessage method across actors, that takes raw data and some "signature" data as input. Actors can implement this method as they see fit, though a "good" implementation should meet certain criteria (see below). In the case of the Filecoin builtin actors, for instance, the Account actor simply implements this by validating the signature itself. An m/n multisig actor could implement this by receiving m signatures of the message in question, and validating them individually.

Specification

Concretely, we propose adding the following method to the built-in Account Actor. This method can then be the blueprint for other builtin actors (eg. the multisig actor), as well as a template for user-defined actors.

    /// Authenticates whether the provided signature is valid for the provided message.
    /// Errors if the authentication is invalid.
    pub fn authenticate_message(params: AuthenticateMessageParams) -> Result<(), ActorError>

The params to this method is a wrapper over the message and signature to validate:

pub struct AuthenticateMessageParams {
    pub signature: Vec<u8>,
    pub message: Vec<u8>,
}

A draft PR may be found here.

Matters of considerations

While the proposal is relatively straightforward, there are some details that require special consideration:

• We would need this new method to be uniformly referenced across actors. Methods are currently referenced by numbers in the Filecoin protocol, and we could simply give this method some special number that is standardized as "the authenticator number" across actors. However, the existing discussion about calling conventions is very germane to this proposal. It would be much preferred to standardize the name of this method, and then have dispatch governed by that name.
• We should think about who pays for the cost of such authentications. By default, all costs involved with message execution are paid by the top-level sender of the message as gas fees. We don't have to deviate from that default, although there is some concern about actors implementing very inefficient authentication methods whose costs could surprise someone interacting with them. It would be nice if actors paid for the cost of their own authentications, but that is likely hard to achieve.
• As mentioned above, there are many important properties that "good" implementations of such AuthenticateMessage methods should satisfy. I'd like to defer a consideration of these properties, scoping this discussion to the portions relevant to implementing this idea in the built-in actors today (with an eye towards replacing FIP-0035 with this idea).

Acknowledgements

Thanks to @anorth for the idea, and the authors of EIP-1271 for the previous work.

[anorth]

Thanks @arajasek. I support pursing this proposal in preference to FIP-0035. The latter would become redundant. This proposal leads to less complexity in the built-in actors, is quicker to implement, and also establishes a pattern for future applications to follow.

In comparison with the approach described in FIP-0035, this proposal is universal from the point of view of actors that need to verify messages. That is, the FIP-0035 approach requires every actor that wants to authenticate messages from either EOAs or other actors to implement their own additional methods and intermediate state; this approach means they can all just delegate it back to the signing actor. The flip side is that it means actors that wish to send authenticated messages must implement something instead. I think it's likely a very good tradeoff in terms of total work and complexity in the ecosystem to put that work on the sender side. I expect there to be many more receivers and a fairly small class of sender implementations (wallet actors, multisigs, DAO roots etc).

[arajasek]

Edited the OP to include an informal specification, as well as a link to a draft PR that prototypes this.

[kaitlin-beegle]

Hi @arajasek! Can you help clarify whether or not it's your intention that the message authentication method be drafted as a FIP, or else implemented directly as a feature enhancement in builtin actors? I believe this falls into a bit of a grey zone, but my initial understanding is that the latter is most appropriate.

[anorth]

Usually this would just be an FRC, but to make it useful we need the built-in actors to implement it. And then usually any change in behaviour to built-in actors needs a FIP (b/c it changes consensus rules).

This doesn't change any existing behaviour, but adds a new one (@arajasek will also need to update the market actor to invoke this new method, to supersede FIP-0035). But still, this enshrines a new standard in the network much more tightly than if the built-in actors did not implement it.

So it's still a grey zone, but for now I think the FIP is appropriate.

[kaitlin-beegle]

Great; thanks @anorth. That's very helpful.

[arajasek]

I was planning on opening a FIP, yes! :)

[Tom-OriginStorage]

Agree on the proposal too.

But do note that in reality, DAOs actually piggyback the signature parameters to squeeze and encode data. For example OpenDAO's airdrop contract actually piggybacks the parameter v in the signature for the airdrop amount.

[raulk]

@arajasek @anorth Have you had the opportunity to reason through how this proposal would integrate with #388? Both proposals are related in the sense that they place message validation logic on chain. One enables an actor to act as a sender (account abstraction); the other enables composability.

[anorth]

Yes. I didn't think to write anything about it because, as you say, they enable different things and I think each are independently valuable.

For the built-in account actor, I would expect the same validation logic (crypto signature validation) to be invoked via either entry point. Other smart-contract wallets would probably do the same, I think. But this proposal also allows contracts that have no private key at all to authenticate messages (e.g. against some internal state) so there's no necessary equivalence.

While "whether or not a message is authentic never changes" makes sense much of the time, I do not think it should be a requirement of this FRC. Neither do I think it's reasonable to place any environmental restrictions on the AuthenticateMessage endpoint. An actor will, in fact, be able to revoke a message's validity.

[arajasek]

Yeah, I don't think they're too tightly coupled, except that some actors may want to extract the core logic into some common method used by both AuthenticateMessage (this discussion) and validate (account abstraction).

I think the chief issue is to have better names for these endpoints!

While "whether or not a message is authentic never changes" makes sense much of the time, I do not think it should be a requirement of this FRC. Neither do I think it's reasonable to place any environmental restrictions on the AuthenticateMessage endpoint. An actor will, in fact, be able to revoke a message's validity.

Hmm, this is interesting. Do you not envision problems with such malleability? The first example that comes to mind for me is a SP being "tricked" into receiving data and locking up collateral for a storage deal, only to find that the validity of the proposal signature has changed.

I don't think we can (or should) enforce such immutability (unlike in the account abstraction validate case), but it does seem to me like a "good" AuthenticateMessage implementation should be immutable.

[anorth]

It's a fair concern, I do agree that it'll usually be preferable. But some implementations will incur a state cost for every message they continue to validate, so there'll be a small incentive to periodically clean up.

I agree that the current implementation of the built-in storage market has this possibility.

• Limited when the SP trusts the signing code (tho upgrading actors can always change it)
• In practise I think there will be a finite set of widely-used actor impls that do deal message authentication, and they'll have their own reputation. SPs taking deals openly will occasionally be misled.
• If the problem were really rife, we (ecosystem) could create non-upgradeable signing actors.
• We can also re-introduce FIP-0035 if proven necessary. There's a tradeoff of cost/complexity of getting the commitment on chain, vs some limited trust.

[raulk]

Agree that the public APIs for these features should not be unified, but actors representing accounts will probably reuse some code for both mechanisms.

Concerning the code malleability attack vector, this could be mitigated by introducing a check in the caller to verify that the CodeCID has not changed from the time of commitment to the time of validation. However, that inflates the tracked state (and associated gas charges). Regardless, this should be documented to avoid footguns.