US20120179917A1 - Code signing system and method - Google Patents

Abstract

A code signing system and method is provided. The code signing system operates in conjunction with a signed software application having a digital signature and includes an application platform, an application programming interface (API), and a virtual machine. The API is configured to link the software application with the application platform. The virtual machine verifies the authenticity of the digital signature in order to control access to the API by the software application.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims priority from and is related to the following prior applications: “Code Signing System And Method,” U.S. Provisional Application No. 60/234,152, filed Sep. 21, 2000; “Code Signing System And Method,” U.S. Provisional Application No. 60/235,354, filed Sep. 26, 2000; “Code Signing System And Method,” U.S. Provisional Application No. 60/270,663, filed Feb. 20, 2001; “Code Signing System and Method,” International (PCT) Application No. CA/01/01344 filed Sep. 20, 2001, and “Code Signing System And Method,” U.S. application Ser. No. 10/381,219, filed Mar. 20, 2003. The entire disclosure of each of the above-referenced applications are hereby incorporated by reference hereinto in their entirety.
BACKGROUND
• 1. Field of the Invention
• This invention relates generally to the field of security protocols for software applications. More particularly, the invention provides a code signing system and method that is particularly well suited for Java™ applications for mobile communication devices, such as Personal Digital Assistants, cellular telephones, and wireless two-way communication devices (collectively referred to hereinafter as “mobile devices” or simply “devices”).
• 2. Description of the Related Art
• Security protocols involving software code signing schemes are known. Typically, such security protocols are used to ensure the reliability of software applications that are downloaded from the Internet. In a typical software code signing scheme, a digital signature is attached to a software application that identifies the software developer. Once the software is downloaded by a user, the user typically must use his or her judgment to determine whether or not the software application is reliable, based solely on his or her knowledge of the software developer's reputation. This type of code signing scheme does not ensure that a software application written by a third party for a mobile device will properly interact with the device's native applications and other resources. Because typical code signing protocols are not secure and rely solely on the judgment of the user, there is a serious risk that destructive, “Trojan horse” type software applications may be downloaded and installed onto a mobile device.
• There also remains a need for network operators to have a system and method to maintain control over which software applications are activated on mobile devices.
• There remains a further need in 2.5G and 3G networks where corporate clients or network operators would like to control the types of software on the devices issued to its employees.
SUMMARY
• A code signing system and method is provided. The code signing system operates in conjunction with a software application having a digital signature and includes an application platform, an application programming interface (API), and a virtual machine. The API is configured to link the software application with the application platform. The virtual machine verifies the authenticity of the digital signature in order to control access to the API by the software application.
• A code signing system for operation in conjunction with a software application having a digital signature, according to another embodiment of the invention comprises an application platform, a plurality of APIs, each configured to link the software application with a resource on the application platform, and a virtual machine that verifies the authenticity of the digital signature in order to control access to the API by the software application, wherein the virtual machine verifies the authenticity of the digital signature in order to control access to the plurality of APIs by the software application.
• According to a further embodiment of the invention, a method of controlling access to sensitive application programming interfaces on a mobile device comprises the steps of loading a software application on the mobile device that requires access to a sensitive API, determining whether or not the software application includes a digital signature associated with the sensitive API, and if the software application does not include a digital signature associated with the sensitive API, then denying the software application access to the sensitive API.
• In another embodiment of the invention, a method of controlling access to an application programming interface (API) on a mobile device by a software application created by a software developer comprises the steps of receiving the software application from the software developer, reviewing the software application to determine if it may access the API, if the software application may access the API, then appending a digital signature to the software application, verifying the authenticity of a digital signature appended to a software application, and providing access to the API to software applications for which the appended digital signature is authentic.
• A method of restricting access to a sensitive API on a mobile device, according to a further embodiment of the invention, comprises the steps of registering one or more software developers that are trusted to design software applications which access the sensitive API, receiving a hash of a software application, determining if the software application was designed by one of the registered software developers, and if the software application was designed by one of the registered software developers, then generating a digital signature using the hash of the software application, wherein the digital signature may be appended to the software application, and the mobile device verifies the authenticity of the digital signature in order to control access to the sensitive API by the software application.
• In a still further embodiment, a method of restricting access to application programming interfaces on a mobile device comprises the steps of loading a software application on the mobile device that requires access to one or more API, determining whether or not the software application includes a digital signature associated with the mobile device, and if the software application does not include a digital signature associated with the mobile device, then denying the software application access to the one or more APIs.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a diagram illustrating a code signing protocol according to one embodiment of the invention;
• FIG. 2 is a flow diagram of the code signing protocol described above with reference toFIG. 1;
• FIG. 3 is a block diagram of a code signing system on a mobile device;
• FIG. 3A is a block diagram of a code signing system on a plurality of mobile devices;
• FIG. 4 is a flow diagram illustrating the operation of the code signing system described above with reference toFIG. 3 andFIG. 3A;
• FIG. 5 is a flow diagram illustrating the management of the code signing authorities described with reference toFIG. 3A; and
• FIG. 6 is a block diagram of a mobile communication device in which a code signing system and method may be implemented.
DETAILED DESCRIPTION
• Referring now to the drawing figures,FIG. 1 is a diagram illustrating a code signing protocol according to one embodiment of the invention. Anapplication developer12 creates a software application14 (application Y) for a mobile device that requires access to one or more sensitive APIs on the mobile device. The software application Y14 may, for example, be a Java application that operates on a Java virtual machine installed on the mobile device. An API enables the software application Y to interface with an application platform that may include, for example, resources such as the device hardware, operating system and core software and data models. In order to make function calls to or otherwise interact with such device resources, a software application Y must access one or more APIs. APIs can thereby effectively “bridge” a software application and associated device resources. In this description and the appended claims, references to API access should be interpreted to include access of an API in such a way as to allow a software application Y to interact with one or more corresponding device resources. Providing access to any API therefore allows a software application Y to interact with associated device resources, whereas denying access to an API prevents the software application Y from interacting with the associated resources. For example, a database API may communicate with a device file or data storage system, and access to the database API would provide for interaction between a software application Y and the file or data storage system. A user interface (UI) API would communicate with controllers and/or control software for such device components as a screen, a keyboard, and any other device components that provide output to a user or accept input from a user. In a mobile device, a radio API may also be provided as an interface to wireless communication resources such as a transmitter and receiver. Similarly, a cryptographic API may be provided to interact with a crypto module which implements crypto algorithms on a device. These are merely illustrative examples of APIs that may be provided on a device. A device may include any of these example APIs, or different APIs instead of or in addition to those described above.
• Preferably, any API may be classified as sensitive by a mobile device manufacturer, or possibly by an API author, a wireless network operator, a device owner or operator, or some other entity that may be affected by a virus or malicious code in a device software application. For instance, a mobile device manufacturer may classify as sensitive those APIs that interface with cryptographic routines, wireless communication functions, or proprietary data models such as address book or calendar entries. To protect against unauthorized access to these sensitive APIs, theapplication developer12 is required to obtain one or more digital signatures from the mobile device manufacturer or other entity that classified any APIs as sensitive, or from a code signingauthority16 acting on behalf of the manufacturer or other entity with an interest in protecting access to sensitive device APIs, and append the signature(s) to thesoftware application Y14.
• In one embodiment, a digital signature is obtained for each sensitive API or library that includes a sensitive API to which the software application requires access. In some cases, multiple signatures are desirable. This would allow a service provider, company or network operator to restrict some or all software applications loaded or updated onto a particular set of mobile devices. In this multiple-signature scenario, all APIs are restricted and locked until a “global” signature is verified for a software application. For example, a company may wish to prevent its employees from executing any software applications onto their devices without first obtaining permission from a corporate information technology (IT) or computer services department. All such corporate mobile devices may then be configured to require verification of at least a global signature before a software application can be executed. Access to sensitive device APIs and libraries, if any, could then be further restricted, dependent upon verification of respective corresponding digital signatures.
• The binary executable representation ofsoftware application Y14 may be independent of the particular type of mobile device or model of a mobile device.Software application Y14 may for example be in a write-once-run-anywhere binary format such as is the case with Java software applications. However, it may be desirable to have a digital signature for each mobile device type or model, or alternatively for each mobile device platform or manufacturer. Therefore,software application Y14 may be submitted to several code signing authorities ifsoftware application Y14 targets several mobile devices.
• Software application Y14 is sent from theapplication developer12 to thecode signing authority16. In the embodiment shown inFIG. 1, thecode signing authority16 reviews thesoftware application Y14, although as described in further detail below, it is contemplated that thecode signing authority16 may also or instead consider the identity of theapplication developer12 to determine whether or not thesoftware application Y14 should be signed. Thecode signing authority16 is preferably one or more representatives from the mobile device manufacturer, the authors of any sensitive APIs, or possibly others that have knowledge of the operation of the sensitive APIs to which the software application needs access.
• If thecode signing authority16 determines thatsoftware application Y14 may access the sensitive API and therefore should be signed, then a signature (not shown) for thesoftware application Y14 is generated by thecode signing authority16 and appended to thesoftware application Y14. The signedsoftware application Y22, comprising thesoftware application Y14 and the digital signature, is then returned to theapplication developer12. The digital signature is preferably a tag that is generated using a private signature key18 maintained solely by thecode signing authority16. For example, according to one signature scheme, a hash of thesoftware application Y14 may be generated, using a hashing algorithm such as the Secure Hash Algorithm SHA1, and then used with the private signature key18 to create the digital signature. In some signature schemes, the private signature key is used to encrypt a hash of information to be signed, such assoftware application Y14, whereas in other schemes, the private key may be used in other ways to generate a signature from the information to be signed or a transformed version of the information.
• The signedsoftware application Y22 may then be sent to amobile device28 or downloaded by themobile device28 over awireless network24. It should be understood, however, that a code signing protocol according to the present invention is not limited to software applications that are downloaded over a wireless network. For instance, in alternative embodiments, the signedsoftware application Y22 may be downloaded to a personal computer via a computer network and loaded to the mobile device through a serial link, or may be acquired from theapplication developer12 in any other manner and loaded onto the mobile device. Once the signedsoftware application Y22 is loaded on themobile device28, each digital signature is preferably verified with apublic signature key20 before thesoftware application Y14 is granted access to a sensitive API library. Although the signedsoftware application Y22 is loaded onto a device, it should be appreciated that the software application that may eventually be executed on the device is thesoftware application Y14. As described above, the signedsoftware application Y22 includes thesoftware application Y14 and one or more appended digital signatures (not shown). When the signatures are verified, thesoftware application Y14 can be executed on the device and access any APIs for which corresponding signatures have been verified.
• Thepublic signature key20 corresponds to the private signature key18 maintained by thecode signing authority16, and is preferably installed on the mobile device along with the sensitive API. However, thepublic key10 may instead be obtained from a public key repository (not shown), using thedevice28 or possibly a personal computer system, and installed on thedevice28 as needed. According to one embodiment of a signature scheme, themobile device28 calculates a hash of thesoftware application Y14 in the signedsoftware application Y22, using the same hashing algorithm as thecode signing authority16, and uses the digital signature and the public signature key20 to recover the hash calculated by thesigning authority16. The resultant locally calculated hash and the hash recovered from the digital signature are then compared, and if the hashes are the same, the signature is verified. Thesoftware application Y14 can then be executed on thedevice28 and access any sensitive APIs for which the corresponding signature(s) have been verified. As described above, the invention is in no way limited to this particular illustrative example signature scheme. Other signature schemes, including further public key signature schemes, may also be used in conjunction with the code signing methods and systems described herein.
• FIG. 2 is a flow diagram30 of the code signing protocol described above with reference toFIG. 1. The protocol begins atstep32. Atstep34, a software developer writes the software application Y for a mobile device that requires access to a sensitive API or library that exposes a sensitive API (API library A). As discussed above, some or all APIs on a mobile device may be classified as sensitive, thus requiring verification of a digital signature for access by any software application such as software application Y. Instep36, application Y is tested by the software developer, preferably using a device simulator in which the digital signature verification function has been disabled. In this manner, the software developer may debug the software application Y before the digital signature is acquired from the code signing authority. Once the software application Y has been written and debugged, it is forwarded to the code signing authority instep38.
• Insteps40 and42, the code signing authority reviews the software application Y to determine whether or not it should be given access to the sensitive API, and either accepts or rejects the software application. The code signing authority may apply a number of criteria to determine whether or not to grant the software application access to the sensitive API including, for example, the size of the software application, the device resources accessed by the API, the perceived utility of the software application, the interaction with other software applications, the inclusion of a virus or other destructive code, and whether or not the developer has a contractual obligation or other business arrangement with the mobile device manufacturer. Further details of managing code signing authorities and developers are described below in reference toFIG. 5.
• If the code signing authority accepts the software application Y, then a digital signature, and preferably a signature identification, are appended to the software application Y in step46. As described above, the digital signature may be generated by using a hash of the software application Y and aprivate signature key18. The signature identification is described below with reference toFIGS. 3 and 4. Once the digital signature and signature identification are appended to the software application Y to generate a signed software application, the signed software application Y is returned to the software developer instep48. The software developer may then license the signed software application Y to be loaded onto a mobile device (step50). If the code signing authority rejects the software application Y, however, then a rejection notification is preferably sent to the software developer (step44), and the software application Y will be unable to access any API(s) associated with the signature.
• In an alternative embodiment, the software developer may provide the code signing authority with only a hash of the software application Y, or provide the software application Y in some type of abridged format. If the software application Y is a Java application, then the device independent binary *.class files may be used in the hashing operation, although device dependent files such as *.cod files used by the assignee of the present application may instead be used in hashing or other digital signature operations when software applications are intended for operation on particular devices or device types. By providing only a hash or abridged version of the software application Y, the software developer may have the software application Y signed without revealing proprietary code to the code signing authority. The hash of the software application Y, along with the private signature key18, may then be used by the code signing authority to generate the digital signature. If an otherwise abridged version of the software application Y is sent to the code signing authority, then the abridged version may similarly be used to generate the digital signature, provided that the abridging scheme or algorithm, like a hashing algorithm, generates different outputs for different inputs. This ensures that every software application will have a different abridged version and thus a different signature that can only be verified when appended to the particular corresponding software application from which the abridged version was generated. Because this embodiment does not enable the code signing authority to thoroughly review the software application for viruses or other destructive code, however, a registration process between the software developer and the code signing authority may also be required. For instance, the code signing authority may agree in advance to provide a trusted software developer access to a limited set of sensitive APIs.
• In still another alternative embodiment, a software application Y may be submitted to more than one signing authority. Each signing authority may for example be responsible for signing software applications for particular sensitive APIs or APIs on a particular model of mobile device or set of mobile devices that supports the sensitive APIs required by a software application. A manufacturer, mobile communication network operator, service provider, or corporate client for example may thereby have signing authority over the use of sensitive APIs for their particular mobile device model(s), or the mobile devices operating on a particular network, subscribing to one or more particular services, or distributed to corporate employees. A signed software application may then include a software application and at least one appended digital signature appended from each of the signing authorities. Even though these signing authorities in this example would be generating a signature for the same software application, different signing and signature verification schemes may be associated with the different signing authorities.
• FIG. 3 is a block diagram of acode signing system60 on amobile device62. Thesystem60 includes avirtual machine64, a plurality of software applications66-70, a plurality of API libraries72-78, and anapplication platform80. Theapplication platform80 preferably includes all of the resources on themobile device62 that may be accessed by the software applications66-70. For instance, the application platform may includedevice hardware82, the mobile device'soperating system84, or core software anddata models86. Each API library72-78 preferably includes a plurality of APIs that interface with a resource available in the application platform. For instance, one API library might include all of the APIs that interface with a calendar program and calendar entry data models. Another API library might include all of the APIs that interface with the transmission circuitry and functions of themobile device62. Yet another API library might include all of the APIs capable of interfacing with lower-level services performed by the mobile device'soperating system84. In addition, the plurality of API libraries72-78 may include both libraries that expose asensitive API74 and78, such as an interface to a cryptographic function, andlibraries72 and76, that may be accessed without exposing sensitive APIs. Similarly, the plurality of software applications66-70 may include both signedsoftware applications66 and70 that require access to one or more sensitive APIs, and unsigned software applications such as68. Thevirtual machine64 is preferably an object oriented run-time environment such as Sun Micro System's J2ME™ (Java 2 Platform, Micro Edition), which manages the execution of all of the software applications66-70 operating on themobile device62, and links the software applications66-70 to the various API libraries72-78.
• Software application Y70 is an example of a signed software application. Each signed software application preferably includes an actual software application such as software application Y comprising for example software code that can be executed on theapplication platform80, one ormore signature identifications94 and one or more correspondingdigital signatures96. Preferably eachdigital signature96 and associatedsignature identification94 in a signedsoftware application66 or70 corresponds to asensitive API library74 or78 to which the software application X or software application Y requires access. Thesensitive API library74 or78 may include one or more sensitive APIs. In an alternative embodiment, the signedsoftware applications66 and70 may include adigital signature96 for each sensitive API within anAPI library74 or78. Thesignature identifications94 may be unique integers or some other means of relating adigital signature96 to aspecific API library74 or78, API,application platform80, or model ofmobile device62.
• API library A78 is an example of an API library that exposes a sensitive API. EachAPI library74 and78 including a sensitive API should preferably include adescription string88, apublic signature key20, and asignature identifier92. Thesignature identifier92 preferably corresponds to asignature identification94 in a signedsoftware application66 or70, and enables thevirtual machine64 to quickly match adigital signature96 with anAPI library74 or78. Thepublic signature key20 corresponds to the private signature key18 maintained by the code signing authority, and is used to verify the authenticity of adigital signature96. Thedescription string88 may for example be a textual message that is displayed on the mobile device when a signedsoftware application66 or70 is loaded, or alternatively when a software application X or Y attempts to access a sensitive API.
• Operationally, when a signed software application68-70, respectively including a software application X, Z, or Y, that requires access to asensitive API library74 or78 is loaded onto a mobile device, thevirtual machine64 searches the signed for an appendeddigital signature96 associated with theAPI library74 or78. Preferably, the appropriatedigital signature96 is located by thevirtual machine64 by matching thesignature identifier92 in theAPI library74 or78 with asignature identification94 on the signed software application. If the signed software application includes the appropriatedigital signature96, then thevirtual machine64 verifies its authenticity using thepublic signature key20. Then, once the appropriatedigital signature96 has been located and verified, thedescription string88 is preferably displayed on the mobile device before the software application X or Y is executed and accesses the sensitive API. For instance, thedescription string88 may display a message stating that “Application Y is attempting to access API Library A,” and thereby provide the mobile device user with the final control to grant or deny access to the sensitive API.
• FIG. 3A is a block diagram of acode signing system61 on a plurality ofmobile devices62E,62F and62G. Thesystem61 includes a plurality of mobile devices each of which only three are illustrated,mobile devices62E,62F and62G. Also shown is a signedsoftware application70, including a software application Y to which twodigital signatures96E and96F withcorresponding signature identifications94E and94F have been appended. In theexample system61, each pair composed of a digital signature and identification,94E/96E and94F/96F, corresponds to a model ofmobile device62,API library78, or associatedplatform80. Ifsignature identifications94E and94F correspond to different models ofmobile device62, then when a signedsoftware application70 which includes a software application Y that requires access to asensitive API library78 is loaded ontomobile device62E, thevirtual machine64 searches the signedsoftware application70 for adigital signature96E associated with theAPI library78 by matchingidentifier94E withsignature identifier92. Similarly, when a signedsoftware application70 including a software application Y that requires access to asensitive API library78 is loaded onto amobile device62F, thevirtual machine64 indevice62F searches the signedsoftware application70 for adigital signature96F associated with theAPI library78. However, when a software application Y in a signedsoftware application70 that requires access to asensitive API library78 is loaded onto a mobile device model for which the application developer has not obtained a digital signature,device62G in the example ofFIG. 3A, thevirtual machine64 in the device64G does not find a digital signature appended to the software application Y and consequently, access to theAPI library78 is denied ondevice62G. It should be appreciated from the foregoing description that a software application such as software application Y may have multiple device-specific, library-specific, or API-specific signatures or some combination of such signatures appended thereto. Similarly, different signature verification requirements may be configured for the different devices. For example,device62E may require verification of both a global signature, as well as additional signatures for any sensitive APIs to which a software application, requires access in order for the software application to be executed, whereasdevice62F may require verification of only a global signature anddevice62G may require verification of signatures only for its sensitive APIs. It should also be apparent that a communication system may include devices (not shown) on which a software application Y received as part of a signed software application such as70 may execute without any signature verification. Although a signed software application has one or more signatures appended thereto, the software application Y might possibly be executed on some devices without first having any of its signature(s) verified. Signing of a software application preferably does not interfere with its execution on devices in which digital signature verification is not implemented.
• FIG. 4 is a flow diagram100 illustrating the operation of the code signing system described above with reference toFIGS. 3 and 3A. Instep102, a software application is loaded onto a mobile device. Once the software application is loaded, the device, preferably using a virtual machine, determines whether or not the software application requires access to any API libraries that expose a sensitive API (step104). If not, then the software application is linked with all of its required API libraries and executed (step118). If the software application does require access to a sensitive API, however, then the virtual machine verifies that the software application includes a valid digital signature associated any sensitive APIs to which access is required, in steps106-116.
• Instep106, the virtual machine retrieves thepublic signature key20 andsignature identifier92 from the sensitive API library. Thesignature identifier92 is then used by the virtual machine instep108 to determine whether or not the software application has an appendeddigital signature96 with acorresponding signature identification94. If not, then the software application has not been approved for access to the sensitive API by a code signing authority, and the software application is preferably prevented from being executed instep116. In alternative embodiments, a software application without a properdigital signature96 may be purged from the mobile device, or may be denied access to the API library exposing the sensitive API but executed to the extent possible without access to the API library. It is also contemplated that a user may be prompted for an input when signature verification fails, thereby providing for user control of such subsequent operations as purging of the software application from the device.
• If adigital signature96 corresponding to the sensitive API library is appended to the software application and located by the virtual machine, then the virtual machine uses thepublic key20 to verify the authenticity of thedigital signature96 instep110. This step may be performed, for example, by using the signature verification scheme described above or other alternative signature schemes. If thedigital signature96 is not authentic, then the software application is preferably either not executed, purged, or restricted from accessing the sensitive API as described above with reference to step116. If the digital signature is authentic, however, then thedescription string88 is preferably displayed in step112, warning the mobile device user that the software application requires access to a sensitive API, and possibly prompting the user for authorization to execute or load the software application (step114). When more than one signature is to be verified for a software application, then the steps104-110 are preferably repeated for each signature before the user is prompted in step112. If the mobile device user instep114 authorizes the software application, then it may be executed and linked to the sensitive API library instep118.
• FIG. 5 is a flow diagram200 illustrating the management of the code signing authorities described with reference toFIG. 3A. Atstep210, an application developer has developed a new software application which is intended to be executable one or more target device models or types. The target devices may include sets of devices from different manufacturers, sets of device models or types from the same manufacturer, or generally any sets of devices having particular signature and verification requirements. The term “target device” refers to any such set of devices having a common signature requirement. For example, a set of devices requiring verification of a device-specific global signature for execution of all software applications may comprise a target device, and devices that require both a global signature and further signatures for sensitive APIs may be part of more than one target device set. The software application may be written in a device independent manner by using at least one known API, supported on at least one target device with an API library. Preferably, the developed software application is intended to be executable on several target devices, each of which has its own at least one API library.
• Atstep220, a code signing authority for one target device receives a target-signing request from the developer. The target signing request includes the software application or a hash of the software application, a developer identifier, as well as at least one target device identifier which identifies the target device for which a signature is being requested. Atstep230, the signing authority consults adeveloper database235 or other records to determine whether or not to trustdeveloper220. This determination can be made according to several criteria discussed above, such as whether or not the developer has a contractual obligation or has entered into some other type of business arrangement with a device manufacturer, network operator, service provider, or device manufacturer. If the developer is trusted, then the method proceeds atstep240. However, if the developer is not trusted, then the software application is rejected (250) and not signed by the signing authority. Assuming the developer was trusted, atstep240 the signing authority determines if it has the target private key corresponding to the submitted target identifier by consulting a private key store such as a target privatekey database245. If the target private key is found, then a digital signature for the software application is generated atstep260 and the digital signature or a signed software application including the digital signature appended to the software application is returned to the developer at step280. However, if the target private key is not found atstep240, then the software application is rejected atstep270 and no digital signature is generated for the software application.
• Advantageously, if target signing authorities follow compatible embodiments of the method outlined inFIG. 5, a network of target signing authorities may be established in order to expediently manage code signing authorities and a developer community code signing process providing signed software applications for multiple targets with low likelihood of destructive code.
• Should any destructive or otherwise problematic code be found in a software application or suspected because of behavior exhibited when a software application is executed on a device, then the registration or privileges of the corresponding application developer with any or all signing authorities may also be suspended or revoked, since the digital signature provides an audit trail through which the developer of a problematic software application may be identified. In such an event, devices may be informed of the revocation by being configured to periodically download signature revocation lists, for example. If software applications for which the corresponding digital signatures have been revoked are running on a device, the device may then halt execution of any such software application and possibly purge the software application from its local storage. If preferred, devices may also be configured to re-execute digital signature verifications, for instance periodically or when a new revocation list is downloaded.
• Although a digital signature generated by a signing authority is dependent upon authentication of the application developer and confirmation that the application developer has been properly registered, the digital signature is preferably generated from a hash or otherwise transformed version of the software application and is therefore application-specific. This contrasts with known code signing schemes, in which API access is granted to any software applications arriving from trusted application developers or authors. In the code signing systems and methods described herein, API access is granted on an application-by-application basis and thus can be more strictly controlled or regulated.
• FIG. 6 is a block diagram of a mobile communication device in which a code signing system and method may be implemented. Themobile communication device610 is preferably a two-way communication device having at least voice and data communication capabilities. The device preferably has the capability to communicate with other computer systems on the Internet. Depending on the functionality provided by the device, the device may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance or a data communication device (with or without telephony capabilities).
• Where thedevice610 is enabled for two-way communications, the device will incorporate acommunication subsystem611, including areceiver612, atransmitter614, and associated components such as one or more, preferably embedded or internal,antenna elements616 and618, local oscillators (LOs)613, and a processing module such as a digital signal processor (DSP)620. As will be apparent to those skilled in the field of communications, the particular design of thecommunication subsystem611 will be dependent upon the communication network in which the device is intended to operate. For example, adevice610 destined for a North American market may include acommunication subsystem611 designed to operate within the Mobitex™ mobile communication system or DataTAC™ mobile communication system, whereas adevice610 intended for use in Europe may incorporate a General Packet Radio Service (GPRS)communication subsystem611.
• Network access requirements will also vary depending upon the type of network919. For example, in the Mobitex and DataTAC networks, mobile devices such as610 are registered on the network using a unique identification number associated with each device. In GPRS networks however, network access is associated with a subscriber or user of adevice610. A GPRS device therefore requires a subscriber identity module (not shown), commonly referred to as a SIM card, in order to operate on a GPRS network. Without a SIM card, a GPRS device will not be fully functional. Local or non-network communication functions (if any) may be operable, but thedevice610 will be unable to carry out any functions involving communications overnetwork619, other than any legally required operations such as “911” emergency calling.
• When required network registration or activation procedures have been completed, adevice610 may send and receive communication signals over thenetwork619. Signals received by theantenna616 through acommunication network619 are input to thereceiver612, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and in the example system shown inFIG. 6, analog to digital conversion. Analog to digital conversion of a received signal allows more complex communication functions such as demodulation and decoding to be performed in theDSP620. In a similar manner, signals to be transmitted are processed, including modulation and encoding for example, by theDSP620 and input to thetransmitter614 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission over thecommunication network619 via theantenna618.
• TheDSP620 not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in thereceiver612 andtransmitter614 may be adaptively controlled through automatic gain control algorithms implemented in theDSP620.
• Thedevice610 preferably includes amicroprocessor638 which controls the overall operation of the device. Communication functions, including at least data and voice communications, are performed through thecommunication subsystem611. Themicroprocessor638 also interacts with further device subsystems or resources such as thedisplay622,flash memory624, random access memory (RAM)626, auxiliary input/output (I/O)subsystems628,serial port630,keyboard632,speaker634, microphone636, a short-range communications subsystem640 and any other device subsystems generally designated as642. APIs, including sensitive APIs requiring verification of one or more corresponding digital signatures before access is granted, may be provided on thedevice610 to interface between software applications and any of the resources shown inFIG. 6.
• Some of the subsystems shown inFIG. 6 perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. Notably, some subsystems, such askeyboard632 anddisplay622 for example, may be used for both communication-related functions, such as entering a text message for transmission over a communication network, and device-resident functions such as a calculator or task list.
• Operating system software used by themicroprocessor638, and possibly APIs to be accessed by software applications, is preferably stored in a persistent store such asflash memory624, which may instead be a read only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device software applications, or parts thereof, may be temporarily loaded into a volatile store such asRAM626. It is contemplated that received and transmitted communication signals may also be stored toRAM626.
• Themicroprocessor638, in addition to its operating system functions, preferably enables execution of software applications on the device. A predetermined set of applications which control basic device operations, including at least data and voice communication applications for example, will normally be installed on thedevice610 during manufacture. A preferred application that may be loaded onto the device may be a personal information manager (PIM) application having the ability to organize and manage data items relating to the device user such as, but not limited to e-mail, calendar events, voice mails, appointments, and task items. Naturally, one or more memory stores would be available on the device to facilitate storage of PIM data items on the device. Such PIM application would preferably have the ability to send and receive data items, via the wireless network. In a preferred embodiment, the PIM data items are seamlessly integrated, synchronized and updated, via the wireless network, with the device user's corresponding data items stored or associated with a host computer system thereby creating a mirrored host computer on the mobile device with respect to the data items at least. This would be especially advantageous in the case where the host computer system is the mobile device user's office computer system. Further applications, including signed software applications as described above, may also be loaded onto thedevice610 through thenetwork619, an auxiliary I/O subsystem62S,serial port630, short-range communications subsystem640 or any othersuitable subsystem642. Thedevice microprocessor638 may then verify any digital signatures, possibly including both “global” device signatures and API-specific signatures, appended to such a software application before the software application can be executed by themicroprocessor638 and/or access any associated sensitive APIs. Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using thedevice610, through a crypto API and a crypto module which implements crypto algorithms on the device (not shown).
• In a data communication mode, a received signal such as a text message or web page download will be processed by thecommunication subsystem611 and input to themicroprocessor638, which will preferably further process the received signal for output to thedisplay622, or alternatively to an auxiliary I/O device628. A user ofdevice610 may also compose data items such as email messages for example, using thekeyboard632, which is preferably a complete alphanumeric keyboard or telephone-type keypad, in conjunction with thedisplay622 and possibly an auxiliary I/O device628. Such composed items may then be transmitted over a communication network through thecommunication subsystem611.
• For voice communications, overall operation of thedevice610 is substantially similar, except that received signals would preferably be output to aspeaker634 and signals for transmission would be generated by a microphone636. Alternative voice or audio I/O subsystems such as a voice message recording subsystem may also be implemented on thedevice610. Although voice or audio signal output is preferably accomplished primarily through thespeaker634, thedisplay622 may also be used to provide an indication of the identity of a calling party, the duration of a voice call, or other voice call related information for example.
• Theserial port630 inFIG. 6 would normally be implemented in a personal digital assistant (PDA)-type communication device for which synchronization with a user's desktop computer (not shown) may be desirable, but is an optional device component. Such aport630 would enable a user to set preferences through an external device or software application and would extend the capabilities of the device by providing for information or software downloads to thedevice610 other than through a wireless communication network. The alternate download path may for example be used to load an encryption key onto the device through a direct and thus reliable and trusted connection to thereby enable secure device communication.
• A short-range communications subsystem640 is a further optional component which may provide for communication between thedevice624 and different systems or devices, which need not necessarily be similar devices. For example, thesubsystem640 may include an infrared device and associated circuits and components or a Bluetooth™ communication module to provide for communication with similarly-enabled systems and devices.
• The embodiments described herein are examples of structures, systems or methods having elements corresponding to the elements of the invention recited in the claims. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the invention recited in the claims. The intended scope of the invention thus includes other structures, systems or methods that do not differ from the literal language of the claims, and further includes other structures, systems or methods with insubstantial differences from the literal language of the claims.
• For example, when a software application is rejected at step250 in the method shown inFIG. 5, the signing authority may request that the developer sign a contract or enter into a business relationship with a device manufacturer or other entity on whose behalf the signing authority acts. Similarly, if a software application is rejected atstep270, authority to sign the software application may be delegated to a different signing authority. The signing of a software application following delegation of signing of the software application to the different authority can proceed substantially as shown inFIG. 5, wherein the target signing authority that received the original request from the trusted developer atstep220 requests that the software application be signed by the different signing authority on behalf of the trusted developer from the target signing authority. Once a trust relationship has been established between code signing authorities, target private code signing keys could be shared between code signing authorities to improve performance of the method atstep240, or a device may be configured to validate digital signatures from either of the trusted signing authorities.
• In addition, although described primarily in the context of software applications, code signing systems and methods according to the present invention may also be applied to other device-related components, including but in no way limited to, commands and associated command arguments, and libraries configured to interface with device resources. Such commands and libraries may be sent to mobile devices by device manufacturers, device owners, network operators, service providers, software application developers and the like. It would be desirable to control the execution of any command that may affect device operation, such as a command to change a device identification code or wireless communication network address for example, by requiring verification of one or more digital signatures before a command can be executed on a device, in accordance with the code signing systems and methods described and claimed herein.

