Encrypted File Control

Abstract

The access client can send an access request to the server, and the access request can be an example of a decryption or encryption request. The access request can include access information and file information for the file to be accessed. The server can verify the access information and generate an access package including an access key and a set of executable code. The access key can be sent to the access client. The access client can execute the executable code to decrypt or encrypt the file. The file can include one or more data packs including a file access policy, ownership information, and a file access log.

Description

[Technical field]

[0001] cross reference This patent application claims priority to U.S. patent application Ser. No. 17 / 482,010, by NIJASURE et al., entitled "ENCRYPTED FILE CONTROL," filed on September 22, 2021, and U.S. Provisional Patent Application Ser. No. 63 / 081,763, by NIJASURE et al., entitled "ENCRYPTED FILE CONTROL," filed on September 22, 2020, each of which is assigned to the assignee hereof and is expressly incorporated by reference in its entirety herein.

[0002] Technical Field The present disclosure relates generally to data security, and more specifically, to encrypted file control. [Background technology]

[0003] background File encryption allows files to be shared between computers over insecure networks and can prevent third parties from accessing sensitive data. However, file encryption may only be as secure as the key used to encrypt the file. Summary of the Invention [Means for solving the problem]

[0004] overview The described techniques relate to improved methods, systems, devices, and apparatuses that support encrypted file control. In general, the described techniques provide for sharing encrypted files without compromising the encryption key used to encrypt the file. The encrypted file payload is salted and encrypted with multiple salts and keys stored in multiple repositories. In response to an access request to encrypt or decrypt a file, the server generates an access package that includes information (e.g., data and / or code) for performing the access. For example, if the data pack includes source code, the source code may be injected with the salt and key used to encrypt or decrypt the encrypted file payload. The server sends an access response along with the access package to the access device that sent the access request to the server. The access device may compile the source code from the access package to generate an executable file that can encrypt or decrypt the encrypted file payload. In some cases, the access device may transform the data of the payload based on the data included in the access package. After being used, the executable file and / or the access package may be deleted from the access device to minimize the time that the salt and key are in the memory of the access device. By not storing the salt and key on the access device, the impact and probability of the access device being compromised is reduced.

[0005] BRIEF DESCRIPTION OF THE DRAWINGS [Brief description of the drawings]

[0006] [Figure 1] 1 illustrates an example system that supports encrypted file control in accordance with an aspect of the present disclosure. [Diagram 2] 1 illustrates an example of an encrypted file that supports encrypted file control in accordance with an aspect of the present disclosure. [Diagram 3]1 illustrates an example computing architecture that supports encrypted file control in accordance with an aspect of the present disclosure. [Figure 4] 1 illustrates an example process flow for supporting encrypted file control in accordance with an aspect of the present disclosure. [Diagram 5] 1 illustrates an example process flow for supporting encrypted file control in accordance with an aspect of the present disclosure. [Figure 6] 1 illustrates an example access device scenario that supports encrypted file control in accordance with an aspect of the present disclosure. [Figure 7] 1 illustrates a block diagram of a user device that supports encrypted file control in accordance with an aspect of the present disclosure. [Figure 8] 1 illustrates a diagram of a system including a device that supports encrypted file control in accordance with an aspect of the present disclosure. [Figure 9] FIG. 2 illustrates a block diagram of data security components supporting encrypted file control according to an aspect of the present disclosure. [Figure 10] 1 illustrates a diagram of a system including a device that supports encrypted file control in accordance with an aspect of the present disclosure. [Figure 11] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 12] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 13] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 14] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 15] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 16] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 17] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 18] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 19] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 20] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 21] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 22] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. [Figure 23] 1 shows a flowchart illustrating a method for supporting encrypted file control according to an aspect of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] Detailed Description Encryption techniques are used in various environments to protect data from unauthorized access. Various forms of encryption keys may be used to encrypt data, decrypt data, securely transmit data, etc. However, these techniques require users and systems to maintain control, storage, and visibility of the keys and data to protect the data. For example, organizations implement device management techniques and systems, identity management techniques and systems, storage management techniques and systems, cloud storage techniques and systems, data classification techniques and systems, among other techniques and systems, to protect data. The complexity of these systems and technologies, as well as the proliferation of malicious actors, have led to widespread data loss and unauthorized data access.

[0008] The implementations described herein support systems and techniques for self-protecting, self-aware, and self-intelligent data. The described implementations support access clients configured to interact with a server to protect data using the techniques described herein. These techniques support immediate and dynamic data control. For example, when a first user sends an encrypted file to a second user and the first user no longer wants the second user to access the file. The first user can access the platform to restrict the second user's access to the file in near real-time, even if the second user already has the file on his or her device. These techniques are supported at various levels of granularity, including at the file level, groups of files or folders of files, team level, organizational level, and the like. Additionally, these techniques may be applicable to various elements or portions within a file. For example, a file may contain one or more data objects (e.g., object linking and embedding objects (OLE), images), and these objects may be encrypted and decrypted (separate from the file itself) while applying the various file access policy techniques described herein. Additionally, the described technology supports file access restrictions or policies using a variety of considerations such as geographic location, device type, and time period, among other restrictions. For example, a user can restrict access to a file or group of files by other users in a particular country. These restrictions can be enforced in near real-time, even if other users already have the file on their personal devices in a particular country.

[0009] To support these various techniques, the server can generate and send an access package to the access client running on the user device in response to a request from the access client. The access package can include one or more encryption keys and executable code. The access client is configured to execute the executable code to encrypt or decrypt a payload (e.g., a file). The encrypted file can include one or more data packs that include file ownership information, file access policies, access logs, among other information. These data packs enable the data to be self-intelligent, as described in further detail herein. Additionally, the server with which the access client is configured to communicate can maintain various file access policies, such as authorized user access, device access, etc. The server can maintain a mapping of files and access policies (verification parameters). Thus, upon receiving a request to encrypt / decrypt a file, the server checks whether the user / device is authorized to perform the encryption / decryption, identifies the corresponding key, generates an access package, and sends the access package to the client. Thus, the self-intelligent data configuration, access client, and server function to maintain data security in a dynamic manner. These and other implementations are described in further detail with reference to the drawings.

[0010] Aspects of the present disclosure are first described in the context of a computing environment supporting encrypted file control. Aspects of the present disclosure are further described with respect to access packages supporting encrypted file control, exemplary file control scenarios, and process flow diagrams. Aspects of the present disclosure are further illustrated by and described with reference to device diagrams, system diagrams, and flow charts relating to encrypted file control.

[0011] 1 illustrates an example of a system 100 that supports encrypted file control according to an aspect of the present disclosure. The system 100 is configured to create and control access to encrypted files. The system 100 includes an access device 105, a mobile device 110, a server 115, and a repository 120.

[0012] The access devices 105 interact with encrypted files based on communication with the server 115. Each of the access devices 105, along with an access client 125 executing on the access device 105, can function as an encryption device for generating and encrypting files and as a decryption device for decrypting and viewing the encrypted files. As an example, the access device 105b may be an encryption device that (in cooperation with the server 115) generates encrypted files and transmits the encrypted files to the access device 105a. The access device 105a may be a decryption device that (in cooperation with the server 115) decrypts the encrypted files and views the encrypted files according to policies associated with the encrypted files.

[0013] The access device 105 may be an example of a computing system according to that described in Figure 8, such as a smartphone, a laptop computer, a tablet, a desktop computer, etc. The access device 105 may interact with other access devices 105, mobile devices 110, and servers 115 using wired or wireless communication techniques.

[0014] The access device 105a can encrypt files, receive encrypted files from other access devices, interact with the server 115 to generate and access encrypted files, present information decrypted from encrypted files, establish connections with the mobile device 110, and update data. The access device 105a includes an access client 125.

[0015] The access client 125 is a set of programs running on the access device 105a that create, access, and view encrypted files. The access client 125 may be a native application or a web-based application that runs through a web browser on the access device 105a. The access application may include a user interface 130a and an access executable 135a. The access client 125 may also be an application plug-in for various file viewing applications such as word processing applications, spreadsheet applications, etc.

[0016] The user interface 130a is the part of the access client 125 that handles user interactions. The user interface 130a includes user interface elements (such as buttons, text boxes, media player windows, etc.) that provide output to the user and receive input from the user. The access executable 135a is an executable file created by the access device 105a from an access package from the server 115 to manipulate encrypted files on the access device 105a. As an example, the access executable 135a may be a dynamic link library (DLL). The access executable 135a includes access functions 140a. The access functions 140a are parts of the access executable 135a that perform functions. The access functions 140a may be an encryption function that creates an encrypted file, a decryption function that decrypts the encrypted file, a termination function that deletes the encrypted file, a decoy function, etc. The decoy function may provide an output of the encrypted file that is similar to the output expected from the encrypted file but does not include data from the payload of the encrypted file.

[0017] The access device 105b includes an access client 125b that includes a user interface 130b and an access executable file 135b. The access executable file 135b includes access functions 140b. The hardware and components of the access device 105b operate similarly to those of the access device 105a.

[0018] The mobile device 110 interacts with the access device 105a to establish a network connection and transfer data. The mobile device 110 is a computing system according to that described in FIG. 8 and may be, for example, a smartphone, a desktop computer, a laptop computer, a tablet, or other type of personal device (e.g., a security card or a security key). The mobile device 110 can establish a personal area wireless connection with the access device 105a and transfer location information. The mobile device 110 includes a mobile application 145.

[0019] The mobile application 145 is a set of programs running on the mobile device 110 that establishes a connection with the access device 105a, collects location data, and transfers the location data. The mobile application 145 can determine the location of the mobile device and collect location data from the positioning system of the mobile device 110 (e.g., a Global Positioning System (GPS) module), which can include the longitude, latitude, and altitude of the mobile device 110.

[0020] Server 115 interacts with other components of system 100 to control access to encrypted files. Server 115 may be an example of a computing system according to that described in FIG. 10 and may be, for example, one of multiple servers in one or more cloud environments that host server application 185.

[0021] The server application 185 is a set of programs that provide access responses to access requests from the access device 105a via the access device 105b, and may be managed by a service provider. The server 115 receives access requests for encrypted files from the access device 105a via the access device 105b. The server application 185 authorizes the access request using several types of information, including user credentials (user identifier, email address, access token, etc.), access device location information, mobile device location information, user privilege information, file access permissions, etc.

[0022] The server application 185 generates an access response to the access request based on the authorization of the access request. The server application 185 generates an access package that is included in the access response returned to the access device 105a via the access device 105b. The access package includes source code from the repository 120 injected with information including keys from one or more of the key servers 190. The access package can be compiled by the access device 105 to form a respective access executable file 135 and a respective access function 140.

[0023] Key server 190 generates and maintains keys used to encrypt and decrypt files in system 100. Key server 190 communicates with server 115. Key server 190 may be hosted on different servers in different cloud zones and different cloud environments to prevent system 100 from having a single point of compromise and to improve security. Different key servers may store different types of keys. For example, one key server may manage payload keys, another may manage microdatabase keys, and another key server may manage file keys. System 100 may be used to configure different key servers and sets of key servers for different entities. For example, a first entity may use a first set of key servers for different types of keys, and a second entity may have a second set of key servers that may be different from the first set of key servers.

[0024] Repository 120 is a computing system that may include multiple computing devices according to those described in FIG. 10. Repository 120 may be hosted by a cloud service provider that hosts server application 185. The cloud service provider may provide hosting services, virtualization services, and data storage services, as well as other cloud services. The service provider that manages server application 185 may operate and control data, programs, and applications that store data in and retrieve data from repository 120. Data in repository 120 may include source code, filters, databases, and the like. As an example, repository 120 includes access source code 150, obfuscation filters 175, and macro database 180.

[0025] The access source code 150 is a source code used to generate the access executable file 135 after additional information (e.g., keys from one or more key servers 190) is injected. The access source code 150 includes an encryption source code 155, a decryption source code 160, a user rights source code 165, and a termination source code 170. The encryption source code 155 includes instructions for encrypting a payload to generate an encrypted file. The decryption source code 160 includes instructions for decrypting the encrypted file to recover the payload from the encrypted file. The user rights source code 165 includes instructions for processing the encrypted file based on user access rights (e.g., full access, shared access, and read-only access). The termination source code 170 includes instructions for deleting the encrypted file from the access device.

