End-To-End Security for Firmware Updates Whitepaper

End-To-End Security for Firmware Updates Whitepaper, v1.1 Version 1.1, OTAFF Page 2 2/1/2005 Table of Contents 1.1 Introduction.........................................................................................................3 1.2 Overview.............................................................................................................3 1.3 Rationale .............................................................................................................4 1.4 Reference Architecture and Diagram.................................................................. 6 1.5 Details of The Specification /Proposal .............................................................. 7 1.5.1 The Secure Provisioning of Information in Device .................................... 8 1.5.2 The Secure Delivery of Update Packages................................................... 8 1.5.3 The Secure Update Activity...................................................................... 16 1.5.4 The Secure Notification and Non-repudiation of Receipt ........................ 18 1.5.5 The Secure Ingestion of Update Packages into an Operator’s Network... 19 2 Recommendation ...................................................................................................... 19 Version 1.1, OTAFF Page 3 2/1/2005 1.1 Introduction To ensure successful firmware and feature updates, an operator’s network must be secure from end-to-end and include secure sessions between each network element. The following diagram describes a scenario in which updates are generated by OEMs, managed by operators and disseminated to customers within the operator’s network. 1.2 Overview This document discusses end-to-end security and considers all network elements involved in firmware updates. Protection of corporate applications, network elements and devices is very important. The Corporate IT department must be assured that user information will be secure and that corporate assets, such as servers and data networks, will not be compromised through the mobile data network by unauthorized intruders. Illegal activity Device OEM Customer Device Management Server Network Management Server /Test Server 1 2 3 4 OEM delivers package to operators’ network END-TO-END SECURITY Secure Secure Secure Operator delivers package to management server Operator protocol to deliver package to customer Customer satisfaction Version 1.1, OTAFF Page 4 2/1/2005 in networks can take the form of server spoofing, man-in-the-middle (MITM) attacks, malicious content or redirecting server access to unauthorized or illegal servers. Operators must develop solutions to address corporate security standards. Moreover, the network operator must make certain that its network cannot be compromised and its service cannot be interrupted as a result of attacks that involve devices that are susceptible through the update facilities. It is important to realize that there is often a difference between updating firmware and updating just another application in a device (that may probably be downloaded by other means). Secure delivery of update content is essential and critical to user privacy and to asset protection. Secure delivery within the network can occur, for example, from OEM’s to operators or from operators to devices. Various types of secure connections are likely to occur between carriers and vendors for content transfer, for example FTP over VPN or SSL-enabled web servers. In some business models, vendors own the servers and operators have access to them. End user device protection is a top priority when conducting firmware updates. . Implementing required package encryption could ensure the confidentiality of specified content, but may not ensure that content is appropriate for the designated device. If TLSliik protocols are considered for transport, for example, they use encryption but do not necessarily authenticate the client, making it possible to encrypt data and still have it delivered and parsed by inappropriate devices.. If client authentication is required, it may be supported at an application layer or in the transport itself. If server authentication is required, it can be easily provided at the transport layer. There are various means to achieve the desired level of security. These may be provided in addition to standard network security services. 1.3 Rationale Several reasons and rationales are listed below for secure end-to-end development and deployment of update packages. • Unauthorized servers o Hackers and malicious users continually attempt to corrupt computers networks, including wireless devices in the telecom industry. Operators need to ensure devices are conducting secure transactions with the designated content servers and that only authorized servers are allowed to manage the devices. Since the connection between the device and the server is such that the server has complete control over the device (by the way of allowing it to determine what runs as firmware on the device), a Version 1.1, OTAFF Page 5 2/1/2005 single transaction of a device with a fraudulent server leads to a complete and immediate compromise of the device. The scope of the effect is so wide that a compromised device may not be repaired using OTA connections and may require expensive physical handling. Moreover, compromised devices may cause immediate and long-lasting damage to the network, and a disruption of service to many subscriber devices could be caused by one compromised device. Due to this possible scope of damage, a system cannot afford even a single case of a device receiving updates from an un-trusted server. • Content authenticity o Each package delivered to individual devices should incorporate cryptographic means to ensure authenticity of the content. There is also a need to ensure that the content is appropriate for that device. Any other content that does not meet specified requirements for authenticity shall be discarded. • Device authenticity o Operators should have authentication methods for selecting the correct device before updates can occur. Devices that are not authenticated must not be allowed to access DM servers or download firmware updates in the operator’s network. Since updates may include licensed software and billing credentials, pushing an update should be treated similar to electronic financial transactions. This creates a requirement to authenticate the client that is critical not only from the network stability perspective, but also to ensure discrete, secure account and billing information. As financial transfers are always mutually authenticated, so should firmware updates. • User information o Subscriber privacy is critical to users as well as operators. All user information shall be secure during all update processes. An update of firmware should not lead to loss of user data, or loss of privacy of user data. • Operator information o The majority of operators currently have systems in place to protect any information about their networks and back end systems. It is very important to protect any operator information during this process. Version 1.1, OTAFF Page 6 2/1/2005 • Secure Notification o The notification to initiate firmware updates must include some means to authenticate the message, such as a MAC. Devices must be able to ignore notifications that seem to come from unauthorized or illegal servers. 1.4 Reference Architecture and Diagram The reference architecture encompasses following entities: • An operator’s network comprising: o a DM server, o a delivery server, and o a repository of update packages; • A device with: o a DM client, o an alternate download client, and o a firmware update agent; and • A generator that is used to generate update packages. In addition, the device optionally includes a SIM /Smart Card. The generator may be part of the operator’s network, and the repository may be part of the DM server. Version 1.1, OTAFF Page 7 2/1/2005 1.5 Details of the Specification /Proposal The specification of the end-2-end security solution addresses all of the following activities: • The Secure Provisioning of Information in a Device; • The Secure Delivery of Update Packages; • The Secure Update Activity; • The Secure Notification and Non-repudiation of a Receipt; • The Secure Ingestion of Update Packages into an Operator’s Network. Version 1.1, OTAFF Page 8 2/1/2005 1.5.1 The Secure Provisioning of Information in Device The provisioning process is one of the most critical pieces of feature updates. Operator and subscriber information is exchanged in this process, and therefore a reliable secure method should be considered. Most operators employ their RF network technology (CDMA, GSM etc.) as a means of securing voice and data provisioning. These applications may be sufficient, but others should be considered. Access to RF network security information is often not available to data communication means established to manage the devices. Secure bootstrap provisioning of a new device is an issue that will be handled by OMA DM. For firmware updates, the provisioning of a DM server is assumed to have been completed before a firmware update is initiated. Secure OTA bootstrap provisioning is a fundamental problem for which carriers have few options – the need to authenticate the server that is trying to provision an un-provisioned device exposes a “chicken and egg” problem. Smart Card based provisioning is perhaps a better option that can circumvent this. For example, a Smart Card may provision a device with the DMAcc object, or at least a URL to a DM server, such that the new device could communicate with the DM server to initiate provisioning. Note: In the TCP/IP world, URL-only provisioning can be vulnerable to attackers using either routing manipulations, or by DNS and cache poisoning, or active attacks. Even if the URL of the DM server is securely stored in a device, this cannot be considered as a security measure. In general, there are two secure initial provisioning options that operators have. These are provisioning using smart cards and provisioning using pre-existent secrets (keys). The pre-existent keys should fulfill a few basic requirements such as being unknown and being unable be discovered or deduced by opponents. Also, these pre-existent secrets have to be such that they allow for security association (SA) and key exchange between the client and the server. Other provisioning options, such as OTA client provisioning (OMA CP), OMA DM bootstrap provisioning seems to lack sufficient security. 1.5.2 The Secure Delivery of Update Packages To ensure an End-to-End Secure Delivery of Update Packages, it is important to identify each step and entities involved in the process. Version 1.1, OTAFF Page 9 2/1/2005 The first sensitive segment is between the software update provider and the OMA Device Management platform. The threats may be: • An official Software update provider could send a valuable update to a fake OMA DM platform; • A fake Software update provider could send a fake update to the official OMA DM platform; • Someone could intercept a valid software update transmission and use it on a device without paying for it; • Someone could modify a valid software transmission. The first two threats above are not limited to an OMA DM platform. These risks are relevant even if an operator is using any DM platforms. The last threat, of someone being able to modify a valid software transmission, is perhaps the biggest threat. By launching an attack on a single transaction, the attacker can introduce a backdoor (through malicious code) that will enable him to access each and every device in the system after this device gets the update from the legitimate server. Normally (by attacks on other links), an attacker has to compromise each device separately or design a complex distribution mechanism. In this case however, the distribution mechanism is already there for the attacker – by means of just one compromised transaction, the attacker gets to poison many devices. The countermeasures could be: • The Software update provider should be authenticated by the OMA DM platform before it receives update packages. Furthermore, the content delivery has to be protected by means that are cryptographically bound to the authentication process done. Otherwise, session hijacking can occur and this makes the authentication meaningless. Content delivery may not be a concern for operators who test their software extensively after delivery by a software update provider; • The OMA DM platform should be authenticated by the Software update provider before delivering update packages; • There should be as many certificates as different software update providers so that in the case where one could be revoked, there is no need to change the others. If each software provider has its own certificate (and therefore its own secret private key) then the software originator’s liability can be enforced and its association with the code it distributed cannot be repudiated. This is useful if this code ends up doing harm to the operators' assets. Also, having several copies of a private key is disastrous to security because, if the private key is leaked, and this is discovered, there is no way to know which link in the security chain was responsible, thereby making it difficult to fix; • Transmitted data should be signed with the software update provider's private key; Version 1.1, OTAFF Page 10 2/1/2005 • Transmitted data should be encrypted; and • The use of TLS /SSL 3.0 networks is recommended for interactions between an operator’s update package repository and a software update provider’s publishing system. It may also be noted that if both encryption and cryptographic authentication are applied, and are cryptographically bound, then there is no need for SSL or TLS. One easy and efficient implementation could be an SSL v3 connection with client authentication between the Software update provider and the operator’s update package repository or the OMA DM platform. A different certificate for each provider is also strongly recommended. A different certificate for different providers means a different private key for each provider, otherwise there is no liability and no way to make sure this key is indeed kept private. The last, but not the least, sensitive segment is between the OMA Device Management platform and the end user handset. Two phases for a Secure Delivery of Update Packages must be considered, between the OMA DM server and the OMA DM client: • Phase 1: Notification; • Phase 2: Package Delivery. 1.5.2.1 During the 1st phase (Notification): The transmitted assets could include: • Some information on the package: download server address and package reference; • Information about the client (identification, update agent version …); • Information about the server (server version …). Those following threats must be considered: • A fake notification message comes to the handset and carries false update parameters (data corruption). Or someone in the middle modifies a valid notification message; • A fake DM platform could send unsolicited requests to the device via a SMS Center; • A valid notification message is replayed to the same device by a fake server; • A valid notification message is sent to another device by a fake server; • Someone intercepts the notification message and steals sensitive information that could be reused for malevolent operations (ex: IMEI); • A fake handset receives a valid notification message (identity usurpation). Version 1.1, OTAFF Page 11 2/1/2005 The following countermeasures could be applied: • Message encryption. A different key must be assigned for each device; • Message signature by the server, checked on the device – a message digest sent with the notification message enables the device to verify the authenticity of the message, if it has the associated keys in the device; • Check on the device that the notification message has not been received more than once. This is an important point, also called "replay prevention" and it can be implemented by either using timestamps or by using nonces. Timestamps here can be of various sorts, some which rely on a secure clock on the device and some that don't. The notification should be one that cannot be used for other devices and/or at another time. Possible implementations: Considering handset capacities (resources are scarce in terms of processing power, memory or data length) it is difficult to give one algorithm or procedure recommendations. Some examples of implementation for CDMA and UMTS/GSM networks include: • Message signature using the procedure described in the "SyncML Notification Initiated Session" v1.1 document. Although this may use a weak secret; • Message encryption based on a symmetrical algorithm, with a shared secret. Refer to the "SyncML device management bootstrap" v1.1 – although again, this may be a weak secret; • DM platform authentication by the server could be enforced by applying login/password procedure as planned in SMPP 3.4, for instance. Below some examples of implementation only for UMTS/GSM networks: The machine which is in charge of the notification, initiates an update session by sending an SMS. There are two possible kinds of SMSs: • Secure SMS (following the 3GPP TS 03.48 specification) sent directly to the Smart Card – Need an application on the Smart Card to treat the message and to trig the process; • Unsecured SMS following the 3GPP TS 03.40 specification sent to the handset. And in this case, the SMS Center (SMSC) is responsible for the sending of the notification SMS to the right handset with the right unique keys. Version 1.1, OTAFF Page 12 2/1/2005 It is also important to note that software update could also be triggered manually (called Pull Update). Thus, all modes (Pull and Push Update) must be taken into account. There is one other option that may be useful and sometimes easier to implement. The insecure SMS bearer can be used in order to deliver a secure SMS (especially in terms of authenticity and integrity). This can be done by using the plain SMS mechanism to deliver a MAC or signature that is parsed and checked by the firmware update application itself. It may be the easiest solution because it does not require smartcards or any other secure SMS prerequisites. It does require keys on the device, but this is something that has to be there anyway for secure firmware update to be feasible. 1.5.2.2 During the second phase (Update Packages Delivery): The assets are: • Primarily, the package itself and the metadata for the package. The assets may also comprise of user data that may be sent back, as a response, during the update process. These following threats must be considered: • The download server is imitated by another illegitimate server and it sends either valid or invalid packages; • The package content is changed by someone in the middle (MITM); • The package content is stolen and played to another user who has not paid for it; • A fake client asks for a package it has not paid for; • An update package is tempered with after it has been delivered to the operator; • Someone (the user or someone else) may fake a response from his (or other) device; • A response data may be read by an adversary causing a privacy violation; • Responses can be replayed (by a device or some entity that captures it in the middle); and • An update package may be replayed to the same or other, unintended, devices. The following countermeasures could be applied: • Device detects that an update package has been tampered with ( by checking the package signature on the server, and on the device; • Package encryption. A different key must be assigned for each device; • Package request signature by the client, and checked by the download server. A different key must be assigned for each device for this signature. The client in the device needs to be capable of signing as well. The download server should verify that this client has paid for the package before delivering it. The signature has to Version 1.1, OTAFF Page 13 2/1/2005 also be protected against replays, and in extreme cases, also authenticate the user behind the device; • Response from a device should be encrypted because they may contain private data; and • Responses should be signed by the client in such a way that it cannot be replayed effectively, and cannot be taken out of context. Possible implementations: • WTLS Class 2 between download server and handset, for data encryption and server authentication. Note: WTLS certificates are scarce and experience in deploying them are rare. TLS in its wireless profile instead, is preferable. In general, a "transport layer security protocol which authenticates both ends of the connection, and which is believed to be secure, would suffice • SSL with mutual authentication 1.5.2.3 Some management and operational issues that need more deliberations: There are some unknown elements: • PKI deployment or not? How? Certificate Authority? • Encryption algorithm used for notification message encryption; • Encryption algorithm used for package encryption; • Signature algorithm used for notification message signature; • Signature algorithm used for package signature; • Signature algorithm used for Package request; • Encryption keys and Signature keys: distribution, installation and storage on devices. 1.5.2.3.1 PKI Deployment or not and how PKI should certainly be presented as an option that has many clear advantages, but since PKI deployment is tedious and often complex it should not be presented as the only solution. Certificate authorities (CAs)are an important part of PKI but are not necessarily required for FOTA. Using CAs implies using certificates that require certificate handling on devices, as well as CA relationships which introduce significant additional costs. If the relationship between the devices and the servers is constant and known at personalization time, there is no need for certificates at all (it is not discussed frequently for CA promotion reasons, but PKI can work well without certificates). If the relationship is not known during personalization, then certificates may be used, but they do not need to be CA certificates but other implementation-specific certificates. The advantages of Version 1.1, OTAFF Page 14 2/1/2005 these type of certificates is that they save the cost of involving an external CA and they may be in a format other than the common X.509 so their certificate handling can be made simpler. 1.5.2.3.2 Encryption algorithm used for notification message encryption, and for package encryption An algorithm which is secure for one use will also be secure for the other, just used in a different scheme. Moreover, since these algorithms will end up having to be implemented on the device, it may be wise to use as few of them as possible so as to not inflate the DM client too much. If we are encrypting more than 2000 bits, which is mostly the case, we should not use the asymmetric ciphers, if just for performance reasons. If we are using symmetric ciphers, AES is probably the best option: It is perceived as secure, it is approved by NIST (so it will be easier to get the products security certified, if the need ever arises) and it runs well even on resource constrained environments. 1.5.2.3.3 Signature algorithm used It should be possible to adopt one algorithm and use it in the various schemes for various signature needs. The only big question is whether we use symmetric or asymmetric techniques. This will determine if we use RSA/ECC or HMAC/MAC. Since the differences between these two are fundamental and have many implications it may be necessary to allow both and provide guidelines for each one. 1.5.2.3.4 Provisioning and storage of keys This is probably the toughest problem to solve. It may not be necessary to mandate a certain scheme or implementation, but rather, useful to provide examples of how this might be achieved effectively. 1.5.2.3.5 The Secure Delivery of Update Packages – Transport Issues There are three different options for secure delivery of update packages that apply to both the OMA DM server and the OMA OTA DL server: a) The client initiates a session over SSL transport or TLS 1.0(preferred mode); b) The client initiates a session over non-SSL transport, in which case the server should challenge the device for credentials; Version 1.1, OTAFF Page 15 2/1/2005 c) A variation to b) wherein the client initiates a session over non-SSL transport but also provides its credentials simultaneously with session initiation so as to save a round trip. The approach in a) is the preferred solution, unless the device is incapable of supporting SSL /TLS based transport. TLS 1.0 is as secure as SSL 3.0. 1.5.2.4 Security for Firmware Updates based on PKI A PKI based security architecture incorporating currently mature technology that has been used by millions of handset devices is proposed in this section. This approach requires the operator to be able to sign an update package that is delivered to the device and the device to be capable of determining if the digital signature on the update package is that of the operator. Also, this approach involves PKI for interactions between OEM and the Network Operator. 1.5.2.4.1 From OEM to Operator’s Network Each OEM is required to obtain a code signing certificate from an operator trusted certificate authority (CA). Alternatively, the keys can be negotiated without the involvement of a third party, such as a CA. Before an OEM submits its update package to an operator’s network, the OEM must digitally sign its package. An operator would reject any unsigned submission. With the requirement of an OEM to sign its code, this will guarantee that only authorized vendor code be recognized. It will also guarantee the data integrity of the update package. Thus preventing any hacker from modifying a legitimate code or submit bogus code to the operator’s network. When an operator receives an update package from an OEM, the operator will first check to see whether the package is from an authorized OEM, and then perform the data integrity check on the update package through the digital signature verification. If the data of origin and data integrity checks are successful, operators then sign the update package with its own signing key. This will mark that the operator approves the OEM’s update package and authorizes it to be distributed through the operator’s network. With the operator signing the OEM’s update package, the operator will have total control on which OEM’s update package will be distributed to its customers. NOTE: The signing of the update package employing Version 1.1, OTAFF Page 16 2/1/2005 an operator’s certificate at operator’s network can be orthogonal to the signing of the update package using an OEM’s certificate. 1.5.2.4.2 From Operator’s Submission server to Device Management Server When a network operator is satisfied with an OEM’s update package and is ready to distribute the code to its customers, the operator will move the OEM’s update package from the initial submission server, such as a staging server, to the operator’s device management server. By this time the OEM’s update package should be already signed with the operator’s signing key. When a device management server receives a package, it should conduct the data authentication and integrity check through signature verification process. 1.5.2.4.3 Secure Delivery of Update Packages from Operator’s Device Management Server to Customer Handset When an update package is available in the device management server, the device management server will send out a notification to its end-users. A notification must be signed with the operator’s signing key. When a handset receives a notification from its operator, the handset should check the authenticity, freshness of the notification and integrity of the notification through digital signature verification. Since a handset only trusts the operator’s signing key, only a package signed with the operator’s signing key can be authenticated by the handset. The handset only needs to make sure that the update package provided is appropriate for the device. 1.5.3 The Secure Update Activity The update package that is delivered to a device is typically consumed by an update agent. The update agent conducts (at a minimum) the following three security checks: • An appropriateness check to make sure that the update package is appropriate for the device; • An integrity check to ensure that the update package has not been tampered with; • A proof of origin check to make sure that the update package originated at the expected source; Version 1.1, OTAFF Page 17 2/1/2005 • An optional verification of the rights to consume an update package. 1.5.3.1 The Appropriateness Check The download agent or some client that downloads the update package shall conduct checks to ensure that the update package delivered is appropriate for the device. However, update packages may be communicated to the device by various means, some not as secure as others. Therefore, the update agent needs to ensure that the update package is appropriate for it just before it consumes it. Verifying that the Manufacturer, Model, and Version number associated with an update package is the same as that of the target device is the recommended practice. It may also be possible to compute the CRC of a set of memory banks by a client side agent and compare that to a CRC provided as metadata and verify that the update package is appropriate for the device. It is advisable to use secure hash functions such as SHA-1 (soon to be replaced by four SHA -2 functions) instead of CRC, if devices can support it. 1.5.3.2 The Integrity Check The update package needs to be checked to make sure that it has not been tampered with. Such tampering may occur during download or after download to the device. Thus, an integrity check would be necessary to make sure that the update agent does not consume corrupted update packages. An MD5 checksum, for example, may be employed to verify the integrity, although SHA-1 would be stronger. 1.5.3.3 The Proof of Origin Check Even if the update package is found to be appropriate and not tampered with, it is necessary to ensure that it came from the right /expected source. Thus, the verification of the source of the update package by the update agent is necessary. A message authentication code (MAC) may be employed to verify the proof of origin. Assuring proof of origin is imperative. It can be conducted either with MACs (as mentioned), or with HMACs or with asymmetric digital signatures. It is important to note that all mechanisms for proof of origin also protect against modification of content as a Version 1.1, OTAFF Page 18 2/1/2005 side effect. Thus, if proof of origin is obtained, there is no need for a separate integrity check. It is recommended that the Update Agent (the final consumer of the update packages) be responsible for verification of the source of the update package. For example, a digital signature of the update package should be verified by the Update Agent prior to consumption of the update package, such a digital signature created with a certificate of the OEM or the operator, as the case might be. 1.5.3.4 The optional verification of the rights to consume an update package DRM has been promoted (especially at OMA) as a standard for rights management. Typically, with DRM, a client that renders or consumes the content is expected to verify that the user has acquired rights to the content before rendering them. Assuming the content is always bound to a particular device, and assuming it is encrypted in a way that only that device can decipher it, and assuming the user has no access to the raw code objects, then we get the same property of DRM through other means that are less complicated to implement. Content which is usable only by the intended recipient and which cannot be copied (because it cannot be read or introduced into another device) is the goal and DRM is just one way to achieve it, with several other possible solutions. 1.5.4 The Secure Notification and Non-repudiation of Receipt Notifications to trigger client action, such as the download of firmware update packages, should be authenticated in order to eliminate spurious notifications that might lead to denial of service. It can lead to much more than denial of service -in some cases it can lead to excessive customer billing that may trigger general repudiation of connectivity transactions. The need to send a secure final notification from device to server is important to ensure that the server does not get spurious notifications form an illegal client device. Spurious notifications can come from legal devices as well; following illegal acts of a customer who wants to make the DM server think that an update has worked okay even though he prevented it from occurring. Finally, if billing is involved, the need to send a digitally signed receipt from device to server at the end of the firmware update is important for non-repudiation. Version 1.1, OTAFF Page 19 2/1/2005 1.5.5 The Secure Ingestion of Update Packages into an Operator’s Network Secure ingestion is the first critical process to package updates. Once an OEM has completed the generation of update packages, a secure process must be implemented to ensure that the update packages are delivered safely and with integrity to the operator’s network. Below are few protocols and secure connections that can be utilized: • VPN (Virtual Private Network); • Secure FTP (File Transfer Protocol); • SSH (Secure Shell). In addition, an SSL/TLS based communication network with mutual authentication can also provide the necessary secure means to transfer update packages or other content from an OEM’s system into the operator’s network. The Update Package Container (UPC), with digital signatures, may be used to securely communicate update packages with associated metadata from an OEM’s system (or an OEM’s generator) to a repository in the operator’s network. 2 Recommendation This following are the OTAFF recommendations on security issues for firmware update solutions. Security Issue Description Recommended Solution 1 Recommended Solution 2 OTA provisioning if /after a DM server is authenticated by client and the client has been authenticated by a DM server Pre-provision for CDMA and for devices with Smart Cards, Smart Card based provisioning (for GSM) The Secure Provisioning of Sync ML Access parameters Information in the Device Bootstrap Provisioning OTA Provisioning not recommended if DM server and DM client cannot be authenticated to each other Provision as part of a secure device personalization process either at the Version 1.1, OTAFF Page 20 2/1/2005 . manufacturer's site or when arriving at the operator's site. The Secure Delivery of Update Packages Between the Software update provider and the OMA Device Management platform VPN recommended, delivering a signed Update Package Container (UPC) Mutual Authentication between the Software provider by the OMA-DM platform, signed update packages delivered in UPC, SSL 3.0, or TLS recommended. Between the OMA Device Management platform and the end user handset -a) and b) below: The Secure Notification a) Notification A message digest for authentication sent with the notification message enables the device to verify the authenticity of the message. The digest has to be keyed, using a key that is specific to the device (either a secret key or a private key), and it needs to be bound to the message (not just to its contents), and also protected against replay. Message digest (or a MAC) and message encryption for confidentiality, (perhaps with based on a symmetrical algorithm, with a shared secret) b) Secure Update package Delivery Package with digital signature provided by server, signature checked by client on device Download using TLS or SSL transport for confidentiality and server authentication The Secure Update Activity a) Appropriateness Check Verifying that the Manufacturer. Model, firmware Version are appropriate Computing the Checksum (MD5 or CRC) of a set of memory banks and comparing to Checksum provided in metadata b) Integrity Check MD5 or other Checksum c) Proof of Origin Check digital signature a MAC, or an HMAC. Version 1.1, OTAFF Page 21 2/1/2005 d) Verification of the rights to consume an update package License check DRM (requires DRM client on device) Nonrepuddiatio of Receipt Digitally signed receipt delivered from device to DM Server