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

I came across another new feature of Windows Mobile 5.0 recently when trying to install an application that we originally created for Windows Mobile 2003 on a WM 5.0 device. The application, called Pocket Beat, is designed to provide Police officers with query access to the UK Police National Computer whilst away from the station.

Part of the application is a power-on-password (POP) replacement component that integrates with the device to capture a strong password from the user and generate a user token that’s used in the application to identify the user. The technique used to create a POP replacement component on WM 5.0 has changed significantly and is not backward compatible with older code due to the new Local Authentication Sub System (LASS) architecture implemented with WM 5.0.

I’m going to have to post about this stuff in bits because there is quite a bit of info I want to share, so consider this part1.

First of all let’s recap a couple of things:

Why would you want to replace the power-on-password? The built in POP is capable of capturing and validating a 4 digit pin or a longer alpha numeric value on Windows Mobile 2003 and beyond, and that is widely considered sufficient for the majority of users.

There are several good reasons for replacing the POP with custom code, for example if you are selling a hardware extension such as a thumb print reader or a smartcard reader, or you need a customized security panel for working environment where users have to wear gloves.

Now, more importantly, consider the suite of utility applications that offer data encryption on the device. Some applications encrypt the whole file store when the device goes into suspend mode, and others provide on-the-fly encryption of data to and from the store. One of the biggest challenges for this type of applications is where to store the key used to encrypt/ decrypt the data. Unlike XP, WM 5.0 has no provision for storing user specific secrets, and in fact has no mechanism for asserting user identity. So a replacement POP screen is used to grab some secret data from the user and derive a key from that information, thus avoiding complex and insecure storage of the key on device.

I have seen the same principal used successfully several times in enterprise applications that want to generate a key for local security and for some form of network authentication or secure communication.

How does the POP architecture fit together? There are four bits that make up the POP architecture.

At the heart is the password storage and checking bits accessed through 3 functions in coredll.dll. These are:

BOOL SetPassword( LPWSTR lpszOldPassword, LPWSTR lpszNewPassword ); // Changes the password stored in the OS

BOOL SetPasswordActive( BOOL bActive, LPWSTR lpszPassword ); // Turns on or off password checking

BOOL GetPasswordActive(); // Find out if password checking is on or off.

There is no header file containing these definitions so you will have to include the prototypes manually in your code.

The second component is the power-on-password screen presented to the user when the password is enabled. This can be replaced with a custom DLL by updating a registry and is loaded and called by the Today screen on power-on. The screen captures a password and returns it as a string to the calling function.

The third component is the control panel applet used to set and manage the password. The inbuilt version is called password.cpl. This is a standard CPL app that exposes a dialog for setting and enabling the password.

The last component is ActiveSync. When a password is set and enabled on the device Active Sync will not allow a connection to be made until the same password has been provided by the desktop user.

How is the POP replaced on Pocket PC? From Pocket PC 2000 through to Windows Mobile 2003 SE the POP can be replaced using two simple steps:

1> First create a C++ dll that exports a function called PromptForPasswd that has the following signature:
LPTSTR PromptForPasswd( HWND hwndParent, BOOL fTightSecurity );

The first parameter provides the parent window for any dialog’s displayed. The second parameter I’ve never worked out what it does. The function must return a string that matches the system held password string. On Windows Mobile 2003 there some OEM’s have a limit of 10 characters for the password, but I’m not sure if that should be the standard or just what these OEM’s have chosen.

2>Update the registry key HKLM\controlpanel\password and set the string value “Redirect” to the dll name and path e.g. “\windows\password.cpl”.

Soft reset the device and your pop is now active. However its probably a good idea to create a control panel app to set and update the password as well.

How do I create a POP CPL? Just the same as any CPL on the desktop or on Pocket PC. Its another export (CPlApplet) and some code to display the capture dialog.

Samples.

There are a couple. The WM 2003 SDK comes with LetMeIn that shows how to replace the POP and provides a CPL in a single dll.

You can also look at Chung Webster’s MSDN article that covers this in a bit more detail: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/wmdeploy.asp

Part 2 we will take a first look at the new LASS architecture in WM 5.0

Marcus