Serious flaws in the way Samsung phones encrypt key material in TrustZone
twitter.com
twitter.com
In theory, you shouldn't be able to get the key while booting on some other media (say, your own Windows USB drive).
> Ensuring the integrity of early boot components and boot configuration data. On devices that have a TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to make data accessible only if the computer’s BIOS firmware code and configuration, original boot sequence, boot components, and BCD configuration all appear unaltered and the encrypted disk is located in the original computer. On systems that leverage TPM PCR[7], BCD setting changes deemed safe are permitted to improve usability.
https://docs.microsoft.com/en-us/windows/security/informatio...
Consoles are largely protected by the same technology, how often do you see people achieving code execution on them by tampering with the hardware?
Also, consoles are "protecting" not the user, but the manufacturer - which is exactly the point people are trying to make.
What hardmods do you know of for current gen consoles? Even the previous generation mostly fixed all public hardware based attacks.
This is standardized hardware that would be a relatively soft target to build tooling against, yet modchips are essentially dead because the attacks are just far too difficult.
That there are still no good attacks for the xbox one speaks volumes.
The way security on modern devices with h/w support work is that a random key is generated in hardware. Subkeys are derived from that. Access to these keys (if they're ever directly exposed) is gated on the correct password, but nothing is actually protected by it.
This is what you want as it means you don't have to make a password that is maybe 50 characters long, and actually random (e.g. no word sets).
Google "Intel Management Engine" or "AMD PSP" or "ARM TrustZone".
The last of these could, in theory, be less bad, except no ARM licensee except Rockchip (and maybe Apple -- jury is still out there) has chosen the "be less bad" option.
Being able to open a Diffie-Hellman encrypted, mutual-signature-authenticated channel to a remote device to then receive an AES key for disk encryption is far better than some TPM header that can easily be sniffed with physical access.
Would be even better if NVMe SSDs were able to authenticate themselves and let you transfer in a key over a DIffie-Hellman channel so sniffing the PCIe bus wouldn't deliver the key (or a non-PFS-encrypted encapsulated form of it) to an attacker. The speeds of NVMe SSDs unfortunately prevent LUKS from being cheap, and TCG Opal is kind of a joke from a security standpoint (doesn't even (seem to) specify that the provided "password" is used to derive a key, suggesting that it may just be used via a password hash to compare against a database entry to decide whether to unlock a disk encryption key).
Even TPMs don't seem to encrypt the communications channel they use with the CPU/PSP, and they are often socketed which makes MITM attacks easy with physical access. If they'd offer Java Card, they'd at least be somewhat useful...
(I'm not hapy with the x86 situation either, but it's still less bad)
I don't know how Samsungs trust zone implementation works, but the Apple secure elements (Ax,Mx,and T2 coprocessor) burn fuses randomly inside the SoC on first power up. Those fuses are used to further encrypt everything down the line from that. There are APIs on macOS+iOS to create asymmetric keys where the private key is handled by the secure element and cannot ever be extracted. Encryption (or signing) using those keys is performed by the coprocessor.
This is the model you want from any "hardware wallet" you might have, and is the model you want to actually secure your data.
How could anyone design TA (i.e application whose whole point is security and hence it runs in the secure mode) and allow user to set IV in the API?
I mean... TLS did the same (in 1.2, it was fixed in 1.3). I co-authored a paper about it: https://www.usenix.org/conference/woot16/workshop-program/pr...
My understanding is that TLS spec did not enforce non-repeating nonce, only suggested it and left it to implementers to decide which led to the vulnerabilities you explored.
This Samsung one here is in a way similar - the TEE API had a way for users of the API to set IV which it should not, TA should make sure the IV is not repeated.
Since you have done prior research in this area, is using a counter for IV still recommended even when IV is 12 byte? I assume chances of HW random number generator (which I assume exists on most phones today) colliding for 12 byte random number generation would be pretty low.
The NSA gave up on back doors, limiting the key size, etc. because people are too stupid to manage keys correctly.
For some people that is enough.
By the way, I keep Google usage minimal. I don't need most of their services. Even YouTube works without an account and I'm using NewPipe most of the time. What I really need is Play, only to update maps, Maps mostly because of satellite images (I use OSMAnd) and Translate as a dictionary. Syncthing and KDE connect deal with backup and file transfer.
Is that still a thing? A few years ago I was interested in that, as an alternative to a laptop, but I seem to remember that it was on the way out.
True... they're only the next closest. After fleeing the Google ecosystem, my only seriously choices were Samsung or Apple.
I do miss the Android OS, but not going back to the bloat and data-vacuums that are intertwined with it.
I bought good OLED and still, I had to connect pihole to block ads...
New LG's are even worse. I don't know what I do if my current TV will stop working.
I want only display, I don't want any additional features (ads, personalization etc.).
For example the Sony web site doesn't seem to support what you are saying
https://www.sony-asia.com/electronics/support/articles/00113...
I set up my grandmothers sony tv last year without Internet.
https://www.bestbuy.com/site/questions/sony-77-class-bravia-...
So assuming you are software savvy enough to not have missed the correct prompt, I have to assume there was a bug with the firmware version you recieved.
Some people like my 92 year old Grandmom don't have internet, and it would make no sense for Sony to have to deal with returns from them.
That’s what you want.
I'd argue this is what parent wants instead...
Samsung makes perfectly good hardware. They just destroy it with their software.
Probably why I don't carry one.
Real shame they are not allowed to make Android phones anymore. I genuinely believe Samsung is a bigger security and data leakage threat nowadays than Huawei was a few years ago
Harmony OS for phones is a fork of Android.
Which isn't any better IMO. Most recent Pixels have been a buggy mess from launch. Google doesn't see to give a damn about the quality of their devices which is especially bad considering they come at flagship prices.
On the other side, my mom's cheap Samsung A52 has been great so far.
The first Pixel was reasonably solid all around and mine lasted quite a while. The Pixel 2 XL’s terrible screen was my first hint that Google was not prepared to carry the torch of a true flagship phone.
That said: I would still often prefer the accidentally broken Pixel phones over the intentionally gimped and bloated Samsung phones. I just can’t buy one at launch, because I have no idea how Google will have fucked it up this time.
I've heard a lot of complains from Pixel 4a and 6 owners though, about bugs in the OS and drivers... Not sure if these issues are widespread or not.
And let's not forget Tizen, who security researchers basically found to be a joke.
To some extent I'd say User Experience is directly correlated with how valuable software engineers are in that particular society.
That’s a fairly good reference for the experience.
I could totally imagine something like Google Translate missing a critical not or similar that completely changes the meaning of a sentence. For technical documentation, that could be a huge problem.
Also, totally not relevant to the article.
Stock Android already contains energy saving mechanisms that work reasonably well. By piling potentially broken additional battery saving mechanisms on top of that, you risk breaking the phone for certain use cases. At the very least, as a user of that phone, there should be an easy way to exclude certain apps from energy saving measures. (Let's pick out Huawei again, where even if you added an app to such exclusion lists, after a few days the OS would randomly remove the app from that exclusion list again. Plus, there was some kind of "lock" that you could activate in the app switcher, but that lock wouldn't survive a reboot.)
Because some of the energy saving measures are so extreme, some manufacturers put popular apps on internal exclusion lists. These apps work fine, but apps by smaller developers don't. This is a major source of market distortion.
Huawei used to be the worst offender in this space, but it has gotten a little bit better by now. Nokia also had a phase where they had a horribly broken energy saver, but thankfully they got rid of that. Samsung has gotten worse and worse over the last years.
As DontKillMyApp notes, "the latest feedback suggests even when you remove an app from the restricted list, Samsung may re-add them later after a firmware update or when it thinks it is using too much resources". That is horrible.