Authenticating a Windows Mobile 6 Device

Question

I have an application that runs on Windows Mobile 6 Professional PDA devices. The application is installed by browsing a url from the device and downloading a cab.

Users capture information in the application and this is then replicated back to a SQL 2005 server using merge replication and IIS v6.

Although the user needs to log into the application on the device anybody who knows the url could download and install. Also if you know a users password anyone with a device could update that users information.

I would somehow like to authenticate the devices either at the installation or replication stage (or both).

Is it possible to authenticate a device based on serial number or IMEI (mobile phone ID) number? Is there a way to load a certificate onto the device so only certificated devices are allowed to connect?

I want a system that is not too hard to implement and support. The users must be able to update their own devices and they are not very good at remembering complicate procedures or password.

Answer 1

One possible solution would be to send the unique device id as part of authentication. There's a post on using GetDeviceUniqueID on the Windows Mobile Team Blog.

You could store this unique id when the user first connect to the server and verify it prior to each merge.

This approach helps to ensure that the user logging in is doing so from their own phone. It solves the problem of a remote intruder downloading your program to their own phone and logging into a legitimate users account. Of course, if such an intruder has access to your users phone AND password, all bets are off.

Answer 2

You have conflicting requirements:

The users must be able to update their own devices and they are not very good at remembering complicate procedures or password.

and:

Also if you know a users password anyone with a device could update that users information.

If your users can only (barely) be expected to use a password, then you cannot expect to be able to protect in any case against anyone else who has their password.

There's no 'magic' authentication that will tell you a particular user or device is legitimate beyond what you provide.

You can password protect the download, you can load certificates, you can get the PDA information (and even the cellular information), but unless you add another authentication mechanism, at the end of the day all you've got is a password.

The password is your weakest link, and you seem to be indicating that you can't provide more strict access, but you somehow need it?

If you have another authentication channel (phone, email, SMS) then you can provide a more robust, meaningful authentication.

For instance, you could make your program operation dependent on a "public.key" file with a per-user public key that your server requires for use. Once the user logs in to your website, have them give you their phone number (so now you have the phone number and the password) and send an SMS with a link to a temporary download for the key. Make a new key for each user, keep their private key on the server, and encrypt (or at least authenticate) every transaction between the device and server using this key pair.

Now if someone else wants to pretend they are their user, they have to get that file in one of three ways:

• They take it directly off the PDA (they also need the password, as the public key should be protected by the user password)
• They get the user to request a new SMS link, and somehow get the link without having the phone
• They change the phone number and request a new SMS link

In any case, you are validating not only the password, but also an associate phone number. You can make it hard for users to change the phone number (validate against their email as well when they request a phone number change, have them call in, etc).

Of course you can do the same with other channels of communication, but users are getting more and more used to SMS authentication and download, so it isn't too much more hassle.

-Adam

Answer 3

You could generate slightly different cab file for every download. The only difference would be security token your application would use as user/password analogue. That should be a public key for real security.

You could send them SMS with a code each time they access your application.