1 out of 1 rated this helpful - Rate this topic

Security for Windows Phone

Windows Phone

March 23, 2012

The Windows Phone Application Platform is designed to deliver a compelling user experience that users can customize by acquiring applications from a healthy ecosystem. Achieving this goal involves ensuring that the trustworthiness concerns of end users are addressed.

The Windows Phone Application Platform incorporates a number of technologies that are designed to help maintain a quality experience for the end user when downloading and using third party applications on a Windows Phone. The concerns addressed by these technologies can be divided into three broad categories:

  • Quality of phone experience. End users want to feel comfortable that the applications they acquire will not adversely affect their phone experience, such as making the phone less responsive or making changes that will affect other applications or the phone itself. Further, it is important that applications are easy to uninstall and that they uninstall completely, should the end user decide for any reason that they no longer want a particular application on their phone.

  • Access to the user's information. End users want to feel comfortable that the applications they acquire will not access certain information without their knowledge. This includes information such as their personal data, their contacts, their geographic location, and their photos.

  • Billable events. End users want to feel comfortable that applications will not perform actions that incur additional costs without their permission. An example is an application that makes a phone call to a 1-900 phone number.

The Windows Phone Application Platform includes several measures designed to address these concerns and foster a healthy ecosystem in which end users are empowered to try applications.

One of the goals of the Windows Phone Application Platform is to foster the creation of applications that are secure by design and secure by default. An important aspect of achieving this goal is to integrate several security safeguards into the development environment and lifecycle. A good example is the mandatory and automated digital signing of all applications that are approved for sale in the Windows Phone Marketplace.

o facilitate the security measures that are in place for the benefit of end users, application developers will be required to follow these steps:

  1. Sign up as a Windows Phone developer, provide information about themselves as an ISV (which is subject to verification), and pay the associated fee.

  2. Acquire the recommended development environment (free versions are available).

  3. Develop a Windows Phone application using only .NET managed language development technologies and tools, and in accordance with the standard practices specified for Windows Phone application development. To facilitate easier testing, developers will be able to register one or more Windows Phones as development devices, thereby allowing them to run an application during development and prior to it being digitally signed during the application submission and certification process.

  4. Submit a Windows Phone application for inclusion in the Windows Phone Marketplace. This process will subject the application to a variety of publicly documented certification tests. If the application passes all of these tests, it will be digitally signed on behalf of the developer and made available for sale in the Windows Phone Marketplace.

By conforming to this structured development environment and process, developers will be doing their part to create an application ecosystem for Windows Phones that inspires confidence in end users.

This structured development platform and execution environment also contains safeguards designed to help protect the intellectual property of developers. For applications to run on a Windows Phone, a valid license that is issued by the Windows Phone Marketplace must be present on the phone. This means that even if a technically savvy end user figures out how to circumvent the Windows Phone Marketplace and load an application onto their phone in some other way, Windows Phone will not allow it to run if the license is not available, thereby helping to protect the fruits of the developer’s labor.

The Windows Phone Application Platform employs a variety of technologies designed to help protect Windows Phone end users from applications that exhibit certain unwanted behaviors:

  • The structured application submission and certification process includes a suite of certification tests to identify certain behaviors that may be associated with problems and prevent those applications from being offered in the Windows Phone Marketplace.

  • The Windows Phone Marketplace is the only legitimate source of application acquisition, mandatory code signing, and application licenses. This approach will help to maintain a consistent set of standards for Windows Phone applications.

  • The requirement to develop Windows Phone applications using only .NET managed code helps to improve developer productivity and the robustness of their applications. When used appropriately, the strong typing, bounds checking, and memory management features of managed code can help to eliminate or minimize many of the common programming errors that can lead to exploitation of the application by hackers, as well as excessive and unintended resource consumption.

  • Windows Phone applications run in a sandboxed process. This means that they are isolated from each other, and will interact with phone features in a strictly structured way. If an application needs to save data or configuration information, it will do so using Isolated Storage, which is designed to be protected from access by other applications. Applications can only communicate with each other through controlled mechanisms. For more information about Isolated Storage, see Isolated Storage Overview for Windows Phone.

  • Windows Phone applications are run under the supervision of an execution manager. The execution manager will measure whether applications behave as required by certain defined conventions. For example, the execution manager monitors the use of resources by applications that are not in the foreground, and terminates non-foreground applications as needed to make the foreground application more responsive to the user.

  • The sandboxed process within which a particular application runs has a customized set of security capabilities. The Windows Phone Application Platform is designed to minimize the attack surface area of each application by only granting it the capabilities that it needs in order to run. For example, if an application does not require the use of the Media Library, the Windows Phone Application Platform will seek to execute it in a sandboxed process that does not have access to the Media Library.

    Certain capabilities that an application might need have a direct impact on information access or cost. In such cases, the Windows Phone Marketplace will disclose this information to the end user before the application is purchased. Preinstalled applications are also required to disclose this information to the end user upon first use of the application.

