Dual-clock based shared key generation

Abstract

Techniques for computer security, and specifically, timestamp-based key generation techniques are described. In some implementations, a table of key generation processes is provided that is shared as a secret key between a first computer system and a second computer system, both of which have two clocks. The first clock is a real-time clock and the second clock is a variable-time clock. The variable-time clocks are synchronized and run at the same rate, either faster or slower than real time. Both computer systems use the same technique to select a key generation process from the table, for example, based on a random number generator seeded with a timestamp obtained from the variable-time clock. Because the computer systems have synchronized variable-time clocks, they both select and use the same key generation process to generate the same encryption key without the need to communicate the key from one system to the other.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 17 / 233,429, filed April 16, 2021, the entire contents of which are incorporated herein by reference.

[0002] This disclosure relates to methods, techniques and systems for computer security, and in particular to generating a shared key based on two separate clocks, one of which may run faster or slower than real time. [Background technology]

[0003] Encryption techniques are divided into symmetric and asymmetric cryptography. Symmetric cryptography involves the use of a shared key (a shared secret key) that is used to convert data into and out of an obfuscated form known as encrypted data or ciphertext. That is, the same key is used for encryption and decryption. The problem with symmetric encryption techniques is that they require the first exchange of the shared key, which is itself vulnerable to security breaches. Another drawback associated with symmetric encryption is that the key cannot be easily changed, especially if the exchange is performed offline (not over a network).

[0004] Many encryption algorithms in use today, such as RSA, use some form of public-private key pairing to securely share data, packets, etc., between computer systems to sign and subsequently verify digital signatures, etc. These algorithms are commonly known as asymmetric encryption algorithms because the key used to encrypt the data is different from the key used to decrypt the data. These algorithms rely on the use of two keys: the recipient's public key, which is publicly known and used by the sender to encrypt the information, and the recipient's private key, which is private and secret, used to decrypt the information encrypted by the public key. Anyone who has a particular recipient's public key can encrypt a message that is to be sent to that person. The message can then only be decrypted by the recipient using his or her own private key (which he or she keeps secret at all times).

[0005] Problems with public and private key encryption technology are that keys generally have long lifetimes and are tightly tied to a particular user or entity. Obtaining a new key pair is not always easy. Also, if an entity loses its private key, it will not be able to decrypt data encrypted by that public key. Furthermore, asymmetric encryption is inherently "one-way" - only those with the private key (usually a single party) can encrypt data. This means that multiple key pairs must be used to achieve two-way communication. Finally, such technology may require infrastructure to create, manage, and retrieve keys. This additional infrastructure may itself be subject to security concerns.

[0006] The primary use of these encryption techniques is to protect data during its transmission from one computer system (device, environment, etc.) to another, and / or to digitally "sign" data so that the recipient can verify that the source of the data is from its claimed source. Using symmetric or asymmetric encryption, the transmitted information is transformed into a format that is difficult to read. This, hypothetically, prevents hackers and other malicious parties from illegally accessing the transmitted encrypted data (ciphertext).

[0007] However, a key is only as secure as the security provided by that key. The security of a key can be increased by the number of bits used to generate the key. For example, an encryption system with a 2048-bit key is computationally more difficult to crack using brute force techniques (trial and error of all combinations) compared to a system with a 1024-bit key. Thus, rather than attempting to decrypt encrypted data using brute force techniques (trying all possible keys), hackers and other malicious parties attempt to expose flaws in the underlying algorithms used to generate the keys.

[0008] To keep transmitted information more secure, some implementations of public key cryptography (such as SSL and TLS) use certificates and certificate authorities to ensure that a communication (e.g., a page served by a server) can be verified as being associated with a currently valid certificate, which is associated with a server that has been previously verified by the certificate authority. After verification, these systems generate a shared session key and may then use any desired encryption technique to encrypt data transmitted between the systems.

[0009] Additionally, some systems use a combination of asymmetric and symmetric encryption. For example, public key encryption techniques may be used to transmit a shared session key (shared secret key) that is encrypted using the recipient's public key. For example, in an exemplary "hybrid" system, the intended recipient's public key may be used to encrypt a new shared key generated by the sender. The generated shared key can then be obtained (decrypted) by the recipient (using the recipient's private key) and used for a symmetric encrypted data transmission where the encryption key, decryption key and algorithms are the same on both sides of the transmission. Often the shared (symmetric) key is session-based and is discarded after the session is over. [Brief description of the drawings]

[0010] [Figure 1A] FIG. 1 is a block diagram illustrating a key generation environment according to an exemplary embodiment. [Figure 1B] FIG. 1 is a block diagram illustrating a key generation environment according to an exemplary embodiment. [Figure 2A] 1 is a flow chart illustrating a key generation process according to an exemplary single-clock embodiment. [Figure 2B] 1 is a flow chart illustrating a key generation process according to an exemplary single-clock embodiment. [Figure 3A] 1 is a flow chart illustrating a key generation process according to an exemplary dual clock embodiment. [Figure 3B] 1 is a flow chart illustrating a key generation process according to an exemplary dual clock embodiment. [Figure 3C] 1 is a flow chart illustrating a key generation process according to an exemplary dual clock embodiment. [Figure 3D] 1 is a flow chart illustrating a key generation process according to an exemplary dual clock embodiment. [Figure 4] FIG. 2 is a block diagram of a participant's computer system implementing a shared key generation module according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] The embodiments described herein provide methods, devices and systems for computer security, and in particular provide a timestamp-based key generation technique for use in encryption and other data processing, without relying on predefined shared keys, shared key exchange, public / private key generation or certificates of devices. Using the described techniques, there is no need to exchange or persistently store shared keys.

[0012] The described technology addresses many of the shortcomings of prior art encryption methods, in that at least one key is required to configure a cryptosystem. This key may be predefined, a public and private key, or it may be a certificate that itself contains the public key if the owner has the private key. Thus, such systems are vulnerable to hackers or disgruntled employees who may steal the key and compromise system security. Also, certificates typically have a long validity period, lasting for several years, because it is very difficult to distribute the certificates to all parties and then coordinate the dates to switch to using a new certificate. If the private key associated with the certificate is stolen, the impact is long-lasting. The described invention involves a new encryption process that does not store the key anywhere in the system. Currently, a hacker or disgruntled employee cannot steal the key and compromise security as in prior art.

[0013] The described invention is based on timestamps obtained from one or more time sources. In one embodiment, the timestamps are obtained from synchronized clocks (e.g., synchronized to a time server). These timestamps are manipulated (typically via random number generators and other mathematical methods) to generate new shared keys for encryption / decryption. Thus, two machines using synchronized clocks and synchronous manipulation techniques can generate the same shared key and use that same shared key to secure a communication channel.

[0014] In a typical embodiment, the time server does not use a standard GMT clock. More importantly, the clock of this time server can run at its own speed that is not defined by the International System of Units. Security can be maintained by one or more of the following features: restricting access to the time server, running the time server at a speed different from (or offset from) the standard time, and having timestamp manipulation techniques (such as a random number generator). Furthermore, this new shared key can be generated as many times as desired. This makes it very difficult to decrypt the data using brute force attack methods. Furthermore, there is no need to use a secure session between computer systems to exchange a new shared key.

[0015] Exemplary embodiments provide an encryption method that utilizes a key generation process that is secure for use with a symmetric encryption algorithm to encrypt / decrypt data / ciphertext. Part of the key generation process itself, e.g., the method for determining which key generation process to select, is configured to be shared among the participating systems, such that the entire process generates the same shared key at each participating system based on a synchronized timestamp. Because the timestamp is the same and the selected key generation process is the same for each participant, the generated key is the same and can be used as the "shared" key.

[0016] An important difference between the described technique and known techniques that require key exchange, or alternative methods such as public / private key (asymmetric) encryption or certificate-based methods, is that each participant system is responsible for generating its own shared key and does not require key exchange. Furthermore, the shared key can be changed (generate a new key) frequently, such as at specific times, at intervals, or per transaction, or after several uses of the shared key. As long as the timestamps of each participant system are synchronized (same within error), the mechanism for selecting which shared key generation process to use is the same, the shared key is calculated by each participant simultaneously, and the resulting generated key can serve as the shared key.

[0017] In overview, a table of shared key generation processes (methods, algorithms, formulas, equations, etc.) that manipulate timestamps to generate shared keys is shared (the same) among the participant systems / users. The key generation process selection method that determines which key generation process entry in the table to use for a particular (potentially next) transaction is a shared secret among the participant systems. For example, this shared secret may be set by an authorized user / administrator of the participant system at system initialization or at some other time.

[0018] Each participant system then separately determines (for its own system) which shared key generation process entry in the table to use to generate a shared key based on the same key generation process selection method, which generates a number used to index the shared key generation process table. Because the same key generation process selection method is used and the table of shared key generation processes is the same, each participant system generates and uses the same index number. Based on this determined index, the next key generation process entry is looked up in the table and applied to a timestamp obtained from a local clock (which is the same because it is synchronized to each participant) to generate a shared key that can be used with existing or future encryption algorithms (or other processes) to encode and decode data transmissions.

[0019] The timestamps used are typically of the form described in U.S. Patent Application No. 16 / 220,652, filed December 14, 2018, entitled "Time-Based Authentication," and U.S. Patent Application No. 16 / 359,962, filed March 20, 2019, entitled "Time-Based Authentication with Redirection," the entire contents of which are incorporated herein by reference. As described herein, these timestamps are synchronized and determined locally to each system and are based on each system's local clock (hardware or software). This local clock is synchronized from a network-accessible time server or other source such as a radio clock signal or global positioning system. For the highest level of security, a private time provider / server can be used for all synchronized participants' clocks. This private time provider does not need to use a standard GMT clock. Furthermore, the clocks can be run faster or slower because their clock speed (rate) does not need to conform to the International System of Units. In this case, it becomes very difficult for an attacker to determine the current time or guess future times on the participants' clocks. Furthermore, the format and precision of the timestamps used by the participating systems may also be configured as a shared secret between them or may be set in advance.

[0020] An exemplary shared key generation process may apply functions and / or constants to the timestamp value, with a virtually infinite number of such methods, such that an unauthorized party cannot access the generated shared key without knowledge of the key generation process selection method and the timestamp used to generate the shared key. Thus, the described technique enhances key generation for use with symmetric encryption algorithms, but does not require a separate transaction (e.g., using public key cryptography) to exchange a session key or other symmetric key, nor does it require the validation of a certificate or certificate (or other token) before exchanging a symmetric key or asymmetric public key encryption pair. Thus, all of the benefits of symmetric key cryptography, such as the speed of the encryption / decryption process, can be achieved without the inherent vulnerability of first exchanging a shared key between participating systems before sending the ciphertext for decryption.

[0021] The described techniques thus improve upon the prior art, for example by improving the operation, integration, or efficiency of one or more computer systems. In particular, the described techniques address shortcomings of current approaches to computer security. Using the described techniques, it becomes more difficult for malicious computer systems to infiltrate secure services, systems, or networks. The described techniques limit access to only those computers or devices that have been configured with the appropriate key generation process.

[0022] 1A is a block diagram illustrating an environment for practicing a first exemplary embodiment of the shared key generation technique described herein. In FIG. 1A, system 101a includes a first participant computer system "A" 10, a second participant computer system "B" 60, and a time server 62. Participant computer system 10 includes an encryption module 100, a key generation module 140, and a table (or similar collection) of key generation processes 120 that are used by key generation module 140 to generate a shared key. Participant computer system 60 also includes an encryption module 100, a key generation module 140, and a table (or similar collection) of key generation processes 120 that are the same as the selected key generation process 120 of participant system 10 and that are used by key generation module 140 to generate a shared key. In some embodiments, key generation process table 120 may also include configuration data such as other processes or cipher suites.

[0023] As an overview, systems 10 and 60 in some embodiments communicate securely as follows. First, participant computer system 60 and participant computer system 10 are arranged to interact over a secure service or network, which may be provided, for example, by a company, university, or other organization. When each participant computer system is initially configured (e.g., when unboxed and configured for its user), an administrator or other privileged user stores or otherwise configures each computer system with the illustrated modules, including key generation process table 120. This may be done manually, such as by loading the modules and data via a thumb drive or other media. In other embodiments, the modules and data may be transmitted to each participant computer system over a secure channel, such as a network that is not connected to the outside world.

[0024] Second, each system synchronizes its internal clock with a private time server, such as time server 62. The private time server is accessible only by system 10, 60 and possibly by other authorized systems. Access to the private time server can be controlled by various known techniques, such as virtual private networks, physical network restrictions, whitelists, etc. In one embodiment, the private time server includes a whitelist of authorized computer systems, which includes machine identifiers, such as IP addresses, hardware identifiers, etc. The private time server need not (and typically does not) follow standard clock time. For example, the private time server may run 23 minutes behind standard time. Also, the time held by the private time server may be faster or slower than standard time. For example, the private time server's time may run 10% faster, so that for every minute of real time that passes, the private time server's clock advances 66 seconds. If the system fails to synchronize with the time server, in some embodiments, the system enters a self-protection mode in which it takes steps to protect information about or access to the system, such as by locking out users, sending distress messages, encrypting or erasing data, etc.

[0025] Once the participant computer systems have synchronized their clocks with the private time server, they generate a first shared key as follows: First, they obtain a timestamp from their system clock (which is synchronized with the private time server). This timestamp is used as a seed for a random number generator, provided to the system during initial configuration. The output of the random number generator is used to generate an index into a table of key generation processes 120. The key generation module 140 then generates an encryption key using the selected key generation process 120.

[0026] Because systems 10 and 60 are both synchronized to the same private time server and use the same random number generator, they will select the same key generation process (and therefore generate the same key) as long as, during operation, both systems use timestamps that are equal within some interval of precision (minutes, hours, days, etc.). To ensure that the systems use the same timestamps, a key generation schedule is configured for each system, which tells the systems when new keys should be generated. In an exemplary embodiment, the schedule indicates that new keys should be generated every hour. For example, at 7:00 AM, each system obtains and uses its timestamp to select a key generation process. Each system uses the timestamp (or a portion of it) as a seed for its random number generator to create an index into the key generation process table 120. The selected key generation process is used to generate a key. Then, assuming system 10 begins communication at 7:15, system 10 will encrypt data sent to system 60 using the key generated at 7:00 AM. Because system 60 is running the same process, it will generate the same key and therefore be able to decrypt data received from system 10.

[0027] An alternative approach is to not generate the key until communication begins. Thus, for example, if system 10 begins communication at 7:23 AM, the system obtains a timestamp, takes the truncated time of the timestamp (7:00 AM), and uses this value as a seed for a random number generator to create an index into key generation process table 120. The selected process is used to generate a key to encrypt the data sent to system 60. System 60 can run the same process using 7:00 AM as the truncated timestamp to look up the same key generation process used by system 10, generating the same key, which can then be used to decrypt the received encrypted data.

[0028] In a typical embodiment, the key generation process 120 takes a timestamp as input and outputs a number based on the timestamp. This number is the generated shared key. An exemplary process may be expressed as K=a*timestamp+b, where a and b are constants stored as part of the key generation process table 120. In some embodiments, the constants a and b are fixed or static parts of the process, while in other implementations the constants are configuration data specified when the key generation process is selected or stored. In other embodiments, other or additional operators (e.g., subtraction, exponentiation, modulo, etc.) may be used to calculate the output based on the timestamp. In some embodiments, the constants a and b themselves are determined based on the output of a random number generator seeded with the timestamp, a previously stored value, or a combination thereof. This makes it more difficult for an attacker to guess the details of the key generation process.

[0029] In some embodiments, each participant computer system, such as participant computer system 10 and participant computer system 60, generates a shared key as follows: First, the participant computer system obtains a timestamp reflecting the current time from a hardware or software clock. The clock is typically local to the participant system, but in some embodiments the clock may be a network-accessible time server or may be synchronized with a private network time server as described above. The participant computer system then applies a selected key generation process 120 to the timestamp to obtain a number to be used as the shared key. For example, if the timestamp is 1544512669 and process 120 applies the function K=34*timestamp+54543, the resulting value is 52513485289. This value is then the shared key, and is shared because another participant computer system determined the same key using (independently) the same process of selecting a key generation process, the same selected key generation process 120, and the same timestamp. The shared key can then be used to process and transmit secure (encrypted) data between the participant computer systems.

[0030] Each participant computer system may also perform steps to ensure the generation of a key of a given size. For example, if a 2048-bit key is used, the system may manipulate the timestamp (or a portion thereof) to generate a 2048-bit data value, and then process this data value through the key generation process. As a simple example, the system may repeat a 64-bit timestamp 32 times to generate a 2048-bit value, and process this value through the key generation process. Of course, the timestamp may be divided, repeated, inverted, XORed, or otherwise manipulated in various ways as it fills the 2048-bit base value. In some embodiments, the exact process of converting the timestamp to the base value is specified by the key generation process itself, such that each key generation process uniquely converts the timestamp to a 2048-bit value and then uniquely manipulates this value (e.g., by multiplication, addition, subtraction) to generate the shared key.

[0031] In a typical embodiment, all participant computer systems use the same process to select a key generation process such that all participants use the same key during a given time interval. In some embodiments, a particular computer system may "participate" in secure transactions with multiple other computer systems (participant groups), such as broadcasting encrypted messages, and therefore stores and associates a separately associated key generation process selection method with each other participant in the group. Thus, when a particular computer system is instructed to generate a shared key for one or more transactions with another particular computer system, it must first select a key generation process 120 specific to that participant group before generating the shared keys to be used in those transactions. A participant group may include one or more participant computer systems, and may include more than two participant computer systems, provided that the shared key is accessible by all participants. A different key generation process can be used for each participant group, since each computer system typically has a table (list, file, database, etc.) that maps the other participants to their respective process selection methods.

[0032] In some embodiments, this table maps a participant's immutable device / user identifier (e.g., MAC address, CPU identifier, or some combination thereof) to an identifier of the process selection method. Each participant computer system in a group of participant computer systems receives the device identifier as part of the initialization data, via a separate network transmission, or as part of an initial network handshake or other network protocol related operation.

[0033] Participant computer systems, such as systems 10 and 60, may decide to generate shared keys to be used for one or more data processing transactions at different times. If both systems follow the same process described herein (using synchronized clocks), they will naturally generate matching keys and will not require key verification or rekeying. For example, if a schedule indicates that a new key is to be generated every hour, one system may generate a key later than another system because it was powered on after that time. If both systems are configured to use a timestamp truncated to the hour (without minutes, seconds, etc.), then one system will select and use the same key generation process even if it is slower than the other system. In some embodiments, the participant systems may exchange optional test data processing transactions (such as test encryption / decryption sequences) to determine if each participant system has the same generated key. If not, the shared key generation process may be repeated until a usable shared key is generated.

[0034] Typically, the time servers used by the participant systems can ensure that the clocks are synchronized to a very high degree of accuracy (e.g., better than a millisecond). Nevertheless, in some embodiments, the key generation process 120 used by each participant system may reduce the accuracy of the timestamp to a larger time interval. A similar reduction in accuracy must be performed at initial system setup. This reduction may therefore be predefined during initial setup between participant systems. For example, if the timestamp is expressed in seconds, the key generation process 120 may round the timestamp to the nearest 10-second interval (e.g., by stripping off the ones digit). Also, to account for timestamps that transition across time interval boundaries, the system 10 may apply the key generation process 120 to timestamps that reflect the current and previous time intervals. As an example, assume that the timestamp obtained by the first participant computer system 10 is 1239 and that the key generation process strips off the ones digit before applying its function. Using K=34*modified timestamp+42, we get 34*123+42=4224. If the timestamp obtained by the second participant computer system 60 is one second later (1240), the computer system 60 will generate K=34*124+42=4258, which does not match the shared key of computer system 10. However, if computer system 60 also attempts to calculate the shared key using a less precise timestamp (123 without the ones digit), it will get a number (34*123+42=4224) that matches the shared key of computer system 10. In other embodiments, multiple shared keys are calculated using the current timestamp, a timestamp based on a previous interval, and / or a timestamp based on the next future time interval. If the calculated keys then succeed in processing the test data, the computer system has a valid shared key. If not, other steps may be taken to first synchronize the clocks of the participant systems. Other modifications are possible as well.

[0035] Each system may select a new key generation process from time to time or upon the occurrence of an event. Changing the key generation process makes it more difficult for a malicious actor to recover the number generation function central to the described technology. For example, the participant computer system 60 may select a new key generation process selection method after every n transactions, after the passage of time (e.g., 1 minute, 1 hour, 24 hours), or on a fixed date (e.g., January 1, 2020). In some embodiments, each system stores a table or similar data structure representing multiple refresh intervals. Each time a key generation process is selected, a new refresh interval is also selected from the table. The refresh interval may be selected in a manner similar to the key generation process, such as a random number generated based on a timestamp.

[0036] Similarly, new shared keys may be generated between participant computer systems from time to time or upon the occurrence of an event. For example, participant computer system 60 may generate a new shared key (using a previously selected key generation process) after every n transactions, at a fixed date (e.g., January 1, 2020) after the passage of time (e.g., 24 hours). Changing the shared key makes it more difficult for a malicious actor to recover the number generation function that is central to the described technology.

[0037] In some embodiments, the details of the different key generation processes 120 may be public. In such embodiments, the table 120 typically hosts a large number (e.g., millions) of key generation processes, so that a malicious actor cannot try them all in a brute force attack. In such "semi-public" embodiments, secrecy can be maintained by one or more of: (1) using private time servers; (2) keeping the process selection method (e.g., the random number generator used to select the process) secret; and (3) keeping the key generation schedule secret. Also, or alternatively, each key generation process 120 may utilize configurable constants or other inputs that can also be kept secret among the group of participants. In some embodiments, the key generation process itself is private. To maximize security, the key generation process is shared only among machines and systems within an organization. For example, a company can establish a secret set of key generation processes that are used only for the purpose of exchanging encrypted data between employees' devices. This set may be stored in a secure shared repository or directly loaded into each device.

[0038] In some embodiments, the described techniques are used to generate shared keys for users and their devices in the context of a corporate or organizational network. In other contexts, the techniques can be used in the context of online web-based services. First, the client machine needs to be synchronized with a public time server so that the web server has the same clock as the client machine. In such an embodiment, every time a user signs into a web service, the server needs to create a new table of key generation processes for this user and then share this new table. The service then initiates the generation of a new shared key with the server and the client device. The user's client device maintains a table that maps web services to key generation process selection methods, so that the correct selection method can be used to select a shared key generation process based on the web service the user is accessing. Furthermore, as mentioned above, these techniques can be combined with other techniques that use a device identifier (such as a MAC identifier or a CPU identifier) ​​to verify the identity of the device when accessing a secure system. Such technology is described in U.S. Patent Application Publication No. 2018 / 0146001, filed November 22, 2016, and entitled “Network Security based on Device Identifiers and Network Addresses,” the entire contents of which are incorporated herein by reference.

[0039] It should be noted that while timestamps are sometimes described herein as integers, they may be represented differently in other embodiments. For example, in some embodiments, a timestamp may be represented as having component parts or fields that refer to logical time and date elements. Thus, rather than using only a single large (e.g., 64-bit) number that represents the number of seconds or milliseconds since a shared starting point (the epoch), a timestamp may additionally or alternatively include fields that represent the year, month, day, hour, second, and microsecond. Such a timestamp may represent the date time of 5:32:19 PM on April 23, 2020 as 20200423173219, where the digits represent year, month, day, hour, minute, and second, in that order. Such record-based timestamps may be combined with epoch-based timestamps, such as 202004231732191587627139, where 1587627139 represents the number of seconds since January 1, 1970 ("Unix time").

[0040] It should be noted that there is virtually no limit to the number of different key generation processes that may be created and / or used. Some embodiments provide multiple (e.g., millions) of different key generation processes, different subsets of which may be used by different companies, organizations, etc. This allows each organization flexibility and independence relative to other organizations. Thus, each organization may implement its own policies for the selection, replacement, and updating of key generation processes.

[0041] It should be noted that the described shared key generation technique can be performed without user intervention. In particular, the key generation module can automatically apply the appropriate key generation process without user intervention and use the resulting number (possibly together with other cached login credentials or tokens) to securely encrypt / decrypt or otherwise process data, etc. In this manner, the technique can be completely transparent to the user. Furthermore, the technique may be implemented at different levels of the protocol stack in different embodiments. For example, in one embodiment, key generation may be performed at the application layer in response to a transaction, such as over an HTTP connection. In another embodiment, key generation may be performed at a lower layer, such as layer 2 (data link) or layer 3 (network).

[0042] It should be noted that while key generation processes are typically described herein as taking a timestamp as an input, other types of key generation processes are contemplated. For example, some key generation processes may take only a portion of a timestamp as an input. Other processes may take as input a number based on a timestamp, such as the index of the key generation process in a table of processes. Combinations of inputs are also contemplated, including a timestamp combined with a network identifier or portion thereof.

[0043] FIG 1B is a block diagram illustrating an environment for practicing a second exemplary embodiment of the shared key generation technique described herein. FIG 1B illustrates a system 101b similar to the system 101a described with respect to FIG 1A. System 101b also includes a participant computer system 10, a participant computer system 60, and a time server 62. Each computer system 10 and 60 also includes an encryption module 100, a key generation module 140, and a table of key generation processes 120 that the key generation module 140 uses to generate a shared key.

[0044] In system 101b, computer system 10 and computer system 60 each include two clocks. For example, computer system 10 includes real-time clock 150 and variable time clock 151. In a typical embodiment, clocks 150 and 151 are hardware clocks, but may additionally or alternatively be implemented at least partially in software or as programmable logic (e.g., field programmable gate arrays). Variable clock 151 is typically a hardware clock that operates at a different frequency than clock 150. The frequency of clock 151 can be controlled and changed using direct digital synthesis techniques. In direct digital synthesis, the output of a reference oscillator is input to a numerically controlled oscillator and changed. The waveform output by the numerically controlled oscillator becomes the reference for the time kept by the second clock. In other embodiments, different or additional techniques can be used to manipulate and / or control the speed at which the second clock operates. For example, a constant time offset may be added to the output of variable clock 151.

[0045] As shown in FIG. 1A, computer system 10 and computer system 60 initially synchronize their clocks with time server 62. More specifically, each real-time clock 150 is initially synchronized with time server 62. Time server 62 may be a public or private time server. Then, each variable clock 151 is synchronized with its respective local real-time clock. From that moment on, variable clock 151 starts to run at a speed different from that of real-time clock 150. Variable clock 151 of each computer system runs at the same speed as real time, faster or slower than real time. The speed may be preselected or dynamically generated, such as via a random number generator. Also, the speed may be changed from time to time or upon the occurrence of some other event, message, command or control signal.

[0046] Each of the participant computer systems then generates a shared key by obtaining a timestamp from the variable clock 151. The computer systems then look up the key generation process in table 120 based on the timestamp. As previously described, the timestamp may be used as an input to a random number generator that is used to obtain an index into table 120. The selected key generation process is then used to generate an encryption key. The keys generated by systems 10 and 60 are the same (symmetric) because both systems initially synchronized their clocks to the same time and their respective variable clocks 151 run at the same speed. New keys may be generated on a periodic schedule (e.g., hourly, daily) or at some other determined series of points in time, such as a list of randomly generated future times stored by each of systems 10 and 60.

[0047] The variable clocks 151 may also be changed, adjusted, or resynchronized based on a schedule. For example, at a set time (e.g., 5:00 a.m.), the frequency of each variable clock 151 may be changed so that the variable clocks 151 run faster or slower than in the previous time interval. In some embodiments, the variable clocks 151 may be resynchronized with the real-time clock 150 at that moment. The adjustment schedule need not be fixed. In some embodiments, the interval between clock adjustments is a predetermined random interval. In other embodiments, the length of each interval is randomly generated on the fly (e.g., if both systems 10 and 60 use the same random number generator) so that a schedule does not need to be stored.

[0048] The dual clock technique described herein offers several advantages over the use of a single clock. In a single clock approach, if each participant computer system uses a clock that runs faster or slower than real time, then these computer systems cannot rely on public standard time servers to synchronize their clocks. Because the computer systems need a common source of real time so that they can synchronize, they must rely on private time servers that run faster or slower than real time. Time servers also present a security weakness because hackers may attempt to obtain the time or disrupt its operation, such as through a denial of service attack. In a dual clock approach, private time servers are not required because each system has a real time clock that can be synchronized to any standard time server. This real time clock serves as the source of real time for each computer system. The real time clock can be used for other time-based functions of the computer systems and can also be used as a basis for synchronizing or modifying the operation of the variable clocks. Thus, the dual clock approach provides a higher level of security while simplifying the implementation of the overall system.

[0049] 2A and 2B are flow charts illustrating a process for generating a shared key at an exemplary participant computer system, according to an exemplary single-clock embodiment. FIG 2A is a flow chart illustrating a first process for generating a shared key at an exemplary participant computer system, according to an exemplary embodiment. The logic illustrated in this flow chart may be performed, for example, by key generation module 140 described with respect to FIG 1A or 1B above.

[0050] At block 202, the process synchronizes the clocks at the participant computer systems. As previously mentioned, the clocks may be synchronized by accessing a network time server, a GPS system, or by other known processes. To preferentially provide a higher level of security, the process synchronizes its clocks with a private time server accessible only by devices and systems operated by a given organization (business, school, etc.). The time maintained by a private time server may also run faster / slower than real time, or may be offset from real time by a certain amount, and therefore may not track real time.

[0051] In block 204, the process obtains a timestamp from the clock. Typically, the process makes an appropriate operating system call to access the system time. Instead of using a synchronized local clock, in some embodiments the process may obtain the timestamp directly from a shared clock, such as the network time server mentioned above.

[0052] At block 206, the process selects a key generation process from a pre-shared set of key generation processes. As discussed herein, each participant system may be provided with a table, list, or other set of key generation processes. In an exemplary embodiment, the process uses a timestamp to select a key generation process from the table of key generation processes. For example, if there are N entries in the table, the process may index the table using index=timestamp modulo N. As another example, the process may use a random number generator seeded with the timestamp to generate random numbers used to index the table (e.g., index=random(timestamp) modulo N, where N is the number of entries in the table). In other embodiments, the key generation process may be selected based on other or additional information, such as an identifier of the recipient machine (received alone or in combination with the timestamp).

[0053] In block 208, the process applies (e.g., runs or executes) the selected key generation process to the obtained timestamp. In other embodiments, the process uses a second timestamp different from the one used to select the key generation process. The second timestamp may be obtained at the beginning of communication with the remote system, while the initial timestamp (used to select the key generation process) may be obtained some time earlier. As previously mentioned, the key generation process is typically a function that takes a timestamp as input and generates an output that can be used as a cryptographic key. The key generation process may specify one or more mathematical operators and constants to be applied to the input key. As an example, the key generation process may be expressed as a function f(timestamp)=A*timestampB+C, where A, B, and C are constants, e.g., 123, 23, and 34223. To generate a key with a sufficient number of bits, in some embodiments, all or part of the timestamp (or the key generated from the timestamp) may be repeated to fill the required number of bits. The manner in which the timestamp is repeated and / or manipulated may itself be specified by the key generation process. For example, one key generation process may specify that a 64-bit timestamp be duplicated 32 times to produce a 2048-bit value. During this padding process, other operations may be performed, such as using only a subset of the available bits, flipping bits, shifting bits, etc.

[0054] In block 210, the process optionally processes data using the generated key. For example, the process may encrypt data using the key and then send the encrypted data to a remote receiving computer system. This receiving computer system will generate the same key, since it used the same described process to select a key generation process to generate the key. The receiver can then use this key to decrypt the received encrypted data. Note that the two systems never transmit any information about the key generation or the key itself. This feature combined with periodic key changes makes it very difficult for hackers or other malicious parties to decrypt encrypted communications.

[0055] In some embodiments, each participant is provided with a fixed set of data / code used to implement the described functionality. The data / code may include: (1) an array or table of the key generation process (or parameters used in the process), (2) a random number generator (or its parameters), (3) a timestamp format specifying the size and placement of fields (if any) in the timestamp and taking into account the precision of the timestamp, (4) a specification of the size of the key and how to manipulate (e.g., repeat, duplicate, reverse) the timestamp or the output of the key generation process to pad out the key size, and (5) data specifying when or how often to generate a new key.

[0056] 2B is a flow chart illustrating a second exemplary process for generating a shared key, according to an exemplary embodiment. The logic illustrated in this flow chart may be performed, for example, by key generation module 140 described with respect to FIG. 1A or 1B above.

[0057] In block 252, the participant computer system receives an indication of a shared key generation process selection method. The output of the method is an index into a table (data store) of key generation processes. Typically, each participant computer system in a group is assigned the (same) key generation process selection method upon initialization, such as when a client computer system is deployed in an organization that is using the described security mechanism. A key generation process selection method is a function, code block, or similar logic that provides a numerical result as an output.

[0058] In one case, the index into the key generation method table is calculated by a shared method selection formula that uses a pseudorandom number, which may be seeded based on the timestamp of each participating system (e.g., a 64-bit integer to the nearest second, minute, hour, etc., accuracy) as the "seed" for the generation of the random number, adding another degree of security to the calculation.

[0059] At block 254, the participant computer system obtains the timestamp generated by a synchronized clock local to that computer system, for example, by making an appropriate system call to obtain the timestamp from the system clock. The system clock of each participant computer system is synchronized with a central time server. As previously mentioned, various time sources may be used to establish precisely or substantially synchronized system clocks, e.g., network time servers, GPS, radio time signals, etc. In some embodiments, instead of using a system clock, the participant computer system may obtain the timestamp directly from a network-accessible source, such as a network time server.

[0060] At block 256, the participant computer system determines an index into the key generation data store 120 by executing the indicated selection method. The data store typically contains an indexed table that contains multiple key generation processes. As previously mentioned, the timestamp may be used to seed a random number generator to determine the index used to select a process from the table.

[0061] In block 258, the participant computer system determines (selects, searches, retrieves, identifies) a selected key generation process from the shared key generation data store based on the determined index. The participant computer system can determine the key generation process in a variety of ways. The participant computer system may look up the key generation process based on the index or may use the index as a hash into a table. In some embodiments, the key generation processes are public. In other embodiments, the set of key generation processes is kept private by the organization.

[0062] In block 260, the participant computer system applies the obtained key generation process to the timestamp obtained in block 204 to generate a new (shared) key. In an alternative embodiment, the key generation process is applied to the newly received timestamp. The generated value serves as the shared key when another participant computer system generates the same exact key using the same logic performed by this process.

[0063] Block 260 includes applying an operator to the timestamp and an integer, where the operator and the integer are specified by the determined key generation process. A typical key generation process operates on the timestamp and at least one other integer using one or more operators. An exemplary process may be expressed as k=a*timestamp+b, where k is the output number and a and b are constants. The constants may be hard-coded into the key generation process. In other embodiments, the constants a and b may be calculated by the key generation process itself to provide a more versatile process, and thus replicable by other participant computer systems. These constants may be provided to the key generation module of the participant computer system along with the instructions of the key generation process itself, if not provided by the key generation process itself. Note that in some embodiments, the key generation process may reduce the precision of the timestamp, for example by rounding or truncating the time to a predetermined time interval (e.g., to the nearest second, to the nearest 10 second window, to the nearest minute). This technique can be used to account for clock drift, communication delays, and / or small differences between the clocks of the participant computer systems.

[0064] Optionally, in block 262, the participant computer system processes some data using the shared key. For example, this may be to send an encrypted message that is decrypted by the participant computer system using its (its) generated shared key. In an optional embodiment, this may be a test transaction to ensure that the key generation process has generated a workable shared key.

[0065] Optionally, in some embodiments, the logic of this process may be initiated to generate new keys after a period of time (e.g., daily, weekly, etc.), in response to various events / conditions, such as on or after a specified date, based on transactions, etc. The logic of this process is also executed by each participating computer system in a participant group to generate the shared keys.

[0066] 3A is a flow chart of exemplary logic in a first computer system for securely communicating with a second computer system. The illustrated process may be performed by cryptographic module 100, and possibly in conjunction with one or more components of computer system 10 described herein. FIG 3A shows process 3A00, which includes blocks 3A01-3A06, which are described below.

[0067] Block 3A01 includes synchronizing a first clock with a clock maintained by a time server, the first clock being part of the first computer system and operating on standard time. Typically, the first clock is a hardware clock that is part of the first computer system. The first clock may be synchronized by accessing a network time server, a GPS system, or by other known processes. To preferentially provide a higher level of security, the process synchronizes the clock with a private time server that is accessible only by devices and systems operated by a given organization (business, school, etc.). In other embodiments, the first clock may be a network time server.

[0068] Block 3A02 includes synchronizing a second clock with the first clock, the second clock being part of the first computer system and running faster or slower than standard time. Typically, the second clock is a hardware clock that is also part of the first computer system. The second clock differs from the first clock in that it runs at a different frequency than the frequency of the first clock. The clock frequency can be controlled and changed using direct digital synthesis techniques. In direct digital synthesis, a reference oscillator provides a stable time reference for the clock. The output of the reference oscillator is provided to a numerically controlled oscillator, which outputs at its output a discrete-time quantized version of a waveform whose period is controlled by a frequency control value input to the numerically controlled oscillator. The waveform output by the numerically controlled oscillator becomes the reference for time kept by the second clock. In other embodiments, different techniques can be used to manipulate and / or control the speed at which the second clock runs.

[0069] Block 3A03 includes obtaining a first timestamp from a second clock. Typically, the process makes an appropriate operating system call to access the system time. Instead of using a synchronized local clock, some embodiments may obtain the timestamp directly from a shared clock, such as a network time server as described above.

[0070] Block 3A04 includes selecting a first key generation process from the key generation process data store based on the first timestamp, where each key generation process in the data store receives as input a timestamp and generates as output a number based on the input timestamp, the number suitable to function as a shared key for encryption purposes.

[0071] Block 3A05 includes executing a first key generation process to generate a first key. As discussed herein, each secure system may be provided with a table, list, or other collection of key generation processes. In an exemplary embodiment, the process uses a timestamp to select a key generation process from the table of key generation processes. For example, if there are N entries in the table, the process may index into the table using index=timestamp modulo N. As another example, the process may use a random number generator seeded with the timestamp to generate random numbers used to index into the table (e.g., index=random(timestamp) modulo N, where N is the number of entries in the table). In other embodiments, the key generation process may be selected based on other or additional information, such as an identifier of the recipient machine (received alone or in combination with the timestamp).

[0072] Block 3A06 includes using the first key to decrypt a message received from a second computer system, which also executes a first key generation process to generate a first key and encrypts the message using the first key, and the first and second computer systems engage in encrypted communication without communicating an encryption key. This second computer system will generate the same key, since it used the same described process to select a key generation process and generate a key. The second computer system also uses this key to initially encrypt the message. Note that the two systems never transmit any information about the key generation or the key itself. This feature, combined with periodic key changes, makes it very difficult for a hacker or other malicious party to decrypt the encrypted communication.

[0073] Figure 3B is a block diagram of an example logic that extends module 3A00 of Figure 3A. More specifically, Figure 3B illustrates a process 3B00 that further includes the following blocks:

[0074] Block 3B01 includes modifying the operation of the second clock after synchronizing the second clock with the first clock. The operation of the second clock may be modified from time to time, such as by changing the frequency of the second clock or by resynchronizing with the first clock.

[0075] Figure 3C is a block diagram of an example logic that extends module 3B00 of Figure 3B. More specifically, Figure 3C illustrates a process 3C00 that further includes the following blocks:

[0076] Block 3C01 includes modifying the operation of the second clock at time intervals, each of random length. In some embodiments, the process uses a random number generator to determine the time intervals, at the end of which it modifies the operation of the second clock, such as by modifying the frequency of the second clock. The frequency change may be determined randomly. Because the random number generator used by the process is the same as that used by the second computer system, the second computer system simultaneously makes the same changes to its variable clock. The time intervals may be determined with respect to the first (real time) clock or the second (variable time) clock.

[0077] Figure 3D is a block diagram of an example logic that extends module 3A00 of Figure 3A. More specifically, Figure 3D illustrates a process 3D00 that further includes the following blocks:

[0078] Block 3D01 includes receiving one or more control parameters. In some embodiments, the process receives control parameters that specify the speed at which the second clock runs. These parameters are typically part of the initial configuration data, along with a key generation schedule and a table of key generation processes.

[0079] Block 3D02 includes controlling a numerically controlled oscillator to generate a waveform used for the second clock based on one or more control parameters. If direct digital synthesis is used, the control parameters may be used as inputs to control the frequency of the waveform generated by the numerically controlled oscillator. The control parameters may additionally or alternatively specify an offset to be added to the output of the clock.

[0080] Figure 4 is a block diagram of a participant computer system implementing a shared key generation module according to an exemplary embodiment. In particular, Figure 4 illustrates computer system 10 executing key generation module 140 using a key generation process selected from key generation process table 120 and encryption module 100 described above. Similar techniques may be applied to the implementation of other participant computer systems, such as computer system 60 described above. Furthermore, the shared key generation module, key generation selection method and / or selected key generation process may be implemented in software, hardware, firmware or some combination to achieve the functionality described herein.

[0081] Computer system 10 may include one or more computer systems and may span distributed locations. Also, each illustrated block may represent one or more such blocks as appropriate to a particular embodiment and may be combined with other blocks. Furthermore, the various blocks may physically reside on one or more machines that communicate with each other using standard remote procedure calls (e.g., RPC) or proprietary inter-process communication mechanisms (IPC).

[0082] In the illustrated embodiment, computer system 10 includes computer memory ("memory") 11, display 12, one or more central processing units ("CPUs") 13, input / output devices 14 (e.g., keyboard, mouse, CRT or LED display, etc.), other computer readable media 15, and network connections 16. Key generation module 140 is shown as residing in memory 11. In other embodiments, some of the content, some or all of the components of module 140 may be stored and / or transmitted to other computer readable media 15. Other modules, such as key generation process 120 and / or encryption module 100, may also be residing in memory 11. Module 140 preferably executes on one or more CPUs 13 and performs the techniques described herein. Other code or programs 30 (e.g., administrative interfaces, web servers, etc.) and potentially other data repositories, such as data repository 20, also reside in memory 11 and preferably execute on one or more CPUs 13. Of note, one or more of the components of FIG. 4 may not be present in any particular implementation. For example, in some embodiments, other computer readable medium 15 or display 12 may not be provided.

[0083] Key generation module 140 is shown executing in memory 11 of device 10. Memory 11 also includes a user interface manager 41 and an application program interface ("API") 42. User interface manager 41 and API 42 are depicted with dashed lines, indicating that in other embodiments, the functions performed by one or more of these components may be implemented outside of module 140.

[0084] The UI manager 41 provides views and controllers that facilitate a user's interaction with the module 140 and its various components. For example, the UI manager 41 may provide interactive access to the module 140 so that a user or administrator may interact with the module 140 to configure an initial key generation selection method or the key generation process data store 120 (e.g., if stored locally). In some embodiments, access to the functionality of the UI manager 41 may be provided via a web server, or in some cases, may be executed as one of the other programs 30. In such embodiments, a user operating a web browser executing on a client system or device may interact with the module 100 through the UI manager 41.

[0085] API 42 provides programmatic access to one or more functions of module 140. For example, API 42 may provide a programmatic interface to one or more functions of module 140 or some other module that may be called by one of the other programs 30. In this manner, API 42 facilitates the development of third party software, such as user interfaces, plug-ins, adapters (e.g., for integrating the functionality of module 100 into a web application), and the like.

[0086] Module 140 can interact with other devices / systems, including computer systems 60, 62 and 64, using network connection 16 via network 99. Network 99 may be any combination of media (e.g., twisted pair, coaxial, fiber optic, radio frequency), hardware (e.g., routers, switches, repeaters, transceivers), and protocols (e.g., TCP / IP, UDP, Ethernet, Wi-Fi, WiMAX) that facilitate communication between people and / or devices at remote locations. Computer systems 60, 62 and 64 may be configured similarly to system 10.

[0087] It should be noted that one or more general-purpose or special-purpose computer systems / devices may be used to implement and / or execute the modules 140. However, just because the modules 140 may be implemented in a general-purpose computer system does not imply that the techniques themselves or the operations required to implement the techniques (singly or in combination) are conventional or well-known. These techniques are not conventional because they at least address and improve upon existing techniques, such as by improving the operation, integration, or efficiency of one or more computer systems.

[0088] In an exemplary embodiment, the components / modules of module 140 are implemented using software programming techniques. For example, module 140 may be implemented as a "native" executable that runs on CPU 13 along with one or more static or dynamic libraries. In other embodiments, module 140 may be implemented as instructions processed by a virtual machine that runs as one of other programs 30.

[0089] The various components may be implemented using more monolithic programming techniques, for example as executables running on a single CPU computer system, or decomposed into client-server or peer-to-peer, each running on one or more computer systems having one or more CPUs, using various structuring techniques, including but not limited to multiprogramming, multithreading. In some embodiments, they may execute simultaneously and asynchronously and communicate using message passing, remote procedure calls, or other distributed computing paradigms. Equivalent synchronous embodiments are also supported. Other functions may be implemented and / or performed by different components / modules, in different orders, by each component / module, and still achieve the described functionality.

[0090] Also, programming interfaces to data stored as part of module 140, such as in data store 20, may be available through expression languages ​​such as XML, through language-specific APIs and libraries for accessing files, databases or other data repositories, or through a web server, FTP server or other type of server that provides access to the stored data. Data store 20 may be implemented as one or more database systems, file systems or any other technology for storing such information, or any combination of the above, including implementations using distributed computing technology.

[0091] Further, in some embodiments, some or all of the components of module 140 may be implemented or provided in other ways, such as at least partially in firmware and / or hardware, including, but not limited to, one or more application specific integrated circuits ("ASICs"), standard integrated circuits, controllers executing appropriate instructions, microcontrollers and / or embedded controllers, field programmable gate arrays ("FPGAs"), complex programmable logic devices ("CPLDs"), and the like. Some or all of the system components and / or data structures may be stored as content (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., a hard disk, memory, a computer network or cellular wireless network or other data transmission medium, or a portable media article read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) to enable or configure the computer-readable medium and / or one or more associated computer systems or devices to execute or use or provide the content to perform at least some of the techniques described. Some or all of the components and / or data structures may be stored on a tangible non-transitory storage medium. Some or all of the system components and data structures may be stored as data signals (e.g., by being encoded as part of a carrier wave or by being included as part of an analog or digital propagated signal) on various computer-readable transmission media, including wireless-based media and wired / cable-based media, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as a number of individual digital packets or frames). Such computer program products may also use other forms in other embodiments. Thus, embodiments of the present disclosure may be practiced with other computer system configurations.

