In a cellphone, the radio is the worst of the bunch. It has the ability to snoop on the main CPU and controls the boot process.
I've heard that said by many people, but as far as I can tell by examining the architecture of the devices I've worked on, it's not true. The baseband radio does have DMA access, like most every peripheral, but it doesn't have any special sort of access to the CPU.
the thing is, 99% of the malware you run into is run-of-the-mill stuff.
Which Windows' built-in antivirus protection will stop.
not running AV because some researcher are doing next-level shit is like not wearing your seatbelt because a sniper might get you.
Nonsense. There's nothing "next level" about this. What Tavis found is that running vulnerable A/V software adds a large and easily-exploitable attack surface to your system. The fact that most current-generation malware isn't exploiting these bugs yet doesn't mean they won't, soon.
Tavis Ormandy has uncovered a shit-ton of serious vulnerabilities in some big name AV / Endpoint Protection products. Great! Those will get fixed and life goes on.
And how many more will be added? A/V software adds attack surface to your system, running at high priority. That's bad. In the past it was a net win because the base OS did nothing to protect against malware, but that's no longer the case. Does Symantec actually provide additional protection over Windows Defender? If so, how do you balance that against the additional risk it adds?
This friends is the slashdot of old, where you you could get intelligent, in depth information from an engineer close to the source, or an astronomer talking about mods to their statistical analysis packages.
There was always a political echo chamber and a certain level of douchbaggery, but this is what made the site shine. I have been here in various guises since 97 or so.
Thanks again for helping keep this place great.
Thanks. That is exactly what always made me love slashdot, and it's mostly those memories that keep me around, I think. I'm glad I could contribute in this case.
Just to be clear, I don't like or support the presence of opaque binaries in systems. One of the things I'm trying to achieve in the Android ecosystem is to move OEMs to using open source code in TrustZone. There is tremendous security value in having a trusted execution environment which is small and isolated, because making full consumer OSes secure is simply impossible, but having the code in that TEE be closed doesn't add anything to the security proposition, and arguably reduces it. That's why Google has Trusty, and why the OS and apps are developed directly in AOSP.
One of the things on my to-do list (far down the list at the moment, given that hardly any devices use Trusty) is to find ways to enable (technically-capable) users to verify that the TEE software running on their device matches the source code. In addition, users should be able to sign and install their own TEE software, as well as their own non-secure world software. The Nexus devices have always allowed the latter, but the TEE has been solely controlled by the SoC vendor. The only exception to that, as far as I know, is the Pixel C tablet from Google. It uses a hardware switch analogous to (and based on) the "dev screw" in Chromebooks. If you flip that switch then you can install your own verification keys for both system and TEE. Your TEE OS won't have access to the DRM keys baked into the hardware, of course, but outside of that limitation you can do whatever you want in the TEE.
Of course, there are a lot of other opaque, highly-privileged binaries in mobile devices. Almost all of the firmware for radios, GPUs, GPS, etc., etc., is all closed, proprietary code written by the component manufacturer and kept secret even from the OEMs. I don't have any idea how we can fix that.
Quitting without giving notice is rude. That's all, just rude.
As your subject line says, it depends. Think about it carefully, because your attempt to be nice may cost you if your employer decides to be rude. That happened to me, when I left IBM. My manager (who was a jerk, worst I've had in 25 years, and a big part of the reason I decided to interview elsewhere) got pissed when I called him on a Thursday afternoon to give him my two weeks' notice. He said "fine, tomorrow is your last day". That sucked because I'd planned out my start date at my new employer so that I wouldn't have a gap in pay or insurance coverage. My new employer couldn't move my start date up, so I ended up with a two-week gap.
Not that two weeks without pay killed me, especially since I was getting a nice raise out of the move, and I could have used COBRA (retroactively, even, you have 30 days, IIRC), if I'd had any big medical expenses. But it was annoying, and in hindsight I should have recognized how my manager was going to react and given much less notice. If any.
The uncovered flaw is entirely an Android software issue, wherein an attacker with malware or a 0-day priviledged exploit can silently [...]
So... to gain access, they need to already get root access to the device?
Sorry to break it to you, but once they got root, it's game over.
For keys managed by the Android/Linux system, that's true, which is why the encryption in question is deprecated and slated for removal. Keys managed in the trusted execution environment are not compromised by rooting, in the sense that the attacker cannot extract the raw key material, and can't direct the TEE to perform any operations with the key that aren't permitted by whatever access controls are enforced in the TEE.
To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself, although the effect is the same. Samsung has some non-Qualcomm chipsets (Exonos) used on some of their phones and those are apparently not affected.
I'm the Google engineer responsible for Keystore.
What you're talking about is a different (and more serious) issue, related to "hardware-backed" keys. The just-published paper is about a weakness in a software-only legacy method that was put in place to provide minimal protection of keys on devices that lacked any reasonable option for device encryption. It's something that I've been meaning to remove completely. It is applied only when apps specifically request it with KeyPairGeneratorSpec.setEncryptionRequired. Based on a scan of the Google Play store, almost no apps request it, and it was formally deprecated in Android Marshmallow. Even if it didn't contain an error in its cryptographic construction, it provides very little security, because you have to root the device to get at the encrypted keys, and once you've done that you have all sorts of options to get at the plaintext.
The primary value in the Android Keystore is in hardware-backed keys: Keys that are generated and used only in the Trusted Execution Environment. Because those keys are (barring issues like the aforementioned Qualcomm TEE bug) never available to the Linux kernel or Android system, no break of the system security can enable extraction of the key material, which keeps the keys bound to the device. Moreover, in a major overhaul of Keystore in Marshmallow, Android Keystore gained the ability to enforce various other access controls to the keys; most of this enforcement is also done in the TEE, reducing the ability of an attacker who roots the device to use Keystore as a key oracle.
There is also some value in Android Keystore on devices without a TEE. Specifically, using Keystore keys rather than keys managed directly by the app moves the key material out of the app's process space, which means that any attack which manages to exploit some security defect in the app and gain access to the app's data can't get a copy of the key material. To do that, the attacker has to get root -- and, assuming "setEncryptionRequired" was used, also break this weak and (in the opinion of the Android security team) unnecessary encryption.
So, yeah. This encryption is broken. But it's unnecessary, deprecated and slated for removal anyway, so it doesn't matter. Which is exactly what I told the researcher when he reported the bug.
The Qualcomm TEE bug, on the other hand, is an issue. It's a fixed issue, but there's this old and very hard-to-fix problem that Android devices don't get security patches the way they should. Nexus devices are patched.
I know a retired police officer who teaches safety courses for concealed weapons permits in Florida. He recommends that you only volunteer such info to a police officer if retrieving your license or registration could reveal the firearm.
In passenger cars, nothing less than a 100% reliable, full-time autopilot function is acceptable
100% reliability is too high. Nothing is 100% reliable -- certainly not human drivers. It doesn't have to be perfect, it just has to be better than humans... which means it can't have modes where suddenly hands control back to the human and expects them to act appropriately. It's okay for it to decide in some situations (say, bad weather) that it isn't able to operate safely, but it has to be able to at least bring the vehicle to a safe stop before turning over control, so the human has time to understand the situation before being required to take control.
Not that I'm defending the shooting, but by now everyone knows what the police officer will want when they pull you over. Get your license out of your wallet and registration/insurance out of the glove compartment, and have them ready in your hands while the officer is walking towards your car.
No, don't do this.
Context: I'm a concealed carry instructor, and what I'm going to say is from the training I received from the state police when I got certified as an instructor.
Per the state police, here's what the cops want you to do when you're pulled over: Put your car in park, turn off the ignition and put your hands where they can see them. On the wheel, or on the dash -- or if you think the officer might have some particular reason to be worried, put them out the window. When the officer approaches, do not move your hands except as specifically requested. Don't rummage around in the glove box or anywhere else while the officer is approaching -- he has no way to know if you're getting your registration or a weapon. When he asks for your registration, tell him where it is before you reach for it and keep your movements reasonably slow and deliberate. No need to make a big production out of it, but avoid rapid, jerky movements.
If it's night, turn your dome light on so he can see inside the car.
Yes, that is a good suggestion.
Also, just for completeness, if you do have a concealed carry permit, know whether or not local law requires you to inform the officer. In my state (Utah) there is no legal obligation, but odds are he'll know (from running your plate) before he approaches, so it's a good idea to say something like "Officer, as a courtesy I want to inform you that I have Utah Concealed Firearm Permit and I am (or am not, as appropriate) armed." At least in my area, this generally makes the police quite happy with you. Most of them are big fans of lawful citizen carry, and it also means they know that you don't have a criminal record.
There is an important distinction though. If I do not control the code running in that processor (or trust zone), it *IS* inherently insecure for me. If I do control it, it may improve security or it might be neutral WRT security.
There's lots of code that you do not control running in every computing device you use. If you insist on that exceedingly strict definition, you should just avoid them entirely. Also, your assertion that if you do control it it's either neutral or positive is patently false. It is entirely possible to exercise control in ways that decrease your security. It's pretty common, for example, for people who root their Android devices to believe that they're improving their device security by taking control over it, when they've actually just poked gaping holes in the security model designed to protect them.
Code that you do not control may be good, bad or neutral from a security perspective. It depends both on the goals of the people who do control it, and on their ability to achieve their goals. Code that you do control may be good, bad or neutral. You know what goals you're trying to achieve, but there's still the question of your ability to achieve them.
No, what makes it "trusted" is that ARM and/or the chip vendor repeatedly tell you it is in press releases. There have been several attacks on TrustZone devices which take advantage of the fact that it's often very poorly implemented, and much less secure than the non-TrustZone stuff.
Utter nonsense. Go take a look at the CVE reports of vulnerabilities in the Linux kernel, and compare them to the CVE reports of TrustZone OS vulnerabilities. The kernel is two orders of magnitude worse. That's not because it's bad, or TZ code is good... I'll readily concede that kernel code is almost certainly higher in quality than closed-source TZ OSes. But it's also vastly larger and more complex, with so much more attack surface.
There are tons of free streaming music sites that cost nothing to listen to. I don't see any reason to pay a monthly fee to anyone.
The difference is that with Google Music (and similar subscription services), you choose specifically what you listen to, rather than just picking a category (however narrow). It's the difference between having a vast library of music to choose from, and listening to the radio. That difference may not be worth $10 per month to you, but it is for me.
Hell, you can even plant something on it, and then return it to them... turn it into the carrier or lost and found or the police or something; odds are they'll be so happy/surprised that it turned up again they won't even think that it was hacked.
Planting something on it isn't so easy if it's locked. But, really, you don't have to do that. Want to get into someone's phone? Here's how:
Buy an identical device. Get a good look at theirs so you can put similar scratches, cover, lockscreen background, etc. on it. Configure your device to send the password they enter to you. Steal theirs and leave yours in its place. When they enter your password, you get it and use it to get into their device. To keep it from being obvious that their device has been replaced, have it refuse to "unlock" no matter what they enter. This also helps you in the event they get their password wrong the first time, because they'll helpfully re-enter it. Meanwhile, they'll think their password on their phone has gotten messed up.
This works on *any* model... Android, iPhone, Windows phone, Blackberry... you name it.
Oh yeah Grandma: "check the patchlevel of your device".
Well, the right answer is to buy a device that has a published support policy that includes monthly security patches. Then you don't have to check the patchlevel (which actually isn't tough, even for Grandma: It's just a date and she's perfectly capable of understanding it), because you know it's good. Maybe someday consumers will demand that of all Android devices. At present, they don't, and manufacturers give them what they want.
Can't this hole be closed by designing the trusted firmware so it requires that the passcode be entered before it will accept a firmware update?
Yes, but it's tricky, particularly because it's not that hard to open the device and write an updated firmware blob to flash directly, bypassing any software-based gatekeeping checks. There are ways to address that, but they raise subtle issues in turn, and ways to address those, but they raise more issues. At root, the existence of Replay Protected Memory Blocks in eMMC controllers makes it feasible to have small amounts of non-volatile storage that an attacker probably can't write to, which I believe makes it feasible. But it's far from simple, especially within all of the other performance, cost, testability and other constraints.
Why not just uncompressed the initramfs, load a binary or other tool to siphon off the users pw on key entry?
The kernel is unencrypted as the system needs to boot from it
If you modify the boot image on a Marshmallow device, the screen will notify the user during boot that verification failed. On a Nougat device I believe it will refuse to boot.
"Trusted" stuff cannot be trusted. It's called "trusted" because its maker trusts it to keep you from doing anything its maker didn't intend you to.
No, the only thing that makes it "trusted" is that it's small, and isolated. Those characteristics reduce its attack surface and reduce the number of bugs it has, on average.
I'll grant that the primary purpose of TrustZone in Android devices, historically, has been DRM, which is absolutely something the maker doesn't want you to muck with. That's not the case with Keymaster. If you want to know what it does, there's a full open source reference implementation in AOSP. That's not the implementation used in Qualcomm devices; they wrote their own and it's closed -- but it does as close to the same thing as what the reference implementation does as the engineers involved could make it. Some other devices do use the code from AOSP.
Don't use TrustZone; store the stuff as a proper LUKS volume and stop using "trusted" proprietary crap
TrustZone isn't proprietary; it's part of the standard ARM feature set. In many cases (not all[*]) the software running in it is. As for using an LUKS volume, the problem with that is that it's no more secure than the Linux kernel, which is popped by another security researcher every week. The kernel is so large and complex that hardening it is really difficult.
Can we just admit already that having supervisory-processor-within-a-processor stuff is inherently insecure?
No, because it's not.
The purpose of having TrustZone isn't that it's inherently more secure. It's still just software, and subject to all of the same kinds of problems as any other software. The reason we have it is because by keeping it very small and simple we can reasonably expect it to have fewer problems. It can still have vulnerabilities (as we see here), and it still needs to be updated. In fact the vulnerabilities used by this researcher have already been patched, and the updates already pushed out to devices.
The fact that TrustZone code isn't immune to bugs doesn't mean that there's no value in having a smaller, simpler, and isolated execution environment. In fact it highlights just why it's so important, because as vulnerable as it may be, the vastly larger amount of code running in the regular execution environment has orders of magnitude more attack surface, and orders of magnitude more bugs.
[*] Google's Trusty is a free, open source implementation of a TrustZone trusted OS. The F/LOSS Genode OS has also been used in TrustZone. There's no technical reason TZ code must be secret or proprietary. The makers of the most widely-used versions keep theirs proprietary, but that's a business decision, not something inherent to the concept of a trusted execution environment.
For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.
Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.
I agree, a house husband/wife/partner should have some type of financial trust just in case everything goes south (considering 60-80% of relationships fail that's to be expected).
That's what the divorce settlement and alimony is supposed to be for. At least, I assume that if I divorced my wife, she'd get half of what I own, plus I'd pay alimony for at least a few years.
Ah, just noticed that the poster was speaking of a girlfriend, not a wife.
Slashdot Mirror
In a cellphone, the radio is the worst of the bunch. It has the ability to snoop on the main CPU and controls the boot process.
I've heard that said by many people, but as far as I can tell by examining the architecture of the devices I've worked on, it's not true. The baseband radio does have DMA access, like most every peripheral, but it doesn't have any special sort of access to the CPU.
the thing is, 99% of the malware you run into is run-of-the-mill stuff.
Which Windows' built-in antivirus protection will stop.
not running AV because some researcher are doing next-level shit is like not wearing your seatbelt because a sniper might get you.
Nonsense. There's nothing "next level" about this. What Tavis found is that running vulnerable A/V software adds a large and easily-exploitable attack surface to your system. The fact that most current-generation malware isn't exploiting these bugs yet doesn't mean they won't, soon.
Tavis Ormandy has uncovered a shit-ton of serious vulnerabilities in some big name AV / Endpoint Protection products. Great! Those will get fixed and life goes on.
And how many more will be added? A/V software adds attack surface to your system, running at high priority. That's bad. In the past it was a net win because the base OS did nothing to protect against malware, but that's no longer the case. Does Symantec actually provide additional protection over Windows Defender? If so, how do you balance that against the additional risk it adds?
Russia isn't evil. Russians aren't evil. Putin most certainly is. He's like a Russian Donald Trump.
Trump is America's answer to Putin. America cannot be outdone by Russia, so Trump is our strategy to out-Putin Putin.
swilden, thank you.
This friends is the slashdot of old, where you you could get intelligent, in depth information from an engineer close to the source, or an astronomer talking about mods to their statistical analysis packages.
There was always a political echo chamber and a certain level of douchbaggery, but this is what made the site shine. I have been here in various guises since 97 or so.
Thanks again for helping keep this place great.
Thanks. That is exactly what always made me love slashdot, and it's mostly those memories that keep me around, I think. I'm glad I could contribute in this case.
Just to be clear, I don't like or support the presence of opaque binaries in systems. One of the things I'm trying to achieve in the Android ecosystem is to move OEMs to using open source code in TrustZone. There is tremendous security value in having a trusted execution environment which is small and isolated, because making full consumer OSes secure is simply impossible, but having the code in that TEE be closed doesn't add anything to the security proposition, and arguably reduces it. That's why Google has Trusty, and why the OS and apps are developed directly in AOSP.
One of the things on my to-do list (far down the list at the moment, given that hardly any devices use Trusty) is to find ways to enable (technically-capable) users to verify that the TEE software running on their device matches the source code. In addition, users should be able to sign and install their own TEE software, as well as their own non-secure world software. The Nexus devices have always allowed the latter, but the TEE has been solely controlled by the SoC vendor. The only exception to that, as far as I know, is the Pixel C tablet from Google. It uses a hardware switch analogous to (and based on) the "dev screw" in Chromebooks. If you flip that switch then you can install your own verification keys for both system and TEE. Your TEE OS won't have access to the DRM keys baked into the hardware, of course, but outside of that limitation you can do whatever you want in the TEE.
Of course, there are a lot of other opaque, highly-privileged binaries in mobile devices. Almost all of the firmware for radios, GPUs, GPS, etc., etc., is all closed, proprietary code written by the component manufacturer and kept secret even from the OEMs. I don't have any idea how we can fix that.
You're using some very unusual machines, then. Or you're mistaken about how many binary firmware blobs there are.
Quitting without giving notice is rude. That's all, just rude.
As your subject line says, it depends. Think about it carefully, because your attempt to be nice may cost you if your employer decides to be rude. That happened to me, when I left IBM. My manager (who was a jerk, worst I've had in 25 years, and a big part of the reason I decided to interview elsewhere) got pissed when I called him on a Thursday afternoon to give him my two weeks' notice. He said "fine, tomorrow is your last day". That sucked because I'd planned out my start date at my new employer so that I wouldn't have a gap in pay or insurance coverage. My new employer couldn't move my start date up, so I ended up with a two-week gap.
Not that two weeks without pay killed me, especially since I was getting a nice raise out of the move, and I could have used COBRA (retroactively, even, you have 30 days, IIRC), if I'd had any big medical expenses. But it was annoying, and in hindsight I should have recognized how my manager was going to react and given much less notice. If any.
The uncovered flaw is entirely an Android software issue, wherein an attacker with malware or a 0-day priviledged exploit can silently [...]
So... to gain access, they need to already get root access to the device? Sorry to break it to you, but once they got root, it's game over.
For keys managed by the Android/Linux system, that's true, which is why the encryption in question is deprecated and slated for removal. Keys managed in the trusted execution environment are not compromised by rooting, in the sense that the attacker cannot extract the raw key material, and can't direct the TEE to perform any operations with the key that aren't permitted by whatever access controls are enforced in the TEE.
Good news, Thanks!
I recently got the Marshmallow update on my Alcatel phone, so I should be all good.
Marshmallow doesn't fix this broken encryption; we just decided in Marshmallow that since this is not useful we should deprecate it.
To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself, although the effect is the same. Samsung has some non-Qualcomm chipsets (Exonos) used on some of their phones and those are apparently not affected.
I'm the Google engineer responsible for Keystore.
What you're talking about is a different (and more serious) issue, related to "hardware-backed" keys. The just-published paper is about a weakness in a software-only legacy method that was put in place to provide minimal protection of keys on devices that lacked any reasonable option for device encryption. It's something that I've been meaning to remove completely. It is applied only when apps specifically request it with KeyPairGeneratorSpec.setEncryptionRequired. Based on a scan of the Google Play store, almost no apps request it, and it was formally deprecated in Android Marshmallow. Even if it didn't contain an error in its cryptographic construction, it provides very little security, because you have to root the device to get at the encrypted keys, and once you've done that you have all sorts of options to get at the plaintext.
The primary value in the Android Keystore is in hardware-backed keys: Keys that are generated and used only in the Trusted Execution Environment. Because those keys are (barring issues like the aforementioned Qualcomm TEE bug) never available to the Linux kernel or Android system, no break of the system security can enable extraction of the key material, which keeps the keys bound to the device. Moreover, in a major overhaul of Keystore in Marshmallow, Android Keystore gained the ability to enforce various other access controls to the keys; most of this enforcement is also done in the TEE, reducing the ability of an attacker who roots the device to use Keystore as a key oracle.
There is also some value in Android Keystore on devices without a TEE. Specifically, using Keystore keys rather than keys managed directly by the app moves the key material out of the app's process space, which means that any attack which manages to exploit some security defect in the app and gain access to the app's data can't get a copy of the key material. To do that, the attacker has to get root -- and, assuming "setEncryptionRequired" was used, also break this weak and (in the opinion of the Android security team) unnecessary encryption.
So, yeah. This encryption is broken. But it's unnecessary, deprecated and slated for removal anyway, so it doesn't matter. Which is exactly what I told the researcher when he reported the bug.
The Qualcomm TEE bug, on the other hand, is an issue. It's a fixed issue, but there's this old and very hard-to-fix problem that Android devices don't get security patches the way they should. Nexus devices are patched.
I know a retired police officer who teaches safety courses for concealed weapons permits in Florida. He recommends that you only volunteer such info to a police officer if retrieving your license or registration could reveal the firearm.
Yeah, know your local laws and practices.
Mostly, I agree with your post. Just one quibble:
In passenger cars, nothing less than a 100% reliable, full-time autopilot function is acceptable
100% reliability is too high. Nothing is 100% reliable -- certainly not human drivers. It doesn't have to be perfect, it just has to be better than humans... which means it can't have modes where suddenly hands control back to the human and expects them to act appropriately. It's okay for it to decide in some situations (say, bad weather) that it isn't able to operate safely, but it has to be able to at least bring the vehicle to a safe stop before turning over control, so the human has time to understand the situation before being required to take control.
Not that I'm defending the shooting, but by now everyone knows what the police officer will want when they pull you over. Get your license out of your wallet and registration/insurance out of the glove compartment, and have them ready in your hands while the officer is walking towards your car.
No, don't do this.
Context: I'm a concealed carry instructor, and what I'm going to say is from the training I received from the state police when I got certified as an instructor.
Per the state police, here's what the cops want you to do when you're pulled over: Put your car in park, turn off the ignition and put your hands where they can see them. On the wheel, or on the dash -- or if you think the officer might have some particular reason to be worried, put them out the window. When the officer approaches, do not move your hands except as specifically requested. Don't rummage around in the glove box or anywhere else while the officer is approaching -- he has no way to know if you're getting your registration or a weapon. When he asks for your registration, tell him where it is before you reach for it and keep your movements reasonably slow and deliberate. No need to make a big production out of it, but avoid rapid, jerky movements.
If it's night, turn your dome light on so he can see inside the car.
Yes, that is a good suggestion.
Also, just for completeness, if you do have a concealed carry permit, know whether or not local law requires you to inform the officer. In my state (Utah) there is no legal obligation, but odds are he'll know (from running your plate) before he approaches, so it's a good idea to say something like "Officer, as a courtesy I want to inform you that I have Utah Concealed Firearm Permit and I am (or am not, as appropriate) armed." At least in my area, this generally makes the police quite happy with you. Most of them are big fans of lawful citizen carry, and it also means they know that you don't have a criminal record.
There is an important distinction though. If I do not control the code running in that processor (or trust zone), it *IS* inherently insecure for me. If I do control it, it may improve security or it might be neutral WRT security.
There's lots of code that you do not control running in every computing device you use. If you insist on that exceedingly strict definition, you should just avoid them entirely. Also, your assertion that if you do control it it's either neutral or positive is patently false. It is entirely possible to exercise control in ways that decrease your security. It's pretty common, for example, for people who root their Android devices to believe that they're improving their device security by taking control over it, when they've actually just poked gaping holes in the security model designed to protect them.
Code that you do not control may be good, bad or neutral from a security perspective. It depends both on the goals of the people who do control it, and on their ability to achieve their goals. Code that you do control may be good, bad or neutral. You know what goals you're trying to achieve, but there's still the question of your ability to achieve them.
No, what makes it "trusted" is that ARM and/or the chip vendor repeatedly tell you it is in press releases. There have been several attacks on TrustZone devices which take advantage of the fact that it's often very poorly implemented, and much less secure than the non-TrustZone stuff.
Utter nonsense. Go take a look at the CVE reports of vulnerabilities in the Linux kernel, and compare them to the CVE reports of TrustZone OS vulnerabilities. The kernel is two orders of magnitude worse. That's not because it's bad, or TZ code is good... I'll readily concede that kernel code is almost certainly higher in quality than closed-source TZ OSes. But it's also vastly larger and more complex, with so much more attack surface.
There are tons of free streaming music sites that cost nothing to listen to. I don't see any reason to pay a monthly fee to anyone.
The difference is that with Google Music (and similar subscription services), you choose specifically what you listen to, rather than just picking a category (however narrow). It's the difference between having a vast library of music to choose from, and listening to the radio. That difference may not be worth $10 per month to you, but it is for me.
Oh yeah grandma: "buy a device that has a published support policy". Christ. No wonder Apple is selling so many iPhones.
Well, she knows to look at the warranty when she buys a car.
Hell, you can even plant something on it, and then return it to them... turn it into the carrier or lost and found or the police or something; odds are they'll be so happy/surprised that it turned up again they won't even think that it was hacked.
Planting something on it isn't so easy if it's locked. But, really, you don't have to do that. Want to get into someone's phone? Here's how:
Buy an identical device. Get a good look at theirs so you can put similar scratches, cover, lockscreen background, etc. on it. Configure your device to send the password they enter to you. Steal theirs and leave yours in its place. When they enter your password, you get it and use it to get into their device. To keep it from being obvious that their device has been replaced, have it refuse to "unlock" no matter what they enter. This also helps you in the event they get their password wrong the first time, because they'll helpfully re-enter it. Meanwhile, they'll think their password on their phone has gotten messed up.
This works on *any* model... Android, iPhone, Windows phone, Blackberry... you name it.
Oh yeah Grandma: "check the patchlevel of your device".
Well, the right answer is to buy a device that has a published support policy that includes monthly security patches. Then you don't have to check the patchlevel (which actually isn't tough, even for Grandma: It's just a date and she's perfectly capable of understanding it), because you know it's good. Maybe someday consumers will demand that of all Android devices. At present, they don't, and manufacturers give them what they want.
Can't this hole be closed by designing the trusted firmware so it requires that the passcode be entered before it will accept a firmware update?
Yes, but it's tricky, particularly because it's not that hard to open the device and write an updated firmware blob to flash directly, bypassing any software-based gatekeeping checks. There are ways to address that, but they raise subtle issues in turn, and ways to address those, but they raise more issues. At root, the existence of Replay Protected Memory Blocks in eMMC controllers makes it feasible to have small amounts of non-volatile storage that an attacker probably can't write to, which I believe makes it feasible. But it's far from simple, especially within all of the other performance, cost, testability and other constraints.
Why not just uncompressed the initramfs, load a binary or other tool to siphon off the users pw on key entry?
The kernel is unencrypted as the system needs to boot from it
If you modify the boot image on a Marshmallow device, the screen will notify the user during boot that verification failed. On a Nougat device I believe it will refuse to boot.
"Trusted" stuff cannot be trusted. It's called "trusted" because its maker trusts it to keep you from doing anything its maker didn't intend you to.
No, the only thing that makes it "trusted" is that it's small, and isolated. Those characteristics reduce its attack surface and reduce the number of bugs it has, on average.
I'll grant that the primary purpose of TrustZone in Android devices, historically, has been DRM, which is absolutely something the maker doesn't want you to muck with. That's not the case with Keymaster. If you want to know what it does, there's a full open source reference implementation in AOSP. That's not the implementation used in Qualcomm devices; they wrote their own and it's closed -- but it does as close to the same thing as what the reference implementation does as the engineers involved could make it. Some other devices do use the code from AOSP.
Don't use TrustZone; store the stuff as a proper LUKS volume and stop using "trusted" proprietary crap
TrustZone isn't proprietary; it's part of the standard ARM feature set. In many cases (not all[*]) the software running in it is. As for using an LUKS volume, the problem with that is that it's no more secure than the Linux kernel, which is popped by another security researcher every week. The kernel is so large and complex that hardening it is really difficult.
Can we just admit already that having supervisory-processor-within-a-processor stuff is inherently insecure?
No, because it's not.
The purpose of having TrustZone isn't that it's inherently more secure. It's still just software, and subject to all of the same kinds of problems as any other software. The reason we have it is because by keeping it very small and simple we can reasonably expect it to have fewer problems. It can still have vulnerabilities (as we see here), and it still needs to be updated. In fact the vulnerabilities used by this researcher have already been patched, and the updates already pushed out to devices.
The fact that TrustZone code isn't immune to bugs doesn't mean that there's no value in having a smaller, simpler, and isolated execution environment. In fact it highlights just why it's so important, because as vulnerable as it may be, the vastly larger amount of code running in the regular execution environment has orders of magnitude more attack surface, and orders of magnitude more bugs.
[*] Google's Trusty is a free, open source implementation of a TrustZone trusted OS. The F/LOSS Genode OS has also been used in TrustZone. There's no technical reason TZ code must be secret or proprietary. The makers of the most widely-used versions keep theirs proprietary, but that's a business decision, not something inherent to the concept of a trusted execution environment.
For devices that get regular updates the Qualcomm TrustZone bug has already been fixed. It went out in the January 2016 updates: https://source.android.com/sec.... Check the patchlevel date on your device.
Of course the other part, that someone who can compel Qualcomm to sign TrustZone software images that intentionally compromise security, is still the case, and likely will be for some time. That's a threat model that hadn't been considered important until recently, and it's one that's not easy to mitigate. That's not restricted to Qualcomm, either. In every device with a trusted execution environment, there's some organization who holds the signing keys needed to load firmware in that environment, generally (but not always) the SoC vendor.
I agree, a house husband/wife/partner should have some type of financial trust just in case everything goes south (considering 60-80% of relationships fail that's to be expected).
That's what the divorce settlement and alimony is supposed to be for. At least, I assume that if I divorced my wife, she'd get half of what I own, plus I'd pay alimony for at least a few years.
Ah, just noticed that the poster was speaking of a girlfriend, not a wife.