`
`EP 2 284 644 A1
`
`26
`
`Claims
`
`1.
`
`A mobile device (62) comprising:
`
`an application platform having application pro-
`gramminginterfaces (APIs), each having a sig-
`nature identifier;
`a verification system for authenticating digital
`signatures (96) and signature identifications
`(94) provided by respective software applica-
`tions (66) to access the APIs; and
`a control system for allowing a software appli-
`cation on the device to access at least one of
`the APIs where the signature identifier of the
`such API correspondswith the digital signature
`identification and digital signature provided by
`the software application is authenticated by the
`verification system.
`
`The mobile device of claim 1, wherein a virtual ma-
`chine comprisesthe verification system and the con-
`trol system, preferably the virtual machine being a
`Java virtual machine and the software application
`being a Java application.
`
`The mobile device claim 1 or 2, wherein the control
`system requires one digital signature and one sig-
`nature identification for each library of at least one
`of the APIs.
`
`The mobile device of any of claims 1 to 3, wherein
`the APIs of the application platform accessat least
`one of a cryptographic module, which implements
`cryptographic algorithms, a data store, a proprietary
`data model, and a userinterface (Ul).
`
`The mobile device of any of claims 1 to 4, wherein
`the digital signature is generated using a private sig-
`nature key under the signature scheme, and the ver-
`ification system uses a public signature key to au-
`thenticate the digital signature.
`
`The mobile device of claim 5, wherein:
`
`the digital signature is generated by applying the
`private signature key to a hash of the software
`application under the signature scheme: and
`the verification system authenticates the digital
`signature by generating a hash of the software
`application to obtain a generated hash, applying
`the public signature key to the digital signature
`to obtain a recovered hash, and verifying that
`the generated hash and the recovered hash are
`the same.
`
`7.
`
`The mobile device of any of claims 1 to 6, wherein
`at least one of the APIs further comprises:
`
`a description string that is displayed when the
`software application attempts to access said at
`least one of the APIs.
`
`A method of controlling access to application pro-
`gramming interfaces (APIs) on a mobile device, in-
`cluding the step of allowing a software application
`on the device to accessat least one of the APIs where
`a signatureidentifier of the such API corresponds
`with a digital signature identification and digital sig-
`nature provided by the software application is au-
`thenticated by a verification system of the device.
`
`The method of claim 8, comprising the additional
`step of:
`
`purging the software application from the mabile
`device where the signature identification does
`not correspond with the signature identifier.
`
`The methodof claim 8 or 9, wherein the digital sig-
`nature and the signature identification are generated
`by a code signing authority.
`
`The methodof any of claims 8 to 10, comprising the
`additional step of:
`
`denying the software application access to the
`API where the digital signature is not authenti-
`cated.
`
`The method of claim 11, comprising the additional
`step of:
`
`purging the software application from the mobile
`device where the digital signature is not authen-
`ticated.
`
`10.
`
`11.
`
`12.
`
`20
`
`30
`
`35
`
`13.
`
`40
`
`The method of any of claims 8 to 12, wherein a de-
`scription string is displayed to a user when the soft-
`ware application attempts to access said at least one
`of the APIs.
`
`14.
`
`45
`
`The methodof any of claims 8 to 13 comprising the
`additional step of:
`
`displaying a description string that notifies a user
`of the mobile device that the software application
`requires access to the API.
`
`15.
`
`The method of claim 14, comprising the additional
`step of:
`
`receiving a command from the user granting or
`denying the software application access to the
`API.
`
`50
`
`55
`
`14
`
`Page 501 of 1415
`
`GOOGLE EXHIBIT 1004
`
`Part 2 of 3
`
`Page 501 of 1415
`
`GOOGLE EXHIBIT 1004
`Part 2 of 3
`
`
`
`EP 2 284 644 A1
`
`Application
`
` Application
`12
`Developer Y
`
`
`Codesigner
`
`
`Signed
`
`Application
`Y
`
`22
`
`s
`
`Wireless
`Network
`
`Y
`
`
`
`
`22
`
`Application
`Y
`
`Device
`
`28
`
`12
`
`
`
`
`AP! PI~29
`
`Figure 1
`
`15
`
`24
`
`1 oO”
`
`Page 502 of 1415
`
`Page 502 of 1415
`
`
`
`EP 2 284 644 A1
`
` Application Y uses
` Test Application Y
`
`in device simulator
`with no signature
`verification.
`
`
`
`LibraryA
`
`
`Figu re 2
`
`oN
`
` Application ¥ Application ¥
`Signing Authority
`
`reviewed by Cade
`
`
`
`
`Rejection
`Cade Signing
`Notification to
`Authority signs
`
`
`
`Software
`Application ¥ with
`
`
`
`Digital Signature
`Developer
`
`
`
`
`
`Retum Application
`Y to Software
`Developer with
`AppendedDigital
`Signature
`
`
`
`
`52.
`
`
` Application Y
`
`loaded on Moble
`Device.
`
`
`
`Page 503 of 1415
`
`16
`
`Page 503 of 1415
`
`
`
`EP 2 284 644 A1
`
`cn ss at ih et aet Sk ei kk Fl a nh i kn eS ar i ah At a Ap A AS SFSSSe Se SEE Ee EP SO om
`
`Signature identification
`
`Digital Signature
`
`-C¢
`
`Seeeseeeeheeoewete~-~oeaANomEOHEeeabeeacero
`
`takakee
`emmmmkmeHnEaSPOmHYOfoswea
`
`API Library C with sensitive API
`
`APILibrary A with sensitive API
`
`
`
`Mabile Device
`
`Figu re 3
`
`17
`
`Page 504 of 1415
`
`Page 504 of 1415
`
`
`
`
`EP 2 284 644 A1
`
`aeGABH BEOOEESaAHaANI¥
`
`Application
`
`System
`
`Platform Operating
`Description
`
`Application Y
`(signed)
`94E
`96E
`
`Signature ID-E. )
`
`Signature - E
`
`Signature ID - F
`Signature - F
`
`
`
`
`
`
`
`Virtual Machine
`
`ae
`
`Mobile Device
`
`
`
`
`Mobile Device
`
`‘e
`
`Mobile Device
`eee EEEEOEERTEEf
`
`J)
`
`62G
`
`61
`
`Page 505 of 1415
`
`Figure 3A
`
`18
`
`Page 505 of 1415
`
`
`
`EP 2 284 644 A1
`
`Application Loaded
`on Mobile Device
`
`104
`
` Does Application
`
`Need Access to Sensitive
`API Library?
`
`102
`
`
`Yes
`
`Virtual Machine
`
`
`Retrieves Public
`
`
`Key and Signature
`Identifier from API
`
`Library
`
`
`
`Signature on
`
`Application?
`
`No
`
`Figu re 4
`
`ON
`
`116
`
`Application Not
`Loaded or
`
`Executed
`
`108 Proper
`
`Virtual Machine
`executes
`Application and
`linkds with API
`Library
`
`120
`
`118
`
`19
`
`Page 506 of 1415
`
`Page 506 of 1415
`
`
`
`EP 2 284 644 A1
`
`Application
`~ Developed
`
`220
`
`230
`
`250
`
`
`
` 210
`
`
`Receive Target
`Signing Request
`
`
`
`Database
`
`
`
`
`
`
`
`Target
`N
`— Haven
`Private Key
`
`Database
`y!
`
`
`
`
`
`
`
`
`Return
`
`Signature
`
`
`Developer
` Developer
`Trusted by
`
`Authority?
`
`Reject Application
`
`240
`
`270
`
`Reject Application
`
`:
`
`Y
`
`260
`
`Sign Application
`
`280 NK200
`
`Figure 5
`
`20
`
`Page 507 of 1415
`
`Page 507 of 1415
`
`
`
`EP 2 284 644 A1
`
`622
`
`Flash
`
`{Auxiliary VO
`628
`
`-
`
`g
`630
`3
`624
`: a
`(RAM)
`py :
`626
`3
`632
`7
` Signats :|Speaker|Receiver
`
`ee
`| 616
`634
`[Merophone|
`
`636 638
`
`i
`Other Device
`Subsystems
`642
`
`Short-Range
`Communications
`'
`640
`
`Ay
`
`er
`
`i
`Control
`; 618
`614
`i
`i
`Lett |
`nana 6i4.~~—C«TS
`Tiortoectneesntenaarcee
`
`810
`
`Figure 6
`
`21
`
`Page 508 of 1415
`
`Page 508 of 1415
`
`
`
`EP 2 284 644 A1
`
`
`
`Europaisches
`Patentamt
`European
`vtcencen
`des ee
`
`EUROPEAN SEARCH REPORT
`
`Application Number
`
`EP 10 18 3655
`
`
`DOCUMENTS CONSIDERED TO BE RELEVANT
`Citation of documentwith incication, where appropriate,
`of relevant passages
`
`CLASSIFICATION OF THE
`APPLICATION (IPC)
`
`Relevant
`to claim
`
`INV.
`GO6F1/00
`
`TECHNICAL FIELDS
`SEARCHED
`(IPC)
`
`"ISO/IEC 7816-4:1995
`ANONYMOUS:
`Information technology -- Identification
`cards -- Integrated circuit(s) cards with
`contacts -- Part 4: Interindustry commands
`for interchange",
`INTERNATIONAL STANDARD ISO/IEC,
`vol. 7816-4:1995(E),
`1 January 1995 (1995-01-01), pages
`1-1V,1-46, XP008124701,
`* page 12 *
`
`"ISO/IEC 7816-8:
`ANONYMOUS:
`IDENTIFICATION CARDS -- INTEGRATED CIRCUIT
`CARDS - PART 8: COMMANDS FOR SECURITY
`OPERATIONS",
`INTERNATIONAL STANDARD 1S0/IEC,
`vol. 7816, no. 8,
`25 June 1998 (1998-06-25), XP002610578,
`* Document consists of pages i-iii, 2-3,
`6-13 *
`* table 4 *
`
`"ISO/IEC 7816-9:
`ANONYMOUS:
`IDENTIFICATION CARDS -- INTEGRATED CIRCUIT
`CARDS - PART 9: COMMANDS FOR CARD
`MANAGEMENT",
`INTERNATIONAL STANDARD 1S0/IEC,
`vol. 7816, no. 9,
`17 June 1999 (1999-06-17), XP002610579,
`* Document consists of i-iv, 9-13, 29-31 *
`* page 9 *
`
`-{--
`
`The present search report has been drawn upfor all claims
`w
`Place of search
`Date of completion of the search
`Examiner
`
`document EPOFORM1503
`
`Munich
`GATEGORYOF CITED DOCUMENTS
`X: particularly relevantif taken alone
`Y : particularly relevant if cambined with another
`dacument of the same category
`A: technological background
`O: non-written disclosure
`P : intermediate document
`
`Kerschbaumer, J
`25 November 2010
`: theory or principle underlying the invention
`: earlier patent document, but published on, or
`afterthe filing date
`: documentcited in the application
`: documentcited for other reasons
`! memberaf the same patentfamily, corresponding
`
`301)
`
`
`
`03.82(P04!
`
`Page 509 of 1415
`
`22
`
`Page 509 of 1415
`
`
`
`EP 2 284 644 A1
`
`
`
`Europiisches
`Patentamt
`European
`Patent Office
`Office européen
`des bevels
`
`EUROPEAN SEARCH REPORT
`
`Application Number
`EP 10 18 3655
`
`DOCUMENTS CONSIDERED TO BE RELEVANT
`
`- RANKL W; EFFING W",
`"Excerpts ED
`1 January 1999 (1999-01-01), HANDBUCH DER
`CHIPKARTEN. AUFBAU - FUNKTIONSWEISE -
`EINSATZ VON SMART CARDS, MUENCHEN : CARL
`HANSER VERLAG, DE, XP0Q07908384,
`ISBN: 978-3-446-21115-5
`* Document concicts of pages 197-203,
`261-273, 740-741, 794-797 *
`* pages 269,272; figure 5.39 *
`
`|semanasee)|FIELDSSEARCHED|semanasee)|
`
`
`The present search report has been drawn upforall claims
`
`
`
`
`
`3
`
`ax
`3
`o
`a
`oe
`3
`=
`z
`9
`uw
`9
`
`Place of search
`
`Date of completion of the search
`
`Examiner
`
`
`Munich
`25 November 2010
`Kerschbaumer, J
`CATEGORY OF CITED DOCUMENTS
`T: theory or principle underlying the invention
`E: earlier patent document, but published on, or
`X ; particularly relevantif taken alone
`afterthe filing date
`D : document sited in the application
`Y : particularly relevantif combined with another
`id
`documentof the same category
`
`A: technological background
`
`
`:
`mberof the same patent family, corresponding
`©: non-written disclosure
`“document
`P : intermediate document
`
`Page 510 of 1415
`
`23
`
`Page 510 of 1415
`
`
`
`REFERENCESCITED IN THE DESCRIPTION
`
`EP 2 284 644 A1
`
`This list of references cited by the applicant is for the reader’s convenienceonly. [t does not form part of the European
`patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be
`excluded and the EPOdisclaimsall liability in this regard.
`
`Patent documentscited in the description
`
`«
`«
`
`US 23415200 P [0001]
`US 23535400 P [0001]
`
`«
`
`US 27066301 P [0001]
`
`Page 511 of 1415
`
`24
`
`Page 511 of 1415
`
`
`
` Europdisches
`
`Patentamt
`European
`Patent Office
`Office européen
`des brevets
`
`(11)
`
`EP 2 278 429 A1
`
`(12)
`
`EUROPEAN PATENT APPLICATION
`
`(43)
`
`Date of publication:
`26.01.2011 Bulletin 2011/04
`
`(51) Int Cl:
`GO6F 1/00 (2096.01)
`
`(21)
`
`Application number: 10183997.5
`
`Date offiling: 20.09.2001
`(22)
`
`
`(84)
`
`Designated Contracting States:
`AT BE CH CY DE DK ES FIFRGBGRIEITLILU
`MC NL PT SE TR
`
`« Brown, Michael S
`Heidelberg Ontario (CA)
`¢ Little, Herbert A
`Waterloo Ontario (CA)
`
`(30)
`
`Priority: 21.09.2000 US 234152 P
`26.09.2000 US 235354 P
`20.02.2001 US 270663 P
`
`(62)
`
`Document number(s) of the earlier application(s) in
`accordance with Art. 76 EPC:
`05024661.0/ 1 626 324
`01973901.0/ 1 320 795
`
`(71)
`
`Applicant: Research In Motion Limited
`Waterloo, ON N2L 3W8 (CA)
`
`(74) Representative: Finnie, Peter John
`Gill Jennings & Every LLP
`The Broadgate Tower
`20 Primrose Street
`
`London EC2A 2ES (GB)
`
`Remarks:
`
`This application was filed on 30-09-2010 as a
`divisional application to the application mentioned
`under INID code 62.
`
`(72)
`
`Inventors:
`Yach, David P
`Waterloo Ontario (CA)
`
`
`(54)
`
`Software code signing system and method
`
`Acode signing system and methodis provided.
`(57)
`The code signing system operates in conjunction with a
`signed software application having a digital signature and
`includes an application platform, an application program-
`ming interface (API), and a virtual machine. The API is
`configuredto link the software application with the appli-
`cation platform. The virtual machine verifies the authen-
`ticity of the digital signature in order to control access to
`the API by the software application.
`
`EP2278429A1
`
`Page 512 of 1415
`
`
`Signed
`2s Application
`v
`
`
`
`
`Device
`
`28
`12
`
`[LAPt]Pr~o
`
`10
`
`Figure 1
`
`Printed by Jouve, 75001 PARIS (FR}
`
`14
`Application
`
` Application
`Developer Y
`
`
`
`
`
`
`
`m
`22
`
`Signed
`Application
`Y
`—
`
`Y
`
`Page 512 of 1415
`
`
`
`1
`
`EP 2 278 429 A1
`
`2
`
`Description
`
`SUMMARY
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001] This application claims priority from and is re-
`lated 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; and "Code Signing Sys-
`tem And Method," U.S. Provisional Application No.
`60/270,663, filed Feb. 20,2001.
`
`BACKGROUND
`
`1. Field of the Invention
`
`[0002] This invention relates generally to the field of
`security protocols for software applications. Morepartic-
`ularly, the invention provides a code signing system and
`method that is particularly well suited for Java(TM) ap-
`plications 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 "de-
`vices").
`
`
`2. Description of the Related Art
`
`Security protocols involving software code sign-
`[0003]
`ing schemes are known. Typically, such security proto-
`cols are used to ensurethe reliability of software appli-
`cations that are downloaded from the Internet. In a typical
`software code signing scheme, a digital signature is at-
`tached to a software application that identifies the soft-
`ware developer. Oncethe software is downloaded by a
`user, the user typically must use his or her judgment to
`determine whether or not the software application is re-
`liable, based solely on his or her knowledge of the soft-
`ware developer’s reputation. This type of code signing
`scheme doesnot ensure that a software application writ-
`ten by a third party for a mobile device will properly in-
`teract with the device’s native applications and other re-
`sources. Becausetypical 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 soft-
`ware applications may be downloaded and installed onto
`a mobile device.
`[0004] There also remains a need for network opera-
`tors to have a system and method to maintain control
`over which software applications are activated on mobile
`devices.
`[0005] 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.
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`[0006] Acodesigning system and method is provided.
`The code signing system operates in conjunction with a
`software application having a digital signature and in-
`cludes an application platform, an application program-
`ming interface (API), and a virtual machine. The API is
`configured to link the software application with the appli-
`cation platform. The virtual machine verifies the authen-
`ticity of the digital signature in order to control access to
`the API by the software application.
`[0007] Acode signing system for operation in conjunc-
`tion with a software application having a digital signature,
`according to another embodiment of the invention com-
`prises 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 accessto the plu-
`rality of APIs by the software application.
`[0008] According toa further embodiment of the inven-
`tion, a method of controlling access to sensitive applica-
`tion programming interfaces on a mobile device compris-
`es the steps of loading a software application on the mo-
`bile device that requires access to a sensitive API, de-
`termining whether or not the software application in-
`cludes 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 accessto the sensitive
`API.
`
`Inanother embodiment of the invention, a meth-
`[0009]
`od of controlling access to an application programming
`interface (API) on a mobile device by a software appli-
`cation created by a software developer comprises the
`steps of receiving the software application from the soft-
`ware developer, reviewing the software application to de-
`termine if it may access the API, if the software applica-
`tion may accessthe API, then appending a digital signa-
`ture 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 appendeddigital signature is authentic.
`[0010] A method of restricting access to a sensitive
`API on a mobile device, according to a further embodi-
`ment of the invention, comprises the steps of registering
`one or more software developers that are trusted to de-
`sign software applications which access the sensitive
`API, receiving a hash of a software application, deter-
`mining 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 soft-
`ware developers, then generating a digital signature us-
`ing the hash of the software application, wherein the dig-
`ital signature may be appendedto the software applica-
`tion, and the mobile device verifies the authenticity of the
`
`Page 513 of 1415
`
`Page 513 of 1415
`
`
`
`3
`
`EP 2 278 429 A1
`
`4
`
`digital signature in order to control access to the sensitive
`API by the software application.
`[0011]
`In a still further embodiment, a method of re-
`stricting access to application programming interfaces
`ona mobile device comprises the steps of loading a soft-
`ware application on the mobile device that requires ac-
`cess to one or more API, determining whether or not the
`software application includes a digital signature associ-
`ated with the mobile device, and if the software applica-
`tion does notinclude 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
`
`[0012]
`
`FIG. 1 is a diagram illustrating a code signing proto-
`col according to one embodimentof the invention;
`FIG. 2 is a flow diagram of the code signing protocol
`described above with reference to FIG. 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 ref-
`erence to FIG. 3 and FIG. 3A;
`FIG. 5 is a flow diagram illustrating the management
`of the code signing authorities described with refer-
`ence to FIG. 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
`
`[0013] Referring now to the drawing figures, FIG. 1 is
`a diagram illustrating a code signing protocol according
`to one embodiment of the invention. An application de-
`veloper 12 creates a software application 14 (application
`Y) fora mobile device that requires access to one or more
`sensitive APIs on the mobile device. The software appli-
`cation Y 14 may, for example, be a Java application that
`operates on a Javavirtual machine installed on the mo-
`bile device. An API enables the software application Y
`to interface with an application platform that may include,
`for example, resources such asthe device hardware, op-
`erating system and core software and data models. In
`order to makefunction 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 AP| access should be interpreted to include
`access of an API in such a wayasto 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 pre-
`vents the software application Y from interacting with the
`associated resources. For example, a database API may
`communicate with a devicefile or data storage system,
`and access to the database AP! would provide for inter-
`action 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 re-
`
`ceiver. Similarly, a cryptographic API may be provided
`to interact with a crypto module which implements crypto
`algorithms on a device. These are merelyillustrative ex-
`amples of APIs that may be provided on a device. A de-
`vice may include any of these example APIs, or different
`APIs instead of or in addition to those described above.
`[0014]
`Preferably, any API may be classified as sen-
`sitive 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 mayclassify
`as sensitive those APIs that interface with cryptographic
`routines, wireless communication functions, or proprie-
`tary data models such as address book or calendar en-
`tries. To protect against unauthorized access to these
`sensitive APIs, the application developer 12 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 signing authority 16
`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 the software application
`Y 14.
`In one embodiment, a digital signature is ob-
`[0015]
`tained for each sensitive API or library that includes a
`sensitive API to which the software application requires
`access. Insome cases, multiple signatures are desirable.
`This would allow a service provider, company or network
`operator to restrict some or all software applications load-
`ed 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 soft-
`ware application. For example, a company maywish to
`prevent its employees from executing any software ap-
`plications onto their devices without first obtaining per-
`mission 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 APls and
`libraries, if any, could then be further restricted, depend-
`ent upon verification of respective corresponding digital
`signatures.
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`Page 514 of 1415
`
`Page 514 of 1415
`
`
`
`5
`
`EP 2 278 429 A1
`
`6
`
`[0016] The binary executable representation of soft-
`ware application Y 14 may be independentof the partic-
`ular type of mobile device or model of a mobile device.
`Software application Y 14 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 de-
`sirable to have a digital signature for each mobile device
`type or model, or alternatively for each mobile device
`platform or manufacturer. Therefore, software applica-
`tion Y 14 may be submitted to several code signing au-
`thorities if software application Y 14 targets several mo-
`bile devices.
`[0017]
`Software application Y 14 is sent from the ap-
`plication developer 12 to the code signing authority 16.
`In the embodiment shownin FIG. 1, the code signing
`authority 16 reviews the software application Y 14, al-
`though as described in further detail below, it is contem-
`plated that the code signing authority 16 may also or in-
`stead consider the identity of the application developer
`12 to determine whether or not the software application
`Y 14 should be signed. The code signing authority 16 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.
`[0018]
`If the code signing authority 16 determines that
`software application Y 14 may accessthe sensitive API
`and therefore should be signed, then a signature (not
`shown) for the software application Y 14 is generated by
`the code signing authority 16 and appended to the soft-
`ware application Y 14. The signed software application
`Y 22, comprising the software application Y 14 and the
`digital signature, is then returned to the application de-
`veloper 12. The digital signature is preferably a tag that
`is generated using a private signature key 18 maintained
`solely by the code signing authority 16. For example,
`according to one signature scheme, a hash of the soft-
`wareapplication Y 14 may be generated, using a hashing
`algorithm such as the Secure Hash Algorithm SHA1, and
`then used with the private signature key 18 to create the
`digital signature. In some signature schemes, the private
`signature key is used to encrypt a hash ofinformation to
`be signed, such as software application Y 14, whereas
`in other schemes, the private key may be usedin other
`waysto generate a signature from the information to be
`signed or a transformed version of the information.
`[0019] The signed software application Y 22 may then
`be sent to a mobile device 28 or downloaded by the mo-
`bile device 28 over a wireless network 24.
`It should be
`
`understood, however, that a code signing protocol ac-
`cording to the present invention is not limited to software
`applications that are downloaded over a wireless net-
`work. For instance,
`in alternative embodiments,
`the
`signed software application Y 22 may be downloaded to
`a personal computer via a computer network and loaded
`to the mobile device through a serial link, or may be ac-
`quired from the application developer 12 in any other
`
`manner and loaded onto the mobile device. Once the
`signed software application Y 22 is loaded on the mobile
`device 28, each digital signature is preferably verified
`with a public signature key 20 before the software appli-
`cation Y 14 is granted access to a sensitive API library.
`Although the signed software application Y 22 is loaded
`onto a device, it should be appreciated that the software
`application that may eventually be executed on the de-
`vice is the software application Y 14. As described above,
`the signed software application Y 22 includes the soft-
`ware application Y 14 and one or more appended digital
`signatures (not shown), When the signaturesare verified,
`the software application Y 14 can be executed on the
`device and access any APIs for which corresponding sig-
`natures have been verified.
`[0020] The public signature key 20 corresponds to the
`private signature key 18 maintained by the code signing
`authority 16, and is preferably installed on the mobile
`device along with the sensitive API. However, the public
`key 10 may instead be obtained from a public key repos-
`itory (not shown), using the device 28 or possibly a per-
`sonal computer system, and installed on the device 28
`as needed. According to one embodiment of a signature
`scheme, the mobile device 28 calculates a hash of the
`software application Y 14 in the signed software applica-
`tion Y 22, using the same hashing algorithm as the code
`signing authority 16, and uses the digital signature and
`the public signature key 20 to recover the hash calculated
`by the signing authority 16. The resultant locally calcu-
`lated hash and the hash recovered from the digital sig-
`nature are then compared, and if the hashes are the
`same, the signatureis verified. The software application
`Y 14 can then be executed on the device 28 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 sys-
`tems described herein.
`[0021]
`FIG. 2 is a flow diagram 30 of the code signing
`protocol described above with reference to FIG. 1. The
`protocol begins at step 32. At step 34, a software devel-
`oper writes the software application Y for a mobile device
`that requires access to a sensitive API or library that ex-
`poses a sensitive API
`(API
`library A). As discussed
`above, some or all APIs on a mobile device maybe clas-
`sified as sensitive, thus requiring verification of a digital
`signature for access by any software application such as
`software application Y. In step 36, application Y is tested
`by the software developer, preferably using a device sim-
`ulator in which the digital signature verification function
`has been disabled. In this manner, the software devel-
`oper may debug the software application Y before the
`digital signature is acquired from the code signing au-
`thority. Once the software application Y has been written
`and debugged, it is forwardedto the code signing author-
`ity in step 38.
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`Page 515 of 1415
`
`Page 515 of 1415
`
`
`
`7
`
`EP 2 278 429 A1
`
`8
`
`In steps 40 and 42, the code signing authority
`[0022]
`reviews the software application Y to determine whether
`or not it should be given accessto the sensitive API, and
`either accepts or rejects the software application. The
`code signing authority may apply a number ofcriteria to
`determine whether or not to grant the software applica-
`tion 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 applica-
`tions, the inclusion of a virus or other destructive code,
`and whether or not the developer has a contractual ob-
`ligation or other business arrangement with the mobile
`device manufacturer. Further details of managing code
`signing authorities and developers are described below
`in reference to FIG. 5.
`[0023]
`If the code signing authority accepts the soft-
`ware application Y, then a digital signature, and prefer-
`ably a signature identification, are appended to the soft-
`ware application Y in step 46. As described above, the
`digital signature may be generated by using a hash of
`the software application Y and a private signature key
`18. The signature identification is described below with
`reference to FIGS. 3 and 4. Oncethe digital signature
`and signatureidentification are appendedto the software
`application Y to generate a signed software application,
`the signed software application Y is returned to the soft-
`ware developer in step 48. The software developer may
`then license the signed software application Y to be load-
`ed onto a mobile device (step 50).
`If the code signing
`authority rejects the software application Y, however,
`then a rejection notification is preferably sent to the soft-
`ware developer (step 44), and the software application
`Y will be unable to access any AP|(s) associated with the
`signature.
`[0024]
`In an alternative embodiment, the software de-
`veloper mayprovide the code signing authority with only
`a hash of the software application Y, or provide the soft-
`ware 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 dig-
`ital signature operations when software applications are
`intended for operation on particular devices