Sigh. The encryption methods haven't changed in years. iOS devices have had these features for multiple generations. You can read the iOS Security Paper from February 2014 to confirm this. It starts on page 8.
Sigh. Could you at least have tried to read the iOS Security Paper before posting?
If you had, you would have realized the decryption key is derived from the passcode, the unique UID burned into the SoC, and the GID unique to each model family.
In order to brute force the securely generated AES 256 decryption key via the passcode, you need the other pieces of information. Had you read the paper, you would have learned how difficult that task is.
Oh, so that means your laptop doesn't support InstantGo/Connected Standby, which requires soldered RAM for security reasons (to prevent cold boot attacks).
Know how I can tell you've never read the iOS Security Paper and have no actual knowledge of how iOS encryption works?
Because you think a 4 digit numeric passcode is the only thing that makes up the securely generated AES 256 encryption key. It's not. At all.
Here's the iOS Security Paper. The relevant section begins on page 10. Read it. Understand it. Then review your original comment and learn how many fundamental mistakes you made.
It's these claims that make me wonder if you've used a Mac. It's easy to confirm on a Mac those claims are not true.
Yes, Image Capture settings most definitely stick. That's what is consulted when you plug in a camera device.
Again,/usr/local/ is explicitly excluded from rootless.
As for your Ruby/Perl issue. You're seriously trying to replace the system libraries first and third parties depend on? Why?! They were only ever tested with those system versions.
However, you can change the PATH by editing rc files or using the dscl tool.
Have you never used a Mac? To change the default application for a camera, set it in Image Capture.app.
And, of course, idiots that think they know better can disable rootless. For those that know better, they install Perl or Ruby from source in a pace such as/usr/local/, which is designed for such installations and doesn't require disabling rootless.
The default is to ask for passwords and the only way to not ask is if the item is free or you buy two things within 15 minutes. You will also always get asked first time you try to get something after reboot.
Purchases do require a password. The problem is, which the summary left out, the kid knew his dad's password. Because of this, all of the iOS protections that exist to stop excessive IAPs were bypassed with the password.
It only counts fixed bugs, so for Mac OS X, that'd be bugs in 10.8.x and later for 2015.
The funny part is the AppleTV bug list. Apple lists CVE numbers for WebKit in AppleTV security updates (as all 2nd gen and later AppleTVs share code with iOS) even though the WebKit framework is inaccessible.
That is, there's no way to trigger those bugs but they still get counted.
No, they are not all security bugs in the software they were reported for. For example, some people make entries for third-party software when it is, in fact, the OS that prevents the third-party software from securing it.
There have also been times when things like "launching malware runs arbitrary code" get assigned CVE numbers when there hasn't actually been any bug. Because the user explicitly launched the malware.
There are two ways to get a CVE assigned to an issue. Either report the issue on your software yourself and a CVE gets reserved or have someone else report the issue in your software and a CVE gets assigned.
Neither method actually determines if the CVE is a security issue or the severity if it is a security issue.
The list is not a list of vulnerabilities. It's a list of known bugs fixed in the last year. It doesn't say anything about the severity of the bugs. For example, since Microsoft never discloses or fixes bugs in Windows Phone, it's very low on the list despite sharing a lot of code with Windows for the desktop. That doesn't mean Windows Phone is somehow more secure.
Because the list includes bugs found and publicly disclosed, the company that fixes the most bugs has the highest number of disclosed bugs in any list. Since Google doesn't really disclose Android bugs, many never get added to the list.
Furthermore, Apple submits self-found security bugs and gets CVEs assigned to them. Most other vendors do not report self-found bugs.
While the previous models did not have something called the “Secure Enclave” they’ve has dedicated security hardware/features/encryption since the iPhone 3GS.
To elaborate, iOS 8.3 fixed the silent install issue, iOS 8.4 fixed the other issues, iOS 9 made it significantly more difficult to trick people into approving enterprise certificates.
If you go to Settings -> Privacy -> Diagnostics & Usage -> Diagnostics & Usage Data on an iPhone that suddenly powered off, the reason why might be in one of those logs. For example, it may be something like a kernel panic or a thermal event (getting too hot and then being forced to shut down). Both events will be logged.
Slashdot Mirror
Sigh. The encryption methods haven't changed in years. iOS devices have had these features for multiple generations. You can read the iOS Security Paper from February 2014 to confirm this. It starts on page 8.
Sigh. Could you at least have tried to read the iOS Security Paper before posting?
If you had, you would have realized the decryption key is derived from the passcode, the unique UID burned into the SoC, and the GID unique to each model family.
In order to brute force the securely generated AES 256 decryption key via the passcode, you need the other pieces of information. Had you read the paper, you would have learned how difficult that task is.
Oh, so that means your laptop doesn't support InstantGo/Connected Standby, which requires soldered RAM for security reasons (to prevent cold boot attacks).
Know how I can tell you've never read the iOS Security Paper and have no actual knowledge of how iOS encryption works?
Because you think a 4 digit numeric passcode is the only thing that makes up the securely generated AES 256 encryption key. It's not. At all.
Here's the iOS Security Paper. The relevant section begins on page 10. Read it. Understand it. Then review your original comment and learn how many fundamental mistakes you made.
Using multiple static data sources when generating an encryption key protects against extremely weak passcodes.
Why did you post a link about something that occurred when the Adobe servers were breached and people used those same credentials with iCloud?
Correct, you do not know much about how iPhones work but it didn't seem to stop you from speculating.
If you want to learn how the encryption works, see this explanation.
Yes, it does use dedicated cryptography hardware. Yes, the key is protected from the rest of the OS.
It's these claims that make me wonder if you've used a Mac. It's easy to confirm on a Mac those claims are not true.
Yes, Image Capture settings most definitely stick. That's what is consulted when you plug in a camera device.
Again, /usr/local/ is explicitly excluded from rootless.
As for your Ruby/Perl issue. You're seriously trying to replace the system libraries first and third parties depend on? Why?! They were only ever tested with those system versions.
However, you can change the PATH by editing rc files or using the dscl tool.
Have you never used a Mac? To change the default application for a camera, set it in Image Capture.app.
And, of course, idiots that think they know better can disable rootless. For those that know better, they install Perl or Ruby from source in a pace such as /usr/local/, which is designed for such installations and doesn't require disabling rootless.
The default is to ask for passwords and the only way to not ask is if the item is free or you buy two things within 15 minutes. You will also always get asked first time you try to get something after reboot.
The source article said the kid had the father's password and used it to make purchases.
iOS asks for a password whenever things are purchased, regardless of method. Buying free apps can skip a password.
However, the kid had the password needed for purchases and was able to enter it when asked.
Purchases do require a password. The problem is, which the summary left out, the kid knew his dad's password. Because of this, all of the iOS protections that exist to stop excessive IAPs were bypassed with the password.
It only counts fixed bugs, so for Mac OS X, that'd be bugs in 10.8.x and later for 2015.
The funny part is the AppleTV bug list. Apple lists CVE numbers for WebKit in AppleTV security updates (as all 2nd gen and later AppleTVs share code with iOS) even though the WebKit framework is inaccessible.
That is, there's no way to trigger those bugs but they still get counted.
No, they are not all security bugs in the software they were reported for. For example, some people make entries for third-party software when it is, in fact, the OS that prevents the third-party software from securing it.
There have also been times when things like "launching malware runs arbitrary code" get assigned CVE numbers when there hasn't actually been any bug. Because the user explicitly launched the malware.
There are two ways to get a CVE assigned to an issue. Either report the issue on your software yourself and a CVE gets reserved or have someone else report the issue in your software and a CVE gets assigned.
Neither method actually determines if the CVE is a security issue or the severity if it is a security issue.
This is incorrect. If you look at any release notes for any Apple security update you will see numerous CVE that were discovered internally by Apple.
The list is not a list of vulnerabilities. It's a list of known bugs fixed in the last year. It doesn't say anything about the severity of the bugs. For example, since Microsoft never discloses or fixes bugs in Windows Phone, it's very low on the list despite sharing a lot of code with Windows for the desktop. That doesn't mean Windows Phone is somehow more secure.
All versions of Mac OS X and iOS are being added together already in the list.
Because the list includes bugs found and publicly disclosed, the company that fixes the most bugs has the highest number of disclosed bugs in any list. Since Google doesn't really disclose Android bugs, many never get added to the list.
Furthermore, Apple submits self-found security bugs and gets CVEs assigned to them. Most other vendors do not report self-found bugs.
While the previous models did not have something called the “Secure Enclave” they’ve has dedicated security hardware/features/encryption since the iPhone 3GS.
Don’t have Trusted Hardware? Hmm? In what way don’t older iPhones have trusted hardware?
They were revoked quite a while ago. The malware hails from 2014.
To elaborate, iOS 8.3 fixed the silent install issue, iOS 8.4 fixed the other issues, iOS 9 made it significantly more difficult to trick people into approving enterprise certificates.
If you go to Settings -> Privacy -> Diagnostics & Usage -> Diagnostics & Usage Data on an iPhone that suddenly powered off, the reason why might be in one of those logs. For example, it may be something like a kernel panic or a thermal event (getting too hot and then being forced to shut down). Both events will be logged.