Platform Security

June 25, 2014

Windows operating systems can be found on a variety of devices, including desktops, laptops, tablets, convertibles, and smartphones. All current Windows operating systems have a consistent look and feel. Regardless of whether you’re using a 32-bit operating system, a 64-bit operating system, or an ARM based operating system, the user experience is similar.

A shared Windows platform for security

Windows-based devices share many security features that are not only identical in name but increasingly common at a code level. The following table lists security features that are common across all current Windows operating systems.

A key advantage to these and other common security features in Windows operating systems is the predictability and uniformity of security configuration. You can use the same types of security policies and settings to enforce the same level of security, regardless of the device used. The security capabilities of Windows operating systems provide an advantage over other operating system families, which often have different security implementations for desktops and laptops versus tablets and smartphones. Windows also offers a common operating system distribution for each hardware vendor and device, whereas competing operating systems may be fragmented into many variations. This lack of consistency in operating system distributions can result in security challenges that just aren’t an issue on the Windows platform.

Security improvements in Windows Phone 8.1

The following lists security related improvements to Windows Phone 8.1 from Windows Phone 8:

Trustworthy Hardware

Operating system security in the modern world requires capability that is derived from security-related hardware, and Windows Phone is no exception to that rule. Windows Phone takes advantage of the latest standards-based security hardware components to help protect devices and the information stored on them.

EUFI

UEFI is a modern, standards-based replacement for the traditional BIOS found in most devices. UEFI provides the same functionality as BIOS while adding security features and other advanced capabilities. Like BIOS, UEFI initializes hardware devices, and then starts the Windows Phone boot loader, but unlike BIOS, UEFI ensures that the operating system loader is secure, tamper free, and prevents jail-breaking which can enable an attacker, or even a user, to tamper with the system and install unauthorized apps.

Current implementations of UEFI run internal integrity checks that verify the firmware’s digital signature before running it. These checks also extend to any optional ROM components on the device. Because only the hardware manufacturer of the device has access to the digital certificate required to create a valid firmware signature, UEFI has protection from firmware and master boot record rootkits (or bootkits). From a security perspective, UEFI enables the chain of trust to transition from the hardware to the software itself.

TPM

A TPM is a tamper-resistant security processor capable of creating and protecting cryptographic keys and hashes. In addition, a TPM can digitally sign data using a private key that software cannot access. Essentially, a TPM is a crypto-processor and secure storage place that both UEFI and the operating system can use to store integrity data, meaning hashes (which verify that firmware and critical files have not been changed) and keys (which verify that a digital signature is genuine).

Among other functions, Windows Phone uses the TPM for cryptographic calculations and to protect the keys for BitLocker storage encryption, virtual smart cards, and certificates. All Windows Phone 8.1 devices include a TPM.

Malware Resistance

It is imperative that all devices be resistant to malware, but it’s even more important for mobile devices like smartphones. Windows Phone devices are frequently used in public, unsecured places, and thieves and security attackers look at smartphones as easy prey. Windows Phone includes features that help make these devices highly resistant to malware.

Boot process

Windows Phone uses some of the same technologies that Windows 8.1 uses to secure the boot process—specifically, UEFI and its Secure Boot component. Secure Boot is a feature of UEFI that helps protect devices against malware or other tampering during the boot process.

When a Windows Phone device starts, the firmware starts the boot loader only if the boot loader’s digital signature has maintained integrity and the boot loader is signed by a trusted authority that is registered in the UEFI database. In the case of all Windows Phone devices, the Windows Phone boot loader signature is trusted.

For Windows 8.1 operating systems, you can disable Secure Boot. Windows Phone and Windows RT devices are designed to run only their respective operating systems, so Secure Boot cannot be turned off and users cannot load a different operating system.

Trusted Boot

As mentioned in the UEFI section above, UEFI Secure Boot verifies that the boot loader is trusted, and then Trusted Boot protects the rest of the startup process by verifying that all Windows boot components have integrity and can be trusted. The boot loader verifies the digital signature of the Windows Phone kernel before loading it. The Windows Phone kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers and startup files.

If a file has been modified (for example, if malware has modified the file to launch malicious code), Trusted Boot protects all of the Windows components and prevents any components that have been tampered with from starting. Among other functions, Windows Phone uses the TPM for cryptographic calculations and to protect the keys for BitLocker storage encryption, virtual smart cards, and certificates. All Windows Phone 8.1 devices include a TPM.