The SDL is a security assurance process that is focused on software development. It is a collection of mandatory security activities, grouped by the phases of the traditional software development life cycle. Many of these security activities would provide some degree of security benefit if implemented on a standalone basis. However, practical experience at Microsoft has shown that security activities executed in chronological order and as part of a repeatable process can result in greater security gains than those resulting from ad-hoc implementation. Combining a holistic and practical approach, the SDL introduces security and privacy throughout all phases of the development process with the goal of protecting end-users. For more information about the SDL, see SDL Process Guidance.

Microsoft offers many SDL tools for developers to use with their applications. As a Windows Phone developer, there are several tools that can be helpful:

SDL Tool

Information

Microsoft SDL Threat Modeling Tool

The SDL Threat Modeling Tool enables non-security subject matter experts to create and analyze threat models by communicating about the security design of their systems, analyzing those designs for potential security issues using a proven methodology, and suggesting and managing mitigations for security issues.

FxCop

FxCop is a static analyzer. It analyzes managed code assemblies and reports information about the assemblies such as possible design, localization, performance, and security improvements.

BinScope

The BinScope Binary Analyzer is a verification tool that analyzes binaries to ensure that they have been built in compliance with the SDL requirements and recommendations. BinScope checks that SDL-required compiler/linker flags are being set, strong-named assemblies are in use, up-to-date build tools are in place, and the latest good ATL headers are being used. BinScope also reports on dangerous constructs that are prohibited by SDL.

MiniFuzz

The MiniFuzz File Fuzzer is a basic testing tool designed to help detect issues that may expose security vulnerabilities in file-handling code. This tool could be helpful for Windows Phone developers that parse files in their applications.

Banned.h

The banned.h header file is a sanitizing resource which supports the SDL requirement to remove banned functions from code. It lists all banned APIs and allows any developer to locate them in code. This tool could be helpful for developers that are building a Web service.

You can connect to a web service using an SSL connection as long as the server’s SSL certificate is valid for the target web site and issued by a trusted authority. Before testing the SSL connection from your application, you can try to navigate to the web site using Windows Phone Internet Explorer. If the certificate causes a warning or error while using the browser, it is likely that the connection will fail in your application as well.

To see a full list of SSL root certificates that ship with Windows Phone, see SSL Root Certificates for Windows Phone.

You can add a certificate authority to the trusted authorities list, but adding Client SSL certificates is unsupported.

You can use the ProtectedData class to easily encrypt and decrypt data using the Data Protection API (DPAPI). For more information, see How to: Encrypt Data in a Windows Phone Application.

For more information about how to handle security with web services, see Web Service Security for Windows Phone.

When an application needs to use APIs associated with the following items, it will be automatically granted a corresponding capability to use them during the application submission and certification process for App Hub. These capabilities are disclosed to an end user when viewing an application to purchase on Windows Phone Marketplace. Certain capabilities such as Location Services are displayed prominently.

For a full list of capabilities, see Application Manifest File for Windows Phone.

Windows Phone supports the following cryptographic algorithms:

  • AES

  • HMACSHA1

  • HMACSHA256

  • Rfc2898DeriveBytes

  • RSA

  • SHA1

  • SHA256

Did you find this helpful?
(1500 characters remaining)