• General

  • What prevents attackers from reading out RAM memory

Computers are very vulnerable to so called "cold-boot attacks", which is where the attacker unplugs the RAM memory modules from the running computer and into their own device, that keeps the RAM memory modules powered, but reads out cached disk content and disk encryption keys loaded in the kernel. The problem here is that the RAM memory modules are easily removable, and won't lose their content for several seconds after losing power, thus can be moved that way, but also that they aren't encrypted in any sense.

My understanding is that on Pixel phones, the RAM memory modules are soldered on, and thus cannot be easily removed. But my understanding is also that they are still entirely unencrypted. What prevent well-invested attackers from opening up the running phone, adding some wires to "virtually" replug the RAM memory module from the phone to their own device, and then read out all cached file content and loaded disk encryption keys? Why do we not hear about attacks like this, but instead that they are exploiting vulnerabilities, which should supposedly be much harder to do?

    I know that some encryption software such as veracrypt for example, give you the option to encrypt the keys in memory, so they always remain encrypted. Not sure how they get it done. I am not certain on how GoS works.

    ryrona What prevent well-invested attackers from opening up the running phone, adding some wires to "virtually" replug the RAM memory module from the phone to their own device, and then read out all cached file content and loaded disk encryption keys?

    I think the storage encryption keys are "wrapped" keys that are held by the storage controller, i.e., not in regular DRAM. The GrapheneOS platform requirements include "Inline disk encryption acceleration with wrapped key support".

        Blastoidea No one is going to bite on this?

        The GrapheneOS community includes people around the world, in different time zones, with different sleep schedules and work obligations.

        Given that, I don't think a five-hour timeout is generally appropriate. While it is often nice to get a rapid response, it's not an entitlement.

          RAM is volatile memory, it requires constant power. If power is lost, the data is lost.
          I can't even image how this attack could work on soldered RAM, but in case of removable sticks, yes it's doable, but extremely hard. You need to freeze the sticks with liquid nitrogen, and then move them extremely quickly to a special and compatible device. It would be easier to wait for some zero-day to work around a software lock.
          Consider your threat model. If you worry about after-first-unlock attacks, put you data at rest, or use GrapheneOS's automatic put-at-rest future if not unlocked for x-hours - it's set to 18h by default. If you worry that someone will take your phone, then within 18h take it to laboratory, where it will freeze the memory AND re-solder it, then you have different kind of problems. Consider "baseball bat attacks" as well.

            DeletedUser43 For mobile devices the "special device" argument is certainly true. But for PCs its easy, no liquid nitrogen and special devices neither software needed.

                DeletedUser43 You need to freeze the sticks with liquid nitrogen, and then move them extremely quickly to a special and compatible device. It would be easier to wait for some zero-day to work around a software lock.

                Oh really, I thought it was way easier. I thought it was even standard procedure to do this for computers. I heard it takes more than 5 seconds for data loss if you just unplug it as it is without freezing, and that some memory modules may retain some data for several minutes after power loss. Tails even implemented zero-on-free on emergency shutdown because they worry data can be obtained after device power off if they didn't. But if that isn't the case, and it indeed is hard to move the memory modules without losing the data, that might explain why we aren't hearing about this more.

                DeletedUser43 Consider your threat model. If you worry about after-first-unlock attacks, put you data at rest, or use GrapheneOS's automatic put-at-rest future if not unlocked for x-hours - it's set to 18h by default.

                I do. I keep profiles with possibly sensitive data logged out at most times, and always turn the phone off completely during sleep. I have even set the phone to reboot after 8 hours. I am really glad for all these features GrapheneOS provides. We definitely need similar for computers.

                      de0u I think the storage encryption keys are "wrapped" keys that are held by the storage controller, i.e., not in regular DRAM. The GrapheneOS platform requirements include "Inline disk encryption acceleration with wrapped key support".

                      Interesting. Would be interesting if someone from the GrapheneOS team could confirm or deny that this is used by GrapheneOS, and where the raw keys are actually stored. A storage controller still sounds like it may be vulnerable for easy key extraction, but a Secure Element may not be very vulnerable to it, nor the CPU itself I guess. So in that case that in combination with the zero-on-free could actually be providing a decent level of protection already.

                        ryrona Oh really, I thought it was way easier. I thought it was even standard procedure to do this for computers. I heard it takes more than 5 seconds for data loss if you just unplug it as it is without freezing, and that some memory modules may retain some data for several minutes after power loss.

                        I can't find any good and fresh sources. Study from 2013, DDR 3 found, it's up to 1 - 1,5s with 10-15% data loss without freezing. They've also found, the smaller the production process the worse the retention.
                        https://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf

                        I'd like to add 3 important points:

                        • I still believe, if RAM is soldered, it's not feasible.
                        • Personal computers don't have to be in constant stand-by like phones to be useful, hibernation closes this attack vector and it's not that big a deal if you have fast NVME drive.
                        • it's easy to add triggers to put data at rest: enough time passed, failed login attempts, ACPI case open, etc.

                            Freezing would be pointless as you would need to heat up the chip to desolder and resolder it. The heat should also help the RAM lose any residual data quicker.

                            DeletedUser43 Doesn't memory encryption (Intel TME "Total Memory Encryption", AMD SME "Secure Memory Encryption") prevent someone from doing a cold boot attack?

                                alfred Doesn't memory encryption (Intel TME "Total Memory Encryption", AMD SME "Secure Memory Encryption") prevent someone from doing a cold boot attack?

                                It would, and performance impact is not bad: https://www.phoronix.com/review/amd-sme-genoa/5
                                The key is stored in the CPU, the question is how extractable it is - I have no idea, but I'm optimistic it's not that easy.

                                fluxcondensator What is even properly setup secure boot? I always tought secure boot is a failure in itself...

                                Secure Boot is a total failure for the closed-source, because it relied on Microsoft keeping a master key a secret - you can guess how that went. For proper Secure Boot you need a motherboard which fully supports provisioning your own keys: Lenovo, Framework laptops and Asus PC boards are all fine AFAIK. Then you sign your boot image on update locally, and not rely on Microsoft's key. I'm actually not sure how it works with Pixels and GrapheneOS. I'm guessing GrapheneOS provisions it's keys on install when the bootloader is unlocked. Then I think the binaries are signed by GrapheneOS, so we rely on them keeping it a secret - I could be totally of base here.

                                      4 days later

                                      alfred Doesn't memory encryption (Intel TME "Total Memory Encryption", AMD SME "Secure Memory Encryption") prevent someone from doing a cold boot attack?

                                      Yes, it would, as the RAM encryption key would then live inside the CPU, and it is much harder to extract secrets from CPUs, since they are designed to be able to keep secrets.

                                      The problem is that only a handful of high-end computers even support TME or equivalent today, and as far as I know, no smartphones. But in a few years it will probably be a standard feature for computers, as it is seen as an important feature to protect cooperate secrets from laptop thieves.

                                      DeletedUser43 I'm guessing GrapheneOS provisions it's keys on install when the bootloader is unlocked.

                                      Yes. The custom verified boot key is one of the things provisioned by the flash script you run to flash GrapheneOS on the device. If a custom key is present, the bootloader will show the yellow triangle warning with the key hash during boot like we are used to, if a custom key is not present, the bootloader will use Google's built-in key instead that only work with stock OS.

                                      DeletedUser43 Then I think the binaries are signed by GrapheneOS, so we rely on them keeping it a secret

                                      Yes, we rely on GrapheneOS project keeping the private keys a secret, and on them not signing any malicious releases. If the key would leak, GrapheneOS can just push out an update that will ask everyone to reinstall GrapheneOS with some new non-leaked signing keys. It is much harder to do something similar for Secure Boot on PC computers, as all motherboard vendors would have to issue BIOS updates with the leaked keys revoked and new ones added, and then get all users to manually install the BIOS update, so if a key leak, most computers will probably be left vulnerable. But GrapheneOS users are already used to flashing GrapheneOS, so the problem would not be as big.