System and method for reliably destroying encryption keys

Abstract

The present disclosure provides a logical treadmill of encryption keys that are created, distributed, and destroyed on a predictable schedule. It also provides a read-only interface for a remote procedure call (RPC) infrastructure that provides cryptographic prophetic access to keys on the treadmill.

Description

[0001] Cross-references to related applications

[0002] This application is a continuation to U.S. Patent Application No. 17 / 388,900, filed July 29, 2021, which claims priority to the filing date of U.S. Provisional Patent Application No. 63 / 104,874, filed October 23, 2020, the disclosure of which is incorporated herein by reference. Background Technology

[0003] Data is typically protected by one or more data encryption keys (DEKs) that are encrypted using a high-value master key. Therefore, the ciphertext possesses properties determined by the key. For example, the ciphertext is subject to access control applied to the high-value master key. Traditionally, the role of the high-value master key is to ensure its reliability, confidentiality, durability, and usability. Summary of the Invention

[0004] Some applications require keys to be transient, meaning the keys are guaranteed to be destroyed. For example, applications such as temporary user identifiability, data recovery from active storage, or distributed secure socket layer (SSL) session key management may require keys to be transient.

[0005] One aspect of the present invention provides a method for providing cloud services that encrypt data with reliable key destruction, comprising: maintaining a logical treadmill of multiple unique encryption keys, the multiple unique encryption keys being made available and destroyed according to a predetermined schedule; and providing an interface that allows encrypted oracle access to the encryption keys on the treadmill. Deletion timestamps may indicate the maximum lifespan before expiration.

[0006] According to some examples, each encryption key has a deletion timestamp indicating when the key will be removed from the treadmill. Maintaining the logical treadmill includes comparing the deletion timestamp of each encryption key with the current time. It may also include removing a given key from the logical treadmill when the deletion timestamp is equal to or later than the current time.

[0007] According to one example, the encryption key is made available according to a first predetermined schedule and destroyed according to a second predetermined schedule different from the first predetermined schedule.

[0008] In some examples, the method may further include receiving data from a client, encrypting the data using one of the keys from the logical treadmill, and automatically destroying one of the keys used to encrypt the data after a predetermined time period. The method may also include receiving from the client an indication of the duration for which the data should be accessible, wherein the key used to encrypt the data is selected from the treadmill based on the amount of time remaining between the current time and the deletion timestamp, the remaining time corresponding to the duration indicated by the client.

[0009] In some examples, the maintenance logic treadmill may include deploying multiple distributed server processes, each of which maintains key material and executes a loop to remove the key material from memory at the deletion timestamp. The multiple distributed server processes reside within the same physical region.

[0010] Another aspect of this disclosure provides a system for secure encryption. The system may include: one or more processors configured to maintain a logical treadmill of multiple unique encryption keys, which are made available and destroyed according to a predetermined schedule; and an interface that grants cryptographic oracle access to the encryption keys on the treadmill. Each encryption key has a deletion timestamp indicating when the key will be deleted from the treadmill. The encryption keys are made available according to a first predetermined schedule and destroyed according to a second predetermined schedule different from the first predetermined schedule. The deletion timestamp may indicate a maximum lifespan before expiration.

[0011] The one or more processors can be configured to delete all keys in the treadmill based on comparing the deletion timestamp of each encryption key with the current time. For example, a processor can remove a given key from the logical treadmill when the deletion timestamp is equal to or later than the current time.

[0012] The one or more processors may be further configured to receive data from a client, encrypt the data using one of the keys from the logical treadmill, and automatically destroy one of the keys used to encrypt the data after a predetermined period of time. An indication is received from the client of the duration for which the data should be accessible, wherein the key used to encrypt the data is selected from the treadmill based on the amount of time remaining between the current time and the deletion timestamp, the remaining time corresponding to the duration indicated by the client.

[0013] According to some examples, one or more processors include multiple distributed server processes, each of which maintains key material and executes a loop to remove the key material from memory at the deletion timestamp. Multiple distributed server processes may reside in the same physical region. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of an exemplary logical treadmill for encryption according to various aspects of this disclosure.

