I can’t claim to understand all of it. Part of what I got from all that is, for example, that perhaps the microphone kill switch on the Librem 5 cannot prevent all audio recording on the phone even when the the switch is set to kill the microphone. This is news to me.
Am I understanding this correctly?
If I want to be sure there is no audio recording possible, will lockdown mode accomplish that for me? And is that my only option besides turning the device off?
For the (somewhat hypothetical) attack via the sensors (gyroscope), yes. Lockdown mode will disable the sensors and defeat that attack.
Nevertheless, a technology (in this case the mic kill switch) that defeats some attacks but not all attacks is not “useless”.
However first and foremost you should be aiming to avoid running untrusted code on your phone. That is always the best “option” as far as this attack or related attacks go.
The original research paper suggests that gyro hardware should be irrevocably limited in what sampling frequency can be used e.g. no greater than 20 Hz. That may be acceptable in the context of a phone. However that is not something that the user can control at all.
The paper also suggests shielding the gyro so that sound does not reach it. That may not be practical for users to do but may not be impossible either.
What about speakers? (Micay wrote: “It doesn’t make sense to have a microphone kill switch where you can still record audio by using the speakers […]”)
Is it possible to record audio via the speakers on the Librem 5? The speakers are still working in lockdown mode, but I don’t know if there are ways to use them to record sound.
I answered the part that I could answer. If someone wants to claim that the above is possible perhaps the onus is on that person to provide a citation for a research paper. (I was easily able to find the research paper regarding the gyroscope attack.)
However, again, a technology that defeats some attacks but not all attacks is not “useless”. As a post in the linked topic says:
According to their logic, the lock on their front door is useless because it can’t stop dynamite. Bet they still use theirs, though, and would refuse to buy a house that couldn’t have one installed.
Just to clarify where I’m coming from in my original question:
I completely agree with the point made by the analogy, “According to their logic, the lock on their front door is useless because it can’t stop dynamite. Bet they still use theirs, though, and would refuse to buy a house that couldn’t have one installed.” Very nice summary.
But speaking for myself, I originally thought, Well, if I turn off the microphone kill switch, then there is no way anyone can “hear” or record anything from my phone. I am now coming to understand that is not exactly true. So for me the analogy is more like this: “That dynamite-proof steel vault door you thought you were getting with your house is in fact only an ordinary door with a lock on it. Still useful, but not what you originally thought you were getting.”
NOT saying anyone deliberately misled me, but I did make what I think most people would consider to be the natural conclusion of what a kill switch accomplishes. Now I’m learning more and know better.
So I think the question comes down to: does the Librem 5 audio hardware that is connected to the various audio outputs support jack retasking (jack remapping)?
Adding: So
for those who want more peace of mind … when you put your phone into Lockdown Mode, also physically disconnect your headphones / earphones from the audio out jack.
I would go with: That dynamite-proof steel vault door you thought you were getting with your house works as advertised but there’s a side-door that leads to an entrance foyer and if you let someone in via that side-door then there are three small exits (gyroscope, accelerometer, speaker) from the entrance foyer that can potentially be used to get into the main part of the house but two of them can be closed off with Lockdown Mode and the third may not in fact be usable at all on a smartphone - and to give house-buyers extra confidence we give you a copy of the detailed construction plans for the house so that you can assess all of this yourself.
If you read the research paper for the gyroscope attack, it is a relatively sophisticated attack. If your threat model includes state actors then, yes, take it into account. If your threat model is just your crazy ex then don’t stress.
Correction: while the L5 can’t do jack retasking, it seems that headphone output’s left channel (HPOUTL) is connected to input line IN1R (signal MIC- in the schematic), which looks like a way to catch the analog output back in for things like echo cancellation. Whether that actually allows to record audio from left headphone channel would have to be answered by someone who can read the schematics better than I can.
Those threads are, paraphrased, saying that you need to know what you are doing to actually take advantage of security features, and also that they haven’t thought this through.
There is slight doubt about hardware kill switches, where they say that one might not be needed if you already have a software switch. That’s a valid point, but also one that dismisses a compromised device.
I’m actually not sure if we published any explanations of threat models those were designed to prevent, I didn’t take part in drafting them.
I’m pretty sure nothing like that has been published. But I think it would make a very interesting series, maybe for @Kyle_Rankin. Including everything from hardware (the bits from @dos above), verifiable boot, encryption, to trusted software.
But maybe he’s planning for that when boot is actually verifiable on the L5
There is no ultimate security. There are more or less sophisticated attacks and more or less probable security incidents. When someone motivated and with resources wants your information, they get your information, ex. by installing eavesdropping device to your window or just hacking phones of your family or your housemates. Or they could sell you hacked mouse or keyboard…
The thing is that kill switches are tool to protect wide range of but not all the range of attacks or leaks. When you talk about something very secret, all parties should not bring any electronic devices, because internal hardware microphone with storage could be installed in advance weeks before. Detection device should be used to scan clothes, etc. And surroundings should be secure.
The value in privacy and security tools is to use them properly. This requires transparency and clarity. Transparency and clarity are things which Purism lacks sometimes - Librem 13 had disabled and neutralized ME, but Librem 14 has just disabled ME (no neutralization). Such technical difference with huge security and privacy threat implications should be communicated heavily even that the probability of ME related attacks is low. Why? Because big part of Librem 13 marketing was based on ME attacks. And because Purism is security and privacy tech company, so it should inform about such technological differences even if looks like bad marketing. Another thing is Purism bad docs (now they are better).
Another thing is Librem 13 and 14 kill switches - do ALL of them disconnect electrical circuit? They do not. Purism explained kill switches in such a way that electrical circuit is disconnected or people got it that it is about electrical circuit, but this is not true for all Librem 13 and 14 kill switches. Cam&mic kill switch on Librem 13 and 14 disconnects microphone from sound chip, but electrical circuit is connected. Clarity failed here and this caused forum posts when people though that kill switch does not work.
Another things is hardware compatibility and specs. On one hand Purism has blogpost about right to repair, on the other hand there is no documentation (or info in the blogpost) about hardware specifics - what RAM frequencies should be used in what configurations in Librem laptops? What is the max size (inches / mm) of SSD and RAM in Librem products? There is info in forums - but when such info must be communicated in forums, there was failure in official communication channels.
One company who do not fear marketing implications around security and privacy topics is Trezor. They produce cryptocurrency hardware wallets with open-source software and open-source hardware and they are very transparent about how they work, when and how they are useful and when security incident happens they write about it extensively. Their documentation is very good and teaches users about the inner workings of their product in simple terms.
The business approach of Trezor is simple and effective - they are transparent so real security professionals know that “they are no marketing bullshit security scammers (exaggeration)” and then the security professionals can recommend the product to ordinary people. Ordinary people are happy because they read documentation written for ordinary people. The difficult security knowledge about tools and their secure use is transformed to knowledge for ordinary people in documentation, blogs and product itself. Experts wants such things too. It is just that once someone learned wheres-hows then it does not need good UX, but company expands, more people come without the learned wheres-hows.
Purism does that job with the Pureboot verification screen (nice notes, recommendations and default next actions), but that approach should be used in documentation and everywhere. Ex. there is no updated guide or documentation how to update Pureboot / Coreboot. Yes, there is blogpost and docs links to that blogpost, but proper docs should contain just steps to do the job. Blogs come and go, docs stay.
Hopefully Purism will be more transparent, clear and simple about products and their proper use.
No one has publicized an exploit for the Intel CSME 14.0 used in the L14’s 10710U.
Here are the exploits that I can find:
Intel-SA-00086 effects 1-8 gen Core, so it’s not relevant for the L14 and Mini gen2 which are 10th gen Core, and the L13/L15 (7th gen Core) and Mini gen1 (8th gen Core) were neutralized so also not an issue. This exploit is during boot, so I don’t know if disabling the HAP bit with Coreboot will prevent it. Maybe someone with more knowledge can clarify how this works.
Intel-SA-00075 needs AMT, but AMT requires a functioning ME and Librem PCs have Ath9k WiFi chips that don’t support AMT, so this exploit isn’t relevant.
Intel-SA-00112 effects Core Duo through 8th gen Core and requires functioning AMT, which isn’t possible on Librem PCs.
They recently found that it was possible to get around the security to prevent unauthorized firmware updates in some of the lower-end Intel processors (which don’t include the processors used in Librem products). In theory, unauthorized firmware could be made that would execute in the ME, but then the cracker would have to figure out how to make firmware that is capable of doing something malicious in the ME.
It appears to me that worrying about the security difference between a disabled CSME 14.0 vs a neutralized ME 11 is not a productive use of my time. However, if you like to worry about zero-day exploits and theoretical threats, then here’s some info for you.
To be fair to Purism, I don’t think that Purism was deliberately hiding this info from its customers. Somebody made a comment on Reddit that Purism neutralizes the ME, and Purism employee Matt DeVillier responded informing people that it wasn’t possible to neutralize the ME in 10th gen Core processors, but if I recall correctly, other Purism employees had posted that it was neutralized in the Mini gen 2 and L14, so it appeared to me that DeVillier hadn’t informed them.
I remember googling it at the time when this was being discussed on this forum, and I couldn’t find this info anywhere on the web, so it isn’t surprising that other Purism employees didn’t know that it was impossible to neutralize the ME in 10th gen Core, because almost nobody knew about it at the time. I don’t know where DeVillier found this info, but he was the first one to post anything about it in a way where a normal Google search could find it, so it was a Purism employee who let the world know about the problem.
But the fact that there is no public exploit does not imply that there is no exploit. My point is that Purism did marketing around ME as potential vulnerability or potential backdoor - so many computers could be attacked this way. It was communicated that the final goal is to neutralize ME - that was achieved after some time in Librem 13 and Librem 15. But then Librem 14 was constructed with newer processor with just disabled ME (there is still ME code present) and no official and clear info about the ME status was communicated. Even if there was some official info, some employees were not aware of it as you mentioned so it was not well handled.
But yes, ME is not the problem in the end - the point of hardware kill switches is that software itself can not be trusted. So Purism just focused from “nice to have” ME neutralization of software by software to “nice to have” boot verification of software by software (PureBoot), both of them help with some attack vectors of software, but boot process is maybe more likely to be attacked than to misuse ME.
Maybe the next step should be to create stateless PureOS, or just PureOS with change verification of all non-user files. The trusted verification utility in PureBoot could back up changes to USB key for later review. Then random or regular audits of such change backups could be paid for by security professionals or some tool on bootable medium.
Change verification can be implemented by hash function - there are hills of unused ASIC and GPU miner machines which could do the service. Or you just plug in some ASIC miner to your Librem laptop with PureBoot and it detects all changes of your 2TB HDD in few minutes (hours), then copy changed files to USB flash drive for later audit.
The Purism web page for the L14 and Mini gen 2 said that the ME “neutralized”, but within a couple days of this being discussed on Reddit and on this forum, Purism changed its web page to just say “disabled”.
Yes, it should have been handled better, but in my experience working at tech companies, it is often the case that the people doing the marketing don’t know the technical details. DeVillier is the only person at Purism who implements CoreBoot and PureBoot for Librem PCs, and it appears that he didn’t think to inform the rest of the company before he informed the public, but I would rather deal with a company where the developers aren’t muzzled and they can talk directly with the public. Sometimes it happens that the developers aren’t on the same page as the official marketing, but I would rather hear directly from the developers rather than the marketing team, and in my experience the Purism developers are really helpful and respond to people’s questions.
However, I do agree with your larger point that Purism’s PCs should be better documented, and Purism’s documentation for Coreboot/PureBoot could be better as well. The situation is much better with the Librem 5, because all the schematics are online to investigate the hardware and there are a lot of bug reports and commits at source.puri.sm about the L5, and we have a community wiki for the L5 as well.
Another correction: this is actually just grounding for external microphone, and that previous “correction” was just me being bad at reading schematics
