Analysis of Privacy Identifiers on Messaging Applications

Abstract

Currently, there has been an important increase in the amount of messaging applications that we use daily as an alternative to SMS or video communication, but the use of these applications normally surges some common concerns of how all our data is treated. Among them, if our privacy is at risk or even the level of security and technology that these applications have. One very important thing to consider if we want to improve our privacy are identifiers, it is argued that messaging applications like Signal, Telegram, WhatsApp implement end-to-end encryption, but they hardly ever protect the metadata of the messages meanwhile they rely on centralized servers. Therefore, in this project, we are going to make a deep analysis of these two last points and prove that it is viable and a good practice to implement decentralized identifiers so that our online privacy can be improved.

Chapter 1. Introduction

Today, we know that the most popular way of communication is by the use of messaging appli- cations, given the fact that more than 2.7 billion people use an application for this purpose [1]. One very important part of online privacy is the user’s identity or user’s identifiers, this usually contains personal data such as IP addresses, cookies identifiers, mac addresses, advertising IDs, account handles, and device fingerprints [2].

Today we have the most popular messaging application which is WhatsApp with more than 2 billion monthly active users [3], next we have Facebook messenger with more than 1.3 billion monthly active users [3], and it is important to emphasize that these two applications belong to the same company. There is also Telegram with more than 500 million monthly active users [3] and finally, we have Signal which according to Sensor Tower as for the end of December 2020 had more than 20 million monthly active users [4].

Nevertheless, even if there have been improvements in matter of security in these messaging applications, the improvements are not enough when talking about privacy [5]. Now, new implementations in decentralized systems as well as in new protocols offer a higher level of privacy, as mentioned in [6]. And that is why we are going to make a deep analysis of how these messaging applications are using our data, what technologies they use, what kind of implementations the have and what are some recommendations we can take to improve or online privacy

To better understand the development of this research there are some important terms and topics that we are going to talk about in a much higher level that needs to be clearly understand. End- to-end encryption is a type of communication system where is intended to prevent data being read, intercept or secretly modified other than the true sender and recipient [2]. Symmetric cryptography is a type of encryption where only one key (a secret key) is used to both encrypt and decrypt information, the entities communicating via symmetric encryption must exchange the key so that it can be used in the decryption process [7]. Asymmetric cryptography is a type of encryption that uses a pair of related keys, one public key and one private key to encrypt and decrypt information [7]. A cryptographic hash function is a type of function that has certain mathematical characteristics. This function is unidirectional since given certain input data it is related to a given digest but given a digest it is extremely difficult to obtain the original message from where it was obtained [7]. Finally, we have the server-side encryption, which is the encryption of data at its destination by the application or service that receives it [5].

Chapter 2.
State of the Art

There are currently two main different ways to separate the privacy analysis of the most im- portant messaging application, the first one is open source-based applications which Signal and Telegram belong to, this allows us to make a deep analysis into the source code and see ex- actly how is implemented [8], for the other hand we also have close source applications which WhatsApp belongs to and because of that we cannot analyze the source code, but we can use diagnostic tools like Wireshark and Zanti to manage, capture and see what packages are share and what information we can collect [8]. Finally, we are going to see how the identifiers have an important role in matter of privacy as they are related to the metadata of the messages that are sent through the previous messaging applications mentioned [2].

Harry Halpin has developed a method that can use a decentralized PKI to create a decentral- ized identity layer on top of the Signal protocol. This technique makes the user’s identity more private by keeping it hidden in the server [6] as mentioned in his research it takes into account the cloud as an adversarial environment and allows the rights of ordinary people to be exercised securely over their identity without sacrificing the availability and reliability of cloud environ- ments [6]. Another important part of this research is the federated identity where Halpin says that currently, identity is the most valuable part of a user’s life and as such is naturally federated between different aspects of life. To build a federated identity that can work in terms of actual deployment, we should build on top of existing standards but make them privacy-enhanced with the minimal possible changes [6]. Once we have a privacy-preserving identity system the next step is to connect this system to a private key material to fulfill our main use-case such as access control over data without falling into the trap of trying to assign “one key per user” via a centralized authority [6].

