CLIENT-SIDE ENCRYPTION

Abstract

Methods and systems of encrypting files at a client in a cloud-based file system are provided. A first key corresponding to an organization to which the client belongs is obtained. Then a first file is encrypted using the first key. Then the encrypted first file is transmitted to a server via a secure channel, for storage in a storage device shared among multiple organizations, the storage device containing one or more files encrypted using keys different than the first key.

Description

CROSS-RELATION TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No. 61/820,793 filed May 8, 2013, which is hereby incorporated herein by reference in its entirety.

TECHNICAL FIELD

This application relates generally to cloud-based file storage. More particularly, this application relates to client-side encryption in a cloud-based file storage.

BACKGROUND

With the dramatic increase in use of mobile devices in recent years, it has become more important now than ever before that a user's files be synchronized between multiple devices. A single user may operate on a desktop computer, laptop computer, tablet computer, and mobile phone, editing the same document at different times on different devices. This issue is only going to become even more important as additional mobile devices, such as wearable computers and vehicle-based computers become popular mechanisms for editing files.

Problems, however, may be encountered as the synchronization of files across devices become more complex. Typically, encryption of objects in a cloud-based storage system is performed on the server-side. Such a system allows for the sharing of documents among multiple users, who each can utilize a key, certificate, or other security object to access a file, folder, or other object in a shared folder on the server. The key, certificate, or other security object may be managed and distributed by the server. The problem is that if one system is cracked, then all the data is potentially at risk. Thus, for example, if hackers obtain access to the server, then all files across all organizations can be cracked.

BRIEF DESCRIPTION OF DRAWINGS

The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1 is a block diagram illustrating a system, in accordance with an example embodiment, of securely synchronizing files.

FIG. 2 is a block diagram illustrating a client device, in accordance with an example embodiment, in more detail.

FIG. 3 is a block diagram illustrating another client device, in accordance with an example embodiment, in more detail.

FIG. 4 is a block diagram illustrating a backend, in accordance with an example embodiment, in more detail.

FIG. 5 is a process flow diagram depicting a method, in accordance with an example embodiment, of client-side encryption prior to upload of a file.

FIG. 6 is a process flow diagram depicting a method, in accordance with an example embodiment, of client-side decryption subsequent to download of a file.

FIG. 7 is a flow diagram illustrating a method, in accordance with an example embodiment, of encrypting files at a client in a cloud-based file system.

FIG. 8 is a flow diagram illustrating a method, in accordance with an example embodiment, of decrypting files at a client in a cloud-based file system.

FIG. 9 is a block diagram illustrating a mobile device, according to an example embodiment.

FIG. 10 is a block diagram of machine in the example form of a computer system within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed.

DETAILED DESCRIPTION

Overview

The description that follows includes illustrative systems, methods, techniques, instruction sequences, and machine-readable media (e.g., computing machine program products) that embody illustrative embodiments. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail.

In an example embodiment, various techniques are utilized in order to allow for efficient, accurate, and secure synchronization of files across multiple devices even in cases where a large number of events are occurring concurrently. This may include using an events-based technique to improve reliability during periods of file modifications being performed concurrently. In another example embodiment, name conflicts between different files may be resolved automatically.

FIG. 1 is a block diagram illustrating a system 100, in accordance with an example embodiment, of securely synchronizing files. In the system 100, files may be synchronized between one or more servers 102 and one or more client devices 104A-104D. The client devices 104A-104D may include various types of devices running various types of platforms with various types of operating systems and applications. For example, client device 104A may be a mobile device running proprietary mobile applications 106. Client device 104B may be a personal computer running a Macintosh™ operating system from Apple Inc. of Cupertino, Calif. This may include a file system known as Finder 108, which may include a specialized plug-in 110 to allow Finder 108 to be altered in order to better operate with a proprietary application 112.

Client device 104C may be a personal computer running a Windows™ operating system from Microsoft Corp. of Redmond, Wash. This may include a file system known as Windows Explorer 114, which may include a specialized plug-in 116 to allow Windows Explorer 114 to be altered in order to better operate with a proprietary application 118. Additionally, applications such as Microsoft Office™ 120 and Microsoft Outlook™ 122 may also include their own specialized plug-ins 124, 126, respectively, which allow them to better operate with the proprietary application 118. Client device 104D may be a web-based device that may operate a web browser 128 instead of a traditional operating system.

Each of the client devices 104A-104D may communicate with a back-end 130 hosted by the one or more servers 102. This communication may either take place directly between the back-end 130 and the proprietary applications 106, 112, 118, or indirectly through a web application 132. A provisioning service, such as HostPilot™ 134 may also be present, and may coordinate with a directory service such as Active Directories 136.

