Security via obscurity doesn't stand up to the test of time. Apple has released a whitepaper providing an overview of their approach to security. It appears to be a good approach and shows that the company is serious about security because security is baked into the iOS cake and not merely included in the icing on its surface.
Pros
Secure boot chain -- Read only LLB is implicity trusted. It loads iBoot after verification which loads iOS after verification. This makes is really difficult to get untrusted code on the device even if an adversary has physical access to the phone. It is still possible if he can mess with the LLB, and I doubt if the hardware has robust resistance to physical tampering, so high value targets should not rely on this.
No downgrade -- Software downgrades are not allowed, thereby narrowing the window of opportunity for an adversary to exploit a software vulnerability to the time it takes to patch the system. Once patched, the window is completely closed.
Curation and signed apps -- Every app is reviewed by Apple and digitally signed. However, because of the size of the developer community, Apple cannot possibly check the apps to guarantee lack of malicious code. I still consider this a pro, because it does reduce the vulnerability surface(and until we get some breakthroughs in computer science theory where a program can be proven benign this is the best one can do). A user should understand that he is trusting the app developer and not Apple for 3rd party apps.
Entitlements -- Every app that requires privileged resources explicitly gets rights to specific resources. This is an implementation of the principle of least privilege and is a better option than implicitly allowing access to everything.
Erase function -- Contents are erased by erasing keys required to access them. This makes the process quick and hence more likely to be used when needed.
Random keys in flash DMA engine -- These are not known to the manufacturer or Apple. So there should be no backdoors.
Cons
Enterprise app provisioning-- It is not clear how this is handled. Can an enterprise app access personal data of the user? Can the user remove the app when he chooses to?
Erase function -- Erasing keys should be followed by actually erasing the file data as well. This will protect against attacks on the ciphertext. Assuming AES is secure is reasonable but assuming that the key generation scheme is perfect is not.
Reliance on passcodes -- Although there are delays between attempts to thwart a brute force attack, passcodes are not very secure for the average user. An adversary can see the user type the passcode, look at fingerprints on the screen to significantly narrow down the scope of the brute force attack etc.
[Apple today acquired a biometrics company, so perhaps we will see this issue get addressed in the next iteration of iOS. Hopefully, it will be available to older generation hardware as well.]
Keychain -- Apple does not allow the user to make the security vs usability tradeoff here. Most keys (like Exchange password) are available in memory after the first unlock of the phone. This allows background apps to run but there should be a way for more security conscious users to opt out of this and have the keys in NSFileProtectionComplete class so that they are erased from cleartext DRAM memory when the phone is locked.
Incomplete forward secrecy -- There seems to be no way (apart from backing up all data and erasing everything) to re-encrypt files with updated keys. Only the keys used to wrap the file encryption keys are changed. This is a problem in the following scenarios --
1. An adversary gets access to unlocked phone and is able to retrieve the file encryption keys. The user(upon discovering this) changes the passcode thinking that any new data saved in the file will be protected. But, the file is still encrypted with the compromised key and the adversary can decrypt the file by getting access to the device.
2. A bug is found in the key generation scheme. In this case, Apple can avoid writing the re-encryption code until it discover the bug and publishes the patch.
There is a way to re-encrypt files with new keys by backing up all data, erasing everything, choosing a new passcode and restoring from backup.
Reference
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
Pros
Secure boot chain -- Read only LLB is implicity trusted. It loads iBoot after verification which loads iOS after verification. This makes is really difficult to get untrusted code on the device even if an adversary has physical access to the phone. It is still possible if he can mess with the LLB, and I doubt if the hardware has robust resistance to physical tampering, so high value targets should not rely on this.
No downgrade -- Software downgrades are not allowed, thereby narrowing the window of opportunity for an adversary to exploit a software vulnerability to the time it takes to patch the system. Once patched, the window is completely closed.
Curation and signed apps -- Every app is reviewed by Apple and digitally signed. However, because of the size of the developer community, Apple cannot possibly check the apps to guarantee lack of malicious code. I still consider this a pro, because it does reduce the vulnerability surface(and until we get some breakthroughs in computer science theory where a program can be proven benign this is the best one can do). A user should understand that he is trusting the app developer and not Apple for 3rd party apps.
Entitlements -- Every app that requires privileged resources explicitly gets rights to specific resources. This is an implementation of the principle of least privilege and is a better option than implicitly allowing access to everything.
Erase function -- Contents are erased by erasing keys required to access them. This makes the process quick and hence more likely to be used when needed.
Random keys in flash DMA engine -- These are not known to the manufacturer or Apple. So there should be no backdoors.
Cons
Enterprise app provisioning-- It is not clear how this is handled. Can an enterprise app access personal data of the user? Can the user remove the app when he chooses to?
Erase function -- Erasing keys should be followed by actually erasing the file data as well. This will protect against attacks on the ciphertext. Assuming AES is secure is reasonable but assuming that the key generation scheme is perfect is not.
Reliance on passcodes -- Although there are delays between attempts to thwart a brute force attack, passcodes are not very secure for the average user. An adversary can see the user type the passcode, look at fingerprints on the screen to significantly narrow down the scope of the brute force attack etc.
[Apple today acquired a biometrics company, so perhaps we will see this issue get addressed in the next iteration of iOS. Hopefully, it will be available to older generation hardware as well.]
Keychain -- Apple does not allow the user to make the security vs usability tradeoff here. Most keys (like Exchange password) are available in memory after the first unlock of the phone. This allows background apps to run but there should be a way for more security conscious users to opt out of this and have the keys in NSFileProtectionComplete class so that they are erased from cleartext DRAM memory when the phone is locked.
Incomplete forward secrecy -- There seems to be no way (apart from backing up all data and erasing everything) to re-encrypt files with updated keys. Only the keys used to wrap the file encryption keys are changed. This is a problem in the following scenarios --
1. An adversary gets access to unlocked phone and is able to retrieve the file encryption keys. The user(upon discovering this) changes the passcode thinking that any new data saved in the file will be protected. But, the file is still encrypted with the compromised key and the adversary can decrypt the file by getting access to the device.
2. A bug is found in the key generation scheme. In this case, Apple can avoid writing the re-encryption code until it discover the bug and publishes the patch.
There is a way to re-encrypt files with new keys by backing up all data, erasing everything, choosing a new passcode and restoring from backup.
Reference
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
No comments:
Post a Comment