Lastly, one advantage of the cloud is massive machine-learning, where Halpin proposes a tech- nique for allowing privacy-enhanced data aggregation over identities and messages, this is very useful to delete our online fingerprints and makes it harder for advertisers to track our online behavior [6].

Also, Samiran Bag et al. proposed a privacy-aware decentralized reputation system, that even if the main focus is not a messaging application, the protocol operations are performed in a de- centralized and privacy-preserving manner, where they created PrivRep, a novel decentralized reputation aggregation system that implements cryptograms and non-interactive zero-knowledge proofs (NIZK) to guarantee privacy across the identity [9]. Now as Samiran says in his research, in electronic marketplaces, the reputation systems are the centralized ones, where all the data regarding the rating history of the user is held by the central system. This is the normal practice that is being used in popular reputation systems (Amazon, eBay, Airbnb, uber, etc.). On the other hand, in P2P network the reputation systems can be distributed where user ratings are retained within the peers and used on-demand upon request from other peers [10], as we can see in the next table:

This was achieved by implementing a secure multiparty computation which enables compu- tation of a mathematical function over inputs from multiple data providers, in a secure and privacy-preserving way as well as cryptographic building blocks that when all the registered users in the system have generated and published their public keys on the public bulletin board (PBB), the encryption key (restructured key) of the user is computed as follows:

The computation of Yi as above ensures that:

Equation 1 ensures that Yi Ski can be used as a randomizer for computing the secret feedbacks. This property is crucial to the design of the Priv Rep system [10]. Saad Ali Alfadhli et al. em- ploys a combination of physically unclonable functions and onetime dynamic pseudo-identities as authentication factors. Furthermore, it eliminates the heavy dependency on the system key by decentralizing the wide precinct of the certificate authority into regional domains and achieves robust control of domains keys, all of this is done to guarantee vehicles authentication, the integrity of messages exchanged, and privacy-preserving in vehicular ad hoc network (VANET) [10]. As Saad Ali mentions in his research, two principal factors were crucial in the development of the research, the first one is the implementation of a physically unclonable function where Ali says that a PUF is a one-way unique digital fingerprint, based on challenge-response char- acteristics. It is an IC that accepts a challenge C, which is a string of bits. Based on the C and its physical characteristics, it obtains a unique string of bits called a response R and it can be represented as follows: R = PUF(C). The term ”physically unclonable” refers to the physical interpretation that it is not possible to make a physical clone of a PUF.1) They give the same response to the same entered challenge with a high probability, irrespective of how many times it may be entered. 1. 2) The same challenge will give a different response result with a high probability if it is used as input for different PUF [9]. And the second one is the implementation of a has function where h(.) is an algorithm that encodes messages into a fixed digits digital signature, such that it is infeasible to derive the original message from the encoded digits and that it can satisfy the following: 1. For any length of the input message, h(.) generates fixed- length encoded digits. 2. Generating b = h(a) from a certain a is trouble-free. On the other hand, it is infeasible to generate a = h1(b) from a certain b. 3. Given a and b, finding h(a) = h(b) can be computationally infeasible [10].

As we have presented on this chapter, by analyzing all of the previous relevant works, we can determine that Halpin’s research is one of the most relevant as he focuses on the same topic of messaging applications. However, the work of Bag and Alfadhli is remarkable and has very interesting insights that could be applied along with this research. Finally, it is very important to emphasize that a privacy analysis of the three messaging applications is crucial for the proper development of this research and help to decide which solutions will fit best.

Chapter 3.
Problem Statement

There are currently billions of people using different messaging applications around the world [1], but these applications offer different amount of privacy and security features, two main concerns are that the identity is completely left behind in the metadata of the messages as well as the companies use centralized servers, these two big concerns are very important in the matter of privacy because with these problems the IP addresses, cookies identifiers, mac addresses, advertising IDs, account handles and device fingerprints data could get exposed by hackers or get treated for marketing and publicity [2].

