FLEDGE MAC support from runAdAuction in the trusted bidding signals request

[stguav]

Proposal

Add a new field to the auctionConfig called perBuyerTrustedServerAuthenticationCode, so that

const myAuctionConfig = {
  //  ...
 'perBuyerTrustedServerAuthenticationCode': {
    'some-buyer':  {
      'authCode': <Base64String>  // with some appropriate length limit
  }
  // ...
};

The new field is passed in the trusted bidding signals request, either as part of the header or as a query parameter.

This could also be a separate special field in each buyer's perBuyerSignals. In general, it seems like it would be preferable to put all DSP data passed to SSPs in one object, so that the SSP is not required to parse buyer data in order to form and forward the data into the auctionConfig. We suggest the above approach only because it is more consistent with existing parts of the API.

Intended Use

In preparing the response to the SSP, the DSP can compute a Message Authentication Code (MAC) or digital signature of the request features that are also available in the trusted bidding signals request. Then the trusted bidding server can verify that the buyer initiated the request, either via a previously shared (symmetric) key for MACs; or via an already established public key passed in the Interest Group for digital signatures.

This allows the trusted server to establish that the request matches a recent DSP initiated auction on the publisher hostname from a browser with the same user agent within some limited time. This helps prevent adversaries from exfiltrating large and unnecessary amounts of sensitive advertiser data from the trusted server. Depending on usage of the trusted server, unauthenticated requests may additionally represent a potential threat to user privacy. For example, if the trusted bidding key is an advertiser user ID and an adversary can guess or otherwise acquire the request key, then potentially sensitive information about the users' interactions with advertiser sites could be exfiltrated from the trusted server.

In practice, some number of bits of the authCode can be used to encode a truncated timestamp and key version. The full timestamp can be used as input into the signature, and the trusted bidding server can verify that the request occurred within an appropriate amount of time, say 500ms.

Goal

The goal of this is to authenticate the trusted bidding server request. The trusted bidding server needs to return a substantial amount of potentially sensitive data to the client. It is desirable to limit the ability of adversaries to request data from the server in an exploratory (force browsing) fashion where there is no value to the DSPs, advertisers, or users.

Extensions

Ideally, we would have a nonce incorporated into the MAC, with some path for transmitting the plaintext nonce to the trusted server—this could be in the trusted bidding request as well. (The trusted server could then reject any duplicates.)

Instead, if integration with the Trust Token API is possible, then a trust token could be incorporated into the MAC and validated by the trusted server.

Privacy Considerations

Let us note that even with a long authentication code and incorporating trust tokens into the API, this proposal does not harm user privacy when the trusted server is faithful to the trust model (and indeed improves user privacy depending on how DSP's use the API); however, if the trusted server is not fully trusted, as perhaps is the case in the BYOS era, then opening additional communication channels between the ad response and the trusted bidding request may be concerning.

In the third-party trusted server era, we anticipate that the usage of this signal exclusively for request authentication would be enforceable, and without privacy concerns.

Related Issues/Concerns

• Ways to authenticate data coming from reporting events #214
• Securely Propagating Auction Signals #119
• Support for Negative Interest Group Targeting #319

Please note that suggestions in #119 and #214 are valuable, but address different threats, and require separate mitigations. (Although one could try to use similar strategies.)

[palenica]

Hi Steven,
thank you for your post. We welcome proposals to strengthen the security and trust properties of the fledge system.

Let me see if I understand the flow you have in mind.

1. client js sends a 'contextual' ad request to an ad exchange (SSP)
2. SSP sends a RTB bid request to DSP.
3. DSP sends a RTB bid response back to the SSP. Among other things, the bid response contains the authCode you are proposing
4. SSP passes the authCode to client, and includes it in the auctionConfig
5. Chrome passes the authCode in a request to the trusted bidding signals server for that buyer
6. The trusted bidding signals server validates the authCode and refuses to respond if the authCode is judged to be invalid

If this is the flow, one downside I see is that it seems to preclude parallelization, as the call to the trusted bidding signals server must wait for the contextual response.

[stguav]

Hi Martin,

The flow you describe is what I was proposing as a starting point for discussion.

Is there a more precise specification of how parallelization would work beyond #385 (comment)? I think there are some potential design options that would achieve similar goals depending on the details. For example, I think with an asymmetric encryption approach the SSP (or Chrome directly) could sign the request parameters with the DSP's public key.

[peiwenhu]

Hi Steven,

To brainstorm, what do you think about this alternative:

During daily updates, the DSP generates a signature of all the trusted bidding signal keys for the IG and stores it as another trusted bidding signal key in the IG. In the same time it pushes the signature's public key to its trusted bidding server.

During the bidding signal call, the server only serves the data if it verifies that the signature is valid.

This doesn't add the dependency on the contextual ads response.

[stguav]

Thanks for the suggestion; if I understand correctly, with the BYOS, we can largely implement this in the existing API (and we are actively working on it) by signing the key(s) during join and update events and verifying in the buyer server. Beyond BYOS, we would need some support like you are describing.

However, that is much weaker protection: it would be easy to acquire (by visiting remarketing sites) and/or share keys, or replay requests outside of any fledge auction that the DSP is participating in. By tying the request back to the DSP's response/participation, we get much stronger protection.

Note that if we are using a bidding and auction service, then the key signing approach may be sufficient since the DSP KV service can restrict responses to requests from the BuyerFrontEnd service and the data sent to the client is much more limited.