Programmatically setup a PEAP connection in Windows Mobile

Question

I have been working on this for a few days and this is doing my head in:

Our application is built using the .NET Compact Framework 2.0 and running on Windows Mobile 5 & 6 devices. We can set the WLAN connection of the device programmatically using the Wireless Zero Config functions (described here: msdn.microsoft.com/en-us/library/ms894771.aspx), most notably the WZCSetInterface function which we pinvoke from our application. This works fine for WEP and WPA-PSK connections.

In a recent effort to add support for WPA2 networks we decided to modify the code. We have successfully added support for WPA2 which uses a certificate for the 802.1x authentication by setting the correct registry settings before calling WZCSetInterface. Now we want to do the same for WPA2 using PEAP (MS-CHAPv2) authentication. When manually creating such a connection in Windows Mobile the user will be prompted to enter the domain/user/password details. In our application we will have those details stored locally and want to do this all programmatically without any user intervention.

So I thought going along the same route as the certificate authentication, setting the correct registry entries before calling WZCSetInterface.

The registry settings we set are: \HKCU\Comm\EAP\Config\[ssid name]

• Enable8021x = 1 (DWORD)
• LastAuthSuccessful = 1 (DWORD)
• EapTypeId = 25 (DWORD)
• Identity = "domain\username" (string)
• Password = binary blob containing the password that is encrypted using the
  CryptProtectData function (described here: msdn.microsoft.com/en-us/library/ms938309.aspx)

But when these settings are set and I call WZCSetInterface with the correct parameters, it still prompts me with the User Logon dialog asking for the domain/username/password.

Has anyone got an idea what I need to do to prevent the password dialog from appearing and connect straight away with the settings stored in the registry?

Answer 1

I don't know if this will help you or not but I had the same problem and kept adding registry entries until something fixed it. I'm not sure which of these fixed it but here are the entries I'm using (edited to hide security related info):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL] "RNG"=-

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WZCSVC\Parameters] "ContextSettings"=hex:[REMOVED]

[HKEY_LOCAL_MACHINE\System\DPAPIKeys\System] @=hex:[REMOVED]

[HKEY_LOCAL_MACHINE\System\DPAPIKeys\default] @=hex:[REMOVED]

[HKEY_LOCAL_MACHINE\init\BootVars] "MasterKeysInRegistry"=dword:1

[HKEY_CURRENT_USER\Comm\EAPOL\Config[REMOVED]] "LastAuthSuccessful"=dword:00000001 "Password"=hex:[REMOVED] "Identity"=[REMOVED] "EapTypeId"=dword:00000019 "Enable8021x"=dword:00000001

[HKEY_CURRENT_USER\Comm\EAPOL\Config[REMOVED]\25] "ConnectionData"=hex:[REMOVED]

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Ethman\Popup] "Enable"=dword:00000000 "Timeout"=dword:0000000F

[HKEY_CURRENT_USER\System\Credentials\Type\2] @=hex:[REMOVED]

Answer 2

After some more investigation I eventually gave up with the registry settings. It seems that the key to a successful connection is the Password value in HKCU\Comm\EAP\Config[SSID]. But because CryptProtectData uses an undocumented entropy value (for obvious security reasons) to encrypt the password, it seems impossible to recreate a valid entry in the registry programmatically.

I then went with the second best solution, catching the User Logon dialog after calling WZCSetInterface and enter the required fields in there:

bool enteredPeapCred = false;
DateTime timePeapCredStarted = DateTime.Now.AddSeconds(10);

// wait for PEAP credentials window to appear (max. wait for 10 seconds)
while (!enteredPeapCred && timePeapCredStarted >= DateTime.Now)
{
  IntPtr hwndLogon = Win32.FindWindow(null, "User Logon");

  if (hwndLogon != IntPtr.Zero)
  {
    // move User Logon window offscreen to prevent screen flicker in app
    Win32.MoveWindow(hwndLogon, -600, 0, 320, 480, true);                               

    // "Network Log On" label   
    IntPtr hwndCtrl1 = Win32.GetWindow(hwndLogon, Win32.GW_CHILD); 
    // "Enter network info..." label
    IntPtr hwndCtrl2 = Win32.GetWindow(hwndCtrl1, Win32.GW_HWNDNEXT); 
    // "User name:" label
    IntPtr hwndCtrl3 = Win32.GetWindow(hwndCtrl2, Win32.GW_HWNDNEXT); 
    // username textbox
    IntPtr hwndCtrl4 = Win32.GetWindow(hwndCtrl3, Win32.GW_HWNDNEXT);
    // "Password:" label 
        IntPtr hwndCtrl5 = Win32.GetWindow(hwndCtrl4, Win32.GW_HWNDNEXT);
    // password textbox 
    IntPtr hwndCtrl6 = Win32.GetWindow(hwndCtrl5, Win32.GW_HWNDNEXT); 
    // enter password into textbox
    StringBuilder sbPassword = new StringBuilder();
    sbPassword.Append(eapPassword);
    Win32.SetWindowText(hwndCtrl6, sbPassword);
    // "Domain:" label
    IntPtr hwndCtrl7 = Win32.GetWindow(hwndCtrl6, Win32.GW_HWNDNEXT); 
    // domain textbox
    IntPtr hwndCtrl8 = Win32.GetWindow(hwndCtrl7, Win32.GW_HWNDNEXT);
    // "Save password" checkbox 
    IntPtr hwndCtrl9 = Win32.GetWindow(hwndCtrl8, Win32.GW_HWNDNEXT); 
    // send BST_CHECKED message to set checkbox
    Win32.SendMessage(hwndCtrl9, Win32.BM_SETCHECK, Win32.BST_CHECKED, 0);                                

    // send WM_COMMAND with left softkey to submit user dialog
    IntPtr hwndMenu = Win32.SHFindMenuBar(hwndLogon);
    Win32.SendMessage(hwndLogon, Win32.WM_COMMAND, 0x2F87, hwndMenu.ToInt32());

    enteredPeapCred = true;                                
  }
}

Note that I'm only setting the password field, because the username and domain fields are pre-populated with the information already stored in the registry (the Identity value mentioned in my original question).

This works well enough, as it creates the WLAN connection using the PEAP credentials. And by moving User Logon dialog offscreen as soon as it's found, this all happens invisibly to our application's user (our app runs in kiosk mode).

Answer 3

We've made positive experience with the wpa_supplicant project under Windows CE 5.0 and 6.0. I don't know whether it works under WM but I suppose it does.

The integration in our application required some efforts (i.e. creating a service around the wpa_supplicant core, disabling Zero Configuration driver). However, it was worth the effort: our application has full control over the whole configuration/association process.