Windows Phone 7 Development : Understanding Device Physical Security & Meeting Certification Requirements

1. Understanding Device Physical Security

With Windows Phone 7, customers rarely have to worry about sensitive data ending up in malicious hands if the device is lost or stolen. That is because several standard features that come complimentary with the phone (i.e., no extra charges) make it possible to feel confident about the security of the device. In this section, we will walk you through the Windows Phone 7 physical security safeguards that Microsoft provides.

1.1. Map It

From an individually customized web site, Windows Phone 7 users will be able to see the location of their phones using Bing maps.

1.2. Ring It

From that same web site, you can instruct the phone to ring for 60 seconds using a special ringtone, even if the ring tone has been turned off.

1.3. Lock It and Display a Message

You can also lock the phone from the web site and display a custom message to instruct people who may have found your phone on how to get in touch with you.

1.4. Erase It

Finally, if all is lost and there is no hope of recovering the phone, you can remotely wipe all of the data from that phone and reset it to factory settings.

As you can see, the Windows Phone 7 security story is very compelling, especially for the first generation of this device. You can expect this story to only become better and more feature-rich in the very near future. Certainly, more and more features from the full .NET framework will find their way onto the phone, which should further contribute to the security of the device.

1.5. Capability List

Windows Phone Marketplace fully discloses to the user whether an application is relying on any of the following services for proper operation:

• Gamer Services

• Location Services

• Media Library

• Microphone

• Networking

• Place Phone Calls

• Push Notifications

• Sensors

• Web Browser

These capabilities are requested on a Windows Phone 7 device when an application developer submits her application for certification. Only the requested capabilities are granted, protecting device users from unexpected behavior of potentially privacy-intruding applications.

2. Meeting Certification Requirements

Microsoft documentation on security in Windows Phone 7 lists explicit requirements regarding application code that gets rejected during the certification phase of an application.

2.1. Application Must Implement MSIL Code

Microsoft imposes a requirement on Windows Phone 7 application developers to use managed code to construct their applications. Strong typing, bounds checking and memory management features of managed code help minimize the most common types of attacks (also referred to in the security community as "attack vectors") on both the application and the Windows Phone 7 application platform.

Generally, if you use C# language with its default settings, you will be in compliance with this restriction imposed by Windows Phone Marketplace. The problems will arise, however, if you venture into unsafe C# code territory, which can be enabled by using the unsafe keyword in a method signature. In addition to the unsafeFigure 19-11. As an example of unsafe code, consider the following code, which uses a simple SquarePtrParam function to accept a pointer variable (non-MSIL code) and perform pointer arithmetic on it: keyword, applications with unsafe code must be compiled with a special switch, as shown in

public partial class MainPage : PhoneApplicationPage
    {
        unsafe public MainPage()
        {
            int i=5;
            InitializeComponent();
            SquarePtrParam(&i);
            PageTitle.Text = i.ToString();
        }

        // Unsafe method, using a pointer to square the number
        unsafe static void SquarePtrParam(int* p)
        {
            *p *= *p;
        }
    }

The good news for Windows Phone 7 developers is that while the foregoing code is a perfectly valid .Net code, the Windows Phone 7 templates in Visual Studio disable the option to compile unsafe code. This option is generally found under Project => Properties => Build tab, and the check box "Allow Unsafe Code" is grayed out on Windows Phone 7 templates, making the option of writing unsafe application for Windows Phone 7 a challenging exercise. And even though it is possible to work around this limitation by modifying the project file (.csproj) using a text editor and specifying the <AllowUnsafeCode> attribute, it is certainly not worth the trouble because Windows Phone Marketplace will reject the application anyway.

Figure 1. Applications that implement unsafe code must be compiled with a special switch.

2.2. Application Must Not Implement Any Security-Critical Code

With .Net version 4.0, Microsoft has moved away from the complexities of its Code Access Security (CAS) model and towards a simpler model it calls the Transparent Security model. The first transparency rule set was initially introduced in .Net 2.0 and then expanded to Transparency Level 2 in .Net 4.0. With Transparency Level 2, code is segregated into three types: transparent code, security-safe-critical code, and security-critical code, which are discussed in the following sections.

2.2.1. Transparent Code

In the transparent category, there are applications that run in a sandbox, which are pretty much all of the Windows Phone 7 applications that you ever write, and these applications have a limited permission set granted by the sandbox. That means that as a developer you do not have to be concerned about checking security policies when you write your applications, as long as you don't try to perform any operation deemed not accessible by the transparent code. For reference purposes, here is the list of tasks that transparent applications are not permitted to perform:

• Directly call critical code

• Perform an Assert operation or elevation of privilege

• Contain unsafe or unverifiable code

• Call native code or code that has the SuppressUnmanagedCodeSecurityAttribute attribute

• Call a member that is protected by a LinkDemand

• Inherit from critical types

2.2.2. Security-Safe-Critical Code

In the security-safe-critical category, there is code that is fully trusted but is still callable by transparent code. It exposes a limited surface area of full-trust code. Correctness and security verifications happen in safe-critical code.

2.2.3. Security-Critical code

Finally, there is a category of code that can't be called by transparent code. This is usually security-critical code that typically implements system-level functionality and has unlimited access to Windows Phone resources, making it a perfect place to embed malicious behavior. Therefore, Microsoft disallows this type of code, and to successfully pass Windows Phone Marketplace certification criteria, applications must not implement any security-critical code. In addition, applications must not invoke native code via PInvoke or COM Interoperability.

You will most likely never have to worry about the ins and outs of the Transparent Security model when you program for Windows Phone 7. But in case you decide to try to implement unsafe or security-critical code in your application, remember that Marketplace certification tests will quickly uncover this type of behavior and deny entry to your application.