[0026] User access rights to a file may include various levels such as full access, collaborative access, and read-only access. With full access, a user may restore the original file which may be edited in an external application. For example, a spreadsheet may be restored and edited in a native spreadsheet application. With collaborative access, a user may view and update information in an encrypted file but may not restore the original file. For example, a user may be able to view and edit information from the payload of an encrypted file in an access client 125 but may not be able to save or print information from the payload of an encrypted file. With read-only access, a user may view information from an encrypted file but may not edit the information. For example, a user may view information using an access client 125 but may not be able to edit, print, or save information from the encrypted file being viewed. User access rights, which may also be referred to as an access policy, may be enforced by the access client 125 and / or the access executable 135. In some cases, user access rights may prevent a payload from being shared within a videoconferencing application.

[0027] The obfuscation filter 175 implements data loss prevention (DLP). The obfuscation filter 175 identifies the type and structure of data to obfuscate. As an example, the obfuscation filter can use regular expressions to identify social security numbers in a search string "\d{3}-\d\{2\}-\d\{4\}" and replace matches with a replacement string "XXX-XX-XXXX" to remove the social security numbers from the document. The obfuscation filter 175 can be applied before encrypting the payload so that the payload of the encrypted file does not contain personally identifiable information. Additionally, the obfuscation filter 175 can be applied after decryption of the encrypted file to prevent viewing or distributing personally identifiable information from the encrypted file. For example, the obfuscation filter 175 can be implemented as an access policy or user right.

[0028] The macro database 180 stores information about files that the system 100 controls. The macro database 180 may include a superset of information in the micro databases (e.g., also called data packs) stored in each encrypted file of the system 100. The macro database 180 stores information about each access of each encrypted file. For example, the macro database 180 for an encrypted file may include a table of information with columns for the date of access to the encrypted file, the type of access (create, read, write, update, etc.), information about the user (e.g., user identifier), and information about the access device (hardware identifier, software identifier, network connection identifier, machine address code (MAC) address identifier, etc.). The rows of the table may distinguish between different access events. The macro database 180 documents the chain of custody that identifies the users and machines that access the encrypted files of the system 100.

[0029] The macro database 180 may use a hash chain to store the access event information. For example, for each access event added to the macro database 180 for an encrypted file, the access event's information is combined with a previous hash value to form a hash payload. A cryptographic hash algorithm is applied to the hash payload to generate a new hash value that is stored with the access event information. The new hash value may be used as the "previous hash value" for subsequent access events to form an immutable chain of hash values. If the information in the hash chain is modified, the subsequent hash values ​​will be incorrect.

[0030] Each component of the system 100 works together to support dynamic, self-intelligent, and self-protecting data security. For example, a user can access the access client 125a to protect a file and allow various users to access the file. Using the access client 125a, the user selects a file to be protected. The file may be, for example, a video file, an audio file, a word processing file, a text file, a multimedia file, a PDF, etc. After selecting the file to protect, the user may be prompted by the access client 125a to select user access parameters that correspond to a file access policy. These user access parameters (or user access policies) may include users authorized to view the file, location or geo-fencing restrictions (e.g., office or other administratively authorized location), duration or unlock time restrictions, device restrictions, among other types of policies and restrictions. To select users, the access client 125a may access a local or remote list of contacts or users and prompt the user to search and / or select users and types of access (e.g., read-only, collaborative, full access) for each user to access the file.

[0031] After selecting the access policy, the user can select a user interface (UI) component to encrypt the file. As described in further detail herein, the access client 125a can receive an access package from the server 115 in response to a request for file encryption. The access package can include an access executable file 135a, and the access client 125a can execute instructions in the executable file 135a to encrypt the file using a key received from the server 115 in the access package. Encrypting the file results in a new encrypted file with a new file extension (e.g., different from the original file), and the new encrypted file is intelligent (rights management aware) based on the file access policy embedded in the encrypted file itself. In some implementations, the new encrypted file replaces the original file. In such cases, the original file is automatically deleted upon successful generation of the encrypted file. This feature may depend on the organization's specific policies or may be activated at the time of file encryption.

[0032] The encrypted file can be passed to various other users using various techniques such as email, FTP, database access, remote access, etc. For example, the access device 105b has local or remote access to the encrypted file, if the user wants to open the file, the access client 125a is configured to send a decryption request to the server 115. The request can include various information to be verified with the server 115. If the server 115 allows the request, the server 115 sends a response with an access package that includes the access executable file 135b. The access client 125b executes the instructions of the access executable file 135b to decrypt the file and its components (e.g., a data pack, which will be described in more detail herein). The access client 125b enforces the user access rights or access policies included in the data pack.

[0033] The data packs contained in the encrypted file include ownership information (e.g., user, device, organization), file access policies (e.g., type of user access rights), and access logs. This information travels with the encrypted file and can be updated via decryption requests. Because the file access policies are contained in the file, the contents of the file (e.g., payloads such as PDFs) can be accessed when the file access policies are executed.

[0034] Additionally, as described herein, the server 115 maintains file policies and access rights through the server application 185 and the repository 120. Generally (though there are some exceptions, as described herein), encrypted files cannot be decrypted by the access client 125 without communicating with the server. Thus, a user (e.g., an administrative user or a file owner) can use the access client 125 (e.g., a dashboard supported by the access client 125) to update file access policies associated with various files. Upon receiving a request to decrypt a file, the server 115 can determine that the access policy in the file is out of date (e.g., not current) and send the updated access policy in an access package to the access client 125. Thus, file access can be dynamically updated without having to first decrypt the file to include the updated access policy. Additionally, because server communication generally occurs with file access requests (e.g., decryption or encryption requests), the server 115 can maintain a log of such requests. The log can be used to support a dashboard that administrative users use to view access locations, access denials, users who requested access, and the like. Additionally, the dashboard can be used to change access policies in near real-time for different users, different files, etc. Thus, the techniques described herein can enable organizations to have a complete and near real-time view of their file security mechanisms and results.

[0035] Additionally or alternatively, those skilled in the art should understand that one or more aspects of the present disclosure may be implemented in the system 100 to solve other problems other than those described herein. Furthermore, aspects of the present disclosure may provide technical improvements to the "conventional" systems or processes described herein. However, the specification and accompanying drawings only include exemplary technical improvements resulting from implementing aspects of the present disclosure, and therefore do not represent all of the technical improvements provided within the scope of the claims.

[0036] 2 illustrates an example of an encrypted file 200 that supports encrypted file control according to aspects of the present disclosure. The encrypted file 200 uses multiple salts and keys (not stored in the encrypted file 200) to control access to and protect the payload 205 from unauthorized access. The encrypted file 200 includes a payload 205, a data pack 210, and metadata 215.

[0037] Payload 205 is the electronic file from which encrypted file 200 originates. Payload 205 may contain any type of electronic file including text documents, spreadsheets, slide presentations, source code files, image files, archive files, video files, etc. Encrypted file 200 may contain a single file within payload 205.

[0038] The payload 205 may be salted with a payload salt 220 and encrypted with a payload key 225 before being inserted into the encrypted file 200. In some implementations, the payload key 225 may be an Advanced Encryption Standard (AES) 256 key that is 256 bits long. In some implementations, the payload salt 220 is a randomly generated 8-byte value. In some implementations, the payload salt 220 is applied to the payload 205 by appending the payload salt 220 to the payload 205.

[0039] The data pack 210 (which may also be referred to as a micro database, an owner database, or a combination thereof) may include a subset of information in the macro database (e.g., the macro database 180 of FIG. 1) regarding recent accesses to the encrypted file 200, a file access policy associated with the encrypted file 200, and owner information associated with the encrypted file. The data pack 210 may include access log information (e.g., in the access log 250) that identifies the last user prior to accessing the encrypted file 200 and the prior access device prior to accessing the encrypted file 200. For example, the data pack may include an access log 250 that includes fingerprints associated with users and devices that previously accessed the encrypted file 200. The user fingerprint information may include email addresses, access tokens, hash values, and the like. The access device fingerprint information may include hardware and / or software identifiers. In some examples, the fingerprint information of the access log 250 may include network information, geographic location information, access client information, and the like. In some cases, the access log 250 includes hardware information that uniquely identifies the hardware component that runs the access client. As an example, the hardware information may be a user thumbprint, which is a universally unique identifier (UUID) from the user's computing system. As another example, the user thumbprint may be a motherboard serial number. The access information in the access log 250 may include an access timestamp. The access timestamp may identify the date and time when the encrypted file 200 was last successfully accessed.

[0040] Additionally, the data pack 210 may include a representation of the access rights (e.g., file access policy 245) of the encrypted file 200 and entity or ownership information (also referred to as an owner database) of the encrypted file 200. The file access policy 245 may indicate full access, collaborative access, read-only access, and may be specified on a global, per-group, per-user basis, etc. The file access policy may also include digital rights management information, which may be a subset of the file access policy that includes data identifying a user's privileges and access rights to the encrypted file 200. As an example, the digital rights management information may include values ​​for the following fields: PrintAllowed, SaveAllowed, LocalCopyAllowed, ForwardAllowed, Collaborate, Readonly, and FullAccess. The digital rights management information may be configured on a global, per-group, per-user basis, etc. The access rights may also include viewing constraints that limit or allow access to the file using various programs, such as limiting or allowing sharing of payloads in a videoconferencing program.

[0041] The values ​​of print permission, save permission, local copy permission, and forward permission may be binary. The value of the print permission field identifies whether information from the payload 205 of the encrypted file 200 may be printed by the user. The value of the save permission field identifies whether information from the payload 205 of the encrypted file 200 may be saved by the user on the access device. The value of the local copy permission field identifies whether a local copy of information from the payload 205 of the encrypted file 200 may be stored on the access device. The value of the forward permission field identifies whether information from the payload 205 of the encrypted file 200 may be forwarded to another device (e.g., as part of an email).

[0042] The values ​​of shared, read-only, and full access may be binary values ​​that may be set independently. The value of the shared field identifies whether a user may have shared access to the payload 205 of the encrypted file 200. The value of the read-only field identifies whether a user may have read-only access to the payload 205 of the encrypted file 200. The value of the full access field identifies whether a user may have full access to the payload 205 of the encrypted file 200.

[0043] The access policy 245 may also include data loss prevention information, which includes information and instructions that may identify and remove or obfuscate sensitive information from the payload 205 of the encrypted file 200. The data loss prevention information may be an example of a display constraint, as described herein. Sensitive information includes personally identifiable information. Sensitive information may be removed or obfuscated before the payload 205 is viewed or stored on an access device that functions as a decryption device. As an example, the data loss prevention information may include values ​​for the following fields PackagelD, Rule, RuleID:

[0044] The value of package lD identifies a package of source code to be included in the access package to remove or obfuscate sensitive information from payload 205. The value of the rule field identifies a group of rules to be included in the access package to remove or obfuscate sensitive information from payload 205. The value of rule lD identifies a specific rule to be included in the access package to remove or obfuscate sensitive information from payload 205. Each rule for data loss prevention includes a regular expression string with a replacement string and replaces data in payload 205 that matches the regular expression (from the regular expression stream) according to the replacement string.

[0045] The file access policy 245 may also include termination information. The termination information may include a termination flag that identifies whether the payload 205 of the encrypted file 200 is terminated. The payload 205 may have been terminated by replacing the original payload (after encryption) with null or random data of the same size as the original payload to prevent access to the data in the original payload. The termination flag may be set to true when an unauthorized user or device attempts to access the encrypted file 200.

[0046] The file access policy 245 may also enforce geographic location restrictions. For example, the file access policy may indicate that the file is only accessible at an office location, a geographic location (e.g., state or country), etc. Thus, when the policy is in force, the access client may use network information, GPS information, or other information that may be used to identify a geographic location to determine that access is authorized. If such information is not available, access to the payload 205 may be restricted. Thus, the file access policy 245 may include various forms, including bits indicating the type of access rights, an indication of rules or instructions that enforce data loss prevention, an indication of geographic restrictions, etc. In some cases, the file access policy 245 may restrict a user from accessing a file using a virtual private network (VPN). Thus, if a VPN is detected, the access request may be denied or the user may be restricted from viewing the file.

[0047] The ownership information 255 may include a value of a creator ID field that uniquely identifies the user who created the encrypted file 200. The creator ID value may be an email address, an employee identifier, a username, etc. The ownership information 255 may include an entity signature, such as a digital signature. A user of the system may be one of multiple employees of the entity. Each encrypted file generated by a user for the entity may include the same entity signature that identifies the entity as the source of the encrypted file, or multiple entity signatures that may identify the entity source of the encrypted file and the user who generated the encrypted file.

