25
`
`EP 2 284 644 A1
`
`26
`
`Claims
`
`1.
`
`A mobile device (62) comprising:
`
`an application platform having application pro-
`gramming interfaces (APls), 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 corresponds with 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 comprises the 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 access at least
`one of a cryptographic module, which implements
`cryptographic algorithms, a data store, a proprietary
`data model, and a user interface (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 ofthe APls 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 (APls) on a mobile device, in—
`cluding the step of allowing a software application
`onthedeviceto access atleastoneoftheAPlswhere
`a signature identifier 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 mobile
`device where the signature identification does
`not correspond with the signature identifier.
`
`The method of claim 8 or 9, wherein the digital sig—
`nature and the signature identification are generated
`by a code signing authority.
`
`The method of 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.
`
`1D
`
`15
`
`20
`
`30
`
`35
`
`10.
`
`11.
`
`12.
`
`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 method of any of claims 8 to 13 comprising the
`additional step of:
`
`displaying a description string that notifies a user
`ofthe 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 of1415
`
`GOOGLE EXHIBIT 1004
`
`Part 2 of 3
`
`Page 501 of 1415
`
`GOOGLE EXHIBIT 1004
`Part 2 of 3
`
`

`

`EP 2 284 644 A1
`
`Application
`
`Y
`16
`
`18
`
`
`
`Application
`
`Code signer
`12
`Developer Y
`
`P
`
`
`
`
`
`Signed
`Application
`Y
`
`
`
` Signed
`
`Application
`y
`
`22
`
`Wireless
`
`Network
`
`22
`
`10/
`
`Page 502 of 1415
`
`Figure 1
`
`15
`
`Page 502 of 1415
`
`

`

`EP 2 284 644 A1
`
` Application Y uses
`
`meryA
`
`
`Figu re 2
`
`30\
`
`Test Appliaflon Y
`
`In device simulabt
`
`with no signature
`verification.
`
`
`
`Signing Auttvomy
` Applieafion Y
`reviewed by Cat
`Signing Authority
`
`
`Application Y
`
`forwarded toCode
`
`
`Rejection
`Code Signhg
`
`
`Notification to
`Authority signs
`
`
`
`Software
`Appficafion Y with
`
`
`
`Developer
`Digital Signanu
`
`
`
`
`
`
`Return Application
`43
`
`Y to 50m
`
`
`Develops: with
`
`Appended Digital
`Signatwa
`
`52
`
`
`
`
` Application Y
`
`loaded on Mable
`Device.
`
`
`
`Page 503 of 1415
`
`16
`
`Page 503 of 1415
`
`

`

`EP 2 284 644 A1
`
`~----------_----“----m-__-_-*--nuu--_-----au---—---o——-----u-----—-—------—--—---a~~--~a
`
`IIIIII
` IIICIISIIDI’IIII3tSIIDIII
`
`llllllllllllllllllllllllllllllllllllllllll
`
`AP! Library A M1?! unsiflve AP!
`
`Wnual Madam
`
`
`
`Digital Signature
`
`—C
`
`
`IIIII!!!fillllllltlv
`IIIIOIIIIIIIIOIDIIIIUIOlIII
`
`Mobule Deuce
`
`Figu re 3
`
`17
`
`Page 504 of 1415
`
`Page 504 of 1415
`
`

`

`EP 2 284 644 A1
`
`............................................................................................................................................................
`
`
`
`Libraty with sensitive API
`
`Description
`
`.
`
`Application
`Platform 32
`Device
`Hardware
`
`Operating
`System
`
`Core Software
`& Data Models
`
`
`
`Application Y
`(signed)
`94E
`965
`
`Signature lD—E. ’
`
`Signature - E
`
`Signature lD - F
`
`Signature - F .
`
`
`
`
`
`
`
`Virtual Machine
`
`
`
`WZW
`
`Mobile Device
`
`Mobile Device
`.......................................................................................................................................................
`
`
`Mobile Device
`
`
`j
`
`61
`
`626
`
`Figure 3A
`
`18
`
`Page 505 of 1415
`
`Page 505 of 1415
`
`

`

`EP 2 284 644 A1
`
`1C?
`
`Does Application
`New Awess in Sensitive
`AP! Ubrmy?
`
`104
`
`
`V‘
`
`Yes
`
`Vanna! Mach?»
`
`
`Retrieves Public
`Key and 359mm
`ldentifiar from AP!
`Library
`
`
`
`
`
`
`
`108
`
`
`Proper
`Signature on
`- n inafim?
`
`
`Yes
`
`1 1o
`
`Stgna‘m
`Verified?
`
`Yes
`
`Figu re 4
`
`100\
`
`No
`
`”0
`
`116
`
`Application Not
`Loaded of
`
`Executed
`12)
`
`1 1 6
`
`Virtual Machine
`executes
`Application and
`“an3 with AP!
`Library
`
`Page 506 of 1415
`
`19
`
`Page 506 of 1415
`
`

`

`EP 2 284 644 A1
`
`21 0
`
`Application
`‘ Developed
`
`220
`
`
`
`Receive Target
`Signing Request
`
`230
`
`
`
`N
`
`240
`
`250
`
`
`
`:,,
`,
`Reject Application
`
`
`
`270
`
`N
`
`'
`Reject Application
`
`.
`'
`
`
`
`
`Develo er
`Developer
`
`
`Databapse
`TmSted by
`Authority?
`
`
`
`Target
`Private Key
`Database
`
`
`~~
`
`HavSeTirget
`y '
`
`
`
`
`
`260
`
`280 L200
`
`Sign Application
`
`Return
`
`‘
`
`Signature
`
`Figure 5
`
`20
`
`Page 507 of 1415
`
`Page 507 of 1415
`
`

`

`EP 2 284 644 A1
`
`
`
`Jossaomdomgw
`
`I
`
`H
`Auxiiiary IIO
`628
`
`Serial Port
`0)
`
`§8 a
`
`5.5<
`632
`
`634
`
`Wcrophone
`
`638
`
`636
`
`614
`
`5.11 """""
`
`.BiQ
`
`Figure 6
`
`Other Device
`Subsystems
`642
`
`Short-Range
`Communications
`640
`
`Page 508 of 1415
`
`21
`
`Page 508 of 1415
`
`

`

`EP 2 284 644 A1
`
`Europiiflhes
`Patentamt
`European
`ofnce européen
`Patent Olfice
`
`des brevets
`
`EUROPEAN SEARCH REPORT
`
`Application Number
`EP 10 18 3655
`
`
`DOCUMENTS CONSIDERED TO BE RELEVANT
`CLASSIFICATION OF THE
`Citation of document with indication, where appropriate,
`of relevant ooassaes
`APPLICATION (IPC)
`
`Relevant
`to claim
`
`Category
`
`INV.
`GOGFl/OO
`
`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,
`voI. 7816—4:1995(E),
`1 January 1995 (1995-01-01), pages
`I-IV,1-46, XP008124701,
`* page 12 *
`
`"ISO/IEC 7816-8:
`ANONYMOUS:
`IDENTIFICATION CARDS -- INTEGRATED CIRCUIT
`CARDS - PART 8: COMMANDS FOR SECURITY
`OPERATIONS",
`INTERNATIONAL STANDARD ISO/IEC,
`v01. 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 ISO/IEC,
`v01. 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 up for all claims
`
`Examiner
`PIace of search
`Date of completIon of the search
`
`Munich
`CATEGORY OF CITED DOCUMENTS
`
`X: particularly relevant if taken alone
`Y: particularly relevant if combined with another
`document oi the same category
`A: technological background
`C): non-written disclosure
`P : intermediate document
`
`Kerschbaumer, J
`25 November 2010
`T : theory or principle underlying the Invention
`E : earlier patent document: but published on, or
`after the filing date
`D : document cited in the application
`L ' document cited for other reasons
`a. : member of the same patent family, corresponding
`document
`
`LA)
`
`3m)
`
`
`
`
`
`
`
`EFOFOFWI150303.62(P00
`
`Page 509 0f1415
`
`22
`
`Page 509 of 1415
`
`

`

`Europiiisches
`Patentamt
`European
`
`
`
`37.112221"
`um
`
`EP 2 284 644 A1
`
`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, XP007908384,
`ISBN: 978—3—446—21115—5
`* Document concicts of pages 197-203,
`261-273, 740-741, 794-797 *
`* pages 269,272; figure 5.39 *
`
`
`
`
`
`
`
`
`
`_ECHN|CALSEARCHED_IPC)FIELDS
`
`The present search report has been drawn up for all claims
`Place of search
`Date 01 completion of the search
`Examiner
`
`Munich
`25 November 2010
`Kerschbaumer, J
`CATEGORY OF CITED DOCUMENTS
`T: theow or principle underlying the invention
`E: earlier patent document, but published on, or
`X . particularly relevant if taken alone
`after the filing date
`D. document cited in the application
`Y : particularly relevant if combined with another
`'
`document of the same category
`A : technological background
`
`
`.
`mber of the same patent family, corresponding
`O : non-written disclosure
`
`document
`P : intermediate document
`
`3
`
`Ou.
`§
`5
`:
`g
`3
`:
`i
`8
`l_l_l
`r‘o
`
`Page 510 of 1415
`
`23
`
`Page 510 of 1415
`
`

`

`REFERENCES CITED IN THE DESCRIPTION
`
`EP 2 284 644 A1
`
`This list of references cited by the applicant is for the reader’s convenience only. It 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 EPO disclaims all liability in this regard.
`
`Patent documents cited in the description
`
`-
`°
`
`US 23415200 P [0001]
`US 23535400 P [0001]
`
`0
`
`US 27066301 P [0001]
`
`Page 511 of 1415
`
`24
`
`Page 511 of 1415
`
`

`

`Europfilsches
`Patentamt
`Eu rope: n
`Patent Office
`Office eu ropé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 C|.:
`GosF 1/00 (2006-01)
`
`(21) Application number: 10183997.5
`
`(22) Date of filing: 20.09.2001
`
`
`(84) Designated Contracting States:
`AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU
`MC NL PT SE TR
`
`(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 I 1 626 324
`01973901.0 I1 320 795
`
`(71) Applicant: Research In Motion Limited
`Waterloo, ON N2L 3W8 (CA)
`
`0 Brown, Michael S
`Heidelberg Ontario (CA)
`0 Little, Herbert A
`Waterloo Ontario (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 lNlD code 62.
`
`(72) Inventors:
`° Yach, David P
`Waterloo Ontario (CA)
`
`
`(54)
`
`Software code signing system and method
`
`A code signing system and method is 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
`configured to link the software application with the appli—
`cation platform. The virtual machine verifies the authen-
`ticity of the digital signature in orderto control access to
`the API by the software application.
`
`12
`
`14
`Application
`
`Signed
`Application
`Y
`f
`
`\
`22
`
`:1
`
`'
`
`r
`
`18
`
`Application
`Developer Y
`
`
`
`
`
`
`16
`
`CO a 5'9“
`
`
`Wireless
`Network
`
`Signed
`22f Application
`Y
`
`
`
`
`Figure 1
`
`10/
`
`Printed by Jouve, 75001 PARIS (FR)
`
`EP2278429A1
`
`Page 512 of 1415
`
`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. More partic-
`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 ensure the reliability of software appli—
`cations thatare 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. Once the software is downloaded by a
`user, the user typically must use his or herjudgment 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 does not 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. Because typical code signing protocols are not
`secure and rely solely on the judgment ofthe 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.
`
`1D
`
`15
`
`20
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`[0006] Acode signing 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] A code 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 orderto control access to the plu—
`rality of APIs by the software application.
`[0008] According to a further embodiment ofthe inven-
`tion, a method of controlling access to sensitive applica—
`tion programming interfaces on a mobile device compris—
`es the steps ofloading 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 access to the sensitive
`API.
`
`In another embodiment ofthe 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 access the API, then appending a digital signa-
`ture to the software application, verifying the authenticity
`ofa digital signature appended to a software application,
`and providing access to the API to software applications
`for which the appended digital 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
`ofthe registered software developers, and ifthe 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 appended to 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 orderto 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
`on a 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 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
`
`[0012]
`
`FIG. 1 is a diagram illustrating a code signing proto—
`col according to one embodiment of the invention;
`FIG. 2 is a flow diagram ofthe 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 ofa 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 ofa 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) for a 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 Java virtual 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 as the device hardware, op-
`erating 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 pre-
`vents 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 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 mayalso be provided as an interface to wireless
`communication resources such as a transmitter and re—
`
`ceiver. Similarly, a cryptographic API may be provided
`to interactwith a crypto module which implements crypto
`algorithms on a device. These are merely illustrative 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 may classify
`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. In some cases, multiple signatures are desirable.
`This would allow a service provider, company or network
`operatorto 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 may wish 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 APIs and
`libraries, if any, could then be further restricted, depend-
`ent upon verification of respective corresponding digital
`signatures.
`
`1D
`
`15
`
`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 independent of 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 shown in 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 APls,
`or possibly others that have knowledge of the operation
`of the sensitive APIs to which the software application
`needs access.
`[0018]
`lfthe code signing authority 16 determines that
`software application Y 14 may access the 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-
`ware application 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 of information to
`be signed, such as software application Y 14, 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.
`[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 computervia 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 (notshown). When the signatures are verified,
`the software application Y 14 can be executed on the
`device and access anyAPls 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 ofa 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 signature is verified. The software application
`Y 14 can then be executed on the device 28 and access
`any sensitive APIs forwhich 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 ofthe code signing
`protocol described above with reference to FIG. 1. The
`protocol begins at step 32. At step 34, a software devel-
`operwrites the software application onr 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 may be 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 isforvvarded to the code signing author—
`ity in step 38.
`
`1D
`
`15
`
`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 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 applica-
`tion access to the sensitive API including, for example,
`the size ofthe software application, the device resources
`accessed bythe API, the perceived utility ofthe 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. 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 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 anyAPl(s) associated with the
`signature.
`[0024]
`In an alternative embodiment, the software de-
`veloper may provide the code signing authority with only
`a hash of the software application Y, or provide the soft-
`ware application Y in some type of ab