Typically updates for wireless devices, such as cellular telephone handsets, are done in a factory or at an authorized service center because of the risk of downloading corrupted or malicious code, which could impact handset functionality and network provider revenue. As handsets move from a closed architecture environment to rich media and services, a method to enable new features, remedy bugs, update protocol code, and the like, in wireless devices is desirable.
Typically, such updates occur by receiving data packets at the communications portion of the device and providing the packets to an applications portion of the device for manipulation into a file, and then sending the file back to the communications portion. Because remote updates not done in a factory or service center are exposed to viruses, hacking and other malicious actions, methods to verify that a file came from a trusted source and that the file is not corrupted exist for the applications portion. However, updating the communications portion of the device is problematic. The communications subsystem does not have the processing power, code or data space to download and verify a full update in an autonomous fashion. Further, it would not be practical for the communication subsystem to include flash management, file-system support, cryptographic and other security capabilities, as multiple such code portions would exist in the wireless device, potentially causing conflicts, compatibility, resource, and implementation issues. Thus a need exists for a communications subsystem to verify that an update is trusted autonomously from the applications subsystem. Further, to enable updates, upgrade a device, remedy bugs, or to upgrade a communications portion of a device outside of the service center or factory (e.g., over-the-air (OTA)), a non-spoofable method of verifying the trust state of the applications subsystem is required.