[0048] The ownership information 255 may also include entity database information including an indication of one or more application programming interface (API) endpoints (e.g., uniform resource locators (URLs)) that an access client uses to verify that a user has access to the encrypted file. For example, the indicated one or more API endpoints may be a verification API and a transfer API. The verification API may be accessed to verify that a user (having the same entity as the encrypted file 200) has access to the encrypted file 200. The transfer API may be accessed to verify that a user (having a different entity than the encrypted file 200) has access to the encrypted file 200. Because the API endpoints may be accessed prior to decryption of the encrypted file 200, the API endpoints may be located outside of any encryption wrapper (e.g., may not be encrypted by one of the keys). For example, an indication of the API endpoints may be included in the metadata 215.

[0049] The metadata 215 is a repository of information about the encrypted file 200. As an example, the metadata 215 may identify the type of file in the payload 205, the name of the file in the payload 205, the length of the file in the payload 205, the encryption algorithm (including the salting algorithm) of the payload 205, the encryption algorithm of the data pack 210, the encryption algorithm of the encrypted file 200, etc. As described herein, the metadata 215 may also include an indication of an API endpoint. Various aspects of the metadata 215 may or may not be encrypted as part of the encrypted file 200. In some cases, aspects of the metadata 215 may be included in a request for access to a server (encryption or decryption request).

[0050] The data packs 210 may be encrypted with one or more data pack keys 230 before being inserted into the encrypted file 200. In some implementations, the one or more data pack keys 230 may be Advanced Encryption Standard (AES) 128 keys. To reduce the time required to access the data in the data packs 210, the one or more data pack keys 230 may be shorter than the payload key 225.

[0051] The encrypted file 200 may be salted with a file salt 235 and encrypted with a file key 240. In some implementations, the file key 240 may be an Advanced Encryption Standard (AES) 256 key. In some implementations, the file salt 235 is a randomly generated 8-byte value. The file salt 235 may be applied to the contents of the encrypted file 200 (e.g., the payload 205 after being salted with the payload salt 220 and encrypted with the payload key 225, the data pack 210 after being encrypted with the data pack key 230) by appending the file salt 235 to the encrypted file 200.

[0052] In some implementations, a salt (e.g., file salt 235) is created by generating a first random 8-digit number between 10 million and 99999999 that is stored in Y. Then a second random number between 1 and 8 is generated and stored in X. The Xth digit of Y is then replaced with the value of X. The step of generating a second random number and replacing the value of Y is repeated four times. The final replaced value is the salt. Different algorithms can be used to generate the salt used by the system.

[0053] The various information contained in the data pack 210, in conjunction with the server communication, supports the dynamic, self-intelligent, and self-protecting data security scheme described herein. When the access client receives the access package (e.g., executable file and access key) from the server, the access client executes the executable code of the access package to decrypt the contents of the encrypted file using the various keys. The access client is configured to enforce the access policy 245 contained in the encrypted file. Furthermore, upon decryption, the executable code of the access package can cause the access log 250 to be updated with information about the access client (e.g., client identifier, version, fingerprint), information about the device executing the access client (e.g., device identifier, motherboard identifier, hardware identifier), user information, and other information described herein. In this manner, if the encrypted file 200 is passed to another user or device and the user attempts to open the encrypted file 200, the contents of the access log 250 can be used to identify the chain of custody of the encrypted file 200 and ascertain who and / or what device has compromised the encrypted file 200.

[0054] In some cases, the access policy 245 associated with a file may be updated before the file is decrypted. In such a case, when a decryption request is sent to a server (e.g., server 115), the server may respond with an updated access policy in the access package such that the updated access policy is implemented upon decryption. However, because the access policy is included with the file, various other features such as offline access are supported.

[0055] The aspects of FIG. 2 are described with respect to a payload 205 that is a file. It should be understood that the techniques described herein may be applicable to a portion of a file or an object within a file. For example, a file may include multiple elements (e.g., OLE elements), images, charts, etc. embedded within the file. In such a case, the payload 205 may be an example of a particular element within the file or a portion of the file (e.g., a particular page). Thus, the element or page (e.g., payload 205) may be encrypted and the access policy 245 may be enforced on the element or page. Similarly, the access log 250 and ownership information 255 may be based on the element or page within the file that is protected.

[0056] 3 illustrates an example of a computing architecture 300 supporting encrypted file control according to aspects of the disclosure. The computing architecture 300 includes a user device 305 and a server 310. The user device 305 may be an example of the access device 105 described with respect to FIG. 1. The server 310 may be an example of the server 115 described with reference to FIG. 1. The user device 305 may be configured to execute an access client 325 to support the file control techniques described herein.

[0057] A user of a user device 305 can access an access client 325 to encrypt and / or decrypt a file or a portion of a file according to the techniques described herein. In some cases, the user is required to log into the access client daily, periodically, etc. Logging into the access client 325 can trigger communication with the server 310, including establishing a secure connection. Additionally, a token may be generated upon login, which may be used for secure communication with the server 325. In some examples, a user may register a geographic location, a network identifier, etc. upon login, and such information is used for token generation, secure communication with the server, enforcement of file access policies (e.g., data geofencing), etc.

[0058] In an example use of the access client 325, a user may use the access client to protect a file or a portion of a file before it is sent to a set of users. The user may select a file via the access client 325 and then select a file access policy for the file. After the file and file access policy are selected, the access client 325 may send an access request 330 to the server 310. In the case of an encryption request, the server 310 may be identified based on a URL (e.g., an API endpoint) configured in the access client 325. The access request 330 may include the access information 315, as well as file information associated with the file (file size, type, file metadata). The access information 315 may be customized based on the access client 325. Depending on the implementation of the access client 325 (e.g., organizational configuration, individual configuration), the access information may include various information such as an Internet Protocol (IP) address, network information, motherboard identifier, universally unique (UU) identifier, user identifier, client identifier (e.g., client license identifier), client version, geographic location information, browser information (e.g., for a browser-based client), application information (e.g., for a client plug-in), etc. The access information 315 may also include an access token.

[0059] The access information may include information about the user, the user's computing system, the location of the computing system, and the type of access being requested. The information about the user may include a username, a user access token, the user's digital signature, the user's public key, etc. The information about the user's computing system may include hardware and software identifiers for the hardware and software components of the computing system. The information about the location of the computer system may include an IP address of the computer system, which may be mapped to a geographic location. The access information may be part of a header of the access request and may be formatted according to the Java Script Object Notation (JSON) standard.

[0060] The server 310 can validate the access information 315. Validation can include location validation, network validation, device validation, token validation (e.g., the token is active), and other information. In some cases, an organization may be associated with an organizational policy that indicates that certain information must be present in order to use the encryption function. For example, a global policy may indicate that a file can only be encrypted when an employee or user is present in the office. Thus, various validations are used to ensure that organizational policies are met. Validation can be customized for various considerations and scenarios.

[0061] The access information 315, access request 330, or another communication from the access client 325 may also include an indication of file access policies for the file to be encrypted. Thus, selected policies, including read, write, collaboration, geographic restriction policies, authorized users, and other policies, may be communicated to the server 310. The server 310 may maintain a record of the file information and access policies in a secure repository (e.g., in the macro database 180 of FIG. 1).

[0062] If the access request 330 is verified, the access information may be stored as described herein, and the server 310 may generate the access package 320. To generate the access package 320, the server 310 may call (e.g., send a request) the secure key store to generate an encryption key using a key service. The secure key store may be an example of a third-party key management service. The secure key store may return a random string that is used to generate the key. The server 310 may be configured to split the string into one or more access keys 335, and thus the secure key store may not be able to identify the access keys 335. In some examples, the request to the key store may include file identification information that may be used in a subsequent decryption request to receive the key string. Each encryption request may result in a different set of keys.

[0063] The server 310 may also generate access information 340 for the access package 320. The access information may include code (e.g., executable code) from various types of encryption or decryption libraries. Thus, the encryption / decryption schemes and keys may be customizable according to the desires of the organization implementing the techniques described herein. The access information 340 may include instructions for encrypting files including payloads and data packs. In some cases, the access package 320 may include instructions for file access policies and / or ownership information such that the policies and ownership information may be encrypted with the file. The access information 340 may be obtained from an instruction repository (e.g., repository 120 of FIG. 1). The instruction repository may be configured for each tenant or organization implementing the systems described herein, thus allowing for customizable or selectable encryption / decryption techniques, key formats, etc. to be used.

[0064] In some cases, as described herein, the access information 340 is compilable by the device 305 to generate machine-executable code used to perform an action (e.g., encrypt, decrypt, enforce a policy). In some cases, the access information 340 is used to convert the payload / file's data into another format, or to apply an operation to change a value in the data, or both. In some examples, the data conversion instructions may be indicated in the access package 320 or may be configured in the access client 325. Thus, if the access information 320 includes a value or data payload, the access information 320 (and the access package 320) may not include compilable or executable code.

[0065] The access package 320 is sent to the device 305 (e.g., access client 325) in an access response 345. The access client 325 is configured to use the access information 340 (e.g., using the access key 335) to generate an encrypted file. Using the access information can include executing code included in the access information 340, which together cause the instantiation and encryption of a data pack, the encryption of the payload (e.g., the file to be encrypted), and the encryption of the data pack and the file. Thus, depending on the configuration, there can be multiple layers of encryption in the encrypted file. The encrypted file can then be sent to various other users and devices using file transfer or communication techniques.

[0066] Similar techniques can be used if the access request 330 is a decryption request. Similar access information 315 can be communicated to the server 310. The server 310 can perform various validations. Decryption validation may differ from encryption validation. For example, the server 310 can determine whether the user and / or device requesting decryption is authorized to access the file based on information stored in association with the file identifier. In some cases, validation includes determining that the location of the requesting user device 305 meets a location policy (geographic location, network location).

[0067] If the access request 330 is verified, the server 310 can generate an access package 320. Generating the access package can include sending a request to a key storage service for an associated key string. For example, the request to the key storage service can include an indication of a file identifier for the file to be decrypted. The server 310 can receive the key string and generate an access key 335 and access information 340. In this case, the executable code can include decryption instructions for decrypting the entire file, data packs, and payload of the encrypted file.

[0068] In some cases, the access information 340 can cause the file and then the data pack to be encrypted. The file access policy of the data pack can then be enforced before the payload is decrypted. For example, if the policy is a geographic location policy and the policy is not met based on the information identified by the access client 325, execution of the access information 340 can be terminated until the policy is met. Thus, even though a portion of the file has been decrypted, the payload is not accessed.

[0069] To execute the access information 340, the access client 325 can instantiate an object associated with the code in memory and use the access key 335 to encrypt or decrypt a file. After the file is successfully encrypted or decrypted, the code is destroyed (e.g., deleted from memory). Thus, the object is retained in the memory of the device 305 during execution and is deleted after execution. Thus, the access client 325 is configured only to execute the code and is not configured (without the code) to encrypt or decrypt files.

[0070] In some examples, the server 310 determines that the access request 330 is invalid based on the access information 315. For example, the server 310 can determine that the request came from an unauthorized location, network, device, client, user, etc. In such a case, the server 310 can perform various actions. One action can include sending a warning to an administrative user (e.g., via email, alert, etc.). Another action can include generating an access package 320 with access information 340 configured to overwrite the contents of the payload. Additionally or alternatively, the access information 340 can trigger an exit flag in the file access policy. In this way, after the unauthorized request, the user cannot access the file and the contents of the file may be overwritten.

[0071] In some cases, the server 310 may determine that the access request 330 is valid, but the server 310 may also determine that the access policy 350 associated with the file is out of date or not up to date. To make such a determination, the server 310 may compare the information included in the access information 315 (e.g., file information, hash value, version) with the information the server 310 maintains (e.g., file information, hash value, version). If the policy is out of date or not up to date, the access package 320 may include an updated or current access policy 350 to be enforced by the access client 325.

[0072] As described herein, an access package may be an encryption package, a decryption package, a decoy package, or an exit package. An encryption package may include source code having functions to encrypt data, but not source code having functions to decrypt data. A decryption package may include source code having functions to decrypt data but not encrypt data. An exit package may include source code having functions to hide or delete encrypted files. A decoy package may include source code having functions to display data that resembles data from an encrypted file, but does not include data from the encrypted file. Exit and decoy packages may not include source code, keys, or salts used to encrypt or decrypt data.

[0073] The termination package can hide the data by displaying a message to the user indicating that the data from the encrypted file cannot be decrypted. The termination package can delete the data by overwriting the data in the encrypted file with random data in response to the computing system that sent the access request being located in a prohibited area of ​​the geofence and in response to the access being granted. The prohibited area of ​​the geofence can include a particular country.

