OMA Client Provisioning Security Best Practices

  • Article

4/8/2010

The device management client in the device includes the following security features for OMA Client Provisioning:

  • For non-branded phones, after the OEM changes certain security policy settings during manufacture, the device supports OTA bootstrap signed with both network and user personal identification numbers (PINs).
  • OTA bootstrap is disabled for phones customized by a mobile operator.
  • The trusted provisioning server (TPS) must send the OTA provisioning message through a configured privileged Push Proxy Gateway (PPG), and the PPG must authenticate the TPS (push initiator).
  • The device supports Windows Mobile security role-based access control.

The following list shows security features that are unsupported due to the nature of the OMA Client Provisioning protocol:

  • There is no end-to-end data integrity check (except OTA bootstrap).
  • There is no end-to-end encryption between client and server.
  • Authentication between device and server relies on network.

Security Best Practices

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

    The following list shows the control:

    • Remotely, if the device is bootstrapped to allow OTA OMA client provisioning as the device manager, TPS server is granted the MANAGER role.
    • Locally, RAPI through desktop depends on the RAPI setting:
      0 = Blocked
      1 = Open; A request over MAPI is granted the MANAGER role.
      2 = A request is granted USER_AUTH role
    • The role for DMProcessConfigXML API depends on the application that calls it and security model. In a two-tier device, Privileged has the MANAGER role and Normal has USER_AUTH role. In a one-tier device, an application that is allowed to be run has the MANAGER role.
    • For cab provisioning files (.cpf files), it depends on the signature of cab file. The SPC store is used to assign security roles to certificates.
    • During the boot process, provxml is interpreted with the MANAGER role.

    Read-write permission is enforced by all sources except settings exposed to the user interface (UI).

    For more information about security roles, see Security Roles.

  • Use security policies to set and control acceptance requirements for messages from push sources.
    All messages received by a push router are assigned the SECROLE_ANY_PUSH_SOURCE role.

    You can use the following security policies to specify whether the message will be accepted and, if it is accepted, what authentication is required before it can be successfully received.

    • OMA CP Network PIN Policy: Accepted messages must be signed with the network password or PIN.
    • OMA CP User PIN Policy: Accepted messages must be signed by the user's password or PIN.
    • OMA CP User Network PIN Policy: Accepted messages must be signed by the user's network password or PIN.

    This feature is backwards compatible with Windows Mobile Version 5.0.

    These policies on the Windows® phone can be read from the server and set or changed with OMA Client Provisioning.

    For more information, see Security Policy Settings.

See Also

Reference

Security and Managing Devices

Other Resources

OMA Client Provisioning
Security Roles