Flashing From/Interacting With Non-Free Hardware

Hardware Librem 5
1

Not everyone has a Librem 5, and fewer still have the privilege of having 2 Purism devices, or a librebooted or corebooted machine to use for flashing/maintenance of the L5.

I have gotten into a bit of a situation where I may have to flash my L5. Originally I really did not want to plug anything, not even a USB drive into my L5.

I have heard horror stories about how simply inserting a USB stick into a laptop/smartphone can infest it with persistent malware or rootkits.

These days even simple usb drives or sd cards have CPU’s, and many modern computers/phones have coprocessors in them with code that is very difficult to replace/audit/inspect/disable.

So the question is, if you have a device (lets say in for Device 1 without such a co processor or Device 2 with such a co processor) and you

A: Plugging it in and interact with the L5 via USB (A.a and giving it access to internal storage A.b not giving access to internal storage) from the device (either before or after boot)
B: Flashing the L5 from USB from the device
C: Writing to an SD card (with a processor on it) from such a device and booting the L5 from it
D: Simply using an SD card (which has a processor on it) with the L5

What are some risks (possibly specific and measured), protections the L5 might have, or possible risk mitigation strategies

Some possible points of considiration:

  • What are potential targets (firmware, OS, bootloader, what else?)
  • The L5 has a novel secure boot implementation (not used by many other devices, as I am not aware of any that use an pgp card instead of tpm), is there a way to circumvent this with a malicious image or corrupted firmware?
  • DMA Attacks
  • Circumventing encryption (as I sortof implied in the first one)
  • Security after a first boot after flashing (malicious image or malware firmware makes changes that are then “signed” on shut down and can be secure booted) or Time-of-check to time-of-use attacks
  • IOMMU support? Or bugs thereof (see also 1, 2, 3, 4)
  • Stumbled on this post when making this

Basically what I want to know is Can the L5 after such an operation be trusted to the same degree as it was fresh from Purism?

And if not what are significant risks and how can they be mitigated

Also is there any way to audit any of this when it comes to A: firmware B: the OS?

Also can the Librem 5 detect if an image has been signed by purism (does is it have a preinstalled key)?

Thanks!

1 Like
2

You should be able to reflash the Librem 5 using any Linux computer (includes another Librem 5, a Raspberry Pi, or a random desktop/laptop), although, for a random desktop/laptop, optimal is recent and Debian family distro.

If you can’t trust the host computer then it is basically impossible to guarantee the integrity of what ends up on the Librem 5 - because reflashing is basically the same as accessing the internal storage of the phone.

I guess if you have severe constraints, you might try to

  • do an untidy clone of the Librem 5 eMMC drive to the ”SD card of the Librem 5
  • on the Librem 5 download the Librem 5 disk image to the ”SD card
  • boot the Librem 5 from the ”SD card
  • do an untidy reflash of the Librem 5 eMMC drive from the Librem 5

This is not something that I have ever tried. It may or may not work, but it avoids involving any other device. It assumes that you have a ”SD card already in the Librem 5 and that the contents of the card can be sacrificed and re-established securely later on. It is of course only possible to do the above procedure if you still have a bootable Librem 5 (which may not apply in your specific “situation”).

If it doesn’t work, you aren’t much worse off than if you had tried to reflash in the standard way.

If reflashing in the standard way, some people prefer to do that from a Live Boot environment. While that in no way defends against all possible attacks, it provides a more guaranteed starting point for the reflash. The reflash script will at least verify the hash of the downloaded disk image before writing it to the Librem 5 i.e. the reflash script does: download, verify hash, flash.

You should probably persevere with trying to resolve the “situation” first, before contemplating a reflash.

Unless you paid for the Anti-Interdiction (AI) service then I don’t think that there is much trust in the original. I mean this is a theoretical point but in theory a phone that arrives with a default encryption passphrase and without AI, can be intercepted in transit and reflashed with a compromised image before you even get the phone.

So, unless you paid for AI, the answer is probably “yes”.

It doesn’t work like that. No image is signed by Purism. There is no pre-installed key. On any Purism hardware.

