56

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?

9
  • 63
    Is compromised hardware secure? No, it's compromised.
    – Num Lock
    Sep 28, 2020 at 5:53
  • 13
    I think that the question contains the answer. Sep 28, 2020 at 6:49
  • 30
    About your side question: "And what is the best option to communicate safely?" Leave all electronic devices at home and take a walk together. Wear a face mask while doing that.
    – Heinzi
    Sep 28, 2020 at 9:30
  • 1
    Re "best option to communicate safely" - open hardware companies/projects like Purism and Pine64, which make an effort to produce phones with as open of hardware as possible, are probably a big part of the solution. Nowadays phones without closed hardware/software are almost impossible, but laptops are increasingly becoming a reality (see the Librem laptops) and with enough demand, phones will follow.
    – mtraceur
    Sep 28, 2020 at 18:39
  • 4
    While trying to add secure messaging to our app, my team was startled to learn that in India it is common for phones to come preinstalled with code that uploads their text messages to the carriers to be sold, in exchange for discounted cell plans :( Sep 28, 2020 at 18:58

10 Answers 10

53

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:

  1. You type or say something into the phone.
  2. 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.
  3. This is then sent to the application you're using.
  4. This application then encrypts the data.
  5. This data is then sent back to the phone's firmware to send it across the network.
  6. Magic happens on the network.
  7. 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.

114

The short answer is that if the hardware is compromised, then anything you can read, it can read.

8
  • Out of curiosity what exactly is compromised hardware in the sense that doesn't all hardware need some software/firmware to work and communicate over a network?
    – northerner
    Sep 29, 2020 at 19:37
  • 3
    @northerner: "Compromised" means that the hardware contains a backdoor or vulnerability which allows an attacker to control or manipulate it in some way. If you want a more specific meaning, you have to use more specific terminology than "compromised."
    – Kevin
    Sep 29, 2020 at 19:57
  • @Kevin can you give an example of compromised hardware? My point is most hardware requires software to run so wouldn't their have to be a software component to the compromise?
    – northerner
    Oct 1, 2020 at 18:14
  • 1
    @northerner: Most examples will be in firmware rather than hardware per se (see for example the Intel Management Engine), but you could have something like an AES chip that implements the algorithm incorrectly.
    – Kevin
    Oct 1, 2020 at 19:18
  • @northerner More subtly, you could compromise the hardware RNG on a phone in such a way that it makes it much easier for someone to break your encryption. Such a change might be hard to detect.
    – Patrick M
    Nov 19, 2020 at 7:05
17

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.

6
  • 3
    In android device, you may trust OS because of its kernel source - the majority of Android users don't build their own kernel from source, they use vendor-distributed binaries. But yes, it's likely that the binaries match the source, and then you can trust that part of the binary based on your trust level in the open source. Sep 27, 2020 at 1:59
  • 7
    @PeterCordes Even if you build the kernel yourself, you'd have to trust the source code, the compiler, the operating system you compile it on, the hardware the compiler is run on.
    – Jeroen
    Sep 27, 2020 at 15:34
  • 1
    Does "SoC" mean "system on a chip" here? Sep 27, 2020 at 16:18
  • @Jeroen ... and the hardware and compiler used to compile the compiler - it indeed is turtles all the way down.
    – peterph
    Sep 29, 2020 at 15:30
  • 1
    @northerner "If you were to flash the official firmware then of course the firmware wouldn't be compromised." That is an assumption based on you trusting the phone vendor. And not just trusting them to be honest, also trusting them to be competent. The official firmware might be compromised by an external party that hacked (or bribed) your phone vendor.
    – AVee
    Sep 29, 2020 at 21:20
14

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.

3
  • 3
    Note, it's also possible that the vendor itself shipped their phones and didn't know about the compromised state. bloomberg.com/news/features/2018-10-04/… Elemental Technologies shipped compromised servers to American Military, CIA, Nasa, Apple, Amazon, and others for many many years before anyone found the chip. Sep 28, 2020 at 19:03
  • 3
    @MooingDuck My spouse worked for Elemental (now AWS Elemental) during the acquisition. The Bloomberg article turned out to be wrong, or, at least, was discounted after the DHS (USA) and the NCSC (UK) found nothing to back it up. It's too bad that Bloomberg never retracted their story... DHS Link ZDNet Link (with references)
    – bitsmack
    Sep 28, 2020 at 21:50
  • @bitsmack The point is that a hardware attack is possible. An extra chip could be added, or a rogue chip could be installed. How do you verify that a chip you puchased is genuine? There seem to be quite a worry about counterfeit components, mostly because of temp spec worries, but also for hidden spy features
    – Roland
    Nov 19, 2020 at 20:44
3

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.

4
  • 4
    Open architecture does not solve the "malicious hardware" problem.
    – schroeder
    Sep 28, 2020 at 8:43
  • 1
    (Unless you build your RISC-V computer from 74*xx TTL or 40xx CMOS chips)
    – Oskar Skog
    Sep 28, 2020 at 19:10
  • 1
    Can you explain what 'under-the-rain' is? A quick search did not give me any satisfactory results. Nov 18, 2020 at 8:47
  • I too am wondering about "under the rain", I found nothing particularly relevant when looking into it briefly. @schroeder As Oskar is suggesting, the idea of increased security from an open architecture comes from the possibility of a trusted party producing the hardware. 3D printers do nothing for me... I look forward to desktop CMOS lithography... ;) May 11, 2022 at 20:50
