Welcome!

.NET Authors: Brad Abrams, Alin Irimie, Colin Walker, Maureen O'Gara, Reuven Cohen

Related Topics: .NET

.NET: Article

Securing .NET Compact Framework Solutions

Securing .NET Compact Framework Solutions
By Jon Box
Article Rating:
October 7, 2003 11:16 AM EDT
Reads:
 15,506

In recent times, and with good reason - as attacks by worms such as Code Red, Nimbda, and Slammer have shown - security has been pushed to the forefront of the minds of architects and developers. And just as Microsoft has rededicated itself to security through its Trustworthy Computing Initiative, your organization should be sure to design and implement its applications using secure coding practices and principles. Even though .NET Compact Framework applications may at first appear immune to such attacks, their connection to back-end systems and their portability introduce a variety of security risks that must be mitigated.

In this column we'll review what you'll need to consider to implement security at the device, application, and communication layers.

Secure the Device
The first layer of security to consider is that provided by the device itself. In addition to relying on mechanisms provided by the device manufacturer or platform (such as the Pocket PC running on Windows CE), your organization can augment the OS software with third-party solutions. Generally, the types of security that can be used to protect the device fall into the categories of authentication, antivirus protection, and lockdown.

  • Authentication: The simplest step organizations can take to protect devices on which Compact Framework applications run is to require some form of authentication. For example, Pocket PC 2002 and later devices running Windows CE support both simple and strong power-on password authentication. By enabling this feature on the device, the user must type in a simple four-character, or more complex seven-character, password at a configurable interval that defaults to one hour. If a user enters an incorrect password, an exponentially increasing time delay is enforced, making it very difficult to repeatedly guess the password. Third-party vendors, such as Trust Digital LLC through its PDASecure product, provide power-on password authentication with additional options that include locking the device after a certain number of invalid password attempts and additionally requiring a soft reset, hard reset, or even "wiping" the device of its data.

    Although this form of authentication can be quite effective, it is based on knowledge of a password that can perhaps be obtained through illegitimate means. To implement authentication based on possession of a physical item like a smart card or a cryptographic certificate located on a removable storage card, or based on user identity through biometric (e.g., fingerprint) or signature identification, third-party products are required. Vendors such as A2000 Distribution, Certicom Corporation, and Cloakware Corporation provide a variety of such solutions.

  • Antivirus Protection: Even though viruses that target mobile devices are not as prevalent as those targeting desktop computers, they are still a potential threat to any software on the device. Typically, however, devices are not damaged by viruses but rather pass them into a corporate network via e-mail attachments and documents. There are, as you might expect, a variety of antivirus packages on the market for devices such as the Pocket PC, from vendors including McAfee, Computer Associates, and F-Secure. Additionally, personal firewall products such as VPN-1 are available from vendors such as Check Point Software Technologies Ltd.

  • Lockdown: Following the accepted security principle of "reducing the attack surface," many organizations may wish to disable some features of the device. Third-party software such as PDASecure, for example, does just that by password protecting or disabling infrared communications, ActiveSync, and the voice recorder.

    Secure the Application
    The second layer to which security should be applied is the application itself. Typically, such security includes the concepts of authentication, data protection, and user input.

  • Authentication: Of course, the main way to secure an application on the device is by requiring the user to present credentials in order to be authenticated by the application. However, depending on what data source the application uses and how it creates a connection, this process can vary greatly. For example, a Compact Framework application might need to authenticate directly to SQL Server when using the SQLClient .NET Data Provider, to a Web server and SQL Server when using Remote Data Access or replication with SQL Server 2000 Windows CE Edition (SSCE), through a SOAP request when using an XML Web service, or through HTTP when using the HTTP pluggable protocol.

    In each of these cases your application must manage the credentials. In the case where multiple sets of credentials are required (for example, for a proxy and Web server in addition to SQL Server) it is a good practice to store the credentials in an encrypted database or file on the device or even on a storage card that is required to be inserted before the application can run.

  • Data protection: This concept involves two key aspects. First, any local data used by the application must be secured. This can be most easily accomplished using the built-in encryption feature of SSCE, which encrypts the database using the RC4 symmetric encryption algorithm with a key generated from an MD5 hash of the password (which implies that the strength of the encryption is dependent on the length of the password chosen). However, if local data is stored in a file it will need to be encrypted using the CryptoAPI (which supports 128-bit encryption on Pocket PC 2002 and Pocket PC 2000 with the Microsoft High Encryption Pack installed) since the System.Security. Cryptography namespace is not supported in the Compact Framework. Additionally, third-party encryption tools such as PDASecure support encryption of individual files.

  • User input: As codified in the "Don't Trust User Input" security principle, you need to secure user input. This issue is most directly relevant when accepting user input that is subsequently used to query or update data in SSCE or on a remote SQL Server. Malicious users may attempt to insert or inject additional SQL into a TextBox control, thereby causing a possibly harmful statement to run against the database. Such SQL injection attacks can be mitigated by cleansing user input with a function. In general, user input can be checked using regular expressions through the RegEx class of the System.Text.RegularExpressions namespace. One interesting use of this class is to create a derived TextBox control that uses a regular expression to validate the text entered by the user.

    Secure the Channel
    The final aspect to securing an application involves securing the transmission of data across the network. This aspect can involve a wide range of issues, including the use of Secure Sockets Layer (SSL), Virtual Private Networks (VPNs), and Wired Equivalent Privacy (WEP).

  • Secure Sockets Layer: The most fundamental way to secure the communication channel between a device and network is the use of SSL over HTTP. Simply put, SSL uses public- and private-key encryption based on the RSA algorithm, along with the use of a digital certificate to encrypt all of the communication between a client and a server. Fortunately, support for 128-bit SSL is built into both Pocket PC 2002 and 2000 devices (with the Microsoft High Encryption Pack installed). Since SSL is used over HTTP, Compact Framework applications can use it when connecting to a back-end server using SSCE connectivity, XML Web services, or the HTTP pluggable protocol.

    On the server side, the IIS server must have a digital certificate installed for the virtual directory in which the resource (the HTML page, for example) resides. The certificate may be either one obtained from a trusted certificate authority such as VeriSign or one generated internally within the organization using Microsoft Certificate Server. In the latter case the root certificate for your organization must also be installed on the device.

  • Virtual private networks: A second option for encrypting the communication channel is the use of VPNs that rely on protocols such as the Point-to-Point Tunneling Protocol (PPTP) and the IP security protocol (IPSec) to both authenticate and encrypt communications. While Pocket PC 2002 and Windows CE .NET 4.1 devices do not support IPSec, they do support PPTP when setting up connections in the Connections tab of the device Settings. After entering the address of the VPN server for the connection, the device will prompt the user for credentials when a connection is made. In order to provide VPN functionality to Pocket PC 2000 devices or to use IPSec, a number of third-party products are available from vendors, including Certicom Corporation and Check Point Software Technologies.

  • Wired Equivalent Privacy: In wireless networks, unlike in wired LANs, walls are ineffective as a means of security since radio waves are not bound by the walls used to protect the network. A first-generation technology used to protect such networks was based on the WEP security protocol. However, this protocol was found to contain flaws that left it vulnerable to attack. As a result, WEP is considered unsecure and should not be used without additional security such as VPNs or SSL.

    Although an initiative called WEP2 was developed to address the issues with WEP, many in the industry felt it too was vulnerable to attack. However, the 802.11i standard, currently in draft form, addresses many of these security issues. While the new specification is being ratified, wireless vendors have agreed on an interim solution called Wi-Fi Protected Access (WPA). WPA support is currently being rolled out in products such as Funk Software's Odyssey Client and Meetinghouse Data Communications' AEGIS Client. In the interim other organizations using server and client software primarily from Funk and Meetinghouse have gone forward and implemented the Extensible Authentication Protocol (EAP) over the competing Tunneled Transport Layer Security (TTLS) protocol developed by Funk and Certicom and the Protected Extensible Authentication Protocol (PEAP) developed by Microsoft and Cisco Systems to allow secure access to WLANs on their corporate campuses. In addition, third parties such as MobileSys, Inc., and Altarus Corporation offer wireless encryption technology.

    Security Is Key
    We hope this column has given you a framework for thinking about how to secure your .NET Compact Framework applications.

    • Published October 7, 2003 – Reads 15,506
    Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
    Syndicated stories and blog feeds, all rights reserved by the author.

    More Stories By Jon Box

    Jon Box is an Architect Evangelist in Developer & Platform Evangelism with the Microsoft Corporation. He coauthored Building Solutions with the Microsoft .NET Compact Framework, published by Addison-Wesley, and blogs at http://blogs.msdn.com/jonbox/default.aspx.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.