[0015] Figure 2 It is a block diagram of an example system based on various aspects of this disclosure.

[0016] Figure 3 This is a block diagram of another example system based on various aspects of this disclosure.

[0017] Figure 4 This is a flowchart illustrating example methods according to various aspects of this disclosure. Detailed Implementation

[0018] This disclosure provides a logical treadmill for cryptographic keys, which is created, distributed, and destroyed according to a predictable schedule. It also provides a read-only interface for remote procedure call (RPC) infrastructure that provides cryptographic oracle access to the keys on the treadmill.

[0019] The logical treadmill consists of a set of cryptographic keys that rotate at a specific granularity. For example, a key is generated every X minutes and expires after Y minutes. As a system guarantee, the keys will only exist in volatile memory and will be deleted from all server instances when they expire.

[0020] Figure 1 An example of an encryption key treadmill 100 is shown. The encryption key treadmill 100 includes a sequence of periodically updated unique encryption keys K1, K2, K3, etc. Each encryption key is identified by available timestamps TS1A, TS2A, TS3A, and follows deletion timestamps TS1B, TS2B, TS3B. The deletion timestamps can be determined by the system-wide time to live (TTL), which is defined relative to a globally observed clock 150.

[0021] like Figure 1As shown, when treadmill 100 becomes available, key K1 is added to treadmill 100 at time TS1A. Key K1 can be used to encrypt data from clients until it expires at TS1B. When key K1 expires, or even shortly before expiration, key K1 is removed from treadmill 100 and permanently deleted.

[0022] One or more second keys K2 can be added to treadmill 100 while the first key K1 is still spinning or after it has expired. For example, the available timestamp TS2A of the second key K2 can be earlier than, later than, or equal to the expiration timestamp TS1B of the first key K1. Although in Figure 1 Only one key is shown on treadmill 100 at a given time, but it should be understood that multiple keys may be rotated at any given time.

[0023] New keys K3 can be added periodically to treadmill 100. For example, one or more new keys can be added when one or more keys expire. Following other examples, new keys can be added at regular intervals. For example, a new key can be added every minute, 30 minutes, hour, several hours, etc.

[0024] The system-wide TTL for determining when a key expires can be, for example, minutes, hours, days, weeks, months, etc. In some implementations, the maximum TTL can vary from one key to the next. In some examples, the system-wide TTL can be reconfigured. Thus, some keys added to the treadmill before reconfiguration may have a first TTL, while other keys added after reconfiguration may have a second TTL. By attaching new keys at explicit, configurable time intervals (e.g., one hour), and by appropriately configuring the system-wide TTL (e.g., 30 days), the key treadmill reliably guarantees that for any TTL from 0 to 30 days, some keys will be destroyed within one hour of the TTL.

[0025] Updates to the treadmills can occur within a distributed operation, referred to here as a "shred loop." The execution of the shred loop and the replication of keys on the treadmills can be coordinated by a distributed lock service. Logically, the shred loop globally deletes all keys preceding the treadmills, the deletion time of which, for example, is indicated by an expiration timestamp, is less than or equal to Now(). For example, the shred loop globally deletes all key records from treadmill 100, and each server also evicts its copy from memory. Once a key expires and all copies of the key are deleted from memory, the data encrypted by that key can no longer be accessed. The shred loop also appends a new key with an available time, for example, indicated by an available timestamp, equal to the current time of global clock 150, to the end of the treadmill.

[0026] The treadmill can expose a read-only interface, such as via a Remote Procedure Call (RPC) structure, providing access to an ephemeral key on the treadmill. This interface can implement major cryptographic operations. Such operations can include, for example, a wrapping operation that briefly wraps short blocks of data using the key on the treadmill, and an unwrap operation that unwraps the ciphertext produced by the wrapping operation if the wrapping key is still available.

[0027] Figure 2 An example system in which the encryption key treadmill is distributed across multiple nodes is illustrated. For example, as shown in the figure, area 210 includes multiple nodes 212, 214, and 216. Nodes can be, for example, servers, replicas, or any other computing devices operating in a distributed system, such as in the “cloud.” In this example, a node is an instance of a server process. As described herein, the terms server process, replica, and node are used interchangeably.