Therefore, we have to understand how these messaging applications works, how they are built, what different technologies they used, so we can know how our data is treated if there are any privacy concerns, and what things we can use or implement to improve our online privacy. Another important aspect to consider for this research is to understand the importance and the role that identifiers have in messaging applications, how are they treated and what proper solutions to implement along with them there are so we can take more concrete actions as users, as mentioned in the article ”Data Privacy Principles All Legal Providers Should Adopt” made by Reuters, ensuring clients data privacy is essential for responsible representation, whether a firm is working on a multi-million-dollar settlement or a small personal injury case, core data privacy principles should protect the identity of all those involved. [11]

Chapter 4.
Proposed Analysis

A proper privacy analysis of WhatsApp, Telegram, and Signal will be done to deeply understand what are the technologies being used to see what data are we able to obtain and how we are going to treat each problem, a comparative table will be made with the principal advantages and disadvantages of each application as well as a deep code review of the open-source applications to prove what parts of our privacy is being vulnerable and based on that what actions can the user take to improve his/her online privacy. We will talk about this more in the Results section (Chapter 6).

We know that every messaging application that we are analyzing have implemented end to end encryption [2] which is an important topic as a matter of security, but on the other hand, each message that we send in these applications have metadata that are not protected and can be linked to us as users by identifiers, leaving our privacy exposed and important information vulnerable such as IP addresses, cookies identifiers, mac addresses, advertising IDs, account handles and device fingerprints [2]. Some of the solutions are to decentralize completely the identifiers, implement new and more secure protocols like Signal’s that are considered the best in a matter of privacy as well as for security, and finally decentralize the PKI to create an identity layer to keep the user’s identifiers hidden in the server-side to improve the privacy level [6] but only we are going to explore this part as theoretical. There will be more to cover for this topic in the Results section (Chapter 6).

Chapter 5.
Evaluation Methodology

As we mentioned before we are going to evaluate the privacy of the messaging applications into two different groups, the open-source and the closed source. For the open-source apps, we are going to evaluate them in two different ways. The first one is that we are going to evaluate and analyze the code source directly, we are going to see the different implementations that each one has and how good or bad is to implement the security and privacy features. In the second part of this evaluation, we are going to intercept a few packaging using the developer tool Wireshark, for this purpose we are going to create a new network and connect our computer running the latest version of Wireshark (3.4.4) and a mobile phone, in this case, an iPhone Running iOS 14.5.1 with the latest versions of Telegram (7.7) and Signal (5.12.0) installed. Then we are going to generate a PSK for more precise results and for this we are going to need the passphrase and the SSID of the network that we are on, once we have de key we need to paste it in the protocol section so we can decrypt the traffic of the smartphone that we have connected and from there we can filter the results to see specific traffic and analyze what metadata we can collect.

The way that telegram was built involved a combination of the open-source community for the most part and also has closed source in some parts of the implementations [12], because of this Telegram doesn’t by default apply end to end encryption to messages, however, if the user decides to use the secret chat option that will be encrypted. Telegram toggles between cloud and secret chats to protect all kinds of users, relying on a standard encrypted cloud storage system based on server-client encryption called MTProto encryption. [12]. In addition to the end-to- end encryption, secret chats also leave no trace on Telegram servers, don’t allow forwarding, and can be sent as self-destructing messages. Secret chats are also separate from the Telegram cloud, and instead can only be accessed via the device of origin. Telegram’s secret chat option can also only be held between two people, meaning there is a lack of end-to-end encryption for group chats. And unlike Signal, Telegram doesn’t comprehensively encrypt metadata. Telegram collects your IP address, which Signal does not, and can link your phone number, contact list, and user ID back to you [12]. Furthermore, we are going to evaluate Telegram by implementing some tests with Wireshark as well as a deep code source review.