Claims (30)

1. A method of controlling access to a plurality of sensitive application programming interfaces (APIs) on a device by an application signed with a private key, the method comprising:

verifying, by a processor of the device, a digital signature of the application using a public key;

after verifying the digital signature of the application using the public key, allowing the application to access a first sensitive API, the first sensitive API being associated with the public key; and

restricting the application from accessing a second sensitive API, the second sensitive API not being associated with the public key.

2. The method ofclaim 1, wherein the second sensitive API is associated with a second public key different from the public key associated with the first sensitive API.

3. The method ofclaim 1 wherein the device comprises a mobile device.

4. The method ofclaim 1 wherein the public key is associated with an entity that classified the first sensitive API as sensitive.

5. The method ofclaim 1 wherein the public key is associated with an author of the first sensitive API.

6. The method ofclaim 1 wherein the public key is associated with a manufacturer of the device.

7. The method ofclaim 1 wherein the first sensitive API is classified as sensitive by a manufacturer of the device.

8. The method ofclaim 1 wherein the first sensitive API is classified as sensitive by an author of the first sensitive API.

9. The method ofclaim 1 wherein the first sensitive API includes a user interface API.

10. The method ofclaim 1 wherein the first sensitive API interfaces with an input/output (I/O) controller.

11. The method ofclaim 1 wherein the first sensitive API includes a radio API.