At the current time in any case the Librem 5 works differently from the Librem laptops etc. as far as boot integrity goes.

4 Likes
3

Probably healthier than dumpster diving for free hardware.

3 Likes
4

Thanks for the reply

I have been considering trying something like that

And that is my problem, it would be great if I could get some sort of terminal or recovery prompt, I maybe could create a raw bit for bit copy of the disk image for verification purposes at least. Or in my case just try to repair the boot config or enter my LUKS key.

And do you mean a live boot image of PureOS? Live booting on the L5 or on the flashing computer? If from the computer Im not sure I understand how that helps?

If you live boot, do you do so from an SD card, or from a USB drive plugged into the device?

By “more guaranteed” do you mean because its a copy on write so its more or less an immutable system?

Flashing and interacting with it via an external computer were proposed solutions. This is just throwing a monkey wrench in my security model and giving me a bit of a pit in my stomach. I never intended to plug this device into anything basically to avoid these kinds of issues.

The L5 is my most trustworthy device as it stands and I would like to have at least one device I can trust on that level

Okay, what if I add the constraint that I know or assume there was no interdiction?

How does it differ exactly? I see there is a user key on the laptops but I am not entirely sure I understand the security model.

I it just a self signed key, and is there a way to optionally verify the integrity of an image using a publisher’s key on the pgp card (assuming the integrity of the PGP card could be assured
 is its firmware writable?)?

Is there a way I could take out the pgp card, use it to sign the image on an external computer, reinsert it into the phone, then use it to verify the image and firmware on flash?

Also since most of the firmware for PureOS is free, might it be easier to remove firmware level malware? Suppose you do infect your phone with something after flashing (or have a malicious configuration), what if you use the phone to overwrite those changes? From what I understand, you cant really ever be sure something absolutely deleted from nvme storage (for example a password), but would this restore the approximate original level of trust in the device?

Im also wondering if its any less of a threat to plug in the SD card to another computer, flash it, then put it in the L5 and boot from there. I already to some extent don’t trust the SD, but I am honestly not sure if that is just as bad or not.

2 Likes
5

Apologies in advance 
 this is a lengthy and rambling post that doesn’t really get you closer to what you actually want.

You need to prepare any of this before your phone is rendered unbootable.

Live booting on the flashing computer (the host computer), not on the Librem 5.

It could be PureOS. It could be something else. If you don’t true the host computer then it doesn’t really matter which distro it runs.

Yes.

Although for greater robustness, it could perhaps be tweaked to avoid even the overlayfs. You might need to find a distro where the live boot is literally read-only. But these are just shades of grey.

And you would have to have prepared this in advance.

I don’t think the Librem 5 was designed for that use case. The underlying boot “ROM” has just two choices. 1. Boot from eMMC drive (native ‘SD’ interface) 2. Boot from USB connected to host computer (uuu).

So if you borked the contents of the eMMC drive, connecting the device via USB to a host computer is the only remaining option.

I guess that the closest that you could get is to have two Librem 5 phones - and just make sure that one of them (at least) is not borked at any one time.

Yes, it would be great if a future hardware version of the Librem 5 supported native USB booting - so you could at least boot it from a local USB disk that had been prepared in advance if you have borked the contents of the eMMC drive and you never want to connect the Librem 5 to a host computer via USB.

The bigger Purism devices come with such a USB drive - so if you trust Purism for the original flash then you can trust the USB drive for the Live Boot.

The Librem 5 can’t natively boot from a local USB disk.

The Librem 5 doesn’t have support for the Librem Key for boot integrity / doesn’t have PureBoot firmware.

Actually I’m not sure that the Librem 5 even has firmware at all in the sense that the bigger Purism devices do.

I don’t think so. I think the threat is the same. If you can’t trust the host computer then it can compromise what it writes to the local ”SD card just as much as what it writes using uuu via USB to the phone’s eMMC drive. (In some respects compromising the ”SD card is easier - assuming that a motivated and somewhat sophisticated attacker was bothering to do this.)

