diff options
Diffstat (limited to 'src/tech/security/index.md')
| -rw-r--r-- | src/tech/security/index.md | 147 |
1 files changed, 99 insertions, 48 deletions
diff --git a/src/tech/security/index.md b/src/tech/security/index.md index cd42289b..db5f1405 100644 --- a/src/tech/security/index.md +++ b/src/tech/security/index.md @@ -85,7 +85,7 @@ device or the web. Google Play makes it easy for developers to reach Android users and potential customers. Google Play also provides community review, application [license verification](https://developer.android.com/guide/publishing/licensing.html), -and other security services. +application security scanning, and other security services. + **Android Updates**: The Android update service delivers new capabilities and security updates to Android devices, including updates through the web or over @@ -268,50 +268,17 @@ runs as its own user. Unless the developer explicitly exposes files to other applications, files created by one application cannot be read or altered by another application. -##Filesystem Encryption +##Cryptography -Android 3.0 and later provides full filesystem encryption, so all user data can -be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC -and ESSIV:SHA256. The encryption key is protected by AES128 using a key -derived from the user password, preventing unauthorized access to stored data -without the user device password. To provide resistance against systematic -password guessing attacks (e.g. “rainbow tables” or brute force), the -password is combined with a random salt and hashed repeatedly with SHA1 using -the standard PBKDF2 algorithm prior to being used to decrypt the filesystem -key. To provide resistance against dictionary password guessing attacks, -Android provides password complexity rules that can be set by the device -administrator and enforced by the operating system. Filesystem encryption -requires the use of a user password, pattern-based screen lock is not supported. - -More details on implementation of filesystem encryption are available at -[https://source.android.com/tech/encryption/android_crypto_implementation.html](/ -tech/encryption/android_crypto_implementation.html) - -##Password Protection - -Android can be configured to verify a user-supplied password prior to providing -access to a device. In addition to preventing unauthorized use of the device, -this password protects the cryptographic key for full filesystem encryption. - -Use of a password and/or password complexity rules can be required by a device -administrator. - -##Device Administration - -Android 2.2 and later provide the Android Device Administration API, which -provides device administration features at the system level. For example, the -built-in Android Email application uses the APIs to improve Exchange support. -Through the Email application, Exchange administrators can enforce password -policies — including alphanumeric passwords or numeric PINs — across -devices. Administrators can also remotely wipe (that is, restore factory -defaults on) lost or stolen handsets. - -In addition to use in applications included with the Android system, these APIs -are available to third-party providers of Device Management solutions. Details -on the API are provided here: -[https://developer.android.com/guide/topics/admin/device-admin.html](https://devel -oper.android.com/guide/topics/admin/device-admin.html). +Android provides a set of cryptographic APIs for use by applications. These +include implementations of standard and commonly used cryptographic primitives +such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level +protocols such as SSL and HTTPS. +Android 4.0 introduced the +[KeyChain](http://developer.android.com/reference/android/security/KeyChain.html) +class to allow applications to use the system credential storage for private +keys and certificate chains. ##Memory Management Security Enhancements @@ -346,6 +313,10 @@ escalation (further enhanced in Android 4.1) + dmesg_restrict enabled (avoid leaking kernel addresses) + kptr_restrict enabled (avoid leaking kernel addresses) +** Android 4.2+** + ++ FORTIFY_SOURCE for system code + ##Rooting of Devices By default, on Android only the kernel and a small subset of the core @@ -387,6 +358,71 @@ devices uses the device password to protect the encryption key, so modifying the bootloader or operating system is not sufficient to access user data without the user’s device password. +#User Security Features + +##Filesystem Encryption + +Android 3.0 and later provides full filesystem encryption, so all user data can +be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC +and ESSIV:SHA256. The encryption key is protected by AES128 using a key +derived from the user password, preventing unauthorized access to stored data +without the user device password. To provide resistance against systematic +password guessing attacks (e.g. “rainbow tables” or brute force), the +password is combined with a random salt and hashed repeatedly with SHA1 using +the standard PBKDF2 algorithm prior to being used to decrypt the filesystem +key. To provide resistance against dictionary password guessing attacks, +Android provides password complexity rules that can be set by the device +administrator and enforced by the operating system. Filesystem encryption +requires the use of a user password, pattern-based screen lock is not supported. + +More details on implementation of filesystem encryption are available at +[https://source.android.com/tech/encryption/android_crypto_implementation.html](/ +tech/encryption/android_crypto_implementation.html) + +##Password Protection + +Android can be configured to verify a user-supplied password prior to providing +access to a device. In addition to preventing unauthorized use of the device, +this password protects the cryptographic key for full filesystem encryption. + +Use of a password and/or password complexity rules can be required by a device +administrator. + +##Device Administration + +Android 2.2 and later provide the Android Device Administration API, which +provides device administration features at the system level. For example, the +built-in Android Email application uses the APIs to improve Exchange support. +Through the Email application, Exchange administrators can enforce password +policies — including alphanumeric passwords or numeric PINs — across +devices. Administrators can also remotely wipe (that is, restore factory +defaults on) lost or stolen handsets. + +In addition to use in applications included with the Android system, these APIs +are available to third-party providers of Device Management solutions. Details +on the API are provided here: +[https://developer.android.com/guide/topics/admin/device-admin.html](https://devel +oper.android.com/guide/topics/admin/device-admin.html). + +##Credential Storage + +By default, Android includes a set of predefined Certificate Authorities (CAs) +that are trusted for operations such as establishing SSL connections within the +browser. In Android 4.0 and later, users can disable preinstalled CAs within +the system settings. Users can also add trusted CAs or certificates to the +system by importing them from USB storage. Android 4.1 and later adds the +ability for OEMs to add hardware-backed KeyChain storage which binds +private keys to the device on which they are stored. + +##Virtual Private Network + +Android provides a built-in VPN client with support for PPTP, L2TP, and IPsec VPNs. +In addition, Android 4.0 introduced the +[VpnService](http://developer.android.com/reference/android/net/VpnService.html) class +to support third-party VPN solutions. Android 4.2 introduced the ability for a +user to configure the VPN as "always on" to indicate that applications can connect +to the network only through the connected VPN. + #Android Application Security ##Elements of Applications @@ -435,10 +471,11 @@ behavior based on that information. ##The Android Permission Model: Accessing Protected APIs -By default, an Android application can only access a limited range of system -resources. The system manages Android application access to resources that, if -used incorrectly or maliciously, could adversely impact the user experience, -the network, or data on the device. +All applications on Android run in an Application Sandbox, described earlier in +this document. By default, an Android application can only access a limited +range of system resources. The system manages Android application access to +resources that, if used incorrectly or maliciously, could adversely impact the +user experience, the network, or data on the device. These restrictions are implemented in a variety of different forms. Some capabilities are restricted by an intentional lack of APIs to the sensitive @@ -586,7 +623,7 @@ instance and handing it off to the system. The system locates some other piece of code (in this case, the Browser) that knows how to handle that Intent, and runs it. Intents can also be used to broadcast interesting events (such as a notification) system-wide. See -[https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html. +[https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html). + **ContentProviders**: A ContentProvider is a data storehouse that provides access to data on the device; the classic example is the ContentProvider that @@ -614,6 +651,11 @@ These APIs include: + In-App Billing + NFC Access +Android 4.2 adds further control on the use of SMS. Android will provide a +notification if an application attempts to send SMS to a short code that uses +premium services which might cause additional charges. The user can choose +whether to allow the application to send the message or block it. + ##SIM Card Access Low level access to the SIM card is not available to third-party apps. The OS @@ -722,6 +764,15 @@ feature](https://developer.android.com/guide/topics/manifest/manifest-element.ht l#uid) where two or more applications signed with same developer key can declare a shared UID in their manifest. +##Application Verification + +Android 4.2 and later support application verification. Users can choose to +enable “Verify Apps" and have applications evaluated by an application verifier +prior to installation. App verification can alert the user if they try to +install an app that might be harmful; if an application is especially bad, it + can block installation. + + ##Digital Rights Management The Android platform provides an extensible DRM framework that lets |