12. The method ofclaim 1 wherein the first sensitive API interfaces with one or more wireless communication functions.

13. The method ofclaim 1 wherein the first sensitive API interfaces with address book data.

14. The method ofclaim 1 wherein the first sensitive API interfaces with calendar data.

15. The method ofclaim 1 wherein the public key is stored on the device.

16. The method ofclaim 1 wherein the public key is obtained from a public key repository.

17. The method ofclaim 1 wherein the first sensitive API is included in an API library.

18. The method ofclaim 1 wherein the verifying includes:

generating a hash of the application;

applying the public key to the digital signature to obtain an output; and

determining that the hash and the output are equivalent.

19. The method ofclaim 1 wherein the verifying includes:

generating an abridged version of the application;

applying the public key to the digital signature to obtain an output; and

determining that the abridged version and the output are equivalent.

20. The method ofclaim 1 wherein the verifying includes:

generating a transformed version of the application;

applying the public key to the digital signature to obtain an output; and

determining that the transformed version and the output are equivalent.

21. The method ofclaim 1 further comprising:

receiving user input regarding whether to grant the application access to at least one of the sensitive APIs.

22. The method ofclaim 1 further comprising:

verifying a second digital signature of a second application using a second public key; and

after verifying the second digital signature of the second application using the public key, allowing the second application to access the second sensitive API, the second sensitive API being associated with the second public key.

