Regular readers of this blog, (although I don’t rank on the Google 500 index I believe there are at least some people out there feeding off my rss), may be tempted to believe I’m playing my records on repeat when I bring up even more OMA, and yet again mentioning Windows Mobile in the same sentence. But previously I’ve only briefly mentioned some of the challenges involved. This time I thought I’d try and tackle some of these challenges. Maybe even solve a few

Ok, quick recap. OMA CP can be used to configure devices by sending SMS messages to them. But a lot of people have been struggling getting this to work on Windows Mobile. And since OMA CP is often used for setting up an OMA DM relationship that hasn’t really taken off on WM either. (Which does make it extra interesting that a product like System Center Mobile Device Manager from Microsoft uses OMA DM as it’s MDM engine.)

Read previous posts for more background info:
http://mobilitydojo.net/2008/10/10/whats-this-oma-dm-thingy-all-about/
http://mobilitydojo.net/2009/05/07/oma-dm-one-step-at-a-time/

So, with all the wonderful MDM platforms out there why spend time over this particular feature? Well, while I’ve previously explained why I don’t consider SMS messages a good method for continous MDM I do see how it might help in a couple of very specific scenarios:

• Initial client deployment
• Remote wipe
• Out-of-band communications channel for when you want to send credentials or something in separate channels.

I’d like to get one particular disclaimer out of the way first; I’m testing on Windows Mobile 6.1. I know that things are different of Windows Mobile 5.0, and possibly things described here will not work on those devices. WM 6.0 is similar to 6.1, and identical on many levels, but I’m not making any guarantees. WM 6.5? Haven’t tested it yet. I tested the HTC X7510 and HTC Touch Diamond 2 so it’s not a large sample pool I’ve tested with. (Lesson to take away – don’t trust anything until you have tested it on your particular device.)

This complexity has helped build a common misconception that OMA CP and OMA DM doesn’t work on Windows Mobile at all, and that MSFT are trying hard not to follow standards. And you’ll often observe that when seeing those annoying ring tone commercials they’ll list a plethora of different devices that are supported, but Windows Mobile is usually absent from that list. (OMA CP are often the basis for triggering download of content.) But at the same time you find references to OMA CP all over the MSDN documentation regarding the Configuration Service Providers. What gives?

Since Windows Mobile was designed primarily with the enterprise market in sight security was not an afterthought. Trust is a major concern in different aspects of the OS. You cannot install an unsigned application without being prompted that you acknowledge the installation. With a two-tier lock level on the device you may not even be able to install unsigned apps at all. If you want to synchronize with an Exchange server using SSL you need to trust the issuer of the SSL certificate. It kind of follows that bytes received from the Internet are not necessarily considered trustworthy either. So when receiving binary SMS messages containing configuration the device pays special attention to these (as opposed to a regular text message). If I send off random configuration messages to random devices these should not consider me trusted under most circumstances. In a very sane manner the logic states that to be able to perform configurations you must be trusted by the device. Who gets to define this trust, you say in a paranoid manner?

Nokia devices (and a whole lot of other manufacturers too of course) are simple in the sense that if you buy a Nokia it is a Nokia. With a Windows Mobile device the logo might say HTC, or Samsung, or xyz. And an HTC device might be branded to an operator like Orange, T-Mobile, etc in addition to the “straight” HTC models. Microsoft didn’t want to go into the hardware business with Windows Mobile, and that’s ok, but in the process they left a couple of implementation details to other players, while providing the overall design and guidelines from Redmond. At this point the concept of security roles, and security policies comes into play. Depending on what the policy definitions say on the device, different roles get to perform different things to my device.

For a primer on the security roles you should skim through:
http://msdn.microsoft.com/en-us/library/bb416273.aspx

And the relevant security policies:
http://msdn.microsoft.com/en-us/library/bb737247.aspx
(The interesting policies being: 4104, 4105, 4108, 4109, 4110, 4111, 4113, 4121, 4124, 4132, 4141, 4142 & 4143)

Now, this all makes sense. If I initiate something on the device it’s trusted. If I initiate something on the server side it may or may not be trusted. Orange devices have been “tampered with” so that the software certificate of Orange is preinstalled on the device. The SMSC of Orange is defined as a Trusted Provisioning Server. Pretty much all Qtek devices I saw in the European markets had Brightpoint and Dangaard root certs preinstalled. (Editor’s note: this would be the distributor of the non-operator branded devices.) Which means that whoever made the device available for me as a consumer had all the necessary rights to do whatever they want to my device. Which is nice. For them that is. Different models, and ROM builds, may have different settings. MSFT provides some default values, but the OEM is free to change the defaults. As a reference this is a registry snapshot of the emulator:
HKLM\SECURITY\Policies\Policies