System and app integrity

After Trusted Boot has completed the startup process, Windows Phone loads the system components and any apps that are loaded automatically at startup. The system components and apps must be properly signed before Windows Phone will load and start them. If a malicious user or code has tampered with the system component or app files, the corresponding component or app will not be loaded and started.

Unsigned apps are unable to run on Windows Phone, because an app must be signed to be in the Windows Store or be signed with the organization’s enterprise development signature. Because all system components and apps must be signed, it is extremely difficult for attackers to run malicious code on a device.

Microsoft Security Development Lifecycle

Windows Phone 8.1 is the culmination of many years of effort from Microsoft. With each release, Windows operating systems improve their defense-in-depth implementation for security. The strategy is derived from the Microsoft Security Development Lifecycle (SDL), which ensures that our research and development teams create software that is secure by design and can eliminate or at least mitigate potential security risks.

Apps

Securing the Windows Phone operating system core is the first step in providing a defense-in-depth approach to securing Windows Phone devices. Securing the apps running on the device is equally important, because attackers could potentially use apps to compromise Windows Phone operating system security and the confidentiality of the information stored on the device.

Windows Phone can mitigate these risks by providing a secured and controlled mechanism for users to acquire trustworthy apps. In addition, the Windows Phone Store app architecture isolates (or sandboxes) one app from another, preventing a malicious app from affecting another app running on the device. Also, the Windows Phone Store app architecture prevents apps from directly accessing critical operating system resources, which helps prevent the installation of malware on devices.

Windows Phone Store

Downloading and running apps that contain malware is a common concern for all organizations. One of the most common methods that enables malware to make its way onto devices is by users downloading and running apps that are unsupported or unauthorized by the organization.

Downloading and using apps published in the Windows Phone Store dramatically reduce the likelihood that a user can download an app that contains malware. All Windows Phone Store apps go through a careful screening process and scanning for malware and viruses before being made available in the store. The certification process checks Windows Phone Store apps for inappropriate content, store policies, and security issues. Finally, all apps must be signed during the certification process before they can be installed and run on Windows Phone devices. In the event that a malicious app makes it’s way through the process and is later detected, the Windows Phone Store can revoked access to the app on any devices that have installed it.

In the end, the Windows Store app-distribution process and the app sandboxing capabilities of Windows Phone 8.1 will dramatically reduce the likelihood that users will encounter malicious apps on the system.

AppContainer

The Windows Phone security model is based on the principle of least privilege and uses isolation to achieve it. Every app and even large portions of the operating system itself run inside their own isolated sandbox called an AppContainer.

An AppContainer is a secured isolation boundary that an app and its process can run within. Each AppContainer is defined and implemented using a security policy. The security policy of a specific AppContainer defines the operating system capabilities to which the processes have access within the AppContainer. A capability is a Windows Phone device resource such as geographical location information, camera, microphone, networking, or sensors.

By default, a basic set of permissions is granted to all AppContainers, including access its own isolated storage location. In addition, access to other capabilities can be declared within the app code itself. Access to additional capabilities and privileges cannot be requested at runtime, as can be done with traditional desktop applications.

The AppContainer concept is advantageous for the following reasons:

• **Attack surface reduction.**Apps get access only to capabilities that are declared in the application code and are needed to perform their functions.

• **User consent and control.**Capabilities that apps use are automatically published to the app details page in the Windows Phone Store. Access to capabilities that may expose sensitive information, such as geographic location, automatically prompt the user to acknowledge and provide consent.

• **Isolation.**Unlike desktop style apps, which have unlimited access to other apps, communication between Windows Phone apps is tightly controlled. Apps are isolated from one another and can only communicate using predefined communications channels and data types.

Like the Windows Store security model, all Windows Store apps follow the security principal of least privilege. Apps receive the minimal privileges they need to perform their legitimate tasks only, so even if an attacker exploits an app, the damage the exploit can do is severely limited and should be contained within the sandbox. The Windows Phone Store displays the exact permissions that the app requires along with the app’s age rating and publisher.

Operating system app protection

