RIV-1017
`Riverbed Technology v. Silver Peak Systems
`IPR2014-00245 / Page 1 of 13
`
`

`

`US 8,386,797 B1
`
`Page 2
`
`
`
`6,473,861
`6,477,624
`6,516,397
`6,662,333
`6,691,209
`6,704,871
`6,718,444
`6,742,116
`6,763,458
`6,804,162
`6,857,076
`6,898,707
`6,968,424
`6,981,141
`7,051,152
`7,058,769
`7,082,530
`7,096,370
`7,117,421
`7,152,156
`7,215,774
`7,231,050
`7,242,768
`7,278,016
`7,606,364
`2001/0050989
`2002/0029315
`2002/0073298
`2002/0099950
`2002/0138747
`2003/0037248
`2003/0046529
`
`U.S. PATENT DOCUMENTS
`31 *
`10/2002
`Stokes .......................... 713/193
`31
`11/2002
`Kedem et a1.
`32
`2/2003
`Roy et a1.
`31
`12/2003
`Zhang et al.
`31
`2/2004
`O’Connell
`31 *
`3/2004
`Kaplan et a1.
`31
`4/2004
`Hughes
`................. 713/ 171
`31 *
`5/2004
`Matsui et a1.
`31
`7/2004
`Watanabe et a1.
`31
`10/2004
`Eldridge et a1.
`
`31 *
`2/2005
`Klein ..................... 713/189
`31 *
`5/2005
`Sit etal.
`........................ 713/167
`31
`11/2005
`Danilak
`31 *
`12/2005
`Mahne et a1.
`31
`5/2006
`Danilak
`31
`6/2006
`Danilak
`
`713/153
`.
`31*
`7/2006
`Diamant
`31 *
`8/2006
`Klein ............................ 713/193
`31
`10/2006
`Danilak
`31
`12/2006
`Babbitt et al.
`32 *
`5/2007
`Onagawa
`31
`6/2007
`Harris
`32
`7/2007
`Challener
`31
`10/2007
`Detrick et al.
`31 *
`10/2009
`Shih ............................. 380/42
`A1
`12/2001
`Zakiya
`A1
`3/2002
`Williams et a1.
`A1
`6/2002
`Geiger et a1.
`A1*
`7/2002
`Smith ........................... 7 13/200
`A1*
`9/2002
`Clarke .......................... 713/189
`A1*
`2/2003
`Launchbury et a1.
`......... 713/ 193
`A1
`3/2003
`Loison et a1.
`
`................. 713/192
`
`................. 713/165
`
`11111111111111111 380/210
`
`2003/0058873 A1
`2003/0065925 A1*
`2003/0084308 A1*
`2003/0108196 A1*
`2003/0115472 A1*
`2003/0177401 A1*
`2003/0188179 A1
`2003/0212868 A1
`2007/0140486 A1
`2007/0143611 A1
`2008/0232581 A1*
`2009/0319782 A1
`2010/0005289 A1
`
`3/2 03
`/2 03
`5/2 03
`6/2 03
`/2 03
`/2 03
`10/2 03
`11/2 03
`6/2 07
`/2 07
`/2 08
`12/2 09
`1/2 10
`
`Geiger et a1.
`................. 713/178
`Shindo et al.
`Van Rijnswou .
`.. 713/189
`
`Kirichenko ..
`380/37
`Chang ..........
`.. 713/182
`Arnold et al.
`................. 713/202
`Challener et a1.
`Alfieri et a1.
`Haran
`Arroyo et al.
`Elbaz et a1.
`Lee
`Devanand et a1.
`
`..................... 380/42
`
`
`
`OTHER 3UBL1CATIONS
`
`Haran et a1, “CTR Mode for Encryption”, 2002, grouper.ieee.org/
`groups/802/3/efnflpublic/ju102/p2mp/haranip2mp7270702.pdf.*
`Bryant, Randal. O’Hallaron David, Computer Systems, A Program-
`mers Perspective, 2001, pp. 1-763.*
`Chodowiec. Pawel, “Comparison of the Hardware Performance of
`the AES Candidates Using Reconfigurable Hardware”, George
`Mason University, 2002, pp. 1-141.*
`Gobioff, Howard. “Security for a High Performance Commodity
`Storage Subsystem”, 1999, Carnegie Mellon University, p. 1-222.*
`Schneier. Bruce, Applied Cryptography, 1996. Wiley& Sons. p. 173.
`Wagner, et a1. “Comments to NIST Concerning AES-modes of
`Operations: CTR-mode Encryption”.
`In Symmetric Key Block
`Cipher Modes of Operation Workshop, Baltimore, Maryland, US,
`Oct. 20, 2000. p. 1-4.
`
`* cited by examiner
`
`IPR2014-00245 I Page 2 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 2 of 13
`
`

