`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`GOOGLE INC.
`Petitioner
`
`v.
`
`BLACKBERRY LTD.
`Patent Owner
`
`_________________
`
`Patent No. 8,489,868
`_________________
`
`DECLARATION OF DR. PATRICK D. McDANIEL
`
`Page 1 of 149
`
`GOOGLE EXHIBIT 1002
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`
`TABLE OF CONTENTS
`
`
`INTRODUCTION ........................................................................................... 1
`I.
`II. QUALIFICATIONS ........................................................................................ 1
`III. SUMMARY OF OPINIONS ........................................................................... 5
`IV. PERSON OF ORDINARY SKILL IN THE ART .......................................... 7
`V.
`TECHNOLOGICAL BACKGROUND .......................................................... 8
`A.
`Secure Systems ...................................................................................... 8
`B.
`Secure Systems and Cryptography ........................................................ 9
`1.
`Encryption and Decryption Generally ........................................ 9
`2.
`Cryptographic Algorithms and Keys ........................................ 11
`3.
`Cryptographic Protocols ........................................................... 13
`VI. OVERVIEW OF THE ’868 PATENT AND RELATED
`PROVISIONAL APPLICATIONS ............................................................... 21
`A.
`The ’868 Patent Specification ............................................................. 22
`B.
`Related Provisional Applications ........................................................ 33
`VII. CLAIM CONSTRUCTION .......................................................................... 35
`VIII. OVERVIEW OF THE PRIOR ART ............................................................. 36
`A. U.S. Patent No. 6,766,353 (“Lin”) (Ex. 1011) .................................... 36
`B. U.S. Patent No. 6,188,995 (“Garst”) (Ex. 1012) ................................ 45
`C. U.S. Patent No. 5,844,986 (“Davis”) (Ex. 1013) ................................ 51
`D. U.S. Patent No. 5,724,425 (“Chang”) (Ex. 1014) ............................... 51
`E.
`U.S. Patent No. 7,243,236 (“Sibert”) (Ex. 1015) ................................ 53
`F.
`U.S. Patent No. 6,131,166 (“Wong-Insley”) (Ex. 1017) ..................... 60
`
`i
`
`Page 2 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`G. U.S. Patent No. 5,657,378 (“Haddock”) (Ex. 1018) ........................... 61
`H.
`Li Gong, “Inside Java 2 Platform Security Architecture:
`Cryptography, APIs, and Implementation” (1999) (“Gong”)
`(Ex. 1016) ............................................................................................ 63
`IX. THE PRIOR ART DISCLOSES ALL OF THE FEATURES OF THE
`CHALLENGED CLAIMS OF THE ’868 PATENT .................................... 70
`A.
`Lin Discloses Every Feature of Claims 1, 13, 76-86, 88-95, 98,
`100, 104, 112, 113, 137, 139, and 142 ................................................ 71
`1.
`Claims 1 and 76 ......................................................................... 71
`2.
`Claims 78 and 81....................................................................... 99
`3.
`Claim 84 ..................................................................................101
`4.
`Claim 85 ..................................................................................102
`5.
`Claim 90 ..................................................................................103
`6.
`Claim 91 ..................................................................................103
`7.
`Claim 92 ..................................................................................105
`8.
`Claim 95 ..................................................................................106
`9.
`Claim 104 ................................................................................106
`10. Claims 113 and 137 ................................................................107
`11. Claim 142 ................................................................................107
`The Combination of Lin and Garst Discloses Every Feature of
`Claims 13, 88, and 98 ........................................................................108
`1.
`Claims 13 and 88.....................................................................108
`2.
`Claim 98 ..................................................................................113
`The Combination of Lin and Davis Discloses Every Feature of
`Claims 77, 79, 80, and 82 ..................................................................115
`
`C.
`
`B.
`
`ii
`
`Page 3 of 149
`
`

`

`D.
`
`E.
`
`F.
`
`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`Claims 77, 79, 80, and 82 .......................................................115
`1.
`The Combination of Lin and Chang Discloses Every Feature of
`Claim 83 ............................................................................................120
`1.
`Claim 83 ..................................................................................120
`The Combination of Lin and Sibert Discloses Every Feature of
`Claim 86 ............................................................................................124
`1.
`Claim 86 ..................................................................................124
`The Combination of Lin and Wong-Insley Discloses Every
`Feature of Claim 89 ...........................................................................128
`1.
`Claim 89 ..................................................................................128
`The Combination of Lin and Haddock Discloses Every Feature
`of Claim 94 ........................................................................................131
`1.
`Claim 94 ..................................................................................131
`The Combination of Lin and Gong Discloses Every Feature of
`Claims 93, 100, 112, and 139 ............................................................133
`1.
`Claim 93 ..................................................................................134
`2.
`Claim 100 ................................................................................137
`3.
`Claim 112 ................................................................................140
`4.
`Claim 139 ................................................................................144
`CONCLUSION ............................................................................................145
`
`G.
`
`H.
`
`X.
`
`
`
`
`iii
`
`Page 4 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`
`I, Dr. Patrick D. McDaniel, declare as follows:
`
`I.
`
`INTRODUCTION
`1.
`I have been retained by Google Inc. (“Petitioner”) as an independent
`
`expert consultant in this proceeding before the United States Patent and Trademark
`
`Office (“PTO”) regarding U.S. Patent No. 8,489,868 (“the ’868 patent”) (Ex.
`
`1001). I have been asked to consider whether certain references disclose or suggest
`
`the features recited in claims 1, 13, 76-86, 88-95, 98, 100, 104, 112, 113, 137, 139,
`
`and 142 (“the challenged claims”) of the ’868 patent. My opinions are set forth
`
`below.
`
`2.
`
`I am being compensated at my rate of $500 per hour for the time I
`
`spend on this matter. My compensation is in no way contingent on the nature of
`
`my findings, the presentation of my findings in testimony, or the outcome of this or
`
`any other proceeding. I have no other interest in this proceeding.
`
`II. QUALIFICATIONS
`3.
`Below I summarize my qualifications, as set forth in more detail in
`
`my curriculum vitae, which I understand is provided as Exhibit 1003.
`
`4.
`
`I earned a Ph.D. in Computer Science and Engineering from
`
`University of Michigan, Ann Arbor in 2001. Before that, I earned a Bachelor of
`
`Science degree in Computer Science from Ohio University in 1989 and a Master of
`
`Science degree, also in Computer Science, from Ball State University in 1991.
`
`1
`
`Page 5 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`After receiving my master’s degree, I worked as a software developer
`
`5.
`
`and project manager for companies in the networking industry, including Applied
`
`Innovation, Inc. (1991-1994) and Primary Access Corporation (1994-1996). While
`
`at these companies, I developed software-based management platforms to
`
`configure and monitor network devices across the country. One of the essential
`
`elements of this software was the management of the security of the device
`
`communication and the device itself. I was responsible for developing the
`
`requirements for security and its implementation in these systems.
`
`6.
`
`In 1996, I returned to graduate school at the University of Michigan in
`
`Ann Arbor. The focus of my studies from 1996 to 2001 was on secure systems
`
`design, which culminated in my dissertation titled, “Policy Management in Secure
`
`Group Communication.” While in graduate school, I worked on several projects
`
`prior to my thesis work in 1999. These projects included work related to the
`
`management of digital certificates, security protocols, and the design of general
`
`security infrastructure.
`
`7.
`
`For example, from 1997 to 2000, I worked on a project called
`
`JavaLauncher as part of a NASA Kennedy Space Center Fellowship. While
`
`working on JavaLauncher, I developed a Java-based framework for isolating test
`
`equipment from the launch apparatus during launch sequences (to prevent test
`
`modes from being initiated during a space shuttle launch). This required secure
`
`2
`
`Page 6 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`communication with the launch system and the isolation of untrusted apparatuses
`
`during launch windows.
`
`8.
`
`Since 2004, I have been a professor of Computer Science and
`
`Engineering at Pennsylvania State University in University Park, Pennsylvania. I
`
`have taught courses in the field of network and computer security and
`
`cryptography at both the undergraduate and graduate level. I created and currently
`
`maintain several of these courses.
`
`9.
`
`Over the years, I was an Assistant Professor (2004-2007), Associate
`
`Professor (2007-2011), and Full Professor (2011-2015) of Computer Science and
`
`Engineering. Since 2015, I have been a Distinguished Professor of Computer
`
`Science and Engineering. I am also the director of the Institute for Network and
`
`Security Research, and the founder and co-director of the Systems and Internet
`
`Infrastructure Security Laboratory, a research laboratory focused on the study of
`
`security in diverse network and computer environments. My research efforts
`
`primarily involve network, telecommunications, systems security, language-based
`
`security, and technical public policy.
`
`10. From 2003-2009, I was an Adjunct Professor at the Stern School of
`
`Business at New York University in New York, NY. At the Stern School of
`
`Business, I taught courses in computer and network security and online privacy.
`
`3
`
`Page 7 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`I am a Fellow of the Association for Computing Machinery (the
`
`11.
`
`leading professional association for computer science) and the Institute for
`
`Electrical and Electronics Engineering (the leading professional association for
`
`computer engineering).
`
`12.
`
`I am also the Program Manager (PM) and lead scientist for the Cyber
`
`Security (CS) Collaborative Research Alliance (CRA). The CRA is led by the
`
`Pennsylvania State University and includes faculty and researchers from the Army
`
`Research
`
`Laboratory, Carnegie Mellon University, Indiana University,
`
`the University of California-Davis, the University of California-Riverside, and the
`
`New Jersey Institute of Technology. This initiative is a major research project
`
`aimed at developing a new science of cyber-security for military networks,
`
`computers, and installations.
`
`13.
`
`I have served as an advisor to several Ph.D. and Master’s degree
`
`candidates, several of which have gone on to become professors at various
`
`institutions such as North Carolina State University, the University of Oregon, and
`
`the Georgia Institute of Technology. I am currently an advisor to two Ph.D.
`
`candidates and several Master’s students.
`
`14. As shown in Exhibit 1003, I have published extensively in the field of
`
`applied cryptography and network security. In addition to writing several articles
`
`for industry journals and conferences, I have authored portions of numerous books
`
`4
`
`Page 8 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`related to applied cryptography and network security. I have served on the editorial
`
`boards of several peer-reviewed journals including ACM Transactions on Internet
`
`Technology, for which I was the Editor-in-Chief. I was also an Associate Editor for
`
`ACM Transactions on Information and System Security and IEEE Transactions of
`
`Software Engineering, two highly-regarded journals in the field. A more complete
`
`list of my publications, authorships, and editorial positions can be found in Exhibit
`
`1003.
`
`III. SUMMARY OF OPINIONS
`15. The opinions contained in this declaration are based on the documents
`
`I reviewed, my professional judgment, as well as my education, experience, and
`
`knowledge regarding secure systems.
`
`16.
`
`In forming my opinions expressed in this declaration, I reviewed the
`
`’868 patent (Ex. 1001); the prosecution file history for the ’868 patent (Ex. 1004);
`
`U.S. Provisional Application No. 60/270,663 (Ex. 1005); U.S. Provisional
`
`Application No. 60/235,354 (Ex. 1006); U.S. Provisional Application No.
`
`60/234,152 (Ex. 1007); The Authoritative Dictionary of IEEE Standards Terms,
`
`IEEE Std. 100-2000 (7th ed. 2000) (Ex. 1008); Bruce Schneier, “Applied
`
`Cryptography” (2nd ed. 1996) (Ex. 1009); U.S. Patent No. 6,766,353 (“Lin”)
`
`(1011); U.S. Patent No. 6,188,995 (“Garst”) (Ex. 1012); U.S. Patent No. 5,844,986
`
`(“Davis”) (Ex. 1013); U.S. Patent No. 5,724,425 (“Chang”) (Ex. 1014); U.S.
`
`5
`
`Page 9 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`Patent No. 7,243,236 (“Sibert”) (Ex. 1015); Li Gong, “Inside Java 2 Platform
`
`Security Architecture: Cryptography, APIs, and Implementation” (1999) (“Gong”)
`
`(Ex. 1016); U.S. Patent No. 6,131,166 (“Wong-Insley”) (Ex. 1017); U.S. Patent
`
`No. 5,657,378 (“Haddock”) (Ex. 1018); U.S. Provisional Patent Application No.
`
`60/146,426 (Ex. 1019); Gary McGraw et al., “Securing Java” (1999) (Ex. 1020);
`
`U.S. Patent No. 6,298,354 (“Saulpaugh”) (Ex. 1021); U.S. Patent No. 5,680,619
`
`(“Gudmundson”) (Ex. 1022); U.S. Patent No. 5,421,013 (“Smith”) (Ex. 1023);
`
`Dorothy E. Denning, “Cryptography and Data Security” (1982) (Ex. 1024); U.S.
`
`Patent No. 5,845,282 (“Alley”) (Ex. 1025); PCT Publication No. WO 97/09813
`
`(“Nguyen”) (1026); PCT Publication No. WO 99/41520 (“Huang”) (Ex. 1027);
`
`Scott Oaks, “Java Security” (Feb. 1999) (Ex. 1028); U.S. Patent No. 6,721,809
`
`(“Roy”) (Ex. 1029); U.S. Patent No. 6,678,887 (“Hallman”) (Ex. 1030); David
`
`Flanagan, “Java in a Nutshell” (Nov. 1999) (Ex. 1031); Bill Venners, “Inside the
`
`Java 2 Virtual Machine” (1999) (Ex. 1032); and any other materials I refer to in
`
`this declaration in support of my opinions.
`
`17. My opinions have also been guided by my appreciation of how a
`
`person of ordinary skill in the art would have understood the claims and the
`
`specification of the ’868 patent at the time of the alleged invention, which I have
`
`been asked to initially consider as the mid-to-late 2000 time frame, including the
`
`September 21, 2000 filing date of the ’152 provisional application. My opinions
`
`6
`
`Page 10 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`reflect how one of ordinary skill in the art would have understood the ’868 patent,
`
`the prior art to the patent, and the state of the art at the time of the alleged
`
`invention.
`
`18. As I discuss in detail below, it is my opinion that certain references
`
`disclose or suggest all the features recited in the challenged claims of the ’868
`
`patent.
`
`IV. PERSON OF ORDINARY SKILL IN THE ART
`19. Based on my review of the ’868 patent, the types of problems
`
`encountered in the art, prior solutions to those problems, the rapidity with which
`
`innovations were made, the sophistication of the technology, and the educational
`
`level of active workers in the field, I believe a person of ordinary skill in the art at
`
`the time of the alleged invention, which I was asked to assume was mid-to-late
`
`2000, would have had at least a Bachelor’s degree in computer science or the
`
`equivalent and two years of work experience in the relevant field, e.g., secure
`
`systems, including security protocols for software applications. More education
`
`can substitute for practical experience and vice versa.
`
`20. All of my opinions in this declaration are from the perspective of one
`
`of ordinary skill in the art, as I have defined it here, during the relevant time frame,
`
`i.e., mid-to-late 2000. During this time frame, I possessed at least the qualifications
`
`of a person of ordinary skill in the art, as defined above.
`
`7
`
`Page 11 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`
`V. TECHNOLOGICAL BACKGROUND
`21.
`In this section, I present the terminology and a brief overview of
`
`several key technologies that were widely known before mid-to-late 2000 and that
`
`relate to the issues discussed in the subsequent sections. This section is not
`
`intended to be technically comprehensive, but rather provide a foundation for
`
`better understanding the ’868 patent and the prior art.
`
`A.
`Secure Systems
`22. Generally, as was known in the art, secure systems govern access to a
`
`“sensitive” resource. (Ex. 1016, 7-11; Ex. 1024, 191, 207-08.) A resource may be
`
`deemed sensitive for various reasons, including security, privacy, ownership,
`
`licensing, and availability. For example, a user of a mobile communication device
`
`may have considered a camera (hardware), personal contacts and other information
`
`(data), and access to banking or other applications (software) stored on the device
`
`to be sensitive resources. The hardware and software work together to control
`
`access to these resources.
`
`23. Two fundamental principles related to access control that were known
`
`at the time were authentication and authorization. Authentication was a well-
`
`known process for confirming the identity of the requesting entity attempting to
`
`gain access to a resource. (Ex. 1016, 15-17.) One example of authentication is
`
`when a user provides a valid username and password. (Id., 16.) Because—in
`
`8
`
`Page 12 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`principle—only the user knows the user’s password, anyone who provides the
`
`password is deemed authentic and is allowed to access the resource. (Id., 15-17.)
`
`24. Authorization, on the other hand, was a well-known process for
`
`determining whether an authenticated entity has the authority to access the
`
`resource. (Id., 7-11.) Authorization was often achieved by checking a security
`
`policy to determine what access rights—if any—had been assigned to the entity.
`
`(Id.) For example, a mobile communication device may have examined its security
`
`settings to determine if a particular application has the right to access the device’s
`
`camera. If the policy states that the entity is allowed to access the camera, the
`
`request is granted. Otherwise, the request is denied.
`
`B.
`Secure Systems and Cryptography
`25. Well before the date of the alleged invention of the ’868 patent,
`
`cryptography provided a means for implementing resource access control on
`
`various systems, including mobile communications systems.
`
`1.
`Encryption and Decryption Generally
`26. At a fundamental level, cryptography is the practice of protecting
`
`data. (Ex. 1009, 1; Ex. 1024, 1, 3-4, 7-11; Ex. 1016, 2, 11-15.) This is achieved by
`
`disguising or hiding the substance of the data using a process referred to as
`
`“encryption.” (Ex. 1009, 1; Ex. 1024, 1.) The original message is referred to as
`
`“plaintext” (or “cleartext”) and encrypted data is referred to as “ciphertext.” (Ex.
`
`9
`
`Page 13 of 149
`
`

`