[0028] Nodes can receive requests from client 260, where such requests are distributed among nodes 212-216 by load balancer 250. For example, the request could be encrypted data. Nodes 212-216 encrypt the data using a key from the logical treadmill and return the data to client 260. In this respect, nodes 212-216 provide cloud services to client 260, where the logical treadmill encrypts the service data using the encryption key.

[0029] Nodes 212, 214, and 216 are communicatively coupled to a distributed lock service 240 comprising cells A, B, and C. For example, nodes 212-216 can be coupled to the distributed lock service 240 via a replication layer 230. Updates are pushed to all nodes 212-216 via the replication layer 230. Updates may include, for example, key schedules, rather than key materials. Updates can be pushed to nodes 212-216 asynchronously.

[0030] The cryptographic key treadmill state includes (i) a common treadmill timer that times events on the cryptographic key treadmill, and (ii) private key material for each key on the treadmill. The common treadmill timer is replicated using a distributed lock service 240. In a given regional deployment, the treadmill key material is replicated and strictly isolated to, for example, RAM, e.g., through lightweight synchronization over a protected channel.

[0031] Within each server instance, a distributed fragment cycle is used to keep the treadmill running, employing master election and local work. The master node can be the sole replica of the system-wide view responsible for propagating new key versions and setting the treadmill state. All other nodes view the treadmill files in the distributed lock service 240, then perform work on the local fragment key and synchronize with their peers if local loss or corruption is detected.

[0032] The system selects a single master node to perform treadmill management. Figure 2 In the example, node 212 is elected as the master node. For instance, the elected master node 212 pushes the determined state to the distributed lock service 240, along with a description of which keys exist. The election of master node 212 forces that there is only one writer for all timer replicas. The timer file will be written by a single master replica and will be world-readable, viewable via replication layer 230.

[0033] In the distributed lock service unit (AC), the master lock box maintains a consistent and authoritative view of which server process is the master. This view is updated when nodes 212-216 participate in the master election protocol, and then the nodes are able to determine definitively whether they are the master node and when they are the master node.

[0034] In some examples, the master node maintains a defined key schedule for use by nodes 212-216. The schedule defines when a particular key becomes available and when it should be destroyed. Master node 212 uses this defined key schedule to update the logical treadmill.

[0035] Schedule predictability is achieved in the fragmentation cycle by fixing the key generation frequency and enforcing that only one new key can be considered "propagated" at a time. Schedule predictability can be provided by one or more parameters. Such parameters could include, for example, that at least one key is propagated through the system at a given time. Furthermore, each key has a fixed TTL, determined by the master replica to which it is added. Keys are added to the end of the schedule in ascending order of expiration time. Subsequent key expiration times are divided by a fixed fragmentation time (TTS). Subsequent key availability intervals either overlap or have no time delay between them.

[0036] If the current time is less than the key's availability time, the key on the treadmill is considered to be in a distribution state. In some examples, the system can force at least one key to be in a distribution state at a given time through distributed fragmentation cycles.

[0037] Master node 212 wakes up frequently to check if a new key should be added to the treadmill. If a new key should be added, master node 212 pushes the update to all nodes 214 and 216. For example, such an update can be pushed by master node 212 via distributed lock service 240 and replication layer 230. The update may include a key schedule, rather than key material. All nodes 212-126 wake up frequently to check if they have missed an update based on the current time. If they have missed an update, they attempt to synchronize with randomly selected neighbors. For example, if node 216 wakes up and determines it has missed an update based on the global clock, node 216 may attempt to synchronize with node 214. For example, a node may asynchronously poll peer nodes for key material. A node can determine if it has missed an update, for example, by resolving a local copy of the treadmill timer via replication layer 230 and checking if the node has the key material for all keys in the timer. If not, the node can synchronize with its peers.

[0038] In distributed lock service 240, the common treadmill state will be explicitly copied between units AC. Although in Figure 2 The diagram shows three units, but it should be understood that the distributed lock service 240 can include any number of units. For each unit, a serializable data structure containing a treadmill timer will be written to a file. The serializable data structure indicates the available timestamp and the deletion timestamp. The state is determined using a majority rule; for example, if a treadmill timer entry is written to a majority of units, then the treadmill timer entry is considered to exist.

