Windows
Mobile includes several options for networking, and most programming is
performed through the standard WinSock API. All Windows Mobile devices
support data plans allowing complete Internet access. Recently, an
increasing number of devices are able to use Wi-Fi when associated with a
local access point. Additionally, Windows Mobile devices can use a PC’s
network connection when cradled. This feature is called passthrough networking.
Connection Manager
Windows
Mobile devices can exist on several different networks at any one time.
The Connection Manager (CM) component is responsible for managing
network connections and determining the most efficient, secure, and
cost-effective route. CM performs the hard work of juggling the
different networks that a mobile device travels between. Connection
Manager is accessible through the Win32 API and the ConnMgrXXX group of
functions.
To manage network
security, CM maintains a security level for each connection and network.
This security level is represented by a DWORD on a sliding scale, with 1
being the most secure. Applications can request that CM provide a
network connection with a minimum security level. If no connection
exists at the desired security level, CM will attempt to find a network
and create a connection at the desired security level. If no connection
is available, CM will return an error code. Regardless of the security
level managed by CM, application developers must always be aware of the
end network that their traffic will travel across and design their
applications accordingly. For example, the most secure type of
connection is a Desktop-Passthrough (DTPT) connection. Most DTPT
connections eventually route to the Internet, so although the actual
device-to-computer connection may be secure, the end path is not.
WinSock
Included in Windows Mobile is a
complete Berkeley Sockets API implementing the standard socket functions
(connect, recv, send, accept, and so on). This API supports generic
sockets and is used for IPv4, Bluetooth, and Infrared Data Access (IrDA)
connections. Both client and server roles are possible. A complete IPv4
stack is provided with support for the TCP and UDP transport layer
protocols.
IrDA
On devices with an
infrared port, Windows Mobile supports infrared networking for in-range
devices. To interface with IrDA, the standard WinSock API is used with
the AF_IRDA address family. A major difference between IrDA networking
and standard IPv4 networking is name resolution. IR devices tend to move
in and out of range, so standard name-to-address resolution would not
work very well. Instead, addressing information is contained in-band. To
discover devices, use the WinSock connect method and request an
IAS_QUERY of the surrounding area. Windows Mobile will perform a sweep
of the IR network, discover devices, and return available addresses.
Bluetooth
Bluetooth
support is included using the WinSock API. To use Bluetooth, use the
AF_BTH address family with the WinSock APIs. Windows Mobile can manage
the pairing of devices, but it may be up to a particular application to
accept a PIN on behalf of a user. For more information, consult the
WinSock and Bluetooth documentation on MSDN.
HTTP and SSL
Windows Mobile includes a
port of the Windows Internet (WinInet) library. This library is the HTTP
backend for Pocket Internet Explorer (IE) but is usable by application
developers as well. WinInet includes client support for HTTP, HTTPS, and
FTP. As an API, WinInet can be a little bit complicated, and it is
obvious that it was originally designed as the internal backend for IE.
WinInet supports
authentication using NTLM and basic authentication. More authentication
types can be added by catching HTTP 401 (Forbidden) errors and managing
the authentication headers manually. Kerberos and domain-joined
authentication functionality are not supported.
The Secure Channel
(SChannel) Security Support Provider (SSP) implements a complete SSL
stack with support for client certificates. WinInet uses SChannel for
SSL functionality. Application developers wishing to create SSL tunnels
can do so by manually using SChannel and the Security Support Provider
Interface (SSPI) functions.
To create a secure SSL
connection, the identity of the server’s certificate must be
cryptographically verified and “chained” to a root certificate. Windows
Mobile keeps a collection of root certificates in an internal
certificate store. You can view this store by launching the Settings
application, choosing the System tab, and starting the Certificates
application. To add new certificates, use ActiveSync. Certain carriers
may prevent certificate installation.
Be very judicious when adding
certificates to the Root Store because these certificates are completely
trusted, and the presence of an attacker’s certificate in the Root
Store could allow the attacker to spoof websites.
