(12) United States Patent
`Yach et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 8,489,868 B2
`Jul. 16, 2013
`
`US008489868B2
`
`(54)
`
`(75)
`
`SOFTWARE CODE SIGNING SYSTEM AND
`METHOD
`
`Inventors: David P. Yach, Waterloo (CA); Michael
`S. Brown, Waterloo (CA); Herbert A.
`Little, Waterloo (CA)
`
`(73)
`
`Assignee:
`
`Research In Motion Limited, Waterloo,
`Ontario (CA)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(1)) by 1974 days.
`
`(21)
`
`(22)
`
`(86)
`
`(87)
`
`(65)
`
`(60)
`
`(51)
`
`(52)
`
`Appl. N0.:
`
`10/381,219
`
`PCT Filed:
`
`Sep. 20, 2001
`
`PCT No.:
`8371 (0)0)s
`(2), (4) Date:
`
`PCT/CA01/01344
`
`Mar. 20, 2003
`
`PCT Pub. No.: WO02/25409
`
`PCT Pub. Date: Mar. 28, 2002
`
`Prior Publication Data
`
`US 2004/0025022 A1
`
`Feb. 5, 2004
`
`Related US. Application Data
`
`Provisional application No. 60/234,152, ?led on Sep.
`21, 2000, provisional application No. 60/235,354,
`?led on Sep. 26, 2000, provisional application No.
`60/270,663, ?led on Feb. 20, 2001.
`
`I t. Cl.
`G110 6 F 21/00
`U 5 Cl
`
`(2006 01)
`'
`
`(58) Field of Classi?cation Search
`None
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,625,690 A
`4/1997 Michel et a1.
`5,978,484 A 11/1999 Apperson et al.
`(Continued)
`FOREIGN PATENT DOCUMENTS
`9736815
`2/1998
`1541350
`10/2004
`(Continued)
`OTHER PUBLICATIONS
`
`AU
`CN
`
`Adams, Carlisle. IDUP and SPKM: Developing Pubic-Key-Based
`APIs and Mechanisms for Communication Security Services. Pro
`ceedings of the Symposium on Network and Distributed System
`Security. Pub. Date: 1996. Relevant pp. 128- 13 5. Found on the World
`Wide Web at:
`http://ieeeXplore.ieeeorg/stamp/stampjsp?tp:
`&arnumber:4924 19 .*
`
`(Continued)
`Primary Examiner * Nathan Flynn
`Assistant Examiner * Jeremiah Avery
`(74) Attorney, Agent, or Firm * Jon A. Gibbons; Fleit
`Gibbons Gutman Bongini & Bianco PL
`
`ABSTRACT
`(57)
`A code signing system and method is provided. The code
`signing system operates in conjunction with a signed soft
`ware application having a digital signature and includes an
`application platform, an application programming interface
`(API), and a virtual machine. The API is con?gured to link the
`software application with the application platform. The vir
`tual machine veri?es the authenticity of the digital signature
`in order to control access to the API by the software applica
`
`USPC ............. .. 713/1; 713/176; 713/187; 713/189;
`719/328; 711/100
`
`non‘
`
`144 Claims, 7 Drawing Sheets
`
`f\8o
`I
`Application
`Platform B2
`
`f\7a
`Library with sensitive API
`
`[\m n
`Application Y
`(algnsd)
`
`onerellns
`
`Syslem
`Cars Software
`& Dala Models
`
`,
`
`Descnpllnn F313;? Signature
`smng
`signature
`‘Gamma’
`
`i
`
`7'
`
`1.. 98 i941
`
`Signature ID - F
`
`Signature-F )
`96F liMF
`
`Vll'tLlBl Machine
`
`Q.
`
`l
`‘.
`
`Mobile Device
`Mobile Device
`/‘
`\ Moblle Device /'
`
`,1)
`
`Page 1 of 22
`
`GOOGLE EXHIBIT 1001
`
`

`

`US 8,489,868 B2
`Page 2
`
`US. PATENT DOCUMENTS
`6,067,582 A
`5/2000 Smith et al.
`6,157,721 A 12/2000 Shear et al.
`6,212,636 B1* 4/2001 Boyle et al. ................. .. 713/168
`6,223,291 B1
`4/2001 Puhl et al.
`. 713/172
`6,233,683 B1* 5/2001 Chan et al. ..
`6,256,737 B1* 7/2001 Bianco et al. ............... .. 713/186
`6,289,382 B1
`9/2001 BoWman-Amuah
`6,324,650 B1* 11/2001 Ogilvie ........................... .. 726/2
`6,345,256 B1* 2/2002 Milsted et al.
`.. 705/64
`6,374,357 B1 *
`4/2002 Mohammed et al.
`726/5
`6,390,374 B1 *
`5/2002 Carper et al. ............... .. 235/492
`6,526,513 B1
`2/2003 Shrader et al.
`6,574,609 B1 *
`6/2003 Downs et al. ................. .. 705/50
`6,584,376 B1* 6/2003 Van Kommer .............. .. 700/245
`6,587,837 B1* 7/2003 Spagna et al. .
`705/52
`6,697,948 B1* 2/2004 Rabin et al.
`726/30
`6,748,541 B1 *
`6/2004 Margalit et al. ................. .. 726/9
`6,766,353 B1
`7/2004 Lin et al.
`6,795,919 B1* 9/2004 Gibbs et al. ................. .. 713/170
`6,795,923 B1 *
`9/2004 Stern et al.
`726/12
`6,895,507 B1* 5/2005 Teppler
`726/19
`7,243,236 B1 *
`7/2007 Sibert ......................... .. 713/179
`2001/0044901 A1* 11/2001 GraWrock ................... .. 713/189
`8/2002 Yach
`2002/0112078 A1
`2002/0128036 A1
`9/2002 Yach et al.
`2003/0026231 A1
`2/ 2003 LaZaridis et al.
`2003/0159029 A1
`8/ 2003 Brown et al.
`2004/0166834 A1
`8/ 2004 Omar et al.
`2004/0170155 A1
`9/ 2004 Omar et al.
`2004/0171369 A1
`9/ 2004 Little et al.
`2004/0171374 A1
`9/ 2004 Little et al.
`2004/0199665 A1
`10/2004 Omar et al.
`2004/0202327 A1
`10/ 2004 Little et al.
`2004/0205330 A1 10/2004 Godfrey et al.
`2005/0009502 A1
`1/2005 Little et al.
`
`CN
`CN
`CN
`CN
`EP
`EP
`EP
`EP
`EP
`EP
`EP
`EP
`EP
`HK
`HK
`HK
`HK
`WO
`WO
`
`FOREIGN PATENT DOCUMENTS
`100573402
`12/2009
`101694687
`4/2010
`101694688
`5/2010
`101714201
`5/2011
`0930793
`7/1999
`1320795
`11/2005
`1626324
`2/2006
`1626325
`9/2010
`1626326
`9/2010
`2278429
`1/2011
`2284644
`2/2011
`2306259
`4/2011
`2306260
`4/2011
`1055629
`5/2006
`1091666
`1/2007
`1091665
`11/2010
`1091667
`11/2010
`9905600
`2/1999
`02/25409
`3/2002
`
`OTHER PUBLICATIONS
`
`Communication of Notices of Opposition (R. 57(1) EPC) dated Sep.
`26, 2006 and Working Translation, 16 pages.
`. ”, Part 9: Additional
`ISO/IEC FCD 7816-9 “Identi?cation cards .
`.
`interindustry commands and security attributes, Jun. 17, 1999, S. 8
`bis 13, 29 bis 31 (D5), 12 pages.
`. ”, Part 8: Security
`.
`ISO/IEC FDIS 7816-8 “Identi?cation cards .
`related interindustry commands, Jun. 25, 1998, S. 2, 3, 6 bis 13 (D6),
`13 pages.
`TechnologyiIdenti?cation
`“Information
`7816-4
`ISO/IEC
`Cards .
`.
`. ”, Part 4: Interindustry Commands for Interchange, 1995,
`S. 12 bis 16 (D7), 6 pages.
`European Search Report issued on May 15, 2009 in connection With
`European Patent Application No. 050246628.
`Rankl, Wolfgang, et al., Handbuch der Chipkarten, Aufbaui
`FIlIIkIIOIISWGISGiEIIISQIZ von Smart Cards, Hanser, 1999iin Ger
`man.
`Notice of Abandonment. Canadian Application No. 2,422,917.
`Dated: Jun. 20, 2011.
`
`First Of?ce Action. Chinese Application No. 200910207911.0.
`Dated: Aug. 10, 2011.
`Extended European Search Report. European Application No.
`101861946. Dated: Jun. 22, 2011.
`Communication Pursuant to Rules 70(2) and 70a(2) and Reference to
`Rule 39(1) EPC. European Application No. 101861946. Dated: Jul.
`25, 201 1.
`Communication Pursuant to Article 94(3) EPC. European Applica
`tion No. 101836559. Dated: Feb. 23, 2011.
`Communication Pursuant to Article 94(3) EPC. European Applica
`tion No. 101836559. Dated: Jul. 13,2011.
`Extended European Search Report (EESR). European Application
`No. 101839975. Dated: Dec. 12, 2010.
`Communication Pursuant to Article 94(3) EPC. European Applica
`tion No. 101839975. Dated: Feb. 23, 2011.
`Communication Pursuant to Article 94(3) EPC. European Applica
`tion No. 101839975. Dated: Jul. 14,2011.
`Extended European Search Report. European Application No.
`101862969. Dated: Jun. 22, 2011.
`Communication Pursuant to Rules 70(2) and 70a(2) and Reference to
`Rule 39(1) EPC. European Application No. 101862969. Dated: Jul.
`25, 201 1.
`Invitation pursuant to Article 94(3) and Rule 71(1) EPC dated Sep.
`28, 2011, European Patent Application No. 101862969.
`First Of?ce Action. Chinese Application No. 200910209311.8.
`Dated: Oct. 19,2011.
`Chinese Of?ce Action dated Sep. 8, 201 1, Chinese PatentApplication
`No. 2009102079125.
`Notice of Abandonment. Canadian Application No. 2,422,917.
`Dated: Nov. 15, 2011.
`Notice of Allowance. Canadian Application No. 2,422,917. Dated:
`Sep. 27, 2010.
`Of?ce Action. Canadian Application No. 2,422,917. Dated: Mar. 4,
`2009.
`Of?ce Action. Canadian Application No. 2,422,917. Dated: Mar. 13,
`2008.
`Written Opinion. Application No. PCT/CA01/01344. Dated: May
`28, 2002.
`International Search Report. Application No. PCT/CAO 1/ 01344.
`Dated: Apr. 22, 2002.
`Preliminary Examination Report. Application No. PCT/CA01/
`01344. Dated: Nov. 15, 2002.
`Communication under Rule 51(4) EPC. European Application No.
`019739010. Dated: May 6, 2005.
`Communication of a notice of opposition. European Application No.
`019739010. Dated: Aug. 21, 2006.
`Observations to opposition. European Application No. 019739010.
`Dated: May 7, 2007.
`Handbuch Der Chipkarten, “Sicherung der Datenubertragung”.
`Summons to attend oral proceedings pursuant to Rule 115(1) EPC.
`European Application No. 019739010. Dated: Mar. 20, 2008.
`Provision of the minutes in accordance With Rule 124(4) EPC. Euro
`pean Application No. 019739010. Dated: Dec. 22, 2008.
`Interlocutory decision in Opposition proceedings (Art. 101(3)(a) and
`106(2) EPC). European Application No. 019739010. Dated: Dec.
`22, 2008.
`First Of?ce Action (English translation). Chinese Application No.
`018192009. Dated: Aug. 26, 2005.
`Second Of?ce Action (English translation). Chinese Application No.
`018192009. Dated: May 30, 2008.
`Rejection Decision (English translation). Chinese Application No.
`018192009. Dated: Sep. 26, 2008.
`Request for Reexamination. Chinese Application No. 018192009.
`Dated: Dec. 24, 2008.
`Third Of?ce Action (English translation). Chinese Application No.
`018192009. Dated: Apr. 17,2009.
`Certi?cate of Invention Patent (English translation). Chinese Appli
`cation No. 018192009. Dated: Dec. 23, 2009.
`Noting of loss of rights pursuant to Rule 112(1) EPC. European
`Application No. 050246610. Dated: Dec. 16, 2011.
`Communication under Rule 71(3) EPC. European Application No.
`050246610. Dated: Jun. 29, 2011.
`
`Page 2 of 22
`
`

`

`US 8,489,868 B2
`Page 3
`
`Extended European Search Report (EESR). European Application
`No. 050246610. Dated: May 15, 2009.
`Communication under Rule 71(3) EPC. European Application No.
`050246628. Dated: Feb. 10, 2010.
`Extended European Search Report (EESR). European Application
`No. 050246636. Dated: May 15, 2009.
`Communication under Rule 71(3) EPC. European Application No.
`050246636. Dated: Feb. 10, 2010.
`Extended European Search Report (EESR). European Application
`No. 101836559. Dated: Dec. 30, 2010.
`Extended European Search Report (EESR). European Application
`No. 101839975. Dated: Dec. 21, 2010.
`ISO/IEC 7816-4 Part 4: “Interindustry commands for interchange”
`XP002269400.
`
`Of?ce Action dated May 11, 2012 for US. Appl. No. 13/413,173.
`Of?ce Action dated Nov. 30, 2012 for US. Appl. No. 13/413,173.
`Java Platform Standard Ed. 6, http://docs.oracle.com/javase/6/docs/
`apl/java/lang/re?ect/Methodihtml (last visited Nov. 3, 2012).
`Application programming interface, http://en.Wikipediaorg/Windex.
`php?title:Applicationiprogramming*interface&
`oldid:520968418 (last visited Nov. 3, 2012).
`ETSI TS 123 057 v3.3.0 (Oct. 16, 2000).
`Devanbu, P.T., et al., “Techniques for trusted software engineering.”
`Proceedings of the 20th International Conference on Software Engi
`neering, p. 126-135. Apr. 19-25, Kyoto, Japan.
`ETSI TA 123 057 v3.2.0 (Jun. 23, 2000).
`
`* cited by examiner
`
`Page 3 of 22
`
`

`

`US. Patent
`
`Jul. 16, 2013
`
`Sheet 1 017
`
`US 8,489,868 B2
`
`12/4 Application
`Developer Y
`
`t a .m M p A
`n .m
`
`Signed
`Application
`Y
`
`/16
`Code signer p'xm
`
`2 2
`
`Signed
`Application
`Y
`
`10/
`
`Dvice
`
`CE P1\20
`
`Figure 1
`
`Page 4 of 22
`
`

`

`US. Patent
`
`Jul. 16, 2013
`
`Sheet 2 0f 7
`
`US 8,489,868 B2
`
`32
`
`Start
`
`7
`
`.
`
`.
`
`Application Y uses U
`LibraryA
`
`34
`
`Figure 2
`
`44
`
`Rejection
`Noti?cation to
`Software
`Developer
`
`52
`
`End
`
`'
`
`1
`
`36
`Test Application Y
`in device simulator /
`with no signature
`veri?cation.
`
`l
`
`_
`
`ApplicatronY _/
`fonlvarded toOode
`Signing Authority
`
`38
`
`7
`
`40
`Y
`Application
`reviewed by Code J
`Signing Authority
`
`42
`/
`Accept Code?
`
`46
`Code Signing
`Yes—> Ai‘g?gggg J
`Digital Signature
`
`i
`48
`Return Application
`Y to Software
`Developer with ‘J
`Appended Digital
`Signature
`
`V
`
`50
`Appl' ati n Y
`re 0
`loaded on Mobile J
`Device.
`
`Page 5 of 22
`
`

`

`US. Patent
`
`Jul. 16, 2013
`
`Sheet 3 of7
`
`US 8,489,868 B2
`
`_
`
`.
`
`_
`
`Apphcation Pla?omx
`
`82\ L Device Hardware
`
`84
`\- Operaking Syskem
`
`Core Software &
`Data Models
`
`__ W A \
`
`
`
`_ 111W \1 _ _
`
`_ i. C
`
`.l“ V..
`_ Mm MA .M m5 MS
`" mm 8 mm mm
`“ Xv. m MA mm
`" mw nm mm mm.
`
`H w mm“ mug
`
`_ n.0 .m. ?m mm
`_ w rm mm
`
`" BUY“
`
`. 9
`- 6
`
`_ _
`
`n M m. m.
`_ S S
`
`D D
`
`_ a
`
`u n w.“ m m m
`_ m .U
`
`_ .Mi
`
`_ m W mam
`_ m I We
`_ D e e e
`
`" w c
`
`_ P er
`
`u _
`u _
`
`" M Mm \ . V arm \..\
`
`. l m
`
`. M W.» hen. K.I d Wu
`
`_ \\l N. PS /
`" MA A .wbw W M
`
`_ W5 v m 9
`
`" unwum m WWW m m
`. amw m .m m
`. mm M7 ,mwm / m .w
`
`Figure 3
`
`Page 6 of 22
`
`

`

`US. Patent
`
`Jul. 16, 2013
`
`Sheet 4 of7
`
`US 8,489,868 B2
`
`Application
`Platform T82
`Device
`Hardware
`
`System
`
`Core Software
`& Data Models
`
`km
`
`’
`L86
`
`Library with sensitive API
`
`Description
`strin
`9
`
`U ‘C _ 9y signature
`to Venfy
`identifier
`Signature
`
`6
`88
`
`C L
`2°
`92
`
`K
`
`Application Y
`(signed)
`94E
`96E
`\
`w
`
`Signature - E
`
`Signature ID - F K
`Signature - F
`
`)
`94F
`
`96F
`
`Virtual Machine
`
`!
`
`C64
`
`Mobile Device
`
`
`
`Mobile Device Mobile Device
`
`Figure 3A
`
`Page 7 of 22
`
`

`

`US. Patent
`
`Jul. 16,2013
`
`Sheet 5 of7
`
`US 8,489,868 B2
`
`Application Loaded
`on Mobile Device
`
`1 02
`
`Figure 4
`
`1 O0
`\
`
`104 \
`Does Application
`Need Access to Sensitive
`APl Library?
`
`Yes
`
`106
`Virtual Machine
`Retrieves Public
`\ Key and Signature
`Identi?er from API
`Library
`
`Nc
`
`N°
`
`108
`
`Proper
`Signature on
`Application?
`
`Yes
`
`/— 1 10
`Signature
`Veri? ed’?
`
`Yes
`
`1 12
`User Prompted ~./
`
`17
`
`Application Not
`116
`\/ Loaded or <—————No
`Executed
`
`Yes
`V
`118
`Virtual Machine
`\’ executes
`Application and -<-———‘
`linkds with API
`Library
`
`120
`
`V
`
`End
`
`Page 8 of 22
`
`

`

`US. Patent
`
`Jul. 16, 2013
`
`Sheet 6 of7
`
`US 8,489,868 B2
`
`210
`
`Application
`Developed
`L
`220
`Receive Target /
`Signing Request
`
`235
`
`250
`
`Developer
`
`Database
`
`Developer
`Trusted by
`Authority?
`.
`
`N
`
`Reject Application
`
`245
`f Y
`
`240
`
`270
`
`Target
`Private Key
`Database
`
`Have Target
`Key’)
`
`Reject Application
`
`Y
`
`F 260
`Sign Application /
`280 \/200
`
`Return
`Signature
`
`Figure 5
`
`Page 9 of 22
`
`

`

`Jul. 16, 2013
`
`7f07teehS
`
`US 8,489,868 B2
`
`
`
`wcoszSEEoomEmugmgzw
`
`
`
`mmcmméocw33mm550
`
`m039;
`
`95w
`
`mm
`
`«8.83:00,
`
`
`
`m9.agzxéq
`
`No
`
`
`
`ton._m:mm
`
`o8
`
`Emogox
`
`Now
`
`Microprocessor
`
`$955
`
`U.S. Patent
`
`
`
`Page 10 of 22
`
`

`

`US 8,489,868 B2
`
`1
`SOFTWARE CODE SIGNING SYSTEM AND
`METHOD
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application claims priority from and is related to the
`following prior applications: “Code Signing System And
`Method,” US. Provisional Application No. 60/234,152, ?led
`Sep. 21, 2000; “Code Signing System And Method,” US.
`Provisional Application No. 60/235,354, ?led Sep. 26, 2000;
`and “Code Signing System And Method,” US. Provisional
`Application No. 60/270,663, ?led Feb. 20, 2001.
`
`BACKGROUND
`
`1. Field of the Invention
`This invention relates generally to the ?eld of security
`protocols for software applications. More particularly, the
`invention provides a code signing system and method that is
`particularly well suited for JavaTM applications for mobile
`communication devices, such as Personal Digital Assistants,
`cellular telephones, and wireless two-way communication
`devices (collectively referred to hereinafter as “mobile
`devices” or simply “devices”).
`2. Description of the Related Art
`Security protocols involving software code signing
`schemes are known. Typically, such security protocols are
`used to ensure the reliability of software applications that are
`downloaded from the Internet. In a typical software code
`signing scheme, a digital signature is attached to a software
`application that identi?es the software developer. Once the
`software is downloaded by a user, the user typically must use
`his or her judgment to determine whether or not the software
`application is reliable, based solely on his or her knowledge of
`the software developer’ s reputation. This type of code signing
`scheme does not ensure that a software application written by
`a third party for a mobile device will properly interact with the
`device’s native applications and other resources. Because
`typical code signing protocols are not secure and rely solely
`on the judgment of the user, there is a serious risk that destruc
`tive, “Trojan horse” type software applications may be down
`loaded and installed onto a mobile device.
`There also remains a need for network operators to have a
`system and method to maintain control over which software
`applications are activated on mobile devices.
`There remains a further need in 2.5G and 3G networks
`where corporate clients or network operators would like to
`control the types of software on the devices issued to its
`employees.
`
`SUMMARY
`
`A code signing system and method is provided. The code
`signing system operates in conjunction with a software appli
`cation having a digital signature and includes an application
`platform, an application programming interface (API), and a
`virtual machine. The API is con?gured to link the software
`application with the application platform. The virtual
`machine veri?es the authenticity of the digital signature in
`order to control access to the API by the software application.
`A code signing system for operation in conjunction with a
`software application having a digital signature, according to
`another embodiment of the invention comprises an applica
`tion platform, a plurality of APIs, each con?gured to link the
`software application with a resource on the application plat
`form, and a virtual machine that veri?es the authenticity of
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`the digital signature in order to control access to the API by
`the software application, wherein the virtual machine veri?es
`the authenticity of the digital signature in order to control
`access to the plurality of APIs by the software application.
`According to a further embodiment of the invention, a
`method of controlling access to sensitive application pro
`gramming interfaces on a mobile device comprises the steps
`of loading a software application on the mobile device that
`requires access to a sensitive API, determining whether or not
`the software application includes a digital signature associ
`ated with the sensitive API, and if the software application
`does not include a digital signature associated with the sen
`sitive API, then denying the software application access to the
`sensitive API.
`In another embodiment of the invention, a method of con
`trolling access to an application programming interface (API)
`on a mobile device by a software application created by a
`software developer comprises the steps of receiving the soft
`ware application from the software developer, reviewing the
`software application to determine if it may access the API, if
`the software application may access the API, then appending
`a digital signature to the software application, verifying the
`authenticity of a digital signature appended to a software
`application, and providing access to the API to software
`applications for which the appended digital signature is
`authentic.
`A method of restricting access to a sensitive API on a
`mobile device, according to a further embodiment of the
`invention, comprises the steps of registering one or more
`software developers that are trusted to design software appli
`cations which access the sensitive API, receiving a hash of a
`software application, determining if the software application
`was designed by one of the registered software developers,
`and if the software application was designed by one of the
`registered software developers, then generating a digital sig
`nature using the hash of the software application, wherein the
`digital signature may be appended to the software applica
`tion, and the mobile device veri?es the authenticity of the
`digital signature in order to control access to the sensitive API
`by the software application.
`In a still further embodiment, a method of restricting access
`to application programming interfaces on a mobile device
`comprises the steps of loading a software application on the
`mobile device that requires access to one or more API, deter
`mining whether or not the software application includes a
`digital signature associated with the mobile device, and if the
`software application does not include a digital signature asso
`ciated with the mobile device, then denying the software
`application access to the one or more APIs.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a diagram illustrating a code signing protocol
`according to one embodiment of the invention;
`FIG. 2 is a ?ow 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 ofa code signing system on a
`plurality of mobile devices;
`FIG. 4 is a ?ow diagram illustrating the operation of the
`code signing system described above with reference to FIG. 3
`and FIG. 3A;
`FIG. 5 is a ?ow diagram illustrating the management of the
`code signing authorities described with reference to FIG. 3A;
`and
`
`Page 11 of 22
`
`

`

`US 8,489,868 B2
`
`3
`FIG. 6 is a block diagram of a mobile communication
`device in which a code signing system and method may be
`implemented.
`
`DETAILED DESCRIPTION
`
`Referring now to the drawing ?gures, FIG. 1 is a diagram
`illustrating a code signing protocol according to one embodi
`ment of the invention. An application developer 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 application Y 14 may, for
`example, be a Java application that operates on a Java virtual
`machine installed on the mobile device. An API enables the
`software applicationY to interface with an application plat
`form that may include, for example, resources such as the
`device hardware, operating system and core software and
`data models. In order to make function calls to or otherwise
`interact with such device resources, a software applicationY
`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, refer
`ences to API access should be interpreted to include access of
`an API in such a way as to allow a software applicationY to
`interact with one or more corresponding device resources.
`Providing access to any API therefore allows a software appli
`cationY to interact with associated device resources, whereas
`denying access to an API prevents the software applicationY
`from interacting with the associated resources. For example,
`a database API may communicate with a device ?le or data
`storage system, and access to the database API would provide
`for interactionbetween a software applicationY and the ?le or
`data storage system. A user interface (UI) API would com
`municate with controllers and/or control software for such
`device components as a screen, a keyboard, and any other
`device components that provide output to a user or accept
`input from a user. In a mobile device, a radio API may also be
`provided as an interface to wireless communication resources
`such as a transmitter and receiver. Similarly, a cryptographic
`API may be provided to interact with a crypto module which
`implements crypto algorithms on a device. These are merely
`illustrative examples of APIs that may be provided on a
`device. A device may include any of these example APIs, or
`different APIs instead of or in addition to those described
`above.
`Preferably, any API may be classi?ed as sensitive by a
`mobile device manufacturer, or possibly by an API author, a
`wireless network operator, a device owner or operator, or
`some other entity that may be affected by a virus or malicious
`code in a device software application. For instance, a mobile
`device manufacturer may classify as sensitive those APIs that
`interface with cryptographic routines, wireless communica
`tion functions, or proprietary data models such as address
`book or calendar entries. 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 classi?ed 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 applicationY 14.
`In one embodiment, a digital signature is obtained for each
`sensitive API or library that includes a sensitive API to which
`the software application requires access. In some cases, mul
`tiple signatures are desirable. This would allow a service
`provider, company or network operator to restrict some or all
`software applications loaded or updated onto a particular set
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`of mobile devices. In this multiple-signature scenario, all
`APIs are restricted and locked until a “global” signature is
`veri?ed for a software application. For example, a company
`may wish to prevent its employees from executing any soft
`ware applications onto their devices without ?rst obtaining
`permission from a corporate information technology (IT) or
`computer services department. All such corporate mobile
`devices may then be con?gured to require veri?cation of at
`least a global signature before a software application can be
`executed. Access to sensitive deviceAPIs and libraries, if any,
`could then be further restricted, dependent upon veri?cation
`of respective corresponding digital signatures.
`The binary executable representation of software applica
`tionY 14 may be independent of the particular type of mobile
`device or model of a mobile device. Software applicationY 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 desirable to have a digital signature for
`each mobile device type or model, or alternatively for each
`mobile device platform or manufacturer. Therefore, software
`applicationY 14 may be submitted to several code signing
`authorities if software applicationY 14 targets several mobile
`devices.
`Software application Y 14 is sent from the application
`developer 12 to the code signing authority 16. In the embodi
`ment shown in FIG. 1, the code signing authority 16 reviews
`the software applicationY 14, although as described in further
`detail below, it is contemplated that the code signing authority
`16 may also or instead consider the identity of the application
`developer 12 to determine whether or not the software appli
`cationY 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
`sensitiveAPIs to which the software application needs access.
`If the code signing authority 16 determines that software
`applicationY 14 may access the sensitive API and therefore
`should be signed, then a signature (not shown) for the soft
`ware applicationY 14 is generated by the code signing author
`ity 16 and appended to the software application Y 14. The
`signed software application Y 22, comprising the software
`applicationY 14 and the digital signature, is then returned to
`the application developer 12. The digital signature is prefer
`ably 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
`software applicationY 14 may be generated, using a hashing
`algorithm such as the Secure HashAlgorithm SHAl, 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 applicationY 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.
`The signed software applicationY 22 may then be sent to a
`mobile device 28 or downloaded by the mobile device 28 over
`a wireless network 24. It should be understood, however, that
`a code signing protocol according to the present invention is
`not limited to software applications that are downloaded over
`a wireless network. For instance, in alternative embodiments,
`the signed software applicationY 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 acquired 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
`
`Page 12 of 22
`
`

