Enhancing Secure Communications with Microsoft Windows CE 2.1

Communicating over a network usually means that your target will be only one of many recipients of your message. For example, local area network transmissions can be received by every computer on the local branch of the network. Internet transmissions may pass through a number of different computers and routers before reaching their destination, such as a specific computer on a local area network.

Users or applications on computers that receive the message may be able to read the contents of that message. The only way to be certain that your message can only be read by its intended recipient—and no one else—is to encrypt it before sending, and decrypt it after it is received. Another important security technique involves authentication, the process of determining that the person sending the data actually is who she claims to be.

If you have a need for secure communications, Windows CE provides several programming options to help secure communications, described here in order from the highest-level interface to the lowest-level interface:

• The WinInet API provides a high-level mechanism for FTP and HTTP communications with enhanced security. It uses the secure sockets extension to Winsock.
• Winsock can also be used directly. Secure Sockets Layer 2.0 and 3.0 and the Private Communication Technology (PCT) 1.0 security protocols are supported. The same three protocols are available through WinInet, but Winsock provides a greater degree of flexibility in how they are used.
• The Security Support Provider Interface (SSPI) is used to request an authenticated connection from a security provider. Winsock uses SSPI internally, but you can also use the API directly for more control over the process.
• The Cryptography API allows applications to control most aspects of encryption.
• Authentication is provided at the data-link level of the network stack by the Password Authentication Protocol (PAP), Challenge Authentication Protocol (CHAP), and Microsoft CHAP.

  The following figure schematically illustrates the Windows CE security architecture.

  

  Figure 1.

  In general, the higher level approaches are simpler to use, but offer less control over how encryption is handled. The following sections of this paper introduce each of these programming interfaces. For complete information, including sample code, please see the Windows CE Toolkit for Visual C++ 5.0.

  Using Secure Sockets: WinINet or Winsock

  Probably the simplest way to implement communications with enhanced security is to create a secure socket connection. After a secure socket connection is established, you simply communicate as usual, while Winsock automatically handles encryption and decryption. Three security protocols are available: SSL 2.0, SSL 3.0, and PCT 1.0.

  There are two ways to use secure sockets:

  1. Use the WinInet API. For encrypted FTP or HTTP communication, this is the simplest approach. Set the appropriate security flags when opening a connection and making a request. WinInet handles the details of setting up the secure socket connection. The remainder of the session is handled in exactly the same way as with a non-secure connection. Encryption and decryption are automatic.
  2. Use the Windows Sockets API. You use setsockopt to specify a secure connection, and WSAIoctl to specify the protocol. Once a secure connection is established, your application simply uses send and recv as it would for a normal socket connection. You must also implement a callback function to receive authentication information. The procedure for creating secure connections is very similar to the procedure for creating non-secure sockets.

     WinInet gives you relatively little flexibility in how the connection is set up. For instance, you cannot select the security protocol that will be used. For more control over the process, you can use Winsock to make the connection and handle communication. You can invoke the security protocols when you establish the socket connection, or you can wait until you need to use them. Once the protocols are invoked, Winsock automatically handles encryption and decryption of the data.

     The Security Support Provider Interface

     Microsoft provides an extensible security layer that applications can call at the top end, while third party security support providers can implement DLLs that map these calls to their specific security system. In this way, applications can use one high-level interface yet interact with very different security systems. New security systems can be added in the future without requiring changes to the applications.

     This general-purpose security layer, the Security Support Provider Interface (SSPI), is modeled after Internet RFC 1508, the Generic Security Services API (GSSAPI), while tailored for use with Microsoft Windows.

     SSPI can be thought of as the Microsoft Win32 interface between transport level applications and network security service providers, offering an architecture that integrates different security models. SSPI enables applications to call one of several security providers to obtain an authenticated connection without knowledge of the details of the underlying security protocol.

     A security provider is a dynamic-link library (DLL) that implements the SSPI and makes one or more security packages available to applications. A security package maps the SSPI functions to an implementation of the security protocol specific to that package, such as Windows NT LAN Manager (NTLM) or SChannel. Security packages are sometimes referred to as "SSPs", such as the "NTLM SSP".

     SSPI does not establish logon credentials because that is generally a privileged operation handled by the operating system. However, after logon credentials for a user are established, the application can use the SSPI functions to create a security context for that user. The security context is an opaque data structure that contains the security data relevant to a connection (such as a session key), the duration of the session, and so on. The client and server in a communication link must cooperate and negotiate to create the security context, and having done so, they can use it with the SSPI message support functions to help ensure message integrity and privacy during the connection.

     SSPI consists of following groups of API functions:

     Credential Management APIs—Credential management APIs provide access to credentials (password data, tickets, etc.).

     Context Management APIs—Context management APIs provide methods for creating and using security contexts. The contexts are created on both client and server side of a communication link. These contexts can then be used later with the message support APIs.

     Message Support APIs—Message support APIs help provide communication integrity and privacy services based on a security context.

     Package Management APIs—Package management APIs provide services for different security packages that the security provider supports.

     The capabilities of the security package determine what services it provides to the application. These capabilities include, for example, support for authentication, mutual or client-only, or to help ensure message integrity and message privacy. Applications will typically select security packages based on the type of security capabilities available to meet the application needs.

     The Microsoft CryptoAPI

     The Microsoft CryptoAPI supports the security infrastructure needed to encrypt your data so that it can be safely transmitted over a public network. Microsoft currently uses the RC4 algorithm from RSA, Inc. and the U.S. government standard DES algorithm (although there are provisions for allowing additional algorithms). RC4 requires both the sender and receiver of the message to have the same secret encryption key. The keys are exchanged between sender and receiver in a certificate, signed by a "Certificate Authority," that guarantees the key is authentic.

     The Microsoft CryptoAPI includes API functions that support encryption, decryption, and certificate management.

     A remote site establishes its trustworthiness by obtaining a certificate from a Certifying Authority (CA). Windows CE supports X.509 style certificates. The first CA may in turn have obtained a certificate from a higher CA, and so on, creating a chain of trust. The decision on whether to trust the site or not is based on the root CA of the chain of trust.

     Windows CE maintains a database of trusted CAs. When a secure connection is attempted by an application, Windows CE extracts the root certificate and checks the CA against the database. It then passes the results of that comparison and the root certificate itself to the application's callback function.

     Your application is responsible for deciding whether or not to trust a particular certificate or CA. You can accept or reject certificates based on any criteria you wish to use. If you reject the certificate by returning an error from the callback function, the socket connection is not completed. At a minimum, a certificate should meet two basic criteria: It should be current, and the identity contained within the certificate should match that of the root CA.

     Authentication Using Low-Level Protocols

     In addition to these high-level interfaces, Windows CE also supports authentication using the low-level protocols. For serial-link networking over a cable or modem, Windows CE supports the widely used Serial Line Interface (SLIP) and Point-to-Point (PPP) protocols. For authentication using these protocols, Windows CE supports:

     • Password Authentication Protocol (PAP)
     • PAP uses clear text (unencrypted) password authentication.
     • Challenge Authentication Protocol (CHAP)

       CHAP requires a challenge response with encryption on the response. Windows CE supports the DES and RSA MD4 encryption algorithms for CHAP authentication.

       Microsoft Challenge Authentication Protocol (MS-CHAP)

       This version of the encrypted challenge response uses Microsoft's version of the RSA MD4 standard, and represents the most secure encryption algorithm supported by Windows CE.

       For More Information

       Complete documentation of the Windows CE operating system is included with the software development kits:

       • The Windows CE Toolkit for Visual C++ 5.0
       • The Windows CE Embedded Toolkit for Visual C++ 5.0

         These software development kits contain samples and complete documentation regarding the API programming interfaces.

         The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only.

         This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

         Other product and company names mentioned herein may be the trademarks of their respective owners.

         
         

         ---

         © 2004 Microsoft Corporation. All rights reserved.