|
|
||||||
|
Home |
News |
Articles |
Forum
| |||||||
|
|
Security features in Windows CE
2004-02-26 Article Rating:  / 0
Foreword: Security is becoming increasingly important in the world of smart, connected devices. This detailed technical whitepaper discusses the various security mechanisms and features that device manufacturers and developers can use to build Microsoft Windows CE based applications and devices with enhanced security.
Topics covered include Windows CE operating system security, cryptography, authentication, smart cards and public key technologies. This paper also discusses common security vulnerabilities and provide tips and best practices to help avoid these pitfalls. Marcus Ash and Mukkul Dasgupta Microsoft Corporation Originally published January, 2003 Create a Trusted Environment Microsoft Windows CE devices send, receive and process information that requires protection from potentially unsafe applications. To help protect your device, you can implement security measures that can help prevent the OS from loading unknown modules, restrict access to system application programming interfaces (APIs), and prevent write access to parts of the system registry. You can designate a module as trusted or not trusted when certifying applications. The kernel can use this information to prevent unauthorized applications from loading or limit their access to the system. To help create a trusted environment, you must implement the following functions:
The following table describes the return values for OEMCertifyModule function.
An OEMCertifyModule function can perform any type of check on the module that is loading. For example, the function may perform a cyclic redundancy check or a certificate check. When a dynamic-link library (DLL) loads into the address space of an .exe file, the trust level of the .exe file determines the final access level. For example, when an .exe file with the OEM_CERTIFY_RUN trust level tries to load a DLL that has a higher trust level (OEM_CERTIFY_TRUST), the final trust level of the DLL is OEM_CERTIFY_RUN. On the other hand, when the .exe file tries to load a DLL that has a lower trust level, the DLL will fail to load. The following table shows the different combinations of .exe file and DLL trust levels.
Note: When you implement the trusted security model, untrusted drivers will fail to load. The OEM must verify all third-party drivers as trusted. The simplest implementation of the trusted model uses the OEMCertifyModule function to return OEM_CERTIFY_RUN for all applications. This allows applications that are not part of the ROM MODULES section of the image to run, but they are restricted from making privileged function calls. By using the OEMCertifyModule implementation at run time, you do not have to specify which applications are trusted. If OEM_CERTIFY_FALSE is returned, applications in RAM will not be able to run. Regardless of which implementation of the trusted model you choose, OEMCertifyModuleInit or OEMCertifyModule, the operating system files in the ROM MODULES section of the image will always run with full privileges. See also:
To create a digital signature from a file, run the file through a hash function and then sign the resulting hash with a private key. An easy way to create a digital signature from a file is to use Signfile.exe, which is included in Microsoft Platform Builder. Signfile.exe is a tool for signing an executable file with a private key supplied by a cryptographic service provider (CSP). Signfile.exe uses the Secure Hashing Algorithm (SHA) to compute the cryptographic hash. SHA generates a 20-byte hash from an arbitrarily sized byte string. Signfile.exe pads the hash as specified by Public-Key Cryptography Standards #1 (PKCS1) and encrypts it by using the RSA public key algorithm. The key modulus length can be from 512 through 1,024 bits. The resulting signature is the same size as the modulus. For example, the signature for a 1,024 bit key is 128 bytes. Signfile.exe then uses the ImageAddCertificate and ImageGetDigestStream Microsoft Windows NT functions to embed the signature in a portable executable (PE) file. The following list shows the contents of the PE file memory:
Each entry in the data directory table consists of an IMAGE_DATA_DIRECTORY structure. The fifth structure in the data directory table contains certificate table information. This is stored in an array of WIN_CERTIFICATE structures. A certificate is a digitally signed statement that contains information about an entity and that entity's public key. Certificates are not loaded into memory as part of the PE file. The following code example shows the format of a WIN_CERTIFICATE structure that is needed to support the PKCS1 standard. Signfile.exe appends the WIN_CERTIFICATE structure to the end of the file and updates the file header accordingly. For sample Signfile.exe code, see %_WINCEROOT%\Public\Common\Oak\Tools\Signfile. Verifying a signature An OEM can verify that a file contains the proper signature by using the OEMCertifyModule function before the kernel loads the file. Using this method, the kernel uses the same hash formula to calculate a signature during the verification process that it used during the signature generation process. OEMCertifyModule compares the signature it calculated from the hash to the signature in the file. If the signatures do not match, OEMCertifyModule prevents the file from loading. Because the size of a PE file header can vary, OEMCertifyModule may not be able to process the entire header in a single call. Because the signature is at the end of the file, it is not possible to specify a hash function in the signature; you must use Secure Hash Algorithm (SHA) or another fixed hash function. When computing the hash, SHA excludes the following data from the file:
The following table shows the functions contained in Loadauth.lib library.
To use the sample verification library (Loadauth.lib)
Note: You can use any name for the functions OEMCertifyModuleInit and OEMCertifyModule. However, it is important to initialize the two kernel pointers, pOEMLoadInit and pOEMLoadModule, in the OEMInit function to these named functions.Signfile.exe Signfile.exe signs an executable with a supplied private key. You can use the following command-line parameters with this tool:
-f PEFile Specifies the file to be signed. -a Appends signature to PE File. -k KeyName Uses a private key from the named CryptoAPI key container. -p Cfile Outputs the public key to a file as a C structure. -s AttribString Specifies an optional attribute string to be included in signature. For example, you can add a string to indicate the trust level of the application. -p SignFile Outputs the signature to a file. For more information about this tool, see Creating Digital Signatures. Trusted APIs In addition to the OEM functions, the CeGetCurrentTrust and CeGetCallerTrust APIs enable a DLL to query the trust level of a calling application. You can use these functions to verify the trust levels of the applications. The following list shows the application programming interfaces (APIs) that can be called only by trusted applications:
CeSetThreadPriority CeSetThreadQuantum CheckPassword ContinueDebugEvent CryptUnprotectData DebugActiveProcess ForcePageout FreeIntChainHandler FreePhysMem InterruptDisable InterruptDone InterruptInitialize KernelLibIoControl LoadDriver LoadIntChainHandler LoadKernelLibrary LockPages PowerOffSystem ReadProcessMemory ReadRegistryFromOEM RegCopyFile RegReplaceKey RegRestoreFile RegSaveKey SetCleanRebootFlag SetCurrentUser SetInterruptEvent SetKMode SetPassword SetPasswordStatus SetProcPermissions SetSystemMemoryDivision SetUserData UnlockPages VirtualCopy VirtualSetPageFlags WaitForDebugEvent WriteProcessMemory WriteRegistryToOEM
CreateFile CreateFileForMapping DeleteAndRenameFile DeleteFile MoveFile RemoveDirectory SetFileAttributes The following list shows database APIs that are influenced by the SYSTEM attribute that can be set on a database. For more information, see Database Security. In addition, the debug flags DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS of the CreateProcess API are restricted. If these flags are used by a non-trusted application, the identified process will still launch but no debugging will occur. Debug flags, DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS, in the CreateProcess API are also restricted. The registry architecture in Windows CE is designed to allow only trusted applications that you have identified to modify keys and values in protected portions of the registry. Because most of the registry is unprotected, OEMs must place all important registry information in one of the protected keys. Note: All applications have read-only access to all registry keys and values. In Windows CE, the following registry root keys and their subkeys are protected from untrusted applications:
The object store provides several elements of security in a trusted environment. System files are protected so that they cannot be read or modified by untrusted applications. System files are files that have the system attribute set. For more information, see File System Security. The system also protects a set of registry keys so that they cannot be modified by untrusted applications. All applications can read all registry keys and values, but only trusted applications can modify values or subkeys below protected keys. The system protects a base set of keys. This set of keys is extensible by the OEM. For more information, see Protected Registry Keys and Values and Request Additional Secure Registry Keys. Additionally, databases that are stored within the object store can be given a system flag. System databases cannot be read or modified by untrusted applications. Databases that are stored in separate database volumes rather than in the object store can be protected by setting the system attribute on the file, just as for any other file in the file system. Database security Windows CE allows trusted applications to mark a system flag on databases to deny access to untrusted callers. Untrusted applications cannot open, read, or modify databases that are marked with the system flag. Trusted callers can set the CEDB_SYSTEMDB flag inside the CEDBASEINFOEX structure passed to CeCreateDatabaseEx2 or CeSetDatabaseInfoEx2 to help protect a database. This feature helps protect a single database, not an entire database volume. Setting FILE_ATTRIBUTE_SYSTEM on the volume file helps protect database volumes. System databases cannot be created inside database volumes that do not have FILE_ATTRIBUTE_SYSTEM set to block untrusted applications from accessing and/or deleting a file containing a system database using the Microsoft Win32 file APIs. Because an untrusted application cannot access any file with the system file attribute set, adding the system flag to a database inside a database volume does not give it any additional security. Therefore, this feature is most useful in databases that are stored within the object store. Removing the system file attribute from a database volume that contains a system database will expose that database to access by untrusted applications and is not recommended. Secure Your Communications Network Security for communications requires special attention because the network interface provides an access point to a device that can be used remotely by an attacker. It is easier for an attacker to remain anonymous or undetected through a network-based attack. This makes determining the source of the attack more difficult. In general, client applications on a network are relatively more secure than servers or service applications. Clients initiate contacts with specific servers and specify the nature of their requests. This allows the client applications to determine the nature of incoming data and the identity of the server or service; they can reject unsolicited communications. Although Clients are not immune to security problems, they have more control over the nature of communications because they initiate communications, which reduces the surface of vulnerability. Examples of client applications are browsers, email clients and FTP clients. Servers are more exposed because they wait to receive requests from clients on the network. Requests can come from anywhere in the network. When the server is exposed to the public interface, the surface vulnerability increases considerably. Examples of server applications include Web servers, FTP servers and Telnet servers. The following list describes the mitigations techniques you can use:
Unlike wired networks, wireless networks can reach beyond the walls of buildings. In many deployments, wired network security depends on the physical security of the networks behind locked doors of the buildings. You need to pass through the building security to get access to the network. On the other hand, wireless networks can be monitored and attacked from outside the walls of buildings. To mitigate security risks, many wireless networks provide ways to encrypt transmissions. You can use simple static encryption (WEP) network keys or more advanced techniques that generate and rotate the WEP keys to help provide privacy. For the most advanced protection, specifically for 802.11, you should use 802.1X industry standard as defined by the Institute of Electrical and Electronics Engineers, Inc. (IEEE). It provides for individual authentication and enhanced privacy by being able to generate and plug in WEP keys. Furthermore, these WEP keys can be generated per user and rotated often based on the policy. For detailed information, see the IEEE Web site. Note: 802.1X is intended only for enterprise deployments. Windows CE does not support mutual authentication in wireless networks. Windows CE uses a number of authentication methods that can be plugged in to 802.1x to customize the authentication methods. You can use simple user name and passwords, certificates, smart cards, or biometrics. The EAP-MD5 supports user name and passwords and the EAP-TLS supports certificate-based authentication. You can also develop your own authentication scheme. For more information, see 802.1x Authentication and the IEEE Web site. You should be aware of another potential security risk that is not software related. Basic interference can cause a network to slow down or stop altogether, if the RF spectrum of the network is jammed with RF noise. Although this intrusion does not compromise privacy, it poses a denial of service risk. You should work with your wireless vendor to determine the best approach to mitigate this risk. Use Authentication You can control access to the device and services only to authorized users by implementing authentication protocols available in Windows CE. Some are built into the feature and others require you to add features to your operating system. For example, if your want to use NTLM SSP and/or Kerberos SSP, you need to add these features to your operating system. NTLM and Kerberos are implemented through the Security Support Provider Interface (SSPI). SSPI is available through the Secur32.dll module, which is a well-defined, commonly used API for obtaining integrated security services for authentication, message integrity and enhanced message privacy. It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries (DLLs) containing different authentication and cryptographic data schemes. These DLLs are called Security Support Providers (SSPs). The following illustration shows the relationship of the SSP DLLs to the SSPI Secur32.dll, Winsock and WinInet.  Figure 1. Windows CE SSP DLLs The available SSPs in Windows CE are:
The following list summarizes the authentication best practices:
You can use the Credential Manager to allow users the option to save authentication information on a device. When a Web site or another computer requests authentication through NTLM or Kerberos, an Update Default Credentials or Save Password check box appears in the Net UI dialog box. If the user selects the check box, the Credential Manager keeps track of the user's name, password and related information for the authentication service in use. The next time that service is used, the Credential Manager automatically supplies the stored credential. If it is not accepted, the user is prompted for the correct access information. If access is granted, the Credential Manager overwrites the previous credential with the new one. See also: Use SSL to Enhance Secure Network Communication To enhance secure network communication, Windows CE also supports Secure Sockets Layer (SSL) 2.0, SSL 3.0 and SSL 3.1 security protocols, which are available through WinInet or directly from WinSock. SSL version 3.1 is also known as Transport Layer Security (TLS). These applications use secure sockets to send and receive encoded data over the communication lines. Secure socket implementation relies on authentication to determine if a remote host can be trusted. Remote hosts establish their trustworthiness by obtaining a certificate from a certification authority (CA). The CA can, in turn, have certification from a higher authority and so on, creating a chain of trust. To determine whether a certificate is trustworthy, an application must determine the identity of the root CA and then determine if it is trustworthy. Windows CE based SSL uses trusted CAs. When a secure connection is attempted by an application, SSL extracts the root certificate from the certification chain and checks it against the CA database. It delivers the server certificate to the application through a certificate validation callback function, along with the results of the comparison against the CA database. You can modify the default SSL behavior by modifying the registry keys. The base registry key is HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL. Applications bear the ultimate responsibility for verifying that a certificate is acceptable. Applications can accept or reject any certificate. If a certificate is rejected, the connection is not completed. At a minimum, a certificate should meet the following requirements:
The following root certificate authorities are included in the Windows CE root certificate store:
CryptoAPI provides services that enable application developers to add data encryption/decryption schemes, to authenticate using digital certificates, and to encode/decode to and from ASN.1 to their Microsoft Win32-based applications. Application developers can use the functions in CryptoAPI without detailed knowledge of the underlying implementation. CryptoAPI works with a number of cryptographic service providers (CSPs) that perform the actual cryptographic functions, such as encryption, decryption and key storage and security. The three elements of the Microsoft cryptographic system are the operating system, the application and the CSP. Applications communicate with the operating system through the CryptoAPI layer and the operating system communicates with the CSPs through the cryptographic service provider interface (CSPI). The following illustration shows the concept.  Figure 2. CryptoAPI data encryption CSPs are independent modules, usually DLLs that contain algorithms and perform all cryptographic operations. Ideally, CSPs are written to be independent of a particular application, so that any application will run with a variety of CSPs. In reality, however, some applications have specific requirements that require a customized CSP. OEMs can write their own CSP package and add it to the registry. The following table shows the predefined CSPs included in Windows CE.
Applications can use CryptoAPI functions to:
Coredll.lib exports CryptoAPI 1.0 functions and Crypto32.lib exports the CryptoAPI 2.0 functions; all these functions are defined in the Wincrypt.h header file. The following table shows the algorithms the CSPs contain and their descriptions.
* Algorithms supported by the Microsoft Base Cryptographic Best practices If possible, do not save sensitive data in RAM, the file system, or the registry. The following list shows best practices to use if you must save sensitive data:
To help protect sensitive information and to prevent data tampering, the protected store API provides a convenient solution to cryptography, key management and user experience issues. The two CryptoAPI functions, CryptProtectData and CryptUnprotectData, take the user's logon credentials to lock and unlock the private data. Typically, only a user with logon credentials matching those of the encrypter can decrypt the data. In addition, decryption must be done on the computer where the data was encrypted. The benefits of the protected store include the following:
Use CryptGenRandom to generate random data. This function has two of the properties of a good random number generator: unpredictability and even value distribution. On a Windows CE device, entropy is generated for CryptGenRandom by the following sources:
If Cryptography Services features are not included in your platform, you can also use CeGenRandom to generate random numbers. Isolate Sensitive Data in a Smart Card You can add an additional layer of security to a Windows CE device by using smart cards to store authentication information or a digital signing mechanism. You can write a custom CryptoAPI provider that exploits a smart card's ability to store information with enhanced security. The Windows CE smart card subsystem supports CryptoAPI through smart card service providers (SCSPs), which are DLLs that enable access to specific services. The subsystem provides a link between the smart card reader hardware and the applications. Windows CE does not provide SCSPs; typically, the smart card vendor provides the appropriate SCSPs. However, Windows CE provides the interfaces described in the following table.
A typical smart card system consists of applications, a subsystem that handles communication between smart card readers and the applications, readers and the smart card. Implementing a fraction of the smart card CryptoAPI service provider functionality in a separate hardware keeps the cryptographic keys and operations safer because it:
See also: Practice Secure Coding Techniques The book Writing Secure Code by Michael Howard and David LeBlanc, Microsoft Press, 2002, is an excellent source of secure programming best practices. The book discusses the vulnerabilities of applications to malicious attacks and shows examples of code defects. One important issue discussed in the book and often overlooked by application developers is buffer overruns. You should avoid using the following C/C++ functions. These functions can cause buffer overruns and cause your application to fail or enable code to be injected into your process space:
As the OEM or application developer, you can use samples, such as VMini for sharing your ethernet network and debugging connections, to quickly build and test your application or operating system. To help protect against these types security vulnerabilities, before you ship your product, you must replace the samples with your own application code. Additional Resources: Copyright © 2003-2004 Microsoft Corp. All rights reserved. This article was initially published on Microsoft's MSDN website. Reproduced by WindowsForDevices.com with permission.
|
news feed