2

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).

2
  • "… you simply should not be using portable communications devices…" — What is your reasoning here? If the device's drive is unencrypted, absolutely, you are correct, but this also applies to non-portable devices such as a desktop. If the device's drive is properly encrypted (such as with LUKS on Linux), your only danger is if someone snatches the device from your hands while the device is currently on and unlocked. Nov 19, 2020 at 12:21
  • A "portable communications device" is vulnerable to radio interception, encryption may make the traffic un-readable but TA (Traffic Analysis) will still yield intensions/information. Dark-Fibre/Hard-Lines mitigates this risk. These are trusted/secure (Hopefully) and private channels. Anything transmitted is not.
    – Tim Seed
    Nov 20, 2020 at 14:29
2

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.

0

You could use another algorithm for your speech but that needs additional hardware. A second way is speaking is a code that only your partner understands.

Otherwise you will have no chance if you don't know if the hardware is compromised so far.

3
  • 5
    This is no better than homemade "encryption". Do not roll your own crypto.
    – Nacib Neme
    Sep 28, 2020 at 5:27
  • 2
    A second way is speaking is a code that only your partner understands. I think that's valid advice.
    – Joelty
    Sep 29, 2020 at 13:09
  • @NacibNeme This is a historically very successful technique when all other options fail. And yes, using some form of encryption that isn't known to anyone else is a valid option, especially when you can't trust the hardware. Oct 26, 2020 at 5:01
0

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:

  1. 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.

  2. 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.

2
  • All your technical examples do not prevent malicious firmware from reading the communication. Only if the malicious vector was in a subsystem (like the comm system).
    – schroeder
    Oct 26, 2020 at 1:19
  • @schroeder Yes, which I called out with:'This really comes down to how much you can trust the "isolated" device'. I did type this up in a hurry; I'll try to clean it up when I have a break in a few hours. Oct 26, 2020 at 4:58
-2

In practice, the connections inside the LAN are easy to secure (VPN, firewalls, etc.). However, connections between operators are the responsibility of many entities and countries. We cannot trust here.

1
  • 3
    This answer makes no sense and does not address the device. Your focus is entirely external to the device. And if the content is encrypted, then the external connections are not a concern.
    – schroeder
    Oct 22, 2020 at 9:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .