(12)
`
`United States Patent
`Lin et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,766,353 B1
`Jul. 20, 2004
`
`US006766353B1
`
`(54) METHOD FOR AUTHENTICATINGA JAVA
`ARCHIVE AR) FOR PORTABLE DEVICES
`
`(75) Inventors: Jyh-Han Lin, Coral Springs, FL (US);
`13);)???‘ ilellgfré stffygale’l EA.
`(
`)> ena
`' ml ’
`Ora _ pnngs’
`FL (Us), {Alan W- Chan> Sunnse, FL
`(Us); 5311.13)’ Wallchoo, Lauderdhllh
`FL (US)
`
`-
`
`6,023,764 A
`6,029,000 A
`6,044,467 A
`
`,
`
`,
`
`*
`
`ue er e a. ........... ..
`
`2/2000 Curtis ...................... .. 713/200
`2/2000 Woolsey et a1. .......... .. 395/705
`3/2000 Gong ....................... .. 713/200
`?emlllan 6: a11- ~~~~~~~~~~~ -
`*
`6,378,075 B1 * 4/2002 Goldstein et a1. ......... .. 713/200
`6,381,696 B1 * 4/2002 Doyle ...................... .. 713/156
`6,477,647 B1 * 11/2002 Venkatraman et a1. .... .. 713/193
`6,523,067 B2 * 2/2003 Mi et a1. .................. .. 709/229
`6,606,708 B1 * 8/2003 Devine et a1. ............ .. 713/201
`
`(73) Assignee: Motorola, Inc., Schaumburg, IL (US)
`
`* Cited by examiner
`
`_
`
`_
`
`( * ) Notice.
`
`_
`
`_
`
`_
`
`_
`
`SubJect' to any d1scla1mer,the term of this
`patent is extended or adJusted under 35
`U.S.C. 154(b) by 411 days.
`
`_
`(21) Appl' NO" 09/613’804
`(22) Filed;
`Ju]_ 11, 2000
`
`7
`(51; Int. Cl. .............................................. .. G06F 15/16
`52
`~~~~ ~~ 709/203; 709/201
`(58) Field of Search ............................... .. 713/200, 201,
`713/156, 168; 709/200, 203, 225, 229,
`226, 217
`
`(56)
`
`_
`References Clted
`U S PATENT DOCUMENTS
`
`Primary Examiner—Mehmet B. Geckil
`
`(74) Attorney) Agent) Or Firm_scott M_ Garrett
`
`(57)
`
`ABSTRACT
`
`A signed application descriptor ?le (206) is used instead of
`X509 certi?cates to authenticate a portable application
`code, such as a JAVA archive (JAR) ?le. The signed ADF
`includes an application descriptor ?le (302), ?le hash (304)
`of the JAR ?le (301), a developer descriptor ?le (308),
`signed time stamp (310), and a developer’s certi?cate (312).
`A network client device (202) includes limited computing
`resources (212) and a virtual machine environment for
`eXecutin the ortable code 208 . Furthermore the client
`g
`P
`device contains a set of cryptographic, digital keys for
`authenticating parts of the signed ADF, Which are further
`used to authenticate the JAR ?le.
`
`5,987,608 A 11/1999 Roskind ................... .. 713/200
`
`8 Claims, 3 Drawing Sheets
`
`302\
`304
`305x
`
`301
`
`1
`314
`SECURITY
`POLICY
`
`1
`316
`LICENSE
`POLICY
`
`318
`
`KEY
`
`TIME STAMP
`
`DEVELOPER
`S I G N A T U R E
`
`31 0
`
`312
`
`300
`
`Page 1 of 7
`
`GOOGLE EXHIBIT 1011
`
`

`

`U.S. Patent
`
`Jul. 20, 2004
`
`Sheet 1 of 3
`
`US 6,766,353 B1
`
`002
`
`202
`
`NIVNOd
`
`Q31931L08d
`
`SIDuNOS3Y
`
`ele
`
`SGOLA
`
`auVML4AOS
`
`ALILNG
`
`AYOMLIN
`
`LNIT19
`
`JOTAIG
`
`2or
`
`NOTLNETYLSIG
`
`yauvad
`
`SHYOMLIN
`
`Y3SAdaS
`
`90T
`
`Page 2 of 7
`
`Page 2 of 7
`
`
`
`
`

`

`U.S. Patent
`
`Jul. 20, 2004
`
`Sheet 2 of 3
`
`US 6,766,353 B1
`
`3SN301
`ALTYNIAS
`&YM
`HSVH3114aae
`ALVOTITLY39
`dNVISIATL
`
`FYNLVNOIS
`YadO19AR0
`43d01739A30
`31I4dave
`
`oTTandfee
`
`OE
`
`FDLA Y3ANaS
`
`NOTLNGIYLSIOONINOIS3009
`yaIdOVIAIGYaANaS
`
`
`
`Tot
`
`Ore
`
`are
`
`AQTV0d
`
`AQI10d
`
`Jad
`
`c0F
`
`bOE
`
`90E
`
`Page 3 of 7
`
`Page 3 of 7
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Jul. 20, 2004
`
`Sheet 3 of3
`
`US 6,766,353 B1
`
`3m
`
`4» Nam
`gm \
`
`\ Hmom
`
` ~ IIIIIIIIII wan llllllln
`
`
`?zmw 52%
`
`
`
`2852153 :93 vaofmz
`
`mm in
`
`NE \
`
`.@ .HVNBN
`
`~
`
`3 man
`
`vow \
`
`82H
`
`l I
`
`
`
`5.653 223m 38 $10550 @2322
`
`
`
`222 <0 E225 @958
`
`Page 4 of 7
`
`

`

`US 6,766,353 B1
`
`1
`METHOD FOR AUTHENTICATING A JAVA
`ARCHIVE (JAR) FOR PORTABLE DEVICES
`
`TECHNICAL FIELD
`This invention relates in general to portable code transfer,
`such as JAVA technology, and more particularly to security
`and authentication of portable code for use by Wireless or
`mobile devices, or other computing devices With relatively
`limited computing resources, and limited communication
`bandWidth.
`
`BACKGROUND OF THE INVENTION
`
`10
`
`15
`
`25
`
`35
`
`In netWorked environments such as the Internet, the use of
`portable code or portable applications has gained Wide
`spread acceptance. The best knoWn technology in this ?eld
`is JAVA. In creating JAVA code, a developer creates an
`application and makes it available on a netWork in byte code
`format. The byte code is doWnloaded by various client
`devices connected to the netWork and loaded into a JAVA
`virtual machine environment on the client machine or com
`puter. The virtual machine environment is a layer of soft
`Ware that can interact With the speci?c computing platform
`of the particular client device and interpret the byte code. An
`application so loaded onto a client device could compromise
`the client device, and may even be designed to do so if the
`developer of the application had malicious intentions.
`Therefore, security is a signi?cant issue With portable code.
`Many security schemes have been devised to address
`these security issues. These range from giving only very
`restricted access to all portable applications to a system of
`authentication in Which different levels of permission may
`be granted depending on Whether the application can be
`authenticated as having come from a trusted source. The
`later scheme is more preferable since it alloWs an application
`more access to the local computer’s resources, so long as it
`is authenticated. This alloWs developers to create more
`poWerful applications because the applications have more
`access to the computer resources of the client machine.
`HoWever, as presently devised, these authentication
`schemes are designed for general purpose personal
`computers, Which are commonly referred to as “desktop”
`computers. These machines have varying degrees of com
`puting resources, but in general the resources they have
`greatly eXceed the computing resources of small, portable
`devices such as personal organiZers and mobile communi
`cation devices. There is an increasing number of these
`smaller devices being manufactured that are able to connect
`to large networks, and particularly the internet. Presently
`X509 certi?cates are Widely used for authentication, but
`these are quite large ?les compared to the limited memory
`resources available on these smaller mobile devices.
`Furthermore, since the certi?cate comes bundled With the
`application typically, the device must load both the appli
`cation and the certi?cate. Therefore a data structure and
`method of authenticating portable applications that can be
`used by smaller devices is needed.
`
`40
`
`45
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shoWs a typical netWork including a server and a
`client;
`FIG. 2 shoWs a representation of a client netWork device
`and its computing resources;
`FIG. 3 shoWs a block diagram of a signed application
`descriptor ?le
`for use in accordance With the present
`invention;
`
`65
`
`2
`FIG. 4 shoWs a sequence chart for creating a signed ADF
`in accordance With the invention;
`FIG. 5 shoWs a sequence chart for establishing the identity
`of a trusted developer for use in creating a signed ADF in
`accordance With the invention; and
`FIG. 6 shoWs a sequence chart for doWnloading a signed
`ADF and a portable application from a distribution server to
`a netWork client device in accordance With the invention.
`
`DETAILED DESCRIPTION OF A PREFERRED
`EMBODIMENT
`While the speci?cation concludes With claims de?ning the
`features of the invention that are regarded as novel, it is
`believed that the invention Will be better understood from a
`consideration of the folloWing description in conjunction
`With the draWing ?gures, in Which like reference numerals
`are carried forWard. Abrief description of the prior art is also
`thought to be useful.
`The present invention solves the problem of doWnloading
`portable applications and authenticating their source onto
`client device With limited computing resources by creating
`a signed application descriptor ?le (ADF), and a developer
`descriptor ?le (DDF). The ADF is a ?le that describes the
`portable application in terms of the computing resources it
`requires, and can be loaded onto the client device ?rst so that
`the client device can determine Whether or not it has
`suf?cient resources, or it can let the user of the client device
`determine if there are sufficient resources. The ADF ?le is
`signed by the developer of the corresponding application
`using a certi?cation authority, Which is a Well knoWn and
`trusted signing authority. Attributes in the signed ADF
`correspond to those of the application so that if the user of
`the client device decides to load the application, the appli
`cation can be authenticated against the signed ADF. The
`DDF is associated With a particular application softWare
`developer and speci?es the general access control related
`information assigned to the developer. For example, a DDF
`may restrict the kind of application libraries that applications
`developed by the developer can use, or the security domain
`to Which the developer belongs.
`Referring noW to FIG. 1, there is shoWn a typical netWork
`100 over Which client and server machines interact. In
`particular, a netWork client device 102, such as a mobile
`communication device, connects With a distribution server
`104 over one or more bearer netWorks 106. Typically the
`bearer netWork includes a TCP/IP netWork, and for public
`distribution of softWare, it includes the Internet. HoWever,
`numerous private netWorks are connected to the Internet
`through various gateWays and portals, including many Wire
`less mobile communication netWorks. Indeed, the present
`invention is suited particularly Well to use on mobile com
`munication devices such as Internet capable mobile or
`cellular radio telephones. These devices may use What is
`referred to as a “microbroWser” to vieW information, or
`“content”, placed on the Internet and other netWorks acces
`sible by the device, as Well as execute portable code. As With
`general purpose computers, there is a desire to load portable
`applications onto these devices. Developers of portable
`applications provide the application on a database 106 of the
`distribution server 104. Client devices access the distribu
`tion server over the netWork and receive the desired portable
`code or portable application over the connection. This is one
`Way Which JAVA code sections, such as applets, are distrib
`uted.
`Referring to FIG. 2 there is shoWn a representation 200 of
`a client netWork device 202 and its computing resources. In
`
`Page 5 of 7
`
`

`

`US 6,766,353 B1
`
`10
`
`15
`
`25
`
`35
`
`3
`this instance, the client device is receiving an application ?le
`204, Which includes a signed ADF 206 and the application
`code 208. The application code may be, for example, a JAVA
`archive (JAR) ?le. These tWo parts maybe transferred sepa
`rately or together. The signed ADF prescribes the security
`domain 210 of the application When loaded into the client
`device. Essentially, the security domain determines Which of
`the client device’s resources 212 the application Will be
`alloWed to access When running in the virtual machine
`environment 214. In the preferred embodiment, the appli
`cation is received in the form of byte code Which the virtual
`machine executes. The virtual machine only alloWs the
`application to access the resources permitted, as dictated by
`the signed ADF. The resources 212 include other processes,
`classes, and methods, as Well as certain hardWare compo
`nents such as volatile and non-volatile memory space. The
`signed ADF is substantially smaller than the presently used
`signed JAR ?le format because a signed JAR ?le includes all
`applications-related ?les, and is more desirable for use With
`computing devices With relatively limited resources.
`Referring noW to FIG. 3, there is shoWn a block diagram
`300 of a signed application descriptor ?le
`for use in
`accordance With the present invention, along With an asso
`ciated JAR ?le 301 containing the portable code to be
`installed on the client machine. The signed ADF includes an
`application descriptor ?le 302, a ?le hash 304 of the JAR
`?le, a developer descriptor ?le (DDF) 306, a developer
`certi?cate 308, a time stamp 310, and a developer signature
`312. ADF 302 describes the resources Which are required by
`the client device, and may include a security policy ?le 314
`or a license policy ?le 316, or both. The ADF contains a
`pointer to the network location of the application in the ?le
`hash 304, an indication of the amount of memory space
`required to execute the application, and the environment
`necessary for execution. The security policy contains the
`information regarding Which resources the application needs
`permission to use, as Well as the names of ?les the appli
`cation may create, and the netWork addresses it may need to
`access. The license policy may be used to set hoW the
`application may be used, such as Whether it has a ?nite
`number of uses, or a ?nite period of time, Whether it may be
`transferred to other users, and so on. The ?le hash 304 is a
`hash of the JAR ?le 301, and is the result of a cryptographic
`method Which produces a small digest that can be used to
`authenticate a larger ?le (in this case a JAR ?le), as is knoWn
`in the art. For additional security, more than one hash may
`be used and included in the signed ADF using different hash
`algorithms, such as SHAl, MD5, or others. The DDF 306
`also contains information about the JAR ?le, and may also
`include information regarding the developer. The develop
`er’s certi?cate is a certi?cate issued to the developer and
`includes the developers public key 318 so that the certi?cate
`may be authenticated by the client device. It also contains
`information about the identity of the developer, the validity
`period, the issuing certi?cate authority, the issuing date, and
`so on, to be used in the authentication process. The time
`stamp 310 is a signed time stamp. It is provided by a trusted
`source, such as a certi?cate authority or perhaps the client
`device’s subscriber netWork operator. By providing a signed
`timestamp, the client device can determine When the appli
`cation Was signed, and if that time stamp is authentic.
`Finally, the developer’s signature 312 is concatenated onto
`the other data structures. The developer’s signature is alloWs
`the client device to authenticate the ADF.
`The developer produces the signed ADF as illustrated in
`FIG. 4, Which shoWs a sequence chart for creating a signed
`ADF 400 in accordance With the invention. The developer
`
`40
`
`45
`
`55
`
`65
`
`4
`sends a request, containing the hash for the ADF and the
`developer certi?cate, to a code signing authority (402), and
`requests a signed timestamp. The code signing authority is
`a trusted entity, such as, for example, Verisign, Inc., or the
`client’s netWork operator. It should be noted that the cer
`ti?cate authority and the code signing authority are not
`necessarily the same entity. A certi?cate authority manages
`certi?cates, While a code signing authority veri?es developer
`certi?cates and signs ADF hash ?les and timestamps it. The
`developer generates and sends a hash of the ADF to the code
`signing authority and receives a signed timestamp back from
`the certi?cate authority (404). The developer then concat
`enates the ADF, the hash of the JAR ?le, the DDF, the
`developer’s certi?cate, and the signed time stamp together.
`The developer’s certi?cate contains a hash of the DDF. The
`developer signs the concatenated ?le (406), by adding the
`developer’s digital signature (element 312 from FIG. 3), and
`the ADF is fully signed. The signed, concatenated ?le is the
`signed ADF, and is then placed on a distribution server
`(408), along With the application code or JAR ?le. The
`netWork address of the signed ADF is then made available
`so that client devices can doWnload it to begin the installa
`tion and authentication procedure for the JAR ?le. In the
`preferred embodiment, the developer uses a softWare devel
`oper’s kit (SDK), Which is a set of softWare creation tools
`distributed by, for example, the creator of the virtual
`machine environment 214 that runs on the client device. The
`SDK automates this Whole procedure, including steps
`402—408.
`FIG. 5 shoWs the sequence 500 for obtaining a develop
`er’s certi?cate. The developer’s broWser, or similar client
`application, ?rst sends a certi?cate request (502) to a code
`signing certi?cate authority server, Which may be operated
`by the same certi?cate authority referred to above. The
`certi?cate authority sends the developer information to a
`developer administration server (504). This entity may be,
`for example, the operator of the client’s home netWork or
`netWork service provider. For example, in the case of the
`client device being a Wireless mobile communication
`device, the developer administrator may be the Wireless
`service provider that provides the Wireless communication
`service. The developer administrator returns a developer
`descriptor ?le (DDF) to the code signing certi?cate authority
`(506), Which becomes part of the signed ADF, as described
`above in reference to FIG. 3. In the preferred embodiment,
`the developer’s certi?cate Will contain a hash of the DDF.
`The preferred format for the certi?cate is a Wireless transport
`layer security (WTLS) certi?cate because it is smaller than,
`for example, an X509 certi?cate. The certi?cate authority
`then forWards a developer certi?cate and the DDF, prefer
`ably both text encoded, to the developer’s computer, such as,
`for example, by email (508). The text encoded information
`is easy to transfer as an email enclosure.
`After the signed ADF has been created and placed on a
`distribution server, client devices can doWnload the signed
`ADF and the application or JAR ?le. The procedure is as
`shoWn in FIG. 6, Which shoWs a sequence chart 600 for
`doWnloading a signed ADF and a portable application or
`JAR ?le from a distribution server to a netWork client device
`in accordance With the invention. Prior to beginning this
`sequence, the client device has had a code signing certi?cate
`authority public key and a time stamping root key placed in
`the client device. The time stamping root key is a public key
`used for authenticating the signed time stamp 310. To begin
`the method, the client device transmits (602) a request to a
`distribution server for the application. The distribution
`server transmits the signed ADF for the desired application,
`
`Page 6 of 7
`
`

`

`US 6,766,353 B1
`
`10
`
`15
`
`25
`
`35
`
`5
`Which is received by the client device (604). Preferably the
`signed ADF contains an application descriptor ?le, ?le hash
`of the application code, developer descriptor ?le, developer
`certi?cate, signed time stamp, and the developer certi?cate.
`These transactions take place using knoWn netWork
`protocols, such as TCP/IP. Upon receiving the signed ADF,
`the client device veri?es the developer certi?cate With the
`code signing certi?cate authority’s public key (606). The
`client may also authenticate the signed time stamp With the
`time starnping root key (608). The veri?ed tirnestarnp is used
`to check Whether the ADF ?le is signed Within the valid
`period of the developer certi?cate. Both of these must be
`veri?ed. If it Was not already received, the client device
`obtains the netWork location of the application code or JAR
`?le, and transmits a request to the server, specifying the
`particular application desired (610). Although shoWn here a
`being on the same distribution server as the signed ADF, the
`application may be located on a different server. The server
`transmits the application code to the client device (612).
`Upon receiving the application code, the client device corn
`pares it to the parameters in the signed ADF. Speci?cally, it
`compares the hash received in the signed ADF With the hash
`of the application, and may also verify attributes such as ?le
`siZe. The hash of the JAR ?le may be produced by the client
`device, and compared to the hash received in the signed
`ADF. If the hash of the application received in the signed
`ADF matches the hash of the received application ?le (in
`step 612), the client device loads the application into the
`virtual machine environment for execution according to the
`security and license policies, if any Were present in the ADF.
`Thus, the invention avoids the use of relatively large ?les
`and certi?cates for authenticating the application code, as is
`used With more poWerful, general purpose computers. A
`typical certi?cate Will be 100—500 bytes, the ?le hash about
`20 bytes, the DDF about 100—200 bytes, and of course the
`JAR ?le can be very small to very large, depending on the
`application. The use of a signed ADF alloWs devices With
`relatively limited resources to easily authenticate the trust
`Worthiness of an application, and to set appropriate perrnis
`sions for the various resources. The security is accomplished
`by providing the client device With a set of keys initially,
`such as the code signing certi?cate authority key and a time
`starnping root key. Furtherrnore, developers provides their
`public key in the signed ADF so that client devices can use
`them to further establish a trusted chain. A hash of the
`application, and preferably a signed hash, is used so that it
`may be compared to the application once it is received at the
`client device. A security policy ?le and a license policy ?le
`may be provided to describe What resources the application
`Will need, What it Will create, and the limitation on the use
`of the application as Well as the transferability of the
`application.
`While the preferred embodiments of the invention have
`been illustrated and described, it Will be clear that the
`invention is not so limited. Nurnerous rnodi?cations,
`changes, variations, substitutions and equivalents Will occur
`to those skilled in the art Without departing from the spirit
`and scope of the present invention as de?ned by the
`appended claims.
`What is claimed is:
`1. A method of authenticating a JAVA archive ?le to be
`loaded onto a netWork client device, the netWork client
`
`40
`
`45
`
`55
`
`6
`device having a code signing certi?cate authority key and a
`time starnping root key, the method comprising:
`
`transrnitting, from the netWork client device, a request to
`a distribution server for the JAVA archive ?le;
`receiving, at the netWork client device, a signed applica
`tion descriptor ?le from the distribution server, the
`signed application descriptor ?le containing an appli
`cation descriptor ?le, a hash of the JAVA archive ?le,
`a developer descriptor ?le, a developer certi?cate con
`taining a developer public key, a signed time stamp,
`and a developer signature;
`verifying the developer certi?cate With the code signing
`certi?cate authority key; and
`verifying the signed time stamp With the time starnping
`root key.
`2. A method of authenticating a JAVA archive ?le as
`de?ned in claim 1, further comprising verifying the devel
`oper signature using the developer public key.
`3. A method of authenticating a JAVA archive ?le as
`de?ned in claim 1, Wherein the receiving cornprises receiv
`ing the signed application descriptor ?le Where the devel
`oper signature is a signed hash of the signed time stamp,
`developer certi?cate, developer descriptor ?le, application
`hash ?le, and the application descriptor ?le.
`4. A method of authenticating a JAVA archive ?le as
`de?ned in claim 1, Wherein the receiving cornprises receiv
`ing an application descriptor ?le containing a security policy
`?le.
`5. A method of authenticating a JAVA archive ?le as
`de?ned in claim 1, Wherein the receiving cornprises receiv
`ing an application descriptor ?le containing a license policy
`?le.
`6. A method of authenticating a JAVA archive ?le as
`de?ned in claim 1, further comprising:
`extracting a netWork address of the application from the
`signed application descriptor ?le; and
`loading the JAVA archive ?le from the netWork address.
`7. A method of authenticating a JAVA archive ?le as
`de?ned in claim 6, Wherein the netWork client device
`comprises a virtual machine environment, the method fur
`ther cornprising loading the JAVA archive ?le into the virtual
`machine environment.
`8. Arnethod of creating a signed application descriptor ?le
`to be used in authenticating a JAVA archive ?le, comprising:
`generating an application descriptor ?le corresponding to
`the JAVA archive ?le, the application descriptor ?le
`describing the resources needed by the JAVA archive
`?le;
`generating a hash of the application descriptor ?le;
`transmitting the hash of the application descriptor ?le and
`a developer’s certi?cate to a certi?cate authority;
`receiving a signed tirnestarnp from the certi?cate author
`ity in response to the transmitting; and
`signing an application descriptor ?le With the ?le hash, a
`developer descriptor ?le, the developer’s certi?cate,
`and the signed time stamp.
`
`*
`
`*
`
`*
`
`*
`
`*
`
`Page 7 of 7
`
`