Live data from Hacker News

Serious flaws in the way Samsung phones encrypt key material in TrustZone

twitter.com

51–60 of 91 posts

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#51
post #6

I personally don't like how it's possible to store data on my device without me being able to access the data. Also most of the time these keys are used for DRM. So... good IMO.

The security of the system is entirely because this key material cannot be extracted.

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.

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#52
post #43

i have a samsung phone for about two years now. it reinds me to update the system all the time, almost every month. i dont do the update now. i just ignore it, i dont need fancy new features. i love it not being that smart. i love it the old way.

Those are monthly security patches. Really unwise to ignore.

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#53
post #15

Earlier quoted context omitted.

The user positive use is securely booting to a password prompt to decrypt your data. Without this security working, anyone who steals your phone will be able to get all the data you have saved on it.

That's kind of the thing with Microsoft's bitlocker as well. It automatically decrypts the hard drive on boot, so the only thing it could protect you from is someone removing the hard drive and mounting it somewhere else. But if they have physical access to the device, why would they do that?

I think the idea is that Windows' security, once booted, is enough to protect your data. It's the same situation if, for example, your laptop gets stolen while in sleep / on the lock screen.

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...

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#54
post #14

Earlier quoted context omitted.

True, Samsung makes a big deal of it. But they don’t actually deserve that title imo. They’re hardly a worthy contender. I am not an apple fan boy, but Samsung is just nowhere close to the apple experience.

Well, I own a few Samsung devices. There is no Samsung experience. I don't bother signing in into a Samsung account or using their store. What for? I already have to be signed in into Google's store to get updates for the apps I must use. Samsung's one is useless and it's not the reason I bought from them. I bought an A40 because it was the smallest Android phone on the market (and yet almost one inch too tall) and a…

> and a tablet (S5e?) because it had Linux in DeX.

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.

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#55
I am pretty surprised how they allowed reusing IV. Unique IV is explicitly mentioned to be an assumption for AES GCM (first sentence in security section of AES-GCM wikipedia page)

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?

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#56
post #52
post #43

i have a samsung phone for about two years now. it reinds me to update the system all the time, almost every month. i dont do the update now. i just ignore it, i dont need fancy new features. i love it not being that smart. i love it the old way.

Those are monthly security patches. Really unwise to ignore.

They are system patches, which may include security patches. That doesn't make it more wise to ignore, but it does become easier to imagine why you would.

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#57
post #6

I personally don't like how it's possible to store data on my device without me being able to access the data. Also most of the time these keys are used for DRM. So... good IMO.

Exactly my first thoughts. Key is derived from "user-controlled data". That makes sense, it's my phone, isn't it? Why would the phone need to encrypt data in a way that the user can't access it.

No, what you want is a random key. The security properties of an n-bit key depend entirely on those n-bits being random. Derived from user data is not (A CSRNG is not secure if the initial state is predictable).

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).

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#58
post #15

Earlier quoted context omitted.

The user positive use is securely booting to a password prompt to decrypt your data. Without this security working, anyone who steals your phone will be able to get all the data you have saved on it.

That's kind of the thing with Microsoft's bitlocker as well. It automatically decrypts the hard drive on boot, so the only thing it could protect you from is someone removing the hard drive and mounting it somewhere else. But if they have physical access to the device, why would they do that?

Physical access does not imply easy arbitrary code execution.

Consoles are largely protected by the same technology, how often do you see people achieving code execution on them by tampering with the hardware?

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#59
post #4

Earlier quoted context omitted.

Their entire value proposition (as marketed by themselves) is as an alternative to Apple. For some people that is enough.

True, Samsung makes a big deal of it. But they don’t actually deserve that title imo. They’re hardly a worthy contender. I am not an apple fan boy, but Samsung is just nowhere close to the apple experience.

> but Samsung is just nowhere close to the apple experience.

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.

Re: Serious flaws in the way Samsung phones encrypt key material in TrustZone

#60

I am pretty surprised how they allowed reusing IV. Unique IV is explicitly mentioned to be an assumption for AES GCM (first sentence in security section of AES-GCM wikipedia page) 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?

> 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...

Post reply on HN