Search

US-12627514-B2 - Event-locked messages with provable attestation

US12627514B2US 12627514 B2US12627514 B2US 12627514B2US-12627514-B2

Abstract

Described herein is an Event Locking System (ELS) and its associated methods for (a) cryptographically locking a given piece of information until a certain time or the occurrence of a certain event and (b) providing an attestation of both the lock time and the locked content to prove that the information has not been accessed or tampered with since the lock time. Applications for such a system abound: from sealed bids for auctions and tenders, sports betting, elections, archiving of sensitive information, securing legal documents, and so on.

Inventors

  • Kishore Swaminathan

Assignees

  • Kishore Swaminathan

Dates

Publication Date
20260512
Application Date
20221102

Claims (18)

  1. 1 . A system configured to perform event-based message locking, wherein messages are locked by encryption and prevented from decryption until a predetermined event has occurred, the system comprising one or more network-connected processors coupled to non-transitory computer-readable storage media storing program instructions that, when executed, cause the processors to execute at least three applications, including a first application, a second application, and a third application, wherein: the first application is configured to: associate a predetermined event with a unique event identifier (“event identifier”); associate, with the event identifier, a pair of asymmetric cryptographic keys called a first key and a second key, wherein the first key and the second key are mathematically related, and a message encrypted using the first key is decryptable using the second key; encrypt the second key using a randomly generated lock key; transmit the lock key to the second application; and transmit the first key and the encrypted second key to the third application; and the second application is configured to: receive the lock key from the first application; and transmit the lock key to the third application in response to receiving a signal key from a computer program designated as an oracle for recognizing the occurrence of the predetermined event; and the third application is configured to: receive the first key and the encrypted second key from the first application; dispense the first key in response to requests for the event identifier's first key; and subsequent to receiving the lock key from the second application: decrypt the encrypted second key using the lock key to obtain the event identifier's second key; and dispense the second key in response to requests for the event identifier's second key.
  2. 2 . The system of claim 1 , wherein the first application is further configured to: designate a computer application as an oracle for recognizing the occurrence of the predetermined event; and provide the oracle with a signal key for signaling the occurrence of the predetermined event.
  3. 3 . The system of claim 1 , wherein the program instructions further cause the processors to execute a fourth application configured to: receive a message M and an event identifier; encrypt M using a randomly generated encryption key EK to obtain a locked message LM; request and receive the event identifier's first key from the third application; and encrypt EK using the event identifier's first key to generate an event-locked encryption key EEK.
  4. 4 . The system of claim 1 , wherein the program instructions cause the processors to further execute a fourth application configured to: receive a locked message LM, an event identifier, and an event-locked encryption key EEK, wherein EEK comprises a randomly generated encryption key EK encrypted using the event identifier's first key; request and receive the event identifier's second key from the third application; decrypt EEK using the event identifier's second key to obtain EK; and decrypt LM using EK.
  5. 5 . The system of claim 1 , wherein the program instructions cause the processors to further execute a fourth application configured to: receive a message M and an event identifier; generate a message module MM comprising: M; hM, a message digest of M created using a predetermined hash function; and ChMt, a certified timestamp of hM at time t, created using a predetermined certified timestamping algorithm; encrypt MM using a randomly generated encryption key EK to obtain a locked message module LMM; request and receive the event identifier's first key from the third application; encrypt EK using the event identifier's first key to obtain an event-locked encryption key EEK; and generate a locked message module LMMA comprising: LMM; hLMM, a message digest of LMM created using a predetermined hash function; ChLMMs, a certified timestamp of the hLMM at time s, created using a predetermined certified timestamping algorithm; and EEK.
  6. 6 . The system of claim 1 , wherein the program instructions cause the processors to further execute a fourth application configured to: receive an event identifier and a message module LMMA locked to the event identifier, wherein LMMA comprises: a message module LMM; hLMM, a message digest of LMM created using a predetermined hash function; ChLMMs, a certified timestamp of the hLMM at time s, created using a predetermined certified timestamping algorithm; and EEK, an event-locked encryption key created by encrypting a randomly generated encryption key EK using the event identifier's first key; verify that ChLMMs certifies hLMM and time s; verify that hLMM is a message digest of LMM created using the predetermined hash function; request and receive the event identifier's second key from the third application; decrypt EEK using the event identifier's second key to obtain EK; decrypt LMM using EK to obtain a message module comprising: a message M; hM, a message digest of M; and ChMt, a certified timestamp of hM at time t; verify that ChMt certifies hM and time t; verify that hM is a message digest of M generated using the predetermined hash function; verify that time t temporally precedes time s; and generate a certification record indicating that M was locked between time t and time s and has not been altered since.
  7. 7 . The system of claim 1 , wherein the predetermined event is an occurrence of a predetermined absolute time, the predetermined absolute time represented using one of a plurality of time representations.
  8. 8 . The system of claim 7 , wherein the designated oracle comprises a plurality of timelocks, and the designated oracle transmits the signal key to the second application after receiving, from at least a predetermined number of the plurality of timelocks, release signals indicating that the predetermined absolute time has been reached or exceeded.
  9. 9 . The system of claim 1 , wherein the program instructions further cause the processors to record digitally signed, timestamped log entries associated with the event identifier in a tamper-evident log, wherein each log entry is hash-linked to a preceding log entry.
  10. 10 . A computer-implemented method for facilitating event-based message locking and unlocking, the method comprising: associating a predetermined event with a unique event identifier (“event identifier”); associating with the event identifier, a pair of asymmetric cryptographic keys called a first key and a second key, wherein the first key and the second key are mathematically related, and a message encrypted using the first key is decryptable using the second key; encrypting the second key using a randomly generated lock key; transmitting the lock key to a trusted application configured to maintain exclusive control of the lock key until the trusted application receives, from a designated oracle, a signal indicating that the predetermined event has occurred; dispensing the first key in response to requests for the event identifier's first key; and subsequent to the trusted application receiving, from the designated oracle, the signal indicating that the predetermined event has occurred: decrypting the encrypted second key using the lock key to obtain the event identifier's second key; and dispensing the second key in response to requests for the event identifier's second key.
  11. 11 . The method of claim 10 further comprising: receiving a message M and an event identifier; encrypting M using a randomly generated encryption key EK to obtain a locked message LM; and encrypting EK using the event identifier's first key to obtain an event-locked encryption key EEK.
  12. 12 . The method of claim 10 further comprising: receiving a locked message LM, an event identifier, and an event-locked encryption key EEK, wherein EEK comprises a randomly generated encryption key EK encrypted using the event identifier's first key; decrypting EEK using the event identifier's second key to obtain EK; and decrypting LM using EK.
  13. 13 . The method of claim 10 further comprising: receiving a message M and an event identifier; generating a message module MM comprising: M; hM, a message digest of M created using a predetermined hash function; and ChMt, a certified timestamp of hM at time t, created using a predetermined certified timestamping algorithm; encrypting MM using a randomly generated encryption key EK to obtain a locked message module LMM; encrypting EK using the event identifier's first key to obtain an event-locked encryption key EEK; and generating a locked message module LMMA comprising: LMM; hLMM, a message digest of LMM created using a predetermined hash function; ChLMMs, a certified timestamp of the hLMM at time s, created using a predetermined certified timestamping algorithm; and EEK.
  14. 14 . The method of claim 10 further comprising: receiving an event identifier and a message module LMMA locked to the event identifier, wherein LMMA comprises: a message module LMM; hLMM, a message digest of LMM created using a predetermined hash function; ChLMMs, a certified timestamp of the hLMM at time s, created using a predetermined certified timestamping algorithm; and EEK, an event-locked encryption key created by encrypting a randomly generated encryption key EK using the event identifier's first key; verifying that ChLMMs certifies hLMM and time s; verifying that hLMM is a message digest of LMM created using the predetermined hash function; decrypting EEK using the event identifier's second key to obtain EK; decrypting LMM using EK to obtain a message module comprising: a message M; hM, a message digest of M; and ChMt, a certified timestamp of hM at time t; verifying that ChMt certifies hM and time t; verifying that hM is a message digest of M created using the predetermined hash function; verifying that time t temporally precedes time s; and generating a certification record indicating that M was locked between time t and time s and has not been altered since.
  15. 15 . The method of claim 10 , wherein the signal received from the designated oracle comprises a signal key.
  16. 16 . The method of claim 10 , wherein the predetermined event is an occurrence of a predetermined absolute time, and wherein the designated oracle comprises a plurality of timelocks, and the designated oracle transmits the signal after receiving, from at least a predetermined number of the plurality of timelocks, release signals indicating that the predetermined absolute time has been reached or exceeded.
  17. 17 . The method of claim 10 , further comprising recording digitally signed, timestamped log entries associated with the event identifier in a tamper-evident log, wherein each log entry is hash-linked to a preceding log entry.
  18. 18 . The method of claim 10 , wherein the predetermined event is an occurrence of a predetermined absolute time, the predetermined absolute time represented using one of a plurality of time representations.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS The present application claims the benefit of Provisional Patent Application U.S. 63/283,959 titled “Event Locked Messaging with Provable Attestation” which is incorporated by reference herein in its entirety. FIELD OF INVENTION This invention is in the fields of information security. It describes systems and methods for cryptographically locking information until a certain time or event. BACKGROUND FOR THIS INVENTION Time capsules are a well-known physical means for locking information away until a specified time, though the creator of a time capsule has no way to enforce when the capsule can be opened or proving that it has not been altered after it was sealed. Auctions and tenders require sealed bids that will be opened at a specified time, with the promise that the best bid will be the winner, though neither the bidders nor the auctioneers can reliably prove when the bids were sealed or opened, nor be sure that the bids were safe from prying eyes until they were opened. Today, billions of dollars are at stake at sport betting events—legal and illegal—where the bets are taken online or over the phone and a bettor has little recourse against the word of a bookie. Other examples include sealed letters that may contain a will or a grant of power-of-attorney to a next of kin in case of death or disablement. Physical mechanisms such as locks or combination safes are one solution, but they store the information in unencrypted form; anyone who gains access can read or copy the information, potentially without leaving a trace. It is therefore necessary to have a reliable cryptographic mechanism for locking information until a specified time and/or the occurrence of a specified event. Such a mechanism, to be credible and useful, must also enable an unlocker to ascertain the time at which the information was locked, and that the information has not been altered since. A real-life scenario may be useful for motivating the need for event locking: imagine an election agency that uses electronic voting machines to conduct elections across many precincts. On election day, after the last vote is cast in a machine, the machine is locked till, say, 9:00 am the next morning and transported to a central location. At precisely 9:00 am the next morning, all machines are unlocked in front of the public and tallying of the votes begins. To be credible, the election agency must be able to prove that the voting database of each machine was sealed from both access and modification after the last vote, and that when the machine is unlocked the next morning, the database is the same one that was locked the previous day (i.e., it has not been swapped or replaced). Locking information with respect to time is not a new problem in cryptography and has been addressed before: the problem was originally posed in 1993 as “sending a message to the future” which became known as “time-release crypto” problem in academia. Over the next several years, researchers recognized that this is a non-trivial problem, there are no “universal” solutions, and any solution requires assumptions and specific usage models. Over the years, the problem has been approached from at least two distinct perspectives: from a purely computational complexity perspective (typically posed as a puzzle where the time complexity of solving the puzzle is greater than the time complexity of constructing the puzzle), and from a trusted-agent perspective, where a trusted third party holds the message or an encryption key until the specified time. Interest in the problem has waned over time since neither a universal solution, nor a general solution to a high-value instance of the problem have been found, although several solutions for specific instances of the problem have been proposed. Some notable early proposals include references [1] and [2]; some of the more recent proposals are references [3] [4] [5] and [6]. To the best of this inventor's knowledge, in patent literature, an invention that addresses event-locking is that of Fletcher [7] that teaches event-lock encryption in a proof-of-work blockchain where a “congress” of users with sufficient voting power can act as an oracle to decide that an event has occurred can compute a decryption key. This invention has many unique features: specifically, the notion of time is generalized into a notion of events (where time is just one kind of events, signaled by a clock). Second, a locked message is associated with an “attestation”: a certified timestamp of when it was locked and a proof of the locked content, enabling anyone to ascertain that the message has not been altered since it was locked. Third, this invention can be implemented using Web3 architecture as distributed applications (dApps) so that it caters to scenarios where trust is critical. BRIEF DESCRIPTION OF THIS INVENTION This invention describes systems and associated methods for cryptographically locking a given piece of info