[0074] In some cases, the access client 325 is configured to access a folder structure on the user device 305, a file storage web service, a remote server, etc. The access client 325 may also be configured to encrypt any files that are saved in a specified folder or location. Thus, when a file is saved in a folder, the access client 325 can trigger an access request 330 (encryption request) transmission to the server 310. Thus, using these techniques, a folder-level security scheme can be implemented.

[0075] 4 illustrates an example of a process flow 400 supporting encrypted file control in accordance with aspects of the present disclosure. Specifically, process flow 400 illustrates operations for encrypting a file in accordance with techniques described herein. Process flow 400 includes an access device 405 and a server 410, which may be examples of the corresponding devices described with respect to FIGS. 1-3.

[0076] At 415, a payload is selected. The payload may be selected by a user using a user interface of an access client executing on the access device 405a. At 420, the access client of the access device 405a may obtain access information. The access information may include information about the user and the access device 405a. As an example, this information may include a hardware component identifier from the access device 405a and an Internet Protocol address of the access device 405a.

[0077] At 425, the access device 405a sends an access request to the server 410. The request is an encryption request to encrypt the payload. The access request includes access information obtained using the access device 405a. The server can be identified based on a configuration in the access client. For example, the access request may be sent to the server via an API endpoint configured in the access client.

[0078] At 430, the server 410 may authorize or verify the request. Authorizing the request includes verifying the location of the access device 405a and verifying that the user is authorized to use the system and perform the requested action. The location may be verified by identifying the geographic location of the access device 405a from its IP address and comparing the geographic location to a set of geofences, which may identify a set of countries in which the system cannot be used. In this example, the user is verified from data in the access information. For example, a user access token may be provided indicating that the user is authorized to use the system and perform the requested action.

[0079] Identification of the computing system sending the request may be satisfied by receiving identifiers of hardware or software components, which may include a MAC address, International Mobile Equipment Identity (IMEI), serial and model numbers of computing system components (such as motherboard, processor, memory, graphics card, etc.), software version numbers of the operating system and basic input / output system (BIOS), etc. Identifiers of the computing system's hardware and software components may be verified by comparing the received identifiers with previously received identifiers of computing system components linked to the user making the access request.

[0080] The location of the computing system may be ascertained by mapping the IP address of the computing system to a geographic location. The mapped geographic location may be compared to a geofence that identifies allowed geographic locations for the type of access specified in the access request. In some implementations, the geofence may identify a particular country where access is not provided. The location of the computing system may also be identified based on wireless local area network (WLAN) or wireless wide area network (WWAN) positioning (e.g., cellular-based positioning).

[0081] The access privileges may depend on the type of access being requested. In the case of an encryption request, a system access privilege policy that may be applicable to each user of the system may be checked to verify that the user requesting encryption is authorized to do so based on the system access privilege policy. In the case of a decryption request, the system policy that applies to each user of the system, the group policy that applies to groups of users of the system, the user policy that applies to individual users, and the file policy that applies to individual files are checked to verify that a particular user can access a particular file with a particular level of privilege. The privilege levels may include full access, shared access, and read-only. Each of the different types of policies may specify a level of access to an individual file or group of files.

[0082] Authorizing the access request may include comparing access device location information from the access information to the access device location rules to determine access authorization. The access device location information may include an Internet Protocol (IP) address of the computing system that sent the access request and a geographic location to which the IP address is mapped. The device location rules may define a geofence to which access may be authorized. The geofence identifies a geographic location to which access may be authorized or restricted. As an example, if the geographic location of the computing system is compared to a geofence that defines an area of ​​a building's geographic location, and the computing system is determined to be within the geofence, the access may be indicated as authorized within the access authorization. If the comparison indicates that the computing system is not within the geofence, the access authorization may indicate that the access is not authorized. In another example of authoring an access request, the server may determine whether the access device is utilizing a VPN to determine that the obtained IP mapping does not mask the user's location. Thus, in some cases, a user and access request may be rejected when a VPN is used.

[0083] Granting the access request may also include comparing the mobile device location information from the access information to the mobile device location rules to determine access grant. The mobile device location information may include satellite positioning information. Additionally or alternatively, the mobile device location information may identify a type of connection between the mobile device and the access device. The mobile device may be connected to the access device via a wired or wireless connection.

[0084] If the mobile device location information includes satellite positioning information, the geographic location corresponding to the satellite positioning information can be compared to the geographic location corresponding to the IP address of the computing system. If the geographic location of the satellite positioning information and the IP address match, the access request can be granted. If not, the access request can be denied.

[0085] If the mobile device location information includes connection information (identifying the type of connection), the access request may be granted when a connection between the mobile device and the computing system is established and remains in existence. As an example, a serial bus cable may be used to connect the mobile device to the computing device to establish a wired connection. As another example, a wireless connection may be established directly or indirectly. A direct wireless connection includes a personal area wireless network connection. An indirect wireless may be through a wireless access point to which both the mobile device and the computing system are connected.

[0086] Multiple servers may be used to authorize aspects of the access request. When multiple servers are used, a server can send subsequent requests to subsequent servers to authorize a user identified from the access information. In some implementations, one server can grant access to an encrypted file, and another server can generate an access package based on the access authorization.

[0087] At 435, the server 410 may generate an access package. If authorized, the server 410 generates an encryption package in response to an encryption request from the access device 405a. The encryption package may be generated by retrieving source code for an encryption function, generating and storing salts and keys for a file to be encrypted by the access device 405a, and injecting the source code with information including the salt and key. The generation of the access package may additionally or alternatively include identification of a data payload or value used to transform data in the payload of the file.

[0088] The server can generate an access package by taking a source code file and injecting the source code file with information. The injected information can include salts and keys for encrypting or decrypting data. The salts and keys are stored separately and separated from the source code to reduce the impact of a compromise of the security of different parts of the system. For example, if an unauthorized user had the key to an encrypted file, the unauthorized user would not yet have the other keys, salts, or decryption algorithms required to access the encrypted file.

[0089] As an example, an access package for an encryption request (e.g., an encryption package) may be generated by taking an encryption source code, modifying the encryption source code with a set of salts and a key to form a modified encrypted source code, and generating an access package with the modified encrypted source code. Similarly, an access package for a decryption request (e.g., a decryption package) may be generated by taking a decryption source code, modifying the decryption source code with a set of salts and a key to form a modified decrypted source code, and generating an access package with the modified decrypted source code.

[0090] At 440, the access package (which is an encrypted package) is sent from the server 410 to the access device 405a. The access package (and any previous requests) are sent over a secure link between the server 410 and the access device 405a.

[0091] At 445, the access device 405a (via the access client) may compile an access package. The access device 405a may compile source code from the access package to generate an executable file, which may be a dynamic link library (DLL). The access package may be deleted from the access device 405a (e.g., from device memory) after the executable file is created. The access package may include source code written in multiple languages, and multiple compilers, assemblers, linkers, etc. may be used to generate the executable file from the access package. In some cases, at 445, the access device 405a may use a data payload or value in the access package to transform the data of the file or payload to be encrypted, rather than compiling the access package.

[0092] At 450, the access device 405a (via the access client) can generate a data pack. The data pack may be generated as part of the encryption process. The data pack may include a file access policy, ownership information, an access log, etc. As described, the data pack may include some information that is injected into the source code of the access package and then stored in the data pack. As an example, an entity signature (or a set of ownership information) may be injected into the source code and compiled into an executable file, which stores the entity signature in a data pack of the encrypted file. Similarly, a file access policy may be injected into the source code and compiled into an executable file, which stores the file access policy in a data pack of the encrypted file.

[0093] At 455, the access device 405a can encrypt the payload. The payload may be encrypted as part of the encryption process that generated the data pack. An encrypted file is generated from the encrypted payload and the data pack using multiple salts and encryption keys.

[0094] At 460, the access device 405a may delete the file, including the executable file, after creating the encrypted file.

[0095] At 465, the access device 405a may transmit the encrypted file to the access device 405b.

[0096] 5 illustrates an example of a process flow 500 supporting encrypted file control according to aspects of the present disclosure. Specifically, process flow 500 illustrates operations for decrypting a file according to techniques described herein. Process flow 500 includes an access device 505 and a server 510, which may be examples of the corresponding devices described with respect to FIGS. 1-4. For example, process flow 500 may be a continuation of process flow 400.

[0097] At 515, an encrypted file is selected at the access device 505b. The encrypted file may be selected on the access device 505b by a user of the access device 505b. The encrypted file may be a file that was sent to the access device as described in FIG.

[0098] At 520, the access device sends an access request to the server 510 (e.g., via an application client). The request, also referred to as a decryption request, may include access information identifying the encrypted file, the user of the access device 505b, and the access device 505b. The request may include an identifier of the encrypted file linked to the data pack and access rights information stored in a macro database of the server. The identifier of the encrypted file may be used by the server to find information about the encrypted file (including user access rights) in a macro database maintained by the server. In some cases, information about the file may be identified from metadata associated with the file. The server may be identified via an API endpoint associated with the file (e.g., in the metadata) or via configuration in the access client (e.g., the access client is pre-configured with the API endpoint).

[0099] At 525, the server 510 can authorize or validate the access request. The server can authorize the access request based on information included in the request and information maintained by the server in association with the file, such as an access policy (e.g., user identifiers authorized to access the file).

[0100] At 530, the server 510 can generate an access package based on the authorization or validation of the access request. The access package can be a decryption package if the access request is authorized, or a termination or decoy package if the request is not authorized.

[0101] At 535, the server 510 may transmit the access package to the access device 505b. The access package (and the previous request) may be transmitted over a secure link between the server 510 and the access device 505b.

[0102] At 540, the access device 505b may compile the access package. The access device 505b may compile source code from the access package (e.g., via an access client) to generate an executable file, which may be a DLL. The access package may be deleted from the access device 505b after the executable file is created. In some cases, at 540, the access device 405a may use a data payload or value in the access package to transform the data of the file or payload to be decrypted, rather than compiling the access package.

[0103] At 545, the access device 505b may update the data pack of the file. The data pack may be updated by the access device 505b as part of the decryption process by modifying the access log (e.g., adding device and user information related to the access device 505b). In some cases, updating the data pack may include updating the file access log based on information included in the access package. Thus, the data pack may be decrypted and updated with access information that identifies the access date and time and a hardware identifier of the computing system that performed the access. After the data pack is updated, an encryption process may be performed to regenerate the encrypted file with the updated data pack.

[0104] At 550, the access device 505b can decrypt the payload of the encrypted file. The payload can be decrypted using an executable file as part of the decryption process that updated the data pack. The encrypted file is decrypted to recover the original payload using multiple salts and encryption keys according to the executable code of the access package.

[0105] At 565, the access device 505b accesses the payload. The payload can be accessed to present information from the payload according to the file access policy (e.g., user rights and privileges) of the encrypted file contained in the data pack. The file access policy can restrict editing, saving, printing, and viewing of information from the encrypted file.

[0106] At 560, the access device 505b may delete the file, such as the executable file, from the memory of the access device 505b.

[0107] In some examples, the access request at 520 is sent to a server associated with the access client executing on the access device 505b. In such cases, the server associated with the access client may indicate that it cannot validate the request (e.g., cannot access the file information). In such cases, the server may return a response indicating the URL of the correct server (e.g., server 510). In other cases, the server may communicate with the correct server 510 to relay the access package to the access device 505b.

[0108] 6 illustrates an example of an access device scenario 600 supporting encrypted file control in accordance with aspects of the present disclosure. The access device scenario 600 includes an access device 605, which may be an example of an access device described in connection with FIGS. 1-5. The access device 605 includes a display 610. The display 610 presents a user interface 615. The user interface may be an example user interface associated with an access client executing on the access device 605.

[0109] In the example of Figure 6, an access client is accessing a file (e.g., the file is decrypted according to the techniques described herein). The data pack associated with the file includes a file access policy that is a mobile device proximity access policy that indicates that the user's mobile device has a connection with the access device 605 to view the payload. Thus, the access client is implementing the mobile device proximity access policy of Figure 6.

[0110] At 625, the user interface 615 displays information (e.g., payload) from the encrypted file when a data connection with the mobile device 620 exists. When the connection to the mobile device 620 is lost, the information is no longer displayed by the access device 605. As an example, the access device 605 may be a desktop computer and the mobile device 620 may be a smartphone. The access device 605 and the mobile device 620 are close enough to be connected using one of several device connection standards (Universal Serial Bus (USB), Wi-Fi, Bluetooth, etc.). The mobile device is then moved far enough away from the access device 605 that the connection can no longer be maintained. After the connection is disconnected, the presented information may disappear from the display because the access client is enforcing the mobile device proximity file access policy. Additionally, the encrypted file may be closed and the executable file used to decrypt the encrypted file may be deleted from the access device 605. In some cases, the connection is checked periodically (e.g., every second) to enforce the policy included in the associated data package. Thus, the technique of FIG. 6 may include additional security mechanisms.

[0111] FIG. 7 illustrates a block diagram 700 of a user device 720 supporting encrypted file control according to aspects of the disclosure. The user device 720 may be an example of an aspect of an access device (e.g., a user device) described with reference to FIGS. 1-6. The user device 720 or various components thereof may be an example of a means for performing various aspects of encrypted file control described herein. For example, the user device 720 may include an access request interface 725, an access package interface 730, an execution component 735, an access package deletion component 740, an encryption component 745, a decryption component 750, a policy component 755, a verification information component 760, a file metadata component 765, an access log component 770, or any combination thereof. Each of these components may communicate directly or indirectly with each other (e.g., via one or more buses).

[0112] The user device 720 can support data security at the access client in accordance with examples disclosed herein. The access request interface 725 can be configured as or otherwise support a means for sending an access request to the server, including access information and file information for the file to be accessed. The access package interface 730 can be configured as or otherwise support a means for receiving an access package from the server, including executable code and one or more access keys, based at least in part on the sending of the access request. The execution component 735 can be configured as or otherwise support a means for executing, by the access client, the executable code to access the file using the one or more access keys. The access package deletion component 740 can be configured as or otherwise support a means for deleting an access package from a memory associated with the access client.

[0113] In some examples, to support the transmission of an access request, the encryption component 745 may be configured or otherwise support a means for transmitting the encryption request and file information to a server.

[0114] In some examples, to support receiving an access package, the access package interface 730 may be configured or otherwise support receiving an access package including a data pack including an indication of one or more file access policies associated with the file, the data pack being encrypted with the file using one or more access keys. In some examples, the one or more file access policies include read access, write access, viewing restrictions, or a combination thereof.

[0115] In some examples, to support receiving an access package, the access package interface 730 may be configured or otherwise support as a means for receiving an access package that includes a data pack that includes an indication of ownership information associated with a file, the data pack encrypted with the file using one or more access keys.

[0116] In some examples, to support sending encryption requests, the policy component 755 may be configured with or otherwise support a means for sending to the server an indication of one or more file access policies associated with the file.

[0117] In some examples, to support execution of executable code, encryption component 745 may be configured with or otherwise support as a means for encrypting, with the executable code, a payload and one or more data packs using one or more access keys to generate an encrypted file.

[0118] In some examples, to support encryption of one or more data packs, the encryption component 745 may be configured with or otherwise support a means for encrypting one or more data packs that include indications of one or more file access policies, file ownership information, file access audit logs, or combinations thereof.

[0119] In some examples, to support sending an access request, the decryption component 750 may be configured or otherwise support a means for transmitting a decryption request and file information to a server, and the executable code includes code used to decrypt the file.

[0120] In some examples, to support receiving an access package, the access package interface 730 may be configured or otherwise support as a means for receiving an access package that includes a data pack that includes one or more updated file access policies.

[0121] In some examples, the verification information component 760 may be configured with or otherwise support a means of identifying verification information at the access client, including access client information, computer information, device information, geographic location information, an authentication token, or a combination thereof, and the decryption request includes an indication of the verification information.

[0122] In some examples, the file metadata component 765 may be configured with or otherwise support a means of identifying that a file is associated with an access client based at least in part on metadata associated with the file, the file including a payload encrypted using a first one of the one or more access keys and one or more encrypted data packs encrypted using at least a second one of the one or more access keys, and a decryption request is sent to a server based at least in part on the file being associated with the access client.

[0123] In some examples, to support the execution of executable code, the decryption component 750 may be configured with or otherwise support a means for decrypting files using one or more access keys.

[0124] In some examples, the decryption component 750 may be configured as or otherwise support a means for displaying the payload of a file at an access client in accordance with one or more access policies associated with the file.

[0125] In some examples, the one or more access policies include read access, write access, viewing restrictions, or a combination thereof. In some examples, the one or more access policies are included in a data pack decrypted with the file using the one or more access keys.

[0126] In some examples, the access log component 770 can be configured with or support a means for updating the file access audit log to include device information, user information, geographic location information, or a combination thereof, associated with the accessing client.

[0127] In some examples, the decryption component 750 may be configured with or otherwise support a means of identifying, based at least in part on the decryption of the file, a payload and one or more data packs within the file, the one or more data packs including an indication of one or more file access policies, ownership information, a file access audit log, or a combination thereof.

[0128] In some examples, the execution component 735 may be configured as or otherwise support a means for instantiating, based at least in part on executing executable code, an access object used to decrypt or encrypt a file in memory associated with the access client, where the access object is deleted from the memory associated with the access client after decrypting or encrypting the file.

[0129] In some examples, the decryption component 750 may be configured or otherwise support a means for sending a decryption request and file information to a server, and the executable code includes code used to overwrite the contents of the file.

[0130] In some examples, to support transmitting an access request, the access request interface 725 may be configured as or otherwise support a means for transmitting an access request including access information including a geographic location of a user device executing the access client, device information associated with the user device, network information associated with the user device, an authentication token associated with the access client, or a combination thereof.

[0131] FIG. 8 illustrates a diagram of a system 800 including a device 805 supporting encrypted file control according to an aspect of the disclosure. The device 805 can include components for two-way voice and data communication, including components for sending and receiving communications, such as a data security manager 820, a communication module 810, an antenna 815, a user interface component 825, a database (application data) 830, a memory 835, and a processor 840. These components can be in electronic communication or coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 845). The device 805 can be an example of a user device that executes an access client, as described herein. In some cases, the access client can correspond to the data security manager 820.

[0132] The communication module 810 can manage input and output signals of the device 805 via the antenna 815. The communication module 810 can include an example of the communication module 810 of the user device 106 shown and described in FIG. 2. In this regard, the communication module 810 can manage communications with the server 110 as shown in FIG. 2. The communication module 810 can also manage peripherals that are not integrated into the device 805. In some cases, the communication module 810 can represent a physical connection or port to an external peripheral. In some cases, the communication module 810 can utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another known operating system. In other cases, the communication module 810 can represent or interact with a modem, keyboard, mouse, touch screen, or similar device. In some cases, the communication module 810 can be implemented as part of the processor 840. In some examples, a user can interact with the device 805 via the communications module 810 , a user interface component 825 , or via a hardware component controlled by the communications module 810 .

[0133] In some cases, the device 805 may include a single antenna 815. However, in some other cases, the device 805 may have multiple antennas 815 that may be capable of simultaneously transmitting or receiving multiple wireless transmissions. The communications module 810 may communicate bidirectionally via one or more antennas 815, over a wired or wireless link, as described herein. For example, the communications module 810 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. The communications module 810 may also include a modem for modulating packets and providing the modulated packets to the one or more antennas 815 for transmission and demodulating packets received from the one or more antennas 815.

[0134] The user interface component 825 can manage data storage and processing in the database 830. In some cases, a user can interact with the user interface component 825. In other cases, the user interface component 825 can operate automatically without user interaction. The database 830 can be an example of a single database, a distributed database, multiple distributed databases, a data store, a data lake, or an emergency backup database.

[0135] The memory 835 can include random access memory (RAM) and read only memory (ROM). The memory 835 can store computer readable computer executable software including instructions that, when executed, cause the processor 840 to perform various functions described herein. In some cases, the memory 835 can include a BIOS that can control basic hardware or software operations such as interaction with peripheral components or devices, among other things.

[0136] The processor 840 may include intelligent hardware devices (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, the processor 840 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into the processor 840. The processor 840 may be configured to execute computer-readable instructions stored in the memory 835 to perform various functions (e.g., functions or tasks supporting the methods and systems for sleep staging algorithms).

[0137] The data security manager 820 can support data security at the access client in accordance with examples disclosed herein. For example, the data security manager 820 can be configured as or otherwise support a means for sending an access request to a server, the access request including access information and file information for a file to be accessed. The data security manager 820 can be configured as or otherwise support a means for receiving an access package including executable code and one or more access keys from a server based at least in part on the sending of the access request. The data security manager 820 can be configured as or otherwise support a means for executing, by the access client, the executable code to access a file using the one or more access keys. The data security manager 820 can be configured as or otherwise support a means for deleting an access package from a memory associated with the access client.

[0138] Data security manager 820 may include applications (e.g., “apps”), programs, software, or other components configured to facilitate the data security techniques described herein via communication with servers, other user devices, etc.

[0139] FIG. 9 illustrates a block diagram 900 of a server 920 supporting encrypted file control according to an aspect of the present disclosure. The server 920 may be an example of an aspect of the server described with reference to FIGS. 1-6. The server 920, or various components thereof, may be an example of a means for performing various aspects of encrypted file control described herein. For example, the server 920 may include an access request interface 925, a request validation component 930, an access package component 935, an access package interface 940, an encryption component 945, a decryption component 950, a key identification component 955, a file policy component 960, an action component 965, a notification component 970, or any combination thereof. Each of these components may communicate directly or indirectly with each other (e.g., via one or more buses).

[0140] The server 920 can support data security at the server according to examples disclosed herein. The access request interface 925 can be configured as or otherwise support a means for receiving an access request from an access client, the access request including access information and file information of the file to be accessed. The request validation component 930 can be configured as or otherwise support a means for validating the access request using the access information. The access package component 935 can be configured as or otherwise support a means for generating an access package including executable code and one or more access keys based at least in part on the validation of the access request. The access package interface 940 can be configured as or otherwise support a means for sending an access package to the access client, the access package being compiled by the access client into an executable file used to access the file.

[0141] In some examples, to support receiving an access request, the encryption component 945 may be configured or otherwise support receiving an encryption request from an access client to encrypt a file, and the access package includes executable code for encrypting the file using one or more access keys.

[0142] In some examples, to support sending an access package, the access package interface 940 may be configured as or otherwise support a means for sending an access package to an access client that includes a data pack that includes an indication of one or more file access policies associated with the file, and the executable code is configured to encrypt the data pack with the file using one or more access keys. In some examples, the one or more file access policies include read access, write access, viewing restrictions, or a combination thereof.

[0143] In some examples, to support transmission of an access package, the access package component 935 may be configured as or otherwise support a means for transmitting to an access client an access package that includes a data pack that includes executable code configured to generate an audit log associated with a file and encrypt the audit log with the file using one or more access keys.

[0144] In some examples, to support transmission of an access package, the access package component 935 may be configured as or otherwise support a means for transmitting an access package to an access client that includes a data pack that includes an indication of ownership information associated with the file, and the executable code is configured to encrypt the data pack with the file using one or more access keys.

[0145] In some examples, to support receiving an access request, the file policy component 960 can be configured or otherwise supported as a means for receiving from an access client an indication of one or more file access policies associated with a file. In some examples, to support receiving an access request, the file policy component 960 can be configured or otherwise supported as a means for storing one or more file access policies in association with a file identifier for a file.

[0146] In some examples, to support receiving an access request, the file policy component 960 can be configured or otherwise supported as a means for receiving, from an access client, an indication of one or more users who are authorized to access the file. In some examples, to support receiving an access request, the file policy component 960 can be configured or otherwise supported as a means for storing, in association with a file identifier for the file, an indication of one or more users who are authorized to access the file.

[0147] In some examples, to support receiving an access request, the decryption component 950 may be configured or otherwise support receiving a decryption request from an access client to decrypt a file, where the access package includes executable code for decrypting the file using one or more access keys.

[0148] In some examples, the file policy component 960 can be configured or otherwise supported as a means for determining that a data pack including one or more file access policies for a file is out of date. In some examples, the file policy component 960 can be configured or otherwise supported as a means for sending an updated data pack including one or more updated file access policies for a file based at least in part on a determination that the data pack is out of date.

[0149] In some examples, the request validation component 930 can be configured or otherwise supported as a means for comparing user information included in the access information received in the decryption request to an access record associated with the file at the server. In some examples, the request validation component 930 can be configured or otherwise supported as a means for determining, based at least in part on the results of the comparison, that a user associated with the access client is authorized to access the file, and an access package is transmitted to the access client based at least in part on determining that the user is authorized to access the file.

[0150] In some examples, the request validation component 930 can be configured with or otherwise support a means for determining that the access client is not authorized to decrypt the file based at least in part on the access information received in the decryption request. In some examples, the action component 965 can be configured with or otherwise support a means for triggering an action at the server based at least in part on determining that the access client is not authorized to decrypt the file.

[0151] In some examples, to support triggering of an action, the notification component 970 may be configured with or otherwise support a means for generating a warning or message indicating that the access client has sent an unauthorized access request.

[0152] In some examples, to support triggering of an action, the access package component 935 may be configured or otherwise support as a means to send an access package that includes executable code that overwrites the contents of a file.

[0153] In some examples, the key identification component 955 may be configured or otherwise support a means for sending a request to a key storage service for a key string and a file identifier associated with a file based at least in part on receiving an access request. In some examples, the key identification component 955 may be configured or otherwise support a means for receiving a key string associated with a file identifier from a key storage service. In some examples, the key identification component 955 may be configured or otherwise support a means for generating one or more access keys using the key string.

[0154] In some examples, to support validation of an access request, the request validation component 930 can be configured or otherwise support a means for validating access information including, for any combination thereof, a geographic location of a user device executing the access client, device information associated with the user device, network information associated with the user device, and an authentication token associated with the access client.

[0155] 10 illustrates a diagram of a system 1000 including a device 1005 supporting encrypted file control according to an aspect of the disclosure. The device 1005 can include components for two-way voice and data communication, including components for sending and receiving communications, such as a data security component 1020, an I / O controller 1010, a database controller 1015, a memory 1025, a processor 1030, and a database 1035. These components can be in electronic communication or coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 1040).

