How safe are we when we use phone hardware from untrusted manufacturers and use end-to-end encrypted communication like Signal and Telegram? Are our conversations really safe from keyloggers or spyware? And what is the best option to communicate safely?
No, the device can see anything you can see, so if it's compromised, using encryption wouldn't protect you against that specifically.
When you use encryption, it goes something like this:
- You type or say something into the phone.
- This goes through the phone's firmware / operating system to turn you touching the screen, pressing a button, etc. into some key codes, characters, screen coordinates, etc. apps can use.
- This is then sent to the application you're using.
- This application then encrypts the data.
- This data is then sent back to the phone's firmware to send it across the network.
- Magic happens on the network.
- The other device's firmware receives it and steps 1 to 5 happen in reverse on that side.
Step 2 would be the obvious weak point as the phone can see it but there is no encryption because the app doesn't even know about the data yet. Similarly, when receiving data, it also wouldn't be encrypted as it's what you're actually hearing or seeing. This is typically where keyloggers reside.
The only ways to protect yourself from compromised hardware would be to have your data encrypted before it gets to the hardware (type encrypted data into the device, which would be a whole lot of effort to do right, or possibly use a trusted device which sends encrypted data to it, which is basically how you normally use encryption to protect yourself from the compromised internet) or to just not use that hardware.
You have to put some level of trust somewhere in the chain. There's no direct way to find out where the backdoor could be. In android device, you may trust OS because of its kernel source but drivers and firmwares are proprietary. If these were flashed in compromised state, it gives an attacker same level of privilege as the kernel.
If the OEM seems to be trusted then the chipmaker can act in bad faith like installing embedded hardware debugger which listens on embedded cables, can host a server and use NIC for internet access. Chipmakers can also install backdoor in primary bootloader which boots SoC and act as root of trust. From there secure boot flow can be compromised down to the OS.
Every SoC comes with Trusted Execution Environment (TEE) which has unrestricted access to the host OS. Compromised TEE can decrypt any secrets for the attacker that it is supposed to protect. It protects encryption key like for the Signal message store, app password, biometric data etc. As it runs outside of host OS it can install debugger in any app to listen app data in memory.
These backdoors are stealthy and unaware to the host OS but if they are not obscure enough, they can be caught.
If the phone is compromised it is possible for the attacker to hijack even encrypted communication, i.e. Telegram, Signal, WhatsApp, ... . This by itself has nothing to do with where the phone was produced, where it was sold and who is the manufacturer. And while it is not impossible that the vendor itself shipped their phones in a deliberately compromised state (i.e. with a known backdoor) it is likely that such a broadly enrolled backdoor gets more or less quickly detected. Therefore it is more likely that the phone could be compromised later due to a bug in the system, i.e. with a more targeted compromise.
I would agree with Izzy3110 to say the only way to be safe on unsafe hardware is to use your own code ('one-time pad' & 'under-the-rain' could help). That said, if the hardware is untrusted then you can't even type the message and encrypt it on the device, you have to type the already encrypted message (again see 'one-time pad').
Hardware is actually one of the biggest problems and some people are working on open architectures to fix it. Until it shows up, you could use a controlled device (no internet link) to encrypt and pass it already encrypted (through a controlled channel) to the device who sends it on.
No it is not secure.
Most Sec agencies, have very strict "out-of-sight" policies for electronic items, to try and mitigate this issue. With no-question replacement/destruction if a device has been un-seen for more than a specified period of time.
There is however another factor which is, you simply should not be using portable communications devices (Phones, Laptops, Tablets) etc to hold, store and communicate more than a specific (and often quite low) security grade (RESTRICTED, SECRET etc).
While the short answer is a quick "NO", there is some room for using a digital device to communicate securely. By today's standards, it comes down to two general options, each with their own points of vulnerability:
Use a device which is suitably isolated from any communication channel for actually decrypting/encrypting your message, and then the actual phone modem need not be trusted. This really comes down to how much you can trust the "isolated" device. A good example of this type of security (and by far the most modern) is with the Puri.sm Librem 5.
The second option involves where / how the "encryption" works. While it's not a very versatile option, it is the least dependent on the hardware you're using. Simply communicating in a format that the device doesn't understand provides a universal solution. This would likely mean using a language that isn't understood by anyone other than the parties involved, though it could be extended to use arbitrary glyphs on an in-app keyboard. Some "secure" phone lines use a version of this, wherein each packet of audio is scrambled before it enters the phone itself, and then the process is reversed on the receiving end.
For a real world example of how to send protected data over possibly compromised mobile devices, look at the Trezor, an external Bitcoin wallet. When it needs a PIN from the user, it shows the (random) position of the digits on its screen, and the user maps those positions to the button presses on the phone's screen. This way, a keylogger on the phone can't grab the PIN, because it can't view the Trezor's screen.