A lot of people don’t know it, but there is a way to deploy Enterprise Line of Business (LOB) applications to employee iPhones without using the Apple appstore.  It definitely has its caveats.  But, it’s worth knowing about.

If your company has 500 or more employees, you can buy an iPhone “Enterprise” developer license.  It’s a bit more then the “Standard” individual and company licenses, but not much.  For more on developer licenses, go here.

Once you have the license, you can sign your LOB apps with your certificate and provision them to company devices.  “Enterprise” developer licensing allows what is called “Universal” application provisioning.  This is the same type of provisioning that is granted to applications deployed through the Apple Appstore and allows deployment of the application to any iPhone on the face of the Earth.

Wow, so with a developer license, you can deploy an app to any iPhone out there without going through the appstore….WRONG!  The “Enterprise” developer license EULA that you accepted dicatates that you are only allowed to deploy apps to iPhones operated by employees of your company.  Deployment to any other iPhones is illegal.  And, I’m absolutely sure that Apple is not going to stand by and let you break the law.

Well, you can deploy your LOB app to your company users and that’s the important thing, right?  At this point, you may be wondering how you go about deploying the application to the employee-operated iPhone.  There are currently two ways to do it.  Use the iPhone Configuration Utility (iPCU) or use Apple iTunes.  Both methods are described in the Apple iPhone Enterprise Deployment Guide.

The caveat here is that neither iPCU or iTunes app deployment can be performed directly between the iPhone and a server.  Both iPCU and iTunes are desktop applications that run on either a Mac or Windows machine.  But, they do support two different scenarios.  iPCU is best if you want to setup a bulk number of iPhones with your LOB before giving them to the user.  iTunes is better for deployment of the app or on-going updates when the iPhone is already in the user’s hands.

When deploying the LOB app, you have to get your Enterprise Developer License .mobileprovision file installed on the iPhone before you can install a .app file.  You can deploy the .mobileprovision file using desktop management that you may have deployed in your network to offload this task from the user.  When the iPhone is connected to the desktop running iTunes, the .mobileprovision file will be deployed.  Then the user must add the .app to their app library and select to install it on their iPhone.

Hello from sunny LA.  Yes, all the natives thought they had seen a pre-halloween ghost when this seattle native hit the streets for the Microsoft Professional Developers Conference 2008 (PDC2008).  As usual, Microsoft has some new, cool products and technologies in the developer space that hit in a big way.  You’ve probably been seeing headlines covering Windows 7 and Microsoft “Azure”. 

Here is my very short, sweet summary of this new stuff.  First, Windows 7:

• Winows 7 will fix all that stuff that caused negative reviews on Vista. 
• It also has a lot of great, new shell features that will positively impact the experience for the everyday user.  Just the taskbar improvements alone are pretty cool.
• UAC will still be there, but in a more flexible format for configuration and they have decided to except more operations from prompting.  However, Microsoft continues to be hardcore about forcing all apps to the do the right thing and operate under “standard user”.  The stats do show that most developers are getting the message and a lot of progress has been made.  As a user, UAC drives me up the wall.  As a security person, it’s the right thing to do.

The more exciting (to me) and new technology has to do with the new Microsoft services strategy which includes “Azure” and the “Geneva” server.  This technology will catalyze  two, important business scenarios that really need to get over the hump:  (1) B2B connectivity in which there are many enmeshed partners sharing a workflow and (2) hosted services for enterprises (not just small orgs).

Microsoft has a big cloud in the sky and plays traffic cop for all services that register to the Microsoft “Services bus”.  But, the bus supports some serious authentication and authorizatio through use of WS federation and SAML tokens.  And, part of the offering is SQL services which equates to a SQL DB that is up in the cloud and protected by the aforementioned authentication and authorization.  So, you can support some great B2B scenarios:

• Partners that all need access to a workflow, but need a slightly different type of data for the same workflow transactions
• Partners that all use a different directory or authentication type can still positively identify into one cloud
• Eventing enables store and forward of transactions when one particular partner connectes to the service.

If you are a small company and you are interested in advertising your service, click into the Microsoft service bus and you just go a free advertisement to services consumers.

But…that’s not all.  The biggie is Geneva because it creates a super easy to setup and configure Enterprise Service connector for Active Directory.  This could enable hosting of an internet-based service to a company with an internal Active Directory.  There is a question here of whether the company will accept the Microsoft EULA for connecting to the Services bus and whether their security policy will accept their authentication getting proxied through the Microsoft Federation Gateway in the cloud.  But, the good news is that all the authentication against the hosted service is handled by the Microsoft Service Connector which is located on the company premises.  It reminds me a little bit of ADSI, but better.  If the company doesn’t want to accept the Microsoft EULA, they can set up a B2B direct to their partner ( the hosting provider) who will have the Federation Gateway  (Geneva) handling “claims”.

We still have 1.5 more days here, but I think all the big news has already popped.

Dave Field, CISSP, MCP

A lot of Enterprise Software for Mobile devices utilizes SSL for security.  SSL is the de facto choice because it can traverse NATs and routers whereas many VPNs cannot.

So, you’ll need to purchase an SSL certificate for your web server and any Windows Mobile clients should have the root of your SSL certificate in the device’s root certificate store. 

