The SSF specification does not require authentication of Receivers at Transmitters. Under certain conditions, this enables an attacker to get a SET for audience values of other Receivers.
Please note that this issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
In the following, we briefly summarize the relevant assumptions from our report.
There is no Receiver authentication, as the SSF specification has no requirements on authentication of the Receiver at the Transmitter.
The audience values of the Receivers are not secret and, therefore, known to the attacker. (For example, the audience value can be a domain of the Receiver, a number that the Transmitter increases for each new Receiver, or some low-entropy value that is easily guessable.)
Transmitters can distinguish between different Receivers when receiving requests to the management endpoint, e.g., by providing different URLs to each Receiver (these URLs essentially contain the audience value).
Subjects are added to a stream based on authorization tokens contained in the request to the add subject endpoint.
Detailed Description
Under this setting, the attacker can trivially get SETs for the audience value of an honest Receiver: Let u be the identifier (i.e., the audience value) of an honest Receiver r at an honest Transmitter t. Without authentication, the attacker can create a new stream at t for the audience value u, and can therefore (at a later step) receive a SET with this audience. (The attacker would potentially need to first add subjects to the stream, which can happen for subjects for which the attacker is authorized). This breaks the confidentiality property described in our report (see Section 4.3). This would be particularly problematic if, upon creating a stream for u, the Transmitter would add certain subjects that only r is authorized to access information about.
Possible Fix
One possible fix is to mandate authentication at the management API, i.e., the Transmitter would use the authenticated identity value as the audience of the SET.
The SSF specification does not require authentication of Receivers at Transmitters. Under certain conditions, this enables an attacker to get a SET for audience values of other Receivers.
Please note that this issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
In the following, we briefly summarize the relevant assumptions from our report.
Detailed Description
Under this setting, the attacker can trivially get SETs for the audience value of an honest Receiver: Let
ube the identifier (i.e., the audience value) of an honest Receiverrat an honest Transmittert. Without authentication, the attacker can create a new stream attfor the audience valueu, and can therefore (at a later step) receive a SET with this audience. (The attacker would potentially need to first add subjects to the stream, which can happen for subjects for which the attacker is authorized). This breaks the confidentiality property described in our report (see Section 4.3). This would be particularly problematic if, upon creating a stream foru, the Transmitter would add certain subjects that onlyris authorized to access information about.Possible Fix
One possible fix is to mandate authentication at the management API, i.e., the Transmitter would use the authenticated identity value as the audience of the SET.