[0039] Treadmill status can be coordinated through the internal management interface exposed on nodes 212-216. This interface can be used to coordinate treadmill maintenance and synchronization. The internal management interface will only respond to server instances within the same regional deployment 210. Operations supported by this interface include update operations used by the master node to push treadmill status to non-master replicas and check operations used by all replicas for synchronization. Updates take treadmill schedules and key material mappings and install them on the local replica. Check operations return locally known treadmill schedules and all known key material.

[0040] At each node 212-216, the replica sharding loop runs frequently. The replica sharding loop primarily performs local work to shred expired keys, detect lost / corrupted keys, and receive missed updates. For example, the replica sharding loop might run to resolve the current treadmill state from the distributed lock service 240. This information can be provided by asynchronous replication layer observers registered for the relevant files. The replica sharding loop can further evict any keys known to be missing from the timeline or expired. For all keys in the timeline that are not expired, the replica observation loop can verify that uncorrupted key material is available for that key. For example, internally, each server can maintain a checksum that can be used for this verification. If unavailable or corrupted key material is detected, a check operation can be performed. For example, a node can check one or more randomly selected classes and search the state of each class to obtain the required key material.

[0041] At the selected primary instance 212, the primary shard runs in a loop, primarily performing local work to correct global schedule losses and advance the schedule. After a periodically scheduled replica cycle, primary instance 212 advances the schedule so that it is up-to-date and contains the schedule buffer at the target time. The primary instance uses the target time as the execution timestamp for the current shard cycle and corrects any lost or corrupted keys in the schedule. Correcting lost or corrupted keys may include, for example, generating new key material and updating the key hash of any key, which should be available at any point within the schedule buffer at the target time. The primary node also checks if the schedule is already up-to-date at the target time plus the schedule buffer. For example, the primary node checks if a certain key in the schedule is being propagated. If no key is being propagated, the primary node advances the schedule and pushes updates.

[0042] The rollout schedule can include an execution process where, if the schedule is empty, a key is added. The added key can be added with a key availability time equal to the target time plus fragment time, minus the TTL. The added key can also be deleted with a key deletion time equal to the availability time plus the TTL. The rollout schedule process can further include calculating the absolute deletion time, distribution, and availability time of a new key when the last key in the schedule has not been propagated by the target time. The absolute deletion time can be calculated using the last deletion time plus the fragment time. The availability time can be calculated as the maximum value of the previous availability time, or the deletion time minus the TTL. The process can also remove all keys that expired before the target time from the schedule.

[0043] Pushing updates can include updating the treadmill file in the distributed lock service 240. An updated treadmill state, containing both the key schedule and key material, can be pushed to all nodes 212-216 via update calls to each node. In some cases, some nodes may miss the update. In this case, these nodes will self-correct in the next local replica shard cycle. The master node can perform server authorization checks before completing the push and / or before accepting check requests. For example, the master node can apply security policies to RPC channels between peers, requiring peers to authenticate as process servers in the same regionalized deployment.

[0044] As an externally-facing cloud service, the system exposes a cryptographic oracle interface as an RPC infrastructure service to temporary keys in a given regional deployment. As mentioned above, this interface supports temporary envelope encryption through RPC wrapping and unwrapping operations. Temporariness can be guaranteed by a cryptographic key treadmill, which reliably guarantees that for any TTL from 0 to 30 days, some keys will be destroyed within one hour of the TTL by attaching new keys at well-defined, configurable intervals (e.g., 1 hour) and by properly configuring the system-wide TTL (e.g., 30 days).

[0045] Each node 212-216 in the system will have local access to the cryptographic key treadmill timer, for example, via the distributed lock service 240 and updates from the master node 212. Each node 212-216 will also have local access to cryptographic key material obtained through peer-to-peer synchronization.

[0046] The AC unit of the distributed lock service 240 can store timers that associate key hashes with events for those keys. For example, a timer could be a sequence of entries for each key containing the following: key hash, key creation time, and key deletion time. According to some examples, the timer can also contain other information corresponding to the key. Each key hash can have one entry. In this respect, the timers, along with the creation and deletion times, can form a mapping from key hashes to key timelines. The sequence can be sorted by creation time to allow for efficient searching. The timers are distributed to nodes 212-216 via replication layer 230. Each node 212-216 can store a mapping that associates key hashes with key material, such as the mapping of key material associated with update operations mentioned above. When a wrapping operation is performed to encrypt data, the key can be resolved by the TTL, for example, by searching the mapping based on the deletion time. When an unwrapping operation is performed to decrypt data, the node can consult its locally stored mapping to resolve the key.

[0047] In each packaging operation, the copy resolves the key to be used on the treadmill using a policy that employs the first key in the schedule and a deletion timestamp following the expiration time. Using this key, the system encrypts the envelope containing the plaintext, thereby creating the packaging key. In addition to the packaging key and key name, the system returns (i) the hash of the key used to generate the ciphertext, (ii) the region of the requested instance, and (iii) the final expiration time determined by the key used for packaging.

[0048] On each unpacking request, the server instance uses a key hash to parse the corresponding key. This key is used to unpack the ciphertext. If unpacking is successful, this will generate key bytes and a fingerprint verifying the source of the plaintext. If the user making the unpacking request meets the access policy, the plaintext is returned to the user.

[0049] The system implements a region-aware security model. If the system is compromised in one region, an attacker cannot obtain key material managed by the system in any other region. All key material synchronization endpoints will only serve instances within the same region, and each master node will refuse to push to invalid peers. Furthermore, if the system is compromised in one region, an attacker cannot use the compromised instance to unpack or re-export any content packaged or exported in another region.

[0050] Figure 3 It shows Figure 2 This is an example system of internal components of a system. Specifically, the system includes a client device 390 that communicates with one or more servers 320 via a network 350, wherein the one or more servers provide encryption of data provided by the client 390.

[0051] Server 320 may run services such as receiving requests from client 390 to encrypt or decrypt data. According to some examples, encryption may be performed using encryption oracle 310. Although encryption oracle 310 is shown as a component within server 320, it should be understood that in other examples, encryption oracle 310 may be a component that communicates externally with server 320. In any example, encryption oracle 310 may be a key management library, a hardware security module (HSM), or other implementation. In further examples, encryption oracle 310 may be a software module executed by one or more processors 370.

[0052] Server 320 includes one or more processors 370. Processor 370 can be any conventional processor, such as a commercially available CPU. Alternatively, the processor can be a special-purpose component, such as an application-specific integrated circuit (“ASIC”) or other hardware-based processor. Although not required, server 320 may include special-purpose hardware components to perform specific computational processes.

[0053] The memory 360 may store information accessible to the processor 370, including instructions that can be executed by the processor 370 and can be retrieved, manipulated, or stored by the processor 370.

[0054] Instructions can be a set of instructions that are executed directly by processor 370, such as machine code, or a set of instructions that are executed indirectly, such as a script. In this context, the terms "instruction," "step," and "program" are used interchangeably. Instructions can be stored in object code format for direct processing by processor 370 or other types of computer languages, including scripts or sets of independent source code modules that are interpreted on demand or pre-compiled. The functionality, methods, and routines of instructions are explained in more detail in the preceding examples and the example methods below.

[0055] Data can be retrieved, stored, or modified by processor 370 according to instructions. Data can also be formatted in a computer-readable format, such as, but not limited to, binary values, ASCII, or Unicode. Furthermore, data may include information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary code, pointers, references to data stored in other memory (including other network locations), or information used by functions to calculate the relevant data.

[0056] although Figure 3 Functionally, the processor, memory, and other components of server 320 are described as being located within the same block; however, a processor, computer, computing device, or memory may actually include multiple processors, computers, computing devices, or memories that may or may not be stored within the same physical enclosure. For example, memory may be a hard drive or other storage media located in an enclosure different from that of server 320. Therefore, references to processors, computers, computing devices, or memory will be understood to include references to a collection of processors, computers, computing devices, or memories that may or may not operate in parallel. For example, server 320 may include server computing devices operating as a load-balancing server farm, a distributed system, etc. Furthermore, although some functions described below are indicated to occur on a single computing device with a single processor, various aspects of the subject matter described herein can be implemented by multiple computing devices, for example, transmitting information over a network.

