Disperser auth

[cody-littley]

Why are these changes needed?

Authenticate StoreChunks() requests.

Checks

• I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
• I've checked the new test coverage and the coverage percentage didn't drop.
• Testing Strategy
  • Unit tests
  • Integration tests
  • This PR is not tested :(

[ian-shim]

lgtm, few comments

[ian-shim]

🤣

[ian-shim]

This would result in an extra ETH call for any new DisperserID it sees.
Since we're already hardcoding the only allowed disperser, does it make sense if we consider a request invalid if DisperserID is unknown (not EigenLabsDisperserID) in isAuthenticationStillValid?

[cody-littley]

	var defaultAddress gethcommon.Address
	if err != nil {
		return defaultAddress, fmt.Errorf("failed to get disperser address: %w", err)
	}
	if address == defaultAddress {
		return defaultAddress, fmt.Errorf("disperser with id %d not found", disperserID)
	}

[ian-shim]

I think this reply is for another comment in reader.

[cody-littley]

Oops, you're correct @ian-shim, wires got crossed here. 🙃

The response I intended to type here was that the code does cache this value inside this cache: keyCache *lru.Cache[uint32, *keyWithTimeout].

[ian-shim]

The case I was worried about is an exploit with sending requests with increasing disperser IDs

[cody-littley]

Ah, I see what you mean. You don't need to send increasing disperser IDs, since nothing is cached when a non-existent disperser ID is queried.

The core purpose of this caching was to reduce the latency of this RPC. The latency of an invalid request is not really that important. Even if reading the chain state is not particularly expensive, I agree that it's generally good practice to avoid doing as much as possible for invalid RPCs.

The solution in the immediate term is to simply reject any disperser ID other than 0. I've made that change.

When we eventually have multiple dispersers, we will need to add a function to the smart contract that returns a list of all currently valid disperser IDs. We can cache this list and refresh it every X seconds, and always reject any request for a disperser that is unknown. Unfortunately this change will not be backwards comparable, meaning that node operators will have a required upgrade when we enable multiple dispersers. Not the end of the world, but not much we can do to avoid it now I think (short of updating contracts again).

[cody-littley]

In my fix, I add an additional parameter to the authentication: disperserIDFilter func(uint32) bool

If a disperser ID causes this function to return false, then the authentication attempt immediately fails.

The purpose of this extra complexity (as opposed to hard coding it) is to avoid having to delete unit tests. The authenticator is more or less capable of handling multiple dispersers (when we eventually have multiple dispersers), and I wrote unit tests to cover those scenarios. Although I could delete those for slightly simpler code, I'd like to avoid having to rewrite them when we get around to decentralized dispersers.

[anupsv]

if the store chunks signing is disabled, we should probably throw a warning on the start up logs.

[cody-littley]

	var requestSigner clients.DispersalRequestSigner
	if config.DisperserStoreChunksSigningDisabled {
		logger.Warn("StoreChunks() signing is disabled")
	} else {
		requestSigner, err = clients.NewDispersalRequestSigner(
			context.Background(),
			config.AwsClientConfig.Region,
			config.AwsClientConfig.EndpointURL,
			config.DisperserKMSKeyID)
		if err != nil {
			return fmt.Errorf("failed to create request signer: %v", err)
		}
	}

[anupsv]

Let's keep this value low for the beginning.

[cody-littley]

I've set this to be one minute by default. Is that sufficient, or should we lower it further?

[jianoaix]

A slightly different structuring of it: shall we pass in an interface, not a concrete implementation?
Like we have RequestSigners interface (and passed around), but with a KMS based implementation. This leaves space for potential non-KMS (i.e. non AWS specific) options (in a decentralized scenario it may be needed).

[cody-littley]

I'm a little confused about this comment. DispersalRequestSigner is already an interface. Is the interface ok in its current form?

// DispersalRequestSigner encapsulates the logic for signing GetChunks requests.
type DispersalRequestSigner interface {
	// SignStoreChunksRequest signs a StoreChunksRequest. Does not modify the request
	// (i.e. it does not insert the signature).
	SignStoreChunksRequest(ctx context.Context, request *grpc.StoreChunksRequest) ([]byte, error)
}

[jianoaix]

Can we settle on either ID or Key? Using both is unnecessary and adds a little bit confusion.
(if this is meant to be an int, ID seems fit)

[cody-littley]

I'm happy with calling this an "ID". These are serial numbers. Eventually when we allow the community to register dispersers, we will allocate these in monotonic order via a smart contract.

Where do you see the terminology "key" being used in this context?

[cody-littley]

Ah, I think I see what you are getting at. There is a method in the chain reader that references the disperser key:

getDisperserKey(
	ctx context.Context,
	now time.Time,
	disperserID uint32) (*gethcommon.Address, error)

The disperser key and the disperser ID are actually distinct things.

• Disperser ID: a unique identifier for the disperser, a 32 bit serial number
• Disperser (public) key: the public key used to verify StoreChunks() requests from the disperser, is an eth address

The reason why the disperser's public key is not a good identifier for the disperser is that we want the capability to re-key the disperser (e.g. if we lose the key, it gets compromised, or we just want to rotate it).

[jianoaix]

Ok, seems like the “operator address" v.s. "operator ID" case.

[jianoaix]

Then why DisperserKeyToAddress is accepting a disperserID as param?

[cody-littley]

There is a map from disperser IDs (serial numbers) to disperser public keys (eth addresses). This function looks up the address given the disperser's ID. The disperser's public key needs to be registered on-chain proper to this call, since the public key is not derived from the ID. Until we decentralize dispersers, there will always be exactly one disperser ID: 0.

The reason why we decided to add this complexity now is that we wanted the ability to change the public key in case we need to rotate the disperser's keys. The disperser ID part was super simple to have, and will mean that we don't need to change this contract in the future when we move to decentralized dispersers.

[jianoaix]

Yea the context makes sense. What I mean was why DisperserKeyToAddress is not called DisperserIDToAddress, since it's accepting an ID and mapping it to address.

[ian-shim]

nit: we can update the file name as well?

[cody-littley]

Oops, forgot to rename the file. 😅 Fixed.

[ian-shim]

I think this reply is for another comment in reader.

[jianoaix]

what public key has only 32 bits?

[cody-littley]

The uint32 is the relay ID. These are serial numbers, not eth keys. Currently we have exactly one disperser, and its ID is hard coded to be uint32(0).

[jianoaix]

Can you fix the comment then?

[cody-littley]

Updated comments to clarify:

// keyCache is used to cache the public keys of dispersers. The uint32 map keys are disperser IDs. Disperser
// IDs are serial numbers, with the original EigenDA disperser assigned ID 0. The map values contain
// the public key of the disperser and the time when the local cache of the key will expire.
keyCache *lru.Cache[uint32 /* disperser ID */, *keyWithTimeout]

[jianoaix]

nit: cacheAuthenticationResult, "save" feels like it's persisting the data which it's not

[cody-littley]

renamed

[jianoaix]

I'd cache this ID to address mapping to save RPCs

[cody-littley]

This is cached (see keyCache *lru.Cache[uint32, *keyWithTimeout]). By design, we re-fetch the same key again after a timeout just in case the key was changed. But not for each RPC.

[jianoaix]

Why disabling is an option? shouldn't it be non optional?

[cody-littley]

It's enabled by default. Necessary to get things working in inabox. Inabox integration is kind of complex, so I'd like to merge this code with it disabled in the e2e test, and to enable it in a follow up PR.

[jianoaix]

This file might be better fit in api/clients

[cody-littley]

I've moved all GRPC hashing code to a new package api/hashing. There is now no longer a dependency (outside of test code) between the client and this file.

[jianoaix]

It doesn't seem to me this is a good dependency direction for api/ to depend on node/

[cody-littley]

this dependency is no longer present

[jianoaix]

lgtm

[jianoaix]

Can you fix the comment then?

[jianoaix]

Then why DisperserKeyToAddress is accepting a disperserID as param?

[ian-shim]

nit: I'd prefer to have a thin kms wrapper client and use it to interface with kms instead of directly importing aws libraries. But feel free to ignore

[cody-littley]

This class is already just a thin wrapper, although its use case specific and not general purpose. Let's discuss this and make any changes in a follow up PR.

[ian-shim]

aws related utils are under common/aws/

[cody-littley]

Moved to common/aws

[ian-shim]

The case I was worried about is an exploit with sending requests with increasing disperser IDs