Privacy mechanisms in internet have bothered the researchers and the users since the beginning of it. In an era where everything is done from a mobile phone, users have trust issues about reporting incidents in authorities without revealing their identity. This paper presents an architecture that helps users to report malicious events in the authorities using their smartphones, while ensuring their identity will not be exposed.
In recent years, people have become more aware of their own data's privacy, resulting from increasing data breaches in government organisations and corporations and surveillance in communications. Privacy Enhancing Technologies - PETs have been emerged towards the protection of privacy in Information and Communication Technologies (ICT). A formal de nition of PETs has been given by Borking and Raab as "a coherent system of ICT measures that protects privacy by eliminating or reducing personal data or by preventing unnecessary and/or undesired processing of personal data; all without losing the functionality of the data system" [1, p. 2].
PETs can include various methods including anonymization,
psedonymization and cryptography. According to P tzman and Hansen, "anonymity of a
subject means that the subject is not identi able within a set of subjects, the
anonymity set" and "a pseudonym is an identi er of a subject other than one of
the subject's real names" [2, p. 9, p. 21]. Finally, cryptology refers to techniques
for communicating securely in the presence of adversaries [
Privacy can be applied in many everyday communications like e-mail, instant
messages and Internet browsing. Even in deep learning, researchers have applied
techniques to protect user data [
Copyright c 2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
Crime and incident reporting constitutes an important situation that requires
privacy. People tend not to report crimes, as they are afraid of their identity
being somehow exposed to the criminal. Similarly, they prefer only to report the
incident without having to testify to the law enforcing o cers [
To this end, we propose a solution that allows anonymous incident reporting
through an onion network, like Tor [
An implementation of the proposed solution has been designed in DESMOS
project for smart and inter-connected cities [
The rest of the paper is organized as follows: In Section 2, notable PETs are reviewed. Section 3 describes and analyzes a solution for private incident reporting. Finally, Section 4, includes the discussion for the proposed system. 2
While there have been almost 30 years since Internet's "Hello World" [
The rst research in PETs was done by Chaum in 1981. He described the
"mix" node; a server that hides the correspondences between its input and
output messages in a cryptographically strong way [
In the early 1990s, the rise of the Internet resulted in the increased need to protect the content and the sender of e-mail messages. Mail servers designed to send e-mail messages without identifying the sender { known as remailers { started to appear in large scale. The remailers have been further classi ed in two types, (i) the pseudonymous and (ii) the anonymous.
In the rst type, the server sends the message with the sender's address
replaced by a "pseudoaddress". This allows the recipient to reply to the message
through the remailer. Penet remailer, by Johan "Julf" Helsingius, was one of
the most known psedonymous remailers which operated in Finland from 1993 to
1996 [
Anonymous remailers on the other hand, remove any information that can
lead back to the sender, and then forward the e-mail to the recipient { Type I (or
Cypherpunk) remailers. They were developed by Eric Hughes and Hal Finney
[
Type II (or Mixmaster) remailers were developed by Lance Cottrell in order
to address the tra c analysis issue in Type I remailers [
In 2003, Danezis et al., proposed the Type III (or Mixminion remailers) [
Based on the mix networks, Syverson et al., presented the onion routing in
1997 [
An architecture for reporting incidents while preserving users' privacy was
proposed in 2017 [
The proposed anonymization network ensures user's anonymity on sending
reports. This solution is based on the Tor project and on \Ensuring Anonymity
For Incident Reporting by Utilizing Onion Networks" [
The anonymization network consists of ve di erent parts: (i) Client, (ii) Directory Server, (iii) Relays Manager, (iv) Trusted Node and (v) Trusted Receiver which is the nal destination of the message.
The Client is the application that the user is going to use to make an anonymized report.
The Directory Server maintains a list of all nodes in the network and their
status. Also, it acts as a registration endpoint for each new node in the network.
The Trusted Node is a service, hosted by a trusted governance mechanism,
that runs software which handles the packets. In speci c, the Trust Node is
capable of:
receiving packets from other nodes
receiving packets from end users
decrypting a packet
forwarding packets to other nodes or to the endpoint
informing the \Directory Server" for its creation
creating unique keys using Di e-Hellman [
Finally, the Trusted Receiver is the endpoint of the network. The endpoints are in some way static because they're limited to governance mechanisms.
Figure 1 depicts the architecture of the anonymization network along with the communication relationships among its parts. The Client communicates only with the Trusted Nodes and the Directory Server, but never directly with a Trusted Receiver (e.g. the police). The Client, also, communicates with the Directory Server to retrieve a list of all active nodes, creating the path to the endpoint. The path is a set of three di erent and randomly selected Trusted Nodes. Moreover, before the Client sends a report, it negotiates the secret keys with each di erent node. Each Trusted Node communicates with the Directory Server, notifying both its creation and destruction. Finally, the Relay Manager manages all the Trusted Nodes in the cluster.
To secure the communication in the network, all of its parts use TLS v1.2, to ensure the con dentiality and integrity of communication. Also, the client creates unique secret keys with each node. Cryptography is used in the transport layer (TLS) and in the application layer (AES). The two parts of the network negotiate the private key (application layer) in a secure way using the Di eHellman protocol. To send a report, the client chooses randomly three di erent nodes of the network. Using the negotiated keys, the client encrypts the nal packet three times (Figure 2). These keys are used only for one report. After sending the report, the keys are destroyed in both the client and the node.
Finally, random delay is inserted between packet transmission to prevent tra canalysis attacks.
The nal packet is a 3-layer packet {one layer for each node{ encrypted with the appropriate key. Each node receives the packet and decrypts it with the key that has exchanged with the client. Inside each packet is information about the next destination, the data that the node has to forward, the type of the packet, a unique id related to the private key, and a ag of exit node if the node is the last one that has to provide the packet to Trusted Destination. The packets are transferred using the JSON format. JSON was preferred over other data interchange formats (e.g., XML) because it is more lightweight and it is easier to integrate more Trusted Receivers, since it is widely used.
Figure 3 depicts the communication ow in the anonymization network for sending a report. After the random creation of the network path, the client has to negotiate the private keys with each Trusted Node of the network. The communication ow begins between the client and the rst node. Using Di eHellman key exchange, they negotiate a unique private key. Afterwards, the client communicates with the next node to create a unique key, while the packet is a 2-layer packet encrypted with the secret key negotiated with the rst node. In the same way, the client negotiates a key with the third node, by sending a 3-layer packet encrypted this time with the secret keys of the rst and the second node.
By collecting three secret keys, the client is ready to send the report. It creates a 3-layer packet, three times encrypted with the secret keys negotiated with the aforementioned nodes. The root of this packet is the user's report. When the packet is created, the client sends it to the rst node. The rst node decrypts the packet with the appropriate key, reads the route information and forwards the 2-layer packet to the next node. The same procedure is followed from the second node of the path. Finally, the third node, decrypts the packet and, using the information inside, sends the packet to the appropriate destination. Due to unidirectional communication and the lack of nodes recording route information, communication for the destination to the client is not possible. 4
The paper presented an approach for private and safe reporting of incidents in various authorities. The presented solution makes it almost impossible for third parties to read or tamper the report, except from the receiver the report is sent to. An attacker would have to decrypt three layers of encrypted data in order to gain access. Time correlation is avoided due to the time delay that each node randomly adds between the arrival and the departure of each packet. The receiver of the report is not able to nd its original sender, since it was not send by the sender, but by three irrelevant nodes instead.
In contrast with the solution in [
One limitation is that in the proposed architecture, it is not possible to send replies to the sender, as nodes don't know how to get back to the sender. Moreover, multiple nodes are required to function properly, otherwise, the route will be always the same, making it easy to nd the original sender
This research has been co- nanced by the European Union and Greek national funds through the Operational Program Competitiveness, Entrepreneurship and Innovation, under the call RESEARCH-CREATE-INNOVATE (project code: T1EDK-03487).