[0057] Memory 360 may store information accessible to processor 370, including instructions 362 that can be executed by processor 370. Memory may also include data 364 that can be retrieved, manipulated, or stored by processor 370. Memory 360 may be a non-transitory computer-readable medium capable of storing information accessible to processor 370, such as a hard disk drive, solid-state drive, magnetic tape drive, optical storage, memory card, ROM, RAM, DVD, CD-ROM, writable and read-only memory. Processor 370 may be a well-known processor or other known types of processor. Alternatively, processor 370 may be a dedicated controller, such as an ASIC.

[0058] Instruction 362 can be a set of instructions that are directly executed by processor 370, such as machine code, or indirectly executed, such as a script. In this context, the terms "instruction," "step," and "program" are used interchangeably. Instruction 362 can be stored in object code format for direct processing by processor 370, or it can be stored as a script or set of independent source code modules in other types of computer languages, including those interpreted on demand or pre-compiled.

[0059] Data 364 can be retrieved, stored, or modified by processor 370 according to instruction 362. For example, although the system and method are not limited to a specific data structure, data 364 can be stored as a table with multiple different fields and records in a computer register in a relational database, or stored in an XML document. Data 364 can also be formatted in a computer-readable format, such as, but not limited to, binary values, ASCII, or Unicode. Furthermore, data 364 may include information sufficient to identify relevant information, such as numbers, descriptive text, proprietary code, pointers, references to data stored in other memory (including other network locations), or information used by functions to calculate relevant data.

[0060] Executable instruction 362 can be used to encrypt data received from client device 390 using a key from the logic treadmill. Instruction 362 can also be executed to update the logic treadmill, for example by executing the master fragment cycle or replica fragment cycle described above.

[0061] Server 320 may also include volatile memory 325, which may be integrated with memory 360 or served as a separate memory unit. Volatile memory 325 may be responsible for storing key materials, such as hashes and events.

[0062] Furthermore, for the example system described above, an example method is now described. This method can be performed using the system described above, its modifications, or any of various systems with different configurations. It should be understood that the operations involved in the following method do not necessarily have to be performed in the exact order described. Instead, various operations can be processed in different orders or simultaneously, and operations can be added or omitted.

[0063] Figure 4 An example method 400 for encrypting data using reliable key destruction is shown. This method can be executed by, for example, a system with one or more distributed server processes.

[0064] In box 410, data is received from the client. For example, the data may include writes to a database or any other information. This data may be information that the client wishes to make temporarily available. According to some examples, along with the request to provide the data, the client may also specify the duration for which the data should be accessible.

[0065] In box 420, data is encrypted using one of several keys. For example, each of the keys may be added to the logical treadmill of available keys at predetermined intervals. Furthermore, each of the keys may have a predetermined expiration. Availability and expiration may be specified by one or more timestamps. Depending on the example of a client specifying the duration for which data can be accessed, the expiration of a key may correspond to a specified duration. One of the keys used to encrypt the data can be any available key on the treadmill. Encrypting the data may include, for example, performing a wrapping operation.

[0066] In box 430, a predetermined time period has elapsed. For example, the predetermined time period could correspond to the duration between data encryption and key expiration.

[0067] In box 440, the key for encrypting the data is destroyed. For example, all records of the key can be automatically deleted from the logical runner. Furthermore, in the server process, all key material for the key is automatically deleted from storage. When the key is destroyed, the data can no longer be accessed.

[0068] In some examples, the duration of data accessibility can be extended. For instance, a client might request access to data for an additional period. In this case, the data can be re-encrypted using a new key from the logic treadmill. For example, before expiration, the data could be unpacked and then repackaged using the new key.

[0069] As described above, encryption is performed using a key from the logic treadmill, providing cryptographic guarantees to the client. The destruction of the key used for encryption can be as secure as the destruction of the data itself, provided the data remains secure. For example, even if a copy of the encrypted data is kept somewhere in memory, the plaintext data will be inaccessible because the key has been destroyed.

