Analysis of the WhatsApp platform and comparison with the Signal platform

(To Alessandro Fiori, Alessandro Rugolo)
30/04/20

With this article we want to present a study on the WhatsApp platform and the risks associated with it. We also tried to make a comparison with the Signal platform.

Although partial, it is still a very complex study. With this preface we present the results of the analysis in order to provide the hasty or inexperienced reader with a rough idea of ​​what has been done.

As a first step, a study was carried out on the encryption protocol used by WhatsApp. The analysis revealed that the encryption level is high enough for the average user.
For nature closed-source of the platform, the case Cambridge Analytica and the behavior of Facebook with regard to data processing, its use in a classified environment is not recommended or if the information is considered of high value (patents, trade secrets, etc.). For these areas, obviously not belonging to the "consumer" market, it is necessary that i vendor themselves can offer adequate guarantees regarding security, privacy, compliance and data processing. These guarantees, in addition to being present at a technical level, must also be regulated at a contractual level with the vendor same.

Analyzing the network and the IP addresses contacted by the application, it emerged that many malicious files, over time, contacted the platform's servers. This is due to the huge spread of the messaging app and to the fact that it is actually easy to modify the web client to convey attacks on other users.

The analysis includes an example of vulnerability, now resolved, regarding this type of modification of the web client. Comparing this with the platform Signal, WhatsApp presents a greater risk.

An additional risk, due to nature closed-source of the application, is the possible implementation of the so-called "Ghost Protocol" which consists in the presence of an invisible third-party user, who (being part of the conversation) can receive messages from all interlocutors.
In the study "Chiffrement de messagerie almost instantanée: à that protocole se vouer?"1, published by Florian Maury in 2017, it is explained that the protocol Signal it is not exactly as open as it seems and that to ensure greater user security, the ideal would be to use the protocol OMEMO.

Below is a summary comparison:

Almost instantaneous: Analyzes the quality of the encryption applied to instant messaging
Decentralization: Analyzes how decentralized the platforms under analysis are
PFS: Analyzes the effectiveness of the Perfect Forward Secrecy implementation by the analyzed Platform
repudiation: Property of a cipher that allows a user to deny that he sent a message
Identifiers: Indicates the possibility of tracing the identity of the user (for example, for Signal it is low because it uses the mobile number as an identifier.
Encryption: Indicates the quality of the cryptographic system and its implementation in the software.
Free implementations: Indicates whether Open Source implementations of the software exist
Public specifications: Indicates whether all software specifications are public and easily available.
Key management system: Indicates the reliability of the key management system, such as the exchange of keys.
Distribution: Indicates how widespread a specific software or cryptographic system applied to instant messaging is.

From the analysis of the ports used by the application WhatsApp, the use of a port was found not standard. This exposes users to possible risks both in case of network traffic control, and in case there is an active attacker, who can concentrate his efforts only on the service not standard.

The analysis also showed how easy it is to recover the keys and the message database from a device, of course this is subject to the possibility of physical access to the device.

It was found as the invitation links to groups of WhatsApp are indexed on Google, exposing users to an important risk for the confidentiality of communications.

Comparing what analyzed with the platform Signal, it has been found that Signal, given its nature open-source (with due reservations), is generally considered more robust than WhatsApp.

A real case of a request for data by a State was also taken into consideration, and it was possible to demonstrate how, precisely because of the nature open of the application, the same is again more robust than Whatsapp. It must be said, however, that few people are able to analyze and verify the entire application code, therefore the risk can be considered mitigated, but not eliminated.

It has been found that systemic threats such as the "Ghost Protocol" are more difficult to implement in the application.
The analysis of Signalinstead, it showed the presence of far fewer malicious files than WhatsApp, but this could be due to the difference in the number of active users on the respective platforms.

It has been found that, although it is more difficult, even for Signal in case of possibility of physical access to the device, there is the possibility of bypassing the security measures of modern mobile Operating Systems through a specially created software.

If use is expected in a hazardous environment, where there may be a risk of physical access to the device by outsiders, both platforms should not be used.

In conclusion, in the event that there is no risk of physical access to the device or it is expected that the opponent does not have the necessary means to use certain controls or software, we recommend using the platform Signal, for common use the use of both platforms is acceptable.

We remind everyone that all the analyzes presented are performed from the outside, i.e. without knowing the internal state of the platforms and systems. Risks related to malicious files could therefore be the result of false positives. The reasoning used to carry out this analysis is of the external "black box" type, ie without knowing the structure of the platform.
This is the scheme of reasoning used (replicable in all external black box analyzes).
Platform analysis WhatsApp and comparison with the platform Signal.

SUMMARY

Introduction
Description of the Protocol WhatsApp
Additional considerations on how WhatsApp
Analysis WhatsApp
Conclusions on the analysis of WhatsApp
Analysis Signal
Conclusion Signal analysis and comparison with WhatsApp
References

Introduction

WhatsApp it is the most used instant messaging application in the world.
This analysis serves to understand the security level of the platform, highlighting any weak points.
Since the Platform has a huge user base, a security flaw would attract more attackers than other Platforms and this could have greater repercussions on users. 
One might think that such a widespread system did not have security problems but it is not so, to cite an example, we report a vulnerability, now resolved, which allowed the reading of files or the execution of code in the victim's device:
https://www.perimeterx.com/tech-blog/2020/whatsapp-fs-read-vuln-disclosure/

WhatsApp has a client / server operating model of this type:
Client (App) → Encrypted Packet Transport → Server (Platform)

The Client is an App, consequently the analysis will take place through a method that allows you to check security on mobile devices.
The transport of data takes place in an encrypted way (end-to-end) or from the sending client to the target client, without even the platform can read the content.

Before describing the functioning of the protocol, it is necessary to study in depth the terminologies used, starting from the encryption keys.

What is meant by "keys":
A cryptographic key is information that serves to "lock" or "unlock" cryptographic functions.
Do not think of the cryptographic key as a password but as a physical key: the physical key, in order to be used, needs its lock.
In the same way, the cryptographic key allows you to "activate" the cryptographic algorithm specific to the type of key and therefore allow it to "encrypt" or "decipher" the data.
In the case of the algorithm under analysis, a key pair is generated, a public and a private one.
The public key must be distributed, while the private key must be kept by the user.
Since the public keys are available to everyone, the sender of the message encrypts the message with the public key of the recipient.
Once the message has been encrypted, only the recipient can decrypt it because only he has the private key.
This type of algorithm is called "asymmetric encryption algorithm" because, in fact, two keys are needed (public of the recipient to encrypt and private one of the recipient to decipher).
In our case we have a 128-bit type of encryption where the number of bits represents the length of the key.
The longer the key, the more difficult it will be in retrospect for an attacker to retrieve or "force" it.
For a deeper understanding of the keys and encryption algorithms used by WhatsApp, see “Reference 1 - Keys and algorithms used by WhatsApp”Present at the end of the study.
Description of the Protocol WhatsApp

Let us now turn to Description of the actual protocol, in every phase:

Registration;
Creation of an encrypted session;
Receiving a new encrypted session;
Exchange of messages;
Media transmission;
Groups;
Phone calls.

1 - Registration
When registering for the service, the Client (the App of WhatsApp) transmits to the server the public identity key (Identity key pair), the pre-signed public key (Signed Pre-Key) and a series of public keys (One-Time Pre-Keys). The server stores this series of public keys, associated with the account ID.

Although the server does not have access to the private keys, the client still has access to the private keys but as it is not open source it is not possible to ascertain the behavior of the application installed on the smartphone with respect to the private keys. This is a first element of risk.

There are risks associated with generating random keys. To generate the keys, the software (not only WhatsApp) use "random number generators", which are actually functions that generate pseudo-random numbers starting from an initial value called "seed" (seed).
If you pass the same initial seed to a random number generator, the software will always generate the same sequence of numbers (as it is not really random).
To overcome this problem, PRNG (Pseudo-Random Number Generators) use various information that is difficult to find, such as a combination of date, time, remaining disk space and device name, just to give an example.
However, there is a risk that an attacker will be able to understand how the PRNG generates the pseudo-random values, thus managing to regenerate the same keys, thus invalidating the cryptographic system.

2 - Creating an encrypted session
To communicate with another user, the client must generate an encrypted session with the other client.
Once the encrypted session is generated, the client does not reinitialize the session until the App is reinstalled.
The document2 that explains the communication protocol does not speak of reinitialization of the keys, this can generate this doubt: the initialisation of the keys occurs only at the FIRST registration?
To be clearer, the document speaks of the "registration phase".
In the next section (encrypted session) it expressly says that clients do not need to rebuild an encrypted session until the device is changed or the App is reinstalled.
Consequently, it is not clear whether the private keys are ACTUALLY regenerated upon reinstallation or device change, or are generated ONLY during the registration phase (in practice when the server sees that our phone number is not present in the User database) .
If private keys were generated only during registration, this could mean that the server is able to keep them.
To establish a session, a client requests the following public keys from the server:

Identity Key
Signed Pre-Key
One-Time Pre-Key

The server responds with data.
During registration, the client sends a series of One-Time Pre-Key.
When establishing an encrypted session, the server returns a single One-Time Pre-Key.
The server, together with the response, removes the One-Time Pre-Key returned to the client.
If there are no One-Time Pre-Keys, the server does not send the One-Time Pre-Key.
Once the public keys are received, the client can also upload its own identity key to generate a so-called "master_secret".
A "Root Key" and the related "Chain Keys" are generated from the "master_secret" (see previous section, "encrypted sessions").

3 - Receiving a new encrypted session
Once the session is created, the client can begin sending messages to the recipient.
Until the recipient replies, the sender includes the request to build a corresponding encrypted session in the message header.
For clarity, and to explain what a header is, take a postal envelope as an example.
The header is the data that allows the envelope to travel correctly to the destination such as the postal address.
The content of the envelope itself is defined as a "payload".
In our case, the header is included in the message and is not displayed by the user, while the payload is the message that the user sends to the recipient.
Once the request is received, the recipient creates a corresponding "master_secret", eliminates the "One-Time Pre-Key" used by the sender who first generated the encrypted session and calculates a "Root Key" and related "Chain Keys" from the "master_secret".

4 - Exchange of messages
Once the encrypted session is built, the exchanged messages are encrypted with AES256 and HMAC-SHA256 to guarantee their authenticity and integrity.
For each message the "Message Key" is changed (see above the types of keys used for the encrypted sessions).
The Message Key is "ephemeral", ie it is generated in such a way that it cannot be reconstructed starting from the state of the encrypted session.
The Message Key is derived from the sender's Chain Key.
At each exchange of messages, the Chain Key is also regenerated.
This guarantees the so-called "Forward Secrecy".
Forward Secrecy or Perfect Forward Secrecy (PFS) is a property that ensures that if a long-term key (such as an Identity Key) is compromised, the sessions generated by that key are still secure.

5 - Media transmission
All media and message attachments are end-to-end encrypted.
The sender sends a message generating an ephemeral AES256 key and an ephemeral HMAC-SHA256.
The sender encrypts the attachment with AES256 with a random IV and hangs at the end, an HMAC-SHA256.
The sender uploads this encrypted data in a special space.
The sender sends the recipient a normal encrypted message, containing the encryption key, the HMAC key, a SHA256 hash that represents the uploaded file and a pointer that tells the recipient where to download the encrypted file.
The recipient can then receive the file and decrypt it.
The document, on this part, does not stop in specifying how the recipient decrypts the file if the IV is random and has not been transmitted.
The document (page 6: "Transmitting Media and Other Attachments") specifically states that the attachment is encrypted with the encryption key and random IV, but the IV is not subsequently mentioned.
It would be useful for users (at least in some sensitive areas) to know the precise functioning scheme of the various functions.

6 - Groups
The first time a user writes to a group, the sender generates a 32 byte chain key.
The sender generates a pair of Curve25519 Signature Keys.
The sender combines the 32 byte Chain Key with the public Signature Key, in a "Sender Key" type message.
The "Sender Key" is encrypted and distributed individually to each member of the group.
For all subsequent messages, the sender calculates the Message Key from the Chain Key and updates the Chain Key.
The sender encrypts the message with AES256.
The sender "marks" the message with the Signature Key.
The encrypted message is sent to the server, which distributes the message to all members of the group.
If a user leaves a group, all participants delete the Sender Key.

7 - phone calls
Voice calls and video calls are encrypted in the following way:
The caller generates a 32 byte SRTP key.
SRTP (Secure Real-Time Transport Protocol) is a protocol that defines a standard for audio and video communications in real time on the Internet, guaranteeing the security and integrity of data transport.
The SRTP key is sent to the recipient via a normal encrypted message.
The recipient can then establish an encrypted call or video call, knowing the key.

Additional considerations on how WhatsApp

There are other system behaviors that need to be taken into account: The application does not protect password-protected chat backups.

WhatsApp allows you to save backups of our conversations on the Cloud (Google Drive).
Unfortunately, Cloud backup is done in the clear3 and the function that allows you to apply a password is not yet available.
In an environment that requires high secrecy, it is not recommended to use the save backup function in the Cloud until you can protect it with a password.

Notifications of reading messages: By default, WhatsApp warns the user that a message has been read by the recipient (double blue tick).
In itself, this option may be convenient, however it is considered restrictive for privacy.
WhatsApp therefore it offers the possibility to deactivate the read receipts but the deactivation is bidirectional, i.e. both the contacts and the user will no longer receive the confirmations.
Furthermore, this option is not valid for groups, where in any case the participants continue to receive read receipts from the user.

The application does not filter the file extensions being sent: Normally WhatsApp it is also used for sending documents and files of various kinds.
However if the user chooses to attach a file, and you choose "Document", the application does not check the extensions of the allowed files.
It is therefore possible to send executable files or zip archives or, for example, applications in "APK" format, that is, installable on your phone, of dubious origin.
It is therefore advisable not to accept any exchanged files in advance and to always check their contents with the sender.

If messages are deleted, the application still displays a notification to the other party: In case a user incorrectly sends a message, once deleted WhatsApp shows the phrase "This message has been deleted" in place of the original content.
This type of behavior, apparently trivial, shows the interlocutors that a message has actually been sent.
It would be better if the elimination of the message was total for all the interlocutors.

Lack of timed messages: Its WhatsApp there is no function that allows the sending of self-destructing messages.
In some situations, it could be very useful to use a setting that allows messages to self-delete after a certain period of time set by users.

Analysis WhatsApp

Let's now pass to the actual analysis. The server is represented by the Facebook platform, which it has acquired WhatsApp, therefore it is necessary to consider the risk that Facebook may interact with the traffic generated by the application.
However, consider that the application also interacts with the underlying Operating System and that other applications can interact with WhatsApp same.
First, we analyze the status of the platform's network, to check for any malicious files that communicate with the domain.

No clear indicators of recent threats were found to communicate directly with the IP addresses of the Platform (at this point of the analysis).
The Platform, on the other hand, has multiple malicious files that communicate with the various subdomains.

Below are the Indicators detected as recent threats, which communicate directly with the Platform:
Domain: web.whatsapp.com
Hash: 183ddb9b37b549f7673ac38ec2ca15e1516655d559f20eaf63146a4030073d2d
The complete extraction of the Indicators of Compromise is performed.
Full extraction: https://otx.alienvault.com/pulse/5e35c5a4977b679705a90b1a

As you can see from the network map (the red points on the map), it is possible to detect that over time APKs (installation packages for the Android Operating System) and malicious executables have been created, it is therefore possible to deduce that there is a risk persistent that our client can interact with a malicious client.

After analyzing the current state of the network and any Indicators, you can examine the platform's data transport protocol.

WhatsAppit uses an end-to-end encryption protocol which means that any data in transit can only be viewed by the sender and the recipient.
The Platform uses end-to-end encryption by default but allows, through a setting, to view when the interlocutor's key changes.

This happens to a phone change or to a reinstallation of the application and is useful to avoid Man in the Middle, that is this function is useful to understand if the user is talking to the real interlocutor since, in case of doubt, the user can ask (obviously in person) the person concerned if he has changed the phone or reinstalled the application.
Here the detail of the communication protocol used by the platform:

https://scontent.whatsapp.net/v/t61/68135620_760356657751682_62129975288...

From this document it is possible to understand that the protocol for encrypting end-to-end data is based on that of Signal.

The Electronic Frontier Foundation (EFF), a non-profit foundation created to defend the rights and privacy of users on the network, has written an interesting document about the security of the application on Android OS, reported in this link:

https://ssd.eff.org/en/module/how-use-whatsapp-android

The study carried out by the EFF highlights some concerns regarding the privacy settings of the application. In particular, the user cannot refuse any use of the telemetry data sent by the user to the Facebook servers.

In detail, as stated by EFF, old users WhatsApp (upon its acquisition by Facebook) had a grace period to change their privacy settings to prevent Facebook from suggesting friendships or presenting targeted advertisements starting from the data collected by Whatsapp. New users do not have this possibility, ie with the use of WhatsApp the user accepts the sharing of data in full.

Although Facebook declares that the data is not shared or resold to third parties, the case does Cambridge Analytica (link: https://www.ilpost.it/2018/03/19/facebook-cambridge-analytica/) can only prove that this sharing is a systemic threat, i.e. there is a risk of data compromise, regardless of the flaws / malware / bugs present on the Platform.
EFF declares its concern with respect to the web version of the application, as it can be modified to make it malicious or interact maliciously with it, confirming what is shown on the network map.

To learn more about the web version of WhatsApp affect the security of the entire Platform, Robert Heaton in 2017 published an interesting post on his blog4 where it describes how to effectively track your contacts thanks to the manipulation of the web interface.
Again at the transport level, end-to-end encryption is useful as long as the application can be considered "trusted".
In detail, WhatsApp is a closed-source application.
This means that no one apart WhatsApp itself, can know what the application does.

However, a document is available, also linked in the protocol explanation at the beginning of this analysis, which explains in detail how WhatsApp performs encryption.
In general, if you want to be paranoid, you cannot know if the application uploads the plaintext messages to other servers. Here too it is possible to demonstrate that this is a systemic threat.

To demonstrate the threat, we can refer to the so-called "Ghost Protocol".
The "Ghost Protocol" (link: https://www.theguardian.com/uk-news/2019/may/30/apple-and-whatsapp-conde...) is a procedure that avoids "breaking" the encryption of an application, while having access to all conversations.

The protocol provides, in fact, to send "in copy" any message from a specific client to a third party, part of the conversation invisibly.

To understand the real impact of the Ghost Protocol on the secrecy of conversations, it is as if an e-mail program automatically sent to a third person, each message sent and received in "hidden copy" mode, without the user having any evidence , completely compromising the security of the information transmitted.

In the second half of 2019, the company denied entering the Ghost Protocol, despite the implementation request coming from GCHQ (the British security agency).

Despite the arm wrestling, the user cannot know for sure whether this protocol (or similar measures) are implemented within the application.

This type of threat is therefore systemic and in a classified environment, the application can be considered compromised until proven otherwise.

Continuing to talk about the transport level, we examine in depth how the application communicates.

To capture packets in transit on a real device, you can use a firewall ("NoRoot Firewall" has been used) as long as this firewall creates a "fakeVPN", ie a local VPN to the device, which redirects all traffic.

Through this, you can analyze the real behavior of the application.

(The result is shown in the screenshot)

By carrying out various tests, the same pattern can be observed.
It is possible that this pattern changes over time or is slightly different for another device.
Given the pattern, various factors can be observed:

Using a non-standard port (5222)
Communication to Facebook servers
Using an unsafe standard door (80)
Using the insecure port to an unknown server (216.58.208.142)

The 216.58.208.142 server is Google's, has the following indicators that are malicious, with which they communicate directly:

e2902cfd28362d7a0eef21e47b544a8b8a1e1a89e57a4140851af00ed1276659
aeb3d16722b438693bdb9afe901715e906f381afe31eb1df3c5fe8cafd8fbc66
3d5d3d5f1b9152da8b9d923451c2740b1e1c1123124b36b6fa62bf496154847f
b6447e14be7082e1437cad2fd5939c4c2ffc5832334a400cec6e994b35510651
a9cfdfa12a256cb9eb4b8f246b246894ffc27d2b034371efa96f1ba0bfd5762e
1010a92ebcf27c9ee2622cf361bd6638de0d9b442f9c422122e777e70c67ff05
69125f4b57aa1abe929d096417d7abefccee291f2988c00f4d36cb11c2049734
154c37eaf9c4eb19a8cec6798c68c9ea3a728d5af237bbf5f221afbe15c1c264
6b02df8d965e0ba96f9888d14c5d410660c41faafdc29586da3781c8c0ac4ac4
1c139f12997bc88aa1efb925007cb3f0c7d6255ab1b5ca1aabfe6fab4532b825
3333a2c2b1f8ec95ef01f4ca596cd443f2c1ae5d70cc3c1dbb50aa0f1740d1ad
055c2eb240a91d8f081a5499593e3ead092f5f4b2285b9b053ebe6cd05b67b12
009e6c27fb56baa09e2445539a9df547f225c22f909d0dfb6004647f13ff8cb1
0e2e40e07ebdeeff248daaf1adc7b78a03a873ca28de1bc73fbc0e64b6f4827f
6b331a27bcc06b2a7fd5060e2fc24285252ad8a4e3e7011ae774edc45b5fe2ca
5ecc6def525b09643d661958b63d7c65a9b93f6b10a27f001363b1790fe751e2
cb8bf1e4f331ea5a4b65a63c4a7c111d6677503b84e59eaff55f2ab95bd55a18
92d398b48f0ce44dc5f135653315aa80e21a8207e034038b52a3e2c235cafef8
b54a8f8d54d64ed346e04f03c027b960fda444505edeb7206b67d83482589d63
d039417cc0375f0d1106e140daa1c4a418cff02443b17ac49fc254ff5305ceba
a544e4f53e893c75514214338bcd33f5ca5a40a6d4a15e1bf8ca68a315a90d55
93db8dd78deecba7326a0c1975edf7bdc0f0bde230540bf887d169217570b741
108edb4cbd90116a725f43f1fad83cfc206303d1e66e3f6ae1d688e6ed0e5119
680dcb42f379d5be2484cd6b437d05e4fad42acfc6e32a726515b3f8aee81327
6757efaf6a6e068b6a4e346c1be0db6198c2888aa537a4f33bc60fe241286c09
9444e490c98c6a516bcaf6f81967b0c0e794f100ba616fcef33eee2264bb11d9
ff61097837d9226e6584b1ae25f5a1a164e4b168718227570025059bf0ad49e9
1b82460806a2d59f49ab82f8302191e500ff9161c5739e9697d22633d00555aa
14d1d88aa38dec7054f1a6fcd2874544640d4e4e9b5fe35b883017f228df16f9
11d85f340f1e133f8cdac2ef2710050311e18d050e7f088941944cd16eaedf23
2857d0f663bad67f930d38de439161dc205b67594f091e07b5fc9e4dd5a27454
9fc4a744fe5044d299e9385b1dbe0a317891546ee28226e0cd9bcb514cfb3ceb
0de6c92a30b63016e7fc42a2becc9f5f96ecaeed3b3440b0a53b064b0860ac24

We therefore proceed with the identification of all the Indicators.
Full extraction:
https://otx.alienvault.com/pulse/5e36395f8654862296f22c8c

As can be seen, even in this case there is a multitude of malevolent Indicators over time.
The second IP address is now analyzed: 157.240.193.50
This IP address does not have Indicators that communicate directly.
The third IP address is now analyzed: 157.240.193.55
Also this address does not present Indicators that communicate directly.

Let us now analyze the ports used.

80
443
5222

Reasoning in business environments, port 80 and 443 are common, so there is a high probability that Firewalls will not block these ports.

Unlike the two ports mentioned above, the 5222 is used by Google Talk, WhatsApp and from Jabber servers, which is a type of server used for instant messaging services.

It is very interesting to observe how active scans on this port have increased exponentially since September 2019:

https://isc.sans.edu/port.html?port=5222

The increase in scans is not directly related to WhatsApp, but it is possible to demonstrate that there is a risk in using a non-standard port.
The problem of using this port concerns a possible traffic inspection at the network level.

Knowing that port 5222 is used by these services, it is possible to scan / attach these devices specifically to the single service, concentrating the attacker's efforts on a single protocol, also reducing the effort that the attacker needs to make.

Once the transport has been analyzed, the risk in using the Platform in its original form, or through application, can be analyzed.
The application itself has 8 CVEs:

https://www.cvedetails.com/vulnerability-list/vendor_id-19851/product_id...

However, there is no direct threat, as the current version is not included in the list of known vulnerabilities. Despite this, the device ecosystem cannot be underestimated.

Mobile devices, unlike computers, have a larger attack surface due to their nature. They must be simple to use, within everyone's reach and they too present systemic threats, i.e. the Operating System is more difficult to modify / control, and usually manufacturers block Administration privileges (i.e. an account with elevated privileges, in order to launch commands that can modify the behavior of the System itself), as well as having proprietary closed-source drivers.
In addition to systemic threats, Operating Systems for mobile devices are very complex and prone to more or less serious vulnerabilities.

This is a list of Android vulnerabilities:
https://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224

This is the list of vulnerabilities in the iOS operating system:
https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49

There is therefore the possibility for a malicious app or an attacker to be able to exploit vulnerabilities to obtain privileges also on the application.

But why also focus on the device? Why the application WhatsApp save your encrypted message databases and end-to-end encryption keys directly to the device.

For this analysis, a test was performed with this tool:

https://forum.xda-developers.com/showthread.php?t=1583021

The test was successful on a completely updated device and without root privileges (administration privileges on the entire system).

The test demonstrates that keys can also be recovered through physical access to the device. This involves a total compromise of the data in transit, defeating any implementation of end-to-end encryption.

Key recovery seems to be possible too Signalwhich, however, turns out to be much more robust, in fact, for this type of operations Signal you need to use a third party program:

https://blog.elcomsoft.com/2019/08/how-to-extract-and-decrypt-signal-con...

This opens up many scenarios where communication security can be compromised.
Consider, for example, the Israeli company Cellebrite.

The company in question has produced a software, UFED, which allows to overcome any protection, even of High End devices:

https://www.cellebrite.com/en/ufed-ultimate/

This platform could also be implemented in the famous recharge "totems", ie information points present in airports and stations.

Finally, a behavioral analysis of the application carried out in the sandbox through VirusTotal is indicated, to detect suspicious "behaviors".

The analysis is public, and does not exhibit suspicious behavior. This is the link to the analysis:

https://www.virustotal.com/gui/file/4a7b1a8f5ab065978feb00fd8f90ba29f8c5...

The advice is to never connect devices to direct USB sockets, but always use the power supply with normal electrical sockets and, at the limit, take power banks.
There is a very risky behavior for users regarding the invitation link to groups.

Journalist Jordan Wildon reported via Twitter (link: https://twitter.com/JordanWildon/status/1230829082662842369) that through the function "Invite via link" the groups are indexed on Google.
This means that, through a simple "personalized" search, it is possible to enter the most disparate groups, exposing the participants to a considerable risk.
This problem has been known since 2018, and there is also a type of "dork"5 on the "exploit-db" portal:
https://www.exploit-db.com/ghdb/4753
It must be said that most of these data "exposed" by Google, are actually the result of errors of configuration of the various servers by the System Administrators.

This (image) is an example of Dork for the above groups of WhatsApp (personally performed to verify that the Dork in question was still "exploitable").

Groups are also indexed with Signal, although it can only happen with open groups.
In the case of private groups, indexing is not allowed.

It can be said that although the risk exists, with Signal the user can decide how to expose the group and, if private, can decide not to expose it.

One last, but not least, analysis concerns the terms of use and the legal notices.

The following are the doubts (not refutable given the closed-source nature of the application) that may arise by reading the terms of service of the service.

In order to take advantage of the services offered by WhatsApp, the user must accept its terms of use6 (this is necessary for any commercial service).

Reading the terms of service, you can see that:
“We are committed to providing the safety and security of WhatsApp by taking appropriate measures in the event of abusive persons, illegal activities and violations of our Terms. We prohibit the misuse of our Services, harmful behavior towards others, and violations of our Terms, Disciplines and Policies and we are committed to dealing with situations where we can provide support or protection to our community. We develop automated systems to improve our ability to detect and remove dangerous activities and people who could put our community and the safety and security of our Services at risk. If we become aware of the presence of such businesses or people, we take appropriate action by removing such businesses or people or by contacting law enforcement. We share information with other affiliated companies when we detect misuse or harmful behavior in the use of our Services. "

The fight (more than fair) to illegal activities in any case raises more than a few questions:

  • How do the aforementioned automated systems perform their function?
  • Is there a database of "keywords" or "patterns" directly within the application?
  • After the algorithm has verified the presence of potentially dangerous activities, are there any people who validate these reports and that it is therefore possible for the company to read the conversations clearly?

Another interesting point to think about is the following:

Address book. The user provides us regularly, in accordance with applicable laws, the telephone numbers of the users of WhatsApp and other contacts in the address book of your mobile device, including those of users of our Services and other contacts.

Who assures us that this information is not reused (and this question is valid for any service of this type)?
What crossings are made on the data (same thing, any service of this type can do it)?

Note now, a fundamental passage in the privacy policy:
User messages. WhatsApp does not store user messages during the normal provision of the Services. Once delivered, messages (including chats, photos, videos, voice messages, files, and shared location information) are deleted from our servers. Your messages are stored on your device. If it is not possible to deliver a message immediately (for example if the user is offline), we will store it on our servers for up to 30 days in an attempt to deliver it. If the message has not been delivered after 30 days, it will be deleted. To improve performance and deliver multimedia messages more efficiently, for example when many people share a famous photo or video, we may store that content on our servers for a longer period. We also offer end-to-end encryption for our Services, which is enabled by default, when you and the people you text with use a version of our app released after April 2, 2016. End-to-end encryption end means that users' messages are encrypted to prevent WhatsApp and third parties from reading them. Learn more about End-to-End Encryption and Businesses on WhatsApp.

This point risks calling into question the solidity of all end-to-end encryption.

In the passage “WhatsApp does not archive user messages during the normal performance of the Services ", what is meant by" normal performance "? Furthermore, quoting again: "To improve performance and deliver messages with multimedia content more efficiently, for example when many people share a famous photo or video, we could store this content on our servers for a longer period".

If multimedia content is also end-to-end encrypted, as it does WhatsApp understand that a content is shared many times?

Another interesting point is certainly the interaction between the application and the device:
Information about device and connections. WhatsApp collects device-specific and connection information when you install, access or use our Services. This includes information such as hardware model, operating system information, battery level information, signal strength, app version, browser and mobile network information, connection information, including number mobile operator, mobile operator or ISP provider, language and time zone, IP, device operation information and identifiers such as device identifiers (including unique identifiers for products offered by Facebook companies associated with same device or account).

With this, note the huge amount of very relevant information that the application collects.

Another very important step certainly concerns the collection of positioning data:
Location information. WhatsApp collects information about the device's location if the user uses location-related functions, such as when they decide to share their location with their contacts, see nearby locations or those that others have shared with them, and the like, and for diagnostic purposes. and troubleshooting, for example if the user experiences problems with the app's location functions. WhatsApp uses various technologies to determine location, including IP, GPS, Bluetooth signals, and information about nearby Wi-Fi access points, beacons and cells.

A final note concerns the application of the European Regulation regarding the processing of personal data GDPR. You can request that your data is no longer processed. Unfortunately there is no automatic procedure, but it is necessary to follow the procedure7 indicated by WhatsApp, by e-mail, motivating your will to be excluded from profiling / data processing.
Se WhatsApp should not consider the user's reason founded, he can reject the user's request, who must contact the competent bodies (also indicated on the specific page).

Conclusions on the analysis of WhatsApp 

The application puts in place a series of protection measures that are sized for the target set, that is the average user.
Analysis of the application shows that WhatsApp it is suitable for common uses, while it should not be used in a classified environment or in situations where the compromise of communication can represent a danger to the life of the user or even in contexts where the data is considered valuable, even if it is not linked to privacy (think of industrial secrecy).

Platform analysis Signal.

Signal is an application for instant messaging, exactly like WhatsApp, and has a "Client / Server" operating model of this type:
Client (App) → Encrypted Packet Transport → Server (Platform)

The working model is the same as WhatsApp and packet transport is always end-to-end. To be precise, Open Whisper Systems (non-profit group that created the application) created the protocol Signal, taken up later by WhatsApp.

The first difference that can be found is given by the type of Client and the type of Server. The platform Signal it is in fact completely Open Source, that is, it is possible to read the source code of the application and the server.

This is the application's GitHub Repository:

https://github.com/signalapp

As can be seen, both the Client code and the Server code are present.

We then proceed to the external analysis of the Platform

Indicators detected:
IP: 104.16.54.111
Hash: 01733a96208c513bdd333efe56900bf0ae03fa28955085058a957a484d599cab

Although only one Indicator has been detected, the entire network map and all the related Indicators have been extracted and appeared over time.
Full extraction: https://otx.alienvault.com/pulse/5e393d8ae94aab466d01fe91

Network map (image)

From the network map it can be understood that with respect to WhatsApp, the platform Signal over time has had far fewer cases of malicious files communicating with it.
This could, however, be a consequence of the lesser diffusion of the software.

After analyzing the Platform, we proceed with theanalysis of the transport protocol.

The Platform uses "end-to-end" encryption, ie the packets are encrypted on the sending device and decrypted on the recipient device, making it impossible for the server to read the contents.

Here you will find all the information on the protocol and the operating specifications of Signal:

https://signal.org/docs/

The Electronic Frontier Foundation, a non-profit foundation whose mission is to defend the privacy and rights of citizens online, has released notes for using Signal.

Notes for using Signal on Android Operating System:

https://ssd.eff.org/en/module/how-use-signal-android

Notes for using Signal on iOS Operating System:

https://ssd.eff.org/en/module/how-use-signal-ios

As also reported by EFF, Signal offers the user the list of contacts who also have the application installed.

To do this, the phone numbers are uploaded to the server Signal, despite being almost immediately eliminated.

A fundamental difference with WhatsApp it is given by the Open Source nature of the Project.

In detail, there is not a large corporation (like Facebook) behind the development of the application and the code is visible, which allows you to promptly check what it does and allows users not to fall into the mesh of monetization needs or of marketing of the company on duty.

Another difference with WhatsApp is given by the fact that, being Open Source, it does not present (and according to those who analyzed the source it is exactly like this) backdoors, or "service doors" that allow a Government, for example, to be able to read conversations without authorization .

To make a real comparison, with Signal (by installing it from official sources) you are sure not to come across the "Ghost Protocol", while with WhatsApp the user cannot say for sure.

In conclusion, Signal it does not present the same systemic threats it presents WhatsApp (at data transport level) given the Open Source nature of the Project.

In some areas it is preferable to use Open Source tools as it gives the possibility to the Organization or to the Community that uses a specific software to be able to analyze the code.
In principle, this condition leads to an increased probability of detecting, analyzing and solving bugs. This is usually done both by the software manufacturer and by the community itself (obviously by people who have the necessary skills) and this allows you to find bugs faster. It is not obvious, however, that these bugs are resolved faster than closed-source software and this may vary based on the people working on the project, the manufacturer's business model and the type of bug reported.

A real case is reported, where the Platform Signal received an investigation request from the State of Virginia.

https://signal.org/bigbrother/

In summary, from this request the only information that the State of Virginia has managed to obtain are the following:

  • Date and time of registration of a user to the service
  • Date of the last connection to the service

To analyze the transport level in depth, the operation of the application on a real device is analyzed.
As for WhatsApp, to capture the connections made by the application, a fakeVPN is used.

This is the result (image)
From the analysis of the pattern, the following information is obtained:

The application uses only standard ports
The application connects to Amazon servers

The analysis of IP addresses does not reveal any recent indicators.

By using port 443 only, the application is more resistant if an opponent has the possibility to inspect network traffic, making communication less detectable.

After examining the transport of data, the Client is analyzed.

The application presents 6 CVE:

https://www.cvedetails.com/vulnerability-list/vendor_id-17912/Signal.html

Despite the CVEs, there is no direct threat, as there are no vulnerabilities registered for the current version of the application.
It is stressed that the ecosystem where the application resides is not negligible.

Exactly as WhatsApp, also Signal it is prone to attacks, in case of course the attacker has physical access to the device.
In addition to the aforementioned UFED, there is a software from the ElcomSoft company, such as "Phone Viewer":

https://blog.elcomsoft.com/2019/08/how-to-extract-and-decrypt-signal-con...

Conclusion of the analysis Signal and comparison with WhatsApp

To conclude, this analysis shows that Signal it could be used in more sensitive areas, minimizing risk thanks to the Open nature of the Project and its infrastructure, which is more secure and robust compared to that of WhatsApp.

A negative note is represented by the behavior of Signal when registering a user. The platform, upon registration, reports all contacts by notification Signal present in the address book of the person who registered.

It is advisable to pay attention to this behavior of the application, in some areas certainly annoying.

The above case shows that the Platform Signal it is resistant even in the event of intervention by a State.

In contrast, for both applications there is a problem with physical access to the device.
If use is envisaged in a risky environment, where there may be physical control and access to the device, both Platforms should not be used.

In the event that there is no risk of physical access to the device or it is expected that the opponent does not have the necessary means to use certain controls or software, we certainly recommend the use of the Platform Signal.

For common use, the use of both platforms is acceptable.

1 https://www.ssi.gouv.fr/uploads/2017/10/chiffrement_messagerie_instantan...
2 https://scontent.whatsapp.net/v/t61/68135620_760356657751682_62129975288...)
3 https://faq.whatsapp.com/it/android/28000019/
4 https://robertheaton.com/2017/10/09/tracking-friends-and-strangers-using...
5 A "Google Dork" is a particular search, which exploits the power of the search engine and its indexing service. The Google engine has various search options, real "flags", which can be used to refine searches. Obviously, like any function, these flags can be used to find information or data, which normally should not be found.
6 https://www.whatsapp.com/legal/
7 https://faq.whatsapp.com/en/general/26000153/

Reference 1 - Keys and algorithms used by WhatsApp
Public keys used by WhatsApp:

Identity key pair: A long-term pair of keys, i.e. archived and stored by the application, of the Curve25519 type, generated during the installation phase.
Curve25519 is a 128-bit elliptical encryption.
An elliptical curve cryptography is a type of cryptography that uses a formula whose results, when placed on a plane, form an ellipse.

Pair of pre-signed keys (Signed Pre-Key): A medium-term pair of keys, i.e. periodically changed, of the Curve25519 type, generated by the identity key during installation.

Key Queue (One-Time Pre-Keys): A series of pairs of Curve25519 keys, generated during installation and regenerable when necessary.

Types of Keys Used by WhatsApp for encrypted sessions:

Root Key: 32 byte value, used to generate the "Chain Keys".

Chain Key: 32 byte value, used to generate the "Message Keys"

Message Key: 80 byte value, used to encrypt the content of the data exchanged on WhatsApp.
This value is used in the following way:

32 bytes for the AES-256 key

32 bytes for the HMAC-SHA256 key

16 bytes to generate the IV

Advanced Encryption Standard (AES)
It is the encryption standard currently used by the United States government.
Unlike the algorithm seen above, AES is a symmetric encryption system, that is, it uses the same key for both encryption and decryption.
AES-256 is an implementation of AES that uses 256-bit keys.
HMAC-SHA256
HMAC (Keyed-hash Message Authentication Code) is a system that uses the original message plus a key to guarantee the authenticity and integrity of the message through hashes.
A hash is a fixed-length string generated by a mathematical function capable of sequentially “mapping” any type of input data, such as a text, audio or video file.
Integrity and authenticity are guaranteed as even the slightest modification of the input data will generate a hash totally different from the original.

An example:
String to be computed: HELLO
Hash: 39F119842EBE582F049160F44BCD99F4
Now notice the difference:
String to be computed: CIaO
Hash: 8C3E82238DF7A597C99EC0B70ACC4A58
The hash string is completely different from the previous one.
This effect, also brought about by the slightest change in the original value, is called the "avalanche effect".
SHA256 indicates that in this case the HMAC is calculated through the hash algorithm "SHA256".
IV (Initialization Vector)
The initialization vector is a precise bit sequence, which allows to have different cryptographic results even with identical keys and must be known to the recipient, who otherwise cannot decipher the message.