`
`
`1009, 11; Ex. 10224, 1.) Thee process
`
`
`
`
`
`
`
`
`
`
`Declaaration of DDr. Patrickk D. McDanniel
`U.
`
`
`S. Patent NNo. 8,489,8868
`
`
`
`of turningg ciphertexxt back innto plaintexxt is
`
`
`
`
`
`referredd to as “decryption.”
`
`
`
`
`
`(Ex. 10099, 1; Ex. 1
`
`
`
`024, 1.) AA book authhored by wwell-
`
`
`
`
`
`known
`
`
`
`rates hy,” illustrCryptographApplied Cr, called “Ace Schneiercryptograppher, Bruc
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`these baasic conceppts in Figuure 1.1:
`
`
`
`
`
`
`
`(Ex. 10009, 1.)
`
`
`
`
`
`227. As exxplained inn Applied
`
`
`
`
`
`
`
`Cryptograaphy, in adddition to cconfidentiaality,
`
`
`
`
`
`
`
`
`
`cryptoggraphy provvides for ddata authenntication, iintegrity, aand nonreppudiation.
`
`
`
`
`
`
`
`
`
`
`
`
`
`(Id.,
`
`
`
`2; see aalso Ex. 10024, 4, 8-110.) Cryptography pprovides foor authenticcation beccause
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`the receeiver of a ddata messaage is ablee “to ascerttain its oriigin” so th
`
`
`
`
`
`
`
`
`
`
`
`
`
`at “an intrruder
`
`should
`
`
`
`not be able to masquuerade as
`
`
`
`
`
`someone eelse.” (Ex.. 1009, 2.)
`
`
`
`
`
` Cryptograaphy
`
`
`
`providees for integgrity because the receeiver of a ddata messaage is able
`
`
`
`
`
`
`
`
`
`
`
`
`
`to “verifyy that
`
`
`
`
`
`
`
`it has nnot been mmodified in transit”
`
`
`
`so that “aan intrudeer should nnot be ablle to
`
`
`
`
`
`
`
`
`
`substituute a false
`
`
`
`s for hy providesryptograph.” (Id.) Crimate one.message ffor a legiti
`
`
`
`
`
`
`
`
`
`
`
`
`
`deny laterr that he seent a
`
`
`
`
`
`nonrepuudiation beecause the
`
`
`
`
`
`messagee.” (Id.)
`
`
`
`sender is
`
`
`
`not able too “falsely
`
`10
`
`Page 14 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`2.
`Cryptographic Algorithms and Keys
`28. Generally, encryption and decryption are accomplished using one or
`
`more cryptographic algorithms (sometimes referred to as a “cipher”). (Id., 2-4; Ex.
`
`1024, 1, 7-11.) These algorithms often involve and depend on a “key,” which is
`
`any one of a large number of values generated using a key generation process. (Ex.
`
`1009, 3; Ex. 1024, 7-11.) The security of the cryptographic algorithm rests in the
`
`key (or keys), as cryptographic algorithms are typically known to the public. (Ex.
`
`1009, 3; Ex. 1024, 7-11.) As discussed below, anyone with the key can perform
`
`encryption or decryption. Thus, security of
`
`the cipher depends on key
`
`management.
`
`29. There are two primary types of key-based algorithms: symmetric and
`
`asymmetric. (Ex. 1009, 4; Ex. 1024, 7-11.)
`
`a)
`Symmetric Algorithms
`30. Symmetric algorithms, also referred to as secret-key algorithms,
`
`single-key algorithms, or one-key algorithms, typically involve an encryption key
`
`and a decryption key that are the same (or can be derived from one another). (Ex.
`
`1009, 4; see also id., 28-29; Ex. 1024, 10-11; Ex. 1016, 13-14.) Figure 1.2 from
`
`Applied Cryptography illustrates a symmetric algorithm using the same encryption
`
`and decryption key:
`
`11
`
`Page 15 of 149
`
`

`