The problem comes when the root certificate is not already in the device root certificate store by default.  You can add certificates to the root store (this got a lot easier in Windows Mobile 6.0).  But, this will likely require a user trying to perform the task or the support tech will need to “touch” the device.  And, if the device is cold reset, you have to perform this task all over again.  It is much easier just to use an SSL server certificate from a Public Certificate Authority  that chains to a root certificate that’s already resident on the device.

Unfortunately, Windows Mobile has no root certificate updating service as included in Windows XP and Windows Vista.  With Windows Mobile, you get the root certifcates that were added when the image was built.

If you are using Windows Mobile 5.0 devices, you should not use GoDaddy or Comodo root certificates for the most part.   Here is a table showing which versions of Windows Mobile includes which Public CA certificates:

Another consideration is the use of wildcard certificates.  As you probably already know if you are reading this, a wildcard certificate allows the use of a wildcarded DNS name prefix such as “*.acme.com”.  You can use the same SSL certificate for many different web servers that all have assigned DNS names that end in “.acme.com”.  It is important for SSL security that the server’s internet DNS name matches the subj or subj alt name on the certificate.  So, if you wildcard th prefix in the certificate, you can use one cert for a lot of servers.

Windows Mobile started supporting wildcard certificates in Windows Mobile 6.0.  If you have Windows Mobile 5.0 devices, you should take a look at the offering from Digicert.  They allow you to pre-populate the subj alt name of the certificate with a list of server names.  This ends up giving you something approaching wildcard certificate features.  However, you do need to know the internet DNS names of all the web servers you’ll be using.  See more details on the Digicert site. Note that digicert is not shown on the list above because they actually chain back to the Entrust root.

Dave Field, CISSP, MCP
Device Management and Security Architect
Enterprise Mobile, Inc.

It is a well know fact that a lot of enteprise IT pros require data encryption for mobile devices.  The Windows Mobile operating system has included support for the Data Protection API (DPAPI) since Windows Mobile 2003.  And DPAPI forms the basis for Windows Mobile file encryption used with removable storage cards (Windows Mobile 6.0) and main memory (Windows Mobile 6.1). 

DPAPI provides easy-to-use functions for encryption and decryption.  A number of applications use DPAPI.  The thing that makes DPAPI easy to use for developers is that they don’t have to wite all the key generation and key management code that typically goes with any encryption solution.  DPAPI uses a master key that is stored in the memory of the device.  When an application calls DPAPI, the same master key is used to generate symmetric keys for all encryption and decryption operations.  In this way, the application does not have to generate or manage the encryption key used.  For a thorough description of DPAPI see the MSDN article covering Windows Data Protection

Of course, this begs the question, “How is the master key protected?” Read the rest of this entry »

Here is the follow-up installment #2 on device emulator configuration.  You may want to read installment #1 first.

I often need to test our code across various versions and SKUs of Windows Mobile.  For instance, I need to test one feature across WM 5.0 Smartphone, WM 5.0 Pocket PC Phone Edition, WM 6.0 Standard, WM 6.0 Professional and, of course, the newer WM 6.1 SKUs.

When testing, you often want to use a hard/cold booted device for the most reproducible results.  Cold booting and then reconfiguring a bunch of devices is super time consuming.  Even if using the device emulator, configuration can be time consuming. Read the rest of this entry »

The following is the first of 2 installments that describe how I use Windows Mobile Device Emulators. This installment covers setup and basic use while the second installment covers configuration.

A lot of people test and demo Windows Mobile devices using actual devices. This works fine for most scenarios. However, there are some distinct advantages to using device emulators:

• The device emulators are free as they come with the Windows Mobile SDKs.
• If you use a device emulator for your demo, you don’t need to use an Elmo overhead projector to show what’s happening on the device.
• You can pre-configure a device emulator, save the pre-configured state and quickly “reset” the emulator back to the pre-configured state. This is a real time saver for both demoing and testing.
• You can test across multiple versions of the Windows Mobile Operating System simultaneously on one PC

If I’ve convinced you that the device emulator is worth setting up, follow these steps. Read the rest of this entry »

The Windows Mobile device management platform supports two different Open Mobile Alliance (OMA) standards: OMA Client Provisioning (OMA CP) and OMA Device Management (OMA DM). By the say, OMA CP is the new name for WAP Provisioning. So, when you see Windows Mobile configuration XML with the root node of <wap-provisioningdoc>, you know you are using OMA CP.

Because Windows Mobile supports both OMA CP and OMA DM, you’ll find that MSDN documentation for most Windows Mobile Configuration Service Providers will include information on configuration XML for both standards. OMA DM is suppose to be the new, improved standard (and it is in many ways). So, you may wonder why OMA CP support is still included. Read the rest of this entry »

Here is a little issue that I researched this week and I thought I’d share it on the blog.

PROBLEM: When accessing a website that is secured to use an NTLM authenticated password, the “Save Password” option does not work on Windows Mobile Pocket PCs and Smartphones.

Here are detailed steps that outline how to reproduce this problem using a Motorola/Symbol MC70 Pocket PC. Note that the test device was running Windows Mobile 5.0 AKU3. Read the rest of this entry »