[0156] The I / O controller 1010 can manage the input signals 1045 and output signals 1050 of the device 1005. The I / O controller 1010 can also manage peripherals that are not integrated into the device 1005. In some cases, the I / O controller 1010 can represent a physical connection or port to an external peripheral. In some cases, the I / O controller 1010 can utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or another known operating system. In other cases, the I / O controller 1010 can represent or interact with a modem, keyboard, mouse, touch screen, or similar device. In some cases, the I / O controller 1010 may be implemented as part of the processor 1030. In some examples, a user can interact with the device 1005 through the I / O controller 1010 or through hardware components controlled by the I / O controller 1010.

[0157] The database controller 1015 can manage data storage and processing in the database 1035. In some cases, a user can interact with the database controller 1015. In other cases, the database controller 1015 can operate automatically without user interaction. The database 1035 can be an example of a single database, a distributed database, multiple distributed databases, a data store, a data lake, or an emergency backup database.

[0158] The memory 1025 can include RAM and ROM. The memory 1025 can store computer-readable computer-executable software that includes instructions that, when executed, cause the processor 1030 to perform various functions described herein. In some cases, the memory 1025 can include a BIOS that can control basic hardware or software operations, such as interaction with peripheral components or devices, among other things.

[0159] The processor 1030 may include intelligent hardware devices (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, the processor 1030 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into the processor 1030. The processor 1030 may be configured to execute computer-readable instructions stored in the memory 1025 to perform various functions (e.g., functions or tasks supporting encryption file control).

[0160] The data security component 1020 can support data security at the server according to examples disclosed herein. For example, the data security component 1020 can be configured as or otherwise support a means for receiving an access request from an access client, the access request including access information and file information for a file to be accessed. The data security component 1020 can be configured as or otherwise support a means for validating the access request using the access information. The data security component 1020 can be configured as or otherwise support a means for generating an access package including executable code and one or more access keys based at least in part on the validation of the access request. The data security component 1020 can be configured as or otherwise support a means for sending an access package to the access client, the access package being compiled by the access client into an executable file used to access the file.

[0161] FIG. 11 shows a flow chart illustrating a method 1100 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1100 may be performed by a user device or components thereof as described herein. For example, the operations of method 1100 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0162] At 1105, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1105 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1105 may be performed by an access request interface 725, as described with reference to FIG.

[0163] At 1110, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including executable code and one or more access keys. The operations of 1110 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1110 may be performed by the access package interface 730, as described with reference to FIG. 7. In some examples, the access package includes one or more access keys and / or access information, such as data or values, rather than executable code.

[0164] At 1115, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operation of 1115 may be performed according to examples disclosed herein. In some examples, aspects of the operation of 1115 may be performed by the execution component 735, as described with reference to FIG. 7. In examples where the access package includes one or more access keys and / or access information, the access device may use the access information to access the data of the payload by transforming the data, which may correspond to encryption or decryption of the data. In some cases, this process may include executing instructions accessible by the access client. These instructions may or may not be included in the access package.

[0165] At 1120, the method may include deleting the access package from a memory associated with the access client. The operations of 1120 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1120 may be performed by an access package deletion component 740, as described with reference to FIG.

[0166] FIG. 12 shows a flow chart illustrating a method 1200 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1200 may be performed by a user device or components thereof as described herein. For example, the operations of method 1200 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0167] At 1205, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1205 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1205 may be performed by an access request interface 725, as described with reference to FIG.

[0168] At 1210, the method may include sending an encryption request and file information to a server. The operations of 1210 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1210 may be performed by encryption component 745, as described with reference to FIG.

[0169] At 1215, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including the executable code and one or more access keys. The operations of 1215 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1215 may be performed by an access package interface 730, as described with reference to FIG.

[0170] At 1220, the method may include receiving an access package including a data pack including an indication of ownership information associated with the file, the data pack encrypted with the file using one or more access keys. The operations of 1220 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1220 may be performed by an access package interface 730, as described with reference to FIG.

[0171] At 1225, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1225 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1225 may be performed by an execution component 735, as described with reference to FIG.

[0172] At 1230, the method may include deleting the access package from a memory associated with the access client. The operations of 1230 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1230 may be performed by an access package deletion component 740, as described with reference to FIG.

[0173] FIG. 13 shows a flow chart illustrating a method 1300 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1300 may be performed by a user device or components thereof as described herein. For example, the operations of method 1300 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0174] At 1305, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1305 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1305 may be performed by an access request interface 725, as described with reference to FIG.

[0175] At 1310, the method may include sending an encryption request and file information to a server. The operations of 1310 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1310 may be performed by encryption component 745, as described with reference to FIG.

[0176] At 1315, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including the executable code and one or more access keys. The operations of 1315 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1315 may be performed by an access package interface 730, as described with reference to FIG.

[0177] At 1320, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1320 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1320 may be performed by an execution component 735, as described with reference to FIG.

[0178] At 1325, the method may include using the executable code to encrypt the payload and the one or more data packs using the one or more access keys to generate an encrypted file. The operations of 1325 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1325 may be performed by encryption component 745, as described with reference to FIG.

[0179] At 1330, the method may include encrypting one or more data packs that include an indication of one or more file access policies, file ownership information, a file access audit log, or a combination thereof. The operations of 1330 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1330 may be performed by encryption component 745, as described with reference to FIG.

[0180] At 1335, the method may include deleting the access package from a memory associated with the access client. The operations of 1335 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1335 may be performed by an access package deletion component 740, as described with reference to FIG.

[0181] FIG. 14 shows a flow chart illustrating a method 1400 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1400 may be performed by a user device or components thereof as described herein. For example, the operations of method 1400 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0182] At 1405, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1405 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1405 may be performed by an access request interface 725, as described with reference to FIG.

[0183] At 1410, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including executable code and one or more access keys. The operations of 1410 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1410 may be performed by an access package interface 730, as described with reference to FIG.

[0184] At 1415, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1415 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1415 may be performed by an execution component 735, as described with reference to FIG.

[0185] At 1420, the method may include deleting the access package from a memory associated with the access client. The operations of 1420 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1420 may be performed by an access package deletion component 740, as described with reference to FIG.

[0186] At 1425, the method may include sending a decryption request and file information to a server, where the executable code includes code used to decrypt the file. The operations of 1425 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1425 may be performed by a decryption component 750, as described with reference to FIG.

[0187] FIG. 15 shows a flow chart illustrating a method 1500 for supporting encrypted file control according to aspects of the disclosure. The operations of method 1500 may be performed by a user device or components thereof as described herein. For example, the operations of method 1500 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0188] At 1505, the method may include identifying, at the access client, verification information including access client information, computer information, device information, geographic location information, an authentication token, or a combination thereof, and the decryption request includes an indication of the verification information. The operations of 1505 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1505 may be performed by verification information component 760, as described with reference to FIG. 7.

[0189] At 1510, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1510 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1510 may be performed by an access request interface 725, as described with reference to FIG.

[0190] At 1515, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including the executable code and one or more access keys. The operations of 1515 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1515 may be performed by an access package interface 730, as described with reference to FIG.

[0191] At 1520, the method may include receiving an access package including a data pack including one or more updated file access policies. The operations of 1520 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1520 may be performed by an access package interface 730, as described with reference to FIG.

[0192] At 1525, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1525 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1525 may be performed by an execution component 735, as described with reference to FIG.

[0193] At 1530, the method may include deleting the access package from a memory associated with the access client. The operations of 1530 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1530 may be performed by an access package deletion component 740, as described with reference to FIG.

[0194] At 1535, the method may include sending a decryption request and file information to a server, where the executable code includes code used to decrypt the file. The operations of 1535 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1535 may be performed by a decryption component 750, as described with reference to FIG.

[0195] FIG. 16 shows a flow chart illustrating a method 1600 for supporting encrypted file control according to aspects of the disclosure. The operations of method 1600 may be performed by a user device or components thereof as described herein. For example, the operations of method 1600 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0196] At 1605, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1605 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1605 may be performed by an access request interface 725, as described with reference to FIG.

[0197] At 1610, the method may include receiving, from the server based at least in part on the transmission of the access request, an access package including executable code and one or more access keys. The operations of 1610 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1610 may be performed by an access package interface 730, as described with reference to FIG.

[0198] At 1615, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1615 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1615 may be performed by an execution component 735, as described with reference to FIG.

[0199] At 1620, the method may include decrypting the file using the one or more access keys. The operations of 1620 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1620 may be performed by a decryption component 750, as described with reference to FIG.

[0200] At 1625, the method may include displaying the payload of the file at the access client in accordance with one or more access policies associated with the file. The operations of 1625 may be performed in accordance with examples disclosed herein. In some examples, aspects of the operations of 1625 may be performed by a decryption component 750, as described with reference to FIG.

[0201] At 1630, the method may include deleting the access package from a memory associated with the access client. The operations of 1630 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1630 may be performed by an access package deletion component 740, as described with reference to FIG.

[0202] At 1635, the method may include sending a decryption request and file information to a server, where the executable code includes code used to decrypt the file. The operations of 1635 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1635 may be performed by a decryption component 750, as described with reference to FIG.

[0203] FIG. 17 shows a flow chart illustrating a method 1700 for supporting encrypted file control according to aspects of the disclosure. The operations of method 1700 may be performed by a user device or components thereof as described herein. For example, the operations of method 1700 may be performed by a user device as described with reference to FIGS. 1-8. In some examples, the user device may execute a set of instructions to control functional elements of the user device to perform the described functions. Additionally or alternatively, the user device may perform aspects of the described functions using dedicated hardware.

[0204] At 1705, the method may include sending an access request to a server, the access request including access information and file information for the file to be accessed. The operations of 1705 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1705 may be performed by an access request interface 725, as described with reference to FIG.

[0205] At 1710, the method may include receiving, from a server based at least in part on the transmission of the access request, an access package including executable code and one or more access keys. The operations of 1710 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1710 may be performed by an access package interface 730, as described with reference to FIG.

[0206] At 1715, the method may include executing, by the access client, executable code to access the file using the one or more access keys. The operations of 1715 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1715 may be performed by an execution component 735, as described with reference to FIG.

[0207] At 1720, the method may include decrypting the file using the one or more access keys. The operations of 1720 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1720 may be performed by a decryption component 750, as described with reference to FIG.

[0208] At 1725, the method may include updating the file access audit log to include device information, user information, geographic location information, or a combination thereof, associated with the access client. The operations of 1725 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1725 may be performed by an access log component 770, as described with reference to FIG.

[0209] At 1730, the method may include deleting the access package from a memory associated with the access client. The operations of 1730 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1730 may be performed by an access package deletion component 740, as described with reference to FIG.

[0210] At 1735, the method may include sending a decryption request and file information to a server, where the executable code includes code used to decrypt the file. The operations of 1735 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1735 may be performed by a decryption component 750, as described with reference to FIG.

[0211] FIG. 18 shows a flow chart illustrating a method 1800 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1800 may be performed by a server or components thereof as described herein. For example, the operations of method 1800 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0212] At 1805, the method may include receiving an access request from an access client, the access request including access information and file information for the file to be accessed. The operations of 1805 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1805 may be performed by an access request interface 925, as described with reference to FIG.

[0213] At 1810, the method may include validating the access request using the access information. The operations of 1810 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1810 may be performed by a request validation component 930, as described with reference to FIG.

