Signature Domain Separation

[geoff-vball]

Simple Summary

Add a tag data before signing to indicate what type of data the serialized bytes correspond to.
This prevents data from being de-serialized into the wrong data type.

Abstract

All signed data on the Filecoin network is first serialized to a byte-array using cbor encoding.
A signed byte-array could potentially be deserialized into a different data type, which could be used maliciously.

Imagine User A signs a payment channel voucher and sends it to a storage provider,
but the malicious storage provider submits the signed data to the Consensus Fault method,
which decodes the data as an invalid block header and slashes User A. This FIP plans to prevent
these possible collisions between data types.

This proposal adds a fixed-length prefix to the data before signing which corresponds to the data type,
allowing us to reject deserializations into the wrong format.

Change Motivation

Currently, all signed data types on the Filecoin Network currently have implicit domain separation by coincidence.
The metadata at the start of each cbor encoding used on the network currently all differ, making it impossible to
deserialize any of them into the wrong type, which is why this FIP has not yet been implemented.
The motivation for the timing of this FIP is to allow users to safely sign arbitrary data with
the upcoming release of programmable contracts on the FVM.

Specification

We can add the tag when signing and verifying signatures, but do not need to transmit the tag,
as we can infer it based on the type of data we're signing or verifying.
Most calls to walletSign() include MsgMeta from api_wallet.go which contains
MsgType which is already implemented for dealproposal, block, and message.
We can extend the use of MsgMeta to include all other data types, and
use this metadata to know which tag to include when signing.

We propose using a single tag for all user-generated data that might be used in a smart contract.
This prevents us from having to deal with an entire "user-space" for tags.
Smart contracts will be free to implement their own tagging system below the
top level tag if desired.

Data Types

A (hopefully) exhaustive list of the different types of data we sign.

• Messages
• Block Headers
• Deal Proposals
• Storage Ask
• Payment Channel Vouchers
• VRFs (Already uses int64 as DST)
• Remove Verified Data Cap (Already uses string DST)
• BLS Aggregation (Do we run into problems here?)

Design Rationale

This FIP details what we believe to be these simplest and most robust way to prevent
unintentional and malicious collisions between message types. A fixed-length tag was chosen
because variable-length tags may not offer total collision resistance.

Backwards Compatibility

We propose doing this upgrade in a 2-step process. In the first step, we will sign all
new messages with the DS Tag, but will verify messages with or without the tag. This
will allow for any messages signed before the upgrade to still be valid after, and will
also give 3rd party wallets a chance to update to use the new tags.

In a later network upgrade, we will enforce the use of tags in the verification process,
invalidating any messages signed without tags. There is one potential exception:
payment channel vouchers. These are designed to be signed messages that live off chain
and have no expiry. We must be very careful if we want to invalidate any payment channel vouchers.

Other Considerations/ Open Questions

This FIP will have to be implemented by 3rd party wallets between steps 1 and 2.
The timing of step 2 can be adjusted if we need more time to strengthen compliance.

The length of the DSTs is still open for discussion.

What to do with payment channel vouchers is an open question.

BLS aggregation may cause issues. VerifyBlsAggregate() may not being able to accept
both tagged and untagged messages in the same aggregation.

FIP PR can be found here

[anorth]

Thanks @geoff-vball. I see a couple of distinct items here, but it makes sense to address them together.

1. Adding DSTs for signed data that's part of the Filecoin L1 protocol, like block headers
2. Providing support for DSTs for user-defined actors

While I agree we should do (1), I'm not sure that will prevent anyone being misled into signing such a payload, since the malicious payload would just include such a tag. But we could make accidental collision less likely.

For (2), we could add an explicit, required DST to the system calls that do signature validation? This would (nearly) force protocol designers to use a DST. However

• actor writers can make code doing whatever they want, including a signature validation method that doesn't force DSTs
• forcing DST would prevent use cases where the designer doesn't control the signer code, e.g. validating signatures from some already-existing scheme

I would not weigh the built-in payment channel actor too highly. Once we have user-defined actors, people can build better payment channels themselves. But I don't think we can ever invalidate existing vouchers held off-chain.

[arajasek]

Thanks for getting this started, I'm excited to try and land a solution here!

This is not currently an issue because fortunately every current type of signed data has a different length, ensuring they are unambiguously decoded.

Can you clarify this, specifying why we have implicit domain separation today as a result of CBOR?

We already do this for several types of data, but not all.

Can you please specify an example here, perhaps linking to the code where the tag gets added to the verification process?

We will have to allow for some period of time where we sign data with the new signature version while accepting old signatures.

I think regardless of the solution we go with, it is a given that we will need some kind of transition period to roll into the new signature scheme. I think a good next step would be to lay out a concrete proposal for what that might look like.

[Kubuxu]

Yes, in many cases the start of the CBOR encoding creates an implicit DST, but we should not rely on that.
The start of the CBOR will be: <Array Tag><numbrt of fields>

[arajasek]

I see a couple of distinct items here, but it makes sense to address them together.

1. Adding DSTs for signed data that's part of the Filecoin L1 protocol, like block headers
2. Providing support for DSTs for user-defined actors

@anorth Thanks for the engagement! I broadly agree with you, and am primarily interested in point 1 (DST for data that's part of the L1 protocol today), though I'm happy to kick off the second point of discussion here too.

While I agree we should do (1), I'm not sure that will prevent anyone being misled into signing such a payload, since the malicious payload would just include such a tag. But we could make accidental collision less likely.

I think some degree of protection can be provided by having interfaces that require users to specify what they are signing (which then gets prepended to the data). The primary motivation is reducing accidental collisions, though.

@geoff-vball has a mental model of what this might look like that he'll add here after a bit more time for people to leave initial thoughts.

For (2), we could add an explicit, required DST to the system calls that do signature validation? This would (nearly) force protocol designers to use a DST.

Yeah, there's some trading off here:

• Perhaps the strictest thing we can do is have a "user space" tag that the VM's verify signature syscall prepends before signing. This forces all user actor data to share the same space that is distinct from the protocol space.
• Another approach could be to have a range of DSTs available to user space that they can use, but they must specify a tag from that space. Using a tag from protocol space would be forbidden.
• The lightest weight approach would just be to have standards and example contracts that we suggest users use...

[kaitlin-beegle]

Hey @geoff-vball! There is some interest in potentially including this FIP in network v17. Do you have an update on the work? Are you still planning to draft a FIP?

[geoff-vball]

I've updated the discussion to better reflect current design thoughts as found in the FIP PR here