Beruflich Dokumente
Kultur Dokumente
This white paper is part of a series of technical papers designed for IT professionals. This whitepaper reviews how security is implemented on Windows Phone in apps and with data and also reviews how Mobile Device Management (MDM) and Exchange ActiveSync can be used to implement a managed and security-enhanced environment for Windows Phone.
September 2013
Legal Disclaimer
2013 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and
views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
Table of Contents
Windows Phone 8 Security Guide..1 WINDOWS PHONE OVERVIEW..2 PLATFORM INTEGRITY..3 APP PLATFORM SECURITY..6 CHAMBERS AND CAPABILITIES..6 THE BROWSER..7 WINDOWS PHONE STORE..7 ENTERPRISE LINE-OF-BUSINESS (LOB) APPS..8 WINDOWS PHONE UPDATES..8 DATA PROTECTION..9 DEVICE ACCESS AND SECURITY POLICIES..9 DEVICE ENCRYPTION..10 REMOVABLE STORAGE..10 INFORMATION RIGHTS MANAGEMENT..10 CERTIFICATES..11 MOBILE DEVICE MANAGEMENT.....13 SUPPORTED EXCHANGE ACTIVESYNC FEATURES BY EXCHANGE SERVER VERSION..14 EXCHANGE ACTIVESYNC SECURITY..16 SUPPORTED EXCHANGE ACTIVESYNC POLICY SETTINGS..16 DIRECT PUSH AND FIREWALL SETTINGS..19 SSL FOR EXCHANGE SERVER ENCRYPTION AND AUTHENTICATION..21
Platform integrity
Trusted Boot and code signing help to ensure the platform integrity of Windows Phone 8. These features help to safeguard the Windows Phone 8 boot process and operating system from malware attacks, especially rootkits, by allowing only validated software components to execute. These features help to deliver a security-enhanced platform for application developers and corporate customers alike, and helps to assure consumers that steps have been taken to help safeguard the information that they care about. Trusted Boot validates firmware images on Windows Phone devices before they are allowed to load the operating system. Trusted Boot is built on a root of trust, which is fused into the
Layered security platform diagram
device during manufacturing and ensures that all binaries, starting with the very first boot loader loaded from system storage, must be signed by a trusted authority. Windows Phone architecture uses a System-on-a-Chip (SoC) design provided by SoC vendors. The SoC vendor and device manufactures provide the pre-UEFI boot loaders and the UEFI environment. The UEFI environment implements the UEFI secure boot standard that is described in section 27 of the UEFI Specification (http://www.uefi.org/specs). This standard describes a process by which all UEFI drivers and applications are validated against keys provisioned into a UEFI runtime variable before they are executed. The UEFI and Windows document (http://msdn.microsoft.com/enus/windows/hardware/gg463149.aspx) on MSDN describes the advantages of using UEFI and how UEFI is supported by desktop versions of the Windows operating system. Although the document focuses on UEFI and Windows, most of the information in the document also applies to Windows Phone. Microsoft provides the Windows Phone boot manager in the UEFI environment. After the pre-UEFI and UEFI components complete their boot processes, the Windows Phone boot manager takes over to complete the Windows Phone 8 boot process so that the user can start using the smartphone. All code in the Windows Phone operating system is signed by Microsoft, including OEM
drivers and applications. Also, applications that are added after manufacturing, or installed from the Windows Phone Store or a private enterprise store must be properly signed to execute. Windows Phone 8 is designed to help mitigate threats or risks with the following platform security features:
Windows Phone security feature Strong device password protection Device lock requires a password or PIN to access the device when it is turned on Local device wipe occurs after a specified number of incorrect login attempts Remote device wipe erases data and helps to prevent unauthorized use Exponential back-off if incorrect passwords are entered Password policy enforcement, such as required password for sync
Secure Sockets Layer (SSL) encryption of all data transmitted between the device and the corporate mail server Advanced Encryption Standard for SSL channel encryption in 128 bit cipher strength Encrypted data passes through a single SSL port on the firewall Supports Information Rights Management protection of e-mail
Security policies such as password enforcement, password complexity, and device encryption, help to control overthe-air access to device Bluetooth discovery mode is turned on only in Bluetooth settings NFC can be turned off to help guard device integrity
Office for Windows Phone does not support macros, so viruses cannot leverage them to do damage
upon app installation for certain capabilities, such as geographic location. Isolation. No communication channels exist between apps on the phone. Apps are isolated from each other and cannot access memory used or data stored by other applications, including the keyboard cache.
The browser
Windows Phone 8 includes Internet Explorer 10 for Windows Phone. Internet Explorer helps to protect the user as it runs in an isolated chamber and prevents web apps from accessing other app resources. In addition, Internet Explorer does not support a plug-in model, so malicious plug-ins cannot be installed. SmartScreen technology is also available in Internet Explorer for Windows Phone. This technology warns users of websites that are known to be malicious.
Screenshot: SmartScreen technology blocking a malicious website
users to discover, install, and optionally run LOB apps created by the enterprise. Company Hubs can also provide other companyspecific experiences or features, such as displaying current company news, upcoming company events, and alerts from the IT department. For more information about LOB app distribution and Company Hubs for Windows Phone, see the Company app distribution for Windows Phone topic (http://msdn.microsoft.com/enus/library/windowsphone/develop/jj206943(v=vs.105).aspx) on MSDN.
penetration testing, and security development practices, all of which help to prevent unauthorized access to phone resources.
Data protection
The Windows Phone security design addresses the need for data protection. To accomplish this, every Windows Phone supports the same set of management and security controls, regardless of hardware manufacturer, enabling organizations to manage all Windows Phones in a consistent, predictable way that helps to mitigate risk.
Device encryption
Windows Phone 8 uses BitLocker technology to support the encryption of all internal data storage on the phone with AES 128. Encryption is enabled by either Exchange ActiveSync policy RequireDeviceEncryption or device management policy. After BitLocker is enabled, the phone automatically begins encrypting the internal storage. The encryption key is protected by the Trust Platform Module (TPM), which is bound to UEFI Trusted Boot to ensure that the encryption key will only be released to trusted boot components. With both PIN-lock and BitLocker enabled, the combination of data encryption and device lock would make it extremely difficult for an attacker to recover sensitive information from a device.
10
Removable storage
Windows Phone 8 supports removable storage using micro SD cards, so users can easily extend the memory available for storage on their phones to store pictures, movies, or music when needed. The Windows Phone operating system allows users to store only media files on SD cards. Although the Windows Phone 8 operating system and user data partitions are encrypted, files that are stored on SD cards that are inserted in the phone are not encrypted. IT professionals can prevent the use of external storage cards on Windows Phones by configuring an Exchange ActiveSync policy setting.
employed, the data in rights-protected documents or email messages is encrypted, so that it can only be viewed by authorized users. IRM can also be used to limit other rights to a document or message, such as by limiting access to read-only, by preventing content in the document or message from being copied, or by preventing the document or message from being printed. IRM relies on Windows Rights Management Services (Windows RMS), a Windows Server-based technology that IT administrators can configure to create the issuance license and perform the encryption of rights-protected documents. In addition, Windows RMS can be applied to email so that messages can circulate in a protected environment, but not be forwarded outside the organization. Windows RMS can also be applied to documents that are attached to email or stored on Microsoft SharePoint servers, limiting distribution and editing capabilities and helping to prevent information from being leaked to unauthorized personnel. IRM can be configured by using the Exchange ActiveSync policy Allow IRM over EAS. For more information about Information Rights Management, see the Information Rights Management topic (http://technet.microsoft.com/dd638140.aspx) on TechNet.
11
Certificates
Windows Phone 8 applications are signed with certificates that are unique to the application and that establish a license for the application. Only signed applications are allowed to run on Windows Phone 8. The only sources of apps for Windows Phone 8 are the Windows Phone Store (http://windowsphone.com/store) and company sites that offer line-of-business apps that are signed with enterprise certificates. A company can sign and distribute its own apps by following the procedures outlined in the Company app distribution for Windows Phone topic (http://msdn.microsoft.com/enus/library/windowsphone/develop/jj206943(v=vs.105).aspx) on MSDN to acquire an enterprise certificate from Symantec.
Applications and games can be made available in the Windows Phone Store through the Windows Phone Dev Center (http://dev.windowsphone.com). All submissions are reviewed for compliance with app policies. Approved applications and games are signed with VeriSign certificates. Certificates in Windows Phone 8 are primarily used to: Create a secure channel using Secure Sockets Layer (SSL) between a phone and a web server or service. Authenticate a user to a reverse proxy server that is used to enable Microsoft Exchange ActiveSync (EAS) for email. Install and license applications (from the Windows Phone Store or a custom company distribution site). Certificates can be installed on the phone using either of the following two methods: Installing certificates via Internet Explorer: A certificate can be posted on a website and made available to users through a device-accessible URL that they can use to download the certificate. When a user accesses the page and taps the certificate, it opens on the device. The user can inspect the certificate, and if they choose to continue, the certificate is installed on the device. Installing certificates via email: The certificate installer supports .cer, .p7b, .pem, and .pfx files. To install certificates via email, make sure that your mail filters do not block .cer files. Certificates that are sent via email appear as message attachments. When a certificate is received, a user can tap on the certificate file to review the contents and install the certificate. Typically, when an identity certificate is installed, the user is prompted for the password (or passphrase) that protects it. Note: Certificates may also be installed via Mobile Device Management service provider.
12
13
The use of an MDM solution also facilitates comprehensive reporting functionality including: Server configured policy values Query installed enterprise apps Device name Device ID OS platform type Firmware version OS version Device local time Processor type Device model
14
15
No
Yes
Yes
No
Yes
Yes
16
Description
Specifies whether a simple device password is allowed. A simple password is one consisting only of repeated "2222" or sequential abcd" characters. The default is $true.
AlphanumericDevicePasswordReq uired
Specifies whether the password for the mobile phone must be alphanumeric. The default is $false.
DevicePasswordEnabled
Specifies whether a password is required. When set to $true, DevicePasswordEnabled requires that the user set a password for the mobile phone. The default is $false.
Policy setting
DevicePasswordExpiration
Description
Specifies the length of time, in days, that a password can be used. After this length of time, a new password must be created. The format of the setting is dd.hh.mm:ss; for example, 24.00:00 = 24 hours.
DevicePasswordHistory
Specifies the number of previously used passwords to store. When a user creates a new password, the user can't reuse a stored password that was previously used.
17
IrmEnabled
MaxDevicePasswordFailedAttemp ts
Specifies the number of attempts a user can make to enter the correct password for the mobile phone before a device reset to factory settings is initiated. You can specify any number from 4 through 16. The default is 8.
MaxInactivityTimeDeviceLock
Specifies the length of time that the mobile phone can be inactive before the password is required to reactivate it. You can specify any interval between 30 seconds and 1 hour. The default is 15 minutes. The format of the setting is hh.mm:ss; for example, 15:00 = 15 minutes.
Policy setting
MinDevicePasswordComplexChara cters
Description
Specifies the number of character groups that are required to be present in the password. The character groups are defined as: Lowercase alphabetical characters Uppercase alphabetical characters Numbers Non-alphanumeric characters For example, if the value of MinDevicePasswordComplexChara cters is 2, a password with both uppercase and lowercase alphabetical characters would be sufficient, as would a password with lowercase alphabetical characters and numbers.
18
MinDevicePasswordLength
Specifies the minimum number of characters in the device password. You can specify any number from 1 through 16. The maximum length a password can be is 16 characters. The default is 4.
RequireDeviceEncryption
Specifies whether encryption is required on the device. Once set, device encryption automatically begins on the internal storage of the phone. The default is $false.
RemoteWipe
Deletes data on the user data partition and resets the phone to default settings.
Policy setting
AllowNonProvisionableDevices
Description
Specifies with the server running Exchange. When set to $true, it enables all mobile phones to synchronize with the Exchange server, regardless of whether the phone can enforce all the specific settings established in the Exchange ActiveSync policy. This also includes mobile phones managed by a separate device management system. When set to $false, this setting blocks mobile phones that aren't provisioned from synchronizing with the Exchange server. The default is $false.
19
Mobile operators should set the idle connection timeout values on outgoing firewalls to 30 minutes. Organizations should set timeout values on their incoming firewalls to 30 minutes.
Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You should be able to safely increase the idle connection time-out value setting without compromising the security of the network. The following table shows examples of attacks and describes how other settings can be used to mitigate exposure to them:
20
IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection. The name of the connection time-out setting in the IIS management console is misleading; TCP connections are closed when the connection time-out value is exceeded (120 seconds by default).
An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.
This threat is mitigated by the same time-out as the previous scenario. The connection time-out setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keepalive scenario.
A short time-out value causes the mobile phone to initiate a new HTTPS request more frequently. This can shorten the battery life of the mobile phone. Higher heartbeat intervals result in longer battery life for the phone.
21