Librem 5 - final decision about kill switches

Hardware Librem 5
1

Hi, this page https://puri.sm/shop/librem-5/ says that Librem 5 will have Hardware Kill Switches for Camera, Microphone, WiFi/Bluetooth, and Baseband.

However, even gyroscope can be used to capture sound data and then extract information:
https://forums.puri.sm/t/librem-5-and-11-12-may-need-gyroscope-hardware-kill-switch/2403

And even speakers can be used to extract data from devices:
https://github.com/romanz/amodem/
https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

In this thread there is a suggestion to include kill switches in form of fancy sliders on the back of the phone:
https://forums.puri.sm/t/killswitch-design-submission-central-panel/1735
https://forums.puri.sm/uploads/default/original/1X/d1942b6a26e243129ddbb09a8306806d5e73871d.png

A) What is the final decision about which kill switches will be available on the device?

B) What is the final decision about the form of kill switches?

PS. I think that it is important to have choice which peripherals are enabled because each of them has own security/privacy risks.
Also I think that speakers are overrated nowadays - many technical people I know use Quiet mode (sound off) with vibrations in standard situations because it does not disturb others. And practically nobody uses device speakers for music because the sound quality is usually low.
There are of course exceptions and if people have speaker kill switch, they could forget to enable it after they enable the software switch. However this can be easily detected by software and users can be notified.

Thank you

@todd-weaver @zlatan-todoric @nicole.faerber @mladen

1 Like
2

Hi @miso,

I think Purism has not communicated anything regarding some more killswitches (or I might have missed it). Regardless of the design, I believe it is safe to assume there will be the three announced killswitches:

  • Camera and Microphone
  • WiFi and Bluetooth
  • Baseband

The dev board is expected next month (June 2018). There reasonably will be no hardware change past this date.

3

It looks like Librem 5 will have one additional hardware kill switch for all sensor (at least accelerometer + GPS) with software switches for greater granularity. Source: youtu.be/XVw0EhYccu4?t=53m33s

I would prefer to have choice to switch each module/sensor independently with hardware switch. Yes, this means to have like 8+ hardware kill switches. Yes, this would never work for Apple customers because Apple/Jobs has/had “user experience-first” philosophy.
But Purism has “privacy experience-first” philosophy. Usability and user experience can be always increased. It is not question of possibility, but the question - if the company has enough good engineers and enough money.

One thing cannot be achieved, however - would it be fashionable and considered as trendy? Probably not. But I do not think that security/privacy is fashionable and trendy and if it is, usually that is a sign of useless/limited security/privacy http://www.businessinsider.com/lenovo-thinkshutter-laptops-webcam-covers-2018-1.

Moreover, fashion is subjective - how many people from Purism community would think trees are cool? :slight_smile:
librem5
(this is just a concept, the actual kill switch tree do not need to be binary)

3 Likes
4

I actually think a kill switch tree like that is an awesome idea!

1 Like
5

The idea of having software controlled hardware kill switches, as @todd-weaver described it in the video @miso linked, seems flawed. The main reason why you would have kill switches for sensors (as distinct from kill switches for baseband or WiFi/Bluetooth) is because you don’t 100% trust the software running on the main CPU. Therefore, it’s nonsense to put the kill-switches under the control of the software running on the main CPU!

A hardware LED indicator isn’t going to help you if some malicious software un-kills a sensor while you’re not looking and starts eavesdropping on you.

However, what would work is to have a hybrid software/hardware approach. Add a momentary push button switch to the hardware. Holding it down would do three things:

  1. Send a signal to the CPU to trigger the display of the software-controlled kill switch UI.
  2. Illuminate the kill-switch status LEDs (which have been designed to directly reflect the actual hardware state).
  3. Allow the kill switch control output signals from the CPU to physically reach the kill-switch circuitry.

Releasing it would stop doing those things.

This means the kill switch circuitry must hold its own state (rather than relying on the CPU to continuously output the desired state). For extra security (against accidental button presses), it might be worth adding a time delay to the circuit, so that the button must be held down for a certain amount of time before events 1 and 3 happen (2 could still happen immediately).

This has suddenly become my favourite option!

With this arrangement, software can only influence the software-controlled kill-switch state when the button is held down, at which point the user should be actively observing the state LEDs and will notice any anomalous behaviour (for example if they hold down the button and enable the GPS, but the microphone LED also illuminates, then they will know that there is some misbehaving software present and can take steps to protect themself).

@nicole.faerber @ekuzmenko I wonder if this is what Todd was describing, or if it’s a new variation.

I would still like to have the three separate slide switches though.

It would be neat if the momentary push button for operating the software kill switches was integrated in to the relevant slide switch: slide to enable/disable everything, or push down for fine-grained control in software.

6

