Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Certificate Lifecycle Manager — Beta 1 Training
July 23, 2006
I attended the beta version of the new week-long training course Microsoft has put together for the Certificate Lifecycle Manager (aka CLM, pronounced “clam”) product. Actually, the course was written by the folks over at IdenIT Inc., and was very well done. In the various segments of the in-class lab portion, you literally configure CLM from installation all the way through live smart card deployment and troubleshooting. The lab is based on the Beta 1 version of the product, dating from February ’06, which is basically the version acquired as Alacris idNexus, minus some features (e.g. card printing).
One of the interesting technical questions that came up during the class was regarding the way CLM stores encrypted passwords in the registry. In short, the Win32 Data Protection API (DPAPI) is used. The critical detail, from a security perspective, is that DPAPI’s “local-machine” flag is specified by CLM for the encryption operation, which in turn allows any authenticated account to perform the decryption. Why does that matter?
Well, let’s look at what account passwords are protected in this manner. There are at least four.
-
CLM Agent
-
CLM Enrollment Agent
-
CLM Key Recovery Agent
-
CLM Authorization Agent
Additionally, if SQL authentication is being used, the database connection string, which includes a password, is stored encrypted in the registry as well. Note that SQL auth is the only option currently available; integrated auth will reportedly be supported in the RTM version.
Anyway, consider the CLM Key Recovery Agent account, which will typically be authorized to decrypt certain user keys archived at the Certificate Authority. Compromise of such a key might allow me to view your encrypted email, for example.
The problem with DPAPI local-machine semantics is that any account with permission to logon to the CLM server can decrypt the data. I confirmed this by writing a tool which reads the encrypted blobs from the registry, runs the blobs through CryptUnprotectData, and displays the resulting password on the console. I did this logged in as a local non-admin user. (As an aside – the tool I wrote is also useful for getting and setting these account passwords without having to re-run the CLM Configuration Wizard. Ping me if you want it.)
Do we really want any user with logon privilege to that particular server to be able to access such high-value accounts? This makes role separation challenging. For example, I used to work at an organization that implemented rotating pager duty for domain controller support. We used local-admin, non-domain accounts to troubleshoot the DCs, which seems like a good compromise. I grant that we’re not actually talking about DCs in this case, but supporting a CLM server in that way implies a much higher bar for vetting the support staff. Also, I admit that I can’t think of a good reason why any high-value server should be configured to grant interactive logon rights to any non-admin, non-domain accounts. But even at the local-admin level, this makes role separation challenging. And let’s face it – IT shops make mistakes. Plus, not too many people really understand how DPAPI works!
How to do better? Well, as soon as integrated auth is supported for database access, use it. Next, every certificate issuance should be configured to require secondary approval. So even if someone with local access to the CLM server can get his hands on the CLM Enrollment Agent password, a different group of people must be tasked with auditing every certificate request.
What about mitigating the Key Recovery case mentioned above? I confess I don’t know enough about the configuration options of that scenario to say definitely whether secondary approval is even an option, assuming the CLM KRA password is compromised. Anyone?
How to do even better in a future version of CLM? At the very least, read-rights on the current registry location could be tightened (in fact, that could be done today with a security template …). Alternately, let’s assume that integrated auth for database access becomes mandatory. Then, all of the CLM agent passwords can be stored encrypted and ACL’d in the database such that only the CLM web pool account has access. In that case, DPAPI could still be used for encryption in the context of that account (i.e. skip the local-machine flag). Password management would then be performed via a web interface which could define its own access rules.
Permalink |No Comments »
No comments yet.
RSS feed for comments on this post. TrackBack URL
