| Security Catalogs and Windows XP Embedded |
by Alex Gimenez (July 16, 2007)
Foreword: Security Catalogs are an important feature of the Windows security system because they help reduce disk footprint used by the code signing process. Security catalogs are installed differently on Windows XP Embedded systems than on desktop systems. This article explains those differences, and how they impact XP Embedded images.
Security Catalogs and Windows XP Embedded
by Alex Gimenez
Terminology and Concepts
A few terms need to be defined for the purposes of this discussion: - Code Signature -- A hash generated for an entire binary file (an EXE, DLL, or others). The hash is encrypted with a private key, and it can be decrypted with a public key which is included in the signature via a certificate. Code signatures can be embedded in the signed binary, or they can be stored separately, in a security catalog. These hashes are produced during the code signing process, and they are used by the OS to authenticate the signature for those binaries. That "authentication" process is also referred to as the "client side" of the code signing process.
- Security Catalog -- a security catalog is a signed file containing a list of code signatures (or hashes) and a set of attributes for a number of binary files.
- Certificate Chain -- A set of related certificates starting with the certificate that can be used to decrypt the encrypted hash and including its issuer and all the higher-level issuers all the way up to a trusted root authority (a self-signed certificate the user has chosen to trust). These certificates, excluding the trusted root authority, are typically stored along with the hashes.
To validate a code signature, the OS decrypts the hash using the signer's public key included in the signature, and then re-calculates the hash (by reading the relevant parts of the signed binary) to verify that the re-calculated value matches the one decrypted. This step validates the integrity of the file (i.e. that is hasn't been altered). Next, the OS validates that the signer is a trusted entity and that it's entitled to sign code through validation of the signer's certificate (this process requires a certificate chain).
The problem that Security Catalogs solve
Initially, code signatures could only be embedded in the signed binaries. That required too much footprint in an OS that had thousands of binaries. Much of the information in the signatures is not unique -- namely, the certificate chains. And they would be the exact same certificate chains stored in every binary. Security catalogs store hashes for multiple binaries, and a single copy of the certificate chain, therefore saving a lot of footprint.
Catalog Databases and multiple hashes
The usage of security catalogs expose yet another problem, which is solved with Catalog Databases: - One file's hash can be present in multiple security catalogs;
- When you install a particular binary, you may want to ensure that the hash used to validate it comes from a particular security catalog – your security catalog;
A catalog database keeps a mapping of all hashes to the catalog file they came from, and to the binary they sign. Programs can inquire for all catalogs that contain a hash for, say, foo.dll, and then pick the hash that comes from the right catalog. This saves application programs from having to read every catalog in the system looking for the right hash.
Given this, you can infer that a catalog database can be re-generated at any time by reading the original catalogs they were generated from.
Catalogs on a Desktop System ("Stop Babbling Theory! Show me something practical!")
Security catalogs are stored in ".cat" files, which are stored at %WINDIR%\system32\catroot. The catalog database is present at %WINDIR%\system32\catroot2. The official way for these files to get there is for them to be installed via the CryptCATAdminAddCatalog API. That API copies the .cat files over to their rightful place under "catroot", and it also updates the catalog database to reflect the addition of all new hashes.
Where XPe fits in ("at last!")
Code signing is disabled for most Windows XP Embedded components. The components that do require code signing, such as Windows Media Player, are authored to directly copy files into %WINDIR%\system32\catroot. This leaves the database in an inconsistent state (i.e., there are .cat files in "catroot" which are not present in the database, in "catroot2"). So how can code signing work on an XPe image? The answer is that the APIs that read security catalogs are made to detect that inconsistency, and rebuild the security catalog when they see such inconsistency. So what actually happens the first time XPe validates a signature is: - It tries to get the location of the hash from the database -- that fails;
- It rebuilds the security catalog.
- It tries again -- this time it will succeed, assuming all the correct ".cat" files were stored where they belong.
You can also force a rebuild of the catalog database, with the following command:del /q "%SystemRoot%\System32\Catroot2\Edb.log
Knowing that this takes place helps you understand why these files are there and what their purpose is. It also helps you optimize your image's first-time use -- you can try to force a rebuild of the catalog databases before first-time use, thus making your application more responsive in its first use.
Note that copying catalogs directly to "catroot" is a shortcut to simplify FBA on XPe, and make FBA independent of some security components. Should you use code signing in your applications, consider using the official catalog installation method (CryptCATAdminAddCatalog) on an existing catalog database.
Conclusion
Code signing is an interesting area of the OS that is handled differently in Windows Embedded (as compared to the Desktop). Understanding those differences can help you optimize your device's first-time use. Understanding code signing in general can help you plan security features for your application.
Copyright (c) 2007 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows XP Embedded team blog, here.
 About the author: Alex Gimenez spent a decade as a software developer before joining Microsoft where he spent three years in Test working with some "cool automation" for Live Meeting. He joined the Embedded Windows team as a developer late last year. Although originally from Brazil, "I can't play soccer to save my life," says Gimenez.
Related stories:
(Click here for further information)
|
|
|
|
|
|
|
news feed