FIG. 2 is a block diagram illustrating a client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds to client device 104C of FIG. 1, although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components in FIG. 2 are labeled as those components are labeled in FIG. 1. In some embodiments, however, the components may not be identical. Proprietary application 116 may be a desktop application, and may store files in a local database 200. The proprietary application 118 may also communicate with specialized plug-ins 116, 124, 126 in Windows Explorer 114, Microsoft Office 120 and Microsoft Outlook™ 122, respectively. This communication may take place, for example, using Thrift over TCP. The proprietary application 118 may communicate with a storage service 202 on the server 102.

FIG. 3 is a block diagram illustrating another client device, in accordance with an example embodiment, in more detail. In an example embodiment, the client device in this figure corresponds to client device 104B of FIG. 1, although in some example embodiments this diagram corresponds to a different client device. Additionally, the various components in FIG. 3 are labeled as those components are labeled in FIG. 1. In some embodiments, however, the components may not be identical. Proprietary application 112 may be a desktop application, and may store files in a local database 300. The proprietary application 112 may also communicate with a specialized plugin 108 in Finder 110. This communication may take place, for example, using Thrift over TCP. The proprietary application 118 may communicate with a storage device 302 on the server 102.

FIG. 4 is a block diagram illustrating a backend, in accordance with an example embodiment, in more detail. In an example embodiment, the backend in this figure corresponds to backend 130 of FIG. 1, although in some example embodiments this diagram corresponds to a different backend. Additionally, the various components in FIG. 4 are labeled as those components are labeled in FIG. 1. In some embodiments, however, the components may not be identical. The backend 130 may include a front-end server 400, which acts to perform much of the server-side storage functions described in this disclosure, as well as interfacing with the various devices. These functions will be discussed in more detail later in this document. The front-end server 400 may interface with client devices 104A-104D through a firewall 402. The front-end server 400 may also interface with a database server 404, which may control access to a database 406. The database 406 may be of many different types of formats. In one example embodiment, the database 406 is a relational database, such as one operated using Structured Query Language (SQL). Other formats of database are envisioned, however, as well, including flat-file and multidimensional databases. The database may store not just files and folders, but also metadata about the files and folders, including, but not limited to, information about which files and folders are shared, and with whom.

A central server 408 performs internal tasks such as cleanup, provisioning, and other backend services. A key management server 410 provides access for keys created for each user. When a user is created on the central server 408, a key may be issued by the key server 410. These keys are also used by an encryption server 412 to encrypt and decrypt files and folders. This is accomplished through the use of the front end server 400, which understands which organization the keys belong and submits file or folder content to the encryption server 412 for encryption. Active Directories 414 is used for integration with Exchange™

Client-Side Encryption

As described earlier, server-based encryption in a cloud storage environment is risky in that if one organization's key is cracked, access to the server puts all organizations at risk. In an example embodiment, client-side encryption of data is performed. Each organization may have its own key. In this way, if the server is cracked, then no data is at risk because accessing the encrypted data on the server will not allow a malicious user to view the data.

FIG. 5 is a process flow diagram depicting a method 500, in accordance with an example embodiment, of client-side encryption prior to upload of a file. A client 502 encrypts data using a key 504 distributed by a key management system (KMS) 506. The KMS may be, for example, an external server whose job it is to manage and distribute keys to organizations of the cloud-based service. The encrypted data is uploaded through a secure channel 508 to a storage service 510, which stores the encrypted data in storage 512 via another secure channel 514. For purposes of this disclosure, a secure channel may be any means of electronic communication that utilizes a mechanism to prevent users not intended to be a recipient of a message from viewing or reading a message. This may include any type of transmission medium, such as wired or wireless. One example secure channel is HyperText Transfer Protocol Secure (HTTPS), although this is merely one example and is not intended to be limiting.

Each organization may have a single key created especially for it, and unique to that organization. In some example embodiments, an organization may have more than one key to allow for even greater security (e.g., the quarantining of sensitive information within the organization, so a hacker obtaining or cracking a key from one division of the organization cannot view or modify information from another division of the organization). If a key is compromised, then that would only affect the one organization—other organizations that share the storage 512 would not have their own files at risk. In an example embodiment, the storage service 510 has no access to the key management service 506 and vice-versa, so if one system is cracked, the data of other organizations cannot be decrypted.

