Compartilhar via

Security Catalogs and Windows XP Embedded

  • Artigo

Overview

Security Catalogs are an important feature of Windows’ Security system. These catalogs help reduce disk footprint used by the code signing process. Security catalogs are installed differently on Windows XP Embedded systems. This article explains those differences in installation and how these differences impact XP Embedded images.

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 O.S. 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 .O.S. 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 O/S 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 O.S. 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 rebuilt 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 O.S. 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.

 - Alex

Comments