US20160239674A1 - Network-based client side encryption - Google Patents

Abstract

A device may provide an upload request to upload a file. The device may receive, based on the upload request, a unique identifier associated with the device. The device may obtain a file key for encrypting the file and a security key for encrypting the file key. The security key may be obtained based on the unique identifier. The device may encrypt the file, using the file key, to create an encrypted file. The device may encrypt the file key, using the security key, to create an encrypted file key. The device may provide the encrypted file and the encrypted file key for storage by a storage device.

Description

BACKGROUND
• A client device may provide a file to a storage device for storage (e.g., a cloud storage device, or the like). The client device may encrypt the file before providing the file to the storage device for storage, and may decrypt the file after receiving the file from the storage device.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIGS. 1A and 1B are diagrams of an overview of an example implementation described herein;
• FIG. 2 is a diagram of an example environment in which systems and/or methods, described herein, may be implemented;
• FIG. 3 is a diagram of example components of one or more devices ofFIG. 2;
• FIG. 4 is a flow chart of an example process for encrypting and uploading a file and a credential used to encrypt the file;
• FIGS. 5A-5C are diagrams of an example implementation relating to the example process shown inFIG. 4;
• FIG. 6 is a flow chart of an example process for updating a stored encrypted file key based on a new unique identifier;
• FIGS. 7A-7C are diagrams of an example implementation relating to the example process shown inFIG. 6;
• FIG. 8 is a flow chart of an example process for downloading and decrypting an encrypted file and a file key used to encrypt the file; and
• FIGS. 9A and 9B are diagrams of an example implementation relating to the example process shown inFIG. 8.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
• The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
• A service provider may provide a storage service (e.g., a cloud-based storage service). The storage service may receive a file from a client device, store the file on a storage device, and/or provide the file to the client device or another device based on receiving a request for the file. The client device may encrypt the file before providing the file to the storage device, and may decrypt the file after receiving the file from the storage device. The encryption and decryption may be based on a credential provided by a user of the client device (e.g., a password, or the like).
• However, the credential provided by the user may be insecure or easily compromised (e.g., the user may share the credential with another entity, may store the credential in an unprotected manner, may use an easily-compromised credential, or the like). Further, the client device may be compromised by a malicious party. Thus, the file associated with the client device may be easily decrypted by a malicious party that determines the credential provided by the user.
• Implementations described herein may aid the service provider in improving the security of the stored file. A client device may generate a cryptographic file key, and may encrypt a file using the cryptographic file key to generate an encrypted file. The client device may provide a request to upload the encrypted file. Based on the request, a network device may determine a unique identifier associated with the client device. The network device may provide the unique identifier to the storage device for authentication. The storage device may authenticate the client device and may provide the unique identifier to the client device. The client device may generate a cryptographic security key based on the unique identifier, and may use the cryptographic security key to encrypt the file key to generate an encrypted file key. The client device may provide the encrypted file key to the storage device. In this way, the service provider may improve the security of the stored file, by providing a unique identifier for encryption and/or decryption of the information, rather than relying on a user-provided credential. The client device may further improve security of the stored file by providing the encrypted file key for storage by the storage device, which may be more secure than the client device.
• FIGS. 1A and 1B are diagrams of an overview of anexample implementation100 described herein. As shown inFIG. 1A, a client device may generate a file key (e.g., a random string of one or more characters). As further shown, the client device may encrypt a file using the file key to generate an encrypted file. As shown, the client device may provide, to a network device, a request to upload the encrypted file. As further shown, the network device may determine a unique identifier associated with the client device. As shown, the network device may provide, to a storage device, an authentication request that includes the unique identifier. As further shown, the storage device may authenticate the client device and/or the unique identifier based on the authentication request. As shown, the storage device may provide the unique identifier to the client device upon successfully authenticating the client device and/or the unique identifier.
• As shown, the client device may generate a security key based on the unique identifier. As further shown, the client device may encrypt the file key, using the security key, to create an encrypted file key. As shown, the client device may provide, to the storage device, the encrypted file and the encrypted file key. Assume that the storage device stores the encrypted file and the encrypted file key. Assume further that the client device retains the security key.
• As shown inFIG. 1B, the client device may provide, to the network device, a request to download the encrypted file. As further shown, the network device may determine the unique identifier associated with the client device, and may provide an authentication request, that includes the unique identifier, to the storage device. As shown, the storage device may authenticate the client device and/or the unique identifier based on the authentication request. As further shown, the storage device may provide, to the client device associated with the unique identifier, the encrypted file key and the encrypted file upon successfully authenticating the client device and/or the unique identifier.
• As further shown, the client device may decrypt the encrypted file key, using the security key, to recover the file key. As shown, the client device may decrypt the encrypted file, using the file key, to recover the file. In this way, the client device may use the storage device to store the encrypted file. The client device may encrypt and decrypt the file using a security key that is generated based on a unique identifier that is not provided by a user of the client device, which may improve security of the encrypted file. The user of the client device may not be required to provide additional credentials to encrypt the file, which may improve the user experience.
• FIG. 2 is a diagram of anexample environment200 in which systems and/or methods, described herein, may be implemented. As shown inFIG. 2,environment200 may include aclient device210, astorage device220, anetwork device230, and anetwork240. Devices ofenvironment200 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.
• Client device210 may include one or more devices capable of receiving, generating, storing, processing, and/or providing information. For example,client device210 may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a desktop computer, a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart watch, a pair of smart eyeglasses, etc.), or a similar type of device. In some implementations,client device210 may provide a message (e.g., an upload request, a download request, an update request, or the like) tostorage device220 and/ornetwork device230. In some implementations,client device210 may provide a file and a credential to and/or receive a file and a credential fromstorage device220.
• Storage device220 may include one or more devices capable of receiving, generating, storing, processing, and/or providing information. For example,storage device220 may include a server, a cloud storage device, or a similar device. In some implementations,storage device220 may provide storage (e.g., cloud storage) for files provided by another device, such asclient device210. In some implementations,storage device220 may provide a stored file and a credential toclient device210 or another device (e.g., based on a download request). In some implementations,storage device220 may authenticate a unique identifier, and may provide the unique identifier to client device210 (e.g., based on receiving, fromnetwork device230, an authentication request that includes the unique identifier).
• Network device230 may include one or more devices capable of receiving, storing, generating, processing, and/or providing security information. For example,network device230 may include a firewall, a server (e.g., a web server), or a similar device. In some implementations,network device230 may provide and/or control access to storage device220 (e.g., by client device210). For example,network device230 may receive an upload request and/or a download request (e.g., from client device210) to upload a file to or download a file fromstorage device220.Network device230 may determine a unique identifier associated withclient device210, and may provide the unique identifier in association with an authentication request tostorage device220, to causestorage device220 to authenticate the unique identifier and/or provide the unique identifier toclient device210.
• Network240 may include one or more wired and/or wireless networks. For example,network240 may include a cellular network (e.g., a long-term evolution (LTE) network, a 3G network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, or the like, and/or a combination of these or other types of networks.
• The number and arrangement of devices and networks shown inFIG. 2 are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown inFIG. 2. Furthermore, two or more devices shown inFIG. 2 may be implemented within a single device, or a single device shown inFIG. 2 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) ofenvironment200 may perform one or more functions described as being performed by another set of devices ofenvironment200.
• FIG. 3 is a diagram of example components of adevice300.Device300 may correspond toclient device210,storage device220, and/ornetwork device230. In some implementations,client device210,storage device220, and/ornetwork device230 may include one ormore devices300 and/or one or more components ofdevice300. As shown inFIG. 3,device300 may include abus310, aprocessor320, amemory330, astorage component340, aninput component350, anoutput component360, and acommunication interface370.
• Bus310 may include a component that permits communication among the components ofdevice300.Processor320 is implemented in hardware, firmware, or a combination of hardware and software.Processor320 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that interprets and/or executes instructions.Memory330 may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use byprocessor320.
• Storage component340 may store information and/or software related to the operation and use ofdevice300. For example,storage component340 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of computer-readable medium, along with a corresponding drive.
• Input component350 may include a component that permitsdevice300 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively,input component350 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.).Output component360 may include a component that provides output information from device300 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).
• Communication interface370 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enablesdevice300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.Communication interface370 may permitdevice300 to receive information from another device and/or provide information to another device. For example,communication interface370 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.
• Device300 may perform one or more processes described herein.Device300 may perform these processes in response toprocessor320 executing software instructions stored by a computer-readable medium, such asmemory330 and/orstorage component340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.
• Software instructions may be read intomemory330 and/orstorage component340 from another computer-readable medium or from another device viacommunication interface370. When executed, software instructions stored inmemory330 and/orstorage component340 may causeprocessor320 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
• The number and arrangement of components shown inFIG. 3 are provided as an example. In practice,device300 may include additional components, fewer components, different components, or differently arranged components than those shown inFIG. 3. Additionally, or alternatively, a set of components (e.g., one or more components) ofdevice300 may perform one or more functions described as being performed by another set of components ofdevice300.
• FIG. 4 is a flow chart of anexample process400 for encrypting and uploading a file and a credential used to encrypt the file. In some implementations, one or more process blocks ofFIG. 4 may be performed byclient device210. In some implementations, one or more process blocks ofFIG. 4 may be performed by another device or a set of devices separate from or includingclient device210, such asstorage device220 and/ornetwork device230.
• As shown inFIG. 4,process400 may include generating a file key for encrypting a file (block410). For example,client device210 may generate a file key (e.g., a cryptographic key, or the like). In some implementations,client device210 may use the file key to encrypt a file and/or to decrypt an encrypted file. In some implementations, the file key may be a random string of characters.
• As further shown inFIG. 4,process400 may include encrypting the file, using the file key, to create an encrypted file (block420). For example,client device210 may encrypt the file, using the file key, to create an encrypted file. In some implementations,client device210 may encrypt the file using an encryption algorithm (e.g., an Advanced Encryption Standard (AES) algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the file key.
• As shown inFIG. 4,process400 may include providing an upload request to upload the encrypted file (block430). For example,client device210 may provide, tonetwork device230, an upload request. The upload request may request to upload an encrypted file (e.g., a file encrypted by, stored by, and/or accessible by client device210). In some implementations, the upload request may include information that identifiesclient device210.
• In some implementations, the upload request may include a device identifier associated with client device210 (e.g., a mobile directory number (MDN), an international mobile subscriber identity (IMSI), an international mobile station equipment identity (IMEI), a mobile equipment identifier (MEID), or the like, that identifies client device210), a file type identifier that identifies a type of file to upload (e.g., a file extension associated with the file, a format of the file, etc.), or the like.
• In some implementations, the upload request may causenetwork device230 to determine a unique identifier. The unique identifier may be a string of one or more characters associated withclient device210. For example, the unique identifier may include a unique identifier header (UIDH). In some implementations, the unique identifier may be associated with network traffic that is received from, transmitted toward, and/or associated with client device210 (e.g., in a header of the network traffic, to identify the network traffic as associated withclient device210, or the like). In some implementations, the unique identifier may include information that identifiesclient device210. For example, the unique identifier may include information that identifies a type ofclient device210, information that identifies a user ofclient device210, information that identifies a service thatclient device210 is authorized to access, information that describes a geographical location ofclient device210, or the like.
• In some implementations, the unique identifier may be a device identifier that identifiesclient device210. For example,network device230 may receive the device identifier from client device210 (e.g., in association with the upload request) and may use the device identifier as a unique identifier associated withclient device210. Additionally, or alternatively,network device230 may receive the device identifier from another device (e.g., a home subscriber server, an authentication authorization and accounting server, or the like).
• In some implementations, the unique identifier may be different than the device identifier. As an example,network device230 may generate the unique identifier. In some implementations,network device230 may generate the unique identifier based on the device identifier (e.g., by applying an algorithm to the device identifier, or the like). As another example,network device230 may assign the unique identifier from a list of unused unique identifiers that are generated bynetwork device230 prior to receiving the upload request, or the like. In some implementations,network device230 may use the device identifier to determine the unique identifier. For example,network device230 may look up a unique identifier based on the device identifier. Additionally, or alternatively,network device230 may provide the device identifier to another device, which may provide a unique identifier tonetwork device230 based on receiving the device identifier.
• In some implementations, the upload request may causenetwork device230 to provide the upload request, an authentication request, and/or a unique identifier tostorage device220. For example, after receiving an upload request fromclient device210,network device230 may determine a unique identifier associated withclient device210.Network device230 may further provide an authentication request that includes the unique identifier and/or the upload request tostorage device220, to causestorage device220 to authenticate client device210 (e.g., to determine ifclient device210 is permitted to upload the file, to ensure thatclient device210 is genuine, to ensure thatclient device210 is not stolen, or the like). In this way,network device210 may improve security ofstorage device220 by requesting authentication ofclient device210 before providing the unique identifier toclient device210.
• In some implementations,storage device220 may provide the unique identifier toclient device210 based on a result of authenticatingclient device210. As an example, assume thatstorage device220 successfully authenticatesclient device210. Based on successfully authenticatingclient device210,storage device220 may provide the unique identifier toclient device210. As another example, assume thatclient device210 has been stolen or compromised (e.g., has been hacked). Assume further that authentication information associated withclient device210 indicates thatclient device210 has been stolen or compromised. Based on the authentication information,storage device220 may fail to authenticateclient device210. Based on failing to authenticateclient device210,storage device220 may not provide the unique identifier to client device210 (e.g., to prevent a malicious party from accessing the unique identifier, to prevent a malicious party from accessing an encrypted file associated withclient device210, or the like). In this way,storage device220 may prevent a malicious party from gaining access to encrypted files associated withclient device210.
• In some implementations, the upload request may be provided by a first application associated withclient device210. For example, assume thatclient device210 is associated with a first application and a second application. In some implementations, the first application may provide an upload request to upload a file associated with the first application. In some implementations, the second application may provide a download request to download the file, as described in more detail elsewhere herein. In this way,client device210 may support cross-platform functionality, as described in more detail elsewhere herein.
• As further shown inFIG. 4,process400 may include receiving a unique identifier based on the upload request (block440). For example based on receiving an upload request,network device230 may determine a unique identifier associated withclient device210.Network device230 may provide the unique identifier, the upload request, and/or an authentication request tostorage device220.Storage device220 may successfully authenticateclient device210, and may provide the unique identifier toclient device210 based on successfully authenticatingclient device210. In some implementations,client device210 may receive the unique identifier via a secure session (e.g., a hypertext transfer protocol secure (HTTPS) session, or the like).
• In some implementations,storage device220 may provide the unique identifier toclient device210 based on a result of authenticatingclient device210. As an example, assume thatstorage device220 successfully authenticatesclient device210. Based on successfully authenticatingclient device210,storage device220 may provide the unique identifier toclient device210. As another example, assume thatclient device210 has been stolen or compromised (e.g., has been hacked). Assume further that authentication information associated withclient device210 indicates thatclient device210 has been stolen or compromised. Based on the authentication information,storage device220 may fail to authenticateclient device210. Based on failing to authenticateclient device210,storage device220 may not provide the unique identifier to client device210 (e.g., to prevent a malicious party from accessing the unique identifier, to prevent a malicious party from accessing an encrypted file associated withclient device210, or the like). In this way,storage device220 may prevent a malicious party from gaining access to encrypted files associated withclient device210.
• As further shown inFIG. 4,process400 may include generating a security key, for encrypting the file key, based on the unique identifier (block450). For example,client device210 may generate a security key (e.g., a cryptographic key, a private key, or the like) based on the unique identifier. In some implementations,client device210 may apply a hashing algorithm to the unique identifier, and may use a resulting hash value as a security key. In some implementations,client device210 may generate the security key based on receiving the unique identifier. For example,client device210 may generate the security key when the unique identifier is received fromstorage device220.
• As further shown inFIG. 4,process400 may include encrypting the file key, using the security key, to create an encrypted file key (block460). For example,client device210 may encrypt the file key, using the security key, to create an encrypted file key. In some implementations,client device210 may encrypt the file key using an encryption algorithm (e.g., an AES algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the security key. The encrypted file key may be decrypted byclient device210 when decrypting the encrypted file, as described in more detail elsewhere herein.
• As further shown inFIG. 4,process400 may include providing the encrypted file and/or the encrypted file key for storage (block470). For example,client device210 may provide (e.g., upload), tostorage device220, the encrypted file and/or the encrypted file key. In some implementations,client device210 may provide the unique identifier in association with the encrypted file and/or the encrypted file key, to aidstorage device220 in identifying the encrypted file, the encrypted file key, and/orclient device210. In some implementations, the encrypted file and/or the encrypted file key may be provided via a secure session (e.g., an HTTPS session, or the like). In this way,client device210 may encrypt a file key based on a unique identifier provided bynetwork device230, and may provide the encrypted file and the encrypted file key for storage tostorage device220, which may improve security of the file by eliminating the need for the user to provide a credential used to encrypt the file (e.g., the unique identifier may be used as the credential).Client device210 may further improve security of the file by providing the encrypted file and the encrypted file key tostorage device220, rather than storing the encrypted file and the encrypted file key locally.
• In some implementations, a first application associated withclient device210 may provide the encrypted file and the encrypted file key. For example, assume thatclient device210 is associated with a first application and a second application. Assume further that the first application provided an upload request tonetwork device230. In that case, the first application may provide the encrypted file and the encrypted file key tostorage device220. In some implementations, the second application may provide the download request and/or may receive the encrypted file and/or the encrypted file key, as described in more detail elsewhere herein. In this way, implementations described herein may provide cross-platform functionality for client-side encryption.
• In some implementations,client device210 may not store the file key locally (e.g., may delete the file key from memory). For example, assume thatclient device210 encrypts the file based on the file key, and encrypts the file key based on the security key. Rather than storing the file key locally (e.g., for decrypting the encrypted file),client device210 may delete the file key. In some implementations,client device210 may later generate the file key by decrypting the encrypted file key using the security key. In this way,client device210 may improve security of the encrypted file by not storing the file key locally, which may prevent a malicious party from decrypting the file after accessingclient device210.
• As further shown inFIG. 4,process400 may include storing the security key locally (block480). For example,client device210 may store the security key locally. In some implementations,client device210 may use the security key to decrypt an encrypted file key received fromstorage device220, as described in more detail elsewhere herein. In this way,client device220 may improve security of the encrypted file by storing the encrypted file key and the security key on different devices.
• In some implementations,client device210 may not store the security key locally. For example, assume thatclient device210 encrypts the file key based on the security key. Rather than storing the security key locally (e.g., for decrypting the encrypted file key),client device210 may delete the security key. In some implementations,client device210 may later generate the security key based on the unique identifier. In this way,client device210 may improve security of the encrypted file by not storing the security key locally, which may prevent a malicious party that accessesclient device210 from determining the security key.
• In some implementations,client device210 may provide the security key. For example,client device210 may provide the security key to another device (e.g., anotherclient device210, or the like). In some implementations,client device210 may provide the security key to the other device via a secure channel (e.g., a secure session, an encrypted session, or the like). Additionally, or alternatively,client device210 may provide the security key to the other device using a physical medium (e.g., a computer-readable medium, or the like). The other device may use the security key to decrypt the encrypted file key, and may use the file key to decrypt the encrypted file. In some implementations, a user ofclient device210 may provide the security key (e.g., via user input) to one or moreother client devices210 to enable the other client device(s)210 to encrypt and/or decrypt a file key and/or a file. In this way,client device210 may support cross-platform functionality by providing a security key to another device.
• AlthoughFIG. 4 shows example blocks ofprocess400, in some implementations,process400 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 4. Additionally, or alternatively, two or more of the blocks ofprocess400 may be performed in parallel.
• FIGS. 5A-5C are diagrams of anexample implementation500 relating toexample process400 shown inFIG. 4.FIGS. 5A-5C show an example of encrypting and uploading a file and a credential used to encrypt the file.
• As shown inFIG. 5A, and byreference number505,client device210 may generate a file key (e.g., shown as file_key) for encrypting a file before uploading the file tostorage device220. Assume thatclient device210 generates the file key by generating a string of random characters and using the string of random characters as the file key. As shown byreference number510,client device210 may encrypt the file, using the file key, to generate an encrypted file (e.g., shown as [file]_{file_key}). Assume thatclient device210 applies an AES encryption algorithm to the file, using the file key, to create the encrypted file.
• As further shown inFIG. 5A, and byreference number515,client device210 may provide, tonetwork device230, an upload request. As further shown, the upload request may include information that identifies the file (e.g., shown as [file]_{file_key}). As shown byreference number520,network device230 may receive the upload request. As further shown,network device230 may generate a unique identifier (e.g., shown as a Unique ID of 1245769) associated withclient device210.
• As shown inFIG. 5B, and byreference number525,network device230 may provide, tostorage device220, an authentication request. As further shown, the authentication request may include the upload request and the unique ID of 1245769 As shown byreference number530,storage device220 may authenticate the unique ID of 1245769 As shown byreference number535, based on successfully authenticating the unique identifier,storage device220 may provide the unique ID of 1245769 to client device210 (e.g., may provide the unique ID of 1245769 toclient device210, rather than a different device, based on the unique ID being associated with client device210).
• As shown by reference number540,client device210 may create a security key based on the unique identifier (e.g., shown as security_key). Assume thatclient device210 generates the security key by applying a hashing algorithm to the unique identifier and using a resulting hash value as the security key. As shown byreference number545,client device210 may store the security key locally.
• As shown inFIG. 5C, and byreference number550,client device210 may encrypt the file key based on the security key to create an encrypted file key (e.g., shown as [file key]_{security_key}). Assume thatclient device210 applies an AES algorithm to the file key, using the security key, to create the encrypted file key. As shown byreference number555,client device210 may provide, tostorage device220, the encrypted file and the encrypted file key. As shown byreference number560,storage device220 may receive and store the encrypted file and the encrypted file key. As described herein,client device210 may encrypt the file based on the file key, and may encrypt the file key based on the security key.Client device210 may provide the encrypted file key and the encrypted file, and may locally store the security key. In this way,client device210 may prevent a malicious party from decrypting the encrypted file (e.g., by storing the file key and the security key on different devices, and by requiring authentication to determine the unique identifier used to encrypt the file key).
• As indicated above,FIGS. 5A-5C are provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 5A-5C.
• FIG. 6 is a flow chart of anexample process600 for updating a stored encrypted file key based on a new unique identifier. In some implementations, one or more process blocks ofFIG. 6 may be performed byclient device210. In some implementations, one or more process blocks ofFIG. 6 may be performed by another device or a set of devices separate from or includingclient device210, such asstorage device220 and/ornetwork device230.
• As shown inFIG. 6,process600 may include receiving a new unique identifier (block610). For example,client device210 may receive, fromstorage device220 ornetwork device230, a new unique identifier.Client device210 may receive the new unique identifier periodically (e.g., every week, every month, or the like). In some implementations,client device210 may receive the new unique identifier based on an interaction. For example, another device, such asstorage device220, may causenetwork device230 to provide the new unique identifier. In some implementations,network device230 may generate the new unique identifier. Additionally, or alternatively,network device230 may receive the new unique identifier from another device, such as a home subscriber server device, an authentication authorization and accounting device, or the like. In some implementations,client device210 may receive the new unique identifier via a secure session (e.g., an HTTPS session, or the like).
• Client device210 may receive the new unique identifier in order to facilitate updating the encryption of the encrypted file key. By updating the encryption of the encrypted file key,client device210 may improve the security of the encrypted file. For example, assume that a malicious party determines an old security key associated withclient device210. Assume further thatclient device210 has provided, tostorage device220, a new encrypted file key based on a new security key. The malicious party may be unable to decrypt the new encrypted file key, despite determining the old security key. In this way,client device210 may improve the security of the encrypted file.
• In some implementations, the new unique identifier may include information that is included in a unique identifier, as described above in connection withFIG. 4. For example, the new unique identifier may include information that identifies a type ofclient device210, information that identifies a user ofclient device210, information that identifies a service thatclient device210 is authorized to access, information that describes a geographical location ofclient device210, or the like. In some implementations, the new unique identifier may include information that identifies the new unique identifier as a new unique identifier (e.g., a version identifier, or the like).
• As further shown inFIG. 6,process600 may include generating a new security key based on the new unique identifier (block620). For example,client device210 may generate a new security key based on the new unique identifier. In some implementations,client device210 may generate the new security key by using the new unique identifier in a similar manner as described in connection withblock450 ofFIG. 4. The new security key may be used to generate a new encrypted file key after decrypting an old encrypted file key using an old security key. In this way,client device210 may improve security of the encrypted file by periodically creating a new encrypted file key based on a new security key.
• As further shown inFIG. 6,process600 may include providing an update request to a device that stores an old encrypted file key (block630). For example,client device210 may provide an update request tostorage device220, based onstorage device220 storing an old encrypted file key. The old encrypted file key may be an encrypted file key previously encrypted and provided byclient device210. In some implementations, the update request may include the old unique identifier.Storage device220 may use the old unique identifier to identify the encrypted file key associated withclient device210.
• In some implementations,client device210 may provide the update request without user input (e.g., automatically). For example, assume thatclient device210 receives a new unique identifier.Client device210 may provide an update request tostorage device220 based on receiving the new unique identifier. In this way,client device210 may ensure that the encrypted file key is updated as the unique identifier is updated, which may improve security of the encrypted file.
• As further shown inFIG. 6,process600 may include receiving the old encrypted file key based on the update request (block640). For example,storage device220 may determine the old encrypted file key based on the update request, and may provide the old encrypted file key toclient device210.Client device210 may receive the old encrypted file key based on the update request.
• As further shown inFIG. 6,process600 may include decrypting the encrypted file key, using an old security key, to recover a file key (block650). For example,client device210 may decrypt the old encrypted file key using an old security key (e.g., the old security key may be a security key used byclient device210 to encrypt the old encrypted file key), to recover a file key. The file key may be used to encrypt a file and/or decrypt an encrypted file, as described in more detail elsewhere herein. In some implementations,client device210 may decrypt the old encrypted file key using a decryption algorithm (e.g., an AES algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the old security key.
• As further shown inFIG. 6,process600 may include encrypting the file key, using the new security key, to generate a new encrypted file key (block660). For example,client device210 may encrypt the file key, based on the new security key, to generate a new encrypted file key. The new encrypted file key generated byclient device210 may be different than the old encrypted file key received by client device210 (e.g., the old encrypted file key may be encrypted based on the old security key, whereas the new encrypted file key may be encrypted based on the new security key). In some implementations,client device210 may encrypt the file key using an encryption algorithm (e.g., an AES algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the new security key.
• As further shown inFIG. 6,process600 may include providing the new encrypted file key to the device (block670). For example,client device210 may provide the new encrypted file key tostorage device220 for storage. In some implementations,client device210 may provide the new encrypted file key via a secure session (e.g., an HTTPS session, or the like). In some implementations,client device210 may provide the new unique identifier in association with the new encrypted file key.Storage device220 may associate the new encrypted file key and the new unique identifier, which may aidstorage device220 in identifying the new encrypted file key. In some implementations,storage device220 may delete the old encrypted file key and/or may replace the old encrypted file key with the new encrypted file key. In this way,client device210 may improve security of the encrypted file, by periodically generating new encrypted file keys and providing the new encrypted file keys tostorage device220.
• As further shown byFIG. 6,process600 may include storing the new security key (block680). For example,client device210 may store the new security key. In some implementations,client device210 may use the new security key to decrypt a new encrypted file key, as described in more detail elsewhere herein. In some implementations,client device210 may delete the old security key and/or may replace the old security key with the new security key. In this way,client device210 may update the encrypted file key based on the new unique identifier, which may improve security of the encrypted file by ensuring that a malicious party that determines an old encrypted file key is incapable of decrypting the encrypted file.
• AlthoughFIG. 6 shows example blocks ofprocess600, in some implementations,process600 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 6. Additionally, or alternatively, two or more of the blocks ofprocess600 may be performed in parallel.
• FIGS. 7A-7C are diagrams of anexample implementation700 relating toexample process600 shown inFIG. 6.FIGS. 7A-7C show an example of updating a stored security key based on a new unique identifier. For the purposes ofFIGS. 7A-7C, assume that the operations described herein in connection withFIGS. 5A-5C have been performed.
• As shown inFIG. 7A, and byreference number705,client device210 may store an old security key (e.g., security_key_old), which may correspond to the security key stored byclient device210 as shown inFIG. 5C. As shown byreference number710,network device230 may generate a new unique identifier that identifies client device210 (e.g., a new Unique ID of 524691). As shown byreference number715,network device230 may provide the new unique identifier to client device210 (e.g., in a “Unique ID Update” message that includes the new unique identifier). Assume thatclient device210 receives the new unique identifier. As shown byreference number720,client device210 may generate a new security key based on the new unique identifier (e.g., shown as security_key_new). Assume thatclient device210 continues to store the old security key.
• As shown inFIG. 7B, and byreference number725,client device210 may provide an update request tostorage device220, requesting to update an old encrypted file key stored bystorage device220. Assume thatclient device210 provides the update request based on receiving the new unique identifier. As shown byreference number730,storage device220 may authenticate the update request. Assume thatstorage device220 successfully authenticates the update request. As shown byreference number735, based on successfully authenticating the update request,storage device220 may provide the old encrypted file key (e.g., shown as [file key]_{security_key_old}). Assume that the old encrypted file key is associated withclient device210.
• As shown inFIG. 7C, and byreference number740,client device210 may decrypt the old encrypted file key using the old security key (e.g., based on the old encrypted file key being encrypted using the old security key) to recover the file key (e.g., shown as file_key). As shown byreference number745,client device210 may encrypt the file key using the new security key to generate a new encrypted file key (e.g., shown as [file key]_{security_key_new}).
• As further shown inFIG. 7C, and byreference number750,client device210 may provide the new encrypted file key tostorage device220. As shown byreference number755,storage device220 may store the new encrypted file key. In some implementations,storage device220 may delete the old encrypted file key. Additionally, or alternatively,client device210 may delete the old security key. In this way,client device210 may update an encrypted file key stored bystorage device220, which may improve security of a file encrypted using the encrypted file key.
• As indicated above,FIGS. 7A-7C are provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 7A-7C.
• FIG. 8 is a flow chart of anexample process800 for downloading and decrypting an encrypted file and a file key used to encrypt the file. In some implementations, one or more process blocks ofFIG. 8 may be performed byclient device210. In some implementations, one or more process blocks ofFIG. 8 may be performed by another device or a set of devices separate from or includingclient device210, such asstorage device220 and/ornetwork device230.
• As shown inFIG. 8,process800 may include providing a download request to download an encrypted file (block810). For example,client device210 may provide a download request tonetwork device230. The download request may request thatstorage device220 provide the encrypted file and/or the encrypted file key. In some implementations,client device210 may provide the download request via a secure session (e.g., an HTTPS session, or the like).
• In some implementations,network device230 may generate an authentication request based on the download request. For example, based on receiving the download request,network device230 may generate an authentication request to causestorage device220 to authenticateclient device210. In some implementations,network device230 may provide the authentication request tostorage device220.
• In some implementations, the download request may be provided by a different application than an application that provided an upload request. For example, assume thatclient device210 is associated with a first application and a second application. Assume further that a first application uploaded an encrypted file. In some implementations, the second application may provide a download request (e.g., to causestorage device220 to provide the encrypted file to client device210). In this way,client device210 may support cross-platform functionality by providing the encrypted file via the first application and receiving the encrypted file via the second application.
• As further shown inFIG. 8,process800 may include receiving the encrypted file and an encrypted file key based on the download request (block820). For example,client device210 may receive, fromstorage device220, an encrypted file and an encrypted file key based on the download request. In some implementations,client device210 may receive the encrypted file and/or the encrypted file key based on the unique identifier associated withclient device210. For example, based on the unique identifier,storage device220 may determine a device identifier associated withclient device210, and may provide the encrypted file and/or the encrypted file key toclient device210 based on the device identifier. In some implementations,client device210 may receive the encrypted file and the encrypted file key via a secure session (e.g., an HTTPS session, or the like).
• As further shown inFIG. 8,process800 may include decrypting the encrypted file key, using a security key, to recover a file key (block830). For example,client device210 may decrypt the encrypted file key, using a security key, to recover a file key. In some implementations,client device210 may store the security key locally. In some implementations,client device210 may decrypt the encrypted filing key using a decryption algorithm (e.g., an AES algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the security key. In some implementations, the security key may be the security key used to encrypt the encrypted file key, as described herein in connection withFIG. 4 andFIG. 6.
• In some implementations,client device210 may decrypt the encrypted file key using a received security key. For example,client device210 may receive a security key from another device (e.g., another client device210) via a secure channel, a physical medium, user input, or the like.Client device210 may use the security key to decrypt the encrypted file key. In this way,client device210 may support cross-platform functionality by using a received security key to decrypt an encrypted file key.
• As further shown inFIG. 8,process800 may include decrypting the encrypted file, using the file key, to recover a file (block840). For example,client device210 may decrypt the encrypted file, using the file key, to recover a file. In some implementations,client device210 may decrypt the encrypted file using a decryption algorithm (e.g., an AES algorithm, an RSA algorithm, an MD5 algorithm, or the like) that utilizes the file key.
• In this way,client device210 may decrypt an encrypted file key using a security key, and may decrypt an encrypted file using the decrypted file key to create a decrypted file that was originally encrypted byclient device210. By storing the security key and the encrypted file key on different devices, and by generating the security key based on a unique identifier provided bynetwork device230,client device210 may improve security of the file.
• AlthoughFIG. 8 shows example blocks ofprocess800, in some implementations,process800 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 8. Additionally, or alternatively, two or more of the blocks ofprocess800 may be performed in parallel.
• FIGS. 9A and 9B are diagrams of anexample implementation900 relating toexample process800 shown inFIG. 8.FIGS. 9A and 9B show an example of downloading and decrypting an encrypted file and a file key used to encrypt the file. For the purposes ofFIGS. 9A and 9B, assume that the operations described herein in connection withFIGS. 5A-5C have been performed.
• As shown inFIG. 9A, and byreference number910,client device210 may provide, tonetwork device230, a download request. As further shown, the download request may identify an encrypted file (e.g., [file]_{file_key}). As shown byreference number920,network device230 may receive the download request. As further shown,network device230 may determine a unique identifier associated with client device210 (e.g., a Unique ID of 1245769).
• As shown inFIG. 9B, and byreference number930,network device230 may provide, tostorage device220, an authentication request. As further shown, the authentication request may include the Unique ID of 1245769 and the download request. As shown byreference number940,storage device220 may successfully authenticateclient device210. As shown byreference number950,storage device220 may determine an encrypted file and a stored encrypted file key that are associated with the Unique ID of 1245769 (e.g., [file]_{file_key}and [file_key]_{security_key}). As shown byreference number960,storage device220 may provide, toclient device210, the encrypted file and the encrypted file key.
• As further shown inFIG. 9B, and byreference number970,client device210 may decrypt the encrypted file key. Assume thatclient device210 decrypts the encrypted file key using a security key stored byclient device210.Client device210 may decrypt the encrypted file key to recover a file key used byclient device210 to encrypt the file. As shown byreference number980,client device210 may decrypt the encrypted file, based on the file key thatclient device210 decrypted using the security key, to recover a file.
• In this way,client device210 may decrypt an encrypted file key using a security key, and may decrypt an encrypted file using the file key to recover a file that was originally encrypted byclient device210. By generating the security key based on a unique identifier provided bynetwork device230, rather than a relatively insecure user-provided credential,client device210 may improve security of the file.
• As indicated above,FIGS. 9A and 9B are provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 9A and 9B.
• In this way,client device210 may improve security of the encrypted file, by generating a security key based on a network-provided unique identifier, rather than a user-provided password.Client device210 may further improve security of the encrypted file by storing the security key and a file key on different devices, and by re-encrypting an encrypted file key periodically based on a new unique identifier.
• The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.
• As used herein, the term component is intended to be broadly construed as hardware, firmware, or a combination of hardware and software.
• To the extent the aforementioned embodiments collect, store, or employ personal information provided by individuals, it should be understood that such information shall be used in accordance with all applicable laws concerning protection of personal information.
• Additionally, the collection, storage, and use of such information may be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as may be appropriate for the situation and type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.
• It will be apparent that systems and/or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods were described herein without reference to specific software code—it being understood that software and hardware can be designed to implement the systems and/or methods based on the description herein.
• Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.
• No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Furthermore, as used herein, the terms “group” and “set” are intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims (20)

What is claimed is:

1. A device, comprising:

one or more processors to:

provide an upload request to upload a file;

receive, based on the upload request, a unique identifier associated with the device;

obtain a file key for encrypting the file and a security key for encrypting the file key,

the security key being obtained based on the unique identifier;

encrypt the file, using the file key, to create an encrypted file;

encrypt the file key, using the security key, to create an encrypted file key; and

provide the encrypted file and the encrypted file key for storage by a storage device.

2. The device ofclaim 1, where the one or more processors are further to:

provide a download request to download the encrypted file;

obtain, based on the download request, the encrypted file and the encrypted file key;

decrypt the encrypted file key, using the security key, to recover the file key; and

decrypt the encrypted file, using the file key, to recover the file.

3. The device ofclaim 2, where the one or more processors, when providing the upload request, are further to:

provide, by a first application associated with the device, the upload request; and

where the one or more processors, when providing the encrypted file and the encrypted file key, are further to:

provide, by the first application, the encrypted file and the encrypted file key; and

where the one or more processors, when providing the download request, are further to:

provide, by a second application associated with the device, the download request,

the second application being different than the first application; and

where the one or more processors, when receiving the encrypted file and the encrypted file key, are further to:

receive, by the second application, the encrypted file and the encrypted file key.

4. The device ofclaim 2, where the one or more processors, when providing the download request, are further to:

provide the download request to a network device for authentication; and

where the one or more processors, when receiving the encrypted file and the encrypted file key, are further to:

receive the encrypted file and the encrypted file key based on the download request being authenticated.

5. The device ofclaim 2, where the one or more processors, when providing the encrypted file and the encrypted file key, are further to:

provide, to the storage device and in association with the encrypted file and the encrypted file key, the unique identifier; and

where the one or more processors, when receiving the encrypted file and the encrypted file key, are further to:

receive the encrypted file and the encrypted file key based on the unique identifier.

6. The device ofclaim 1, where the encrypted file key is a first encrypted file key;

where the unique identifier is a first unique identifier;

where the security key is a first security key; and

where the one or more processors are further to:

receive a second unique identifier associated with the device,

the second unique identifier being different than the first unique identifier;

obtain a second security key based on the second unique identifier,

the second security key being different than the first security key;

provide an update request for the first encrypted file key;

receive the first encrypted file key based on the update request;

decrypt, using the first security key, the first encrypted file key to recover the file key;

encrypt, using the second security key, the file key to create a second encrypted file key; and

provide, to the storage device, the second encrypted file key.

7. The device ofclaim 1, where the one or more processors, when providing the upload request, are further to:

provide the upload request to a network device for determining the unique identifier; and

where the one or more processors, when receiving the unique identifier, are further to:

receive the unique identifier from the network device or the storage device.

8. A computer-readable medium storing instructions, the instructions comprising:

one or more instructions that, when executed by one or more processors, cause the one or more processors to:

provide an upload request to upload a file;

receive, based on the upload request, a unique identifier;

obtain a file key for encrypting the file and a security key for encrypting the file key,

the security key being obtained based on the unique identifier;

encrypt the file, using the file key, to create an encrypted file;

encrypt the file key, using the security key, to create an encrypted file key; and

provide the encrypted file and the encrypted file key for storage by a storage device.

9. The computer-readable medium ofclaim 8, where the one or more instructions, when executed by the one or more processors, further cause the one or more processors to:

provide a download request to download the encrypted file;

receive, based on the download request, the encrypted file and the encrypted file key;

decrypt the encrypted file key, using the security key, to recover the file key; and

decrypt the encrypted file, using the file key, to recover the file.

10. The computer-readable medium ofclaim 9, where the one or more instructions, that cause the one or more processors to provide the upload request, further cause the one or more processors to:

provide, by a first application associated with the one or more processors, the upload request; and

where the one or more instructions, that cause the one or more processors to provide the encrypted file and the encrypted file key, further cause the one or more processors to:

provide, by the first application, the encrypted file and the encrypted file key; and

where the one or more instructions, that cause the one or more processors to provide the download request, further cause the one or more processors to:

provide, by a second application associated with the one or more processors, the download request,

the second application being different than the first application; and

where the one or more instructions, that cause the one or more processors to receive the encrypted file and the encrypted file key, further cause the one or more processors to:

receive, by the second application, the encrypted file and the encrypted file key.

11. The computer-readable medium ofclaim 9, where the one or more instructions, that cause the one or more processors to provide the download request, further cause the one or more processors to:

provide the download request to a network device for authentication; and

where the or more instructions, that cause the one or more processors to receive the encrypted file and the encrypted file key, further cause the one or more processors to:

receive the encrypted file and the encrypted file key based on the authentication.

12. The computer-readable medium ofclaim 9, where the one or more instructions, that cause the one or more processors to provide the encrypted file and the encrypted file key, further cause the one or more processors to:

provide, to the storage device and in association with the encrypted file and the encrypted file key, the unique identifier; and

where the one or more instructions, that cause the one or more processors to receive the encrypted file and the encrypted file key, further cause the one or more processors to:

receive the encrypted file and the encrypted file key based on the unique identifier.

13. The computer-readable medium ofclaim 8, where the encrypted file key is a first encrypted file key;

where the unique identifier is a first unique identifier;

where the security key is a first security key; and

where the one or more instructions, when executed by the one or more processors, further cause the one or more processors to:

receive a second unique identifier,

the second unique identifier being different than the first unique identifier;

obtain a second security key based on the second unique identifier,

the second security key being different than the first security key;

provide an update request for the first encrypted file key;

receive the first encrypted file key based on the update request;

decrypt, using the first security key, the first encrypted file key to recover the file key;

encrypt, using the second security key, the file key to create a second encrypted file key; and

provide, to the storage device, the second encrypted file key.

14. The computer-readable medium ofclaim 8, where the one or more instructions, that cause the one or more processors to provide the upload request, further cause the one or more processors to:

provide the upload request to a network device for determining the unique identifier; and

where the one or more instructions, that cause the one or more processors to receive the unique identifier, further cause the one or more processors to:

receive the unique identifier from the network device or the storage device.

15. A method, comprising:

providing, by a device, an upload request to upload a file;

receiving, by the device and based on the upload request, a unique identifier associated with the device;

obtaining, by the device, a file key for encrypting the file and a security key for encrypting the file key,

the security key being obtained based on the unique identifier;

encrypting the file, by the device and using the file key, to create an encrypted file;

encrypting the file key, by the device and using the security key, to create an encrypted file key; and

outputting, by the device, the encrypted file and the encrypted file key.

16. The method ofclaim 15, further comprising:

providing a download request to download the encrypted file;

receiving, based on the download request, the encrypted file and the encrypted file key;

decrypting the encrypted file key, using the security key, to recover the file key; and

decrypting the encrypted file, using the file key, to recover the file.

17. The method ofclaim 16, where providing the upload request further comprises:

providing, by a first application associated with the device, the upload request; and

where providing the encrypted file and the encrypted file key further comprises:

providing, by the first application, the encrypted file and the encrypted file key; and

where providing the download request further comprises:

providing, by a second application associated with the device, the download request,

the second application being different than the first application; and

where receiving the encrypted file and the encrypted file key further comprises:

receiving, by the second application, the encrypted file and the encrypted file key.

18. The method ofclaim 16, where providing the download request further comprises:

providing the download request to a network device for authentication; and

where receiving the encrypted file and the encrypted file key further comprises:

receiving the encrypted file and the encrypted file key based on the download request being authenticated.

19. The method ofclaim 15, where the encrypted file key is a first encrypted file key;

where the unique identifier is a first unique identifier;

where the security key is a first security key; and

where the method further comprises:

receiving a second unique identifier associated with the device,

the second unique identifier being different than the first unique identifier;

obtaining a second security key based on the second unique identifier,

the second security key being different than the first security key;

providing an update request for the first encrypted file key;

receiving the first encrypted file key based on the update request;

decrypting, using the first security key, the first encrypted file key to recover the file key;

encrypting, using the second security key, the file key to create a second encrypted file key; and

providing, to the storage device, the second encrypted file key.

20. The method ofclaim 15, where providing the upload request further comprises:

providing the upload request to a network device for determining the unique identifier; and

where receiving the unique identifier further comprises:

receiving the unique identifier from the network device or a storage device, the network device being different than the storage device.

Images