There’s no intrinsic reason for that. Booting Jumpdrive on the phone is just booting something other than the normal operating system. However
Jumpdrive wants to expose the disks as USB mass storage class devices, therefore however you boot Jumpdrive, the running software must have completely finished using the disks. An advanced user might well be able to package up Jumpdrive to boot from the eMMC drive or boot from the µSD drive.
Users might not want Jumpdrive occupying space on the eMMC drive if they aren’t using it.
Booting via uuu covers cases where you have more comprehensively borked your phone.
Whether the blob is in the firmware jail or the blob is in the WiFi card … the blob is still there, the blob is still blackbox, and the blob may still be able to be replaced. And in the case of being in the WiFi card, three-letter agencies may have a better shot at that than you do. (Whereas in the firmware jail you have the same shot at replacing the firmware - it’s just that you can’t get new firmware to use as the replacement, whereas the manufacturer and the government may be able to do so.)
That’s why you need: hardware kill switch, isolation and encrypted traffic only (regardless of where the blob is).
Personally, I don’t buy the “it’s a good thing” argument. I buy the “it’s a necessary thing” argument. The old WiFi card simply didn’t work ideally, and getting further behind as WiFi standards move onwards and upwards. (You can argue that on a phone you may not need the fastest possible WiFi and you aren’t going to get it anyway - but on a laptop where you can shift serious amounts of data it becomes harder to support the idea of using older WiFi standards.)
jail it is nothing and moreover wlan controller may have microcode too.
this is ridiculous, as the slave it depend on master so high speed wireless no make sense either where freedom and security it mandatory via Gnu System.
Digressing onto future hypothetical possibilities … because the boot disk is eMMC, it could be possible for the boot path to be fully secured against the Evil Maid … using the RPMB area of the eMMC drive. This area is protected by a one-time programmable, write-only secret key, which key is used to sign any content that is written to that area - and you simply can’t write the RPMB without possessing the secret key. So if uboot were written to the RPMB area (it does appear to fit comfortably) then it could not be altered by the maid - and then because uboot has integrity it could in principle verify the integrity of the /boot partition using more conventional verification.
Note that in that case, the eMMC drive ought to arrive from the supplier with the secret key not programmed - and you must then generate a random secret key and arrange the above. So it’s self-signed, which is exactly what you want (rather than Big Tech-signed or Purism-signed). However that means that Anti-Interdiction would require some other mechanism.
There are no doubt gaps in this but it’s food for thought.
That is so cool, a whole new thing to learn about! Thanks for bringing this up! Its so interesting hardware devices literally have spaces in them we just have no idea about (for better or worse) or are more or less invisible too us even as programmers.
I wonder what a good channel for learning this kind of thing about hardware is, or how it might be discovered by your OS.
I like the idea of self signing in particular also if I can verify the software from the vendor. I actually would like the ability to (perhaps optionally) store additional keys in there say from purism or I have noticed purism seems to have some support for Quobes OS. Self signing would at least confirm however that data-integrity was preserved after write, and would help detect tampering.
That would require some work
A couple I things that came to mind:
I did read this uses symmetric encryption which may be a bit tricker because this would be a highly sensitive key , but at the same time if its long enough that makes it quantum resistant (not that I am that concerned about a relevant quantum computer at present, but good to plan for the future).
Weather the encryption is symmetric or a public key (which in theory could be extracted given encrypted data) you would not want to use the key with an un-trusted device, when it has the key, it can flash whatever it wants, this may be a good reason to be able to use vendor keys, perhaps with the hashes encrypted by the vendor (but that would require public key-cryptography)
I think there is some marginal benefit to using public key cryptography: the public key is less sensitive and be safely exported/viewed (for example, I guess private keys generally cant [unless perhaps you have a lab where you dissect it or something] be exported), and the boot part of the disk is read proof (if the private key never leaves the device for instance)
on your phone would reveal the 4 distinct areas of the eMMC drive (only one of which, the normal data area, is currently being used). NB: I am using the term ‘area’ here as distinct from ‘partition’. The normal data area is itself split into two partitions but that is different and more vanilla.
Ah, well, being quantum resistant may go beyond the scope of this topic. The key is 32 bytes (256 bits). It’s not an encryption key though. It’s a signing key. The readable content of the RPMB is in plaintext (unless of course the actual original content that you wrote to the RPMB were first encrypted).
The goal of the RPMB is integrity, not confidentiality.
Yes, you must protect this key (keep it secret) for this functionality to be useful. However you don’t need the key to reside anywhere on the phone except when you are actually updating e.g. uboot, which would be infrequent. (So you could e.g. keep it on a flash drive and just plug the flash drive in on the rare occasions that you would use it. Of course it is also essential to keep some kind of backup copy of the key if you intend to use the key.)
I think I am right in saying that Jumpdrive does not (yet) support the RPMB area. The area is not exposed and probably the necessary specialised read and write commands are not supported. So this would mean that you can’t delegate maintenance of the RPMB area to the host computer.
As a hypothetical, you could make the RPMB completely and irrevocably read-only by generating the key, sending the key to the eMMC drive, writing the RPMB area once, and then throwing away the key. For some threat models that would be good.
Vendor keys are, well perhaps I won’t say anathema but, not a good thing. It opens you up to having to trust the vendor. It opens you up to situations where the vendor gets taken over, goes out of business, obsoletes the product. It opens you and the vendor up to situations where the vendor is compromised, either by a hacker or by government coercion.
I lately have limited options for immediately available devices, so I wondered whether it would be possible for me to upgrade to Crimson with an SD card.
I started by looking at the contents of librem5-flash-image script that the reflashing guide in the wiki refers to. The script uses a hardcoded URL for the images repository at https://storage.puri.sm/librem5/images/. After inspecting the repository, I downloaded the latest image with wget and unarchived it. Having the image, I powered off Librem 5 to insert a spare SD card, unmounted it after booting, and copied the uncompressed image to it. It is similar to creating a bootable USB flash drive for desktop distribution. To boot from the SD card, hold the volume down button, press the power button, and then release the volume down button when the LED glows green. The green LED indicates that the U-Boot is booting. The partition is resized automatically during the first boot to occupy the free space available on the media, which is the SD card here.
Now, when operating from that SD card, I expect to be able to repeat the same trick and write an image to the eMMC. That is something I am going to try when Crimson is declared stable.
I would have to learn to interpret it a bit more but its interesting, ty
Yes your right, I think I misread and article and I thought it encrypted the volume
That works if you only plug it the key into the phone and update the phone from the phone (perhpase using the sd card, or from the flash drive itself). In such a case it could be some sort of trusted flash drive like what you mentioned before that comes with the larger purism devices. Maybe the pgp card on the phone could be used to confirm its integrity, or decrypy RPMB key (using a Key Encryption Key) on it. That way you could load signed images onto it and boot off it without risking the RPMB key.
Not exposed via hardware or just software?
A decent option. Especially if you could some how detect tampering. I think the “trusted flash drive” option might eliminate its necessity though.
To be clear, I don’t necessarily mean the root key (or something like that, the one that generates all the other keys in a typical TPM say from micro$oft).
In the manner I propose, the key is revocable and optional, and perhaps you could have multiple (multiboot for instance), and I propose from either (or both) an OS vendor or a hardware vendor. You can purge it from the pgp card if you feel the need (you no longer trust the vendor), and or re sign your image with another key (so you can boot an old trusted version of the OS but not a new version).
If I wanted to, say, load postmarketOS or Qubes instead of pure os, I could get a key from postmarketOS or Qubes and install it and use it to verify what I am booting.
One probably should trust the key at least as much as the OS you are loading from that vendor. They key may require an additional level of trust, and I understand what your saying there (which is where the optional/revokable part comes in). I think it might be the best way to ensure the software your running on the device is actually from the vendor (who’s software you choose to use) you want it to be from. It helps ensures integrity, not trusting the vendor. Sort of like, how I could have a pgp encrypted chat with someone I dont trust, but pgp helps to ensure that I am actually chatting with who I think I am chatting with (though cryptographic mutation is possible its difficult so to some extent I can affirm that they are saying what I think they said).
In other words, if you boot normal PureOS on the Librem 5, you can see that the specialised areas exist on the eMMC drive but when you boot Jumpdrive on the Librem 5, the Librem 5 does not make those areas accessible to the host computer.
I can attest to this working, I have done it several times and it is a lot easier than having to do all the ‘flashing procedure’ with a compatible device.
It even works if there is no image on the eMMC. So if one has a bricked L5, you can just boot from an SD and, voila.
It’s not clear to me what “repeat the same trick” means.
Is it scp an uncompressed image to the eMMC of a Librem 5 booted from its SD card, copying a compressed image to the bootable file system on the SD card and uncompress that to the eMMC while booted from the SD card, or something else?
