Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

The code sample links for two of my MSDN online articles have been fixed.  Sorry that they were broken for a while.  Links to both article & code sample sets are here:  http://msdn2.microsoft.com/en-us/library/bb945060.aspx.

Separate links:

Permalink | Comments (0)

I’ve got a good email thread going with a colleague regarding the deployment of smart cards, and specifically regarding the choice of reliable card middleware. Wanted to broadcast some of it for wider benefit:

Regarding vendor selection for a smart card deployment, there are a couple of things you’ll have to evaluate and choose: who provides the chip, who puts the chip on the card, who provides the software mask that runs on the chip, who provides the middleware for the host, and who provides the readers. There are packages wherein some or all of those choices are made for you.

Middleware refers to the application-layer software that runs on the PC. The Cryptographic Service Provider (CSP) plug-in in Windows is an example of one component of the middleware. The CSP allows Windows apps to use a given card for crypto operations via Crypto API (CAPI), such as those required for logon or for signing an email.

Due to the complexity of application interfaces such as CAPI, it’s easy for vendors to make mistakes in the middleware that can cause client apps to fail and/or cause the card to exhibit poor performance. For that reason, assuming you’re targeting Windows, I recommend looking for cards that support the “card mini-driver” or “card module” (two names for the same thing) interface (more info). In that case, Microsoft has provided a CSP called the Base Smart Card Crypto Provider (or BaseCSP), and the vendor has written a much smaller card-specific plug-in that sits under that. That way, there’s less application surface area exposed to vendor code.

Some applications require PKCS#11 middleware instead of a CSP. Thus, in an ideal world, you’d have a card with supported P11 and CAPI middleware.

Another piece of the interoperability puzzle is to ensure that your choice of card works well with your choice of card reader (also called the interface device, or IFD). Ensure the reader has drivers available for all of the OS versions you want to support and that the driver is reliable. Finally, test the card with the reader to ensure you don’t see spurious communications failures and that card operations are speedy: once the card has been provisioned, signing an email with it shouldn’t take more than 1/2 second, for example.

It’s a good idea to run a pilot deployment, gradually scaling up to 5 - 10% of the user base, to work all of these things out.

Permalink | Comments (1)

http://isc.sans.org/diary.html?storyid=3823
http://it.slashdot.org/it/08/01/08/0439231.shtml

Plus, my Vista machine bugchecked after the forced injection of last night’s Windows Update patches.  Anyone else?

Permalink | Comments (0)

Just upgraded to QuickBooks 2008, since it claims to interoperate better with Vista. Since I’m planning on exchanging QB data files with my accountant, I thought I’d be clever and create a dedicated QB directory and mark it as encrypted (that is, using the built-in NTFS Encrypting File System feature).

Unfortunately, after doing so, when attempting to import a QB backup (or the ‘portable’ data file format), the program shows some nasty error code and the backup fails.

Educated guess as to the nature of the failure? Well, it turns out QB installs a service! It’s called QBCFMonitorService.exe and it’s running as Local System. Now, why does QB need an NT service, and why would it need to run as system? These are security attack surface questions that keep me up at night.

I suppose that service is trying to read the new data file at the end of the import procedure. And it can’t, because that file is encrypted such that only my user account can read it (which was the whole point of using EFS).

Removing the “encrypted” property from my QB data directory allowed the import to succeed.

Permalink | Comments (0)

Hi-tech companies prosper by investing in their people. There are two factors:  training and re-training the people you already have, and growing the company by hiring more of the best and brightest. And regarding the second factor, great companies don’t want to just hire the smartest people within a 10 mile radius; they want to hire the best people from all over the world.

That’s a model for the challenge faced by the United States and its messed up immigration policies. We need to be doing two things:  training our workers so they’re ready to be competitive in the world market for the best jobs, and absorbing the smartest people from the rest of the world. We’re currently not doing a good job of either.

These are problems for which our presidential candidates should be held accountable. A precious few of them have articulated believable strategies to this end.

If you’re a US citizen and you’re reading this, then you should get informed, and then when the time comes, vote.

Various relevant issue statements from the current leading candidates (alphabetical order):

Hillary Clinton
http://www.hillaryclinton.com/feature/innovation/
http://www.hillaryclinton.com/issues/immigration/

John Edwards
http://www.johnedwards.com/issues/trade/
http://www.johnedwards.com/issues/tax-reform/

Mike Huckabee
http://www.mikehuckabee.com/?FuseAction=Issues.View&Issue_id=5

John McCain
http://www.johnmccain.com/Informing/Issues/0B8E4DB8-5B0C-459F-97EA-D7B542A78235.htm (”Tax Cut Plan”)
http://www.johnmccain.com/Informing/Issues/68db8157-d301-4e22-baf7-a70dd8416efa.htm (”Immigration”)

Barack Obama
http://www.barackobama.com/issues/technology/#improve-competitiveness
http://www.barackobama.com/issues/economy/#innovation

Mitt Romney
http://www.mittromney.com/Issues/global-economic-competition
http://www.mittromney.com/Issues/immigration

Permalink | Comments (0)

I received some much-appreciated feedback recently regarding a demo and presentation I’ve been doing on programming the Windows Firewall (”with Advanced Security”) on Vista.

For context, the whitepaper and the demo video.

The demo shows that the firewall can be manipulated programmatically, in essentially an arbitrary way, by any account with local administrators rights. The feedback I received, not directly about my demo but about the underlying feature, is that you shouldn’t be able to that.  That is, even for a local admin, an explicit warning should be given to the user that a firewall change has been made. 

I do believe that the operating system has been designed correctly in this case. The Windows security model is that administrators have full control over the local box.  That applies to programmatic interfaces as well as GUI configuration tools (which, after all, are merely a logical layer on top of the former).

Interestingly, the firewall is an example of a Vista feature wherein Microsoft attempts to straddle the above line. By default, if you turn off the firewall, you’ll get the security center nag icon in the systray.  That happens even despite the fact that admin credentials were required to make that change in the first place!  (Note - my understanding is that the OS will stop nagging the user in that scenario if a 3rd party firewall registers itself with security center.)  But - I don’t think the nagging accomplishes anything of real value.

Admins must be expected to know what they’re doing (the same argument applies to the su account on *nix systems).  Additional prompting is detrimental in that it adds no security and devalues confirmation dialogs in general.

Permalink | Comments (0)

While spending some time debugging a NAP (Network Access Protection) SHV (System Health Validator) on WS08 (Windows Server 2008) RC1 recently, it was brought to my attention that all such plug-ins must implement the INapComponentInfo interface.  For details, see this MSDN page.

That interface allows NAP to query the plug-in for converting custom error codes to localized strings, for example.  Don’t use any custom error codes?  Too bad ;) - you still must implement the interface, otherwise your plug-in will most likely fail to register.

Careful - I think this was a change from Beta 3.  So if you’ve got custom NAP plug-ins that you’ve been working on for a while, be sure to retest before deploying to WS08 RC1 or RTM.

Permalink | Comments (0)
« Older Posts