B L A C K B E R R Y M 2 M S O L U T I O N S A Comparison of Protocols for Device Management and Software Updates In the last two decades, the number of connected computing devices has grown at a staggering rate. One of the biggest challenges that individuals and corporations now face is how to manage and update these devices in a secure, efficient, and convenient way. The extension of mobile communication into new industries and verticals such as the automotive industry brings new opportunities for operational efficiencies and customer satisfaction. Selecting the right protocols to manage and update software in these devices in ways that are tailored to the specific needs of the industry becomes mission critical. In this White Paper, OMA DM, BBF TR069, UPnP-DM, and BlackBerry protocols for updating and managing computing devices, for verticals such as automotive, will be compared. Security, scalability, interoperability and efficiency of each solution will be briefly considered and the rich feature set of the BlackBerry protocol will be summarized. White Paper
OMA DM Protocols Open Mobile Alliance (OMA) Device Management (DM) protocols include a feature for Firmware Updates that uses the Firmware Update Management Object (FUMO). We will discuss the security, scalability, and efficiency of this solution, as well as the OMA DM standards working group factors of version 1.2.1. About SyncML and FUMO Originally designed for basic device provisioning, the OMA DM protocols have been amended to attempt to cover more requirements from the industry. The OMA DM solution is based on the Synchronization Markup Language (SyncML). Initially, SyncML wasn t under the control of the OMA organization, but SyncML was later absorbed by the OMA working groups. SyncML was designed for transmitting data elements between the client and server and has been largely unchanged for about a decade. The base DM protocols contain all of the necessary components to allow clients and servers to exchange data elements in a hierarchical tree. Each version of the DM protocol and each of the versioned management objects includes base-level features. Sessions are always initiated by the client, either as a result of a device-side condition or as a result of a server sending a push message to the client. The protocols are versioned and can be implemented by any organization. The FUMO object contains two required items: an URL to download a single firmware image, and an execute command, which signals the client to start the firmware download and update process. The firmware image can be placed directly in a data element in the FUMO tree, but this isn t typically used, except in the case of very small firmware images. All other custom features and data elements must be added as custom nodes to the DM tree. Any custom business logic associated with these custom data elements requires pre-existing server and/or client-customized support. Security Transport-layer security can be accomplished using the normal SSL and TLS cipher suites. This provides encryption, but not authentication of both endpoints. Security for OMA DM transactions is limited to username:password combinations or HMAC-MD5 for authenticity verification. The HMAC-MD5 effectiveness is highly dependent on the server and client implementations. If one or the other isn t rotating the nonce values on a prudent schedule, then the strength of the solution is drastically diminished. Moreover, not all servers and clients have implemented solid security models of the nonce rotation. Scalability The DM protocol requires that the synchronization of data elements in the DM tree be sequenced in order to ensure that all of the relevant data is on the device before certain commands are executed. These data elements can be synchronized within a single session between the client and server, but no session is guaranteed to be 100% reliable. A broken session can leave a client in an incomplete state regarding the required set of data elements that need to be synchronized. For a feature to work correctly, if there are dependencies required, each server session with a client needs to ensure the state of the DM tree. For example, if a firmware update is targeted at a specific device and there are custom nodes that contain extra data elements that aren t specified in the FUMO object, then all of the custom nodes would need to be verified, and possibly synchronized, before the FUMO EXEC command could be issued to the client. It s exactly this type of scenario that makes for complex server-scalability solutions when more than one DM server instance is required. For large device populations, it s not possible to vertically scale a single DM server high enough to handle high-transaction loads. Large-scale deployments need to be able to scale vertically, horizontally, geographically, and cost effectively. BlackBerry has recently worked with some cellular operators that have experienced DM server overloads and crashes due to normal day-to-day traffic loads that they weren t able to effectively scale for. The protocol wasn t designed for large-scale operations with high-transaction rates. Interoperability Interoperability within the DM protocol isn t guaranteed. There has been no industry-wide interoperability test session in over 4 years. Typically, OMA DM vendors try to mitigate this by including provisions in their contracts stating that they will perform interoperability testing with other vendors. Sometimes this testing includes server interoperability or client interoperability, and sometimes it requires server vendors to integrate each other s solution with their own before testing interoperability. This last case doesn t offer fully independent interoperability. In the past, the OMA DM group organized regular test fests to encourage hands-on interoperability testing. The last full multivendor test fest was May 22, 2009, which suggests that successful interoperability seems unlikely.
Efficiency In general, the SyncML protocol is a chatty protocol. This means that there are numerous messages sent back and forth between the client and server as part of synchronizing data elements within a tree. The SyncML protocol isn t well suited to resource-constrained environments where bandwidth and power are limited. In this context, the cellular networks are considered a resource-constrained environment. Cellular networks have limited throughput, a limited number of simultaneous data streams, and limited numbers of connected clients. There are more desirable solutions than OMA DM 1.2.1. The OMA DM working group has acknowledged that the solution space is in need of a more efficient protocol. While there are several options being researched and proposed, nothing is finalized at the moment. Any changes would break backwards compatibility with existing protocol versions and thus all existing clients and servers will continue to rely on 1.2.1 protocol communications. Based on the feedback from companies that have deeply invested in 1.2.1, we don t expect rapid adoption of a new version of the protocol. The OMA DM protocols are designed by committee and anyone can join the working group. As with most open standards where companies have competing interests, only the features that are the lowest common denominator are accepted by all of the parties. The FUMO feature appears to be in such a situation, as it only supports a single firmware image and an execute command. All other related business logic or data must be added in by the DM servers and DM clients; however, any custom business logic breaks the interoperability goals of DM. For more information about the OMA DM protocol, see http://openmobilealliance.org/about-oma/work-program/device-management BBF TR069 and UPnP-DM Protocols There are other protocols that are capable of remotely managing software updates for connected devices. In general, these protocols aren t designed for wirelessly connected or resource-constrained environments. Also, these protocols weren t designed for hundreds of millions of connected devices. Most of these protocols have been targeted at wired and broadband domains where bandwidth and speed are sufficiently available and the population sizes are far smaller than the millions needed by large domains. We won t discuss these protocols in detail due to their limiting design factors, but more information is available from the following resources: BBF TR069: http://www.broadband-forum.org/certifiedtr069.php UPnP-DM: http://upnp.org/specs/dm/dm1/ BlackBerry Protocols About the BlackBerry Software Update Management service The Software Update Management service is a solution that is specifically designed to provide the highest levels of industry standardized security models, to support the configuration of software and delivery of updates to hundreds of millions of connected computing devices, and to provide a rich set of base features in a single protocol. The BlackBerry Software Configuration and Management protocol suite is a set of XML payloads delivered over HTTP sessions between the client and server. Sessions are always initiated by the client, either as a result of a device-side condition or as a result of a server sending a push message to the client. Compressed binary versions of the protocol are also available. The protocols are versioned and can be implemented by any organization. Additionally, the solution also provides support for OMA DM 1.2.1 and the FUMO management object. Security Transport layer security can be accomplished by using the normal SSL and TLS cipher suites. This provides encryption, but not authentication of both endpoints. For authentication, BlackBerry supports using digital signatures or lesser-grade authentication using sets of identifiers that are unique to the endpoints. There are numerous cipher suites and bit strengths that have been standardized by the industry today. These range from vulnerable SHA-1 to common RSA to bitfriendly Elliptic Curves.
By default, the level of security used by the BlackBerry solution is 521 bits of elliptic curve, although other cipher suites and bit levels are available, depending on the client needs. Each transaction that a client has with the server is digitally signed using an ECDSA-521 key pair. This is the equivalent of about 16,000 bits of RSA. To put this into perspective, today most online banking transactions use a maximum of 2048 bits of RSA. By using ECDSA-521 (521 bits), not only is the cipher strength extremely strong, but it s also extremely efficient to transmit over wireless bearers. This has the benefit of consuming less bandwidth and requiring less storage space on the client device. When managing millions of devices that need to be communicated with in a short period of time, the benefit of 521 bit signatures versus 16,000 bit signatures (a 30 times reduction in bits) can be immediately appreciated in a wireless medium. The trade off is a higher computational cost to verify the signature on the client, compared to other cipher suites. BlackBerry values high security and high integrity in its solutions, especially when wireless bearers are involved in the network topology. The strength of the cipher suite must be balanced with the client needs, wireless consumption constraints, and power consumption rates. Scalability and efficiency A device management solution must be able to handle large amounts of clients and high-transaction rates. Clients can t be completely controlled to yield a perfectly uniform distribution of transactions; peaks and valleys of incoming load are inevitable. The BlackBerry solution and protocol is designed to minimize the required state management on the server side. The benefit here is that a client can connect to any server at any time anywhere in the BlackBerry Device Management cloud around the world. The server will be dynamically chosen by the BlackBerry Infrastructure only when the client initiates a session with BlackBerry. Parameters such as geographic location, server availability, and server load can be used to route clients to an appropriate server. This type of design allows for the efficient and automatic handling of incoming traffic load as necessary. The client side of this design doesn t need to have any awareness or business logic to make this feature work. Simple client designs are highly desired, as this allows server-side changes to affect behavioral changes and feature updates with little or no client changes. To support this type of server-side architecture, the entire cloud must have access to all of the data all of the time. Highly reliable and high-speed data management across the cloud is a nontrivial problem to solve, but is extremely valuable for customers with millions of computing devices to manage. Updating a firmware image isn t sufficient in today s mobile computing environments. It s not enough to manage a single firmware image that is applied homogenously to all clients with no customization or policy management. It s often desirable to have a rich set of control options when a fleet of devices needs to be modified. For example, updating the firmware for one hundred million devices as fast as possible would be an unmitigated disaster for any wireless network and all up-stream infrastructures. Some of these controls will be completely managed by the servers, but some control points need to be communicated to the clients so that they can act out the constraints and rules using local data. Every version of the BlackBerry Software Configuration and Management protocol has several control features included in them. All of the data that the client needs to know about will come in a single digitally signed response. This creates very efficient use of bandwidth, which translates to shorter transactions and faster response times to the device user. For example, a firmware update is eligible for one hundred million clients, but some clients will be told that their update also includes Priority #1 security updates, while others will be told that their updates are to be performed silently (in the background). All of the clients are also told that they will be subject to download rules based on battery levels on the device. By having all of the customizable data within the same response message, there isn t a need to have extended back and forth chatter with the server to communicate all of the related policies and controls associated with the command being executed. Splitting out the data into multiple messages leads to complex sequencing and distributed transactions that must be managed and performed by all of the servers in the cluster in order to guarantee the consistency and accuracy of the data on the device. This would make cloud-based stateless servers where clients could connect to any device in the cloud a near impossibility, and therefore would severely limit scalability and reliability. BlackBerry takes the former approach of including all of the relevant data for the command in the same single-server response to the device. If there are custom data elements above what the base features support, these data elements are also included in the single-server response.
Summary There are several protocol suites that are capable of managing connected devices and in particular, managing software updates for connected devices. All of the protocols that weren t designed for wirelessly connected devices or large population sizes don t meet the needs of large-scale software update solutions. The OMA DM protocols have desirable goals, but have limited security and authentication options, limited base features, chatty SyncML underpinnings, and challenging interoperability issues. These protocols are simply not as capable as BlackBerry needs them to be. The BlackBerry Software Configuration and Management protocols are designed and controlled by BlackBerry, but any vendor can implement their own client, provided that the client adheres to the protocol. For basic updates and for interoperability, the OMA DM 1.2.1 and FUMO protocols can be suitable when it is not known which backend will be managing and updating the device, and when there is a need to support multiple backends, such as when vendors delegate software update rollouts to wireless service providers. However, in cases where an OEM requires end to end control of the rollout to its entire fleet of devices, the BlackBerry Software Configuration and Management protocols are comprised of a rich feature set above and beyond simple monolithic firmware updates. This feature set includes significantly higher security solutions, policy and control features specific to wireless networks, and highly scalable and reliable server deployment options. In a field where software updates aren t just simple monolithic images, security solutions need to live in the field for more than a decade, population sizes are in the millions, wireless awareness and control are involved, and custom work is likely needed from any vendor for any protocol for the customer needs, the best solution combines a basic interoperability with other backend services with the advanced features provided by the BlackBerry Software Updates and Management Service. The challenge in selecting the right protocol to use depends on an organization s requirements, and the complexity will vary based on those requirements. BlackBerry has designed its services and protocols to be interoperable, and can support a wide range of clients ranging in complexity from single protocols such a FUMO or BlackBerry to a more complex hybrid solution where both protocols are being used jointly. Keep your business moving: www.blackberry.com/m2m 2013 BlackBerry. All rights reserved. BlackBerry and related trademarks, names and logos are the property of Research In Motion Limited and are registered and/or used in the U.S. and countries around the world.