23. The method ofclaim 1 further comprising:

failing to verify a second digital signature of a second application using the public key; and

purging the second application.

24. The method ofclaim 1 wherein the device further includes a non-sensitive API, the method further comprising:

allowing the application to access the non-sensitive API.

25. The method ofclaim 1 wherein the device further includes a non-sensitive API, the method further comprising:

allowing an unsigned application to access the non-sensitive API.

26. The method ofclaim 1 further comprising:

restricting an unsigned application from accessing the first sensitive API and the second sensitive API.

27. The method ofclaim 26 further comprising:

executing the unsigned application on the device.

28. The method ofclaim 1 further comprising:

determining that a second application is unsigned; and

purging the second application from the device.

29. The method ofclaim 1 further comprising:

on a second device, verifying a second digital signature of a duplicate of the application using a duplicate of the public key; and

allowing the duplicate application to access a duplicate of the first sensitive API on the second device, the duplicate of the first sensitive API being associated with the duplicate of the public key.

30. A device capable of controlling access to a plurality of sensitive application programming interfaces (APIs) on the device by an application signed with a private key, the device comprising:

a processor capable of executing machine readable instructions for:

verifying a digital signature of the application using a public key;

after verifying the digital signature of the application using the public key, allowing the application to access a first sensitive API, the first sensitive API being associated with the public key; and

restricting the application from accessing a second sensitive API, the second sensitive API not being associated with the public key.

Images