Because there was a flaw in the security before the update that allowed you to swap out the Touch ID sensor. The update patched a flaw and then the phone noticed a problem with the trust of the hardware.
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.
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.
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.
Apple has addressed this as part of the way the iOS encryption system works. The encryption system creates it's own temporary encryption key each boot that it uses to encrypt everything it stores in RAM.
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.
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 encryptio
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.
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.
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.
exactly. There is an API of some sorts that your system uses to communicate to T-Mobile that the data you are sending is video data, they throttle that stream appropriately, and don't subtract the bits used from the user's bucket of available bits to use.
The user, optionally, can turn off the "Binge On" feature, which will prevent the throttling of the stream and you can get full HD quality, but then the bits are subtracted from your bucket.
T-Mobile has said that everyone is invited to join. Everyone. Just follow the technical requirements that are very straight forward and you're in. You don't have to pay any money.
There are no kickbacks or fees for providers to get on the list of approved requirements. Just some pretty straight-forward requirements around how to stream the data.
Mainly, you have to 1) Have a way to identify video and non-video data to t-mobile 2) Use a technology that will use variable bit-rates based on available bandwidth 3) Notify and work with t-mobile if you change the protocols to make sure the new protocols still meet the requirements before those changes go live. 4) only stream content you have the rights the stream
Otherwise, there is no cost to participate and everyone is welcome.
They are not intercepting and modifying the stream. They do have a requirement to participate that your streaming technology support adaptive bit rates, such that if the available bandwidth drops, your stream compensates and reduces in quality. But T-Mobile is not doing the reencoding for you.
Content providers are NOT subsidizing the bandwidth. T-Mobile will let any content provider participate, and they don't have to pay anything to get on the list of approved providers. The requirements are pretty straight forward:
1) You have to identify the data to T-Mobile as streaming video data. 2) You must use adaptive bitrate technology 3) If you make changes to your streaming methods you have to give T-Mobile a heads up before those changes go live to ensure you still meet the requirements. 4) You have to be able to tell T-Mobile when you are sending non-video content so they can count that against user data caps. 5) You can only stream content legally (proper licenses to content, etc.) 6) Don't violate their trademarks
You don't have to pay, and T-Mobile will work with you directly to ensure you can meet their requirements. Once you've been approved, you're all set. No other requirements and you don't have to pay them anything.
Often times, even after conviction and you end up in prison, you have reasons to contact your attorney. Perhaps you are working on an appeal, the period of time between conviction and the sentencing, etc. These are all still privileged communications.
The fingerprint is only good once the phone has been previously unlocked via the passcode. After the phone is either rebooted, or if it's been greater than 48 hours since last unlocked, then then phone can no longer be unlocked via the fingerprint.
My guess is that there is a cache of the decryption key that is stored in RAM. a power cycle will clear that, or the phone clears it itself after 48 hours.
Every device that is capable of running iOS 8 is the iPhone 4S and greater...so pretty much 5 generations of devices. I doubt many people have a 5+ year old iPhone at this point. iPhone 4 and under account for 4% of the current iOS market share. (source: https://david-smith.org/iosver... )
I doubt that they are now using this as a gimmick to try and force people to upgrade to a new handset at this time.
Actually it can. The contract people agreed to when signing up for service says that they can change the price at any time. However, if the price goes up you have the right to back out of the contract without paying the early termination fee.
They could target specific commercial VPN providers. Pick the top 10 VPN providers and just block access to connecting to them. You'd stop a good majority of the unwanted VPN traffic while still allowing businesses (whose VPNs are almost certainly privately run) to continue to work just fine.
Slashdot Mirror
Because there was a flaw in the security before the update that allowed you to swap out the Touch ID sensor. The update patched a flaw and then the phone noticed a problem with the trust of the hardware.
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.
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.
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.
Apple has addressed this as part of the way the iOS encryption system works. The encryption system creates it's own temporary encryption key each boot that it uses to encrypt everything it stores in RAM.
It's AES 256. Try "we have a 50% chance to find it sometime before the heat-death of the universe".
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.
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 encryptio
Agreed. I actually enjoyed the John Carter movie.
TFA: The Force Awakens. Star Wars Episode 7.
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.
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.
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.
exactly. There is an API of some sorts that your system uses to communicate to T-Mobile that the data you are sending is video data, they throttle that stream appropriately, and don't subtract the bits used from the user's bucket of available bits to use.
The user, optionally, can turn off the "Binge On" feature, which will prevent the throttling of the stream and you can get full HD quality, but then the bits are subtracted from your bucket.
T-Mobile has said that everyone is invited to join. Everyone. Just follow the technical requirements that are very straight forward and you're in. You don't have to pay any money.
There are no kickbacks or fees for providers to get on the list of approved requirements. Just some pretty straight-forward requirements around how to stream the data.
Mainly, you have to
1) Have a way to identify video and non-video data to t-mobile
2) Use a technology that will use variable bit-rates based on available bandwidth
3) Notify and work with t-mobile if you change the protocols to make sure the new protocols still meet the requirements before those changes go live.
4) only stream content you have the rights the stream
Otherwise, there is no cost to participate and everyone is welcome.
Source: http://www.t-mobile.com/conten...
They are not intercepting and modifying the stream. They do have a requirement to participate that your streaming technology support adaptive bit rates, such that if the available bandwidth drops, your stream compensates and reduces in quality. But T-Mobile is not doing the reencoding for you.
Content providers are NOT subsidizing the bandwidth. T-Mobile will let any content provider participate, and they don't have to pay anything to get on the list of approved providers. The requirements are pretty straight forward:
1) You have to identify the data to T-Mobile as streaming video data.
2) You must use adaptive bitrate technology
3) If you make changes to your streaming methods you have to give T-Mobile a heads up before those changes go live to ensure you still meet the requirements.
4) You have to be able to tell T-Mobile when you are sending non-video content so they can count that against user data caps.
5) You can only stream content legally (proper licenses to content, etc.)
6) Don't violate their trademarks
You don't have to pay, and T-Mobile will work with you directly to ensure you can meet their requirements. Once you've been approved, you're all set. No other requirements and you don't have to pay them anything.
Source: http://www.t-mobile.com/conten...
Often times, even after conviction and you end up in prison, you have reasons to contact your attorney. Perhaps you are working on an appeal, the period of time between conviction and the sentencing, etc. These are all still privileged communications.
If they're calling their attorney...Yes.
My guess is that if you bought direct from manufacturers, they would setup their own service centers.
The fingerprint is only good once the phone has been previously unlocked via the passcode. After the phone is either rebooted, or if it's been greater than 48 hours since last unlocked, then then phone can no longer be unlocked via the fingerprint.
My guess is that there is a cache of the decryption key that is stored in RAM. a power cycle will clear that, or the phone clears it itself after 48 hours.
Every device that is capable of running iOS 8 is the iPhone 4S and greater...so pretty much 5 generations of devices. I doubt many people have a 5+ year old iPhone at this point. iPhone 4 and under account for 4% of the current iOS market share. (source: https://david-smith.org/iosver... )
I doubt that they are now using this as a gimmick to try and force people to upgrade to a new handset at this time.
Actually it can. The contract people agreed to when signing up for service says that they can change the price at any time. However, if the price goes up you have the right to back out of the contract without paying the early termination fee.
They could target specific commercial VPN providers. Pick the top 10 VPN providers and just block access to connecting to them. You'd stop a good majority of the unwanted VPN traffic while still allowing businesses (whose VPNs are almost certainly privately run) to continue to work just fine.