aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAdrian Ludwig <aludwig@google.com>2012-11-09 15:01:30 -0800
committerNick Kralevich <nnk@google.com>2012-12-14 10:58:29 -0800
commite30dbd19a0d334de0ae526b6f3927b92da8ef34c (patch)
treeaf0ccaddc76b29a31ff385446728ae9a108ce166
parentcb63f6e30408f21b1f795c7db12fb2d1ecb452c0 (diff)
downloadsource.android.com-jb-mr1-dev.tar.gz
Add documentation for new security features in the Android 4.2 release.android-cts-4.2_r2android-4.2.2_r1.2android-4.2.2_r1.1android-4.2.2_r1jb-mr1.1-releasejb-mr1-dev
Also, fill in some gaps in some gaps in the Android Security overview, such as support for VPN and cryptography. Change-Id: I48fe22ffb7ea94b133ba1b0e0a6586e7a5f18938
-rw-r--r--src/tech/security/android_4_2_security_enhancements.md55
-rw-r--r--src/tech/security/index.md147
-rw-r--r--src/tech/security/sidebar2.md5
3 files changed, 159 insertions, 48 deletions
diff --git a/src/tech/security/android_4_2_security_enhancements.md b/src/tech/security/android_4_2_security_enhancements.md
new file mode 100644
index 00000000..ad003745
--- /dev/null
+++ b/src/tech/security/android_4_2_security_enhancements.md
@@ -0,0 +1,55 @@
+#Security Enhancements in Android 4.2
+
+Android provides a multi-layered security model described in the [Android
+Security Overview](index.html). Each update to Android includes dozens of
+security enhancements to protect users. The following are some of the security
+enhancements introduced in Android 4.2:
+
++ **Application verification.** Users can choose to enable “Verify Apps" and
+have applications screened 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.
+
++ **More control of premium 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.
+
++ **Always-on VPN.** VPN can be configured so that applications will not have
+access to the network until a VPN connection is established. This prevents
+applications from sending data across other networks.
+
++ **Certificate Pinning.** The Android core libraries now support
+[certificate pinning](https://developer.android.com/reference/android/net/http/X509TrustManagerExtensions.html). Pinned domains will receive a certificate validation
+failure if the certificate does not chain to a set of expected certificates.
+This protects against possible compromise of Certificate Authorities.
+
++ **Improved display of Android permissions.** Permissions have been organized
+into groups that are more easily understood by users. During review of the
+permissions, the user can click on the permission to see more detailed
+information about the permission.
+
++ **installd hardening.** The installd daemon does not run as the root user,
+reducing potential attack surface for root privilege escalation.
+
++ **init script hardening.** init scripts now apply O_NOFOLLOW semantics to
+prevent symlink related attacks.
+
++ **FORTIFY_SOURCE.** Android now implements FORTIFY_SOURCE. This is used by
+system libraries and applications to prevent memory corruption.
+
++ **ContentProvider default configuration.** Applications which target API
+level 17 will have "export" set to "false" by default for each
+[ContentProvider](https://developer.android.com/reference/android/content/ContentProvider.html),
+reducing default attack surface for applications.
+
++ **Cryptography.** Modified the default implementations of SecureRandom and
+Cipher.RSA to use OpenSSL. Added SSL Socket support for TLSv1.1 and TLSv1.2
+using OpenSSL 1.0.1
+
++ **Security Fixes.** Upgraded open source libraries with security fixes include
+WebKit, libpng, OpenSSL, and LibXML. Android 4.2 also includes fixes for
+Android-specific vulnerabilities. Information about these vulnerabilities has
+been provided to Open Handset Alliance members and fixes are available in
+Android Open Source Project. To improve security, some devices with earlier
+versions of Android may also include these fixes.
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
diff --git a/src/tech/security/sidebar2.md b/src/tech/security/sidebar2.md
new file mode 100644
index 00000000..a751c779
--- /dev/null
+++ b/src/tech/security/sidebar2.md
@@ -0,0 +1,5 @@
+# Security Topics #
+- [Security Overview](/tech/security/index.html)
+- [Android 4.2](/tech/security/android_4_2_security_enhancements.html)
+
+