PRIVATICS-Inria
commented
4 years ago Hello @huitseeker. Yes, if the federation key is compromised, we run into problems. This is the type of detail that needs to be fixed. At the moment this is a little bit out of scope of our work.
Regarding the claim:
Finally, we note a decentralized protocol presents no similar DdoS escalation path.
It is obvious that if you assume DP3T to be deployed throughout the world, inter-operability is solved by design. The reality will be a bit more complex. The CC (country code) tag of the EBID, encrypted and only accessible to the server, is a way to avoid privacy issues while making it possible to route EBIDs to the right server. But in turn it creates other potential difficulties. Once again it depends on what assumptions you make.
huitseeker
As described in §6.2 "Server operations", any server executes two successive steps (numbered resp. 2, and 3-4) in the treatment of incoming h_A messages:
Note that this second steps is the first full validation operated on any message h_A, and as a consequence, the server routes some messages before fully checking their authenticity. We'll see later how this is a necessity of the protocol as designed.
This could allow any attacker that has compromised the federation key to then break the full forwarding mechanism, through a Distributed Denial of Service (DDoS) against a particular country amplified by the other federation members themselves. This would probably happen in spite of denial of service protections.
But what about denial of service protections?
The ROBERT protocol, by virtue of being a service with pseudonymous users deployed on a continental scale, is susceptible to DoS attacks. One usual remediation would be to proxy access to back-end servers at the network level, whereby many proxy servers are the (load-balanced) initial recipients of user traffic and rate-limit any single network source of incoming packets. External users can't address back-end servers directly.
A counter-attack is to orchestrate a distributed denial of service (DDoS), by which many sources of packets emit an overwhelming number of seemingly valid messages overall, without any single one producing so much traffic as to be rate-limited. The proxies are not overwhelmed, but route their data to the back-end services, which are.
The answer to this is an application-level proxy, which would be able to authorize further processing of incoming messages by validating (or in-validating) their contents rather than just their network meta-data.
Yet there is precious little that a such an application-level proxy can do without access to a server's secret key K_S or the identifiers id_A tied to its users. At most, the time validation listed under steps 5-6 in §6.2 can be executed sooner in the process — yet valid time stamps would be easy to falsify for an attacker.
In particular, if those servers do not have the K_S and id_A used for foreign users — something which is an explicit design goal (and a lynchpin of data sovereignty)— they must take a forwarding decision without analyzing the validity of the data. From the point of view of international forwarding, there is no such thing as message validation.
The Escalation
Assume a malicious attacker has obtained the federation key K_G. As the federation key is shared with more and more endpoints along the growth of the deployment, and no key rotation protocol has been specified for this secret, the probability of this event only grows over time.
The attacker can then generate a colossal number of distinct messages h_A with an invalid EBID_A component but a valid country code, since he created EBID_A, knows K_G, and the country codes are public (§3.1). He generates this torrent of bogus messages to all bear the code CC_T of the Target country they want to attack, and sends it through a variety of network routes to the public endpoints of other, non-T countries.
These countries will forward the messages in question to the servers of the target country T. Furthermore, it is probable that this re-direction will be privileged, meaning that the initial message recipient is able to address the servers of the target country T without going through any public-facing proxies.
Indeed, if redirects coming from inside the federation were not privileged, that message forwarding would offer little to no benefit when compared to user re-direction, by which the initial recipient server simply indicates to the user to contact another country's public endpoint, and does no further processing.
As the DdoS' internationally forwarded messages are sent directly to back-end servers without validation, and it is probably possible to find a target that has much less back-end servers on its own than there are relaying servers in the whole of the federation outside of it, those server-powered redirections overwhelm the target country's ability to process messages, while helping hide the source of the attack.¹
Possible Remediations
It seems wise to want to minimize the chance of compromise of the federation key, at least by having a strong design for its custody, including rotation. A fall-back mode that would switch to user redirection rather than forwarding in case a DdoS is observed on /any/ country's back-end from any source also seems useful. Caution should be used in enabling heavy-handed DoS remediation at the final back-end, such as lengthy source address bans. Finally, we note a decentralized protocol presents no similar DdoS escalation path.
¹: Note that even in the absence of key compromise, any federation member with the resources to DdoS another can leverage the same attack and obtain plausible deniability by claiming it is the unwitting victim of the present attack. Other federation members are therefore trusted in that sense as well.