I hear a lot about physical kill switches that physically turn off the battery, camera and signals (gps etc) to prevent remote intrusions.

I've also heard grapheneos does something that although is not physical, still shuts down the camera, battery, and gps - to an extent above and beyond what other privacy companies do.

Even so, is grapheneos as good as having a physical kill switch to make sure no one can remote in and turn on phone including gps, camera, mic?

Please explain the pros and cons of the kill switch.

    • Edited

    CodexAG To some extent it depends on exactly what one is worried about.

    If a phone allows physically turning off the microphone except when a voice call is in progress, that protects against audio being captured when a voice call is not in progress even if the software stack on the phone is exploitable.

    But if the software stack is exploitable, then it could capture and exfiltrate in-call audio, and a hardware kill switch on the microphone would do nothing to stop that.

    GrapheneOS is highly focused on avoiding exploits of the software stack -- through a combination of careful practice, software tools (e.g., hardened malloc), and Pixel hardware features (verified boot, hardware key management, MTE... many things). To whatever extent that works, hardware kill switches would be a "defense in depth" addition rather than foundational.

    At present phones with hardware kill switches do not have strong hardware and software-stack security (or, for that matter, open firmware, something many people would view as a security and privacy win). It would be great to have everything in one device, but that is not the current situation.

    Please note that I do not speak for the GrapheneOS project.

      de0u so is it technically possible for a bad actor to remote intrude into a powered down grapheneos phone and 1) turn it on, 2) listen through the mic and 3) access gps location?

      Whereas a physical hard Killswitch would definitely prevent this when not using the phone.

        CodexAG

        A software exploit is possible. GrapheneOS adds additional hardening to AOSP to prevent exploits, but no software is impenetrable.

        Note that a mic kill switch won't block listening against a highly sophisticated attack unless it also disables speakers.

          CodexAG so is it technically possible for a bad actor to remote intrude into a powered down grapheneos phone and 1) turn it on, 2) listen through the mic and 3) access gps location?

          That depends. It seems plausible that somebody could implant malware onto a phone which would cause it to appear to be off, but remain covertly on and monitoring (How the NSA Could Bug Your Powered-Off iPhone, and How to Stop Them. It is far less clear that an uninfested phone can be remotely activated. Are there demonstrated examples of that happening?

          Meanwhile it is also possible that a phone with hardware kill switches could have a secondary microphone implanted. Or perhaps a sufficiently-clever attacker could use some non-microphone hardware to capture audio.

          Hardware kill switches are not inherently a bad thing -- they cost money, may increase the likelihood of water leaking in, etc., but by no means are they an inherent evil or definitely a mistake. However, if in practice getting hardware kill switches means giving up on other important features that increase resistance against known spyware attacks then some people may well choose phones without hardware kill switches.

            CodexAG so is it technically possible for a bad actor to remote intrude into a powered down grapheneos phone and 1) turn it on, 2) listen through the mic and 3) access gps location?

            Not in powered down, 'power on' button must be pressed mechanically.
            As mentioned here several times, Pixel exploits are very expensive and are only used in very targeted ways. None are known for Pixels with GrapheneOS. There are much simpler & cheaper options that are actually used:
            https://www.notrace.how/earsandeyes/

            p338k Disabling accelerometers and gyroscopes would be required since they act as microphones when polled at high frequency. Operating systems normally don't allow apps to freely poll them at high frequency. Existing physical kill switches for microphones don't work correctly, and the devices with them have awful security.

            CodexAG An attacker able to compromise your device gets all your data including your pictures/videos, documents, login sessions, passwords, contacts, encryption keys and everything else on your device. They can record and see everything done with the device. Kill switches don't stop any of that and don't stop them recording via the microphone when the user has it enabled to make calls, record videos, etc. or simply if they haven't turned it off. A kill switch for a microphone has an extremely narrow use case. To work properly, it has to disable access to other sensors usable as microphones. Existing implementations of this are largely incorrect and don't stop audio recording.

            Camera kill switch has the alternative of shutters or other ways of blocking the cameras instead.

            Kill switches for radios largely lack a purpose and are a solution looking for a problem. The purported purpose of these features doesn't make sense and goes against the basic logic of how security works.

            Having a secure device preventing an attacker from taking it over is certainly far better than an attacker getting absolutely everything from your device and having full control of it, except that they can't use the microphone or camera if you have them disabled, so instead they can record low quality audio via accelerometer/microphone still able to decipher speech and can wait until you turn it on for any calls, video recording, etc. They still get everything else even if you always leave it off.

            We would include a properly working audio recording kill switch on a device where we got to add a bunch of features we wanted. It would be a small frill providing a last line of defense when the device has nearly completely failed the user and gotten deeply compromised by an attacker, not a major feature with a lot of value.

              de0u Hardware kill switches which lack a proper threat model and do not accomplish the purported goals would be a bad thing just like other fake privacy and security features. A switch users believe disables audio recording which does not stop a halfway competent attacker recording speech with the device using other methods is an anti-feature. Security features should work properly or they shouldn't be included. It's better for users to know a device that's deeply exploited can be used to record audio than believing it cannot be used that way due to a faulty kill switch.

              We would like to have a proper audio recording kill switch (not simply a microphone kill switch) on a future GrapheneOS device, but it has a very narrow use case of defending against a compromised device. We wouldn't present this as a huge feature. The main benefit would be that it would help convince people to use a secure device meeting our main security requirements because they believe that it's important to them. We certainly wouldn't include any sketchy kills switches lacking any real threat model or purpose which only provide a false feeling of better security. That's not how we do things in any part of GrapheneOS.

              GrapheneOS except that they can't use the microphone or camera if you have them disabled, so instead they can record low quality audio via accelerometer/microphone still able to decipher speech and can wait until you turn it on for any calls, video recording, etc.

              So even if the phone is off and hard kill switch activated, it's still possible a bad actor could use methods outside of the speaker device to capture audio? Has this been documented being done before?

              I just want to be able to go to a location and turn the phone off so there's no way the location, signals or microphone can be activated or send out information. That's why I hoped you guys would figure out a post market way to remove the friggin battery.

              By the way, you Sir deserve a round of applause for your excellent thorough answers. I appreciate how you are non abrasive and allow the thread to continue running a healthy reasonable course, which helps attract interesting contributions.

              Thank you.

                • Edited

                CodexAG So even if the phone is off and hard kill switch activated, it's still possible a bad actor could use methods outside of the speaker device to capture audio? Has this been documented being done before?

                Speakers can easily be reused as microphones, and accelerometers and gyroscopes can detect vibrations to reconstruct sound. The hypothetical kill switch would need to disable all of them. An attacker with with the ability to bypass the software restrictions would also be capable of using other sensors.

                Below are some papers describing gyroscopes and speakers to obtain audio:

                https://crypto.stanford.edu/gyrophone/files/gyromic.pdf

                https://www.usenix.org/system/files/conference/woot17/woot17-paper-guri.pdf

                CodexAG I just want to be able to go to a location and turn the phone off so there's no way the location, signals or microphone can be activated or send out information. That's why I hoped you guys would figure out a post market way to remove the friggin battery.

                Software exploits are still possible, but you can turn off the location, microphone and other sensors. It would be nice if there were a device with comparable security to the Pixel that also had properly implemented hardware kill switches, but I know of no such device.

                I agree with @GrapheneOS that avoiding "security theater" is important.

                  17 days later
                  admin locked the discussion .