71–80 of 132 posts
Earlier quoted context omitted.
As far as I know, it can install an app but not run it (EDIT: on Android, that is). So it shouldn't be able to do any such decryption.
It could be an update of an app that runs by default, or an update of a core component of the OS.
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…
Yes, currently iCloud backups are not encrypted so they can be extracted by law enforcement, but on the other hand they are not mandatory, as Apple also offers a full local backup solution through iTunes (albeit, admittedly, they could make it work automatically like Time Machine, instead of manually; I guess they'll get there, now that they're using privacy in marketing). On the other hand, it is perfectly possible…
This is wrong. iCloud uses AES 128 and 256 encryption:
http://support.apple.com/kb/HT4865?viewlocale=en_US&locale=e...
I wonder, is it in the realms of possibility for big-budget organizations like the NSA to simply read the UID from the silicon by means of physical analysis (e.g. a scanning tunneling microscope)?
It's very probably within the realms of possibility , yes. It's very probably not within the realms of practicality just yet, however.
The only issue would be making the process so 100% reliable that you succeed first time, because a single mistake or misunderstanding could trash the single copy you have of the code.
I'm curious now if flylogic or chipworks have done any serious teardown of the 'secure enclave' stuff.
Earlier quoted context omitted.
There is an argument against using the fingerprint access and that is that a user gives up the right of consent while in custody. If law enforcement gets a judicial order to forcibly press the prisoner's finger to the sensor to unlock the device, then he or she has little recourse as the right to remain silent is not implicated. One cannot be similarly physically compelled to disclose a code only held in his or her m…
> One cannot be similarly physically compelled to disclose a code only held in his or her memory. Are you sure? In the UK and I'm pretty sure in my native Australia, they definitely can, under pain of "contempt of court".
Even under a mandatory key disclosure regime, it's still a choice to remain silent even if that means one remains jailed. That situation sure seems like a form of torture to extract information from the incarcerated individual.
This 2012 Forbes article is a good read on the matter: http://www.forbes.com/sites/jonmatonis/2012/09/12/key-disclo...
It could be a total lie, and hardwired or masked-rom per-revision (but I doubt that, too easy to discover)
It could be in a one-time programmable block somewhere that gets provisioned during manufacture - a flash block/eeprom with write-only access (externally at least), or a series of blowable fuses, or even laser/EB-trimmed traces.
All of those 1-time prog methods are susceptible to the person operating the programmer to record the codes generated, although managing and exfiltrating that much data would make it rather tricky.
The method of storage also influences how hard it is to extract through decapping and probing/inspection.
If I had to design something like this (note: not a crypto engineer), I'd have some enclave-internal source of entropy run through some whitening filters, and read from until it meets whatever statistical randomness/entropy checks, at which point it is used to seed & store the UID into internal EEPROM. That way, there's no path in or out for the key material, except when already applied via one of the supported primitives.
Then you need to protect your secrets! Couple of layers of active masks (can they do active resistance/path-length measurements instead of just continuity yet? That would annoy the 'bridge & mill' types :)) Encrypted buses, memory, and round-the-houses-routing is also pretty standard for the course, but I'm sure it too could be improved on.
IIRC there was someone on HN who was working for a TV smartcard mfgr who was reasonably confident they'd never been breached. Curious what he'd have to say (without an NDA :) )
Invasive attacks for extracting the UID depend on exactly how it's 'implemented in hardware'. It could be a total lie, and hardwired or masked-rom per-revision (but I doubt that, too easy to discover) It could be in a one-time programmable block somewhere that gets provisioned during manufacture - a flash block/eeprom with write-only access (externally at least), or a series of blowable fuses, or even laser/EB-trimme…
My understanding here is that this Enclave is just a specific part of the overall die, so they're somewhat constricted in the crazy-fabtech methods they might otherwise be able to consider.
Earlier quoted context omitted.
This is the fundamental problem: unless you are rolling your own silicon, at some point you have to take some big corporation's word for it that a chip does what they say it does. This fundamental problem is the reason that nuclear launch codes are protected by a relatively low-tech solution: http://en.wikipedia.org/wiki/Gold_Codes
But if this is the case, why bother with bullet point 1. to 4. The chip is probably manufactured in China, why spend a thought about whether US law enforcement can somehow via Apple decrypt the data of my phone when the Chinese Government can do it anyways?
Available info indicates that the A8 is fabbed on a 20nm process by both Samsung and TSMC [1]. For Samsung, that would indicate production in either the US or South Korea [2]; for TSMC, that would indicate production is in Taiwan [3].
[1] http://recode.net/2014/09/23/teardown-shows-apples-iphone-6-...
[2] http://www.samsung.com/global/business/semiconductor/foundry...
[3] http://www.kitguru.net/components/graphic-cards/anton-shilov...
Apple claims they can't decrypt data, but, the article suggests that they can simply run the decryption on the local phone with custom firmware. Most people chose a 4 digit pin, and, @80 millisecond/guess, that means Apple should be able to crack your phone in 12 minutes.
If you use a longer passcode, your data is more secure - but I thought that was always the story with Apple.
So what, if anything, has changed (other than more data being encrypted?)
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…
> (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.
There is an argument against using the fingerprint access and that is that a user gives up the right of consent while in custody. If law enforcement gets a judicial order to forcibly press the prisoner's finger to the sensor to unlock the device, then he or she has little recourse as the right to remain silent is not implicated. One cannot be similarly physically compelled to disclose a code only held in his or her m…
You can in the UK.
https://en.wikipedia.org/wiki/Regulation_of_Investigatory_Po...