Was recently introduced to the concept of security rings. I was a bit alarmed when learning about ring -3. While there's debate about nomenclature, I'm curious about the existence of something similar on mobile devices. I read that ARM processors do not have a separate soc like most x86 do.

Ultimately I'm wondering if someone could shed some light on how much of a backdoor this creates, especially when it comes to mobile devices (our pixels) and if GrapheneOS does anything about it.

I spoke to a lead developer on the Microsoft Defender team that introduced me to it. He seemed pretty convinced that it was a collaboration between big government and companies to always have an accessible hardware backdoor available to them.

    ARM processors indeed do not have a SoC like x86, that I know of. Mobile phones, however, have an equally, if not moreso, dangerous concept. A phone has three processors: the CPU, which is what everyone is already familiar with, the baseband, which is the processor that handles carrier communication (i.e. SMS, calls, data, etc.), and the SIM. The SIM is a computer, albeit a small one, and both it and the baseband are "under" the CPU and OS completely. They communicate with the carrier and each other, are encrypted, and currently they are just as much a black box as ME, except it certainly communicates to cell towers via encrypted channels.

    This is a good example, albeit outdated, of how powerful the SIM/baseband is. It theoretically has full control, a benefit of being "under" the OS, and if hacks like this happened again (or carrier/government malpractice), there would be similar capabilities, and likely more.

    Now, please don't misinterpret this as some boogie monster under the bed. "Nobody knows" means exactly what it says, and I'm not insinuating anything. It's simply a black box. You should develop your own threat model and decide whether this is a risk for you. Also, while everything I've said is correct to the best of my knowledge, I haven't double-checked, so believe it at your own risk. I will happily edit if anyone corrects me.

      GrouchyGrape

      I hadn't heard it called Ring -3 before now, although I have heard it called the Intel Management Engine (ME).

      While there's debate about nomenclature, I'm curious about the existence of something similar on mobile devices.

      You should read through this thread, particularly the posts from the official GOS account:
      https://discuss.grapheneos.org/d/10029-intel-management-engine-equivalent-on-pixels

      Ultimately I'm wondering if someone could shed some light on how much of a backdoor this creates

      A somewhat old but related article from EFF about this in the general case:
      https://www.eff.org/deeplinks/2017/05/intels-management-engine-security-hazard-and-users-need-way-disable-it

        GrouchyGrape I spoke to a lead developer on the Microsoft Defender team that introduced me to it. He seemed pretty convinced that it was a collaboration between big government and companies to always have an accessible hardware backdoo

        Do you have any source or proof? I have my doubts, that someone in this position would say something like that.

        Its easy for threads like this to descend into baseless speculation.

        There is a good overview of the issues around this in the posts zzz linked to.

        zzz You should read through this thread, particularly the posts from the official GOS account:
        https://discuss.grapheneos.org/d/10029-intel-management-engine-equivalent-on-pixels

        tldr:
        modern hardware is complex and avoiding having to place trust in the hardware manufacturer is a very hard unsolved problem.

        Pixel hardware is well designed. It gets a lot of independent hardware and software developers and researchers prodding at it because it is the reference device where many new Android hardware and software features land first

        Pixels also get first class ongoing support and any security weaknesses found will almost certainly get fixed as quickly or quicker than they would elsewhere.

          zzz I hadn't heard it called Ring -3 before now, although I have heard it called the Intel Management Engine (ME).

          Ring -3 is a reference to rings, where different rings denote different levels and priviliges---for instance, ring 0 is the kernel, ring 3 is applications, and ring -1 is hardware virtualization (since it would be under the kernel)

          xmachina ARM processors indeed do not have a SoC like x86, that I know of.

          Um... Titan M[x], TEE, QSEE. These chips are responsible, in part, for "securely storing" all of your crypto keys, and they run code that does who the heck knows what.

            secrec Um... Titan M[x], TEE, QSEE. These chips are responsible, in part, for "securely storing" all of your crypto keys

            The keys stored in titan and used in unlocking user data are only a part of what is required to decrypt the data. Other things including the users unlock PIN or pass are also critical. If you want to depend less on the Titan you should use a strong PIN or pass
            https://grapheneos.org/faq#encryption

            secrec that does who the heck knows what.

            Titan has much less attack surface than TrustZone. The Titan has very limited inputs, outputs, exposure and functionality compared to the main CPU cores. There are far greater limits to what it can do.

            All phone chipsets are proprietary. So are pretty much all laptop and PC chipsets. Using a HSM to store one of the inputs necessary to decrypt data provides clear benefits compared to doing everything on the main CPU cores.

            I refer, again, back to the posts, made by the project account here that were linked above
            https://discuss.grapheneos.org/d/10029-intel-management-engine-equivalent-on-pixels/8

              • Edited

              Carlos-Anso

              Titan has much less attack surface than TrustZone. The Titan has very limited inputs, outputs, exposure and functionality compared to the main CPU cores. There are far greater limits to what it can do.

              All phone chipsets are proprietary. So are pretty much all laptop and PC chipsets.

              Curious about a tangential thing -
              Does anyone know how the RISC-V architecture compares to the typical Intel and ARM ones discussed above? (in terms of attack surface, etc)
              https://en.m.wikipedia.org/wiki/RISC-V

              Although its not perfect, I was tickled to learn about Framework's new RISC-V laptops:

              What makes RISC-V unique is that it is an entirely open architecture, which means that anyone can extend on it and create their own processors that use it without paying a fee. RISC-V International is the collaborative organization that exists to help develop the standard and define common versions to ensure cross-compatibility of hardware and software. There are hundreds of companies now developing cores and chips around RISC-V, but most of these have been hidden away in embedded applications. The DeepComputing RISC-V Mainboard is one of the first instances of leveraging this ecosystem for the main processor in a consumer-facing product.
              [...]
              The DeepComputing RISC-V Mainboard uses a JH7110 processor from StarFive which has four U74 RISC-V cores from SiFive. SiFive is the company that developed CPU cores using the RISC-V ISA, StarFive is the processor designer that integrated those CPU cores with other peripherals, DeepComputing created a Mainboard leveraging that processor, and Framework makes laptops that can use the Mainboard. The power of an open ecosystem!

              https://frame.work/blog/introducing-a-new-risc-v-mainboard-from-deepcomputing

              Also, seconding this statement:

              Carlos-Anso modern hardware is complex and avoiding having to place trust in the hardware manufacturer is a very hard unsolved problem.

              Its worth noting that the Qubes community in desktopland also has discussions on this subject.
              Its a tough threat modelling exercise to swallow for some, sadly with only a handful of difficult solutions in the context of Qubes:
              https://forum.qubes-os.org/t/why-does-qubes-support-mostly-intel-computers-which-have-me/20647
              https://forum.qubes-os.org/t/lets-get-to-the-bottom-of-this-how-can-i-control-my-home-qubes-computer-using-intel-me/15661

              • de0u replied to this.

                zzz Does anyone know how the RISC-V architecture compares to the typical Intel and ARM ones discussed above? (in terms of attack surface, etc)

                Intel processors are fairly similar each other, at least compared to ARM processors, which vary a fair amount, but RISC-V processors vary widely, or maybe even wildly. While it is possible to say "x86 architecture" and also possible to say "RISC-V architecture", those terms aren't really parallel - saying you have a RISC-V processor predicts less than saying you have an x86 processor.

                At a very high level it could be argued that it should be easier to build a RISC-V processor without bugs than an x86, but if you want a fast RISC-V that high-level theoretical advantage may or may not be meaningful.

                Meanwhile, if device manufacturers have business reasons to embed closed-source hardware agents, they will, and it's not structurally any safer to have a RISC-V black box inside a device than it would be to have an ARM black box.

                Overall, picking one instruction set over another doesn't produce security wins to a significant extent. Good security is hard and expensive. In my opinion, Apple and Google have more of it than Microsoft or Fairphone because Apple and Google have been paying a lot of time and money.

                • zzz likes this.

                The replies and links have more than sufficiently answered my questions. Thank you everyone who took the time to respond. This thread can be marked as solved and/or closed. Again, thank you.