“消息支持函数”在安全连接上交换消息时，使用安全上下文以确保消息的完整性和保密性。通过消息签名和签名验证来保证消息的完整性。通过加密和解密保证消息的保密性。

“包管理函数”为所支持的各种安全包提供服务。

用户身份验证和 DCOM 安全性

在客户端/服务器应用程序中，Windows CE 3.0 使用 Windows NT LAN Manager 安全性支持提供者 (NTLMSSP.dll) 进行用户身份验证。客户端应用程序向 NTLMSSP 提供用户名、域名和密码，服务器和客户端应用程序交换令牌以完成身份验证。

在 Windows CE 上运行的服务器应用程序也可以充分利用 Windows NT LAN Manager 安全包。例如，如果选择了 RPC_C_AUTHN_WINNT 标志，分布式组件对象模型 (DCOM) 将使用 Windows NT LAN Manager 协议来建立用户凭据。

虽然 Windows CE 与 Windows NT 的身份验证类似，但两者之间还是有显著的差别。在 Windows NT 中，每当客户端与服务器建立连接、客户端呼叫或者客户端与服务器交换数据时，都要进行身份验证；也可以禁用身份验证功能。Windows NT 支持模拟，也就是允许对象获取已通过身份验证的用户或客户端的安全凭据，而 Windows CE 不支持此功能。在 Windows CE 中，仅在连接层 (RPC_C_AUTH_LEVEL_CONNECT) 进行身份验证。在连接层，当客户端首次呼叫服务器时，DCOM 进行身份检查，但在随后的呼叫中不再进行身份验证。Windows CE 上的 DCOM 对象可以在任何身份验证级别发起呼叫，但是不会出现身份验证级别高于 CONNECT 的呼入请求。此外，可以禁用 Windows CE 的身份验证 (RPC_C_AUTHN_LEVEL_NONE)。

身份验证成功之后，要根据访问列表执行访问检查，访问列表标识可以在系统中启动类的主控者。在服务器初始化期间，根据 DefaultAccessPermissions 注册表设置创建该列表，或者编写程序用 DCOMAccessControl 对象来提供列表。

当 Windows CE 客户端通过网络连接到 Windows NT 域控制器（管理安全凭据）时，可以进行正常的身份验证。但在移动环境中，Windows NT 域控制器并非总是可用的，或者网络不是基于 Windows NT 的，在这样的情况下，您可以创建用户名和密码的本地数据库，以便 Windows NT LAN Manager 安全包使用这些信息验证凭据。Windows CE 提供下列 API 来创建和管理这些本地安全数据库：

• NTLMEnumUser 为数据库的给定索引返回已注册的用户名。
  
  
• NTLMSetUserInfo 在数据库中创建一个用户（如果不存在），并更改该条目中的信息。
  
  
• NTLMDeleterUser 从数据库中删除用户。

对安全网络通信使用 SSL

为了进行安全网络通信，Windows CE 还支持 SSL 版本 2.0 和 3.0 的安全性协议，可以通过 WinInet 或直接通过 WinSock 来使用这些协议。这些应用程序使用安全套接字来发送和接收通信线路上的编码数据。

安全套接字依靠身份验证来确定是否可以信任远程主机。远程主机通过从证书颁发机构 (CA) 获取证书，来建立自己的信任度。同样，CA 可能会从高一级的机构获取证书，依此类推，建立一条信任链。要确定证书是否可靠，应用程序必须确定根 CA 的身份，然后再确定其是否可靠。

Windows CE 3.0 SSL 维护信任 CA 的数据库，该数据库独立于 CryptoAPI 2.0 证书存储区。当应用程序试图建立安全连接时，Windows CE 3.0 从证书链中提取根证书，并根据 CA 数据库进行检查。它通过证书验证回调函数将服务器证书和根据 CA 数据库得到的比较结果传递给应用程序。

最终，应用程序负责验证是否可以接受证书。应用程序可以接受或拒绝任何证书。如果某证书被拒绝，则连接建立失败。证书至少要满足两个条件：证书是当前使用的；证书代表的身份与正在建立连接的目标实体的身份相匹配。通道 CA 数据库中包括根证书颁发机构的列表。注意，这些根证书颁发机构是有一定期限的，可能需要定期更新。也可以通过编辑注册表来更新数据库，以添加更多的 CA。

在 Windows CE 3.0 Schannel CA 数据库中包含下列根证书颁发机构：

• VeriSign/RSA Secure Server
  
  
• VeriSign Class 1 Public Primary CA
  
  
• VeriSign Class 2 Public Primary CA
  
  
• VeriSign Class 3 Public Primary CA
  
  
• GTE Cybertrust ROOT
  
  
• Thawte Personal Basic CA
  
  
• Thawte Personal Freemail CA
  
  
• Thawte Personal Premium CA
  
  
• Microsoft Root Authority
  
  
• Root SGC Authority
  
  
• Entrust.net Secure Server CA
  
  
• Entrust.net Premium Secure Server CA

使用 CryptoAPI 加密数据

通过 CryptoAPI 提供的服务，应用程序开发人员可以添加数据加密/解密方案、使用数字证书进行身份验证、为基于 Win32 的应用程序进行 ASN.1 的编码或解码操作。应用程序开发人员无需了解内部的实现细节，即可使用 CryptoAPI 中的函数。CryptoAPI 与许多执行实际加密功能（例如，加密、解密、密钥存储和安全性）的加密服务提供者 (CSP) 协同工作。

Microsoft 加密系统包含三个要素：操作系统、应用程序和 CSP。应用程序通过 CryptoAPI 层与操作系统通信，操作系统则通过加密服务提供者接口 (CSPI) 与 CSP 通信。下图说明了这一点。

图 2：应用程序通过 CryptoAPI 层与操作系统通信，操作系统通过加密服务提供者接口 (CSPI) 与 CSP 通信。

CSP 是实现所有加密操作的独立模块，通常是一个 DLL。理想情况下，CSP 是一个与应用程序无关的模块，因此任何应用程序运行的都是同一种 CSP。但是，实际上某些有特定要求的应用程序需要定制的 CSP。EOM 可以编写自己的 CSP 包并将其添加到注册表中。

下表介绍 Windows CE 3.0 中包含的两种预定义的 CSP。

应用程序可以使用 CryptoAPI 函数执行下列操作：

• 生成和交换密钥。
  
  
• 加密和解密数据。
  
  
• 编码和解码证书。