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.
Note
The DM server account cannot have more roles than those of the bootstrap message, and it cannot configure a role that it doesn't have.
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.
.gif "Bb737391.security(en-us,MSDN.10).gif")
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.