True, but I think @todd-weaver said in the video that one hardware kill switch will control all sensors (link to the sentence: https://youtu.be/XVw0EhYccu4?t=54m16s). And then software buttons can control each sensor separately. This is good enough for privacy/security, however it is not good enough for usability. So I would like to have hardware kill switch tree with reasonable groupings/subtrees for great usability.

1 Like
7

switch circuitry with memory state means uC, uC means firmware, firmware means reflashable, reflashable means could be compromised.
Hard switch is a switch with mechanical memory state. It either closes the circuit or opens it. no some nifty signals, triggers, color change, greeting message, fireworks. just that - disconnects the circuit.
On top of that (daisy chained, not parallel) one can build whatever circuitry he wants. but if circuit is mechanically open - all those software features will be powered off together with target hardware component.
This is the only option I can favour, anything else defeats the purpose.

4 Likes
8

That’s not true. No microcontroller is required. Only one bit of state is required per electronic kill switch. For the cost of a handful of logic chips and some board space, the circuit could be implemented entirely in non-programmable discrete logic using, for example, flip-flops to keep track of state.

Default the switches to the killed state after a power loss (battery removal) as a fail-safe. (Since state will be lost.)

That is a concern. It should be possible to avoid connecting the pins used for programming the µC to the main CPU, so that firmware-replacement attacks can only be conducted with physical access to the board.

But, having said that, I would still be wary of trusting a microcontroller-based solution for this particular application. I would rather it was implemented in discrete logic. A microcontroller is unnecessary extra complexity, when you consider all the functionality it contains that we wouldn’t be using. A microcontroller could crash.

Of course, a microcontroller would be cheaper and more compact, but I don’t think that’s a good trade-off.

I definitely still want at least some mechanical master kill switches. Even if the electronic switching is properly designed to eliminate attack vectors, I think it introduces a slightly heightened chance of the switch (transistor) failing short, as opposed to open, or leaking a small amount of current when it’s supposed to be open circuit. Who can say that a baseband module won’t operate on a tiny amount of current and record your location?

9

sorry but I’m not aware about single-bit non-volatile flip-flop. and to use nvram/eeprom you’d normally need uC.

10

I don’t think it needs to be non-volatile. The device will have a battery attached most of the time. The power consumption to maintain the state should be negligible in comparison to running the rest of the device. I could live with it reverting to the most locked-down state every time power is lost.

11

One of the key points of Librem 5 is that the core OS is completely open source, in that case you should be able to trust the software because you can verify it yourself. If you trust the code but don’t trust Purism, compile from source. I would be fine with a single hardware switch, but IMO you are crazy if you would like 8 easily available hardware switches on your phone.

2 Likes
12

There also is the very special case of the malware compromission. Purism advertised about it in a blog post for their laptops:

For most vendors you would focus only on software protections against spying because that’s your only option. Fortunately we can go one step further because we also build privacy protections into the hardware itself in the form of kill switches. Purism devices include hardware switches that allow you to cut power to radio hardware (WiFi) and to the webcam and microphone. Unlike a software hot key, these hardware switches disconnect power from the hardware so it can’t be bypassed by malicious software

In my understanding, the “master killswitch + software panel” would not cover this case

13

But why? The most important thing is to have privacy/security. Then it is about usability. The best usability with the best privacy/security is to have 8+ hardware kill switches (which unplug the circuit) in tree structure or some groups as proposed above in this thread. This way we could disable or enable multiple internal sensors at once.

1 Like
14

If the battery is built in, there MUST be a hardware switch for it.

1 Like
15

Hi…i am a new user here. As per my experience you would have kill switches for sensorsis because you don’t 100% trust the software running on the main CPU. Therefore, it’s nonsense to put the kill-switches under the control of the software running on the main CPU!
A hardware LED indicator isn’t going to help you if some malicious software un-kills a sensor while you’re not looking and starts eavesdropping on you.

EDIT: removed unrelated link

17

This is one of the primary tenants of FOSS. Being able to 100% trust the software you are running.

18

While you might well trust the software that you put on the device, someone else could have installed something which is absolutely not trustworthy. No system is completely bug-free, and bugs have a nasty habit of getting exploited by evil people to do unpleasant things. Hardware killswitches help to mitigate that issue.

1 Like
19

hello All.

it’s too late for the final decision so the following proposal will be written FFU:

  • instead of switches consider to provide a holes in the case with 2 contacts inside allowing to break the contact with the small piece of plastic or paper inserted and left in the hole
  • instead of limiting customer with the switch per function consider to provide ways (uC or CPLD) for customer kill switch grouping choices
  • instead of complex full hardware kill switches array consider to have just 1 kill switch blocking uC firmware reprogramming with customer group-kills preferences per each switch
  • instead of using uC consider using CPLD chip having way more IOs for the same price and allowing any custom wiring to be enabled/disabled by any custom number of buttons or switches using specific RTL routing
  • consider keeping database/filebase with prefilled group-kills firmware (uC) or bitstream (CPLD) downloadable for “very busy” customer to simplify “download and apply” process

Oleg

20

Terrible idea. Those extra loose bits will be missing the very moment you’d need them.

For the rest, I can’t tell what are you talking about. Sounds like something overengineered, though.

4 Likes
21

Aesthetically and functionally I would personally rather a normal switch. What is the benefit that you see in that approach? (Not rhetorical, I’m actually wondering.)

Any kill switch design needs to be done in a way that can’t be compromised. If it can be compromised then you would need overriding hardware switches somewhere else, otherwise it is of no benefit. You would then have to educate every customer about those risks… :nerd_face:

Although the current switch setup doesn’t give control of everything individually, the Lockdown Mode feature has added a lot to the switch design. It’s always worth thinking about improvements for future revisions but the simplicity of the current kill switch setup is pretty great.

4 Likes