Qualcomm’s Chain of Trust
lineageos.org
lineageos.org
The phone should at least always be unlockable by a single switch in the developer settings - none of this "oh go to our website and generate an unlock code/pay us money for an unlock code/phone us" which is a HUGE pain in the butt.
I swap between roms a lot, and the whole idea of a system partition and data partition etc is just stupid. They always are the wrong size for what they need to be and then I try to install gapps and its like "oh your system partition is too small my dude," so why separate these and just have everything like a regular linux OS.
Maybe I'm missing something stupid? But I kinda just want a phone that just starts a linux based operating system like a PC, and lets me do everything I can on my linux PC in a touch-centric way.
If the current trend of UEFI and laptops without any expansion options is any indication, that open PC of yore will fade into a very tiny niche, as computers become appliances.
Still anyone that has had the pleasure to write portable UNIX code knows that portability is relative.
It boils down to "no secure boot, no DRM, no Netflix 4k for you".
At least this was the case when I was still working with consumer electronics a few years ago.
I have no idea if that's actually the case (I only worked tangential to a retail store's mobile department) so take that with a grain of salt, that's just what I observed the carriers making a big fuss about on the regular. I don't think that excuses the practice either; I'll always be in favor of being in full control of any hardware I'm supposed to trust with my data, but ofc I realize I'm in the minority there.
What's not OK is having a permanently locked bootloader that guarantees my device will be useless after the carrier decides to stop delivering OTA updates in a year or two.
I really can't say I'm worried about the theoretical inability to stream 4k video to a 5" screen. At that size, 4k is just wasting bandwidth.
Is it really that hard to think a bit farther than yourself?
By my calculations, assuming an angular resolution of the eye of about 1 arcminute[0] and holding the device at 300mm, I get about 700 lines as the upper limit of the human eye. [1] So really there should be no benefit for anything above 720p.
There may be other factors relating to scaling and compression that might make higher resolutions on small devices look better, but it's definitely of diminishing returns.
[0] https://en.wikipedia.org/wiki/Naked_eye
[1] https://gist.github.com/dpwm/af467dff758d6f0c5810a2cf902bbf8...
It's a marketing issue - "Galaxy S9 can do Netflix in HD and OnePlus can't" news article is something people will change their purchasing behaviour on.
Not to mention other media providers which will fully refuse to allow video streaming to non-DRMed platforms. Don't get hung up on this one example case.
I was incorrect in my usage of the term.
EDIT: Actually, if I was referring to TV lines then I guess I wasn't wrong, but "lines" is ambiguous to the point of confusion if n lines can mean a vertical resolution of both n and 2n.
I just happen to have some objects from my early childhood, and late teens. I now keep them just for an aging reference.
Until about age 20, I could focus right up to roughly an inch away from my eyes. However, at moderate distances, comparable to some phone viewing, there are features on those objects I know well and could resolve then which take a lens now.
Used to judge quality of LCD displays by the ratio of pixel to space between with naked eye into my early 30s.
Hard to do today. And for me specifically, because of those references, I know about how much harder, or if impossible without a lens.
My point here is I believe many younger people will appreciate 720p plus on modern phone displays. I know I would have.
Or, _perhaps_, someone who doesn't own the device.
That statement sounds too simplified. How about non-approved images pumping power upstream above regulatory limit on RF? Or overclocking the CPU? Or reporting all keystrokes to a place of your choice? Would you, as a manufacturer of the device, like to make that easily possible?
> Their point is to verify that the whole OS from kernel to userspace can't be modified by 3rd parties (such as you, the owner of the device).
What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images. Some owners of some secure-boot devices, do have keys and sign their images. One example: a telecom operator, owner of its park of the set-top box decoders, does that. Secure boot can be made to allow several/many authorized keys.
I am not sure what to tell you. The situation pre-dates the secure boot. If I recall correctly, Iiyama monitors were known to be unrepairable because the manufacturer always refused to release schematics. It did not prevent their extreme popularity.
As an end-consumer, I support very much the freedom to change any products I own, the way I want. I once replaced ball bearings in the drum of my washing machine -- you get the idea.
As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone... I am none of that, but I guess I would have a very different opinion.
Let's be honest and accept it's just about money and control to the makers of these devices. They will bring reasons such as these in their defense, but really they just want to keep the user from being in control of their device and e.g. making tracking them more difficult. I mean there have probably been tens of thousands of roms flashed on different devices. How many of them have emitted unhealthy levels of RF? And parents could retain the ability to flash their devices without giving that ability to their children. The reasons really just don't hold any water imo.
https://null-byte.wonderhowto.com/how-to/set-your-wi-fi-card...
> Let's be honest and accept it's just about money and control to the makers of these devices.
Agree. My point is that less control for manufacturers over the image presumably will lead to lesser profits. My illustrations might be more or less relevant, depending on the standpoint.
This used to be, can be, and should continue to be limited on a hardware level. You can't flash a phone to emit "unhealthy or unsafe levels of RF" if the circuit itself won't let such amounts of power to flow to the radio. Of course, someone could still mess with the hardware itself, but that doesn't scale and (in case of breaking RF limits) is illegal.
> or a parent of teenagers using social media,
This is interesting because, in a way, it's telling me that you the maker of the device are my parent. The argument sounds like, "to prevent your child from flashing your device, we'll prevent you from flashing your device". How about giving me the tools to limit my child's access, if I desire to do so, while not limiting my access?
> or a developer of medical applications intended for mobile phone...
This is a large topic, but to a first approximation, I don't believe a software that cannot be modified by the end-user for health reasons should be allowed on the phone. I also don't believe most medical apps in the smartphone spaces are of this category. The way I see it currently: either accept that some users (like myself) want to have full read & write access to their data on their phones, or make your solution a separate, tamper-proof, black-box device (and get a regulator to rule that for me to open it is illegal).
Safety is complex - what if the phone starts emitting on bands allocated to emergency services.
That's an invalid argument. It doesn't matter how long this has been the case.
>As a person authorizing a product that can potentially emit unhealthy or unsafe levels of RF, or a parent of teenagers using social media, or a developer of medical applications intended for mobile phone...
You're presuming this is the only and the correct way of handling this. That is, you're arguing it is the manufacturer's affair and right to restrict one's basic rights to enforce lawful handling of their product.
I'd rather argue that in reality the manufacturer's main interests lie in reducing support costs and the enforcement of their patents and copyrights.
This is not really what I said (somehow people focus on the second part), but I do believe that offering this freedom (to install any image) will lead to lesser profits for the manufacturers. Quite possibly because other potential customers might find this feature unacceptable (my illustrations may be good or bad). That is, your personal freedom runs into someone else's. Then the market should decide, right?
> I'd rather argue that in reality the manufacturer's main interests lie in reducing support costs and the enforcement of their patents and copyrights.
Yes. Add there loss of face in case of hostile hacking. Etc. Since when this is condemnable?
Do not confuse the tools businesses are provided by the law with the interest to profit. For instance, 10 to 80 years long copyright terms after death are not your inherent rights as a creator but tools the current legal infrastructure offers. Hence it is not the only solution.
>This is not really what I said (somehow people focus on the second part)
No, you did, and the market decides only a share because it is already affects by numerous direct and indirect regulatory measures, e.g., patents. In the past explicit enforcement of the right to repair was rarely an issue for consumers just as net neutrality had not been a serious issue. This has obviously changed.
> How about non-approved images pumping power upstream above regulatory limit on RF?
This is possible through other means (you can buy RF chips and wreck havoc on the frequencies). And it's illegal to do so anyway.
>Or overclocking the CPU? Or reporting all keystrokes to a place of your choice?
I, the owner of the device, might want to do this and these are sometimes completely reasonable things to do (if you're a developer, for instance).
> Would you, as a manufacturer of the device, like to make that easily possible?
Probably not, but that goes against the interests of the customer. ("but most of them won't care anyways")
> What makes it impossible is not the secure boot but the fact that the _unauthorized_ 3rd parties don't have the keys for signing stages of the images.
I am completely fine with this if, and only if, I can add my own secure boot keys and sign my own firmwares/OS images which allow.
I, the owner of the device, should be an "authorized" party when it comes to my device.
I am willing to accept that I do not get 8k service from YouFlix Inc if I add my own keys.
I have no problem with secure boot (the technology) but I do take issue when it is used to limit the rights of the owner to their own device.
But since you say:
> I, the owner of the device, ...
I am tempted to ask -- how much would you agree to pay for a phone that is working but will never be able to connect to the network (no 4G and no WiFi)?
If you're implying that devices without locked bootloaders can't connect to RF networks, that's just incorrect. There are lots of devices that aren't locked, and it wasn't a common practice a decade ago.
4G is also a pointless restriction. It is illegal to connect a device with the wrong specification to 4G networks already. This does not need to be enforced by DRM it is already enforced by law.
didn't iphone 3g did that? it was alwas a few W over what the spec and regulations called for to steal better reception than other devices around it. nobody was punished and it actually become the norm.
Having worked with DRM for 10 years, I can confirm that while very simple, that statement is entirely correct. He says this is the reason the secure boot process exists, not that this is the only benefit.
> How about X, Y, Z
Those scenarios certainly benefit from a secure chain of trust but they are not what brought it about. The whole secure boot chain exists because of companies that require DRM to access their content.
Samsung wants Netflix to play the best content on their devices. That's the only motivation that has ever mattered to device manufacturers.
There are also things such as Google Pay/Banking Apps that don't like it if you are using a custom ROM (although this is root based) it can be bypassed easily using Magisk.
There will always be away round frivolous DRM attempts, even Denuvo and it really just hurts consumer choice and device freedom.
Not for Netflix 4K, which requires SGX capable CPUs to play.
Basically it's such a pain in the ass, you aren't going to have 4k Netflix on PC, possibly even if you try...
I think it ultimately is caused by: a) content is not fungible, and b) content-delivery platforms (Netflix, HBO, whatever) cannot seem to agree on cross-licensing the content. This means that they simply cannot deliver the convenience of torrented content. For some reason this translates to "we must protect our content with even 'stronger' DRM" in the business-peoples' minds, but piracy isn't the root of the problem.
Well, even that can be a non-issue if you have access to the better indexers, be it P2P or Usenet.
Anything bad that happens to the companies or entities that are responsible for shoving this crap down customers' throats is their doing alone.
Almost all high end release scene attacks on DRMed content services target Android or Tizen.
That might be an effect but I doubt it's the cause. Signed bootloader's have been around longer than Android and longer than the Netflix app. They were originally introduced to do things like -- protect the device subsidy lock, prevent customers from flashing their phone with invalid or buggy firmware, prevent modification of radio functions (maybe required for FCC license?).
Nowadays they're useful for more than just DRM too. I'd guess that since the owner unlocks the phone functionality, they are a big disincentive to thefts.
No drm is a feature, and fine I'll just pirate it, it's easier anyways.
Nexuses/Pixels, OnePlus, Xiaomi's Android One line (Mi A1/A2) do not require unlock codes.
OnePlus and Google still honor warranties on unlocked devices so I've been sticking with them, but may hop over to Xiaomi due to the high prices of newer OnePlus and Google devices next time - if only they had one with a 3.5mm jack and NFC this would be a no-brainer. Still running my OnePlus one nearly 4 years in...
Here you go: https://puri.sm/shop/librem-5/
(alternatively, https://neo900.org/)
First, full-device encryption is much weaker if you can do offline bruteforce. With a secure boot trust of chain, it is online, and is rate-limited by the TEE (and could be made to destroy after too many tries) Even better, per Android documentation, full-device encryption key is tied to boot public key. So if someone flashes another OS, even if you enter the passphrase, noone will access your data.
Also, with a PC, if someone replaces your PC, and changes the OS to simply ask for your passcode and send it back to that someone, you won't notice it. With a proper boot chain of trust (which PCs don't have, except for Librem BIOS), it is evident that the OS has been changed, so you know not to give this device your passcode.
Also, boot chain of trust makes it harder to do cold-boot attacks.
So globally, having a chain of trust, is much more secure for full-device encryption, because it forces online bruteforce. Considering that usually passwords used on smartphones are much more weaker (many people have 6 digits for their smartphone, vs 10 characters on their computers), the added security seem necessary to me.
Even with a chain of trust, what is to stop someone desoldering the storage chip off my device and reading the data and bruteforcing that way?
I had a long think while writing this reply about different ways of stopping the issue you described of "change[ing] the OS to simply ask for your passcode and send it back to that someone, you won't notice it", and I couldn't think of one that would be entirely secure (eg. encrypting system, extra checks for this part of the OS) so I agree there - however:
- There are 100s of millions (billions?) of PCs that start and do not have a chain of trust or SecureBoot that store much more confidential information than who my mother last called.
- Lots of servers that store confidential information do not have a chain of trust or SecureBoot.
- SecureBoot is vulnerable.
- Users who get a little popup when starting their phone would likely just ignore it. (if you disagree with this then you severely overestimate the average phone user)
- The chain of trust becomes completely worthless after I decide to put a new operating system on my device. This limits my choice and freedoms as a user of a device.
It doesn't matter how good your encryption or password is if I can change your bootloader to have a program steal that password or read the encryption key out of memory.
See some of the thunderstrike attacks for examples of what a compromised bootloader can do.
“what is to stop someone desoldering the storage chip off my device and reading the data and bruteforcing that way?” - the key will be 128-bit, not bruteforcable in the next hundred years. The TEE contains that key, and can only be unlocked by giving it your user password, online.
The remainder of your arguments seem to be “well it’s not perfect, so why bother?” Servers don’t get left on the subway or stolen. Modern PCs mostly do have forms of secure boot. I can’t speak for Android ecosystem, but users won’t get a popup on iPhone, a modded firmware will just not let the phone boot.
I see your point about bruteforcing that key, however I was more talking about bruteforcing the password.
Servers have been stolen in the past, and I am not just talking about a big rack server here.
In Android, all you tend to get is an unlock symbol on the bootloader logo, or a warning triangle.
With the desoldering the chip to read the data off, you’ll get an encrypted blob which is encrypted with a securely random 128-bit key, so it’s impossible to crack. the Key and the users password are embedded inside the TEE and cannot be read out - the TEE only provides an interface where you can supply a candidate password, and if you get it correct it’ll provide you the 128-bit key to decrypt your data. It has an internal delay and counter, and will destroy the key if you get the password wrong X number of times.
So I’m not sure how you might go about being able to brute force the password, given you can only brute-force online, which is slow and will only give you a small number of attacks.
> - The chain of trust becomes completely worthless after I decide to put a new operating system on my device. This limits my choice and freedoms as a user of a device.
Actually, no. If you just want to replace the operating system, you're good to go. Modern android phones display the public key of the kernel when booting a non-OEM ROM and bootloader has been re-locked. (granted, pretty much noone does that)
A good thing, IMHO.
"Insecurity is freedom."
"Those who give up freedom for security deserve neither."
I’m sure most people are prepared to give up the freedom of easy access to their house in order to require access with a key, as a fair trade off of security.
That isn't the case with these locked-down systems.
In general, it's funny how security bods sometimes worry about attackers modifying the hardware when the attacker could achieve the same thing more easily by completely replacing the hardware.
(Is that really your phone that you just entered your passcode into, or is it an identical phone modified so as to transmit the passcode to the thief who just substituted one for the other?)
Because there are several limitations with the PC boot process. See the heads project for what a reasonably secure PC boot would look like.
>The phone should at least always be unlockable by a single switch in the developer settings
True. That's a business thing. Not technical. Buy pixels in general for fewer hassles. Also, not just unlockable, but also re-lockable with custom keys. Again, only pixels support this.
>the whole idea of a system partition and data partition etc is just stupid
It's not. System is readonly. It reduces the attack vector significantly. Also makes block based updates simpler, and allows other security features like dm-verity. If anything, traditional desktop OSes are trying to move towards this direction. Look at Fedora's atomic workstation/silverblue.
I've had far less (as in, zero) luck with Qualcomm and Broadcom; they publish sources, but there is basically no documentation beyond that.
Not saying that I agree with the method, but I see why they're doing it.
I wanted almost the same thing so I built Maru: https://maruos.com
Maru runs Linux in a container alongside Android so you can have the best of both worlds. Hook up to an external monitor with a BT keyboard and mouse and you have a full Debian-based desktop at your disposal.
Maru only supports older hardware (Nexus 5, Nexus 7) at the moment, but newer devices (Nexus 5X/6P, HTC 10, Moto Z2 Force, Galaxy S9) have working ports on our forum and should have official images available soon: https://groups.google.com/forum/#!forum/maru-os-dev
We're an open-source project too, so you can even attempt your own port if you own an unsupported device: https://github.com/maruos/maruos
The article suggests that the boot process has been simplified, but as an outsider it still looks astoundingly complex, and the "random oem additions that are likely to be insecure" part is absolutely terrifying.
Am I wrong?
If this isn't illegal (the warranty part), it should be.
Hardware warranty shouldn't be generally affected, unless it's about parts that can fail because of software malfunction - e.g. when failsafes are defined in user-overridable software. It is fair that a hardware vendor shouldn't be responsible for user e.g. overclocking something.
Software warranty should be voided. Although I can't remember when it was the last time I saw a warranty for software, explicit or implied. Rather, I believe there's an explicit dismissal of any warranties in every single licensing agreement out there.
As an aside, LineageOS seems to have been getting gradually more buggy on my Nexus 5X. 15.1 has the two issues above, plus Bluetooth music streaming is broken and crashes the music player. I reverted to an old 14.1 ROM and everything works perfectly.
I have none of those problems with 15.1 on my nexus 5x, but I also make it a point to install the latest weekly updates and the latest vendor partition blob.
- Get latest nightly build from lineageos.org
- Get matching factory image from Google and extract vendor and radio images from it
- Install TWRP
- Do a full wipe of the phone
- Install LineageOS, vendor image and radio image
Then when an OTA update came out, I'd install it and update the vendor image manually if it complained.
What'd I miss?
Yea it's incredible how long the battery lasts on this device, compared to previous nexus devices (though I never owned a nexus 5..) I've only ever run lineageos on this thing and regularly get multiple days on a charge with light/moderate usage. I once took it on a 8 day backpacking trip where it was powered on but in airplane mode (to serve as camera and backup map), got out of the wilderness with something like 40% battery left. IMHO that really shows how much negative impact on performance google's shit has on a mobile device when it can last that long without it.
Come on. If you modify the device to work in a way it wasn’t intended (eg overclocked) you have clearly voided the warranty. This is what this is there to detect.
You are moving the goalposts, because we were talking about "changing the ROM", not about "changing the ROM and then doing something that will fuck the hardware up"
By the way, if you fuck up the CPU by overclocking it I guarantee they won't notice it because they will just throw the entire motherboard away. The subcontracted company that fixes your mobile (it's almost never the manufacturer) won't spend their time doing some CSI on it.
There were car makers voiding warranties when users replaced a tire. They gave the same arguments: Users modifying the car might do anything, so better give them no chance, as nobody could ever walk safely on the streets again.
Wiser heads prevailed, and e.g. the USA created the Magnuson-Moss Warranty Act. It is today legal to replace tires on your car. It is nevertheless illegal to make it non-street-worthy. If you stupidly damage your car while replacing a tire, you do in fact void your wararanty. If reality isn't clear enough, a judge decides. While streets might not be that safe, it is extremely rare that modified vehicles are part of the problem. The system works.
Why do we have to rediscuss all of this again? Exactly the same idea is applicable to software.
The important point is that the second of your changes is the one that voided the warranty: Replacing the tire to run in an unsafe way will void your warranty too. Modifying the ECU, on itself, doesn't do anything to the warranty.
And it is up to the manufacturer to prove your specific modification is unsafe. Claiming that some parts are inherently so complex that any change voids your warranty is legal bullshit for cars.
If I understand your argument well, it is that for cell phones the OS is so complex that any person on this planet should be declared unfit to make changes to it, except the manufacturer.
* First of all, the very audience of this site disproves this statement. Note the 'hacker' in hacker news.
* Second, I invite you to take a look to the garbage you find in most software powering our hardware. Someone going trough the effort to examine a device and create a modification is almost guaranteed to create better quality. There is something Darwinian going on here: Software mods, when they are supported for some time, give by their very existence away something of the persistent and qualified nature of their creator (otherwise they would not have been published).
* Third, the nature of software is that it is hard to create and easy to copy. Only 1 person has to create the firmware modification. The rest of us can copy it. This is exactly the reverse of the tire example and makes firmware mods a lot more easy.
UPDATE: After rereading, this post sees a bit harsh and a personal attack. So let me add that I have respect for your 2 posts. You provide a valid viewpoint in a reasonably toned, adult post. I also respond to more than can be found in your posts alone. I disagree with people downvoting you. I do however respectfully believe your viewpoint is incorrect and dangerous.
This is a lie sold to you to convince you to give up control to the manufacturers, to make a warranty a flimsy and easily discarded thing. Their products are getting lower in long term quality and reliability each year, but they don't want to take responsibility for them.
If you modify your cars engine increasing the pressure in the cylinders beyond what they are designed to handle you have voided the warranty, and wouldn’t be covered when the seals fail etc.
Your warranty covers the intended use cases. It does not cover you t do what ever you want...
OnePlus' oxygenOS which they ship on the 3, 3T, 5, and 6 is very close to cyanogenmod in functionality and no-bullshit-added android experience.
https://forum.xda-developers.com/showpost.php?p=76423626&pos...
https://forum.xda-developers.com/showpost.php?p=76511525&pos...
(Citation: https://techcrunch.com/2017/10/15/user-outcry-prompts-oneplu...)
I understand that once set, it can't be restored.
My question: could some of the earliest priviliged states decide to burn unburnt fuses of the public key? or is there an extra special root fuse which only allows burning the key fuses if it isn't yet burnt, and which is burnt as soon as the root public key is burnt?
This may seem irrelevant if we don't have access to the privileged states, but perhaps with hardware vulnerabilities as we have been seeing more and more, it may conceivably be possible to force it to run code to burn an unburnt fuse of the key. I.e. perhaps we can set bits in the public key such that the new key is easier to factor? (in case of say RSA)
EDIT: if this is possible we could sign our own root bootloader
You burn the bits "0001" into some fuse bank, which is mirrored in an anti-fuse bank that now equals "1110".
You can burn the unburned fuses in the normal bank, but can't unburn them in the antifuse bank.
I actually thought of that, but it seems rather inefficient compared to a single fuse, unblown before writing a key, blown after written key is verified as correctly written, once blown no fuses for this key can be blown...
But I don't know if they actually use such a system, or perhaps they simply assume the attackers never get fuseblowing privilege, and perhaps they assume that a key in a blown set of fuses is no longer rewritable...
a lot gets built into these 'cannot be undone' moments. The cryptech people talked about building large capacitor circuits into their design to be charged up and blow the secure keystore if the tamper switch went "bing" but I always wonder if you could eg use a electron microscope to reverse engineer the keystore state before it was wiped.
For easier chips like TPMs(Trusted Platform Module). What I've seen people do when trying to steal secrets(key) on a chip is to buy multiples of the same chip. On each chip expose the layer under a microscope(A chip exist of multiple layers, thats why we need multiple chips). Now, you know everything to reverse engineer the secrets. There exists tools for drilling and probing each trace on the chip. Here is an example. https://www.youtube.com/watch?v=h-hohCfo4LA
I think what you mean by charging a huge capacitor and blowing up the secrets. You refer to an HSM(Hardware Security Module). They typically have sensors to detect any fraudulent behavior. They are much harder hack. But there is always holes in each HSM. I think hackers use the same technic there as well. Buy multiple HSM to figure out the design. Reverse engineer the traces and try to probe without being detected on the target device. To my knowledge there are currently no sensors that are 100% bullet proof. They can either be fooled or have weak spots.
Or use X-ray tomography: