PCT/GA 01/01344
`oe Decent 2e8] Ca 6,/4.0!)
`
`
`
`
`
`oi
`
`UNITED STATES DEPARTMENT OF COMMERCE
`
`United States Patent and Trademark Office
`
`November 27, 2001
`
`THIS IS TO CERTIFY THAT ANNEXED HERETOIS A TRUE COPY FROM
`THE RECORDS OF THE UNITED STATES PATENT AND TRADEMARK
`OFFICE OF THOSE PAPERS OF THE BELOW IDENTIFIED PATENT
`APPLICATION THAT MET THE REQUIREMENTSTO BE GRANTED A
`FILING DATE UNDER35 USC 111.
`
`APPLICATION NUMBER: 60/270,663
`FILING DATE: February 20, 2001
`
`PRIORIT
`DOCUMENT
`SUBMITTED OR TRANSMITTEDIN
`COMPLIANCE WITH RULE 17.1(a) OR (6)
`
`VALy
`By Authority of the
`. oh COMMISSIONER OF PATENTS AND TRADEMARKS
`
`PA 494424
`
`
`
`
`
`
`
`
`YSk e Ee
`
`LOALE,TOWH.
`PRESENTS SHALL,
`
`
`
`
`
`
`
`
`
`
`Sy
`Sergey p
`Tanna t
`
`N. WOODSON-
`Certifying Officer
`
`
`
`
`
`
`
`
`
`Page 1 of 30
`GOOGLEEXHIBIT 1005
`
`Page 1 of 30
`
`GOOGLE EXHIBIT 1005
`
`

`

`-
`
`an
`
`LKOV
`
`uw
`
`.
`
`PTO/SB/16 (8-00)
`Please type a plus sign (+) inside this box ———» [++
`Approvedfor use thraugh10/31/2062. OMB 6651-0032
`U.S. Patent and Trademark Office; U.S, DEPARTMENT OF COMMERCE
`«derthe Paperwork Reduction Act of 1995, no persons are raquired to respondto a collection of infarmation unlessit displays a valld OMB contre! number.
`Ss8. PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`>=Nn
`This is a requestforfiling a PROVISIONAL APPLICATION FOR PATENTunder37 CFR 1.53(c).
`oc
`OS==nph
`INVENTOR(S)
`za
`——
`===given Name(firstand middle ifany)
`Family Name orSumame
`CvMichael
`Brown
`
`=
`a
`oa_
`Residence
`ao S4
`aos —>
`and eitherState or Foreign Count
`City
`
`io
`
`
`a
`P.O. Box 216, 7 Danube Drive
`eu
`Heidelberg, Ontario NOB 1Y0
`oS
`cs
`el
`CANADA
`
`:
`
`Additional inventors are being named on the _L_ separatelynumbered sheets attached hereto
` TITLE OF THE INVENTION (280 characters max’
`
`CODE SIGNING SYSTEM AND METHOD
`
`
`
`-
`
`:
`
`CORRESPONDENCE ADDRESS
`Direct all correspondenceto:
`ee rete
`Bar Code Labelhere=-
`
`
`OoR
`Type Customer Number here
`.
`Firm or
`Individual Name
`David B. Cochran, Esq.
`Jones, Day, Reavis & Pogue
`Address
`North Point, 901 Lakeside Avenue
`
`lcySi Cleveland [state|OF|p|
`rus[Telephoneb16/586—3939] Fax_|
`
`
`!
`ENCLOSED APPLICATION PARTS (cheekall that apply)
`
`
`Specification NumberofPages
`[az
`Satake Assignment
`Lx] Drawing(s) NumberofSheets
`Other
`(specify)
`Power of Attorney fo}
`
`
`er (speci
`_
`Toe
`;
`[_] Application Data Sheet. See 37 CFR 1.76
`Provisional Appin
`
`
`METHOD OF PAYMENTOFFILING FEES FOR THIS PROVISIONALAPPLICATION FOR PATENT
`FILING FEE
`
`
`AMOUNT ($
`L]
`Applicant claims small entity status. See 37 CFR 1.27.
`
`
`
`[1 Acheck or money order is enciasedto coverthefiling fees
`
` $190.00
`501432
`The Commissioneris hereby authorized to chargefiling
`
`
`fees or credit any overpaymentto Deposit Account Number:
`Ref:
`555255012198
`[1 Paymentby credit card. Form PTO-2038is attached.
`The invention was madeby an agency of the United States Governmentor undera contractwith an agencyofthe
`
`
`
`United States Government.
`i No.
`
`
`(J ves, the nameof the U.S. Government agency and the Government contract numberare:_____
`=$$
`
`a“
`
`
`: eeDudB.CreSran vee[auFive
`REGISTRATION NO.
`SIGNATURE
`-
`TYPED or PRINTED NAME Dawid B. Cochran
`Pvorurna
`
`Docket Number:
`
`TELEPHONE —-216/586~3939
`USE ONLYFOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of Information is required by 37 CFR 1.51. The information is used by the public to file (and by the PTO to process) a
`provisional application, Confidentiality is governed by 35 U.S.C, 122 and 37 CFR 4.14. This collection is estimated to take 8 haursto
`complete, including gathering, preparing, and submitting the complete rovisional application fo the PTO. Time will va
`depending upon
`the individual case.
`Any comments on
`fhe amountoftime you require to complete
`this form and/or suggestionsforreducing thisBurden,
`should be sent to the Chief Information Officer, U.S. Patent and Trademark Office, U.S, Department of Commerce, Washington, D.C,
`20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND 10: Box Provisional Application, Assistant
`Commissioner for Patents, Washington, D.C. 20231.
`
`
`
`39,142
`
`555255012198
`
`Page 2 of 30
`
`Page 2 of 30
`
`

`

`mcrNLL
`
`PROVISIONAL APPLICATION COVER SHEET
`Additional Page
`
`PTO/SB/16 (8-00)
`Approved for use through 10/31/2002, OMB 0651-0032
`U.S. Patent and Trademark Office, U.S, DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required te res} pondto a collection of information unless It displays a valid OMB cantro} number.
`
`
`555255012198
`
`INVENTOR(SYAPPLICANT(S}
`
`Given Name(first and middle{ifan’ Family or Surname City and either State or Foreign Count
`
`Residence
`
`
`
`
`
`523A Rosemeadow Crescent
`
`Waterloo, Ontario N2T 129
`
`
`
`
`
`
`
`CANADA
`
`
`
`254 Castiefield Ave.
`Waterloo, Ontario N2K 2N1
`
`CANADA
`
`Herb
`
`Little
`
`
`
`WARNING:Information on this form may becomepublic. Credit card information should not
`be included on this form. Provide credit card Information and authorization on PTO-2038.
`
`Page 3 of 30
`
`Page 3 of 30
`
`

`

`Title:
`
`Code Signing System and Method
`
`Inventor(s):
`
`Michael Brown, Herb Little, David Yach
`
`5 Assignee:
`
`ResearchIn Motion Limited
`
`BACKGROUNDOF THE INVENTIONBesaEE
`
`10
`
`Field of the Invention
`
`This invention relates to security protocols with dynamic library linking
`
`programs such as Java™ programs. Specifically, this invention relates to assigning a
`digital signature to a program in orderto useit on a mobile communications device.
`
`
`
`
`
` cryptographic routines residing on the device must be restricted.
`
`Description of the Prior Art
`Whenan application program arrives at a mobile communications device
`
`such as the RIM Wireless Handheld 957™ or a multiple mode device incorporating both
`
`data and voice communications features, there is a need to control the access that the
`
`application has. For example, if such a device is to be exported, access to any strong
`Interfaces to a radio
`transmitter may be protected sothat destructive applications are unable to flood a wireless
`network with transmission signals; similarly, interfaces to a databaseorfile system may be
`protected so that destructive applications are unabletofill a device's storage space with
`
`unwanted data or alter existing data.
`
`25
`
`One schemeforprotecting interfaces involves application software signing,
`commonly called code signing. In conventional code signing schemes, an application
`
`-4-
`
`Page 4 of 30
`
`Page 4 of 30
`
`

`

`
`
`program developeror author generates a signature indicating the identity of the author and
`appendsthe signature to the application. Upon the arrival of a signed application at a
`device such as described above,the signature is used to authenticate the authorof the
`application.If the authoris a trusted source,the application may be loaded and executed
`
`on the device.
`Most known code signing schemes grant access to device or system
`resources for an application program based on authentication of the author of the
`application. However, there remains a need for a code signing schemewhichprovides for
`more selective resource accessrestriction, based onthe particular application instead of
`
`solely upon author authentication.
`
`SUMMARY OF THE INVENTION
`It is therefore an objectof the invention to provide an improved coding signing
`
`system and method.
`It is a related object of the invention to oversee the management and
`execution of Java and other dynamic library link-based applications arriving at a mobile
`
`communications device.
`It is a further object of the invention to verify that any application has been
`digitally signed as having permissionto carry outits intended functions.
`A siill further object of the invention is to prevent unacceptable applications
`from gaining accesssirong cryptographic routines and anyother application programming
`interface (API) designated by the AP! author as “sensitive”.
`In the presentinvention, digital signatures are used to control access to
`-2-
`
`5
`
` _
`
`20
`
`Page 5 of 30
`
`Page 5 of 30
`
`

`

`5
`
`sensitive APIs, thereby allowing access to onlythose applications that have been digitally
`signed by the authorof a sensitive APIor by a signing authority acting on behalf of the API
`author. The invention thereby advantageously implements an authorization schemeinstead
`of the conventional authentication scheme. According to this aspeci of the invention, a
`device checksa digital signature appendedto an application to determine whetheror not
`the application has been authorized to access device resources.
`In a preferred embodiment of the invention, a Java application, which will
`access a sensitive API, is developed to run ona device. In orderto run on the device and
`access the sensitive API, the authorof the API must approve theapplication by attaching a
`digital signature using the author's private key. Before the application can be executed on
`a device, the signed applicationwill be verified. The author of any API may decidethat the
`API should not be exposed to every application on the device, but only to those that have
`
` beenverified to be non-destructive,orforwhich some business arrangementpre-exists,for
` the course of the following detailed description.
`
`example.
`
`Furtherfeaturesof the invention will be described or will become apparentin
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`In order that the invention may be more clearly understood, embodiments
`
`20~—«thereof will now be described in detail by way of example, with reference to the
`
`accompanying drawings,in which:
`Fig. 1 is a system diagram of a first preferred embodimentthe invention;
`Figs. 2A and 2Billustrate componenis of a device on which an application
`
`-3-
`
`Page 6 of 30
`
`Page 6 of 30
`
`

`

`may be loaded and executed;
`Fig. 3 is a detailed flow diagram of the signing process accordingtothefirst
`
`embodiment;
`
`second embodiment; and
`Fig. 7 is a detailed flow diagram ofthe handling of a signed application on the
`device in accordance with the second embodiment.
`
`Fig. 4 is a detailed flow diagram of the handling of a signed application onthe
`device in accordance withthefirst embodiment;
`Fig. 5 is asystem diagram of asecond preferred embodiment the invention;
`Fig. 6 is a detailed flow diagram of the signing process according to the
`
`application, creating the signed application 8. The signed application 8 may now access
`
`5
`
`
`
`“s
`
` i
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
`Several embodimentsof the invention will now be described with reference to
`
`Figures 1-8.
`
`FIG 4 is an overall system diagram ofa first embodimentof the invention. An
`application developer2, creates an application Y, 4, such as a Java application, to run on
`the device 12 and access somesensitive API 6.
`In this embodiment, before the device
`application Y can be executed and granted access to the sensitiveAPI 6, a codesigner10,
`which may be the authorof the sensitive API or a competent signing authority chosen by
`
`20~~‘the API author and acting on behalf of the API author must sign the application. Thatis,
`using the author's private key, code signer 10 must attach a digital signature to the
`
`Page 7 of 30
`
`Page 7 of 30
`
`

`

`the sensitive APIit requires whenit arrives on the device.
`If access to more than sensitive
`APIis required bythe application, a uniquesignatureis preferably generated for each API
`and appendedto the application.Itis also contemplatedthat a single signaiure may grant
`
`access to a group of related APIs. Signature requirements are easily established in
`
`5
`
`accordancewith any desired level of control of API access.
`
`The signed application 8, having one or more appendedsignatures, may be
`
`sentvia the wireless network 9 orvia a seriallink (not shown)to the device. In the example
`
`of a Java application, a Java virtual machine (as shownin Fig. 2A) on the device will verify
`
`the digital signature of the signed application 8 before allowing the signed application
`
`accessto the sensitive API.
`
` applicable to other dynamiclibrary linking-based applications which require access to
`
`FIG 2Ais a diagram of the basic componentsof the invention on the device,
`including the Java virtual machine 20, applications 22, andlibraries 24. Although the
`device represented in Fig. 2A is enabled for Java applications, the invention is inno way
`
`limited thereto. Referencesin this description to Java applications and associated device
`
`components are forillustrative purposes only. As described above, the invention is
`
`devicelibraries or interfaces.
`
`|
`
`The Java virtual machine 20 is responsible for managing the linking and
`
`execution ofall Java applications that are running on the device. The applications may be
`
`20
`
`sent to the device overthe wireless networkor througha serial link. As shownin FIG 2B,
`
`the applications 22 may include somesigned applications 23 as well as some unsigned
`
`applications. Where the device 12 is a multiple mode device capable of data and voice
`
`Page 8 of 30
`
`Page 8 of 30
`
`

`

`communications for example, the applications may include data applications, voice
`
`applications and possibly applications relating to both data and voice functionality.
`If a library on the device 12 exposes a sensitive API,
`it must contain the
`
`following three items:
`
`5
`
`a) Astring 26 that provides a short description of the contents ofihe library;
`
`b) A public key 28 corresponding to the private key held by the code signer 10, which
`public key will be used to verify signatures on signed applications that require
`
`access to the sensitive API; and
`
`c) An APIidentifier 30 that uniquely identifies the sensitive API. Ifa library exposes
`
`more than one sensitive API, the library will include an identifier for each sensitive
`
`API.
`Any signed application 23 on the device mustcontain the following three items:
`
`a) The Java byte codethatis to be run;
`
`b) One or more digital signatures; and
`
`c) An APidentifier for each digital signature indicating which APIthe digital signature
`
`protects.
`
`q ;::: :
`
`neeiFey) wh So
`
`
`
`FIG 3 is a flow diagram ofthe code signing schemeofthefirst embodiment.If
`an application developer is writing an application that will require accessto a sensitive API
`
`on a device, through a library X for example as shown at step 40, then thefinished
`
`20
`
`application will need to be signed before it can run on the device. The developer can write
`
`such an application 4 (FIG 1) andtestit in a locally available device simulator environment
`
`in which signature checkingis disabled (step 42). Once the developeris satisfied that the
`
`i P
`
`age 9 of 30
`
`Page 9 of 30
`
`

`

`application is working properly, the application is submitted to the code signer for the
`
`protected API, in step 44. . As indicated at step 46, the code signerfor the protected API
`
`reviews the application and verifies that it may be granted accessto the sensitive AP} on
`
`the device 12. The code signer may applyaplurality of criteria to determine whether or not
`
`5
`
`such accessto the sensitive API is to be granted, including but in no waylimited to: a
`
`maximum application size restriction, the specific device resources used by the application,
`
`the perceivedutility and value of the application to a device user,its interaction with other
`
`applications on the device, and perhaps most important, whether or not the application
`
`appears to contain a virus or destructive code.
`
`
`ae
`
`iz,
`
`
`
`ime
`
`In step 48, the code signer makes a determination of whetherornot to sign
`
`the submitted application. If the code signeris satisfied, then in step 50, the code signer
`
`generates a signature, preferably using a hash of the application and a private key, and
`
`appendsthedigital signature (including the API identifier) to the application. Where the
`
`application requires access to more than one sensitive API such that more than one
`
`signature is required, steps 46 through 54 would be repeated (not shown). The signed
`
`application is then returned to the application developer as in step 52. Provided that all
`
`required signatures granting access to all required APIs have been appended to the
`
`application, the application developer may then send the signed application, as in step 54,
`
`to a real device for execution therein. In step 56, if the code signer does not accept the
`
`20
`
`code or does not wish to grant access to one or more of the required APIs, the developer
`
`receives a rejection notice and the submitted application will not run on the device,if sent
`
`to it. As described above, the code signer may be the API author or a signing authority
`
`Page 10 of 30
`
`Page 10 of 30
`
`

`

`acting on behalf of the AP! author.
`
`FIG 4 is a flow diagram of a method,in accordancewiththefirst embodiment
`
`of the invention, that a device uses to handle a signed application. Once an application
`
`has arrived on the device in step 60, through a wireless communication link or a direct
`
`5
`
`connection to the device, the virtual machine 20 may begin theverification process. Any
`
`libraries that the application requires must also be present on the device before the
`
`process can continue. Once the device hasall of the libraries required by the application,it
`
`will determine if the application needs access to a sensitive AP! within one of these
`
`libraries, in step 62.
`
`If not, the application can be linkedwith allof thelibrariesit requires,
`
`and executedin step 76.
`
`In step 64,if the application does require accessto a protected
`
`API, the virtual machine can extract the public key and APIidentifier from the library
`
`exposing the API. Then,in step 66, the virtual machine looks throughall of the signatures
`
`appendedto the application, and tries to find one with an identifier matching the API
`t
`identifier extracted from the library. The virtual machine determinesif there is a match in
`
`
`step 68.
`
`5
`
`If a signature for the specific API is found in step 66,it must then be verified.
`
`Verification of the signature at step 68 preferably involves hashingthe application, applying
`
`a public key corresponding to the private key used by the code signer during the code
`
`signing process, and comparing the result with the appendedsignature. A match between
`
`20
`
`the locally generated result and the appended signature verifies the signature. If the
`
`signature cannotbeverified, the application is not loaded or executed (step 74) and the
`
`process ends (step 78). According to a further aspect of the invention, non-verified
`
`-8-
`
`Page 11 of 30
`
`Page 11 of 30
`
`

`

`applications are purged from the device.If the signatureis verified properly in step 68, then
`
`the application must have been signed using the code signer’s private key. Since only the
`code signer has accessto thatprivate key, the code signer must have beensatisfied that
`
`the application should be granted access to the sensitive API. This verification process
`
`5 maybe repeated, whenthe application requires access to more than one sensitive APIfor
`
`
`
`
`is
`
`example. When all signatures have been verified, the virtual machine will display a
`
`notification message to the user, including the description of the API required by the
`
`application, such as: “Application X requires accessto the ‘strong cryptographicprimitives’
`
`API.” The userwill then be askedif the application should be allowed to proceed, at step
`
`70.
`
`if the user chooses to execute the application, the virtual machine will link the
`
`application with any required libraries and, once the linking process is complete, the
`
`application will be executed as in step 76. Otherwise, the application will be not be loaded
`
`or executed, and the process ends (78).
`
`Thefirst embodimentof the invention as described abovetherefore provides
`
`for control of access to sensitive APIs by a code signer. However, this necessitates a
`through review of every application requiring access to any sensitive APIs on the device by
`
`the code signer. Such application review is a time- and labor-intensive process. The code
`
`signer must also assumethe substantial responsibility of ensuring that the codeforall such
`
`applications is “clean”, or free from viruses and destructive code.
`
`20
`
`For an application developer, a code signing scheme accordingto thefirst
`
`embodiment requires the transmission of an application to the code signer. As thoseskilled
`
`in the art will appreciate, most application developers invest significant time and expense to
`
`| P
`
`age 12 of 30
`
`Page 12 of 30
`
`

`

`prevent early release of applications currently under development. Therefore, a code
`
`signing schemeas described above mayactually discourage application development by
`
`certain developers.
`
`A code signing scheme according to a second embodimentofthe invention
`provides for API access control, but overcomesboth of the above potential disadvantages
`
`5
`
`of the first embodiment. An overall system diagram of a second embodimentof the
`
`invention is shown in FIG 5. As described abovein conjunction with FIG 1, an application
`
`developer 2, creates an application Y, 80, to run on the device 12 and access a sensitive
`
`API 6. The application must therefore be granted accessto the sensitive APIin order to
`
`run on the device. In accordance with the second embodimentof the invention, the
`
`application developer 2 uses a hashing algorithm, such as the known Secure Hashing
`
`Algorithm SHA1, to generate a hash of the application. For a Java application, the Java
`
`.cod file is preferably used in the hashing operation. Instead of sending the application to a
`
` of the first embodiment, but performs somewhat different functions as will become
`
`code signer for approvalasin the first embodiment, the hash of the application Y, 82,is
`
`sent to the a signing authority 11. The signing authority 11 is similar to the code signer 10
`
`apparentasthis description proceeds.
`In a particularly preferred embodiment, a registration process is executed
`
`between the application developer 2 and the signing authority 11 before the hash of the
`
`20
`
`application Y, 82, is sent to the signing authority 11. Such a registration processis
`
`preferably initiated when a development or other business relationship between the
`
`application developer 2 and the signing authority 11 is established. Where an application
`
`-10-
`
`Page 13 of 30
`
`Page 13 of 30
`
`

`

`developer 2 has entered into an agreement with a manufacturer or service provider of
`
`device 12 to provide further services to the device 12 for example, registration of the
`
`application developer 2 could be performed, regardless of whetheror not an application
`
`has yet been completed. The registration of an application developer2 is preferably limited
`
`5
`
`to specific APls, such that applications from a particular application developer 2 would be
`
`signed for access only to certain APIs. Therefore, a hash of an application from an
`application developer registered with the signing authority 11 for developing applications
`
`requiring access to a data messaging API or a voice- or telephony-related API in a
`
`communication device for example, would not be signed by the signing authority 11 to also
`grant accessto a cryptographic or any other sensitive API onthe device. API accessis
`
`thus closely controlled.
`
`The registration process begins with a request from an application developer
`
`‘2 to use a particular API.
`
`-If the developer 2 has established some sort of business
`
`relationship as described above,the signing authority 11 may then provide the application
`
`developer 2 with detailed information about the API to allow the application developer2 to
`
`‘write applications which operate with the API. The application developer 2 may submit a
`
`registration request to the signing authority 11 to be registered as a developerof
`
`applications for the particular API. The signing authority 11 then registers the application
`
`
`
` =
`
`developer 2 accordingly.
`
`20
`
`The signing authority 11 thereby controls which application developers may
`
`write applications requiring access to sensitive APls. Different developers may have
`
`different API access requirements and maythus acquire different API accessregistrations.
`
`-11-
`
`Page 14 of 30
`
`Page 14 of 30
`
`

`

`The nature of some APIs, such as any cryptographic APIs, may require morestrict controls
`
`than messaging or telephony APIs for example. As described above, export regulations
`
`may define specific guidelines for access to any cryptographic APls on a device. The
`
`registration operations performedbythe signing authority 11 can be adapted to implement
`
`5
`
`any such guidelines.
`
`If export regulations require that an application developerobtain a
`
`permit in order to access a cryptographic API, then the signing authority 11 would confirm
`
`that the application developer has obtained such a permit before registering the developer
`
`for cryptographic API access.
`
`
`
`Whena hashof an application Y, 82, is sent to the signing authority 11, an
`
`authentication process is performed by the signing authority 11 to authenticate the
`
`application developer 2. Provided that the application developer 2 has previously been
`
`registered with the signing authority 11 and the registration has not expired or been
`
`revoked, the signing authority 11 will sign the hash of the application and send the
`
`signature 84 back to the application developer 2. The signature 84 is generated using a
`
`secret key of the signing authority 11 and the hash 82 of the application, as described
`
`above. Most modernsignature algorithms involve calculation of a hash of an inputfile or
`
`data, and any such algorithm may be usedin this embodimentof the invention. Instead of
`
`generating a hashofits input however, the signing authority 11 may use the hash 82 of the
`
`application sent by the developer 2. The signature 84 is then appendedto the application
`
`20
`
`80 to form a signed application 86, which may be transmitted to the device 12 over a
`
`wireless network or loaded onto the device through a direct connection (not shown). The
`y
`
`device 12 must verify the appended signature 84 before the application is executed.If
`
`-12-
`
`Page 15 of 30
`
`Page 15 of 30
`
`

`

`
`
`access to more than one sensitive API is required, then more than one signature 84 may
`
`be generated by the signing authority 11 and appendedto the application BO.
`
`The second embodimentof the invention differs from thefirst embodiment
`
`primarily in aspects relating to code signing and signature verification. The actual
`
`5
`
`applications and execution thereof are substantially the samefor both embodiments. Thus,
`
`applications 80, signed in accordance with the code signing scheme of the second
`
`embodimentof the invention, may be executed in a device as shownin FIG 2A and FIG 2B
`
`as described above.
`
`The code signing process according to the second embodiment
`
`is
`
`= ©
`
`representedin the flow diagram of FIG. 6. As in FIG 4, an application requiring access to a
`
`HHLawealIt
` the signing authority 11 determines whetherornotthe application developeris registered
`
`sensitive API on a device is shownat 40, usinga library X for example. The application,
`
` when complete, may be tested in a device simulator environment in which signature
`checkingis disabled (step 42).
`If proper operation of the application within the simulator
`
`environmentis verified, then the application is hashed and the hash of the applicationis
`
`submitted to the authorof the protected APIor the signing authority, in step 88. At step 90,
`
`with the signing authority 11. If so, then in step 92, a signature is generated using a private
`
`key, and the digital signature (including the API identifier) is returned to the application
`
`developer as in step 94. Steps 56, 92 and 94 maybe repeated if access to more than one
`
`20
`
`sensitive API is required by the application. The application developer appends the
`
`signature orsignatures to the application (96) and may then sendthe signedapplication,
`
`as in step 98, to a device.In step 56,if the application developeris not registered with the
`
`-13-
`
`Page 16 of 30
`
`Page 16 of 30
`
`

`

`signing authority 11 or is not registered for access to oneof the required APIs, such that
`
`ihe hash of the application should not be signed, then the developer receives a rejection
`
`notice and the submitted application will not run on any device.
`FIG 7 illustrates the operations executed on a device upon receipt of an
`
`5
`
`application signed in accordance with the second embodiment of the invention. The
`
`process begins at a step 60 when anapplication with at least one appendedsignature
`
`arrives at the device. As described above, anylibraries that the application requires must
`
`also be present on the device before the process can continue. At step 62,itis determined
`
`whether or not the application requires access to a sensitive API within any of these
`
`If not, the applicationis linked withall of the librariesit requires and executed,at
`‘fibraries.
`In step 64,if the application does require accessto a protected API, the virtual
`step 76.
`machine (FIG 2A) extracts the public key and APIidentifier from the library exposing the
`
`API.
`
`If a corresponding signature with an identifier matching the APIidentifier extracted
`
`
` application 80 and using the public key corresponding to the private key used by the
`
`from thelibrary has been appendedto the application, as determined at step 66, then the
`
`virtual machine attempts to verify the signature (102) by calculating a hash of the
`
`signing authority 11.
`
`If the signature cannotbe verified, the application is not loaded or
`
`executed (step 74) and the process ends (step 78). As described above, non-verified
`
`applications may possibly be purged from the device.
`
`20
`
`if the signatureis verified in step 102, then the virtual machinewill display a
`
`notification message to the user, including the description of the API required by the
`
`application, and await input from the userto indicate whetherornot the application should
`
`-14-
`
`Page 17 of 30
`
`Page 17 of 30
`
`

`

`be allowed to proceed, at step 70.
`
`If the user chooses to execute the application, the
`
`virtual machinewill link the application with any requiredlibraries and the application will be
`
`executed (76). Otherwise, the application will be not be loaded or executed (74), and the
`
`process ends (78).
`
`Notably, in the second embodiment,only a hash 84of the application is sent
`
`to the signing authority 11 by the application developer2, such that the signing authority 11
`
`does not checkthe applicationfor errors, viruses, and the like. Responsibility for the code
`
`therefore lies with the application developer 2. Since the application developer 2, in order
`
`to be registered with the signing authority 11, must have established a service or other
`
`businessrelationship with the signing authority 11 or the entity on whosebehalf the signing
`
`authority 11 acts, the application developer2 will ensure that no destructive or otherwise
`
`problematic code is sent to any devices. Should any such code be found in a signed
`application or suspected because of peculiar, destructive or problematic behaviour
`
`exhibited whena signed application is executed on a device,the signaturefor the particular
`
`application will be revoked. Theregistration orprivileges of the application developer2 with
`
`the signing authority 11 may also be suspended or revoked, since the signature 84
`
`provides an audit trail through which the developer of a problematic application may be
`
`identified. In such an event, all devices would preferably be informed of the revocation or
`
`instructed to download an updated revocation list.
`
`If any applications for which the
`
`
`
`
`‘fC —_ oa
`
`20
`
`corresponding signatures have been revoked are running on a device, the device halts
`
`execution of the application and may purge the application from its local storage. Every
`
`device would also preferably store and periodically update a revocationlist to ensure that
`
`-15-
`
`Page 18 of 30
`
`Page 18 of 30
`
`

`

`
`
`any subsequently received or downloaded signed applications for which a signature has
`been revoked will not be verified and are therefore not executable on any device.
`
`In addition, hashing algorithms are designed to prevent reconstruction of an
`
`input from the hash,or at least render such reconstruction computationally infeasible. As
`such, security concerns regarding the release of applications under developmentfor
`
`5
`
`verification by a signing authority should bealleviated. Only a hash 84 of the application
`
`80, not the application 80itself, is sent to the signing authority 11.
`
`Although the signature 84 generatedbythe signing authority 11 is dependent
`
`upon authentication of the application developer and confirmation that the application
`developer has been properly registered, the signature 84 includes the hash of the
`application 80 and is therefore application-specific. This contrasts with prior art code
`signing schemes, in which API accessis granted to any applicationsarriving from trusted
`applica