We do not consider solutions that require alert sources to trust the repository with protecting privacy of the reported data. In the context of completely open public repositories, as opposed to trusted services such as DeepSight [32] and DShield [34], such solutions are both impractical (a commercial enterprise is unlikely to trust an open repository to be careful with business secrets) and dangerous for the repository operator, as she may be exposed to legal liability if the repository is attacked and private alert data compromised.
We also rule out solutions that require sharing of secret keys between sensors. An obvious solution might involve encrypting sensitive data with a common key to enable alert comparison by infrastructure participants, while hiding the data from a casual observer. This approach may solve the corrupt repository problem, but it is vulnerable if the attacker signs up as a participant, gains access to the common key, and breaks privacy of alerts generated by all other participants.
Finally, solutions that require multiple producers to collaborate and/or interact to protect a single alert are impractical in our context. Given the volume of alerts, especially when the network is under attack, the communication overhead is likely to prove prohibitive. This eliminates mechanisms based on threshold cryptography [11,14] such as proactive security [15,6], and secure multiparty computation (see section 2.3) even though they are secure if a subset of participants has been corrupted by the adversary.