[0214] At 1815, the method may include generating an access package including executable code and one or more access keys based at least in part on the validation of the access request. The operations of 1815 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1815 may be performed by an access package component 935 as described with reference to FIG. 9. In some examples, generating the access package may include identifying one or more access keys and / or access information, such as data or values, rather than executable code.

[0215] At 1820, the method may include transmitting an access package to an access client, the access package being compilable by the access client into an executable file used to access the file. The operations of 1820 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1820 may be performed by an access package interface 940, as described with reference to FIG. 9. If the access package includes access information, the access client may use the access information to access the data of the payload by transforming the data, which may correspond to encrypting or decrypting the data. In some cases, this process may include executing instructions accessible by the access client. These instructions may or may not be included in the access package.

[0216] FIG. 19 shows a flow chart illustrating a method 1900 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 1900 may be performed by a server or components thereof as described herein. For example, the operations of method 1900 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0217] At 1905, the method may include receiving an access request from an access client, the access request including access information and file information for the file to be accessed. The operations of 1905 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1905 may be performed by an access request interface 925, as described with reference to FIG.

[0218] At 1910, the method may include receiving an encryption request from an access client to encrypt a file, the access package including executable code for encrypting the file using one or more access keys. The operations of 1910 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1910 may be performed by encryption component 945, as described with reference to FIG. 9.

[0219] At 1915, the method may include validating the access request using the access information. The operations of 1915 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1915 may be performed by a request validation component 930, as described with reference to FIG.

[0220] At 1920, the method may include generating an access package including the executable code and one or more access keys based at least in part on the validation of the access request. The operations of 1920 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1920 may be performed by an access package component 935, as described with reference to FIG.

[0221] At 1925, the method may include sending an access package to an access client, the access package being compilable by the access client into an executable file used to access the file. The operations of 1925 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1925 may be performed by an access package interface 940, as described with reference to FIG.

[0222] At 1930, the method may include transmitting an access package to the access client, the access package including a data pack including an indication of one or more file access policies associated with the file, the executable code being configured to encrypt the data pack with the file using one or more access keys. The operations of 1930 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1930 may be performed by an access package interface 940, as described with reference to FIG. 9.

[0223] At 1935, the method may include transmitting to the access client an access package including a data pack including executable code configured to generate an audit log associated with the file and encrypt the audit log with the file using one or more access keys. The operations of 1935 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 1935 may be performed by an access package component 935 as described with reference to FIG.

[0224] FIG. 20 shows a flow chart illustrating a method 2000 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 2000 may be performed by a server or components thereof as described herein. For example, the operations of method 2000 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0225] At 2005, the method may include receiving an access request from an access client, the access request including access information and file information for a file to be accessed. The operations of 2005 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2005 may be performed by an access request interface 925, as described with reference to FIG.

[0226] At 2010, the method may include receiving an encryption request from an access client to encrypt a file, the access package including executable code for encrypting the file using one or more access keys. The operations of 2010 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2010 may be performed by encryption component 945, as described with reference to FIG. 9.

[0227] At 2015, the method may include receiving, from the access client, an indication of one or more file access policies associated with the file. The operations of 2015 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2015 may be performed by a file policy component 960, as described with reference to FIG. 9.

[0228] At 2020, the method may include storing one or more file access policies in association with a file identifier of the file. The operations of 2020 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2020 may be performed by a file policy component 960, as described with reference to FIG.

[0229] At 2025, the method may include validating the access request using the access information. The operations of 2025 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2025 may be performed by a request validation component 930, as described with reference to FIG.

[0230] At 2030, the method may include generating an access package including the executable code and one or more access keys based at least in part on the validation of the access request. The operations of 2030 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2030 may be performed by an access package component 935, as described with reference to FIG.

[0231] At 2035, the method can include sending an access package to the access client, the access package being compilable by the access client into an executable file used to access the file. The operations of 2035 can be performed according to examples disclosed herein. In some examples, aspects of the operations of 2035 may be performed by an access package interface 940, as described with reference to FIG. 9.

[0232] FIG. 21 shows a flow chart illustrating a method 2100 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 2100 may be performed by a server or components thereof as described herein. For example, the operations of method 2100 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0233] At 2105, the method may include receiving an access request from an access client, the access request including access information and file information for the file to be accessed. The operations of 2105 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2105 may be performed by an access request interface 925, as described with reference to FIG.

[0234] At 2110, the method may include receiving, from the access client, an indication of one or more users who are authorized to access the file. The operations of 2110 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2110 may be performed by a file policy component 960, as described with reference to FIG. 9.

[0235] At 2115, the method may include receiving an encryption request from an access client to encrypt a file, the access package including executable code for encrypting the file using one or more access keys. The operations of 2115 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2115 may be performed by encryption component 945, as described with reference to FIG. 9.

[0236] At 2120, the method may include storing, in association with a file identifier of the file, an indication of one or more users who are authorized to access the file. The operations of 2120 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2120 may be performed by a file policy component 960, as described with reference to FIG.

[0237] At 2125, the method may include validating the access request using the access information. The operations of 2125 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2125 may be performed by a request validation component 930, as described with reference to FIG.

[0238] At 2130, the method may include generating an access package including the executable code and one or more access keys based at least in part on the validation of the access request. The operations of 2130 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2130 may be performed by an access package component 935, as described with reference to FIG.

[0239] At 2135, the method can include sending an access package to the access client, the access package being compileable into an executable file used by the access client to access the file. The operations of 2135 can be performed according to examples disclosed herein. In some examples, aspects of the operations of 2135 may be performed by an access package interface 940, as described with reference to FIG. 9.

[0240] FIG. 22 shows a flow chart illustrating a method 2200 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 2200 may be performed by a server or components thereof as described herein. For example, the operations of method 2200 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0241] At 2205, the method may include receiving an access request from an access client, the access request including access information and file information for the file to be accessed. The operations of 2205 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2205 may be performed by an access request interface 925, as described with reference to FIG.

[0242] At 2210, the method may include validating the access request using the access information. The operations of 2210 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2210 may be performed by a request validation component 930, as described with reference to FIG.

[0243] At 2215, the method may include, at the server, comparing user information included in the access information received in the decryption request with an access record associated with the file. The operations of 2215 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2215 may be performed by a request validation component 930, as described with reference to FIG.

[0244] At 2220, the method may include determining that a user associated with the access client is authorized to access the file based at least in part on a result of the comparison, and an access package is sent to the access client based at least in part on determining that the user is authorized to access the file. The operations of 2220 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2220 may be performed by a request validation component 930, as described with reference to FIG. 9.

[0245] At 2225, the method may include generating an access package including the executable code and one or more access keys based at least in part on the validation of the access request. The operations of 2225 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2225 may be performed by an access package component 935, as described with reference to FIG.

[0246] At 2230, the method can include sending an access package to an access client, the access package being compileable by the access client into an executable file used to access the file. The operations of 2230 can be performed according to examples disclosed herein. In some examples, aspects of the operations of 2230 may be performed by an access package interface 940, as described with reference to FIG. 9.

[0247] At 2235, the method may include receiving a decryption request from an access client to decrypt a file, the access package including executable code for decrypting the file using one or more access keys. The operations of 2235 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2235 may be performed by a decryption component 950, as described with reference to FIG. 9.

[0248] FIG. 23 shows a flow chart illustrating a method 2300 for supporting encrypted file control according to aspects of the present disclosure. The operations of method 2300 may be performed by a server or components thereof as described herein. For example, the operations of method 2300 may be performed by a server as described with reference to FIGS. 1-6 and 9-10. In some examples, the server may execute a set of instructions to control functional elements of the server to perform the described functions. Additionally or alternatively, the server may perform aspects of the described functions using dedicated hardware.

[0249] At 2305, the method may include receiving an access request from an access client, the access request including access information and file information for the file to be accessed. The operations of 2305 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2305 may be performed by an access request interface 925, as described with reference to FIG.

[0250] At 2310, the method may include validating the access request using the access information. The operations of 2310 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2310 may be performed by a request validation component 930, as described with reference to FIG.

[0251] At 2315, the method may include generating an access package including the executable code and one or more access keys based at least in part on the validation of the access request. The operations of 2315 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2315 may be performed by an access package component 935, as described with reference to FIG.

[0252] At 2320, the method may include sending a request to a key storage service for a key string and a file identifier associated with the file based at least in part on receiving the access request. The operations of 2320 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2320 may be performed by a key identification component 955, as described with reference to FIG.

[0253] At 2325, the method may include receiving, from a key storage service, a key string associated with the file identifier. The operations of 2325 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2325 may be performed by a key identification component 955, as described with reference to FIG. 9.

[0254] At 2330, the method may include generating one or more access keys using the key string. The operations of 2330 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2330 may be performed by a key identification component 955, as described with reference to FIG.

[0255] At 2335, the method can include sending an access package to the access client, the access package being compilable by the access client into an executable file used to access the file. The operations of 2335 can be performed according to examples disclosed herein. In some examples, aspects of the operations of 2335 may be performed by an access package interface 940, as described with reference to FIG. 9.

[0256] A method for data security in an access client is described, the method including the steps of: sending an access request to a server, the access request including access information and file information of a file to be accessed; receiving an access package from the server, the access package including executable code and one or more access keys, based at least in part on the sending of the access request; executing, by the access client, the executable code to access the file using the one or more access keys; and deleting the access package from a memory associated with the access client.

[0257] An apparatus for data security in an access client is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to send an access request to a server including access information and file information of a file to be accessed, receive from the server an access package including executable code and one or more access keys based at least in part on sending the access request, execute, by the access client, the executable code to access the file using the one or more access keys, and delete the access package from a memory associated with the access client.

[0258] Another apparatus for data security in an access client is described, the apparatus may include means for transmitting an access request to a server, the access request including access information and file information of a file to be accessed, means for receiving from the server an access package including executable code and one or more access keys based at least in part on the transmission of the access request, means for executing, by the access client, the executable code to access the file using the one or more access keys, and means for deleting the access package from a memory associated with the access client.

[0259] A non-transitory computer readable medium storing code for data security at an access client is described, the code may include instructions executable by a processor to send an access request to a server including access information and file information of a file to be accessed, receive from the server an access package including executable code and one or more access keys based at least in part on the sending of the access request, execute, by the access client, the executable code to access the file using the one or more access keys, and delete the access package from a memory associated with the access client.

[0260] In some examples of the methods, apparatus, and non-transitory computer readable media described herein, the methods, apparatus, and non-transitory computer readable media may include further operations, features, means, or instructions for transmitting the encryption request and the file information to a server.

[0261] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access package may include an operation, feature, means, or instruction for receiving an access package including a data pack including an indication of one or more file access policies associated with the file, where the data pack may be encrypted with the file using one or more access keys.

[0262] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the one or more file access policies include read access, write access, viewing restrictions, or a combination thereof.

[0263] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access package may include operations, features, means, or instructions for receiving an access package including a data pack including an indication of ownership information associated with a file, where the data pack may be encrypted with the file using one or more access keys.

[0264] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the encryption request may include an act, feature, means, or instruction for sending to the server an indication of one or more file access policies associated with the file.

[0265] In some examples of the methods, apparatus, and non-transitory computer readable media described herein, executing the executable code may include acts, features, means, or instructions for using the executable code to encrypt the payload and one or more data packs using one or more access keys to generate an encrypted file.

[0266] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, encrypting one or more data packs may include operations, features, means, or instructions for encrypting one or more data packs that include indications of one or more file access policies, file ownership information, file access audit logs, or combinations thereof.

[0267] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the access request may include operations, features, means, or instructions for sending a decryption request and file information to a server, and the executable code includes code that may be used to decrypt the file.

[0268] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access package may include operations, features, means, or instructions for receiving an access package including a data pack that includes one or more updated file access policies.

[0269] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying, at the access client, verification information including access client information, computer information, device information, geographic location information, an authentication token, or combinations thereof, and the decryption request includes an indication of the verification information.

[0270] Some examples of methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying that a file may be associated with an access client based at least in part on metadata associated with the file, where the file includes a payload encrypted using a first one of the one or more access keys and one or more encrypted data packs that may be encrypted using at least a second one of the one or more access keys, and a decryption request may be sent to a server based at least in part on the file being associated with the access client.

[0271] In some examples of the methods, apparatus, and non-transitory computer readable media described herein, executing the executable code may include acts, features, means, or instructions for decrypting a file using one or more access keys.

[0272] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for displaying the payload of a file at an access client in accordance with one or more access policies associated with the file.

