Securing Communications

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 using SSL, VPNs, WEP, and custom SOAP extensions.

Secure Sockets Layer

Perhaps 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 SSL is built into both Pocket PC 2000 and 2002 devices, although to support the more robust 128-bit keys, the Microsoft High Encryption Pack should be installed on Pocket PC 2000 devices.

Because SSL is used over HTTP, Compact Framework applications can use it when connecting to a back-end server using SQLCE Connectivity, XML Web Services, or the HTTP Pluggable Protocol, as mentioned earlier in the chapter.

For example, in an application that uses WebRequest, SSL can be enabled simply by changing the URL from "http" to "https"; when using SQLCE Connectivity, the InternetURL property can include "https" to enable SSL.

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 one obtained from a trusted CA such as VeriSign or one generated internally within the organization using Microsoft Certificate Server.^[10] In the latter case, and as mentioned in Chapter 7, the root certificate for your organization must be installed on the device, as documented in the SQLCE Books Online.

^[10] For more information on installing certificates, see the FAQs at www.iisfaq.com/default.aspx?View=P20.

Virtual Private Networks

A second option for encrypting the communication channel is the use of VPNs that rely on protocols such as PPTP and IPSec to both authenticate and encrypt communications.

While the Pocket PC 2002 and Windows CE .NET 4.1 devices do not support IPSec, they do support PPTP when setting up connections, for example on the Pocket PC 2002, in the Connections tab of the Device Settings dialog. After entering the address of the VPN server for the connection as shown in Figure 9-3, the device will prompt the user for credentials when a connection is made.

As a result, VPNs can be used transparently on top of any type of connection, for example when using the WebRequest class or even when using the Socket class in the System.Net.Sockets namespace.

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 that include Certicom Corporation and Check Point Software Technologies.

Wired Equivalent Privacy

An increasing number of devices connect directly to home and corporate LANs through 802.11 protocols. In these networks, unlike in wired LANs, walls are ineffective as a means of security because 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, which used a shared secret key and the RC4 algorithm; however, early in 2001, a team of researchers at the University of California, Berkeley, discovered flaws in WEP that left it vulnerable to attack, in part because of its use of 40-bit keys and its weak key-management scheme.[11] As a result, WEP is considered nonsecure and should not be used without additional security, such as VPNs, SSL, or patches like that created by RSA Security.[12] Although an initiative called WEP2 was developed to address the issues with WEP, including increasing the key size to 128 bits, many in the industry felt that it, too, was vulnerable to attacks. [11] See the PC World article referenced in the "Related Reading" section at the end of this chapter. [12] See the RSA Wireless Connection newsletter at www.rsasecurity.com/newsletter/wireless/2002_winter/feature.html.

However, the 802.11i standard, in draft form until the end of 2003, 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 Communications's 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), developed by Funk and Certicom, or 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 and Altarus Corporation offer wireless encryption technology.

Custom SOAP Extensions

Although the other techniques described in this section are more industry standard, developers may implement a custom form of channel security when using XML Web Services by employing a SOAP extension.

Simply put, a SOAP extension is a SOAP pre- and postprocessor that provides extensibility to the normal ASP.NET processing of a Web Service and can be used by both the Web application hosting the Web Service in IIS and in the Compact Framework application that consumes the Web Service on the device. The extension is developed by creating a class that inherits from the SoapExtension class in the System.Web.Services.Protocols namespace. Within this class, the developer can override methods such as ProcessMessage and ChainStream to inspect and alter the message, for example, to encrypt and decrypt the body of a SOAP message by calling private methods in the class. The structure of a SOAP extension is shown in Listing 9-4.

Listing 9-4 The Structure of a SOAP Extension. This listing shows how a SOAP extension would be structured. The ProcessMessage method is called at various stages during the processing of a SOAP message.

public class MyExtension : SoapExtension
{
    Stream oldStream;
    Stream newStream;

    //  Process the message
    public override void ProcessMessage(SoapMessage message)
    {
        switch (message.Stage)
        {
            case SoapMessageStage.BeforeSerialize:
                break;
            case SoapMessageStage.AfterSerialize:
                // User specific code to encrypt the stream
                break;
            case SoapMessageStage.BeforeDeserialize:
                // User specific code to decrypt the stream
                break;
            case SoapMessageStage.AfterDeserialize:
                break;
            default:
                throw new Exception("invalid stage");
        }
    }

    public override Stream ChainStream( Stream stream )
    {
        // Save the stream so the rest of the code can work on it
        oldStream = stream;
        newStream = new MemoryStream();
        return newStream;
    }
}

As Listing 9-4 shows, the MyExtension class overrides the ProcessMessage and ChainStream methods. The latter allows the stream to be captured for modification and the former is called at multiple stages during the processing of a SOAP message.

In order for the SOAP extension to be activated, the developer must also create a class inherited from SoapExtensionAttribute that is then used to decorate the method(s) for which the extension will be active. For example, for the simple extension shown in Listing 9-4, the following attribute could be created:

[AttributeUsage(AttributeTargets.Method)]
public class MyExtensionAttribute : SoapExtensionAttribute
{
    private int priority;

    public override Type ExtensionType
    { get { return typeof(MyExtension); } }

    public override int Priority
    { get { return priority; }
       set { priority = value; } }
}

This attribute can then be applied to a method in a Web Service and the corresponding method in the Web Service proxy class. Of course, because the Compact Framework does not support the cryptography classes required to perform the encryption and decryption of the SOAP body, developers will need to build two versions of the extension and attribute classes. In the Compact Framework version, PInvoke calls to the CryptoAPI, or a third-party library can be used, as discussed previously in this chapter. In addition, remember that if a symmetric encryption algorithm is used, both ends of the channel will need to have access to the agreed-upon key to encrypt and decrypt the data. This is not as trivial as it might sound because a nonsecure key exchange leaves the encrypted data vulnerable.