(Values in hex, convert to decimal to line up with the SecurityPolicy DDF on MSDN.)

So how do I get the server initiated config to be trusted when I am not in a position where I get to decide the contens of the OS ROM? (I accept that MobilityDojo.net being a one-man operation does not have that power yet.) Finally we are getting to the point of the matter.

There’s disabling trust checking as much as possible on the device. I don’t know if all the checks can be disabled though. It would require you to touch the devices too, so while you’re at it you would probably be better off just enabling the trust relationship. And if you have access to touch every device before the user gets it there’s really not many limits to what you can do. But we want “zero touch deployments”.

A better solution would probably be to send the trust request in the first OMA CP message, have the user accept it interactively, and then you should be able to do your stuff. Let’s try that approach. A quick copy-paste from MSDN (msdn.microsoft.com/en-us/library/ms889523.aspx), and a minor adaptation, and we end up with the following xml:

<?xml version="1.0"?>
<!DOCTYPE wap-provisioningdoc PUBLIC "-//WAPFORUM//DTD PROV 1.0//EN"
"http://www.wapforum.org/DTD/prov.dtd">
<wap-provisioningdoc>
  <characteristic type="BOOTSTRAP">
    <parm name="PROVURL" value="http://www.mobilitydojo.net/TPS" />
  </characteristic>

  <characteristic type="PXLOGICAL">
    <parm name="NAME" value="WAP Push Gateway"/>
    <parm name="PROXY-ID" value="10.10.10.10"/>
    <parm name="TRUST"/>
    <characteristic type="PXPHYSICAL">
      <parm name="PHYSICAL-PROXY-ID" value="Push Gateway 1"/>
      <!-- The push gateway's SMS address -->
      <parm name="PXADDR" value="1234"/>
      <parm name="PXADDRTYPE" value="E164"/>
      <parm name="PUSHENABLED" value="1"/>
      <parm name="TO-NAPID" value="SMS NAP"/>
    </characteristic>
  </characteristic>

  <characteristic type="NAPDEF">
    <parm name="NAPID" value="SMS NAP"/>
    <parm name="NAME" value="SMS Connection"/>
    <parm name="NAP-ADDRESS" value="1234"/>
    <parm name="BEARER" value="GSM-SMS"/>
  </characteristic>
</wap-provisioningdoc>

A couple of pointers:

Type whatever you like in the dns name. (Apparently this does not matter as long as you’re only doing pushing from the server. If the device is to connect back to fetch data it probably would matter.)

The phone number is whatever you define as the from address in your Kannel. So once you bootstrap a device you should stick to the same phone number. It does not have to be an actual phone number, and the fictitious “1234″ above should work.

To test the procedure I sent out the following xml to disable WLAN (this one also requiring the user to accept it just be sure while testing):

<wap-provisioningdoc>
  <characteristic type="NetworkPolicy">
    <characteristic type="WiFi">
      <characteristic type="Settings">
        <parm name="Disabled" value="1"/>
      </characteristic>
    </characteristic>
  </characteristic>
</wap-provisioningdoc>

Hey, ho, that works!

Here’s a few screenshots showing it device side:

Accepting the message.

You’ll get a message in the SMS inbox saying that the config was applied.  

Oh, yeah, maybe I should add a few lines regarding what I’m doing in Kannel as well. OMA CP for Windows Mobile works much the same way as for the Nokia I used for my previous test runs. Do an HTTP GET against http:/kannel:13000/sendota?etc. I use “userpin” for authentication here. You cannot bootstrap without a security mechanism. What’s the difference between userpin and networkpin you say? (If you’ve read some of the MSDN links content that is.) Userpin is a code you define, and the user has knowledge of. For instance the user is provided with the pin 1234 in a separate text message sent first, or provided on a self service portal. The network pin is not readily available as this is the IMSI of the SIM card (on GSM devices, on CDMA it’s the ESN). The IMSI can be acquired programatically, but that’s usually the only way you’re going to get it. Most SIM cards have a long number printed on them, and while that is an identifying number it is usually not the IMSI. If you are the mobile operator you can do a database lookup inputing either the phone number or the IMEI of the device, but for some reason the mobile operators usually don’t expose an API for this to the general public

The bonus of the network PIN is that it will let you do further actions silently, and without user interaction. (I had some problems with this. I managed to get the device to accept the message without prompting the user, but for some reason it wouldn’t accept the settings. Haven’t looked further into why this isn’t working.)

With OMA CP in place you should probably be able to bootstrap the OMA DM server too. Haven’t tested it yet though. Let me know if it’s of interest – I have no idea if these Kannel related articles are playing to an audience of more than a few geeks with similar niche interests