FIG. 6 is a process flow diagram depicting a method 600, in accordance with an example embodiment, of client-side decryption subsequent to download of a file. Here, the client 602 requests data via a secure channel 604 from the storage service 606, which retrieves encrypted data via secure channel 608 from the storage 610. The encrypted data may contain a key identifier, which the client 602 uses to obtain a key 612 from the key management system 614, and then uses the key to decrypt the encrypted data locally. In one or more example embodiments, one or more of the components 602-614 may be identical to components described in FIG. 5. For example, client 602 may be the same client as client 502. Secure channel 604 may be the same channel as secure channel 508. Storage service 606 may be the same service as storage service 510. Secure channel 608 may be the same channel as secure channel 514. Storage 610 may be the same storage as storage 512. Key management system 614 may be the same system as key management system 506.

As described above, each organization may have its own key. This key may be obtained by or shared with various members of the organization, allowing these members to decrypt files stored on the server. In the event that a file needs to be shared among members of two (or more) different organizations, a unique key may be created for the combination of organizations that allows access to just those cross-organizationally shared documents. For example, a key for organization A may allow members of organization A to access files of organization A. A key for organization B may allow members of organization B to access files of organization B. A key for the combination of organization A and organization B may allow members of organization A and members of organization B to access files that are shared between the organizations.

In an example embodiment, the key management system is located in a low-risk area, not generally accessible to the Internet, to prevent security breaches. This also allows a system administrator to easily remove compromised keys and reallocate new keys without disrupting services.

It should be noted that, based on the type of encryption used, a single “key” assigned to an organization may actually itself comprise a number of different keys. For example, in some example embodiments, the key assigned to an organization may include an encryption key and a decryption key. These keys may be related to each such that the decryption key is used to decrypt files encrypted using the encryption key. Thus, these may be described as using a single key, despite the fact that the decryption key is different than the encryption key.

FIG. 7 is a flow diagram illustrating a method 700, in accordance with an example embodiment, of encrypting files at a client in a cloud-based file system. At operation 702, a first key corresponding to an organization to which the client belongs is obtained. At operation 704, a file is encrypted using the first key. At operation 706, the encrypted file is transmitted to a server via a secure channel, for storage in a storage device shared among multiple organizations, the storage device containing one or more files encrypted using keys different than the first key.

FIG. 8 is a flow diagram illustrating a method 800, in accordance with an example embodiment, of decrypting files at a client in a cloud-based file system. At operation 802, an encrypted file is downloaded from a storage device via a secure channel. At operation 804, a key corresponding to an organization to which the client belongs is obtained. At operation 806, the encrypted file is decrypted using the key.

Example Mobile Device

FIG. 9 is a block diagram illustrating a mobile device 900, according to an example embodiment. The mobile device 900 can include a processor 902. The processor 902 can be any of a variety of different types of commercially available processors suitable for mobile devices 900 (for example, an XScale architecture microprocessor, a Microprocessor without Interlocked Pipeline Stages (MIPS) architecture processor, or another type of processor). A memory 904, such as a random access memory (RAM), a Flash memory, or other type of memory, is typically accessible to the processor 902. The memory 904 can be adapted to store an operating system (OS) 906, as well as application programs 908, such as a mobile location enabled application that can provide LBSs to a user. The processor 902 can be coupled, either directly or via appropriate intermediary hardware, to a display 910 and to one or more input/output (I/O) devices 912, such as a keypad, a touch panel sensor, a microphone, and the like. Similarly, in some embodiments, the processor 902 can be coupled to a transceiver 914 that interfaces with an antenna 916. The transceiver 914 can be configured to both transmit and receive cellular network signals, wireless data signals, or other types of signals via the antenna 916, depending on the nature of the mobile device 900. Further, in some configurations, a GPS receiver 918 can also make use of the antenna 916 to receive GPS signals.

Modules, Components and Logic

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules can constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more processors can be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

In various embodiments, a hardware-implemented module can be implemented mechanically or electronically. For example, a hardware-implemented module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module can also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) can be driven by cost and time considerations.

Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor can be configured as respective different hardware-implemented modules at different times. Software can accordingly configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time.

Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules can be regarded as being communicatively coupled. Where multiple such hardware-implemented modules exist contemporaneously, communications can be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware-implemented modules. In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules can be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module can then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules can also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein can, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein can be at least partially processor-implemented. For example, at least some of the operations of a method can be performed by one of processors or processor-implemented modules. The performance of certain of the operations can be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors can be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors can be distributed across a number of locations.

The one or more processors can also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations can be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).)

Electronic Apparatus and System

Example embodiments can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Example embodiments can be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

In example embodiments, operations can be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments can be implemented as, special purpose logic circuitry, e.g., a FPGA or an ASIC.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures require consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently and temporarily configured hardware can be a design choice. Below are set out hardware (e.g., machine) and software architectures that can be deployed, in various example embodiments.

Example Machine Architecture and Machine-Readable Medium