`

`ILS.Patent
`
`Faxzmzms
`
`Shmtlflfi
`
`USS§8¢797B1
`
`SOFTWARE
`PROGRAMS
`
`fl? 11.1
`
`0’5
`
`_.————————.————————-—p—_——'-———
`
`MAIN MEMORY
`
`
`
`1—62
`
`
`HOST
`SYSTEM
`
`132
`
`
` STORAGE
`
`PROCESSOR
`1L6 DATA
`
`STORAGE
`
`MEDIUM
`
`
`
`KEY REGISTER(S)
`
`
`149
`
`
`MEMORY figngROLLER
`
`ENCRYPTION/
`DECRYPTION
`ENGINE
`
`
` 15g
`
`NETWORK PROCESSOR
`UNIT
`
`17_0
`
`NETWORK
`
`.11_8
`NETWORK
`
`
`PROCESSOR
`
`u:
`
`
`FIGURE 1
`
`IPR2014-00245 I Page 3 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 3 of 13
`
`

`

`U.S. Patent
`
`Feb. 26, 2013
`
`Sheet 2 of6
`
`US 8,386,797 B1
`
`£9 E
`
`A MEMORY CONTROLLER RECEIVES A REQUEST (WITH PASSWORD) FROM
`A SOFTWARE PROGRAM TO STORE DATA ON A STORAGE MEDIUM
`210
`
`MEMORY CONTROLLER VERIFIES THE PASSWORD AND UNLOCKS
`ENCRYPTION KEY
`
`3g
`
`ENCRYPT THE DATA USING A KEY STORED IN HARDWARE COUPLED TO
`THE MEMORY CONTROLLER
`220
`
`THE MEMORY CONTROLLER TRANSFERS THE DATA TO THE STORAGE
`MEDIUM TO BE STORED THEREON
`
`230
`
`
`
`
`THE MEMORY CONTROLLER READS THE DATA FROM THE STORAGE
`MEDIUM, IN RESPONSE TO A REQUEST (WITH PASSWORD) FOR THE DATA
`
`
`240
`
`
`MEMORY CONTROLLER VERIFIES THE PASSWORD AND UNLOCKS
`ENCRYPTION KEY
`
`2g
`
`DECRYPT THE DATA IN A HARDWARE ENCRYPTIONIDECRYPTION ENGINE
`USING THE KEY
`
`252
`
`THE MEMORY CONTROLLER TRANSFERS THE DATA TO MAIN MEMORY
`260
`
`IPR2014-00245 I Page 4 of 13
`
`RIV-1017
`
`“ F
`
`IGURE 2
`
`RIV-1017
`IPR2014-00245 / Page 4 of 13
`
`

`

`U.S. Patent
`
`Feb. 26, 2013
`
`Sheet 3 of6
`
`US 8,386,797 B1
`
`M
`
`
`ENCRYPT A KEY WITH USER SUPPLIED PASSWORD TO
`PRODUCE ENCRYPTED KEYS
`
`310
`
`
`
`
`REPEAT AS
`NEEDED
`
`STORE THE ENCRYPTED KEY ON STORAGE MEDIUM
`
`320
`
`
`
`IN RESPONSE TO RECEIVING ONE OF THE PASSWORDS,
`RETRIEVE THE CORRESPONDING ENCRYPTED KEY FROM
`
`
`STORAGE MEDIUM AND DECRYPT IT WITH THE PASSWORD
`
`
`TO PRODUCE THE KEY
`330
`
`
`
`
`
`
`
`ACCESS DATA FROM STORAGE MEDIUM AND DECRYPT IN
`HARDWARE ENCRYPTIONIDECRYPTION UNIT
`
`:49
`
`FIGURE 3
`
`IPR2014-00245 I Page 5 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 5 of 13
`
`

`

`U.S. Patent
`
`Feb. 26, 2013
`
`Sheet 4 of6
`
`US 8,386,797 B1
`
`M
`
`A MEMORY CONTROLLER RECEIVES A PASSWORD FROM A BASIC
`
`INPUT OUTPUT SYSTEM (BIOS) WHEN A COMPUTER SYSTEM
`COUPLED TO A STORAGE DEVICE IS BOOTED
`
`4_12
`
`«.142
`
`THE MEMORY CONTROLLER DECRYPTS A KEY STORED IN
`
`HARDWARE USING THE PASSWORD
`420
`
`THE MEMORY CONTROLLER READS DATA COMPRISING AT LEAST
`
`A PORTION OF AN OPERATING SYSTEM PROGRAM ON THE
`STORAGE DEVICE
`430
`
`THE MEMORY CONTROLLER DECRYPTS THE DATA USING THE
`
`KEY, WHEREIN THE OPERATING SYSTEM PROGRAM IS
`AVAILABLE TO BE LOADED IN THE COMPUTER SYSTEM
`
`FIGURE 4
`
`IPR2014-00245 I Page 6 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 6 of 13
`
`

`

`U.S. Patent
`
`Feb. 26, 2013
`
`Sheet 5 of 6
`
`US 8,386,797 B1
`
`&
`
`PARTITIONS (STORE MAPPING IN A TABLE IN MEMORY
`CONTROLLER)
`fig
`
`GENERATE A PLURALITY OF UNIQUE KEYS
`520
`
` MAP A DATA STORAGE DEVICE INTO A PLURALITY OF
`
`STORE THE PLURALITY OF UNIQUE KEYS IN A MEMORY
`CONTROLLER COUPLED TO THE STORAGE DEVICE
`530
`
`ENCRYPT DATA USING THE APPROPRIATE KEY
`540
`
`STORE THE ENCRYPTED DATA IN THE APPROPRIATE PARTITION
`
`550
`
`HGURE5
`
`IPR2014-00245 I Page 7 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 7 of 13
`
`

`

`U.S. Patent
`
`Feb. 26, 2013
`
`Sheet 6 of6
`
`US 8,386,797 B1
`
`/W
`
`ENCRYPTION
`
`@
`
`S/W
`
`ENCRYPTION
`
`&
`
`115
`
`HARDWARE ENCRYPTION/DECRYPTION
`
`USING AES IN CTR MODE BASED ON BLOCK
`
`NUMBER AND ADDRESS OF BYTE-ALIGNED BLOCK
`
`PASSED THROUGH A TRANSFORM FUNCTION
`
`IPR2014-00245 I Page 8 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 8 of 13
`
`

`

`US 8,386,797 B1
`
`1
`SYSTEM AND METHOD FOR TRANSPARENT
`DISK ENCRYPTION
`
`2
`
`protect data on a hard drive without impacting system perfor-
`mance or relying too heavily on user interaction.
`
`FIELD OF THE INVENTION
`
`SUMMARY OF THE INVENTION
`
`The present invention relates to the field of data storage.
`Specifically, embodiments of the present invention relate to
`encrypting data on a data storage device at a hardware level
`such that the encryption is transparent to the operating system
`and application programs.
`
`10
`
`BACKGROUND ART
`
`The proliferation of laptop computers has made it more
`important than ever to protect the data on a hard drive from 15
`theft. For example, if a laptop is stolen, the contents of the
`hard drive are extremely vulnerable, even if steps are taken to
`protect the data. Considering that many corporate and gov-
`ernment employees routinely take their laptops home, the
`contents may contain extremely valuable and sensitive infor- 20
`mation, which an unauthorized user or a thief may be willing
`0 go to significant lengths to extract.
`One technique for protecting the data on a hard drive is a
`password-locked hard drive. In this case, a software routine
`allows access to the data only if the proper user code and 25
`oassword are entered. While this may provide some measure
`of protection, a moderately computer savvy thief can easily
`‘ecover the contents of the hard drive that are stored without
`
`
`
`encryption. For example, the thief may read the contents of
`he hard drive by either physically removing the hard drive 30
`and attaching it to another host computer or by using special-
`ized disk recovery equipment. In this fashion, the contents
`nay be dumped sector by sector and read without the pass-
`word.
`
`Another technique to protect data on a hard drive is an 35
`operating system encrypting selected files to be stored to the
`hard drive. In this case, files are encrypted on a file-by-file
`basis. For example, the operating system may have an option
`that prompts the user to encrypt files. However, the user may
`decide to leave the encryption option offbecause it may be too 40
`time consuming or inconvenient. Moreover, when the user
`does turn on the encryption option, the user may choose not to
`encrypt some files that should be. Hence, much of the data is
`vulnerable and this option relies too heavily on user interac-
`tion.
`
`45
`
`Furthermore, it may be impossible to use the operating
`system encryption option for some types of files and/or appli-
`cations. Examples of files for which this encryption may be
`unavailable are compressed files, memory mapped files, swap
`files, and garbage files. For example, the hard drive may 50
`receive a temporary file that is not encryptable by this method.
`Therefore, the operating system encryption option is unus-
`able with certain types of files and data connected to certain
`applications.
`Additionally, the operating system encryption option may 55
`consume substantial central processor unit (CPU) time (e.g.,
`25% of CPU utilization) during encryption and decryption.
`Thus, this method severely impacts system performance.
`Therefore, it would be advantageous to provide a way to
`protect data on a hard drive. It would also be advantageous to 60
`protect data on a hard drive via a method that is not vulnerable
`to theft by simply bypassing a password. It would also be
`advantageous to protect data on a hard drive via a method that
`does not require the user to painstakingly encrypt files on a
`file-by-file basis. It would also be advantageous to protect all
`types of files stored on a hard drive and data connected with
`any application. Furthermore, it would be advantageous to
`
`65
`
`The present invention protects data on a hard drive by
`performing encryption at a hardware level transparently to
`system software (e.g., operating system software). Embodi-
`ments ofthe present invention protect data on a hard drive via
`a method that is not vulnerable to theft by simply bypassing a
`password.
`Embodiments of the present invention also protect data on
`a hard drive without requiring the user to painstakingly
`
`encrypt files on a file-by-file basis. Embodiments of the
`present invention protect all types of files stored on a hard
`drive and files connected with any application. Embodiments
`of the present invention protect data on a hard drive without
`impacting system performance or relying on human interac-
`tion. The present invention provides these advantages and
`others not specifically mentioned above but described in the
`sections to follow.
`
`A data storage system providing transparent encryption is
`disclosed. In one embodiment, the data storage system has a
`hardware encryption/decryption engine and a
`register
`coupled to the hardware encryption/decryption engine. The
`register is for securely storing a key for encrypting and
`decrypting data. The key may not be read from outside the
`data storage system. More specifically, the key may not be
`read by the operating system. The user does not have access to
`the encryption key, but may have a password that is passed to
`a controller coupled to the encryption/decryption engine. The
`controller verifies the password and causes data received
`from main memory to be encrypted by the hardware encryp-
`tion/decryption engine using the key. The controller also
`transfers the encrypted data to the data storage device.
`Another embodiment of the present invention provides for
`a method of performing encryption and decryption. The
`method starts with a controller receiving a request, along with
`a password, from a program to store data on a storage
`medium. The controller verifies the password and causes a
`hardware encryption/decryption engine to encrypt the data
`using a key stored in hardware. Then, the memory controller
`transfers the data to the storage medium. At some later time,
`the controller reads the encrypted data from the storage
`medium, in response to a request for the data. Then, the
`hardware encryption/decryption engine decrypts the data
`using the key. Finally, the controller transfers the data to main
`memory. Thus, the encryption’decryption is transparent to the
`requesting program.
`In another embodiment, file-by-file encryption performed
`by an operating system is combined with the method of per-
`forming encryption and decryption of the previous embodi-
`ment.
`
`In another embodiment, a data storage device is mapped
`into multiple partitions, with the mapping stored in a control-
`ler coupled to the data storage device. A unique key is gener-
`ated for each partition and the keys are securely stored in the
`controller. In response to a request from a software program,
`data is encrypted in a hardware encryption/decryption engine
`coupled to the controller using one of the keys and the
`encrypted data is stored in the corresponding partition of the
`data storage device.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The accompanying drawings, which are incorporated in
`and form a part of this specification, illustrate embodiments
`
`IPR2014-00245 I Page 9 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 9 of 13
`
`

`

`US 8,386,797 B1
`
`3
`
`4
`
`of the invention and, together with the description, serve to
`explain the principles of the invention.
`FIG. 1 is a block diagram of a system for encrypting/
`decrypting data on a storage medium, according to an
`embodiment of the present invention.
`FIG. 2 is a flowchart illustrating steps of a process of
`performing encryption at a hardware level, according to an
`embodiment of the present invention.
`FIG. 3 is a flowchart illustrating steps of a process of
`encrypting data on a hard drive with multiple users sharing a 10
`common key, according to an embodiment of the present
`invention.
`
`5
`
`FIG. 4 is a flowchart illustrating steps of a process of
`booting a computer system whose hard drive is encrypted,
`according to an embodiment of the present invention.
`FIG. 5 is a flowchart illustrating steps of a process storing
`encrypted data on a hard drive in multiple partitions, accord-
`ing to an embodiment of the present invention.
`FIG. 6 is a block diagram illustrating files encrypted at both
`a software and a hardware level, according to an embodiment 20
`of the present invention.
`
`15
`
`
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`In the following detailed description of the present inven- 25
`tion, a method and system for transparent encryption/decryp-
`tion, numerous specific details are set forth in order to provide
`a thorough understanding of the present invention. However,
`it will be recognized by one skilled in the art that the present
`invention may be practiced without these specific details or 30
`with equivalents thereof. In other instances, well-known
`methods, procedures, components, and circuits have not been
`described in detail as not to unnecessarily obscure aspects of
`the present invention.
`Embodiments of the present invention perform encryption 35
`at a hardware level and are thus transparent to all software
`layers (e.g., transparent to the operating system). Referring
`now to the embodiment of FIG. 1, a card, embedded system,
`or peripheral component 115 has a hardware encryption/
`decryption engine 150 for encrypting and decrypting data. 40
`The card 115 may be, for example, a graphics card, although
`embodiments of the present invention are not so limited. The
`card 115 may also be referred to as a data storage system. The
`card 115 has a memory controller for accessing a data storage
`medium 130 (e.g., hard drive). The memory controller 120 45
`also has one or more key registers 140 for storing a key(s) for
`encrypting and decrypting data. Public key encryption may
`be used.
`
`The card 115 receives requests from, for example, a soft-
`ware program 111 or an operating system 112 to store data 50
`(e.g., from main memory 160) to the data storage medium
`130. Along with the request, the card 115 may receive a
`pas sword, which may be used to unlock a key in a key register
`140. The data is encrypted in the hardware encryption/de-
`cryption engine 150 with the key before it is transferred to the 55
`data storage medium 130. The memory controller 120 may
`receive the data and send it to the hardware encryption/de-
`cryption engine 150 or cause the data to be transferred
`directly from main memory 160 to the hardware encryption/
`decryption engine 150. Upon chip reset the encryption mode 60
`may be off, wherein encryption is enabled by, for example, a
`command from the operating system 112. However, this is not
`required. Upon a request from the software program 111 or
`operating system 112 containing a valid password,
`the
`memory controller 120 accesses the data from the data stor-
`age medium 13 0 and has it decrypted by the hardware encryp-
`tion/decryption engine 150 using the key and passed back to
`
`65
`
`main memory 160. In this fashion, the encryption/decryption
`is transparent to the requesting program.
`Referring still to FIG. 1, the memory controller 120 may
`share the encryption/decryption engine 150 with another
`component. For example, a network processor 117 in a net-
`work processing unit 170 for interfacing with a network 118
`may be coupled to the encryption/decryption engine 150. The
`memory controller 120 may have a storage processor 116
`coupled to the encryption/decryption engine 150. In this fash-
`ion, the network processor 117 and the storage processor 116
`share the hardware encryption/decryption engine 150.
`Still referring to FIG. 1, the encryption/decryption engine
`150 may be implemented in hardware in order to process data
`at a sufficient speed. For example, 1 GB/s network traffic
`maybe 125 MB/s in filll duplex and 125 MB/s for encryption
`and 125 MB/s for decryption. There may be, for example, two
`memory controllers 120, each supporting, for example, 133
`MB/s. The encryption/decryption engine 150 may be config-
`urable such that it may be used for both encryption and
`decryption simultaneously. Thus, this embodiment provides a
`low cost and low gate count solution.
`FIG. 2, is a flowchart illustrating a process 200 in which
`data is encrypted and decrypted in a fashion that is transparent
`to a program (111, 112) requesting that data be stored on a
`data storage medium 130. In step 210, a memory controller
`120 receives a request from the program (111, 112) to store
`data on a data storage medium 130. The request may be for
`any data that is to be stored on the data storage medium 130.
`The requesting program (111, 112) need not be aware that the
`data is to be encrypted when stored on the data storage
`medium 130, although optionally it may be so informed. The
`data may already be encrypted when received or not, may be
`compressed or uncompressed, and may be associated with
`any requesting program (111, 112). Thus, embodiments of
`the present invention may be used along with encryption
`performed in software, for example, by the operating system
`112. A password to unlock the encryption key may also be
`passed to the memory controller 120.
`In step 215, the memory controller 120 verifies the pass-
`word and unlocks the encryption key stored in the key register
`140. For example, the memory controller 120 forwards the
`key to the hardware encryption/decryption engine 150.
`If the password is invalid, the memory controller 120 may
`refuse to forward the key and/or refuse to transfer data to the
`data storage medium 130. In one embodiment, the data is
`always encrypted even if no password is received.
`In step 220, the data is encrypted at a hardware level using
`the key stored in hardware and to which the memory control-
`ler 120 has access. For example, the memory controller 130
`may route the data to the hardware encryption/decryption
`engine 150. To produce the key, a random number may be
`generated by the hardware (e.g., in the memory controller
`120). In one embodiment, the unencrypted key carmot be read
`from outside the hardware (e.g., calmot be read outside to
`card 115) and never leaves the hardware.
`In step 230,
`the memory controller 120 transfers the
`encrypted data to the data storage medium 130 to be stored
`thereon. In contrast to prior art,
`the entire data storage
`medium 130 may be encrypted, not just files. For example,
`rather than encrypting on a file-by-file basis, the memory
`controller 120 may encrypt all data that is to be stored. How-
`ever,
`it
`is not required that all data be encrypted. Also,
`embodiments of the present invention provide for using dif-
`ferent keys to encrypt different data.
`At some later point in time, the memory controller 120
`reads the encrypted data from the data storage medium 130, in
`response to a request for the data, in step 240. The memory
`
`IPR2014-00245/ Page 10 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 10 of 13
`
`

