Chinaunix首页 | 论坛 | 博客
  • 博客访问: 5175645
  • 博文数量: 1696
  • 博客积分: 10870
  • 博客等级: 上将
  • 技术积分: 18357
  • 用 户 组: 普通用户
  • 注册时间: 2007-03-30 15:16
文章分类
文章存档

2017年(1)

2016年(1)

2015年(1)

2013年(1)

2012年(43)

2011年(17)

2010年(828)

2009年(568)

2008年(185)

2007年(51)

分类: 嵌入式

2010-08-18 17:48:43

Application Deployment essentials for VS2005 device application developers - Part II

Here is my second blog post in the series on deployment related issues. So as to keep my blog small and easy to read,  I will just concentrate on Windows Mobile Smartphone application security from the perspective of VS2005 developers.  The remaining issues will be covered in the next blog post.

1. How Deployment to Smartphone is different from PocketPC? - It differs in two important aspects i) typically Smartphone devices have less memory and less powerful cpu compared to PocketPC devices. This translates to more time required to connect and deploy compared to PocketPC.  ii) Windows Mobile Smartphone devices by default are governed by 2-tier security model which restricts what could be deployed and run whereas PocketPC devices by default support 1-tier open security model which doesnt put any restrictions.  It should be noted here that Windows Mobile 5.0 allows to enable Smartphone security model on PocketPC devices too.

2. What is Windows Mobile Smartphone application security model in a nut shell? - Windows mobile application security model is based on digital signing.  This is to protect end-user's devices by not allowing the user to install applications from an unknown source. 

A Smartphone has two types of certificate stores: privileged and unprivileged.  A digital certificate present in privileged certificate store of the device is considered a privileged certificate.  Similarly, a digital certificate present in unprivileged certificate store is considered an unprivileged certificate.  It should be noted here that there is nothing special about a privileged certificate.  Based on the certificate with which an application is signed it is categorized as: privileged app, unprivileged app or unsigned app.

Security configuration of a Smartphone is determined by the following four security policies or registry settings:

  1. Can unsigned applications run?
  2. Prompt or No-Prompt - Whether user be prompted when an unsigned application attempts to run
  3. 1 or 2-tier device - Is the device 1-tier or 2-tier.  In 1-tier any code that can run is fully trusted. In 2-tier code can run either as trusted or normal.  A trusted process can all any API without any security restrictions whereas a normal process is forbidden from calling certain APIs.  Note that PocketPC supports only 1-tier mode.
  4. RAPI disabled, allowed or restricted - What rights desktop application have when making RAPI calls. Restricted means desktop application can do what an end-user could do.

The values of the above security policies define a security configuration.  There are five standard security configurations.

  1. Locked - unsigned apps cannot run, no-prompt mode, 1 or 2-tier, RAPI is disabled
  2. Third-party Signed - unsigned apps cannot run, no-prompt mode, 1 or 2-tier, RAPI is disabled
  3. 2-tier Prompt - unsigned apps can run, prompt mode, 2-tier, RAPI is restricted
  4. 1-tier Prompt - unsigned apps can run, prompt mode, 1-tier, RAPI is restricted
  5. Security Off - unsigned apps can run, no-prompt mode, 1-tier, RAPI is allowed.

Let us consider an example here for better understanding.  In 2-tier prompt configuration: applications signed with privileged certificate run as trusted, applications signed with unprivileged certificate run as normal, unsigned application result in a prompt and answering "yes" to the dialog makes the application run as normal.

Note here that it is possible to set a Smartphone to a non-standard security configuration.  For example, unsigned apps cannot run, no-prompt mode, 2-tier, RAPI is allowed or restricted.

3. Why do I need to bother knowing about Smartphone application security? How does it impact application deployment and the application itself? - VS2005 depends on RAPI to bootstrap Windows Mobile devices.  Bootstraping prepares a device for connectivity (eg TCP/IP).  If the security configuration is such that RAPI calls are disabled,  VS2005 cannot bootstrap such a device and hence connectivity will fail.  For example, devices which are either Locked or Third-party Signed cannot be used for development with VS2005 as RAPI is disabled in these configurations. 

For TCP/IP connectivity and debugging, VS2005 deploys few components on the device.  These components needs to run as fully trusted and hence needs to be signed with privileged certificate.  Therefore, on a 2-tier device, the device side components needs to be signed with a privileged certificate.  But how can a developer obtain a digital certificate which is already installed on the device in privileged store? VS2005 ships with a couple of test certificates along with its SDK for development purpose.  By default all the device side components that VS2005 deploys on the device are shipped pre-signed with privileged SDK certificate.  To use a Smartphone device that is 2-tier, user has to manually install SDK certificates on the device.  SDK certificate cab (sdkcerts.cab) can be found under the folder "C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SDKTools" assuming VS2005 is installed on C: drive. To install this cab on the device, copy it manually using ActiveSync and execute it on the device. 

It is worth mentioning here that by default SDK certificates are pre-built into the emulator and hence developers need not install them. Also, alert readers might have noticed that on a Security Off device SDK certificates need not be installed.

Okay, VS2005 is taking care of signing the components that it requires for connectivity and debugging. Doesnt the user application and other components it depends on need to be signed? The answer to this depends on i) whether user application is using API that needs privileged access or ii) whether security configuration doesnt allow unsigned apps to run.  In case (i) without code signing, both deployment and application launch will succeed, but privileged API calls will fail. In case (ii) without code signing, deployment succeeds but application launch will fail.  Then how can I sign my application?  VS2005 supports Athentic Code Signing feature exposed through project properties under "Athenticode Signing" category.  By default code signing is off.  One needs to turn on the code signing and specify a certificate to be used.  For development purpose we can use SDK test certificates for signing.  These certificates needs to be imported into desktop certificate store before using them.  If VS2005 is installed under C: drive, test certificates (TestCert_*.pfx) can be found under the folder "C:\Program Files\Microsoft Visual Studio  8\SmartDevices\SDK\SDKTools\TestCertificates".  Importing of test certificates too can be done through VS.  Depending on the requirement, either a privileged or unprivileged certificate could be selected.  Once the code signing is turned on, rebuilding the project automatically signs the application executable with the selected certificate.

Alert reader might have guessed that what gets installed on device are (sdkcerts.cab) public key certificates and on desktop (TestCert_*.pfx) are private key certificates.

4. Where can I find more details on Windows Mobile application security? - In my future blog posts I will try to cover some of the finer aspects of application security which VS2005 developers needs to be aware of.  Meanwhile, here are a couple of links for enthusiastic developers to explore.

The below link leads to an article that explains how application security worked in Smartphone 2003 devices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/smartphone_security.asp

The following link explains Windows Mobile 5.0 security model which is supported by PocketPC 2005 and Smartphone 2005 devices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/wmsecurity.asp

Time for me to stop here.  Check this space for more next time.
阅读(647) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~