MEDC 2005: Security model changes
Notes from CLI320 – Security and device configuration
The smartphone security model has been in place from the original Smartphone 2002 version. It was originally designed to proved a flexible protection layer primarily to give Mobile Operators the confidence to allow these general purpose devices onto their network. The flexible design has since proved very useful for enterprises customers to restrict application to those approved by the organization. It has the added benefit of protecting consumers from the anonymous spread of viral applications.
Windows Mobile 5.0 adds very little to the Smartphone security model (I will highlight these later). This release of the operating system is about levelling the playing field between Pocket PC and Smartphone, with the Pocket PC getting a 1 tier implementation of the security model that is set in the ‘prompt’ mode by default.
1 tier security means that an application either runs fully trusted (called the ‘TRUSTED’ code group) or doesn’t run at all. The basic principal is this: every application code block (DLL, EXE, ActiveX control, COM object, managed code component etc.) is checked for a digital signature by the OS application loader. If a signature is present, the on-device certificate store is scanned for the presence of that cert or a root of that cert. If its found then the application is marked considered ok to run. If the application is not signed, or the signature us not recognised then the user is prompted to allow or deny load of that module. If the user says ‘yes’ then the code runs in the Trusted code group. On-device policy can be set to change the behaviour in many ways: for example an enterprise can provision a new certificate to the device and change the policy so the user is not prompted, but the unsigned or unrecognised modules silently fail to load. Alternatively the policy can be set to silently allow all modules to load and run in the Trusted code group.
Smartphone has a 2 tier security model which adds a second certificate store and a concept of Normal code group which has restricted API access (e.g. SIM manager, kernel functions etc.).
MSDN has a bunch of docs that describe this in much more detail. Here is one by James Pratt that covers the basics.
Anyway, back to the session…
Samim talked about a couple of changes effecting both PPC and Smartphone:
1> Device drivers are now subject to signing. A device driver *must* resolve to the Trusted code group in order to load on the device. This also applies to registered services as well.
2> The default mode for remote connection is now Restricted: there are three levels available open, restricted and closed. In Restricted mode several functions are not available. It’s possible to call remote DLL entry points in Restricted mode but the DLL must be signed correctly.
Pocket PC gets new UI for dealing with unsigned messages, the ‘toast’ popup message appears across the bottom of the screen rather than popping down from the top.
This was a good session and I attended one of the panel sessions on security as well, that went into quite a bit more detail and looked at some of the future features in this area. Samim always draws a link between the trust process involved in running code and the trust process we go through before purchasing and consuming food… good stuff, but it was late and after skipping lunch, the last half an hour was pure torture!
Marcus