51–60 of 132 posts
Now if only it was possible to turn off remote installation of applications on both iOS and Android devices, this kind of security would actually mean something. Right now, you can do full disk encryption on an Android device (which seems likely to become hardware-assisted on future devices similar to the solution mentioned in the article). If you pick a sufficiently strong passphrase, that should keep your data secu…
Earlier quoted context omitted.
The problem is the attack surface for an app on a device vs. in the wild is much, much larger and much, much less secure. Once its on your phone, it can just screenshot things if nothing else.
Android requires root privilege and/or system-level app to take screenshots. iOS is probably similar. I don't think an app could spy like this without user enabling it (which is a valid but separate concern about how knowledgeable the average rooter/jailbreaker is.) [0] http://android.stackexchange.com/questions/10930/why-do-we-n...
======
Using hardware partners
Now we get into the solutions which require commercial action.
Talking to the Android chipset makers often presents a solution. Since they design the hardware, they have access to the framebuffer - and they often are able to provide libraries which entirely avoid the Android permissions model by simply accessing their custom kernel drivers directly.
If you're aiming at a specific phone model, this is often a good way forward. Of course, the odds are you'll need to cooperate with the phone maker as well as the silicon manufacturer.
Sometimes this can provide outstanding results. For example I have heard it's possible on some hardware to pipe the phone hardware framebuffer directly into the phone hardware H.264 video encoder, and retrieve a pre-encoded video stream of whatever is on the phone screen. Outstanding. (Unfortunately, I only know this is possible on TI OMAP chips, which are gradually withdrawing from the phone market3).
======
Probably not something an average crapware author can do, but certainly within reach of the NSA.
> The Secure Enclave is designed to prevent exfiltration of the UID key. On earlier Apple devices this key lived in the application processor itself, and could (allegedly) be extracted if the device was jailbroken and kernel patched. Speaking as a jailbreaker, this is actually incorrect. At least as of previous revisions, the UID key lives in hardware - you can ask the hardware AES engine to encrypt or decrypt using…
Technically, this sounds about right (am mostly a n00b though) but the comments on this thread seem to me terrifyingly naive for a post-Snowden world. Apple has semi-convincingly denied the presence of a few, very specific attack vectors, and the article is speculating about the details of those denials, which is all well and good. But it is an absolute certainty that communications technologies built and operated by…
Also look at the sworn affidavit that EFF obtained from local SF bay area whistleblower Mark Klein -- an AT&T technician who revealed the existence of the NSA's fiber taps at the 2nd & Folsom Street SF facility.
There is no such entity as "major American industry." There are different companies with different incentives and different willingnesses to protect their users. Some companies do the right thing; others don't.
Earlier quoted context omitted.
I've been thinking about the possiblity of commercial software updates being used as an attack vector to overcome WDE. Could you imagine if the NSA went to Apple or Microsoft and said "push this compromising update to computers from this IP address/MAC address/serial number"?
That's quite possibly no longer a theoretical scenario at this point. It would really surprise me if you were the first person to think of that trick (it's pretty obvious) and that + gag orders would do nicely. Parallel construction to plug any holes in case someone wises up that this is already done in practice.
> The Secure Enclave is designed to prevent exfiltration of the UID key. On earlier Apple devices this key lived in the application processor itself, and could (allegedly) be extracted if the device was jailbroken and kernel patched. Speaking as a jailbreaker, this is actually incorrect. At least as of previous revisions, the UID key lives in hardware - you can ask the hardware AES engine to encrypt or decrypt using…
Technically, this is where it breaks down. As in "Trust me I don't store the keys."
If that hypothesis is true(they don't store these keys), then they'll have a hard time breaking your encryption indeed. But you must trust Apple at that point.
If there was a way to buy an anonymously replaceable chip with this cryptographic key in it and replace it on the phone like a SIM, then we'd be much closer to stating "Apple can't decrypt your phone".
> (Apple pegs such cracking attempts at 5 1/2 years for a random 6-character password consisting of lowercase letters and numbers. PINs will obviously take much less time, sometimes as little as half an hour. Choose a good passphrase!) Do not use simple pin passwords on your phone. In particular, if you use fingerprint access, there is no reason not to have a long, complex password.
Your advise is good, I'm not trying to dismiss or counter it. > In particular, if you use fingerprint access, there is no reason not to have a long, complex password. Very, very often my fingerprint isn't recognised properly and I have to type in my password. It has been getting better as of the last few updates, but I still need to input my password multiple times per day.
> Apple doesn't use scrypt. Their approach is to add a 256-bit device-unique secret key called a UID to the mix, and to store that key in hardware where it's hard to extract from the phone. Apple claims that it does not record these keys nor can it access them. Technically, this is where it breaks down. As in "Trust me I don't store the keys." If that hypothesis is true(they don't store these keys), then they'll have…
If someone obtains your phone, and prevents you from initiating a remote wipe (perhaps they have you in custody, or perhaps they have isolate the phone so that it cannot receive the wipe command), it sounds like this technology will do a good job of preventing them from decrypting your data from the phone if you have a decent passcode. They cannot throw GPUs or FPGAs or clusters or other custom hardware at the proble…
1. [...] 2. [...] 3. [...] 4. [...] 5. The manufacturer of the A7 chip stores every UID for every chip. I'm a total layman, but the UID has to be created at some point and so it can be known by someone. Wouldn't it be the easiest way to just record it for every chip? Apple wouldn't even have know about it.