FIG. 10 is a block diagram of machine in the example form of a computer system 1000 within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, can be executed. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 1000 includes a processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 1004 and a static memory 1006, which communicate with each other via a bus 1008. The computer system 1000 can further include a video display unit 1010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1000 also includes an alpha-numeric input device 1012 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation device 1014 (e.g., a mouse), a disk drive unit 1016, a signal generation device 1018 (e.g., a speaker), and a network interface device 1020.

Machine-Readable Medium

The disk drive unit 1016 includes a machine-readable medium 1022 on which is stored one or more sets of instructions and data structures (e.g., software) 1024 embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1024 can also reside, completely or at least partially, within the main memory 1004 and/or within the processor 1002 during execution thereof by the computer system 1000, with the main memory 1004 and the processor 1002 also constituting machine-readable media 1022.

While the machine-readable medium 1022 is shown in an example embodiment to be a single medium, the term “machine-readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures 1024. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions 1024 for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions 1024. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media 1022 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Transmission Medium

The instructions 1024 can further be transmitted or received over a communications network 1026 using a transmission medium. The instructions 1024 can be transmitted using the network interface device 1020 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 1024 for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter can be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments can be utilized and derived therefrom, such that structural and logical substitutions and changes can be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter can be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose can be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

1. A method of encrypting files at a client in a cloud-based file system, comprising:

obtaining a first key corresponding to an organization to which the client belongs;

encrypting a first file using the first key; and

transmitting the encrypted first file to a server via a secure channel, for storage in a storage device shared among multiple organizations, the storage device containing one or more files encrypted using keys different than the first key.

2. The method of claim 1, further comprising:

downloading an encrypted second file from the storage device via the secure channel;

obtaining a second key related to the first key and corresponding to the organization to which the client belongs; and

decrypting the encrypted second file using the second key.

3. The method of claim 1, wherein the first key is obtaining from a key management system used to assign keys to a plurality of different organizations.

4. The method of claim 2, further comprising:

obtaining access to the storage device and locating one or more encrypted files belonging to organizations other than the organization to which the client belongs;

attempting to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key; and

receiving an indication that the attempt to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key, has failed.

5. The method of claim 1, wherein no other keys than the first key correspond to the organization.

6. The method of claim 1, wherein the organization is a company.

7. The method of claim 1, wherein the organization is a division of a company.

8. A system comprising:

a client device comprising: one or more processors; a memory; a client application executable by the one or more processors and configured to: obtain a first key corresponding to an organization to which the client belongs; encrypt a first file using the first key; and transmit the encrypted first file to a server via a secure channel, for storage in a storage device shared among multiple organizations, the storage device containing one or more files encrypted using keys different than the first key.

9. The system of claim 8, wherein the client application is further configured to:

download an encrypted second file from the storage device via the secure channel;

obtain a second key related to the first key and corresponding to the organization to which the client belongs; and

decrypt the encrypted second file using the second key.

10. The system of claim 8, wherein the first key is obtaining from a key management system used to assign keys to a plurality of different organizations.

11. The system of claim 9, wherein the client application is further configured to:

obtain access to the storage device and locating one or more encrypted files belonging to organizations other than the organization to which the client belongs;

attempt to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key; and

receive an indication that the attempt to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key, has failed.

12. The system of claim 8, wherein no other keys than the first key correspond to the organization.

13. The system of claim 8, wherein the organization is a company.

14. The system of claim 8, wherein the organization is a division of a company.

15. A non-transitory machine-readable storage medium comprising instructions, which when implemented by one or more machines, cause the one or more machines to perform operations comprising:

obtaining a first key corresponding to an organization to which the client belongs;

encrypting a first file using the first key; and

transmitting the encrypted first file to a server via a secure channel, for storage in a storage device shared among multiple organizations, the storage device containing one or more files encrypted using keys different than the first key.

16. The non-transitory machine-readable storage medium of claim 15, further comprising:

downloading an encrypted second file from the storage device via the secure channel;

obtaining a second key related to the first key and corresponding to the organization to which the client belongs; and

decrypting the encrypted second file using the second key.

17. The non-transitory machine-readable storage medium of claim 15, wherein the first key is obtaining from a key management system used to assign keys to a plurality of different organizations.

18. The non-transitory machine-readable storage medium of claim 16, further comprising:

obtaining access to the storage device and locating one or more encrypted files belonging to organizations other than the organization to which the client belongs;

attempting to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key; and

receiving an indication that the attempt to decrypt the one or more encrypted files belonging to organizations other than the organization to which the client belongs, using the first key, has failed.

19. The non-transitory machine-readable storage medium of claim 15, wherein no other keys than the first key correspond to the organization.

20. The non-transitory machine-readable storage medium of claim 15, wherein the organization is a company.