Building Secure GOV-LOB Windows Phone Apps. Part II, Session II

Previous Session II

Overview of Windows Phone Security Features

 

Managed code security and API access on WP7       

Windows Phone 7 applications can only be written using ‘managed’ code – specifically C# or VB.NET. This keeps a developer from becoming prey to vulnerabilities such as buffer overflows, format string errors, memory management errors, etc. which are common to unmanaged code written in C/C++.

Access to Windows APIs is also restricted in WP7. For example, 3rd party applications cannot access the Registry via an API, thus mitigating against a threat of Registry manipulation by malicious code that could force the device into an unstable state. Similarly, access to the physical file system of the device is not supported, reducing the risk of damage to system files on the device.

In general, 3rd party applications cannot directly access any system resources or call native APIs via P/Invoke. For example, file system access through System.IO.File or via P/Invoke is no allowed. Instead, developers must use the sandbox-restricted IsolatedStorageFile API.

WP7 3rd party applications are essentially sandboxed/least-privileged applications that are built using the Silverlight Framework or XNA Framework. Silverlight-based applications on WP7 run in out-of-browser (OOB) mode. XNA applications are more common in gaming scenarios.

WP7 applications run inside a managed sandbox which implements the Silverlight security model. Silverlight is supported by a stripped-down version of CLR called CoreCLR. Managed code in Silverlight follows the new CLR Security model based on the notion of ‘transparency’. This divides code into 3 layers (based on custom attribute annotations):

Transparent Code – with transparent code, permissions of the call stack cannot be elevated and hence transparent code can only run with same permission as the caller. All 3rd party application code and significant portions of framework libraries code is Transparent code. Transparent code:

• Cannot contain unverifiable code. This means that all of the code must be verifiably type-safe.
• Cannot, by itself, call native code via a P/Invoke or COM interop.
• Cannot access Critical code or data unless the target is marked SafeCritical

Again, all 3rd party application code in Silverlight runs as Transparent code.

SafeCritical Code – SafeCritical Code is the bridge between Transparent code and Critical code. SafeCritical code performs all the checks and ensures that Transparent code is clean to perform the critical operations. Basically SafeCritical code is expected to perform the necessary due diligence on the caller before, in its turn, calling Critical code.

Critical Code – Critical Code has the highest privileges and is not restricted in any way in the operations it can perform.

Summary of Layers:

Managed Layer

Code Annotated with

Role

Accessibility

SecurityCritical

System.Security.SecurityCritical

Fully trusted code. Can do pointer arithmetic and P/Invoke

Can only be accessed by SafeCritical layer.

SafeCritical

System.Security.SecuritySafeCritical

Acts as a bridge between Transparent and Critical code.

Can be accessed by all layers.

Transparent

System.Security.SecurityTransparent or UnAnnotated

Can call into SafeCritical code. All user application code is Transparent; any annotation on user code is ignored by the runtime.

Can be accessed by all layers.

Note that only Microsoft assemblies (i.e., those that ship in the device as part of the managed platform) are allowed to have these annotations and hence only they can directly access any native code. All 3rd party application code and libraries are themselves treated as Transparent code and can only access Transparent and SafeCritical methods in the managed platform APIs.

Execution Model

The Windows Phone 7 execution model governs application execution from launch to termination. One of the significant features of WP 7.0 execution model was that it only allowed one 3rd party application to run at a time. That is, at any given point of time, the only application that could run was the one in the foreground. Thus, in WP 7.0 background execution or multi-tasking of 3rd party applications was not supported and the only interesting states an application could be in were “Running”, “Tombstoned” or “Terminated” (see descriptions further below).

However with the release of WP 7.1, developers can utilize the multi-tasking feature of the release. A programming framework is provided for applications to manage their state as they are deactivated and reactivated. This not only enhances the performance of the foreground application and makes for a snappy mobile device experience but also provides a high quality end-user experience. WP 7.1 adds the ability to switch to a previously running application by pressing and holding the hardware Back button.

The following diagram provides lifecycle of Windows Phone Application in WP 7.1. In the below diagram, circles are application states, rectangles show either application or page level events where application should manage their state.

The various execution states an application can be in are described below:

a) Launching: Application will be in this state once the user taps on the application tile at start or at the application entry in the installed applications. Every time a user launches an application, a new instance of the application is created.

b) Running: After the Launching state, the application enters the Running state where the application performs most of its functionality and maintains any state it needs to manage.

c) Closing: Once the application is in a Running state, the application can transit to other states depending on user interaction. One of the possible states after Running state is Closing state. When the user is at the first page of the application and presses the hardware back button the application will get terminated which results in bringing the application to Closing state. The only state in which an application can transit from Closing state is Launching state – i.e. , once the application is terminated then the user has to launch it again.

d) Deactivating: As discussed above, the Execution model allows only one 3rd party application to run at a time. So when an application is in Running state and some other application is invoked due to some reason (e.g., a phone call is received while playing a game), the execution model will deactivate the first application in this series - the game. However there is a difference between Deactivating and Closing. In case of Deactivating , the application is said to be Tombstoned meaning that the device OS will keep the details related to the application and allow the application to store some state which will help in reactivating the application if the user returns to the Tombstoned application.

e) Activating: An application can be activated only if it is Deactivated (i.e. , Tombstoned). Once the application is in Deactivated state, the possible states can be Launching state where the user launches a new instance of the application or Activating state where the user can resume from where s/he had left.

f) Dormant: This state is present in WP 7.1 release only as only WP 7.1 supports multi-tasking of applications. When the user navigates forward, away from an application, after the Deactivated event is raised, the operating system will attempt to put the application into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory. If the application is reactivated from this state, the application does not need to re-create any state, because it has been preserved. If new applications are launched after an application has been made dormant, and these applications require more memory than is available to provide a good user experience, the operating system will begin to tombstone dormant applications to free up memory.

g) Tombstoned: A tombstoned application has been terminated, but information about its navigation state and state dictionaries populated by the application during Deactivated are preserved. The device will maintain tombstoning information for up to five applications at a time. If an application is tombstoned and the user navigates back to the application, it will be relaunched and the application can use the preserved data to restore state. Otherwise, the application is simply terminated.

The PhoneApplicationService class exposes the four events: Launching, Deactivated, Activated, and Closing that capture the relevant state transitions. As an application developer it is important to understand the significance of each state and the corresponding transition and perform the necessary actions for proper state management for an application. Doing so correctly will ensure that there is no unexpected loss of user data. For instance, it is possible that a Tombstoned application may never be revived! As a result, an application developer should not count on that and should save any persistent data to IsolatedStorage during the Deactivated event.

Fast Application Switching: In WP 7.0, an application was automatically terminated when the user navigated away from it. In WP 7.1, applications are typically put into a dormant state when the user navigates away. In this state, the application is preserved in memory so that if the user returns to the application, it can resume almost instantly. Applications do not need to implement any code to enable fast application switching; it is enabled automatically. However, it is still possible that an application will be terminated while it is dormant. It is important that you design your application so that it handles these changes in state that occur throughout the application lifecycle.

Several new platform features are included in WP 7.1 that leverage the addition of support for multi-tasking and fast application switching.

These are outlined below:

• Background Audio: Allows applications to play audio even when the application is not running in the foreground.
• Scheduled Tasks: Allows an application to implement an agent that can execute code in the background even when the main application is not running. There are two ways one of these agents can be scheduled. A Periodic Task runs regularly for a short amount of time. A resource-intensive task runs for a longer period of time, but only when the device is in a state where resource-intensive processing will not disrupt the foreground experience.
• Background File Transfers: Allows an application to queue up multiple HTTP file transfer requests that will continue to be performed when the application is no longer running in the foreground. Both file download and upload are supported.
• Scheduled Notifications: Allow applications to register recurring and one-time alarms and reminders that pop up in the foreground on a predefined schedule.

In Part II, Session III we will explore the following topics:

• Multi-targeting and Application Compatibility
• Application Deployment and
• Device Security Features

Based on work from Manish Prabhu, Sameer Saran, Don Willits, and Dharmesh Mehta.

G E T F-R-E-E 
Phone: Tools, Devices
Cloud: Tools, Account
Client: WebMatrix
Resources: Infokit
Apps Ideas: Ideas

Comments

• Anonymous
  April 30, 2012
  Previous Entry In this entry we will cover: Multi-targeting and Application Compatibility Application

• Anonymous
  April 30, 2012
  Previous Entry In this entry we will cover: Multi-targeting and Application Compatibility Application

• Anonymous
  April 30, 2012
  Previous Entry In this entry we will cover: Multi-targeting and Application Compatibility Application

• Anonymous
  April 30, 2012
  Previous Entry In this entry we will cover: Multi-targeting and Application Compatibility Application

• Anonymous
  April 30, 2012
  Previous Entry In this entry we will cover: Multi-targeting and Application Compatibility Application