| 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)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Windows is a trademark or registered trademark of Microsoft Corporation in the United States and/or other countries and is used by WindowsForDevices under license from owner. All other marks are the property of their respective owners. WindowsForDevices is an independent publication not affiliated with Microsoft Corporation.
news feed