Share via

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

  • Article

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

Comments

  • Anonymous
    December 08, 2005
    Doh! forgot to post a link to my converted project. Grab it here:
    http://marcusperryman.members.winisp.net/BlogStuff/letmeinlap.zip

    Marcus

  • Anonymous
    December 16, 2005
    A side-affect of LAP_CAPABILITIES_MASTER_KEY is that if it's set, a call to LASSReloadConfig causes an implicit call to VerifyUser. Though this is listed in the PB LAP doc for LASSReloadConfig, somehow I missed it, and it caused some confusion when a sample LAP of mine was going through the verify sequence on LASS reload.

    Anyway, thanks for the attention to LAP/LASS, Marcus, it's appreciated. Any more info on LAP & master key encryption would be especially appreciated.

    Also, I see the LAP doc says that a LAP should also support the following optional entry points, any info on them?

    LAPCancelVerifySequence
    LAPDisplayCodeword
    LAPDisplayPreWipe
    LAPLockoutUser

    Thanks!

  • Anonymous
    December 22, 2005
    Thanks for the info Craig,
    Havent looked those exportsm, let me take a look and see what I can dig up.

    Marcus

  • Anonymous
    February 13, 2006
    As you mention
    "although you don’t strictly need to do this it will make development and deployment much easier.",

    how can we develop using VC++4?

  • Anonymous
    February 13, 2006
    Frankie, see my reply here:
    http://blogs.msdn.com/marcpe/archive/2006/02/14/531679.aspx

    Marcus

  • Anonymous
    April 05, 2006
    The comment has been removed

  • Anonymous
    April 05, 2006
    The comment has been removed

  • Anonymous
    April 06, 2006
    The comment has been removed

  • Anonymous
    September 20, 2006
    Hello,

    is there a way to programmatically lock the device ? I read that there is a SHDeviceLockAndPrompt() function but it seems not available yet in the Pocket PC SDK. A call to VerifyUser is not sufficient beacause it does not block the UI and ActiveSync connections.
    Thanks

  • Anonymous
    October 17, 2006
    Hi Also, I see the LAP doc says that a LAP should also support the following optional entry points, any info on them? LAPCancelVerifySequence LAPDisplayCodeword LAPDisplayPreWipe LAPLockoutUser Where I can read about this?answer me in mail _sergey_001@mail.ru thanks.

  • Anonymous
    December 13, 2006
    Thanks so much for the infor. I just get one question: is it possible to debug the code on emulator? Thanks in advance, guru!

  • Anonymous
    October 25, 2007
    Where can i find sample example for creating a custom LAP in Windows Mobile 5 Pocket PC as well as Windows Mobile 5 Smart Phone? The Sample i got from Marcus Perryman's WebLog does not seem to work on my HP hx6960 WM5 Smart Phone which is using AKU2 (MSFP) OS build of WM5. I wanted the LAP to load everytime i power on / off the PDA, it works for my Pocket PC which is using an older OS build of WM5, however when it comes to Smart Phone it fails to load. I wonder if the cause is due to the different OS builds or due to the differences in Pocket PC and Smart Phone platform. I found out that everytime i power on/off, the dwoption parameter pass in to the verifyUser is always VU_NO_UI. How is this so?

  • Anonymous
    May 16, 2008
    I handled a couple of cases related to this and therefore I think it's worth mentioning it here, to help