Dan Griffin's Blog

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

We’ve posted a "smart card mini-driver compatible" card initialization and debugging tool, available for download here - http://www.jwsecure.com/downloads.html. Feedback is welcome!

Permalink | Comments (0)

I recently got feedback that my Hybrid Credential Provider sample (see the code download with this article - http://msdn.microsoft.com/msdnmag/issues/07/01/CredentialProviders/) in MSDN magazine doesn’t support the Unlock scenario (i.e. it just supports Logon). Sorry about that!

Few notes about this. First - the credprov sample in the Vista RTM version of the Windows SDK (see "Samples\Security\CredentialProvider" from the SDK root directory) unfortunately has the same bug. Second - five newer credprov samples are available for download via the following link - http://www.microsoft.com/downloads/details.aspx?FamilyID=b1b3cbd1-2d3a-4fac-982f-289f4f4b9300&DisplayLang=en. The latter appear to have been fixed.

Finally, the bug is this - Credential::GetSerialization needs to return a KERB_INTERACTIVE_UNLOCK_LOGON structure instead of a KERB_INTERACTIVE_LOGON (see NTSecAPI.h in the SDK as well as SampleCredentialProvider\SampleCredentialProvider\CSampleCredential.cpp from the new credprov sample set). The following comment from the latter is particularly instructive:

"We use KERB_INTERACTIVE_UNLOCK_LOGON in both unlock and logon scenarios. It contains a KERB_INTERACTIVE_LOGON to hold the creds plus a LUID that is filled in for us by Winlogon as necessary."

Permalink | Comments (1)

Interesting article in this month’s BioIT World magazine entitled "The Case for Security in Bioinformatics" - http://www.bio-itworld.com/issues/2007/april/bioinformatics-security/. In summary, the article observes that some old network security problems apply to an emerging field - surprise - but there are a couple of points worth discussing.

The observation is made that the use of distributed research resources, such as shared data repositories, is a potential problem. Due to the high stakes and big dollar values involved in drug research, labs typically want to reveal as little as possible about the types of efforts they’re investing in. But even the behavior ("meta-data") of network traffic can be revealing. For example, what type of queries is a reseacher making against a hosted database? The nature of the queries may indicate a new research direction that was intended to be kept secret.

How to prevent this? Well, application or transport-layer encryption come to mind - options include SSL/TLS and IPsec. The former is widely deployed in ecommerce; perhaps it’s less so in the context of scientific data repositories. The latter is less widely used, although might be an interesting option for providing an encrypted link between a lab’s network edge and a hosted database on the internet. Of course, the amount of raw data involved in such research scenarios tends to be huge. I don’t know whether the overhead imposed by TLS or IPsec encryption would be noticeable; however, a dedicated encrypted link between two edge servers would likely warrant special offload hardware (a solution which has historically proven cost prohibitive on individual workstations).

Although confidentiality may be less of a concern within the laboratory LAN (as compared to data sent across the wide-open internet), data integrity is still an issue. A colleague recently shared with me that the entire lab data path (from device to network to device, etc) is of concern from a compliance perspective. That is, what assurances are made that data in transit, or at rest, hasn’t been modified, maliciously or otherwise? Again, the amount of data for which integrity claims must be made is huge - potentially hundreds of gigabytes per day or more!

Another point raised by the article is that of trustworthy software. How should research labs evaluate the quality of a given software solution from a security perspective? As in any computing environment, there will be those who reflexively prefer either closed source or open source. But I’m not aware of any correlation between the "openness" of a body of code, and the caliber/qualifications of the people who wrote, reviewed, and tested it, especially from a security perspective. What criteria then - reputation, number of patches issued? I’m a (biased) fan of 3rd party assessments, although that approach is expensive. The current state of the "software evaluation and deployment" art seems to be a best-effort combination of all of the above, plus some perimeter security and patching solution, with the costs shared (one way or another) between each vendor and its clients. This is an area ripe for disruptive innovation!

Permalink | Comments (0)

My company does most of its software development testing using virtual machines, since that approach reduces the cost of setting up (and tearing down) complex scenarios. The VM approach raises some interesting challenges too …

One recent complex test configuration demonstrates such a challenge. The config is an Active Directory environment supporting smart card logon, deployment via Identity Lifecycle Manager, and a peer-to-peer IPsec policy. That configuration requires at least three separate images (one for Domain Controller/CA/IIS/SQL/ILM, and two clients to test IPsec). We typically try to run all of the images on a single server box via VMware Server. In this case, even though both clients are Vista - which we’ve found to be a real resource hog when it comes to virtualization - a single server with decent RAM and fast disks can handle it (just don’t try to boot all of the images at the same time if you’re in a hurry). In fact, we’ve even got a Longhorn Server Beta 3 Escrow guest image running smoothly on a Vista host - how’s that for cutting edge!

In general, the VM configuration allows for kernel debugging of the guests via serial pipes, as well as restoring snapshots when something goes really wrong during testing. All goodness.

Smart card testing in that configuration continues to pose a problem, though. We’ve encountered two issues. First issue - and there’s really no way around this one - we primarily interact with the VMs by connecting to the host server via RDP (Remote Desktop Protocol/Terminal Services/TS). Then we view the guests via the VM console from within the remote session. This is especially convenient since it allows the developer to toggle between VM windows during testing, rather than toggle between TS client windows (I find the latter to be truly painful). However, if the host server happens to be in a different room, then there’s no convenient way to do smart card testing. Why? Well, in this case, the TS smart card redirection feature allows the server to see any smart card readers plugged into the TS client. But those devices are only visible on the server via the smart card subsystem. I.e. they don’t show up in the USB stack. Thus they’re invisible to the guest VMs.

There’s a work-around to this, but in essence it breaks the virtual machine scalability model, which is to run as few physical machines as possible. The work-around is to run one of the test VMs from either the developer workstation, or a secondary machine sitting next to it. This raises the second issue: using VMware on Vista hosts, we haven’t been able to get the guest OS to detect a USB smart card reader (not sure if we’ve tried any other type of USB device). Anyone else had any luck with this? The same scenario works using XP as the host.

Anyway, the developer machine is running Vista, since that’s most of the work we do. Therefore, the only option has been to run a separate XP test machine right next to it, and to run a Vista VM guest on the XP host. The interesting bit is that we’re still connecting to the host machine via RDP, just like in the first scenario above. The difference in this case is that the smart card reader is plugged into the VM host machine, instead of into the developer machine. Since the VM host machine is sitting right next to the developer, there’s no problem accomplishing device removal and insertion. And since the host is XP, the Vista VM manages to latch onto the USB device.

I recently read that there’s a VMware v6 Beta available which advertises full Vista support. Hopefully it fixes the USB issue; we haven’t tried it yet. The work-around doesn’t work so well if multiple smart-card-enabled Vista guests are required in parallel, since anything less than server-class hardware will severly drag under that load.

Links:

* What smart card redirection looks like under the covers - http://blogs.msdn.com/spatdsg/archive/2006/10/16/smartcard-logon-over-terminal-services-rdp-redirection.aspx. The architecture is slightly different in Vista; Microsoft doesn’t seem to have documented this anywhere, though.

* VMware 6.0 Beta - http://www.vmware.com/products/beta/ws/releasenotes_ws60_beta.html.

Permalink | Comments (0)

I’ve been reading "The Essential Drucker," by business guru Peter Drucker, who makes the following assertion on page 188:

"The fact remains that so far, anyone who is willing to use marketing as the basis for strategy is likely to acquire leadership in an industry or a market fast and almost without risk."

That comes at the end of an entire chapter on entrepreneurial business strategy (it’s originally from a book he wrote in 1985). It’s a pretty powerful statement. And, if nothing else, it reminded me of the importance of branding, and of taking a customer-first approach rather than a technology-first approach. Nevertheless, I think that to say a business strategy is ‘almost without risk’ is to exaggerate slightly, or at least to oversimplify.

He’s not talking about marketing hype. He’s talking about the process of listening to customers. He’s talking about supplying something that’s useful and valuable from the customer perspective. Of course, lots of stuff can go wrong, and customers don’t always know what they want. I guess the really shocking thing is that Drucker also asserts that few businesses follow this advice, as fundamental as it seems, and as widely as it’s taught. Is that because it’s genuinely hard to do?

Permalink | Comments (0)
Athena has announced (http://biz.yahoo.com/bw/070409/20070409005420.html?.v=1) support for Elliptic Curve Crypto smart cards, via the new Vista smart card minidriver model.  That’s the first publicly announced ECC minidriver card I’ve heard of, so that’s pretty cool. 

ECC cards are thought to offer a compelling alternative to those based on the RSA cryptosystem.  In theory, smaller (i.e. fewer bits) ECC keys can achieve the same level of security as larger RSA keys.  Fewer bits typically implies that the required mathematical operations can be completed with less processing power, which is desirable in an embedded device such as a smart card - and especially so for contactless cards.  Fewer bits also implies a reduced storage footprint, although the difference is sufficiently few bytes that it doesn’t seem to be much of a concern these days.

The one concern is that ECC hasn’t had anywhere near the same amount of "road testing" as RSA, in terms of cryptanalysis and real-world deployment.  So it’s tough to fully trust it yet.

Permalink | Comments (0)

My proposal to present "Hacking Windows Vista Security" (see info at http://seattle.toorcon.org/talks.php?id=6) has been accepted by the ToorCon Seattle organizers. I’m jazzed! I’ll post my slide deck after the event.

As of today, the conference website says there’s still space available for attendees. Looks like there may still be speaking slots available as well, although I’m not certain.

Permalink | Comments (0)

Although I touched on this in my credential provider article (http://msdn.microsoft.com/msdnmag/issues/07/01/CredentialProviders/default.aspx) for MSDN Mag, I could have done a better job of describing how to get out of a certain nasty debugging situation. Specifically, what do you do when you’ve got a broken credprov registered on the system, and it’s preventing you from logging on?

First answer: reboot to safe mode. Logon as the local admin via password. Un-register the broken credprov. Reboot.

To make your life even easier, ensure that your credprov has working DllRegisterServer and DllUnregisterServer exports, and that those are the first thing you test. That way, once you’re in safe mode, all you have to do is "regsvr32.exe /u mycredprov.dll".

Off the top of my head, I can’t think of a good reason why the above shouldn’t work, but you never know. In general, when testing plug-ins that can hose a system (e.g. credprovs), we always do either of the following:

- Test on a VM (best practice), and take a snapshot before installing the credprov. Undoing a mistake in this case takes less time than a reboot on most machines.

- Otherwise, if a separate test machine is the only option, keep a safe-boot partition (i.e. a separate working boot entry, perhaps XP)

 

Permalink | Comments (0)