`

`US 8,386,797 B1
`
`5
`
`6
`
`5
`
`controller 120 also receives a password to unlock the encryp-
`tion key. For example, the key is transferred to the hardware
`encryption/decryption engine 150. The password may be the
`same password received in step 210. However,
`in one
`embodiment different users may have their own passwords,
`and hence this may be a different password than received in
`step 210. The operating system 112 and device drivers issue
`commands to the memory controller 120 as if no encryption
`were being done. Thus, process 200 is transparent to software
`layers (e.g., software programs 111, operating system 112).
`In step 245, the memory controller 120 verifies the pass-
`word and unlocks the encryption key stored in the key register
`140. For example, the memory controller 120 forwards the
`key to the hardware encryption/decryption engine 150. If the
`password is invalid, the memory controller 120 may refuse to 15
`forward the key.
`The data is then decrypted, in step 250. The memory con-
`troller 120 may route the data to the hardware encryption/
`decryption engine 150 either directly from the data storage
`device 130 or after passing though the memory controller 20
`120. Of course, the hardware encryption/decryption engine
`150 may reside within the memory controller 120, in one
`embodiment.
`
`10
`
`In step 260, the memory controller 120 transfers the data to
`main memory 160, such that it is available to the requesting 25
`program (111, 112). In this fashion, the encryption is per-
`formed at a hardware level and is transparent to all layers of
`software. Process 200 then ends.
`
`Embodiments of the present invention allow for one or
`more user supplied passwords to be involved with the encryp- 30
`tion process. In this fashion, a single user or a group of users
`may have access to all or a selected portion of data (e.g., file
`or partition) on the data storage medium 130. For example,
`many of today’s BIOS (Basic Input/Output System) imple-
`mentations support password protection. In one implementa- 35
`tion, this password (or another password) may be used as a
`base for the encryption/decryption key. However, if the user
`loses his or her password, the encrypted content of the data
`storage medium 130 may be lost. Furthermore, if the user
`changes the password, the encrypted data needs to be re- 40
`encrypted with the new password.
`Therefore,
`instead of using the password directly to
`encrypt the data, the encryption key may be randomly gener-
`ated, with the password being used to encrypt and decrypt the
`encryption key, in one embodiment. In order to store data, the 45
`user supplies the password, which is used to decrypt the key,
`which in turn is used to encrypt the data. Because the data is
`always encrypted with just the encryption key (e. g.,
`the
`encryption does not directly use the password), if the user
`wishes to change the password the data does not need to be 50
`re-encrypted. Only the key needs to be re-encrypted using the
`new password. However, because the encryption key is ran-
`domly generated, if the user loses the password, the data
`cannot be recovered. Also, this embodiment protects against
`the event that the user may leave the company and refuse to 55
`provide the password.
`Thus, rather than encrypting the data with a key that is
`unique for each user, the data may be encrypted with an
`encryption key that is known by an administrator, in one
`embodiment. This known key is encrypted/decrypted with 60
`the user password. If the user leaves the company or forgets
`the password, the data may be recovered using the known
`password.
`There are times when a user may desire to share with
`several others the information encrypted on the data storage 65
`medium 130. While all the users could share a password, this
`is undesirable because users may tend to use the same or
`
`similar passwords for a variety ofendeavors. FIG. 3 illustrates
`a process 300 in which multiple users share a common key but
`use their 0an personal passwords to encrypt the key. Each
`user supplies a unique personal password. This may be imple-
`mented as a BIOS option, but is not so limited. In step 310, the
`encryption key is encrypted with one of the user personal
`passwords. The encryption key may be randomly generated
`within the hardware in which the memory controller 120
`resides.
`
`In step 320, the encrypted personal password is stored on
`the data storage medium 13 0. For example, the encrypted key
`may be stored on the first sector of the data storage medium
`130. However, the personal password is not stored on the data
`storage medium 130. Furthermore, the key is neither stored
`nor transferred outside the hardware “in the clear.” Steps 310
`and 320 are repeated for each user personal password and
`may be performed at any time. Furthermore, the personal
`passwords may be changed at any time without re-encrypting
`data on the data storage medium 130. Only the encrypted key
`on the data storage medium 130 has to be re-encrypted.
`In step 330, the memory controller 120 retrieves one ofthe
`personal password encrypted keys from the data storage
`medium 130 and causes the key to be decrypted by the hard-
`ware encryption/decryption engine 150 using a personal
`password supplied from a user.
`In step 340, the memory controller 120 accesses encrypted
`data from the data storage medium 130 and causes it to be
`decrypted by the hardware encryption/decryption engine 150
`using the just decrypted key. The memory controller 120 then
`causes the decrypted data to be sent to main memory 160.
`Process 300 then ends.
`
`In the rare event that two users have the same password
`(which may be used to encrypt the key), the encrypted key
`would be the same unless extra precautions are taken. This is
`undesirable, as it makes it possible for someone to decipher
`another’s password by noting that the key encrypted to the
`same value.
`
`An embodiment ofthe present invention all but ensures that
`this will not happen by adding a random number to the key
`before encrypting it. Thus, even ifthe same two passwords are
`used, a different encrypted key will result. When decrypting
`the password-encrypted key, the random numbers are thrown
`away. Thus, the same encryption key is used by everyone in
`the group.
`In the event that all the data the entire data storage medium
`130 is encrypted, then there needs to be a way to decrypt the
`data at boot-up time. Referring now to step 410 ofprocess 400
`in FIG. 4, in one embodiment, the memory controller 120
`receives a password from, for example, the BIOS while the
`computer is begin booted. In some cases, a user may enter the
`password at boot-up time. In other cases, the password may
`be received from over a network 118. For example, the com-
`puter system may be a rack-mounted or a blade server, for
`which remote boot-up is important. In this case, the number of
`unsuccessful logins may be limited to prevent someone from
`hacking in.
`In step 420, the memory controller 120 uses this password
`to decrypt a key stored in hardware (e.g., a key register 140).
`In this fashion, only a user who knows the password may
`enable the encryption/decryption key.
`The memory controller 120 uses this password to decrypt
`data from the storage device during boot-up, in step 430. For
`example, the memory controller 120 receives requests to load
`data on the storage medium 130 for the operating system and
`other programs, such as, device drivers, a boot-up program,
`etc.
`
`IPR2014-00245/ Page 11 of 13
`
`RIV-1017
`
`RIV-1017
`IPR2014-00245 / Page 11 of 13
`
`

`

`US 8,386,797 B1
`
`7
`
`8
`
`In step 440, the memory controller 120 decrypts the data
`(e.g., operating system) using the key. In this fashion, the
`operating system is available during boot-up even though it
`was encrypted while stored on the data storage medium 130.
`Clearly, systems that require the operating system to perform
`encryption are incapable of this feat.
`In another embodiment, the encryption of the data storage
`medium 130 may be on a partition basis. For example, the key
`that is used to encrypt the data depends on which portion of
`the data storage medium 130 is accessed. In this embodiment,
`the data storage medium 130 is partitioned into sections that
`are encrypted using unique keys. Referring now to process
`500 of FIG. 5, in step 510 the data storage medium 130 is
`mapped into a number of partitions. This mapping may be
`stored in the memory controller 120. The operating system
`portion may be unencrypted (allowing for boot without pass-
`word via BIOS) or may be encrypted with its own unique key,
`in which case boot-up may be according process 400 of FIG.
`4.
`
`In step 520, a number of unique keys are generated. Any
`suitable mechanism may exist for generating tmique keys for
`the various partitions. For example, the operating system 112
`may direct the memory controller 120 to generate keys for
`each partition.
`In step 530, the keys are stored in the memory controller
`120. There is no need to encrypt the keys and store them on the
`data storage medium 130.
`In step 540, the memory controller 120 receives a request to
`store data on the data storage medium 130 in a particular
`partition, using a particular key. The operating system 112
`may forward the proper password to the memory controller
`120 when a user (e.g., engineering, marketing) desires to
`access the data storage medium 130. The memory controller
`120 encrypts and stores the data, in response to this request.
`An embodiment of the present invention provides for an
`encryption API (Application Programming Interface), which
`may be used by, for example, the operating system 112 or
`software programs 111. The encryption API allows data to be
`read from a specified main memory 160 location and written
`to a specified main memory 160 location. The two locations
`may be the same,
`in which case an in—place encryption
`decryption function is provided. As discussed herein, the
`actual encryption/decryption is performed in the hardware
`encryption/decryption engine 150. The operating system 120
`may have a special driver or extension for accessing the
`encryption AFI.
`Embodiments of the present invention may be used with
`file-by-file encryption performed in software (e.g., performed
`by the operating system). Referring now to FIG. 6, two sepa-
`rate files 602 (file 1 and file 2) are encrypted separately via
`software encryption 604. The encryption keys may be differ-
`ent and the encryption may be performed at separate times. A
`third file 602 (file 3) is not encrypted at the software level. The
`files 602 are passed to the card 115, which performs hardware
`encryption decryption. However, at the hardware level the
`same key may be used irrespective of which file 602 is being
`processed, although separate keys maybe used, if desired.
`For a given input data block, the same encrypted result will
`always occur. Given that some input data blocks are more
`common than are others, the same output pattern may appear
`with greater frequency. For example, an input data block ofall
`zeroes may be common. Hence, its encrypted counterpart will
`also appear more frequently. This may be undesirable as it
`may provide clues as to the nature ofthe encryption algorithm
`and/or the stored data. Furthermore, using the AES (advanced
`encryption standard) in CBC (cipher block chaining) mode
`(or feedback mode) may create scalability issues (e.g., as
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`defined by the critical feedback path in AES) or additional
`latency (e.g., multiple unites operating at lower speed and
`sub-cluster sizes near the end may be aggregated together).
`Therefore, AES may be used in CTR (counter) mode to avoid
`the above-mentioned issues. The counter may be based on
`block number