[0273] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the one or more access policies include read access, write access, viewing restrictions, or a combination thereof.

[0274] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the one or more access policies may be included in a data pack decrypted in the file using one or more access keys.

[0275] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for updating the file access audit log to include device information, user information, geographic location information, or combinations thereof associated with the access client.

[0276] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for identifying a payload and one or more data packs within the file based at least in part on decoding the file, the one or more data packs including indications of one or more file access policies, ownership information, file access audit logs, or combinations thereof.

[0277] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include acts, features, means, or instructions for instantiating, in a memory associated with the access client, an access object that may be used to decrypt or encrypt a file based at least in part on executing the executable code, and the access object may be deleted from the memory associated with the access client after decrypting or encrypting the file.

[0278] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for sending a decryption request and file information to a server, where the executable code includes code that can be used to overwrite the contents of the file.

[0279] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, transmitting the access request may include acts, features, means, or instructions for transmitting an access request including access information including a geographic location of a user device executing the access client, device information associated with the user device, network information associated with the user device, an authentication token associated with the access client, or a combination thereof.

[0280] A method for data security in a server is described, the method including the steps of receiving an access request from an access client, the access request including access information and file information of a file to be accessed, validating the access request using the access information, generating an access package including executable code and one or more access keys based at least in part on the step of validating the access request, and sending the access package to the access client, the access package being compilable by the access client into an executable file used to access the file.

[0281] An apparatus for data security in a server is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executable by the processor to cause the apparatus to receive an access request from an access client, the access request including access information and file information of a file to be accessed, validate the access request using the access information, generate an access package including executable code and one or more access keys based at least in part on validating the access request, and send the access package to the access client, the access package being compilable into an executable file used by the access client to access the file.

[0282] Another apparatus for data security in a server is described, the apparatus including means for receiving an access request from an access client, the access request including access information and file information of a file to be accessed, means for validating the access request using the access information, means for generating an access package including executable code and one or more access keys based at least in part on validating the access request, and means for transmitting the access package to the access client, the access package being compilable by the access client into an executable file used to access the file.

[0283] A non-transitory computer readable medium storing code for data security at a server is described, where the code may include instructions executable by a processor to receive an access request from an access client, the access request including access information and file information of a file to be accessed, validate the access request using the access information, generate an access package including executable code and one or more access keys based at least in part on validating the access request, and send the access package to the access client, where the access package is compilable into an executable file used by the access client to access the file.

[0284] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access request may include an act, feature, means, or instruction for receiving an encryption request from an access client to encrypt a file, and the access package includes executable code for encrypting the file using one or more access keys.

[0285] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the access package may include an operation, feature, means, or instruction for sending an access package to the access client including a data pack including an indication of one or more file access policies associated with the file, and the executable code may be configured to encrypt the data pack with the file using one or more access keys.

[0286] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the one or more file access policies include read access, write access, viewing restrictions, or a combination thereof.

[0287] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the access package may include operations, features, means, or instructions for sending to the access client an access package including a data pack including executable code that may be configured to generate an audit log associated with the file and encrypt the audit log with the file using one or more access keys.

[0288] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, sending the access package may include an operation, feature, means, or instruction for sending an access package to the access client including a data pack including an indication of ownership information associated with the file, and the executable code may be configured to encrypt the data pack with the file using one or more access keys.

[0289] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access request may include acts, features, means, or instructions for receiving, from an access client, an indication of one or more file access policies associated with the file, and storing the one or more file access policies in association with a file identifier for the file.

[0290] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access request may include acts, features, means, or instructions for receiving from an access client an indication of one or more users who may be authorized to access the file, and storing the indication of the one or more users who may be authorized to access the file in association with a file identifier of the file.

[0291] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, receiving an access request may include an act, feature, means, or instruction for receiving a decryption request from an access client to decrypt a file, where the access package includes executable code for decrypting the file using one or more access keys.

[0292] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for determining that a data pack including one or more file access policies for the file may be out of date and transmitting an updated data pack including one or more updated file access policies for the file based at least in part on determining that the data pack may be out of date.

[0293] Some examples of methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for, at the server, comparing user information that may be included in the access information received in the decryption request with an access record associated with the file, and determining, at least in part, that a user associated with the access client may be authorized to access the file based at least in part on the results of the comparison, and an access package may be sent to the access client based, at least in part, on determining that the user may be authorized to access the file.

[0294] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for determining, based at least in part on the access information received in the decryption request, that the access client may not be authorized to decrypt the file, and triggering an action at the server based at least in part on determining that the access client may not be authorized to decrypt the file.

[0295] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, triggering an action may include an action, feature, means, or instruction for generating a warning or message indicating that the access client has sent an unauthorized access request.

[0296] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, triggering an action may include an action, feature, means, or instruction for sending an access package including executable code that overwrites the contents of the file.

[0297] Some examples of methods, apparatus, and non-transitory computer-readable media described herein may further include acts, features, means, or instructions for sending a request to a key storage service for a key string and a file identifier associated with the file based at least in part on receiving the access request, receiving from the key storage service a key string associated with the file identifier, and generating one or more access keys using the key string.

[0298] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, validating the access request may include operations, features, means, or instructions for validating access information including, for any combination thereof, a geographic location of a user device executing the access client, device information associated with the user device, network information associated with the user device, and an authentication token associated with the access client.

[0299] It should be noted that these methods describe example implementations, and that the operations and steps can be rearranged or otherwise modified such that other implementations are possible. In some examples, aspects from two or more methods can be combined. For example, aspects of each method can include steps or aspects of other methods, or other steps or techniques described herein. Thus, aspects of the present disclosure can provide consumer preference and maintenance interfaces.

[0300] The description set forth herein describes exemplary configurations in conjunction with the accompanying drawings and does not represent every example that may be implemented or fall within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration" and does not mean "preferred" or "advantageous over other examples." The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, these technologies may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.

[0301] In the accompanying drawings, similar components or features may have the same reference label. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes the similar components. If only a first reference label is used in this specification, the description is applicable to any of the similar components having the same first reference label regardless of the second reference label.

[0302] The information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0303] The various example blocks and modules described in connection with the disclosure herein may be implemented or performed using a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration.

[0304] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions may be stored or transmitted as one or more instructions or codes on a computer-readable medium. Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination thereof. Features implementing the functions may also be physically located in various locations, including being distributed such that some of the functions are implemented in different physical locations. Also, as used herein, including in the claims, "or" used in a list of items (e.g., a list of items prefaced with a phrase such as "at least one" or "one or more") indicates an inclusive list, such as, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an example step described as "based on condition A" can be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" is intended to be interpreted in the same manner as the phrase "based at least in part on."

[0305] Computer-readable media includes both non-transitory computer storage media and communication media, including any medium that facilitates transfer of a computer program from one place to another. Non-transitory storage media may be any available medium accessible by a general purpose or special purpose computer. By way of example and not limitation, non-transitory computer-readable media may include RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general purpose or special purpose computer, or a general purpose or special purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio and microwave are included in the definition of the medium. As used herein, disk and disc include CDs, laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically and disks reproduce data optically using a laser. Combinations of the above are also included within the scope of computer readable media.

[0306] The various example blocks and modules described in connection with the disclosure herein may be implemented or performed using a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration. The functionality of each unit may also be implemented in whole or in part by instructions embodied in a memory formatted to be executed by one or more general purpose or application specific processors.

[0307] In the accompanying drawings, similar components or features may have the same reference label. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes the similar components. If only a first reference label is used in this specification, the description is applicable to any of the similar components having the same first reference label regardless of the second reference label.

[0308] The description herein is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. 1. A method for data security in an access client, comprising: identifying a file associated with the access client based at least in part on metadata associated with the file, the file including a payload encrypted using a first one of one or more access keys and one or more encrypted data packs encrypted using at least a second one of the one or more access keys; sending an access request to a server, the access request including access information and file information of the file to be accessed, the sending of the access request comprising: sending a decryption request and the file information to the server, the decryption request being sent to the server based at least in part on the file being associated with the access client; receiving an access package from the server based at least in part on the transmission of the access request, the access package including executable code and one or more access keys, the executable code including code used to decrypt the file; executing, by the access client, the executable code to access the file using the one or more access keys; and deleting the access package from a memory associated with the access client.

2. The step of transmitting the access request includes: The method of claim 1 , further comprising the step of transmitting an encryption request and the file information to the server.

3. The step of receiving the access package includes:

3. The method of claim 2, further comprising: receiving the access package including a data pack including an indication of one or more file access policies associated with the file, the data pack being encrypted with the file using the one or more access keys.

4. The method of claim 3 , wherein the one or more file access policies include read access, write access, viewing restrictions, or a combination thereof.

5. The step of receiving the access package includes:

3. The method of claim 2, further comprising: receiving the access package including a data pack including an indication of ownership information associated with the file, the data pack being encrypted with the file using the one or more access keys.

6. The step of transmitting the encryption request includes:

3. The method of claim 2, further comprising the step of transmitting to the server an indication of one or more file access policies associated with the file.

7. The step of executing the executable code includes:

3. The method of claim 2, comprising using the executable code to encrypt a payload and one or more data packs using the one or more access keys to generate an encrypted file.

8. The step of encrypting the one or more data packs comprises:

8. The method of claim 7, comprising encrypting the one or more data packs that include an indication of one or more file access policies, file ownership information, file access audit logs, or a combination thereof.

9. The step of receiving the access package includes: and receiving the access package including a data pack including one or more updated file access policies.

10. 10. The method of claim 1, further comprising identifying, at the access client, verification information including access client information, computer information, device information, geographic location information, an authentication token, or a combination thereof, and wherein the decryption request includes an indication of the verification information.

11. 2. The method of claim 1, further comprising: instantiating, within the memory associated with the access client, an access object used to decrypt or encrypt the file based at least in part on executing the executable code, the access object being deleted from the memory associated with the access client after decrypting or encrypting the file.

12. 2. The method of claim 1, further comprising the step of sending a decryption request and the file information to the server, the executable code including code used to overwrite contents of the file.

13. The step of transmitting the access request includes:

2. The method of claim 1, comprising: transmitting the access request including the access information including a geographic location of a user device executing the access client, device information associated with the user device, network information associated with the user device, an authentication token associated with the access client, or a combination thereof.

14. The step of executing the executable code includes: The method of claim 1 , further comprising the step of decrypting the file using the one or more access keys.

15. displaying the payload of the file at the access client in accordance with one or more access policies associated with the file. The method of claim 14.

16. The method of claim 15 , wherein the one or more access policies include read access, write access, display restrictions, or a combination thereof.

17. The method of claim 15 , wherein the one or more access policies are included in a data pack decrypted with the file using the one or more access keys.

18. 15. The method of claim 14, further comprising updating a file access audit log to include device information, user information, geographic location information, or a combination thereof, associated with the access client.

19. 15. The method of claim 14, further comprising identifying a payload and one or more data packs within the file based at least in part on the decryption of the file, the one or more data packs including an indication of one or more file access policies, ownership information, a file access audit log, or a combination thereof.

20. An apparatus for data security in an access client, comprising: A processor; a memory coupled to the processor; Instructions stored in the memory and executable by the processor, the instructions causing the device to: identifying a file as being associated with the access client based at least in part on metadata associated with a file, the file including a payload encrypted using a first one of one or more access keys and one or more encrypted data packs encrypted using at least a second one of the one or more access keys; causing a server to transmit an access request including access information and file information of the file to be accessed, and transmitting the access request includes: sending a decryption request and the file information to the server, the decryption request being sent to the server based at least in part on the file being associated with the access client; receiving, based at least in part on the transmission of the access request, an access package from the server, the access package including executable code and one or more access keys, the executable code including code used to decrypt the file; causing execution, by the access client, of the executable code to access the file using the one or more access keys; and causing the access package to be deleted from a memory associated with the access client.

21. 1. A non-transitory computer readable medium storing code for data security at an access client, the code comprising: identifying a file associated with the access client based at least in part on metadata associated with the file, the file including a payload encrypted using a first one of one or more access keys and one or more encrypted data packs encrypted using at least a second one of the one or more access keys; Sending an access request to a server, the access request including access information and file information of a file to be accessed, and sending the access request includes: sending a decryption request and the file information to the server, the decryption request being sent to the server based at least in part on the file being associated with the access client; receiving an access package from the server based at least in part on the transmission of the access request, the access package including executable code and one or more access keys, the executable code including code used to decrypt the file; executing, by the access client, the executable code to access the file using the one or more access keys; A non-transitory computer-readable medium comprising instructions executable by a processor to delete the access package from a memory associated with the access client.

Images