Although applications built for Windows Phone are designed to be secure and free of defects, the reality is that as long as human beings are writing code, vulnerabilities will always be discovered. When identified, malicious users and software may attempt to exploit the vulnerability in the hopes of a successful exploit.

To mitigate these risks, Windows Phone includes core improvements to make it more difficult for malware to perform buffer overflow, heap spraying, and other low-level attacks.. For example, Windows Phone includes ASLR and DEP, which dramatically reduce the likelihood that newly discovered vulnerabilities will result in a successful exploit. Technologies like ASLR and DEP act as another level in the defense-in-depth strategy for Window Phone.

• **Address space layout randomization.**One of the most common techniques for gaining access to a system is to find a vulnerability in a privileged process that is already running, or guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. In the early days of operating systems, any malware that could write directly to system memory could pull off such an exploit: The malware would simply overwrite system memory within well-known and predictable locations.

  Because all Windows Phone Store apps run in an AppContainer and with fewest necessary privileges, most apps are unable to perform this type of attack outside of one app. It is conceivable that an app from the Window Phone Store might be malicious, but the AppContainer severely limits any damage that the malicious app might do, as apps are also unable to access critical operating system components. The level of protection AppContainers provide is one of the reasons that their functionality was brought into Windows 8.1 client operating systems. However, ASLR provides an additional defense in-depth to help further secure apps and the core operating system.

• **Data execution prevention.**Malware depends on its ability to put a malicious payload into memory with the hope that it will be executed later. ASLR makes that much more difficult, but wouldn’t it be great if Windows Phone could prevent that malware from running if it writes to an area that has been allocated solely for the storage of information? DEP does exactly that by substantially reducing the range of memory that malicious code can use for its benefit. DEP uses the eXecute Never (XN) bit on the ARM processors in Windows Phone devices to mark blocks of memory as data that should never be executed as code. Therefore, even if an attacker succeeds in loading the malware code into memory, to the malware code will not execute. DEP is automatically active in Windows Phone because all devices have ARM processors that support the XN bit.

Line-of-business apps

With Windows Phone, organizations can register with Microsoft to obtain the tools to privately sign and distribute custom LOB apps directly to their users. This means that organizations are not required to submit business apps to the Windows Phone Store before deploying them. After registration, organizations (or contracted vendors) can use a validated process to privately develop, package, sign, and distribute apps.

These LOB apps are identical in architecture to apps obtained from the Windows Phone Store. The only difference is the method that is used to deploy these apps and that they are for private rather than public consumption.

Management of these LOB apps is identical to managing Windows Phone Store apps and can be done by using Windows Phone policies

Company portal

Many MDM systems, such as Microsoft System Center 2012 R2 Configuration Manager and Windows Intune, have a company portal app that allows users to install LOB and Window’s Phone Store apps. A company portal app coupled with a properly designed MDM system can help reduce the likelihood of users downloading apps that have malware, because the company portal list only those apps that the organization trusts and has approved.

Internet Explorer

Windows Phone includes Internet Explorer 11 for Windows Phone. Internet Explorer helps to protect the user because it runs in an isolated AppContainer and prevents web apps from accessing the system and other app resources. In addition, Internet Explorer on Windows Phone supports a browser model without plug-ins, so plug-ins that compromise the user experience or perform malicious actions cannot be installed (just like the Windows Store version of Internet Explorer in Windows 8.1).

The SmartScreen URL Reputation filter is also available in Internet Explorer for Windows Phone. This technology blocks or warns users of websites that are known to be malicious or are suspicious.

Internet Explorer on Windows Phone can also use SSL to encrypt communication, just as in other Windows operating systems. This is discussed in more detail in the “Communication encryption” section later in this guide.

Information Protection

Although it is extremely important to protect the Windows Phone operating system and the apps running on the device, it is even more important to protect the information that these apps access. Windows Phone supports several technologies that help protect this information.

Internal storage encryption

Windows Phone 8.1 performs device encryption, which is based on BitLocker technology, to encrypt the internal storage of devices with Advanced Encryption Standard (AES) 128-bit encryption. This helps ensure that data is always protected from unauthorized users, even when they have physical possession of the phone.

The encryption key is protected by the TPM to ensure that the data cannot be accessed by unauthorized users, even if the internal storage media is physically removed from the device. With both PIN-lock and device encryption enabled, the combination of data encryption and device lock would make it extremely difficult for an attacker to recover sensitive information from a device.

