.NET Compact Framework Security Considerations

The .NET Compact Framework is Microsoft’s attempt to bring the functionality you enjoy when working with a desktop, LAN, or Internet application to the Pocket PC. You can use the .NET Compact Framework to produce a wide variety of applications for devices such as the Pocket PC, SmartPhone compatible devices, and some embedded applications. Theoretically, your next home security system could have the .NET Compact Framework installed. Web-based application programming extends the range of application types and platforms to most wireless devices that can support a Web browser interface. For example, if you need to support both the Pocket PC and the Palm, you’d use a Web-based application to do it.

The following sections describe the security implications of working with wireless devices using the .NET Compact Framework. These sections don’t discuss other wireless security issues in very much detail. You’ll also learn a quick way to determine which classes the .NET Compact Framework supports. By using careful programming strategies, you can often reduce the amount of work required to produce a secure application that works with little recoding on a wireless device. Finally, you’ll see a simple programming example with a few of the security measures you’ll need to implement. This programming example shows functionality provided by Visual Studio .NET 2003 (the first version that has embedded .NET Compact Framework support), so it probably won’t work with older version of Visual Studio .NET, even if you’ve added .NET Compact Framework support.

Understanding Wireless Security Issues

It’s important to understand that at best the .NET Compact Framework can secure the data within the application you create. It can’t secure the wire (which includes all of the connectivity between two machines) because the wire isn’t physical. Using wireless transmission leaves the communication path open. Even Wired Equivalent Privacy (WEP) has limitations that make it less than a perfect solution for wireless security. (See the 802.11 Planet article at http://www.80211-planet.com/tutorials/article.php/2106281 for details.) Some users make the wireless problem worse by not changing the default Service Set Identifier (SSID) or using the SSID as part of the WEP encryption key.

Wireless data interception isn’t a new problem—everyone who has ever used radio to transmit secret data has had the same problem. For example, many people imagine that spies obtain the secret information used to fight wars, but most modern wars (including World War II) have relied on breaking the enemy’s radio codes and using that information to listen in on the enemy’s conversations. Any data transferred over the air is susceptible to interception and interpretation by someone else.

The .NET Compact Framework also can’t secure the transfer point between the wireless connection and the physical network (part of the access point). Current systems translate the data at this connection point, which means decrypting the data, performing the translation, and encrypting it again. This particular area is the point where many crackers break into the system. The lack of processing power for wireless devices makes it harder to use strong encryption, which only makes the problem worse. (Read the eWeek article at http://security.ziffdavis.com/article2/0,3973,1115544,00.asp to learn how you can control rogue access points.)

When you couple these special wireless application problems with the problems of a laptop or desktop system (such as stupid user tricks and inept enterprise policies), you have a significant security threat that the .NET Compact Framework can’t address. In short, anyone who relies on wireless technology to protect the innermost secrets their company possesses is in for a surprise. The .NET Compact Framework can help you make the data more secure, but these external issues make it impossible for any .NET developer to guarantee the security and data integrity of a wireless application.

Advances in Mobile Device Security

Mobile device vendors understand that security is a significant issue for their products. Most vendors are working on new security features that make security easier. For example, according to InfoWorld, ARM is adding hardware-based security to their processors (http://www.infoworld.com/article/03/05/27/HNarmsecure_1.html). An interesting concept to take from this story is that no security scheme seems to fulfill everyone’s needs. Although a hardware-based security setup would tend to keep crackers at bay, at least for awhile, many people are concerned that vendors will use the security feature to enforce digital rights management (DRM). The same technology that lets you lock up an application could allow someone else to lock up data or the off-the-shelf application your company purchased. Another vendor making the push into hardware-based security is Cisco. You can read this story at http://www.infoworld.com/article/03/05/21/HNciscosecure_1.html. The point is that you will need to design your wireless application with security from other sources in mind.

The problems with wireless security get worse. In some respects, wireless security flaws are a matter of developer attitude toward the devices. Many developers find wireless devices a nuisance because they normally require separate coding. Even using the .NET Compact Framework or Web-based applications is only a partial solution because desktop users also demand full functionality from their applications—most wireless device applications have fewer features than do their desktop counterparts because they have less capacity. As a result, some wireless applications are rushed and not fully secured because they aren’t fully tested.

Another problem that you’ll have to face is user demand. Users who don’t fully appreciate the significant security threats posed by wireless devices are asking for more applications. If wired device vendors have their way, users might soon request applications that are difficult to secure and could be illegal depending on how you interpret the law. Consider the InfoWorld story on biotechnology at http://www.infoworld.com/article/03/04/24/HNbiotech_1.html. On the surface, such new applications are laudable. However, given the current state of wireless security and the requirements of the Health Insurance Portability and Accountability Act of 1996 (HIPAA), it’s reckless for a developer to consider creating such an application even if the vendor provides the proper tools. You can learn more about HIPAA on the Health and Human Services site at http://www.hhs.gov/ocr/hipaa/ and the HIPAA.ORG site at http://www.hipaa.org/.

As you can see, the security problems of wireless applications are significant and you can’t do anything to make security even approach a reasonable level of reliability. For this and many other reasons, it’s probably a good idea to restrict any data you transfer using a wireless connection significantly. Although the .NET Compact Framework can help you secure the transmission a little, it simply isn’t enough to make security good enough for critical data.

Discovering Which Classes Apply to Both Environments

The .NET Compact Framework isn’t the same as the .NET Framework you normally use—you’ll notice differences between the two. Most of the differences are due to environment. All of the wireless devices you use have limited capability—although some industry pundits predict that the Personal Digital Assistant (PDA) will eventually catch up with the desktop. For now, however, you need to consider the capacity limitations and understand how they affect .NET functionality. Microsoft just couldn’t make the two environments the same.

Fortunately, Microsoft makes it relatively easy to perform a comparison as long as you have a newer version of MSDN to use. The Class Library Comparison Tool provides a color-coded list of the .NET Framework classes and shows which classes the .NET Compact Framework implements. This tool appears at ms-help://MS.MSDNQTR.2003FEB.1033/dv_spchk/html/NET _Compact_Framework.htm. When you first open this tool, you see a list of display options similar to the ones shown in Figure 13.1.

Figure 13.1: Use the display option settings to filter the output of the Class Library Comparison Tool.

Once you choose some display settings, you can start looking at the classes that interest you. Just click through the hierarchical list as usual. For example, Figure 13.2 shows the System.Collections.ArrayList class comparison.

Figure 13.2: Display an individual class and you see how the two frameworks compare.

The color-coding does make the list a lot easier to see than the image in the book. Fortunately, each entry uses a different icon as well. For example, both frameworks support all of the constructors. They also support the Add() and AddRange() methods. However, you can only use the BinarySearch() method with the .NET Framework—wireless devices won’t support this method.

Unfortunately, some exceptionally important security classes are missing. For example, notice that the entire System.Security.Permissions namespace is missing. This omission makes simple security measures such as imperative (Listing 1.2) and declarative (Listing 4.4) security impossible. The System.Security.Principal namespace is also missing. This means you can’t create a WindowsPrincipal object (Listing 1.1) to verify a user’s role.

Interestingly enough, the .NET Compact Framework has a few features that the .NET Framework doesn’t. You can find a complete list of these features in the Classes Exclusive to the .NET Compact Framework help topic at ms-help://MS.MSDNQTR.2003FEB.1033/ dv_evtuv/html/etconclassesexclusivetonetcompactframework.htm. These new classes fall into three categories.

Infrared Data Association (IrDA) Support These classes help you communicate with the IrDA port on your wireless device (if it has one). I wish that Microsoft had chosen to make these classes available earlier and make them available to the desktop. The problem is that Microsoft doesn’t provide good support for IrDA devices on desktop machines, so you might find yourself resorting to older Win32 API programming techniques to develop a complete solution.

SQL Server CE Support SQL Server CE is a special version of SQL Server for wireless devices. Many developers complain about its lack of functionality. In general, it is a limited solution for very special needs—I haven’t found any yet and haven’t heard about good uses for this product from other developers either, so the need is very special.

Microsoft.WindowsCE.Forms Classes The support provided by these classes wouldn’t have a place anywhere on the desktop, so you should become familiar with this group of classes immediately. It’s interesting to note that these classes provide a level of application control that does fit within the realm of security. For example, you can choose to enable or disable the InputPanel as needed to ensure safe operation of your application.

Developing a Simple .NET Compact Framework Program

One of the first concerns many developers have with wireless devices is the safety of their applications. A cracker could tamper with an application and many users wouldn’t notice until the virus has so corrupted their data that any attempt at recovery is futile. Unfortunately, attempting to protect the application using other techniques in this book won’t work for the most part. Yes, you can sign the file, but as demonstrated in the “Validating Your Code” section of Chapter 6, smart crackers can still get around your security measures. Unfortunately, the Pocket PC doesn’t provide quite as many resources for solving this problem, but you can still do it.

Note

The .NET Compact Framework can work with a wide variety of devices to create a broad range of applications. For example, the default Visual Studio .NET installation includes both Windows CE and Pocket PC platform support for the Smart Device Application Wizard. Both of these platforms support a Windows application, class library, non-graphic (console) application, and an empty project. In short, this chapter won’t cover all of the project types—I chose projects based on how they could present security issues, rather than application programming technique.

Listing 13.1 shows a technique for checking the hash code of an assembly. The method isn’t quite as refined as the desktop version shown in Listing 6.1, but it does work well enough that most crackers won’t try to circumvent it. (You can find this example in the \Chapter 13\C#\SimpleSecurity or \Chapter 13\VB\SimpleSecurity folder of the source code located on the Sybex Web site.)

Listing 13.1 Application Security Technique

private void btnTest_Click(object sender, System.EventArgs e) {    Assembly    Asm;        // Assembly reference.    FileStream  FStrm;      // File holding data.    String      HashOut;    // Hash value in string form.    Char[]      Converter;  // Conversion array.    Byte[]      Output;     // Output data.    Int32       Counter;    // Loop counting variable.    // Get the current assembly.    Asm = Assembly.GetExecutingAssembly();    // Check for the hash file.    if (File.Exists(@"Settings.TXT"))    {       // Open the file.       FStrm = File.Open(@"Settings.TXT", FileMode.Open);       // Determine the file length and read it.       Output = new Byte[FStrm.Length];       FStrm.Read(Output, 0, Output.Length);       // Convert the output to a string.       Converter = new Char[Output.Length];       for (Counter = 0; Counter < Output.Length; Counter++)          Converter[Counter] = Convert.ToChar(Output[Counter]);       HashOut = new String(Converter);       // Close the file stream.       FStrm.Close();       // Perform the comparison.       if (HashOut == Asm.GetHashCode().ToString())          MessageBox.Show("The code is safe.", "Application Status");       else          throw new SecurityException("Unsafe Application");    }    else    {       // Create a new file to contain the hash code.       FStrm = File.Create(@"Settings.TXT");       // Get the hast code and convert it to a Byte array.       HashOut = Asm.GetHashCode().ToString();       Output = new Byte[HashOut.Length];       Converter = HashOut.ToCharArray();       for (Counter = 0; Counter < Converter.Length; Counter++)          Output[Counter] = Convert.ToByte(Converter[Counter]);       // Write the hash code to disk and close the file.       FStrm.Write(Output, 0, Output.Length);       FStrm.Close();       // Display a success message.       MessageBox.Show("Hash value successfully written!",                       "Data Output");    } }

The code begins by getting the current assembly using the Assembly.GetExecutingAssembly() method. The desktop version of the Assembly object contains a number of useful features, including the Evidence property. The .NET Compact Framework lacks support for this feature, but it does include the GetHashCode() method, which the example uses to check the validity of the code.

Once the code obtains the assembly information, it checks for the hash file using the File.Exists() method. The first time the application runs, the file won’t exist, so the code uses the File.Create() method to create a new file. It then uses the Asm.GetHashCode() method to obtain the current hash value and converts it to a Byte[] array. The FStrm.Write() places the data on disk and the FStrm.Close() method closes the file.

Note that the example uses a simple text file for storage to make it easy for you to check the application results and remove the file when you get finished working with the example. In a real world implementation, you should choose a file with a unique name, store it in a unique location, and protect it as much as possible. You could also encrypt the content of the file to make it difficult to modify the content.

When the hash file exists, the code opens the file using the File.Open() method. The code converts the input data to a string. It then uses the string contained in HashOut to compare the current hash value with the Asm.GetHashCode().ToString() method. Notice that you can throw a SecurityException exception if the hash values don’t match.

To test this program, try clicking Test twice. The first time you’ll see the “Hash value successfully written!” message. The second time you’ll see the “The code is safe.” message. Open the File Explorer found in the Programs folder of the emulator (not on your desktop machine). Locate the Settings.TXT file in the MyDevice folder, as shown in Figure 13.3. Open the file and change the hash value to something else.

Note

Although every wireless application in this chapter is tested using a Pocket PC, all of the screenshots in this chapter rely on the emulator. They may vary slightly from the images you see on screen. Differing screen resolutions and device capabilities affect the appearance of the test applications on screen.

Figure 13.3: Locate the Settings.TXT file in the MyDevice folder so you can change the hash value.

Now that the program is set up for a failure, click Test. You should see an error message appear after a waiting period (normally a few seconds). Figure 13.4 shows a typical security exception when you use the emulator from the debugger.

Figure 13.4: Throwing a security exception when the hash values don’t match alerts the user to the problem.

As you can see, this error message looks very similar to the ones you receive when you work with desktop applications. I pointed this out because Microsoft has tried hard to make the development environment friendly (and, in this case, it shows). You could try to catch the exception, but, in this case, the output is more dramatic and likely to catch the user’s attention the first time. Figure 13.5 shows typical output from the emulator when you run the application without the debugger.

Figure 13.5: The wireless device user will see a message similar to this one when an application hash error occurs.

Tip

If you see a deployment error when you try to run the program from the debugger, verify that the application isn’t already running on the emulator. When the application runs, the emulator locks the file and makes it impossible to deploy the application. The debugger won’t run until it can deploy the latest version. Closing the existing copy of the application on the emulator usually solves the problem and lets you run the debugger.

Generally, I try to make the user’s life as easy as possible because it’s poor programming practice not to catch errors and handle them if possible. In this case, the error message occurs before the application is running (you might even include the check as part of the constructor), so displaying the actual error message isn’t such a big problem. Obviously, there isn’t any way to fail gracefully if the application has a security error that demonstrates some kind of tampering. The best practice is to inform the user immediately and end the program before it has a chance to load any data.