Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:Context On the Issue (Score 1) 406

The sensor doesn't process the fingerprint information, but when the encryption of the underlying filesystem is setup, it creates a trust relationship between the secure enclave (dedicated crypto chip) and the Touch ID sensor. This is a security measure to make sure that you are accessing your data on trusted hardware. The whole thing is actually done entirely in hardware in the dedicated crypto chip.

Comment Re:Damned if you do, damned if you don't (Score 5, Informative) 406

It's not the fingerprint sensor itself that decides. The fingerprint sensor sends an image of the fingerprint to the Secure Enclave, which is a chip on the device that handles all of the encryption. The secure enclave itself does the analysis and makes the decision. This line of communication between the fingerprint sensor and the secure enclave is encrypted with a key exchange between the sensor and the secure enclave. This pairs your specific secure enclave with the Touch ID sensor. There is anti-replay techniques involved here as well.

The point of pairing the sensor to the secure enclave is so that someone can't open up the phone, install a sniffer on the bus between the secure enclave and the sensor to then collect the fingerprint data for later collection and replay it to the secure enclave to get it to unlock. It also prevents someone from just replacing the touch ID sensor to provide a known good fingerprint to the secure enclave via a hardware hack. You have to, in theory, have an authorized finger pressed up against a trusted sensor.

Comment Re:catch it in the middle, then, coppers (Score 1) 231

Backups can happen in one of two ways: Backup over-the-air using iCloud or Backup through a connection to your local computer via iTunes.

iTunes backups aren't encrypted by default, but you can encrypt iTunes backups with a password you select when you enable encryption of your iTunes backups. Obviously, selecting a good strong password for this increases the strength of your encryption.

iCloud backups are a bit trickier:

Pretty much everything stored in iCloud backup is available for Apple to decrypt on demand. The only parts of it that Apple can't decrypt are your iCloud keychain (stored passwords).

Basically: If you don't want your data to be subject to government search, don't store your backups on iCloud. Use iTunes backups and make sure you turn on encryption.

You can make iTunes backups be somewhat similar to iCloud backups in the sense that you can turn on wifi sync. If your iPhone and computer are on the same network, then your phone will sync with your computer and backup over wifi without having to plug the phone in. These backups will be encrypted and safe from government search, assuming your password is strong.

Comment Re:A hypothetical consumer? (Score 1) 231

Physical access doesn't necessarily get you the encryption key. The encryption key is stored on the device in some very complicated silicon that is not easily read outside of the device itself. For a full explanation see this: http://apple.slashdot.org/comm...

Basically, the only chip that has access to the key also does all of the encryption itself. the key never leaves this chip and it's not really possible to get the encryption key from the chip. You can't use a different chip or brute force the key from the chip because the chip intentionally slows brute force attempts to once per hour after 9 attempts and can be set to destroy the key after the 10th attempt.

maybe...JUST MAYBE...you might be able to extract the key from the chip using an electron microscope and a large quantity of labor (man months worth) and it would cost millions of dollars to do so. And it is possible they designed the chip such that exposing the silicon so it can be scanned by the microscope could be destructive.

Comment Re: catch it in the middle, then, coppers (Score 2) 231

You're not an expert in cryptographically strong systems are you? See my previous post on this subject here: http://apple.slashdot.org/comm...

tldr: What you are suggesting is actually impossible. Brute forcing the unlock code isn't at all possible through pretty much any means...reasonable or even unreasonable...maybe...JUST MAYBE...it's possible through absurdly unreasonable means.

If what you are suggesting was actually possible, then the FBI, CIA, and nearly all law enforcement agencies across the USA and the world wouldn't currently be having a hissy fit over the way the iPhone is encrypted.

Now go back to naturalnews.com or whatever moron website you came from. Over here we demand participants actually know something before posting.

couldn't have said it better myself.

Comment Re:catch it in the middle, then, coppers (Score 5, Informative) 231

You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave.

Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers.

The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.

The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.

The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.

Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored on the flash itself, it's only stored within the secure enclave itself which you can't remove the storage from.

Each boot, the secure enclave creates it's own temporary encryption key, based on it's own UID and random number generator with proper entropy, that it uses to store the full device encryption key in ram. Since the encryption key is also stored in ram encrypted, it can't simply be read out of the system memory by reading the RAM bus.

The only way I can possibly see to potentially unlock the phone without the unlock code is to use an electron microscope to read the encryption key from the secure enclave's own storage. This would take considerable time and expense (likely millions of dollars and several months) to accomplish. This also assumes that the secure enclave chip itself isn't built to be resistant to this kind of attack. The chip could be physically designed such that the very act of exposing the silicon to read it with an electron microscope could itself be destructive.

TLDR: Brute forcing the unlock code isn't at all possible through pretty much any means...reasonable or even unreasonable...maybe...JUST MAYBE...it's possible through absurdly unreasonable means.

Source: http://www.apple.com/business/...

Comment Re:Adaptation (Score 1) 748

Usually rear ending somebody at a traffic light is not from a distracted driver. It's just the opposite. The driver realizes the light is about to change and accelerates, but not expecting the lead vehicle to stop.

Perhaps distracted is the wrong word. "Rear ending someone is caused by a driver who is not paying attention" may be a better thing to say. The reason they aren't paying attention could be because they are distracted...or it be caused by them making an assumption about how someone is going to behave and then tuning out.

Either way, the person who did the rear-ending is in the wrong.

Comment Re:Unison (Score 1) 748

People will also adapt to them being more common. Right now people are making the assumption that it's a human behind the wheel and they are driving like everyone else. Once people get used to automated cars, their driving behaviors will adapt. There will be a period of time where people won't know what to do, but as more and more autonomous vehicles get on the road, people will get used to dealing with them and how they behave.

Comment Re:Unison (Score 1) 748

You're thinking like a human with a human perspective on the limitations of perception/senses. You have to remember that self-driving cars can take advantage of numerous additional technologies for reading the road and what's around them...and they can perceive them all in real time.

For example: If a deer is getting close to the highway, but still hiding in the trees/bushes, your human eyes might not be able to see them...At least until they come darting out into the road. But a driverless car can use Infrared (body heat), sonar, radar, night-vision, etc. to sense that there is a deer over in this area next to the road and then slow way down...even if it's not crossed into the road yet. It can then send out a wireless signal that marks that area of the road as having a potential for a deer running out for other cars to slow themselves down. If other cars continue to perceive the deer, the wireless signal gets renewed. Suddenly it's not just even your vehicle's sensors...it's the sensors of all the other nearby vehicles that are alerting yours to a potential danger.

Granted, this won't eliminate all accidents related to hitting a deer, but it can certainly prevent a significant percentage of them.

Slashdot Top Deals

If at first you don't succeed, you are running about average.

Working...