[0092] Although the embodiments of the present invention have been illustrated and described above, many changes can be made without departing from the spirit and scope of the present invention. Accordingly, the scope of the present invention is not limited by the above disclosure.

Claims

1. 1. A method in a first computer system for securely communicating with a second computer system, comprising: synchronising a first clock, which is part of said first computer system and operates on standard time, with a clock maintained by a time server; synchronizing a second clock, which is part of the first computer system and which runs faster or slower than standard time, with the first clock; obtaining a first time stamp from the second clock; selecting a first key generation process from a key generation process data store based on the first timestamp, each key generation process in the data store receiving as input a timestamp and generating as output a number based on the input timestamp, the number being suitable to function as a shared key for encryption purposes; executing the first key generation process to generate a first key; using the first key to decrypt a message received from the second computer system, the second computer system also executing the first key generation process to generate the first key and encrypting the message using the first key, the first computer system and the second computer system engaging in encrypted communication without communicating an encryption key; A method comprising:

2. The method of claim 1 , further comprising the step of altering operation of the second clock after synchronizing the second clock with the first clock.

3. 3. The method of claim 2, further comprising the step of altering operation of the second clock at time intervals each of which is of random length.

4. receiving one or more control parameters; controlling a numerically controlled oscillator to generate a waveform used for said second clock based on said one or more control parameters; The method of claim 1 further comprising:

5. generating a random number based on a random number generator seeded with the first timestamp or a portion thereof; generating an index based on the generated random number; searching the key generation process data store for the first key generation process using the index; The method of claim 1 further comprising:

6. 2. The method of claim 1, wherein the first computer system and the second computer system each store a table of a key generation process, the table of the first computer system being identical to the table stored by the second computer system.

7. The method of claim 1 , wherein the first computer system is configured to select the second key generation process upon the occurrence of an event or upon the passage of time.

8. selecting a new key generation process every hour or every day; Get a new timestamp, and selecting the new key generation process from the key generation process data store based on the new timestamp; By steps The method of claim 1 further comprising:

9. 2. The method of claim 1, wherein the time server stores a whitelist including indicators of the first computer system and the second computer system, and wherein a private time server provides time only to computer systems identified by the whitelist.

10. The method of claim 1 , wherein the time server is configured to communicate only with computer systems that are part of a particular virtual private network.

11. The method of claim 1 , wherein the first key generation process identifies an operator and an integer and applies the operator to a timestamp and the integer.

12. 2. The method of claim 1, wherein the first key generation process multiplies the first timestamp by a first integer to obtain a first product value and adds a second integer to the product value to obtain a sum that is used as at least a portion of the first key.

13. 2. The method of claim 1 , wherein the first key generation process identifies manipulating an N-bit timestamp to generate an M-bit value, where M is greater than N, and the manipulation includes duplicating at least a portion of the timestamp.

14. 2. The method of claim 1, wherein the first computer system and the second computer system do not persistently store an encryption key that encrypts data transmitted between the first computer system and the second computer system, and no shared encryption key is communicated between the first computer system and the second computer system.

15. 2. The method of claim 1, wherein obtaining a first timestamp from the second clock comprises obtaining the first timestamp in response to receiving the message from the second computer system.

16. 2. The method of claim 1, wherein performing the first key generation process to generate a first key comprises applying the key generation process to a value that is reduced in precision by at least one order of magnitude from the first timestamp.

17. regenerating a shared key if the first computer system is unable to successfully decrypt the message. The method of claim 1 further comprising:

18. entering a self-protection mode in response to a failure to synchronize the first clock or the second clock with the time server, the self-protection mode including at least one of locking out users, sending a warning message, erasing data, and encrypting data. The method of claim 1 further comprising:

19. A first computer system, comprising: A processor; a first clock operating on standard time; a second clock that runs faster or slower than standard time; a memory storing instructions that, when executed by the processor, synchronizing said first clock with a clock maintained by a time server; synchronizing the second clock with the first clock; obtaining a first time stamp from the second clock; selecting a first key generation process from a key generation process data store based on the first timestamp, each key generation process in the data store receiving as input a timestamp and generating as output a number based on the input timestamp, the number being suitable to function as a shared key for cryptographic purposes; executing the first key generation process to generate a first key; and using the first key to decrypt a message received from a second computer system, the second computer system also executing the first key generation process to generate the first key and encrypting the message using the first key, the first computer system and the second computer system engaging in encrypted communication without communicating an encryption key; A memory configured to: A first computer system comprising:

Images