Hacker News Reader

Comment by yegle | Hacker News Reader

The system is intended to be annonymous and can't have any user registration or authentication.

How can you validate when someone report they are infectious, the Diagnostic Key is indeed from a legit iOS device? If you can't validate it, this can be easily abused (attacker generate a huge list of Diagnosis Keys and upload, claiming to be infected, and causing a wave of public panic)

My understanding is that there must be some internal/proprietary API from Apple that they are using to validate this, and there's no other vendor except Apple to develop such an API to mitigate the abuse risk.

View on HN

This is misguided. As you note, the system is anonymous and can't have any registration or authentication. Moreover, an Apple or Google specific API for validation would prevent interoperability of other (future) implementations including any free and open source (ie actually verifiable) ones.

Therefore, all authentication must be done on the receiving end by deciding which data sources to trust. This should be fairly straightforward because when a healthcare provider performs testing they are in a position to collect any keys from you at the same time. They are then the ones trusted to accurately report keys, which should be fine since we already trust them both to accurately report test results and to safeguard patient privacy.

Importantly, such a decentralized design allows for cooperative framework implementations, competing app implementations, and multiple data sources. Google or Apple could run a data server, your local government could run a data server, etc. Even more interestingly, such a framework could be repurposed for other less critical uses later as a form of privacy-preserving mutually opt-in contact discovery. Non-essential use of the framework might even ensure that people keep it running all the time, so that the data is ready and waiting the next time a novel pathogen appears.

What you describe is not in conflict with the Apple/Google proposed solutions. Or rather, it (the part of reporting and aggregating on the server side) is not part of the proposed solution.

When tested positive, to which server the diagnosis keys are reported to can vary depending on the platform and app. It could be reported via a goverment approved app, or reported to Google/Apple provided server. As long as Google/Apple aggregate the diagnosis keys across multiple servers (or even multiple servers across multiple countries), we still take the full advantage of this contact tracing framework.

> What you describe is not in conflict with the Apple/Google proposed solutions.

I didn't mean to suggest that it was. Rather, I was objecting to your earlier claim that there must be an internal and proprietary Apple API used to validate diagnosis keys and that only Apple could mitigate the abuse risk.

> As long as Google/Apple aggregate the diagnosis keys across multiple servers

There's nothing that inherently requires Google or Apple involvement here (although realistically I assume they will end up providing the majority of the servers as a service). All implementations and services including the framework, any apps, and the data server can be done completely independently (if desired) and still interoperate with any Apple or Google provided implementations. That's what's so great about a decentralized system.

According to the previous announcement, we should know more about the implementation details sometime in mid-May.

They should only accept infection reports that are signed with a trust chain terminating with an Apple/Google internal CA, and sign keys provided by governments with their root CA.

Alternatively, the system could be configured to connect to the "infected keys server" run by the local government(s), as determined by the countries of the cell network the user connected to in the last 30 days.

Other protocols have suggested that uploads be governed by authorization codes provided by health-care providers. Another suggests having providers digitially sign records uploaded to the server too.

With a sufficiently large key that attack you're proposing is effectively impossible (people would notice the yottabytes or however many you need to pull it off).

Although you still do need to protect against people making false claims.

Reply on news.ycombinator.com