创建安全 Windows CE 设备(转)
Maricia Alforque
Microsoft Corporation
2000 年 10 月更新
適用于:
?????Microsoft Windows CE 版本 3.0
摘要:本文高度概括了 Windows CE 3.0 中為設備和應用程序提供安全性的不同選項。本文假定讀者熟悉基本的 Microsoft 安全技術和 Win32 應用程序編程接口 (API)。
簡介
安全服務是現代操作系統的核心部分。網絡基礎結構、系統管理策略和最終用戶的感受都取決于安全服務的管理功能、靈活性和實施。Microsoft? Windows? CE 3.0 通過提供安全服務的集成功能集,使企業在日益增長的網絡世界中不斷擴展,且無須犧牲安全性。安全服務包括以下功能:
- 信任環境模型。
- 安全性支持提供者接口 (SSPI)。
- Windows NT? LAN Manager 支持。
- 安全套接字層 (SSL) 支持。
- 加密技術。
- 支持 CryptoAPI 的智能卡基礎結構。
- 唯一的設備標識符。
- 受保護的內核配置。
- 撥號啟動加載程序中的數字身份驗證。
創建信任環境
Windows CE 設備發送、接收和處理需要保護(以避免潛在的不安全應用程序)的信息。那么,如何保護您的設備呢?您可以創建一個安全操作系統 (OS),防止加載未知模塊、限制對系統 API 的訪問、并禁止對系統注冊表的某些部分執行寫入操作。
要創建信任環境,必須實現下面兩個函數:
- OEMCertifyModuleInit
- OEMCertifyModule
在內核加載應用程序之前,OEMCertifyModule 函數驗證應用程序簽名,以避免非法應用程序進入您的系統。這可以確保僅當應用程序包含有效的數字簽名時,才能夠被基于 Windows CE 的平臺加載。OEMCertifyModule 函數返回以下三個選項之一:
下表對這兩個函數加以說明。
| 函數 | 說明 | 返回值 |
| OEMCertifyModuleInit | 啟用 OS 加載程序來通知 OEM 有一個新的模塊正在加載。允許 OEM 決定是否驗證該模塊以確保安全。 | TRUE 或 FALSE |
| OEMCertifyModule | 允許 OS 加載程序將模塊代碼(例如,DLL、EXE 和 OCX)傳遞給 OEM,以驗證該模塊是否可以在系統中安全地運行。 | OEM_CERTIFY_TRUST OEM_CERTIFY_RUN OEM_CERTIFY_FALSE |
下表說明 OEMCertifyModule 函數的返回值。
| 返回值 | 說明 |
| OEM_CERTIFY_TRUST | 信任應用程序,可以執行任何操作。 |
| OEM_CERTIFY_RUN | 信任應用程序,可以運行,但不能調用任何特權函數。 |
| OEM_CERTIFY_FALSE | 不信任,因此不允許運行。 |
OEMCertifyModule 函數可以對正在加載的模塊進行任何類型的檢查,例如,循環冗余檢查或證書檢查。當動態鏈接庫 (DLL) 加載到某 EXE 程序的地址空間時,EXE 的信任級別將決定最終的訪問級別。例如,如果 OEM_CERTIFY_RUN 信任級別的 EXE 試圖加載具有較低信任級別 (OEM_CERTIFY_TRUST) 的 DLL 時,DLL 的最終信任級別是 OEM_CERTIFY_RUN。另一方面,如果 EXE 試圖加載具有較高信任級別的 DLL 時,加載操作將失敗。
下表顯示 EXE 和 DLL 信任級別的不同組合方式。
| EXE 信任 | DLL 信任 | 最終 DLL 信任 |
| OEM_CERTIFY_RUN | OEM_CERTIFY_RUN | OEM_CERTIFY_RUN |
| OEM_CERTIFY_RUN | OEM_CERTIFY_TRUST | OEM_CERTIFY_RUN |
| OEM_CERTIFY_TRUST | OEM_CERTIFY_RUN | 加載 DLL 失敗 |
| OEM_CERTIFY_TRUST | OEM_CERTIFY_TRUST | OEM_CERTIFY_TRUST |
注意:???OEM 必須對所有第三方驅動程序進行數字簽名,否則加載驅動程序時將失敗。實現此安全模型時,所有驅動程序都必須受信任。
要實現信任模型,最簡單的方法是使用 OEMCertifyModule 函數,為所有應用程序返回 OEM_CERTIFY_RUN。從而使映像的非 ROM MODULES 部分的應用程序可以運行,但是對特權函數的調用會受到限制。通過這種方法,您不必指定運行時哪個應用程序是否受信任。如果返回的是 OEM_CERTIFY_FALSE,那么 RAM 中的應用程序將不能運行。在任何情況下,位于映像的 ROM MODULES 部分中的操作系統文件總是以最高權限運行。
要創建數字簽名,您可以使用 Signfile.exe,該程序包含在 Platform Builder 3.0 中。Signfile.exe 是用私人密鑰為可執行文件簽名的工具,使用 Secure Hash Algorithm (SHA) 計算加密散列。關于 Signfile.exe 代碼的示例,請參見 Platform Builder 3.0 產品 CD 中的 Public\Common\Oak\Tool\Signfile。
要在加載時驗證簽名,您可以使用 Loadauth.lib 函數,該函數在 \Public\Common\Oak\Lib 中與處理器對應的 Platform Builder 目錄中。關于使用 Loadauth.lib 函數的詳細信息,請參見 Platform Builder 3.0 文檔。
您也可以不使用 Platform Builder 工具,而編寫自己的簽名驗證方案。
下面的代碼是使用 Loadauth.lib 函數實現 OEMCertifyModuleInit 和 OEMCertifyModule 函數的示例:
/* 簽名公共密鑰 BLOB */ const unsigned char g_bSignPublicKeyBlob[] = { 0x06,0x02,0x00,0x00,0x00,0x24,0x00,0x00,0x52,0x53,0x41,0x31,0x00,0x02, 0x00,0x00,0x01,0x00,0x01,0x00,0xb1,0x00,0x93,0x7c,0x18,0x63,0xce,0xf3, 0x23,0xe3,0x57,0x74,0x13,0x54,0x17,0x2c,0xdb,0xf6,0x56,0x77,0xb3,0x8d, 0x34,0x6c,0x41,0x3d,0x4e,0xbb,0xc1,0xaf,0x3d,0x17,0xb6,0x0e,0x70,0x72, 0x43,0x12,0x1d,0xb1,0x2a,0x57,0x05,0x27,0x58,0x63,0xef,0xb7,0x3b,0x71, 0xee,0xe4,0xcd,0x14,0xbe,0xf7,0x32,0xec,0xa2,0xae,0xbf,0x9a,0x6b,0x75 }; // RAM 可執行程序加載時簽名檢查 // 的聲明 typedef BOOL (* OEMLoadInit_t)(LPWSTR lpszName); typedef DWORD (* OEMLoadModule_t)(LPBYTE lpData, DWORD cbData); extern OEMLoadInit_t pOEMLoadInit; extern OEMLoadModule_t pOEMLoadModule; extern BOOL InitPubKey(const BYTE *KeyBlob, DWORD cbKeyBlob); // Loadauth 庫例程 extern BOOL CertifyModuleInit(void); extern BOOL CertifyModule(PBYTE pbBlock, DWORD cbBlock); extern BOOL CertifyModuleFinal(PBYTE *ppbSignData, PDWORD pcbSignData); // 為每個 RAM 可執行模塊調用一次 // 以初始化簽名檢查 static BOOL OEMCertifyInit(LPWSTR lpszName) { return CertifyModuleInit(); } // 在 OemLoadInit 之后調用一次或多次 static DWORD OEMCertifyModule(LPBYTE lpData, DWORD cbData) { if (cbData) { // 處理模塊字節 return CertifyModule(lpData, cbData); } else { // 最終調用 DWORD dwTrustLevel = OEM_CERTIFY_FALSE; LPBYTE pSignedData; DWORD cbSignedData; BOOL fRet = CertifyModuleFinal(&pSignedData, &cbSignedData); if (fRet) { // 該文件有有效簽名 // 我們希望以簽名數 // 據返回信任級別 if (cbSignedData < sizeof(CHAR)) dwTrustLevel = OEM_CERTIFY_RUN; else switch (*pSignedData) { case 'T' : dwTrustLevel = OEM_CERTIFY_TRUST; break; case 'R' : dwTrustLevel = OEM_CERTIFY_RUN; break; default: dwTrustLevel = OEM_CERTIFY_FALSE; break; } } #ifdef DEBUG if (!fRet) lpWriteDebugStringFunc(TEXT("OEMCertifyModule:signature check failed.\r\n")); #endif // 返回一個 OEM_CERTIFY 級別 return dwTrustLevel; } } void OEMInit() { ... ... // // 設置模型簽名驗證掛鉤。 // pOEMLoadInit = OEMCertifyInit; pOEMLoadModule = OEMCertifyModule; // // 初始化簽名驗證公共密鑰。 // InitPubKey(g_bSignPublicKeyBlob,sizeof(g_bSignPublicKeyBlob)); // // 其他 OEM 初始化步驟 // ... }注意:???OEMCertifyModuleInit 和 OEMCertifyModule 函數的名稱是任意的;您可以使用任何名稱。但重要的是,應初始化 OEMInit 函數中的兩個內核指針:pOEMLoadInit 和 pOEMLoadModule,讓它們分別指向這兩個命名函數。
受限制的 API
除了 OEM 函數,還可以使用 CeGetCurrentTrust 和 CeGetCallerTrust API 來查詢調用應用程序的信任級別。您可以使用這些函數驗證應用程序的信任級別。
不信任模塊不能調用以下 API:
- SetInterruptEvent
- SetSystemMemoryDivision
- CESetThreadPriority
- CeSetThreadQuantum
- ForcePageout
- VirtualCopy
- LockPages
- UnlockPages
- SetProcPermissions
- SetKMode
- ReadProcessMemory
- WriteProcessMemory
- SetCleanRebootFlag
- PowerOffSystem
- DebugActiveProcess
CreateProcess API 中的調試標志:DEBUG_ONLY_THIS_PROCESS 和 DEBUG_PROCESS 也是受限制的。
Windows CE 3.0 中的安全注冊表體系結構只允許已經識別的“信任應用程序”(OEM_CERTIFY_TRUST) 修改受保護注冊表中的鍵和值。
在 Windows CE 3.0 中,以下注冊表主鍵及其子鍵是受保護的,以避免不信任應用程序的非法操作:
- HKEY_LOCAL_MACHINE\Comm
- HKEY_LOCAL_MACHINE\Drivers
- HKEY_LOCAL_MACHINE\HARDWARE
- HKEY_LOCAL_MACHINE\SYSTEM
- HKEY_LOCAL_MACHINE\Init
- HKEY_LOCAL_MACHINE\WDMDrivers
此外,如果不信任應用程序試圖使用以下注冊表函數,將得到 ERROR_ACCESS_DENIED 返回值:
- RegSetValueEx
- RegCreateKeyEx
- RegDeleteKey
- RegDeleteValue
因為注冊表的其余部分是不受保護的,所以 OEM 必須將所有重要的注冊表信息存放在某個受保護的鍵中。
注意:???所有應用程序對所有注冊表鍵和值都具有只讀訪問權限。
使用 SSPI 管理安全性提供者
在 Secur32.dll 模塊中提供的安全性支持提供者接口 (SSPI) 是一個嚴格定義的通用 API,用于獲取進行身份驗證、消息的完整性檢查和消息加密的集成安全服務。它在應用程序層協議和安全性協議之間提供了一個抽象層。因為不同的應用程序在網絡上傳輸數據時所采用的識別或驗證用戶身份的方法,以及加密數據的方法各不相同,因此 Windows CE SSPI 提供了訪問包含各種身份驗證和加密數據方案的 DLL 的途徑。這些 DLL 被稱作安全性支持提供者 (SSP)。
下圖說明了 SSP DLL 和 SSPI Secur32.dll、Winsock、WinInet 之間的關系。
圖 1:SSP DLL 和 SSPI Secur32.dll、Winsock、WinInet 之間的關系
SSPI 生成應用程序可用的一個或多個 SSP(也叫做安全包)。安全包將不同的 SSPI 函數映射到該安全包專用的某個安全性協議的實現上。OEM 也可以編寫他們自己的安全包,然后將其添加到注冊表中。
以下是 Windows CE 3.0 中可用的 SSP:
- Schannel Cryptographic Provider
- Windows NT LAN Manager SSP
SSPI 函數
SSPI 允許應用程序開發人員使用多個 SSP 中的一個,而不必了解安全性協議的細節。
下表列出了 Windows CE 3.0 支持的 SSPI 函數。
“憑據管理函數”提供對主控者的憑據的訪問。主控者是一個操作系統能識別的實體,可以是用戶或進程。主控者使用憑據建立用戶或應用程序的標識。
| 函數 | 說明 |
| AcquireCredentialsHandle | 使應用程序能夠獲取憑據的句柄。 |
| FreeCredentialsHandle | 釋放憑據句柄和所有相關資源。 |
| QueryCredentialsAttributes | 檢索憑據屬性。 |
“上下文管理函數”允許應用程序創建和使用安全上下文。安全上下文是與連接相關的安全數據,并且包含諸如會話密鑰和會話持續時間等數據。客戶端和服務器必須合作,來共同創建安全上下文。
| 函數 | 說明 |
| InitializeSecurityContext | 通過生成可以傳遞給服務器或遠程對等終端的令牌來初始化安全上下文。 |
| AcceptSecurityContext | 使用重定向器驗證憑據來建立安全上下文。 |
| DeleteSecurityContext | 釋放安全上下文,并刪除與之相關聯的本地數據結構。 |
| QueryContextAttributes | 檢索安全上下文的屬性。 |
| ApplyControlToken | 在現有的安全上下文中應用附加的安全性消息。 |
| FreeContextBuffer | 釋放由安全性提供者分配的內存緩沖區。 |
“消息支持函數”在安全連接上交換消息時,使用安全上下文以確保消息的完整性和保密性。通過消息簽名和簽名驗證來保證消息的完整性。通過加密和解密保證消息的保密性。
| 函數 | 說明 |
| MakeSignature | 生成消息的加密校驗和,并且包含有序的數據,以防止消息丟失或誤插。此函數還允許應用程序選擇不同的加密算法。 |
| VerifySignature | 驗證消息簽名。 |
“包管理函數”為所支持的各種安全包提供服務。
| 函數 | 說明 |
| EnumerateSecurityPackages | 列舉可用的安全包及其功能。 |
| QuerySecurityPackageInfo | 檢索指定的包的信息。 |
用戶身份驗證和 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。
| CSP | 說明 |
| RSA 基本提供者 | 支持數字簽名和數據加密,是多用途的加密工具。 |
| RSA 增強提供者 | 支持 128 位的密鑰加密。通過擴展密鑰長度和附加算法提供更強大的安全性。 |
應用程序可以使用 CryptoAPI 函數執行下列操作:
- 生成和交換密鑰。
- 加密和解密數據。
- 編碼和解碼證書。
- 管理和保證證書的安全性。
- 創建和驗證數字簽名,并計算散列。
CryptoAPI 1.0 在 Windows CE 3.0 中提供的功能與在 Windows 2000 和 Windows NT 中提供的功能很相似;但是,僅支持 CryptoAPI 2.0 的子集。Windows CE 3.0 支持 CryptoAPI 2.0 的下列功能:基于 X.509 標準對數字證書進行編碼和解碼,以及管理證書。不支持下列功能:管理驗證字撤銷列表 (CRL) 和驗證字信任列表 (CTL) 的工具、低級消息傳遞函數和簡化的消息傳遞函數。
Coredll.lib 導出 CryptoAPI 1.0 函數;Crypto32.lib 導出 CryptoAPI 2.0 函數;所有這些函數都在 Wincrypt.h 頭文件中定義。
在智能卡中隔離敏感數據
通過使用智能卡存儲身份驗證信息或數字簽名機制,您可以向 Windows CE 設備添加安全層。可以編寫定制的 CryptoAPI 提供者,使用智能卡的功能實現安全信息存儲。
Windows CE 智能卡子系統通過智能卡服務提供者 (SCSP) 支持 CrytoAPI,SSCP 是允許訪問特定服務的 DLL。該子系統在智能卡讀卡器硬件和應用程序之間提供鏈接。通常,Windows CE 不提供 SCSP,而由智能卡供應商提供相應的 SCSP。但是,Windows CE 提供下表中描述的接口。
| 子系統組件 | 文件 | 說明 |
| 資源管理器 | Scard.dll | 使用 Win32 API 管理對多個讀卡器和智能卡的訪問。 |
| 資源管理器幫助器庫 | Winscard.dll | 為使用智能卡和智能卡讀卡器提供 PC/SC 服務。 |
| 智能卡讀卡器幫助器庫 | Smclib.lib | 提供通用智能卡驅動支持例程,以及所需特定驅動程序的附加 T=0 和 T=1 協議支持。 |
| 智能卡讀卡器驅動程序示例 | Pscr.dll bulltlp3.dll stcusb.dll | SwapSmart PC 讀卡器驅動程序。 串行讀卡器驅動程序。 通用串行總線 (USB) 讀卡器驅動程序。 |
典型的智能卡系統包括應用程序、處理智能卡讀卡器和應用程序之間的通信的子系統、讀卡器以及智能卡。下圖顯示了基于 Windows CE 的智能卡系統的體系結構。
圖 3:基于 Windows CE 的智能卡系統的體系結構
在一個獨立的硬件中實現智能卡 CryptoAPI 服務提供者的部分功能將保證密鑰和操作的安全性,因為:
- 提供防止篡改的存儲區,以便保護個人信息的私人密鑰和其他表單。
- 隔離注重安全性的計算,這些計算涉及系統其他部分的身份驗證、數字簽名和密鑰交換。
- 使憑據和其他私人信息具備便攜性。
在使用智能卡的組織中,用戶實際不必記住任何密碼(只有一個個人識別號或 PIN),并且出于其他安全性目的(例如電子簽名的電子郵件),他們可以使用相同的證書。
唯一標識設備
OEM 可以為 Windows CE 設備提供唯一的識別標記,并使應用程序可以訪問它。例如,您可能需要標記運行您的 OS 映像的每個蜂窩電話,以便達到記帳和安全性的目的。
Windows CE 使用 DEVICE_ID 結構來保存唯一的設備識別號。OEM 適配層中的輸入/輸出控制 IOCTL_HAL_GET_DEVICEID 返回指定給該 Windows CE 設備的當前 DEVICE_ID。有關詳細信息,請參閱 Platform Builder 文檔的“操作系統開發”一節中的“為應用程序提供平臺信息”。
使用受保護的內核模式
在運行線程時使用全內核模式將使整個系統易受攻擊,因為 Windows CE 繞過了安全性特性。在全內核模式中,應用程序可以訪問系統中的任何物理內存。這將使系統對惡意應用程序保持開放,不能防止它們獲取特權信息和加密代碼,或者刪除文件。
盡管在全內核模式下運行時性能將得到提高,但這在一個開放的未受保護的環境中是不可接受的。您可以禁用全內核模式;在 Config.bib 文件中設置 ROMFLAGS 的第二個字節。根據其他標志的設置,ROMFLAGS 的值可能會有所不同。
在撥號啟動加載程序中使用數字身份驗證
撥號啟動加載程序是一個存儲在 ROM 中的程序,該 ROM 用于通過快閃內存或遠程服務器升級 OS 映像文件 (Nk.bin)。要確保下載的 OS 映像的完整性,您可以使用數字密鑰來簽名和驗證 OS 映像文件。撥號啟動加載程序通過 Microsoft CryptoAPI 使用非對稱散列算法 (CALG_SHA) 來驗證數據。非對稱散列算法將生成 160 位散列值。
Platform Builder 3.0 為數字身份驗證提供下列工具:
- Makekey.exe,用于創建公共密鑰/私人密鑰對。
- Mksigs.exe,用于簽名 OS 映像文件。
- Addsigs.exe,用于向清單文件中附加簽名。
在 OS 映像下載進程中,撥號啟動加載程序從清單文件中提取簽名,并驗證每個 OS 映像文件的可靠性。如果驗證失敗,將暫停下載進程并通知用戶。
更多信息
有關 SSPI、安全套接字層、CryptoAPI 和智能卡的實現細節,請參閱 Windows CE 軟件開發人員手冊(英文)。
有關內核級別安全性(信任模型和內核模式)、設備標簽和撥號啟動加載程序的實現細節,請參閱 Windows CE Platform Builder 3.0(英文)。
還請參閱 MSDN Online Windows 嵌入式開發人員中心,網址為 http://msdn.microsoft.com/embedded(英文)。
有關智能卡的詳細信息,請參閱 PC/SC 工作組主頁,網址為 http://www.pcscworkrgroup.com(英文)。
本文中的信息介紹目前為 Windows CE 3.0 設備和應用程序提供安全性的技術。如果您認為本文的格式和信息有用,或者您有任何其他注釋有助于我們為您提供更多的內容,請將您的反饋發送到 ceuafdbk@microsoft.com。
轉載于:https://www.cnblogs.com/abob/archive/2008/02/17/1071406.html
總結
以上是生活随笔為你收集整理的创建安全 Windows CE 设备(转)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ASP:FileSystemObject
- 下一篇: VC操作XML编程实例