Noting though that there isn’t a lot of difference between an eMMC drive and an SD card. They are at a similar level of technology and if you think that the storage itself contains a computer and that said computer is compromised then I wouldn’t trust either.

Then I guess your most solid option is to pay Purism to reflash the phone for you i.e. send it back and let them reflash it - because whatever the strengths and weaknesses of the original procedure, they will be the same the second time around. (If you are inside the US, this may be a viable option. If you are outside the US, not so much.)

1 Like
6

You can purchase another Librem 5.

7

I appreciate the reflection.

Its frustrating but I guess I have to accept that. Though it would have been nice if purism would have set up a recovery partition or prompted me to set one up.

Agreed on the shades of grey, probably wouldn’t bother with it, thank you for answering these questions.

I appreciate your analysis and explaining that.

Thats interesting, can you explain please? :slight_smile:

I think your right about that.

I think firmware implants (or using devices like this to exfiltrate data from existing implants) could be used as a form of mass-surveillance or cyber warfare. But its really speculation.

In the case of the librem 5 with mostly open firmware (or generally firmware from the companies that are willing to work with Purism), I trust the firmware on the internal eMMC more than the proprietary blob or silicon on the closed-source SD card.

Its an option :thinking:

I’m aware this post is a bit paranoid, I’m frustrated with the situation but it is what it is. Thank you taking the time to respond.

1 Like
8

Too much money, though anything with a similar degree of openness would likely do

1 Like
9

It would be cost-efficient to send your Librem 5 back to Purism under warranty then.

1 Like
10

My understanding is that the boot goes straight from boot ROM (read-only, can’t be compromised in the manner contemplated here) to code loaded from the eMMC drive (software). So there’s no writeable firmware to compromise. It is of course all in the choice of terms. What I am calling “not firmware” someone else may choose to call firmware.

Yes, with the benefit of hindsight.

I guess a recovery partition would have been controversial, given the small size of the main disk (the eMMC drive), and given that for most customers recovery via uuu is acceptable.

Also, at the time of initial release there was no support for booting from the ”SD card - and hence they could not sensibly have prompted you to set up a recovery partition on the ”SD card (where there can be oodles of available disk space for a recovery partition).

I don’t see why. The eMMC drive contains its own computer running closed-source code, in order to implement the eMMC drive. The standards for eMMC may be open but any actual implementations are just as proprietary as anything else that is closed, just as blobby, as far as I know.

Maybe we are talking at cross-purposes though.

I don’t see why it would be under warranty. The OP broke his/her phone doing something that was expressly advised against by at least one other forum user.

Sending it back for Purism to reflash (if inside the US), and paying for that, is likely to be cheaper than a second phone though.

2 Likes
11

Hey i have few Petitboot machines too. :wink:

2 Likes
12

Thats interesting, and comforting, though is this where the firmware discussed here including u-boot resides?

Also it seems like it can be flashed, so could you clarify what you mean by non-writable?

Yep.

Those are all good points.

I think I had a misunderstanding, I thought the only closed source blobs the L5 had were for the 4G modem, because purism could not find a manufacturer willing to work with them. After looking into it I realized I was wrong. Though I have the understanding the Purism has looked specifically with manufactures who are willing to work with them (lowers risk in my opinion), and stores proprietary firmware on a separate flash chip, I think your more or less correct here. Any differences assessing the threat level would be down to the use case of an eMMC drive vs an SD card. Where and SD card is lower cost and likely to move from computer to computer, the eMMC drive is likely to stay in one machine and is higher cost.

Guess I will find out :person_shrugging:

1 Like
13

I briefly looked into Petitboot after I saw your post, I’m curious, could you elaborate, do you feel this increases the trust level you have in your machine?

2 Likes
14

I think you’ve got the wrong end of the stick here.

There are many places that peripheral firmware could be stored:

  • embedded within the peripheral that needs it itself - and no action by the operating system is required at boot time (the peripheral firmware is already where it needs to be)
  • on a separate, dedicated flash chip that exists largely or solely for the purposes of holding firmware (aka firmware jail) - and the peripheral firmware is copied by the operating system from the flash chip to the peripheral at boot time
  • on the operating system disk - and the peripheral firmware is copied by the operating system from the disk to the peripheral at boot time