[0070] Unless otherwise stated, the above alternative examples are not mutually exclusive, but can be implemented in various combinations to achieve unique advantages. Since these and other variations and combinations of the features discussed above can be utilized without departing from the subject matter defined by the claims, the above description of the embodiments should be carried out in an illustrative rather than restrictive manner towards the subject matter defined by the claims. Furthermore, the embodiments provided herein, and terms phrased as "such as," "including," etc., should not be construed as limiting the subject matter of the claims to the specific embodiments; rather, these embodiments are merely illustrative of one of many possible embodiments. Additionally, the same reference numerals in different drawings may identify the same or similar elements.

Claims

1. A method for reliably destroying an encryption key, characterized in that, include: A logical treadmill that maintains multiple unique encryption keys, which are made available and destroyed according to a predetermined schedule; Provide an interface that allows encrypted oracle access to the encryption key on the treadmill; Receive data from the client; The data is encrypted using one of the keys from the logical treadmill; After a predetermined period of time, one of the keys used to encrypt the data will be automatically destroyed; as well as The client receives an indication of the duration for which the data should be accessible, wherein the key for encrypting the data is selected from the treadmill based on the amount of time remaining between the current time and the deletion timestamp, the amount of time remaining corresponding to the duration indicated by the client.

2. The method according to claim 1, characterized in that, Each encryption key has a deletion timestamp that indicates when the key will be removed from the treadmill.

3. The method according to claim 2, characterized in that, Maintaining the logical treadmill includes comparing the deletion timestamp of each encryption key with the current time.

4. The method according to claim 3, characterized in that, It also includes removing a given key from the logical treadmill when the deletion timestamp is equal to or later than the current time.

5. The method according to claim 1, characterized in that, The encryption key is made available according to a first predetermined schedule and destroyed according to a second predetermined schedule different from the first predetermined schedule.

6. The method according to claim 1, characterized in that, The deletion timestamp indicates the maximum lifespan before expiration.

7. The method according to claim 1, characterized in that, Maintaining the logical treadmill includes deploying multiple distributed server processes, each of which maintains key material and executes a loop that removes the key material from memory at the deletion timestamp.

8. The method according to claim 7, characterized in that, The multiple distributed server processes are located in the same physical region.

9. A system for reliably destroying encryption keys, characterized in that, include: One or more processors configured to maintain a logical treadmill of multiple unique cryptographic keys, which are made available and destroyed according to a predetermined schedule; as well as An interface that allows encrypted oracle access to the encryption key on the treadmill; The one or more processors are further configured to: Receive data from the client; The data is encrypted using one of the keys from the logical treadmill; After a predetermined period of time, one of the keys used to encrypt the data will be automatically destroyed; as well as The data received from the client is accompanied by an encryption request indicating the duration for which the data should be accessible, wherein the key for encrypting the data is selected from the treadmill based on the amount of time remaining between the current time and the deletion timestamp, the remaining amount of time corresponding to the duration indicated by the client.

10. The system according to claim 9, characterized in that, Each encryption key has a deletion timestamp that indicates when the key will be removed from the treadmill.

11. The system according to claim 10, characterized in that, When maintaining the logical treadmill, the one or more processors are configured to delete all expired keys in the treadmill based on comparing the deletion timestamp of each encryption key with the current time.

12. The system according to claim 11, characterized in that, When maintaining the logical treadmill, the one or more processors are configured to remove a given key from the logical treadmill when the deletion timestamp is equal to or later than the current time.

13. The system according to claim 9, characterized in that, The encryption key is made available according to a first predetermined schedule and destroyed according to a second predetermined schedule different from the first predetermined schedule.

14. The system according to claim 9, characterized in that, The deletion timestamp indicates the maximum lifespan before expiration.

15. The system according to claim 9, characterized in that, The one or more processors include multiple distributed server processes, each of which maintains key material and executes a loop that removes the key material from memory at the deletion timestamp.

16. The system according to claim 15, characterized in that, The multiple distributed server processes are located in the same physical region.

Images