OMA Device Management Security Best Practices

4/8/2010

Windows Mobile Version 5.0 and later supports Open Mobile Alliance Device Management (OMA DM). The DM client in the device supports the following security features:

• Secure HTTP transport over SSL. The SSL includes server certificate based authentication, data integrity check, and encrypted transport channel

• Device management application level Basic and MD5 client authentication

• Device management application level MD5 server authentication

  Note

  MD5 server authentication messages need to include all the elements in the OMA Device Management Security specification including LocURI and LocName. The OMA Device Management Security specification (OMA-TS-DM_Security-V1_2-20070209-A) is available from this OMA Web site.

• Authenticating server notification trigger

• Windows Mobile security role-based access control

The security roles of the DM server account are the same as the bootstrap message unless they are explicitly set by using Role parameters.

The security roles for the DM server are assigned as follows:

• If the DM server is bootstrapped at manufacture, the server is assigned all roles implicitly.
• When bootstrapping a DM server account over the air (OTA) or through Remote API (RAPI), the DM server roles are set to the Role parameter of the server account, as described in DMAcc Configuration Service Provider and w7 APPLICATION Configuration Service Provider.

Security Best Practices

• Security roles for the DMACC Configuration Service Provider and the DMS Configuration Service Provider should be synchronized
  The DMAcc Configuration Service Provider and DMS Configuration Service Provider share the same data store, Having different roles could result in elevated privileges. The roles for each should be the same.

• Transport over Secure Sockets Layer (SSL)
  The OMA DM implementation requires SSL transport over HTTP with the OMA DM server. Without SSL, information on the device that the OMA DM server can access is vulnerable to interception from a malicious party.

  The SSL must provide server certificate-based authentication, data integrity check, and encrypted transport channel authentication.

  OMA device management transport client will enforce using SSL transport connecting to the server).

• The OMA DM server should authenticate the DM client using either Basic or MD5 authentication at the application level
  The following table shows the ways OMA DM server can authentication the client.

  Authentication type	Description
  MD5	An MD5 one-way hashing algorithm used for authentication.
  Basic	Based on the model that a client must authenticate itself with a user name and password for each realm. Security Note: Basic authentication provides weak security unless the transport channel is first link-encrypted with SSL or Transport Layer Security (TLS) 1.0.

• For the server notification trigger, use MD5 hashed with the DM server credential
  The server notification Short Message Service (SMS) message that is sent from the server to initiate a DM session is signed with MD5 server credential. The DM client authenticates the server notification message by calculating the message's MD5 digest using the configured server credential, and then compares it with the MD5 hash received in the message.

• Renew the server MD5 nonce in each DM session
  To ensure that the nonce is renewed for each DM session, the DM client sends the new server nonce for the next session to the server over a Status element in every DM session.

  The device does not challenge the server if the server does not send MD5 credentials. In this case, the next nonce is sent to the server using a success SyncHdr Status element.

  The DM server that supports OMA DM version 1.2 can support a nonce resynchronization request per the OMA DM specification OMA Device Management Security (OMA-TS-DM_Security-V1_2-20070209-A) available from this OMA Web site. By default, nonce resynchronization is not turned on for Windows Mobile devices. You can turn it on when you bootstrap the device with DM server access information. For more information about nonce resynchronization, see OMA DM MD5 Authentication Nonce.

• Use role-based access control
  Access control is done using the Windows Mobile 2003 role-based access control. It only applies to OTA provisioning. The settings exposed in the device user interface (UI) do not conform to these controls.

  In the standard DM account object, you should use the Role setting to specify the Security Roles for the DM server. If the role is not configured explicitly over provisioning XML, the default security role is the one assigned to the DM account object configuration message. The role specified in this setting is a subset of configuration message roles.

  Read-Write permission and access security roles for each configurable setting can be managed over the Microsoft custom properties RWAccess and AccessRole in an OMA DM session. For more information about these settings, see Metabase and OMA DM.

  The following list shows the control:

  • Remotely, if the device is bootstrapped to allow OMA DM server as the device manager, TPS server has the MANAGER role. For more information, see Bootstrapping To Use An OMA DM Server.
  • Locally, RAPI through desktop depends on the RAPI setting:
    0 = Blocked
    1 = Open; A request over MAPI has the MANAGER role
    2 = A request has USER_AUTH role
  • The role for DMProcessConfigXML API depends on the application that calls it and security model. In two tier device, Privileged has the MANAGER role. NORMAL has USER_AUTH role. In a one tier device, application that is allowed to be run at the device has MANAGER.
  • For a Cab Provisioning Format (.cpf) file, it depends on the signature of the .cab file. The SPC store is used to assign security roles to certificates.
  • During the boot process, the .provxml file is interpreted with the MANAGER role.

  For information about security roles, see Security Roles.

See Also

Reference

Security and Managing Devices

Other Resources

OMA Device Management
Security Roles