The primary goal of Purism’s design is to avoid specifically the third of those options i.e. no peripheral firmware on the disk.

It is also noted that for peripheral firmware that relates to the boot disk, it is difficult or impossible to have the firmware on the disk anyway (chicken and egg problem). So most storage devices opt for the first of those options.

The approach taken will differ from peripheral to peripheral, and from product to product.

Also note that, regarding the first option, it may or may not be possible to update the firmware at all. It is assumed that there is some way of updating the firmware with the second option. It is obvious that the firmware can be updated with the third option.

That’s definitely not right. In any modern computer, there are a heap of blobs, although some of them may be invisible and some of them may not in practice be able to be updated (for a variety of reasons).

At a minimum, the WiFi card has a blob (but the source of the blob differs between the original WiFi card - blob is embedded - and the more recent WiFi card - blob is in firmware jail) - but also the power delivery controller has firmware, the touchscreen controller has firmware, the GPS module has firmware, the smartcard reader has firmware, and of course the cellular modem has firmware. And as discussed the eMMC drive would have firmware. Maybe I missed some.

With all these blobs, and all these potentially hostile peripherals, different strategies are employed to manage that. One of the main strategies is that the peripheral does not have direct access to memory - a communication bus can only be used where the host can only ever be the bus master etc.

Another strategy, as used with WiFi, is that ideally all traffic is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). The same strategy, as used with disk storage, is that ideally all content is encrypted by the host (so even if the hostile blob is snooping, the content is meaningless). In either case, ideally content is also integrity protected (so even if the hostile blob is maliciously altering content, the host can detect that). By default that does not occur with disk storage although theoretically LUKS has an option for the brave for that.

My understanding is that uboot resides on the eMMC drive. So it is more in the nature of a primary bootloader than firmware. Being on the disk, it can of course be written to.

The terms “flash” and “reflash” are confusing here - because noone ever talks about reflashing a USB flash drive, we just talking about writing to it - even though all of the following are in fact flash storage: NVMe disk, SATA SSD, USB flash drive, USB portable SSD, eMMC drive, SD card, flash chip. There are great differences in how they are accessed but ultimately they are all flash storage.

1 Like
15

This is getting to be a very interesting conversation! :smiley:

Part of my issue here is, Im a software person, the firmware, the chips, etc. to some extent are a scary black box too me. To an extent I dont know the limits, or how really to evaluate their capabilities. I have been able to piece together most of your information here, but it is very helpful that you have laid it all out and explained that its normal to have a combination of these things, thank you.

Does this mean its on the blob is still on the perhipheral in the most recent version? Im not really familiar with firmware jails.

So perphirals with propreitary firmware hosted on them (or with just proprietary firmware) on the Librem 5 dont have direct access to memory? Thats so cool actually.

That’s actually awesome.

Thank you for explaining, but there is a bootloader on ROM to load u-boot?

One thing I dont understand about the verified boot here, is it all self signed? What am I confirming the integrity of exactly or comparing it too (last boot? what about after flashing?)?

Suppose the u-boot on disk was an evil maid, how would I know? Is there a way to detect if the u-boot I would write to disk I flashed the phone is “tampered” with respect to the u-boot that was on there before?

Also, if I wanted too, is there a way to sign an image such that it can be checked using the pgp card?

It is a bit vague too me, does any firmware (from the first two types you mentioned) actually get written when we “flash” with jumpdrive (is it even really possible on the L5?)? Or are we just writing files to disk? Also since the USB controller has a proprietary blob, does that mean that it does not have direct access to memory? If so, in turn, does that mean a connected computer does not have direct memory access?

From what your saying it seems: so long as the integrity of the OS image and bootloader are secured, even if there are malicious blobs on (or sent too) the L5, they cant really do anything because of the steps taken to frustrate anything evil they might do?

Also is all the free firmware contained in the OS image? Or is it also on a flash chip (or ROM)?

1 Like
16