On the other hand, Signal is completely open-source meaning that we are able to make a deep analysis into the source code and see all the technologies it is using. In comparison with Telegram, Signal implements end-to-end encryption in every single conversation, it does not store or share your phone number, nor does it siphon up your contact lists [13]. Instead, it creates a one-way cryptographic hash of your number and then generates an alert on your device when a friend has joined, if the same hashed number appears in your contacts list. Another feature that Signal has, is encrypted audio, this means that all voice notes and audio calls are also end to end encrypted, so as we can tell, Signal is focused on privacy first and gives you a host of tools to manage that privacy currently making it one of the most private and secure messaging application [13]. And because it is open source we are going to evaluate the source code and make some tests with Wireshark as well.

Given the fact that we are going to work with a closed source application, we are not able to analyze the source code [8] we are going to use two different evaluation methods, the first one is the same implementation of Wireshark, we are going to intercept a few packaging using the developer tool Wireshark, for this purpose we are going to create a new network and connect our computer running the latest version of Wireshark (3.4.4) and a mobile phone, in this case, an iPhone Running iOS 14.5.1 with the latest versions of WhatsApp (2.21.90) installed. Then we are going to generate a PSK for more precise results and for this we are going to need the passphrase and the SSID of the network that we are on, once we have the key we need to paste it in the protocol section so we can decrypt the traffic of the smartphone that we have connected and from there we can filter the results to see specific traffic and analyze what metadata we can collect. And for the second part, we are going to implement a modified version of the open-source Zanti diagnostic tool, which with some changes in the framework we can use the tool for a Man in The Middle attack and see what data we are able to obtain.

On the other hand, we have WhatsApp which even if it is the most popular messaging application it does not have de most private and secure implementations of the market [2]. It was until 2016 that WhatsApp finally completed the end-to-end encryption implementation and messages are stored on your device and not in WhatsApp servers after they are delivered [14]. Unfortunately, on the private part WhatsApp is the least private among all applications, not forgetting that it changed its privacy policies to share information across Facebook and Instagram making your online information vulnerable [14] and because it is a closed source software, we are going to implement the Wireshark tests as well as the use of the modified Zanti diagnostic tool to make a man in the middle attack and see what data we are able to collect.

Chapter 6. Results

First, we are going to analyze how end-to-end encryption in secret chats works:

Some key differences that are implementing in MTProto 2.0 are that now it is using SH-256, the padding bytes are involved in the computation of msgkey, and the msgkey depends not only on the message to be encrypted but on a portion of the secret chat key as well [14]. The keys are generated using the Diffie-Hellman protocol, and when sending a request, user A executes messages.getDHConfig to obtain the Diffie-Hellman parameters: a prime p, and a high order element g.messages.getDHConfig returns configuration parameters for Diffie-Hellman key generation. Can also return a random sequence of bytes of required length:

The client is expected to check whether p is a safe 2048-bit prime (meaning that both p and (p-1)/2 are prime and that 2 elevated to 2047 ¡ p ¡ 2 elevated to2048), and that g generates a cyclic subgroup of prime order (p-1)/2, i.e., is a quadratic residue mod p. Since g is always equal to 2, 3, 4, 5, 6 or 7, this is easily done using quadratic reciprocity law, yielding a simple condition on p mod 4g — namely, p mod 8 = 7 for g = 2; p mod 3 = 2 for g = 3; no extra condition for g = 4; p mod 5 = 1 or 4 for g = 5; p mod 24 = 19 or 23 for g = 6; and p mod 7 =3, 5 or 6 for g=7. After g and p have been checked by the client, it makes sense to cache the result, to avoid repeating lengthy computations in the future [15]. Now, for accepting the request, After User B confirms the creation of a secret chat with A in the client interface, Client B also receives up-to-date configuration parameters for the Diffie-Hellman method. Thereafter, it generates a random 2048-bit number, b, using rules similar to those for a. Having received ga from the update with encryptedChatRequest, it can immediately generate the final shared key: key = (pow(ga, b) mod dhprime). If key length ¡ 256 bytes, add several leading zero bytes as padding so that the key is exactly 256 bytes long. Its fingerprint, keyfingerprint, is equal to the 64 last bits of SHA1 (key) [15]. Notice that in this particular case SHA-1 is used here even for MTProto 2.0 secret chats which is not a very positive thing given the fact that MTProto 2.0 can implement SHA-256 for a more secure practice.

A TL object of type DecryptedMessage is created and contains the message in plain text. For backward compatibility, the object must be wrapped in the constructor decryptedMessageLayer with an indication of the supporting layer (starting with 46). The resulting construct is serialized as an array of bytes using generic TL rules. The resulting array is prepended by 4 bytes containing the array length not counting these 4 bytes. The byte array is padded with 12 to 1024 random padding bytes to make its length divisible by 16 bytes. (In the older MTProto 1.0 encryption, only 0 to 15 padding bytes were used.) Message key, msgkey, is computed as the 128 middle bits of the SHA256 of the data obtained in the previous step, prepended by 32 bytes from the shared key. For MTProto 2.0, the AES key aeskey and initialization vector aesiv are computed (key is the shared key obtained during Key Generation) as follows: • msgkeylarge = SHA256 (substr (key, 88+x, 32) + plaintext + randompadding); • msgkey = substr (msgkeylarge, 8, 16); • sha256a = SHA256 (msgkey + substr (key, x, 36)); • sha256b = SHA256 (substr (key, 40+x, 36) + msgkey); • aeskey = substr (sha256a, 0, 8) + substr (sha256b, 8, 16) + substr (sha256a, 24, 8); • aesiv = substr (sha256b, 0, 8) + substr (sha256a, 8, 16) + substr (sha256b, 24, 8); For MTProto 2.0, x=0 for messages from the originator of the secret chat, x=8 for the messages in the opposite direction:

The steps above are performed in reverse order. When an encrypted message is received, you must check that msgkey is, in fact, equal to the 128 middle bits of the SHA256 hash of the decrypted message, prepended by 32 bytes taken from the shared key. If the message layer is greater than the one supported by the client, the user must be notified that the client version is out of date and prompted to update [15].

The Cloud chats (server-client encryption) has a similar implementation to the secret chats but with some changes as we can see in this setup overview:

Each plaintext message to be encrypted in MTProto always contains the following data to be checked upon decryption in order to make the system robust against known problems with the components: server salt (64-Bit), session id, message sequence number, message length, time. And given the secret chat analysis, we can determine that the end-to-end encryption is using an additional layer on top of the described above and because of that, it is a more secure implementation [15].

As we can see in the Wireshark result of a non-secret chat communication the connection made through the server is by HTTP making it more vulnerable to intercept more personal information, but interesting the metadata is still hidden.

But as we can see in the connection made in a secret chat communication the request is made through HTTPS making it more secure by adding the extra layer of privacy that we mentioned before and keeping all metadata completely hidden:

The Signal protocol can be divided into three different stages, the first one is an initial exchange of keys with the X3DH protocol. The second stage involves an asymmetric cryptography imple- mentation where the users alternate to send new ephemeral Diffie-Hellman keys in a mode with previously generated root keys that generates keychains with a direct secret location. The third stage is based on symmetric cryptography, where users do not take additional entropy, instead, it uses a key derivation function to create symmetric encryption keys [16].

The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically, the parties will use some key agreement protocol to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones. The parties also send Diffie-Hellman public values attached to their messages. The results of Diffie-Hellman calculations are mixed into the derived keys so that later keys cannot be calculated from earlier ones. These properties give some protection to earlier or later encrypted messages in case of a compromise of a party’s keys [16]. The main principle of the double ratchet algorithm is the KDF chain, which is defined as a cryptographic function that takes a secret and random KDF key and some input data and returns output data.

Before initialization, both parties must use some key agreement protocol to agree on a 32-byte shared secret key SK and Bob’s ratchet public key. These values will be used to populate Alice’s sending chain key and Bob’s root key. Bob’s chain keys and Alice’s receiving chain key will be left empty since they are populated by each party’s first DH ratchet step [16]. Once Alice and Bob have agreed on SK and Bob’s ratchet public key, Alice calls RatchetInitAlice() and Bob calls RatchetInitBob():