`

`US 8,489,868 B2
`
`5
`is preferably veri?ed with a public signature key 20 before the
`software applicationY 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 soft
`ware application that may eventually be executed on the
`device is the software applicationY 14. As described above,
`the signed software application Y 22 includes the software
`applicationY 14 and one or more appended digital signatures
`(not shown). When the signatures are veri?ed, the software
`applicationY 14 can be executed on the device and access any
`APIs for which corresponding signatures have been veri?ed.
`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 repository (not shown), using the
`device 28 or possibly a personal 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 application 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 calculated hash and the hash recovered from the digi
`tal signature are then compared, and if the hashes are the
`same, the signature is veri?ed. The software applicationY 14
`can then be executed on the device 28 and access any sensitive
`APIs for which the corresponding signature(s) have been
`veri?ed. As described above, the invention is in no way lim
`ited to this particular illustrative example signature scheme.
`Other signature schemes, including further public key signa
`ture schemes, may also be used in conjunction with the code
`signing methods and systems described herein.
`FIG. 2 is a ?ow 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 developer writes the software
`application Y for a mobile device that requires access to a
`sensitive API or library that exposes a sensitive API (API
`library A). As discussed above, some or all APIs on a mobile
`device may be classi?ed as sensitive, thus requiring veri?ca
`tion of a digital signature for access by any software applica
`tion such as software applicationY In step 36, applicationY
`is tested by the software developer, preferably using a device
`simulator in which the digital signature veri?cation function
`has been disabled. In this manner, the software developer may
`debug the software applicationY before the digital signature
`is acquired from the code signing authority. Once the soft
`ware applicationY has been written and debugged, it is for
`warded to the code signing authority in step 38.
`In steps 40 and 42, the code signing authority reviews the
`software applicationY to determine whether or not it should
`be given access to the sensitive API, and either accepts or
`rejects the software application. The code signing authority
`may apply a number of criteria to determine whether or not to
`grant the software application access to the sensitive API
`including, for example, the siZe of the software application,
`the device resources accessed by the API, the perceived utility
`of the software application, the interaction with other soft
`ware applications, the inclusion of a virus or other destructive
`code, and whether or not the developer has a contractual
`obligat