Dan Griffin's Blog

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

Location Platform sensor: lessons learned so far

March 16, 2009

In researching and developing the Laptop LoJack prototype (see blog thread and Codeplex page), I encountered a few gotchas. For posterity:

First, some kudos. The Windows 7 Location Platform sensor driver model uses the User Mode Driver Framework (UMDF). Like any technology, UMDF has a learning curve, and I wasn’t totally over it before I started this project (I’d experimented with some of it previously). That said, UMDF is one of the most important Windows technologies of the past several years: anything that doesn’t have to be in the kernel, shouldn’t be. That’s important for: reliability, security, and time-to-market for IHVs and ISVs who may now be able to avoid the extra cost of kernel-mode development.

The Win 7 Beta DDK (which I believe is unfortunately only available to premium MSDN subscribers right now) includes a sample sensor driver. The second kudos goes to the Microsoft location platform team for the documentation that they included with that driver code, specifically on how to customize it (i.e., how to take the sample and turn it into something real). If every product team at Microsoft included that kind of documentation with their samples (assuming they actually provide those, of course) the company’s dominance would be assured for many years to come …

Second point: as I described in the previous post on this topic, I customized the sample sensor to turn it into the IP geocoding sensor required for Laptop LoJack. I then used the devcon.exe tool (from the DDK, but looks like you can download it separately too) to install the driver. First mistake: I didn’t realize that the WDF helper dlls (e.g., WdfCoInstaller01009.dll), from the DDK redist sub-directory, were required in order for the installation to succeed. Frankly, the error message from devcon.exe is useless. Second mistake: I grabbed the wrong WDF dlls, thinking that I wanted the *_chk versions, since I was installing chk driver binaries.

You can avoid both of those mistakes by noticing which install helper binaries are referenced by the driver INF produced by build.exe.

Third point: Inf2Cat.exe is another useful DDK tool. If your building a driver (even UMDF) that’s going to actually be deployed somewhere, then you should be signing it to avoid the nasty prompt. But building your own CAT file is a pain, which is why Inf2Cat.exe is quite useful. However, remember that the CAT file needs to reference all of the files that are referenced by the INF. Thus, like devcon.exe, Inf2Cat.exe also needs to be able to find the WDF helper dlls. A build script would be the way to go here: copy the necessary files to a temporary location in order to build the CAT, then clean up duplicate files.

Fifth point: once the sensor driver is installed, it needs to be enabled via the Location Platform control panel applet. You can find that by typing “location” into the search field on the Start menu. The Laptop LoJack scenario would actually call for this sensor to be enabled by default, since it’s expected to be a managed laptop and the user shouldn’t be able to disable the sensor in this case. Hopefully, this is just a regkey that we can set via the installer. In fact, there’s a second problem here, which is that, even after the sensor is enabled, there’s a separate prompt asking the user for permission to expose data from that sensor. That strikes me as overkill, even for an un-managed deployment scenario. Again, hopefully there’s a registry override.

Sixth point: once I got this far, my driver still wouldn’t load with the test program (included with Laptop LoJack code; it’s just an adaptation of a Location Platform sample included with the SDK). I had an easy guess why, though. I had disabled these two “GPS sensor type” location properties,

SENSOR_DATA_TYPE_ALTITUDE_SEALEVEL_METERS
SENSOR_DATA_TYPE_ERROR_RADIUS_METERS

since I only have data for latitude and longitude. Turns out those are required. I re-enabled them, and just return hard-coded values for now, and the driver works fine. A better way to handle that? A future version of the driver could take the returned lat & long values and look-up the altitude for that location. Error radius is still problematic, though, since as I mentioned in a previous post, IP geolocation is really a best-guess with regional granularity. I’m guessing it could be off by several hundred miles, unless you live in a city in the northern hemisphere.

Seventh point: I mentioned one potential improvement above in doing a reverse look-up on your altitude. Additional potential improvements:

1. The current IP geocoding web-lookup code, since it screen-scrapes Live maps, is fragile. Maybe someone has a better idea. However, what it currently does is convenient for two reasons. (A) we don’t have to do a separate “what’s my public IP address” look-up, since that’s implicit. And (B), the string matching logic for the Live page is pretty simple, even in native C. Still, I’d love to improve on this.
2. There’s currently no caching of latitude and longitude data. That’s partly because the sensor driver makes separate queries for those two items, and I’m not yet confident enough in my knowledge of the UMDF sensor architecture to make a caching recommendation. However, because the relevance of the data is really just city to city, as previously stated, caching the data for an hour or more should be fine (even if you’re in a jet!).

Search:

Archives

Recent Posts

• Cloud developers
• Microsoft Security Intelligence Report v8
• Windows LNK bug and SCADA vuln
• Mobile devices + Cloud
• Concurrency, Security, and Windows

RSS Feed

Blogroll

Security Focus: