There have been numerous studies on second hand smoke and it has been showntobequitedangerous. Even a small amount is bad and has been shown that it can cause long-term health issues.
You might look in to the new iPad Pro that was just announced today as you can use apple's full stylus on it. So you can get Apple's App ecosystem with the stylus now.
You can smack the dead guy with the $5 pipe wrench all you want. The guy who knows the passcode to the phone is still dead. You won't be getting the passcode to the phone from him.
Have you read what the court order to apple says? Actually says? I have read the actual court order.
It says:
1) It will bypass or disable the auto-erase function. 2) it will enable the FBI to submit passcodes to the subject device for testing electronically via the physical device port, bluetooth, wifi, or other protocol available. 3) it will not purposefully introduce any additional delay between passcodes attempts beyond what is incurred by hardware 4) they are to provide a signed iPhone software file that can be loaded onto the device and run from RAM without modifying the iOS installation on the actual phone, the user data, or system partitions on the device's flash memory
So yes...they are required to allow for electronic entry of the passcode. And they have to write the software in a way that hasn't been done before... without touching the flash memory on the iPhone. You can not run iOS on the phone "from RAM".
This is absolutely a new piece of software that they will likely have to start with. Much more complicated than just "removing a few lines of code".
It is pretty common that people or businesses are being subpoenaed or ordered by the court to cooperate in a criminal investigation, and little care is given for your interest in the matter.
Subpoenas and court orders to cooperate in investigations have always been along the lines of "come to the courthouse and testify" and "Let us look at your records/books/transaction logs/call logs/records/and any other collection of facts you have within your possession." NEVER has a court order gone so far as to order a company to completely engineer a tool that does not exist.
Drama much ? Apple is asked to cooperate in a criminal investigation, at little cost to them (just a few hours of labor), and no cost to their other lawful customers.
I don't care how little or how much it costs, or how long it takes to accomplish. I don't care that they're being compensated for it. It's indentured servitude. They are being forced to apply their trade for the government's benefit with no right to refuse.
The best way to handle it is to make it an "if the unlock code is provided, then you can update the software of the OS and firmware of the device without wiping the encryption keys. If the unlock code is not provided, then I will let you update the software but first I will wipe the encryption keys." Since the encryption is all done in a hardware chip with it's own separate OS and update process, it would not be difficult to accomplish.
secure enclave will accept software updates in two cases: 1) provide unlock code and keep the encryption key intact. 2) do not provide unlock code and then wipe the encryption key.
This is a secure method of doing it. You can either provide the unlock code and update the firmware of the secure enclave without wiping the device, or you can wipe your device and update the firmware of the secure enclave without the unlock code.
The article is plain wrong. The article is quoting someone who writes Windows Rootkits for a living. I'm sure his technical expertise is sound, but he's talking about systems he may be unfamiliar with at a deep level.
For the specific hardware in this case, the iPhone 5C, Apple is capable of creating software that they can side load on to the device to bypass the time delays between key entry and key destruction, as ordered by the court. However, they must be in physical possession of the device. As far as i'm aware, there is no mechanism for apple to push software on to a phone without user intervention.
Apple does have the ability to remotely disable and remove apps from phones. The automatic update process, if turned on and set appropriate, will automatically download the updates, but will not automatically install without user intervention. I have not come across any case that says Apple has the ability to force new software on to an iPhone.
For current available new hardware (iPhone 5S, 6, and 6S) Apple does not have the ability to unlock the phones without wiping the user space on the phones. Per Apple's own iOS security document (https://www.apple.com/business/docs/iOS_Security_Guide.pdf) the time delays and key destruction are enforced in hardware. Even if you completely compromise the kernel of the iPhone, the secure enclave chip enforces the encryption, time delays and key destruction.
The iOS security document also states that the secure enclave has it's own separate protected software update process. You can update the software on the secure enclave in one of two ways: Provide the unlock code and you can update without key destruction, or you can destroy the key and force an update.
Basically, for current gen hardware, apple actually can say they have zero way to unlock the device, even if they wrote their own software to attempt to do so, even if they completely compromised the software of the device.
They actually can't. All of the encryption is done in hardware and the storage is encrypted. The hardware can't read the storage without being provided the code.
Once you provide the code, then you possibly could read the bus to the storage.
This happened through the Windows Update process on Windows 7 and 8. Microsoft created a deceptively labeled software update that, at some point, started the Windows 10 update process.
If you turned off Automatic Updates to Windows entirely, you did not get updated to Windows 10 and Microsoft likely doesn't have a way to force software on to your computer if the Automatic Update process is disabled.
My apologies. Rereading my initial post, I realize I made a mistake. I did say "UDID", but I meant "UID".
These are two separate numbers within the phone. The UDID is known to the OS and can be queried. But it is not a part of the encryption key.
The UID is burned in to the silicon and is only known within the encryption system itself. Not even software running at the kernel level can query the UID.
You confuse UDID with UID. The UID is unique and burned in to the processor of the phone. The GID is unique to the Secure Enclave and is burned in to the silicon of the secure enclave. Apple does not have any record of any phone's UID or GID. Both of which combine from separate hardware components to create 1/2 of the encryption key.
The other 1/2 of the key is randomly generated during initial device setup by the user and stored in memory that is embedded within the secure enclave itself. It cannot be removed and imaged from the secure enclave...it's actually within the silicon of the chip. The chip has no method of querying for the key. The chip itself does all of the crypto calculations on board.
Apple doesn't have any way of knowing the UID, GID, or randomly generated part of the encryption key. There isn't any memory that they can reasonably image. Because of this you require the actual hardware you are trying to get into. If you are missing any piece of it, you don't have the full key.
The secure enclave is physically built to resist these kinds of attacks...EM shielding and such. I'm not saying it's not possible, but it is very difficult, time consuming, and requires a lot of special tools. Tools that apple probably doesn't have because it never created them. And the secure enclave storage is still only 1/2 of the key.
Another 1/4 of the key is physically burned in to the application processor, and the remaining 1/4 of the key is physically burned in to another part of the secure enclave.
All of this adds expense in forcibly extracting the key from the device.
The secure enclave does all the crypto itself. It sits between the OS kernel and the flash memory itself. The full key is never in a space where it is accessible to any part of the application processor.
The secure enclave assembles the full crypto key using the 3 pieces... it's own 64-bit Unique Device ID (UID), the application processor's unique 64-bit Group ID (GID), and a 128-bit random number that the secure enclave generates during the initial device setup that is stored within the secure enclave chip itself.
Quite simply, the full key never leaves the secure enclave.
I don't think this will help them. The secure enclave utilizes its own secure boot and personalized software update separate from the application processor. Basically, The secure enclave can have it's software updated, but it's firmware update is separate from the main firmware for the device. The secure enclave requires you to enter the unlock code before it will accept new firmware. Anytime you do an iOS update on your phone, it asks for the unlock code...This is why...you need it to put the secure enclave into a mode where it will accept a new firmware.
The whole system is designed to be resilient even if the main kernel of the device has been compromised.
No. In short: The iPhone's encryption is tied to the physical hardware. Within the chips themselves lies a full 256-bit AES encryption key. The 4-digit pin simply unlocks the encryption key from the chips. They are tamper resistant and you can't just write software to get around their protection of the full encryption key as it's all hardware enforced.
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. The secure enclave stores a full 256-bit AES encryption key.
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. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.
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, effectively erasing all the data on the device. 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 in the flash itself, it's only stored within the secure enclave itself which you can't remove the stora
The fingerprint sensor has a dedicated encrypted bus with the secure enclave (dedicated crypto chip). The secure enclave then pairs itself with the fingerprint sensor (key exchange).
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.
Slashdot Mirror
There have been numerous studies on second hand smoke and it has been shown to be quite dangerous. Even a small amount is bad and has been shown that it can cause long-term health issues.
The "bad guys" in this case were already dead. They died the day they committed their crimes.
You are quoting an article on Canada. Their legal system doesn't apply to the USA.
You might look in to the new iPad Pro that was just announced today as you can use apple's full stylus on it. So you can get Apple's App ecosystem with the stylus now.
You can smack the dead guy with the $5 pipe wrench all you want. The guy who knows the passcode to the phone is still dead. You won't be getting the passcode to the phone from him.
Have you read what the court order to apple says? Actually says? I have read the actual court order.
It says:
1) It will bypass or disable the auto-erase function.
2) it will enable the FBI to submit passcodes to the subject device for testing electronically via the physical device port, bluetooth, wifi, or other protocol available.
3) it will not purposefully introduce any additional delay between passcodes attempts beyond what is incurred by hardware
4) they are to provide a signed iPhone software file that can be loaded onto the device and run from RAM without modifying the iOS installation on the actual phone, the user data, or system partitions on the device's flash memory
Source: http://www.ndaa.org/pdf/SB-Sho...
So yes...they are required to allow for electronic entry of the passcode. And they have to write the software in a way that hasn't been done before... without touching the flash memory on the iPhone. You can not run iOS on the phone "from RAM".
This is absolutely a new piece of software that they will likely have to start with. Much more complicated than just "removing a few lines of code".
It is pretty common that people or businesses are being subpoenaed or ordered by the court to cooperate in a criminal investigation, and little care is given for your interest in the matter.
Subpoenas and court orders to cooperate in investigations have always been along the lines of "come to the courthouse and testify" and "Let us look at your records/books/transaction logs/call logs/records/and any other collection of facts you have within your possession." NEVER has a court order gone so far as to order a company to completely engineer a tool that does not exist.
Drama much ? Apple is asked to cooperate in a criminal investigation, at little cost to them (just a few hours of labor), and no cost to their other lawful customers.
I don't care how little or how much it costs, or how long it takes to accomplish. I don't care that they're being compensated for it. It's indentured servitude. They are being forced to apply their trade for the government's benefit with no right to refuse.
You're holding up a work of dramatic FICTION, with all of it's hollywood over dramatizations, as evidence of Mobsters being political?
The best way to handle it is to make it an "if the unlock code is provided, then you can update the software of the OS and firmware of the device without wiping the encryption keys. If the unlock code is not provided, then I will let you update the software but first I will wipe the encryption keys." Since the encryption is all done in a hardware chip with it's own separate OS and update process, it would not be difficult to accomplish.
Maybe. With the security hardware that exists in the iPhone 5S and later devices, it's possible a software update to them could simply fix it.
You are correct.
You can fix that super easily:
secure enclave will accept software updates in two cases: 1) provide unlock code and keep the encryption key intact. 2) do not provide unlock code and then wipe the encryption key.
This is a secure method of doing it. You can either provide the unlock code and update the firmware of the secure enclave without wiping the device, or you can wipe your device and update the firmware of the secure enclave without the unlock code.
The article is plain wrong. The article is quoting someone who writes Windows Rootkits for a living. I'm sure his technical expertise is sound, but he's talking about systems he may be unfamiliar with at a deep level.
For the specific hardware in this case, the iPhone 5C, Apple is capable of creating software that they can side load on to the device to bypass the time delays between key entry and key destruction, as ordered by the court. However, they must be in physical possession of the device. As far as i'm aware, there is no mechanism for apple to push software on to a phone without user intervention.
Apple does have the ability to remotely disable and remove apps from phones. The automatic update process, if turned on and set appropriate, will automatically download the updates, but will not automatically install without user intervention. I have not come across any case that says Apple has the ability to force new software on to an iPhone.
For current available new hardware (iPhone 5S, 6, and 6S) Apple does not have the ability to unlock the phones without wiping the user space on the phones. Per Apple's own iOS security document (https://www.apple.com/business/docs/iOS_Security_Guide.pdf) the time delays and key destruction are enforced in hardware. Even if you completely compromise the kernel of the iPhone, the secure enclave chip enforces the encryption, time delays and key destruction.
The iOS security document also states that the secure enclave has it's own separate protected software update process. You can update the software on the secure enclave in one of two ways: Provide the unlock code and you can update without key destruction, or you can destroy the key and force an update.
Basically, for current gen hardware, apple actually can say they have zero way to unlock the device, even if they wrote their own software to attempt to do so, even if they completely compromised the software of the device.
They actually can't. All of the encryption is done in hardware and the storage is encrypted. The hardware can't read the storage without being provided the code.
Once you provide the code, then you possibly could read the bus to the storage.
This happened through the Windows Update process on Windows 7 and 8. Microsoft created a deceptively labeled software update that, at some point, started the Windows 10 update process.
If you turned off Automatic Updates to Windows entirely, you did not get updated to Windows 10 and Microsoft likely doesn't have a way to force software on to your computer if the Automatic Update process is disabled.
My apologies. Rereading my initial post, I realize I made a mistake. I did say "UDID", but I meant "UID".
These are two separate numbers within the phone. The UDID is known to the OS and can be queried. But it is not a part of the encryption key.
The UID is burned in to the silicon and is only known within the encryption system itself. Not even software running at the kernel level can query the UID.
You confuse UDID with UID. The UID is unique and burned in to the processor of the phone. The GID is unique to the Secure Enclave and is burned in to the silicon of the secure enclave. Apple does not have any record of any phone's UID or GID. Both of which combine from separate hardware components to create 1/2 of the encryption key.
The other 1/2 of the key is randomly generated during initial device setup by the user and stored in memory that is embedded within the secure enclave itself. It cannot be removed and imaged from the secure enclave...it's actually within the silicon of the chip. The chip has no method of querying for the key. The chip itself does all of the crypto calculations on board.
Apple doesn't have any way of knowing the UID, GID, or randomly generated part of the encryption key. There isn't any memory that they can reasonably image. Because of this you require the actual hardware you are trying to get into. If you are missing any piece of it, you don't have the full key.
The secure enclave is physically built to resist these kinds of attacks...EM shielding and such. I'm not saying it's not possible, but it is very difficult, time consuming, and requires a lot of special tools. Tools that apple probably doesn't have because it never created them. And the secure enclave storage is still only 1/2 of the key.
Another 1/4 of the key is physically burned in to the application processor, and the remaining 1/4 of the key is physically burned in to another part of the secure enclave.
All of this adds expense in forcibly extracting the key from the device.
Yes. The random number is generated during the initial device setup process and then stored within the secure enclave itself.
The secure enclave does all the crypto itself. It sits between the OS kernel and the flash memory itself. The full key is never in a space where it is accessible to any part of the application processor.
The secure enclave assembles the full crypto key using the 3 pieces... it's own 64-bit Unique Device ID (UID), the application processor's unique 64-bit Group ID (GID), and a 128-bit random number that the secure enclave generates during the initial device setup that is stored within the secure enclave chip itself.
Quite simply, the full key never leaves the secure enclave.
I don't think this will help them. The secure enclave utilizes its own secure boot and personalized software update separate from the application processor. Basically, The secure enclave can have it's software updated, but it's firmware update is separate from the main firmware for the device. The secure enclave requires you to enter the unlock code before it will accept new firmware. Anytime you do an iOS update on your phone, it asks for the unlock code...This is why...you need it to put the secure enclave into a mode where it will accept a new firmware.
The whole system is designed to be resilient even if the main kernel of the device has been compromised.
No. In short: The iPhone's encryption is tied to the physical hardware. Within the chips themselves lies a full 256-bit AES encryption key. The 4-digit pin simply unlocks the encryption key from the chips. They are tamper resistant and you can't just write software to get around their protection of the full encryption key as it's all hardware enforced.
For a full explanation, see my previous post earlier in the article: http://yro.slashdot.org/commen...
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. The secure enclave stores a full 256-bit AES encryption key.
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. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.
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, effectively erasing all the data on the device. 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 in the flash itself, it's only stored within the secure enclave itself which you can't remove the stora
The fingerprint sensor has a dedicated encrypted bus with the secure enclave (dedicated crypto chip). The secure enclave then pairs itself with the fingerprint sensor (key exchange).
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.