`
`
`
`
`
`Declaaration of DDr. Patrickk D. McDanniel
`U.
`
`
`S. Patent NNo. 8,489,8868
`
`
`
` (Ex. 10009, 3.)
`
`1. With
`3
`
`
`
`
`h symmetriic algorithhms, the ssender andd receiver
`
`
`
`
`
`
`
`of a messsage
`
`
`
`
`
`
`
`
`
`
`
`must aggree on a seecret key bbefore the mmessage caan be secuurely commmunicated.
`
`
`
`
`
`(Id.,
`
`4.) The
`
`key must
`
`(Id.)
`
`
`
`remain seecret, or ellse anyonee can encryypt or decrrypt messaages.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`b) Assymmetricc (Public-KKey) Algo
`rithms
`
`
`
`
`
`
`3
`
`2. Asymmmetric alggorithms, aalso referreed to as puublic-key aalgorithms
`
`, use
`
`a pair o
`f different
`
`
`
`but relatedd keys gennerated usinng compleex mathemaatical formmulas
`
`
`
`
`
`
`
`
`
`
`
`
`
`for encrryption andd decryptioon. (Id.; seee also id.,
`
`
`
`
`
`
`
`
`
`1-12; Ex. 129-32; Exx. 1024, 11
`
`
`
`016,
`
`
`
`Applied CCryptograpphy illustraates a
`
`
`
`
`
`
`
`14-15; EEx. 1014,
`
`
`
`12:23-13:229.) Figuree 1.3 from
`
`
`
`
`
`
`
`
`
`public-kkey algoritthm using ssuch a key
` pair:
`
`
`
`(Ex. 10009, 4.)
`
`12
`
`
`
`
`
`Page 16 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`33. The encryption key is typically referred to as the “public key,” and the
`
`corresponding decryption key is typically referred to as the “private key” (or secret
`
`key). (Ex. 1009, 4; Ex. 1016, 14.) These algorithms are called “public-key”
`
`because the public key can be made public, while the private key remains secret.
`
`(Ex. 1009, 4; Ex. 1016, 14.) This means a third party can use the public key to
`
`encrypt a message, while the encrypted message can only be subsequently
`
`decrypted by the party with the corresponding private key. (Ex. 1009, 3-4; Ex.
`
`1016, 14.) However, in some contexts—such as digital signatures—the private key
`
`is used to encrypt the message and the public key is used to decrypt the message.
`
`(Ex. 1009, 4; Ex. 1016, 14-15; Ex. 1014, 12:50-52.) In other words, in all cases,
`
`the keys are encryption inverses of each other—anything encrypted with the public
`
`key can only be decrypted with the private key, and anything encrypted with the
`
`private key can only be decrypted with the public key.
`
`34. The pair of keys is unique in that two different public keys cannot be
`
`used with the same private key, and vice versa, and each key is useless without its
`
`sibling. Moreover, either key cannot practically be derived from the other. (Ex.
`
`1009, 4; Ex. 1016, 14; Ex. 1024, 11; Ex. 1014, 12:52-54.)
`
`3.
`Cryptographic Protocols
`35. Cryptographic algorithms provide security when used as part of a
`
`“protocol”—which has an important meaning. (Ex. 1009, 21-28.) A protocol is a
`
`13
`
`Page 17 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`series of steps between two or more parties designed to accomplish a task. (Id.,
`
`21.) Each step must be performed in sequence and no step can be performed before
`
`the previous step is finished. (Id.) Also, each party involved in the protocol must
`
`know the protocol and the steps to be followed. (Id.) When a protocol uses
`
`cryptography, the protocol is referred to as a “cryptographic protocol.” (Id., 22.)
`
`a)
`Communications Using Symmetric Algorithms
`36. One example of a cryptographic protocol is the secure communication
`
`between parties using a symmetric algorithm. (Id., 28-29; Ex. 1016, 13-14.) To
`
`illustrate this protocol, assume a hypothetical person named Alice wishes to
`
`securely send a message to a hypothetical person named Bob. To do so, Alice and
`
`Bob must perform the following steps in order: (i) Alice and Bob agree on a
`
`symmetric algorithm and secret key, (ii) Alice generates a ciphertext message by
`
`encrypting the plaintext message using the symmetric algorithm and the secret key,
`
`(iv) Alice sends the ciphertext message to Bob, and (v) Bob decrypts the ciphertext
`
`message using the same symmetric algorithm and the same secret key. (Ex. 1009,
`
`28.) Bob can now read the original plaintext message. (Id.) So long as the secret
`
`key remains a secret to Alice and Bob, a third party cannot decipher the ciphertext
`
`message to derive the original plaintext message. (Id., 28-29.)
`
`
`
`14
`
`Page 18 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`b) Communications Using Public-Key Algorithms
`37. Another example of a cryptographic protocol
`is
`the secure
`
`communication between parties using a public-key algorithm. (Id., 31-32; Ex.
`
`1024, 11-14; Ex. 1014, 12:60-65.) In order for Alice to securely send a message to
`
`Bob using this protocol, the following steps must be performed in order: (i) Alice
`
`and Bob agree on a public-key algorithm, (ii) Bob sends Alice his public key, (iii)
`
`Alice takes her plaintext message and generates a ciphertext message using the
`
`public-key algorithm and Bob’s public key, (iv) Alice sends the ciphertext message
`
`to Bob, and (v) Bob decrypts the ciphertext message using the same public-key
`
`algorithm and Bob’s secret key. (Ex. 1009, 31-32.)
`
`38. As this example illustrates, communication using a public-key
`
`algorithm avoids the key distribution risks involved with symmetric algorithms.
`
`(Id., 32.) That is, while symmetric algorithms require distribution of a secret key in
`
`order to securely communicate messages, increasing the risk that the secret key
`
`becomes compromised, public-key algorithms do not require the distribution of a
`
`secret key. (Id.) Instead, secure communication using public-key algorithms
`
`require the distribution of only a public key—i.e., the private key is not distributed
`
`and remains private. (Id.) With only the public key (and/or public-key algorithm),
`
`one cannot recover the corresponding private key or a message encrypted using the
`
`public key. (Id.)
`
`15
`
`Page 19 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`c)
`Digital Signatures Using Public-Key Algorithms
`39. Using cryptographic protocols, an entity can “sign” a digital message
`
`to generate a “digital signature.” (Id., 34-44; Ex. 1016, 14-15; 1024, 14-16; 1014,
`
`12:66-13:3; Ex. 1020, 84, 88-90.) A digital signature can be thought of as an
`
`electronic counterpart to a handwritten signature. (Ex. 1009, 34-35.) For example,
`
`similar to a handwritten signature, a digital signature is authentic, unforgeable,
`
`reusable, unalterable, and cannot be repudiated:
`
`1. The signature is authentic. The signature convinces the
`document's recipient that the signer deliberately signed the
`document.
`
`2. The signature is unforgeable. The signature is proof that the
`signer, and no one else, deliberately signed the document.
`
`3. The signature is not reusable. The signature is part of the
`document; an unscrupulous person cannot move
`the
`signature to a different document.
`
`4. The signed document is unalterable. After the document is
`signed, it cannot be altered.
`
`5. The signature cannot be repudiated. The signature and the
`document are physical things. The signer cannot later claim
`that he or she didn't sign it.
`
`(Id., 34-35; see also id., 37-38, 53-54.)
`
`40. A digital signature can be generated using a cryptographic protocol
`
`16
`
`Page 20 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`based on a public-key algorithm. (Id., 37-38; Ex. 1016, 14-15.) Simply stated,
`
`because only Alice holds her private key, Alice can generate a digital signature by
`
`encrypting (“signing”) a document using her private key. (Ex. 1009, 37-38; Ex.
`
`1016, 14-15.) Anyone with Alice’s public key can verify Alice’s digital signature
`
`by decrypting the signed document using Alice’s public key. (Ex. 1009, 37-38; Ex.
`
`1016, 14-15.)
`
`41. More specifically, the protocol requires the following steps be
`
`performed in order: (i) Alice and Bob agree on a public-key algorithm, (ii) Alice
`
`“signs” her plaintext message by encrypting the message using the public-key
`
`algorithm and her private key to generate a ciphertext message, the ciphertext
`
`message representing Alice’s digital signature, (iii) Alice sends the ciphertext
`
`message (digital signature) to Bob, and (iv) Bob decrypts the ciphertext message
`
`(digital signature) using the same public-key algorithm and Alice’s public key,
`
`thereby verifying Alice’s digital signature (e.g., Bob obtains the plaintext
`
`message). (Ex. 1009, 37-38.) In general, if the result of the decryption step is
`
`random (rather than expected) data, Alice’s digital signature is not verified.
`
`d) Digital Signatures Using Public-Key Algorithms and
`One-Way Hash Functions
`42. Public-key algorithms are often too computationally inefficient (e.g.,
`
`slow) to sign a large amount of data, such as software code. (Id., 38; Ex. 1032, 69-
`
`70.) Therefore, digital signature protocols often include a one-way hash function
`
`17
`
`Page 21 of 149
`
`

`

`Declaration of Dr. Patrick D. McDaniel
`U.S. Patent No. 8,489,868
`(sometimes referred to as a message digest) as a way to reduce the amount of
`
`computation needed to generate a signed message. (Ex. 1009, 38; Ex. 1012, 5:25-
`
`57; Ex. 1031, 161-62; Ex. 1032, 68-75.)
`
`43. One-way hash functions also provide data integrity, and are often used
`
`to protect data during storage and transit. (Ex. 1009, 37-38; Ex. 1016, 12; Ex.
`
`1012, 5:30-41; Ex. 1032, 69-72.) Such functions take a variable-length input and
`
`convert it to a fixed-length output, which is typically much smaller than the input
`
`(e.g., tens of bytes). (Ex. 1009, 30; Ex. 1032, 69.) As the