OMA Client Provisioning Security Best Practices
The device management client in the device includes the following security features for OMA Client Provisioning:
- For non-branded phone, 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 a mobile operator customized phone, .
- The trusted provisioning server (TPS) must send the OTA provisioning message through configured trusted 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 unsupported security features 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 2003 role-base access control. It only applies to OTA provisioning. The settings exposed in device user interface (UI) does not conform with 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 two tier device, Trusted 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 cab provisioning file (.cpf file), 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 user interface (UI).
For more information about security roles, see Security Roles.
See Also
Security and Device Management | OMA Client Provisioning Device Management | Security Roles
Send Feedback on this topic to the authors