My understanding is “no”. The blob is in the firmware jail with the most recent (second) WiFi card.

I guess though even peripherals that operate like that must have some mini-blob embedded in the peripheral and the mini-blob is capable of handling the blob that is sent by the operating system to the peripheral.

It does of course come at a performance cost. That probably doesn’t matter on the Librem 5 where shifting GB of data 24x7 isn’t a goal.

That is my understanding.

This is a major area that Librem 5 (right now) departs from the bigger Purism devices. What is your reason to believe that that functionality exists?? Documentation link?

One reason that it is less critical as far as the Evil Maid goes is that you can keep a phone on your person for much more of the time than you can keep a laptop.

You wouldn’t normally (re)flash with Jumpdrive. You might image the disk with dd using Jumpdrive and then later on therefore you might restore the entire disk with dd using Jumpdrive, if you stuffed something up badly - which is a kind of reflash.

But let’s rewrite the question as: does any firmware get written when we reflash a Librem 5? My answer would be ‘no’. It just rewrites the contents of the disk. So it’s more like a wipe-and-reinstall-the-operating-system.

Most of the peripherals have embedded firmware - except the 2nd kind of WiFi card where the firmware is in the firmware jail. So reflashing won’t change any firmware either way - which is a good thing and a bad thing i.e. a design trade-off.

A connected computer most definitely does not have direct memory access. All it can do is send and receive packets over USB. However, were you to put your phone in serial download mode (in preparation for using Jumpdrive or reflashing or other things), the effect of sending and receiving packets might well be to alter the contents of memory (as well as to alter the contents of the disk). So I guess you shouldn’t connect your phone, when the phone is in serial download mode, to an untrusted host computer.

I don’t know. There isn’t a lot of free firmware around though for mainstream peripherals - and even less that would be relevant to the Librem 5. All I can say is that if the firmware is open source then it is within Purism’s principles to include it within the operating system disk image.

1 Like
17

Thank you for the reply!

Interesting okay, so the “firmware jail” is that second flash chip I mentioned earlier (so this is effectively the “second kind” of firmware from your list)?

Figured as much, but the L5 is more about privacy/security and less about raw computational power. Wortwhile tradoff as far as Im concerned.

For some reason I thought it did and that was part of cryptsetup, also posts like this discuses secure boot related topics and how the pgp card is an alternative to a secure enclave/tpm. The post specifically mentions firmware and software verification, and discuses using the pgp card for disk unlocking as well (which in my mind is related). I think I took this to mean that the smart card was used as purism’s version of a tpm for verified boot, but your right, it never actually that it is used for secure boot specifically. Though that would be cool (and a feature I really would want)!

Yes. I think I mentioned it however thinking that the bootloader did verified boot, so it could load a malicious OS if you can just write the bootloader to disk (assuming its out after the OS loads and doesn’t do anything malicious beyond that point).

It would be nice if I could do something like: create a key pair and extract the public key, then sign the desired OS image with it, write it to disk using a computer (or SD card or USB stick as previously discussed), then unplug it and verify the image once its actually on the device before booting from the image. Or if purism pre-installed a key I could optionally use to verify their images. Or even store a hash for a checksum.

But what your saying is: there is no way to verify the image once its on the device (except by perhapse using another image on an SD card, or using the booting image and having it check itself on disk)?

Thats good to know, so basically a zero-day (or something very advanced, which was my guess) would be required to attack most of the peripheral firmware from the computer? We have already discussed the L5’s resilience to malicious firmware. Though if both the on-disk bootloader, OS and the firmware can be compromised that would be an issue

Thank you. It would be nice to be able to verify the full disk image (nothing hidden in the OS). I suppose you could verify that only what you wanted written was written by monitoring the current/voltage in the USB cable :sweat_smile:

Okay, so is this is what is required to “flash” the OS to the disk using uuu right?

Thanks for answering that.

P.s do you happen to know if using an x86 computer with jump-drive is a hard requirement? And if so why?

1 Like
18