RatchetEncrypt() is called to encrypt messages. This function performs a symmetric-key ratchet step, then encrypts the message with the resulting message key. In addition to the message’s plaintext, it takes an AD byte sequence which is prepended to the header to form the associated data for the underlying AEAD encryption [16]:

RatchetDecrypt() is called to decrypt messages. This function does the following: 1. If the message corresponds to a skipped message key this function decrypts the message, deletes the message key, and returns. 2. Otherwise, if a new ratchet key has been received this function stores any skipped message keys from the receiving chain and performs a DH ratchet step to replace the sending and receiving chains. 3.This function then stores any skipped message keys from the current receiving chain, performs a symmetric-key ratchet step to derive the relevant message key and next chain key, and decrypts the message. If an exception is raised, then the message is discarded and changes to the state object are discarded. Otherwise, the decrypted plaintext is accepted and changes to the state object are stored [16]:

Interesting enough Signal implements very well its own protocols for privacy and encryption no matter the type of chat and multimedia that is dealing with, making all sort of information hidden and encrypted as we can see:

The initial communication is with the Signal server, but then for a matter of privacy, the requests are changed by sending the request through another DNS making it much more difficult to keep track of the data and the requests. It is also using HTTPS for secure connections and as well as secret telegram chats all the personal information is hidden and securely encrypted:

As we mentioned before WhatsApp is a closed source application, making it more difficult to analyze because we don’t have access to the source code and the documentation is quite limited for developers and users, that why we are going to use two tools the first one is Wireshark as well as a modified version of Zanti apk diagnostic tool to see if we can get any information by implementing a man in the middle attack.

Here we can see that the connection that WhatsApp makes with its servers is done through HTTPS making it more secure:

but we were able to see that one connection was made through HTTP and we were able to get some metadata as we can see here:

We were able to obtain a user agent that could get the browser that was in use, as well as the IP address exposing more personal data than it should, even if it is implementing encryption algorithms and good privacy practices, this is definitely a very concern issue for users and as we know there are more information related and linked to the user’s identifiers, such as phone number, email address, Facebook profile, among others.

As we can see in the images above a network scan was made while using WhatsApp sending and receiving messages, then when the diagnose finished it wasn’t able to obtain any requests, metadata, or passwords of the user account, as well as any vulnerability, was found.

Chapter 7. Conclusion

As we can see for all the analysis and results that we get from the previous chapters there are still many concerns related to security and privacy that needs to be treated and fixed such as metadata encryption to helped hide identifiers, end to end encryption enabled by default, and transparent reports for private companies. We analyze the three most popular messaging applications and as seen in the results Signal is the most private and secure messaging application among all, it implements the most secure encrypted algorithms, it doesn’t link any information to the users, and it is a very transparent non-profit organization that is completely open-source given more transparent tools to not only users but to developers as well. The second most private and secure application is Telegram which even if it doesn’t encrypt messages by default, it can do it by using the secret chat functionality, and even if it is not as transparent company as Signal, it also doesn’t link too much information with the user. Finally, we have WhatsApp which even if it implements good encryption algorithms it links a lot of personal information of the users and it even can link Facebook profile information with its latest privacy policies updated.

Finally, we know that a principal concern among privacy by using messaging applications are identifiers, which sometimes contain important metadata of a user and not all applications implement practices to eliminate this issue, that is why new privacy practices like decentralizing the identifiers or even rotating the identifiers should be investigated, tested and implemented in the future so it can help to improve the online user’s privacy while using this kind of messaging applications.

Bibliography

[1] Statista. Mobile messaging users worldwide. [Online] Available https://www.statista.com/statistics/483255/ number- of- mobile- messaging- users- worldwide [Accessed 19 February 2021].

[2] R. Green, n.d. What are identifiers and related factors?. [Online] Available short- url.at/aeQ09 [Accessed 19 February 2021].

