Windows Mobile 5.0 Local Authentication Sub System (LASS) - Part 3

In Part1 I looked at the power-on-password replacement options for Windows Mobile 2003. Part 2 introduced the new Windows Mobile 5.0 LASS architecture and how to create a simple LAP. This post will look at a slightly more complex LAP, converting the LetMeIn power on password sample that shipped in the Windows Mobile 2003 SDK. I wanted to show the steps needed to move an existing POP replacement forward to WM 5.0.

 

The original LetMeIn sample is a power on password replacement using a simple drawing to replace the default alpha numeric password input for Pocket PC’s. Grab the original from here to save you installing the Pocket PC 2003 SDK. To make this work with the new LASS architecture the code needs to be converted to WM 5.0, a few changes to the code and a bit more registration to allow the LASS on Pocket PC to pick it up. These are the steps I went through:

 

1> Convert the project from EVC 4.0 to Visual Studio 2005 – although you don’t strictly need to do this it will make development and deployment much easier.

2> Remove the old POP exports and add in the new LAP exports.

3> Link up the new methods to the existing code.

4> Sign, deploy and register.

 

Conversion from EVC 4.0 to VS 2005

If you used beta versions of VS 2005 you may have come across the EVC upgrade wizard utility that was shipped as a separate download from Microsoft. The good news is this functionality is built into the released version of the product so nothing extra to install.

Note: installing the beta upgrade tool with the released VS 2005 will break the install!! Learn from my mistake and don’t do it. I had to run the VS repair to set everything right again.

 

To convert the project: from VS 2005 click File| Open Project/Solution and select letmein.vcw and click Open. Let the conversion wizard do its thing and you should then have a VS 2005 project.

 

Next, change the target platform from Pocket PC 2003 to Windows Mobile 5.0 Pocket PC. If you try and build at this it will fail due to a machine type mismatch. To fix this we need to change the Target Machine setting: click Project | Properties, select the linker settings, select Advanced and change the Target Machine to MachineTHUMB. Next select the General tab (still for Linker) and change the output file to <inherit from project settings>. Don’t forget to do these for release build as well as debug.

 

Just check everything builds at this point, ignore the /OUT directive warning, it's fixed in the next step when we get to the DEF file.

Changing the Exports

Open up LetMeIn.def and change the library name and exports to be as follows:

LIBRARY LetMeIn

EXPORTS

      LAPCreateEnrollmentConfigDialog

      VerifyUser

      InitLAP

      DeinitLAP

      VerifyUserStart

      VerifyUserStop

      VerifyUserToTop

 

Implement the new exports

Open LmiMain.cpp and replace the cpl.h include with

#include <lap.h>

Delete all the code after the DllMain function and replace it with the following. All I’ve done here is lift the lines in bold from the old code and put them into the LAP structure.

BOOL InitLAP(InitLap* il)

{

return TRUE;

}

void DeinitLAP()

{

return;

}

VOID VerifyUserStart(

const GUID* AEKey,

LPCWSTR pwszAEDisplayText,

HWND hWndParent,

DWORD dwOptions,

PVOID pExtended

)

{

// NOOP

}

VOID VerifyUserStop()

{

//NOOP

}

VOID VerifyUserToTop()

{

//NOOP

}

BOOL VerifyUser(const GUID *AEKey,

LPCWSTR pwszAEDisplayText,

HWND hwndParent,

DWORD dwOptions,

PVOID pExtended

)

{

// Prompt the user and handle all the custom security stuff

LmiDialog_DoModal( hwndParent, TRUE );

return true;

}

BOOL LAPCreateEnrollmentConfigDialog(HWND hwndParent,DWORD dwOptions)

{

// Prompt the user and handle all the custom security stuff

LmiDialog_DoModal( (HWND)hwndParent, FALSE );

return false;

}

Sign and Register the new LAP

Open Project | Properties, select the Authenticode signing tab and enable signing. Select an appropriate cert, and provision the device – select the privileged certificate store.

To use the registration tool I showed in part 2 you will also need to change the deployment location for your dll to \windows. However if you want to put the dll somewhere other than \windows then a full path can be put in the dll registry entry for the LAP. Just as a reminder here are the reg keys that need to be set to register the LAP:

Create the key:

HKLM\Comm\Security\LASSD\LAP\LetMeIn

Set the dll string value:

HKLM\Comm\Security\LASSD\LAP\LetMeIn\dll = <path>LetMeIn.dll

Update the ActiveLAP to point at our new registry entry:

HKLM\Comm\Security\LASSD\LAP\ActiveLAP = LetMeIn

Were done. If you are using the registration tool click Reload so the OS picks up the registry changes. Or simply soft reset the device.

The new LAP should now be active:

For more info on the LetMeIn code, see the WM 2003 SDK docs.

Stuff worth noting

I’ve had to hard reset (clear save state) the emulator lots of times when testing this code so I would highly recommend you don’t try this on a device that has valuable data because if this all goes wrong there is no way of getting the data out of a locked device. I suggest you only move to a device when you have this all working in the emulator.

If your LAP is destined for retail devices rather than just for fun, the certificate used to sign your dll becomes much more important. All retail WM 5.0 devices have the Mobile2Market certificates installed so purchasing and using signing incidents from one of the providers (Verisign, Baltimore etc) is the preferred route – check out Mobile2Market web for more details. For enterprise devices – e.g. if you are rolling out controlled devices to your workforce then it might be worth considering creating (or purchasing) an enterprise owned cert, use it to sign your LAP and provision the device store with the new cert - for even tighter control over the device you could opt to revoke the standard Mobile2Market certs so software signed with your cert will run, but that’s a different story for another blog.

I haven’t worked out yet what effect the Authentication Events (AE’s) have on the Pocket PC login process yet. The documentation implies they can be used for finer control over when the LAP gets displayed, but I cant seem to effect the behavior of the default LAP in any way by changing the values for these. These might be a more relevant for a bespoke CE OS rather than Windows Mobile - I guess this needs a bit more investigation work.

Also I haven’t quite worked out what implications LAP_CAPABILITIES_MASTER_KEY has on a LAP. This is an option flag that can be returned from InitLAP and is sent to VerifyUser and EnroleUser. The docs imply this should be returned from InitLAP if the LAP supports master key protection, and the equivalent flag will be passed to VerifyUser if the LAP should use master key protection. Master key protection is a way of encrypting and decrypting data using OS managed keys via the CryptProtectData and CryptUnprotectData API’s. Master key protection implies the LAP will be used to capture the master key used to protect these OS keys. Again, I think this is something for a later blog.

I think that’s Pocket PC LASS pretty much finished. Next I want to try the same stuff on Smartphone so there might be a part 4 when I get it all working.

Marcus