Jumpdrive is not a hard requirement at all. I certainly would recommend it as a good tool to have though. Jumpdrive is the easiest way of doing backup and restore in a reliable way and almost all computers should have some kind of backup strategy - and the onus is on you to decide whether to have a backup strategy, what that strategy is, and to execute that strategy.

I would say that being able to reflash the phone is (close to) a hard requirement.

Reportedly you can reflash from an ARM computer - so x86 is not a hard requirement. Reflash from ARM (e.g. Raspberry Pi or another phone) is not something that I have done though.

The key requirements for reflashing are a computer that has available: a working git command, a working uuu command, working Python3, and obviously an internet connection. It is unlikely that many people would want to attempt to achieve that on any computer that does not run Linux.

The exact boundaries of how adventurous you can get in trying to meet those requirements are unknown. I’m happy for someone to use WSL under Windows combined with brute force and hackery - and demonstrate that you can reflash under Windows. :wink:

Do you want your life to be simple? Do you want to be able to focus on more productive challenges?

The actual files that get downloaded and then written onto the phone can basically be treated as opaque data.

If you can’t reflash your phone then you have to guarantee that you will not break your phone (it has happened e.g. through tinkering) and you have to guarantee that a Purism update will not break your phone (that has happened too although I would say that as the product matures that will become less likely).

If you can’t reflash your phone then you will find it more difficult or even impossible to perform a major version update (e.g. amber → byzantium → crimson). Again, as the product matures it is likely that in-place major version updates will become more straightforward.

Yes, serial download mode on the phone is necessary in order to reflash the phone and is necessary in order to boot Jumpdrive on the phone and is necessary for some other low level operations.

Fair enough. I can see why that text could be confusing. It’s not wrong. You can certainly use the OpenPGP card for verification and authentication - but not for the boot path, not for the operating system itself - because it would be too late. The Librem 5 simply does not work the same as the bigger computers at the current time as far as Evil Maid goes.

Reportedly it is possible to use the OpenPGP card to unlock the LUKS container, although that is not something that I am currently doing.

However it is important to note that the default LUKS configuration (on any Linux computer) does not contain integrity functionality, regardless of whether a card or a passphrase will be used to unlock. So someone with physical access to your computer could alter your encrypted file system. There is a high likelihood that they would just corrupt some file or corrupt the file system and the alteration would likely be being done blind. However only the corruption would alert you to the alteration. The alteration would not itself trigger any failure.

1 Like
19

I can understand from the phrasing of the question and the context, why you thought if I was asking if jumpdrive itself was a hard requirment, I meant only to ask if it was a hard requirement to use an x86 computer with jumpdrive. You answered that as well so thank you.

The answer to the last is yes haha

Is this the normal update mechanism

So it is required for all operations concerning jump-drive?

1 Like
20

I struggle when reading this to shake free of the notion that even on the Librem 5, at some low technological level, humanity loses.

After Purism announced the Firmware Jail coming to Librem 14 (Intel AX200 Wi-Fi/Bluetooth Shipping for New Orders – Purism) they endorsed the idea that it’s a good thing if the user is “free” to replace the firmware of their WiFi with a new blob, even though none of us users have the source code of these firmware blobs.

So, everyone is free to replace their firmware, but some people are more free than others if they are government 3-letter agencies with the blob sourcecode.

The Librem 5 is fun because it usually philosophically tries to be better than the grotesque of Android and iOS that we are all jedi mind tricked into thinking we should use.

But at the end of the day, it’s unlikely for users who want the privacy necessary to sleep at night to win the information war against governments who make it their active goal to secretly treat every living human like a criminal in case they might become one.

What makes you think you can win? I learned enough software to believe that at the hardware level I probably already lost, so all I can really do is take solace in winning the imaginary battles in the simulated software space that I was trained to understand. How can we verify hardware? How do we know it’s not all calling home to its creators in China? It’s fun to use a Liberty Phone and aspire to believe that maybe the mostly-for-show made “mostly” in USA branding will protect me. But whenever I open the back, it says Zhonshan manufacturing because the batteries are cheap China junk. If I were China, I would probably but some cellular call home machine into there. Why not? There are so many possible vectors.

2 Likes