7 Jun 2012

iOS and Android Security

- iOS apps run as the unpriviledged user "mobile". This is different from Android, which runs each app under a different Unix user id.
- As many OS processes as possible run under the "mobile" user. If a system process requires more authority than sandboxed third-party apps, it's given extra entitlements rather than running it as root.
- There are two partitions on disk -- an OS partition that's normally mounted read-only, and a user partition containing user data. This is similar to Android.

- Encryption and hashing are done in hardware, for performance and energy efficiency (battery life).
- iDevice CPUs have a couple of baked-in AES-256 keys, which cannot be read by software or firmware -- only the results of encrypt/decrypt operations performed using these keys are visible to software.
- There's also hardware SHA-1 support.
- Encryption is in the DMA path from RAM to flash

- Every file on the filesystem is encrypted, with a different key. This key is stored in the file's metadata, after further encryption, as explained below.
- Every file on the filesystem belongs to one of four "Data protection" classes:
    - Complete protection: The file is accessible only when the device is unlocked.
    - Protected unless open: Similar to complete protection, but if the file is open, you can continue to access it even when the device is locked.
    - Protected until first authentication: Once unlocked, on first access, it stays unlocked. This is similar to desktop full-disk encryption: once you boot up your machine and authenticate, your files are accessible until shutdown.
    - None. No encryption.
- These data protection classes are implemented by encrypting the per-file encryption key with the encryption key for its protection class, and then storing the encrypted key in the file metadata. In more detail:
    - Complete protection: once a file belonging to this protection class is written to disk, its per-file encryption key is encrypted with the key for the complete protection class. This global key is generated from the user's passcode or password (and nonce and unique device ID...), and is thrown away when the device is locked, so there's no way to read that file.
    - Protected unless open: similar to complete protection, except that the key for this class isn't purged when the device is locked, until the last open file is closed.
    - Protected until first authentication: again similar, except that the key for this class is never purged.
    - No protection: there's no key for this class, so the per-file key is stored directly in the file metadata
- So, the overall picture is that each file is encrypted with a per-file key, which is encrypted again (based on its protection class) and then stored in the metadata.
- There's a third level of encryption -- a root key that you need to decrypt any file. This provides quick erase, not additional security: when you reset your device, this key is thrown away, so none of your files are decryptable.
- Keep in mind that flash devices perform block remapping, so deleting a key from disk is not as simple as erasing that logical block. The system erases the physical block by looking up the logical to physical mapping, and erasing that block in the NAND flash.

- The above describes protection for files. There's also the keychain, which is an sqlite database managed by the security framework (securityd daemon).
- There's only one sqlite database for the entire system, shared by all apps. This is because apps from the same developer can choose to share a keychain. Example: Log in to Google+, and your account carries over to Gmail.
- Sqlite is a file (or maybe files) on the filesystem, but it does not use the file protection system. It sets a file protection level of no protection. Instead, it implements its own protection system on top of the file-level protection system.
- The keychain protection levels are similar to file protection levels, except there's no "protected until open" level. Keychain entries are not opened and closed like files.
- There's also another dimension of keychain protection levels, which is whether the item is confined to the device or can be copied out.

- Boot sequence:
    - On power-up, the CPU starts executing code from a fixed ROM location (similar to BIOS). This code is implicitly trusted.
    - The boot ROM contains a key that is used to decrypt and verify the boot loader to ensure it hasn't been tampered with, and pass control to it.
    - The boot loader is divided into two stages: Low-level bootloader (LLB) and iBoot, the second stage. This allows Apple to upgrade iBoot without modifying the signature in ROM, which can't be done.
    - Booting into recovery mode (where the device shows a Connect to iTunes message) entails booting into iBoot. This happens if the OS is corrupted, or you explicitly choose to boot into recovery mode.
    - There's an even lower mode called DFU mode, where it boots only till LLB. In this mode, the screen is off and there's no visual indication that the device is even powered on. This is logically equivalent to a PC booting into BIOS when its hard disk has been erased.

- Preventing OS downgrade protects you from adversaries who temporarily gain posession of your device, downgrade it to a known vulnerable iOS version and then break it.
- iOS does not use or need a firewall because unneeded ports are not open in the first place, and in many cases unneeded software like telnet isn't present on the device to begin with.
- Push notifications, FaceTime and iMessage use encrypted protocols.
- iOS suppots many VPN protocols. It connects on demand, and keeps the connection active when the device is unlocked. In some cases, the user needs to download an app to handle the authentication UI.
- iOS supports WPA2 enterprise to connect to corporate networks.
- iOS enforces an escalating delay for each unlock attempt, and can be configured to wipe the device after 10 failed attempts.
- Enterprises can push configuration profiles to devices. Configuration profiles both provide access (email, for example) and enforce restrictions. They can be configured to not be uninstallable (short of a reset) or allow uninstallation with a passcode, in which case uninstalling the profile removes corporate email, apps, etc.

Source: http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf, among others.

No comments:

Post a Comment