The Require Device Encryption policy prevents users from disabling device encryption and forces encryption of internal storage. Additional security can be included when the Device wipe threshold policy has been implemented to wipe the device when a brute-force attack on the PIN lock is detected. For more information about this policy, see “Security-related policy settings” later in this guide.

Removable storage protection

Many Windows Phone devices have an SD card slot that allows users to store apps and data on an SD card (the installation of apps on an SD card is a new feature in Windows Phone 8.1). Windows Phone stores the apps on an encrypted SD card partition that is specifically designated for apps. This feature is always enabled, so there is no need to explicitly set a policy to have this level of protection.

The Disable removable storage card policy prevents users from using SD cards altogether, but the primary advantage to the new SD card app partition encryption feature is that you can give users the flexibility to use an SD card while still protecting the confidential apps and data on the SD card.

Important note
Windows Phone stores personal content (like photos and videos) on the SD card in an unencrypted partition so that the user can access the SD card on other devices and share content with others.

If SD card use is enabled, users can sideload apps and upload data from the card. They can use this functionality to install apps that might be accessible by your MDM system, as well, but any apps installed from the SD card must be signed by the Windows Phone Store or your organization’s certificate.

Important note
To sideload an app from an SD card, the device must be unlocked, which you can prevent by setting the Disable development unlock (side loading) policy.

Information Rights Management

Windows Phone is one of the few smartphones that offers native support for IRM, enabling users to fully participate in IRM-protected email conversations and to access IRM-protected documents on their devices. Support for IRM in Windows Phone is based on Windows RMS. When IRM is employed, the data in rights-protected documents or email messages is encrypted, and only authorized users can view it. IRM can also be used to limit other rights to a document or message, such as limiting access to Read only content, preventing anyone from copying content in the document or message, preventing email form being forwarded, or preventing the document or message from being printed.

IRM relies on Windows RMS, a Windows Server–based technology that IT administrators can configure to manage the encryption keys for 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.

Organizations can use IRM in conjunction with Microsoft Office 365 services, such as SharePoint Online and Exchange Online. You can enable Windows Azure Active Directory Rights Management for your organization in Office 365 and use IRM just as you would if you had installed Windows RMS on your intranet. IT can configure IRM by using the Allow IRM over EAS policy in your MDM system or Microsoft Exchange Server. For more information about this policy, see the “Security-related policy settings” section later in this guide.

S/MIME signing and encryption

New in Windows Phone 8.1 is S/MIME support, which allows you to digitally sign or encrypt email messages. The digital signature helps recipients know the authenticity of the sender and that the email message actually originated from the sender. Digital encryption encrypts the content of the email message and can be unencrypted by the authorized recipients only.

Use the following policies in your MDM system or Exchange Server infrastructure to configure S/MIME support in Windows Phone:

• Require signed S/MIME messages

• Require encrypted S/MIME messages

• Require signed S/MIME algorithm

• Require encrypted S/MIME algorithm

• Allow S/MIME encrypted algorithm negotiation

• Allow S/MIME SoftCerts

S/MIME uses certificates that your MDM system manages or even virtual smart cards to perform encryption and signing.

Communication encryption

Attackers commonly gain unauthorized access to information by viewing unencrypted data sent between devices and the services users access. Windows Phone provides a number of encryption methods for protecting the communication between the device and the services that manage your data, including:

• Transport Layer Security (TLS) and Secure Sockets Layer (SSL). Most web-based services use TLS or SSL for secure communication. Windows Phone supports TLS 1.0 – 1.2 and SSL 3.0 to help ensure that all communication is adequately protected. Windows Phone ships with several trusted root certificates that can be used with TLS and SSL, and you can easily add new trusted root certificates manually or through your MDM system.

• VPN. In some instances, users require access to information that resides on servers on your organization’s private intranet. VPN connections are a common method for providing this type of secured access. You can require VPN connection encryption by configuring the VPN servers in your organization to it. Windows Phone includes support for a number of VPN vendors in addition to Microsoft VPN connections. Windows Phone 8.1 introduces support for IKEv2, IPsec, and SSL VPN connection (the SSL VPN connections require a downloadable plug-in from the VPN server vendor). VPNs also require user (and optionally device) authentication to help further protect the VPN connection.