[3] Statista. Most popular messaging apps. [Online] Available https://www.statista.com/statistics/258749/ most- popular- global- mobile- messenger- apps [Accessed 19 February 2021].

[4] M. Singh. Signals Brian Acton talks about exploding growth, monetization and WhatsApp data-sharing outrage. [Online] Available https://tcrn.ch/38BHusb [Accessed 19 February 2021].

[5] R. Mueller, S. Schrittwieser, P. Fruehwirt, P. Kieseberg, and E. Weippl, “Security and privacy of smartphone messaging applications,” Int J of Pervasive Comp and Comm, vol. 11, no. 2, pp. 132–150, Jun. 2015, doi: 10.1108/ijpcc-04–2015–0020

[6] H. Halpin, “Decentralizing Identity with Privacy for Secure Messaging,” presented at the ARES ’17: International Conference on Availability, Reliability and Security, Dic. 2017, doi: 10.1145/3098954.3104056.

[7] R. Aldeco, G. Galegos and L. Rodriguez, Introducci ́on a la Ciberseguridad y sus Aplica- ciones en M ́exico. Academia Mexicana De Computaci ́on, A, C., 2020.

[8] K. Oliinyk, ”Open Source VS Closed Source Software”, Himpunan Mahasiswa Sistem In- formasi ITS, 2018. [Online]. Available: https://hima.is.its.ac.id/2020/05/28/open-souce- vs-closed-source-software/. [Accessed: 18- May- 2021].

[9] S. Bag, M. A. Azad, and F. Hao, “A privacy-aware decentralized and personalized reputation system,” Computers and Security, vol. 77, pp. 514–530, Aug. 2018, doi: 10.1016/j.cose.2018.05.005.

[10] S. Alfadhli, S. Lu, K. Chen, and M. Sebai, 2020. MFSPV: A Multi- Factor Secured and Lightweight Privacy-Preserving Authentication Scheme for VANETs. IEEE Access, 8, pp.142858–142874.

[11] L. Powell, ”Data Privacy Principles All Legal Providers Should Adopt”, Legal.thomsonreuters.com, 2021. [Online]. Available: https://legal.thomsonreuters.com/en/insights/articles/data-privacy-principles. [Accessed: 31- May- 2021].

[12] ”Is Telegram secure? Here’s what you need to know about the messaging app that ri- vals WhatsApp and Signal — Business Insider, Business Insider, 2021. [Online]. Avail- able: https://businessinsider.mx/is-telegram-secure-heres-what-you-need-to-know-about- the-messaging-app-that-rivals-whatsapp-and-signal/?r=USIR=T. [Accessed: 19- May- 2021].

[13] M. Eddy, ”Signal Private Messenger Review”, PCMAG, 2021. [Online]. Available: https://www.pcmag.com/reviews/signal-private-messager. [Accessed: 19- May- 2021].

[14] ”WhatsApp Encryption Overview”, Scontent.whatsapp.net, 2020. [Online]. Available: https://scontent.whatsapp.net/v/t39.8562- 34/1222491424 698577206422752 152527586907531259n .pdf /.[Accessed : 19 − M ay − 2021].”W hatsAppEncryptionOverview”, Scontent.whatsapp.net, 2020.[Online].Available : https : //scontent.whatsapp.net/v/t39.8562 − 34/12.[Accessed : 19 − May − 2021].

[15] ”How Does Telegram’s Identity Verification Work?”, Information Security Stack Exchange, 2021. [Online]. Available: https://core.telegram.org/api/end-to-end. [Accessed: 20- May- 2021].

[16] ”The double ratchet Algorithm”, Signal.org, 2021. [Online]. Available: https://signal.org/docs/specifications/doubleratchet/. [Accessed: 21- May- 2021].

[17] ”Secure Messaging Apps Comparison. Privacy Matters”, Securemessagingapps.com, 2021. [On- line]. Available: https://www.securemessagingapps.com. [Accessed: 24- May- 2021].