US20100142704A1 - Cryptographic encoding and decoding of secret data - Google Patents
Cryptographic encoding and decoding of secret data Download PDFInfo
- Publication number
- US20100142704A1 US20100142704A1 US12/606,710 US60671009A US2010142704A1 US 20100142704 A1 US20100142704 A1 US 20100142704A1 US 60671009 A US60671009 A US 60671009A US 2010142704 A1 US2010142704 A1 US 2010142704A1
- Authority
- US
- United States
- Prior art keywords
- event
- key
- computer
- dependent
- predetermined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
- H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
- H04L9/3013—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the discrete logarithm problem, e.g. ElGamal or Diffie-Hellman systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/42—Anonymization, e.g. involving pseudonyms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- This invention relates generally to cryptographic encoding and decoding of secret data in data processing systems. More particularly, the present invention relates to systems, methods and apparatus for verifiably encrypting data in order to prevent the decryption of the data until the occurrence of a predetermined event.
- Cryptographic encoding is used in a variety of security and privacy-sensitive applications where one party (hereinafter “user”) needs to send private data securely to another party (hereinafter “verifier”) in a potentially insecure data processing system, for example over an insecure network such as the Internet. Some applications necessarily involve the verifier decoding the private data. In other applications, it is desirable to keep the private data secret from the verifier, unless circumstances arise which necessitate disclosure of the private user information. A common example of the latter scenario is making an on-line purchase where users connect to a remote server via a data communications network to access some service or other resource.
- the privacy concerns of users and regulatory privacy requirements often demand that users have anonymity in such circumstances, i.e. that the identity of users is not revealed to the service provider. However, to protect the interests of the service provider, there should be a way for the service provider to obtain the identity of misbehaving users, e.g. users who do not pay their bills. This situation therefore demands for privacy protection coupled with user accountability.
- the cryptographic construction can be a credential generated using a cryptographic process by a trusted issuing party who has in some manner verified the information for which the credential is issued.
- the secret data should be encoded in the cryptographic construction using a “verifiable encryption process”, where this term refers generally herein to encryption processes employing cryptographic protocols which allow proofs to be made about the properties of encrypted data (often defined in terms of “attributes”) without revealing the data itself (the “attribute values”).
- secret data X is encoded using a verifiable encryption process
- the verifier can cryptographically verify that the received construction contains the required secret data without the secret data itself being revealed. If valid circumstances arise for decrypting the secret data, the verifier can apply to the trusted third party, for example the police or other government agency, to obtain a decryption of the secret data.
- a method for cryptographically encoding secret data in a data processing system includes the step of encoding the secret data in accordance with a verifiable encryption process to produce a cryptographic construction ( ⁇ ) having a decryption constraint dependent on the occurrence of a predetermined event.
- a computer readable article of manufacture tangibly embodying computer readable instructions is provided for causing a data processing system to execute the steps of the above method.
- an encoding apparatus for cryptographically encoding secret data.
- the encoding apparatus includes control logic adapted to encode the secret data in accordance with a verifiable encryption process to produce a cryptographic construction ( ⁇ ) having a decryption constraint dependent on the occurrence of a predetermined event.
- a decoding apparatus for receiving a cryptographic construction ( ⁇ ) is provided.
- the decoding apparatus includes memory for storing the cryptographic construction and control logic adapted to (i) verify that the cryptographic construction contains secret data, (ii) determine the existence of a predetermined decoding condition which is dependent on the occurrence of at least one event including a predetermined first event, and (iii) decode the cryptographic construction as permitted by a decryption constraint if the at least one event occurred where the secret data is encoded in accordance with a verifiable encryption process such that the cryptographic construction has the decryption constraint which is dependent on the occurrence of the predetermined first event.
- a distributed trust data processing system for cryptographically encoding and decoding data.
- the distributed trust data processing system includes a user computer, wherein the user computer is adapted to (i) generate a public key of a public-private keypair which is dependent on an event indicator (t ⁇ ) indicative of a predetermined first event such that extraction of a private key (sk ⁇ ) of the keypair is also dependent on occurrence of the event indicated by the event indicator (t ⁇ ), (ii) use the public key to encode secret data in accordance with a verifiable encryption process which produces a cryptographic construction ( ⁇ ) having a decryption constraint dependent on the occurrence of the predetermined first event, and (iii) send the cryptographic construction ( ⁇ ) to the verifier computer via a data communications network; a key-extraction computer, wherein the key-extraction computer is adapted to respond to the request from the verifier computer by (i) determining if a predetermined decoding condition,
- FIG. 1 is a schematic illustration of a first data processing system embodying the invention
- FIG. 2 illustrates interaction between a user computer and a verifier computer in the FIG. 1 system
- FIG. 3 illustrates operation of a key extraction computer in the FIG. 1 system
- FIG. 4 is a schematic illustration of a second data processing system embodying the invention showing steps involved in operation of the system.
- the verifiable encryption process used to encode the secret data is such that an event-dependent decryption constraint is built into the cryptography. That is, there is an intrinsic restriction on the ability to decrypt the encoded secret data, this restriction being dependent on the occurrence of a predetermined event. This event can be related to the circumstance under which it is deemed permissible to reveal the secret user data, allowing user accountability to be provided without relying wholly on a fully-trusted third party who has full power to decrypt the data. This technique thus offers stronger user privacy while reducing the investment of trust required for implementing user accountability.
- the event-dependent decryption constraint provides the basis for secure, efficient, and flexible distributed-trust data processing systems which provide accountability, as exemplified by preferred embodiments described below.
- a verifiable encryption process means that a verifier can cryptographically verify that the cryptographic construction contains secret data with the required property or properties without the data itself being revealed to the verifier. If the secret data is a user ID for example, it can be cryptographically proven that the construction contains a valid user ID without disclosing the ID itself.
- the verifiable encryption process can of course involve encoding other elements as well as the secret data, so that the resulting cryptographic construction can comprise the encoded secret data and other encoded components. While alternatives can be envisaged, in preferred embodiments the verifiable encryption process is based on a system introduced by Camenisch and Shoup.
- this allows the user to prove that the required secret data is encoded in the cryptographic construction, and that the construction can be decoded if required, via a zero-knowledge proof, i.e. a proof which does not reveal any other information than that which is to be proved.
- a zero-knowledge proof i.e. a proof which does not reveal any other information than that which is to be proved.
- a user can use this system to encrypt her true identity to the authorities, provide this encrypted data to a verifier, and then convince the verifier in a zero-knowledge proof of knowledge that this encrypted data contains a valid user identity that can be opened by the authorities.
- the decryption constraint on the cryptographic construction can comprise a single constraint term, e.g. that decryption is impossible before some event E has occurred or a plurality of component constraint terms, e.g. that decryption is impossible before event E 1 and decryption is impossible after event E 2 .
- the decryption constraint can in general depend on one or a plurality of predetermined events.
- Various types of event can be envisaged here depending on the particular application.
- an event can be a time event, where “time” here can be real clock time or measured in terms of any other ordered sequence of events such as the number of times that some particular action, e.g.
- a system access occurs, or the issue of some numbered item such as a periodical magazine.
- Other types of event can include the satisfaction of some condition or the completion of some task, for instance payment of a bill, or the acquisition or issuance of some item such as a certificate proving a particular fact or occurrence.
- a cryptographic construction can be constructed so as to implement the decryption constraint.
- this is achieved by generating the public key of a public-private keypair which is dependent on an event indicator indicative of the predetermined event such that extraction of the private key of the keypair is dependent on occurrence of the event indicated by the event indicator.
- the secret data is then encoded using this public key, whereby the resulting construction can only be decoded when the event-dependent key-extraction is possible.
- extraction of the private key can require an input dependent on occurrence of the event indicated by the event indicator, e.g. some cryptographic symbol which is trusted evidence of occurrence of the event. A particular example of this will be described below.
- the cryptographic construction once generated, will be transmitted via a data communications channel to a receiving device of the data processing system where it will be subject to cryptographic verification and possible future decoding.
- a predetermined decoding condition can be dependent only on the occurrence of the predetermined first event.
- the condition can be that an event has occurred.
- the condition can be dependent on one or more further events and can be dependent in numerous ways on the occurrence of the different events as desired for a given application.
- the control logic of the decoding apparatus preferably comprises: verifier logic for verifying that the cryptographic construction contains the secret data; and key extraction logic for extracting the private key of the keypair if the predetermined decoding condition exists.
- the verifier logic and key extraction logic can be under independent control here, thus further reducing the level of trust required of different components of the system. This provides the basis for highly flexible and efficient distributed trust data processing systems.
- the private key can be unlinkable to a specific user at the key extraction computer, preventing infringement of any specific user's privacy by a key extraction authority.
- trust is distributed between at least the verifier and key extraction computers, so that neither one need be trusted to the same degree as if the functionality of the two were combined.
- particularly preferred embodiments can distribute trust among additional independent entities to provide, if desired, full end-to-end unlinkability.
- a computer program embodying the invention can constitute an independent program or can be an element of a larger program, and can be supplied, for example, embodied in a computer-readable medium such as a disk or an electronic transmission for loading in a computer.
- the program code means of the computer program can comprise any expression, in any language, code or notation, of a set of instructions intended to cause a computer to perform the method in question, either directly or after either or both of (a) conversion to another language, code or notation, and (b) reproduction in a different material form.
- An embodiment of the present invention provides a verifier computer of a distributed trust data processing system.
- Another embodiment of the present invention provides a key extraction computer of a distributed trust data processing system.
- Damg ⁇ rd and Fujisaki (“An integer commitment scheme based on groups with hidden order”, I. Damg ⁇ rd and E. Fujisaki, http://eprint.iacr.org/2001,2001) show that if the group G is an RSA group and the committer is not privy to the factorization of the modulus, then in fact the Pedersen commitment scheme can be used to commit to integers of arbitrary size.
- CL signatures are described in detail in: “A Signature Scheme with Efficient Protocols”, J. Camenisch and A. Lysyanskaya, in S. Cimato, C. Galdi and G. Persiano editors, Security in Communications Networks, Third International Conference, SCN 2002, volume 2576 of Lecture Notes in Computer Science, pages 268-289, Springer Verlag, 2003. Briefly, however, the scheme consists of two secure protocols:
- IDP An efficient protocol between a user and a signer with keys
- IDP here refers to an Identity Provider who issues identity credentials to a user. This entity might be a passport authority or similar, and implementations are well known in the art and need not be discussed further here).
- the common input consists of pk IDP and C, a Damg ⁇ rd and Fujisaki commitment as introduced above.
- the user obtains a signature ⁇ pk IDP ( ⁇ 1 , . . . , ⁇ l ) on his committed values, while the signer does not learn anything about them.
- the CL scheme uses the integer commitment primitive Com( )introduced above which can be operated on by zero-knowledge proofs of knowledge. We provide an additional interface to the scheme:
- An Identity-based Encryption (IBE) scheme is an encryption scheme that allows the public key of a recipient to be an identity string id. Examples could be the recipient's e-mail address, yet, also the identifier of a service transaction. IBE schemes rely on a trusted third party, the Key Generation Center (KGC), to derive the user's secret key for an identity sk id . The function to generate this secret key from the identity string is called IBEExtract( ).
- KGC Key Generation Center
- Anonymous IBE Introduced by Abdalla et al., “Searchable encryption revisited: Consistency properties, relation to anonymous ibe, and extensions”, in V. Shoup, editor, Advances in Cryptology—CRYPTO 2005, volume 3621 of Lecture Notes in Computer Science, pages 205-222, Springer Verlag, 2005 ensures that it is infeasible to derive the identity string id to which the message was encrypted from the ciphertext.
- blind extract IBE which provides the capability to generate the secret key to an identity sk id in a blinded fashion. Where normal IBE schemes transfer the identity string in plain text to the Key Generation Center, Blind Extract IBE keeps the identity id confidential from it.
- Camenisch et al propose an IBE primitive that combines both properties in “Public key encryption with oblivious keyword search and its application to data retention”, IBM Research Report RZ 3708, IBM Research, May 2008, http://domino.research.ibm.com/library/cyberdig.nsf/index.html.
- Their Committed Blind Anonymous IBE allows for a blind extraction of the secret key sk id by giving the Key Generation Center a commitment on the identity string.
- the user of the system may either disclose partial information about the identity string or prove statements with efficient Zero-Knowledge Proofs of Knowledge about the commitment. This may, for instance, convey statements about linear relations or range proofs.
- Such proofs can be easily combined with proofs over attributes certified by a CL signature as introduced above.
- verifiable encryption schemes allow for proving properties about encrypted data.
- Camenisch and Shoup Practical verifiable encryption and decryption of discrete logarithms”, in D. Boneh, editor, Advances in Cryptology—CRYPTO 2003, volume 2729 of Lecture Notes in Computer Science, pages 126-144, 2003
- Their contribution focuses on discrete-log problems. It can be combined with Pedersen's as well as Damg ⁇ rd and Fujisaki's commitment schemes and the CL signature scheme introduced above.
- A encrypts a message m under the public key pk T , derives a ciphertext ct and sends it to B.
- A can prove a statement about the encrypted m in an efficient Zero-Knowledge Proof of Knowledge to B, while B cannot decrypt the ciphertext ct on its own.
- B may however gain confidence by A's proof that the ciphertext ct contains a valuable piece of information that principal T is able to retrieve. For instance, A may encrypt its own true identity id A under the public key pk T . It may prove in zero-knowledge that the ciphertext contains the very same identity string as certified in a credential A possesses. Then a receiving service B can be confident that it can have T decrypt the true identity of A if a dispute occurs.
- FIG. 1 is a simplified schematic of a first embodiment of a distributed trust data processing system showing the main components involved in operation of the system.
- the data processing system 1 includes a user computer 2 which embodies an encoding apparatus for encrypting secret user data, and a decoding apparatus implemented by a verifier computer 3 and a key extraction computer 4 .
- the system also includes a time server (TS) computer 5 .
- User computer 2 includes encoder logic 6 for implementing the encoding process, memory 7 , and a communications interface 8 .
- Verifier computer 3 includes verifier logic 9 for performing a verification process described below, memory 10 , and a communications interface 11 .
- Key extraction computer 4 comprises key extraction logic 14 for implementing functions described below, memory 13 , and a communications interface 14 .
- Computers 2 , 3 and 4 can communicate over a data communications network 15 via their respective communications interfaces (where network 15 can comprise a plurality of component networks and/or internetworks).
- the control logic 6 , 9 , and 12 of these computers is configured for implementing the appropriate steps of cryptographic processes.
- this control logic can be implemented in hardware or software or a combination thereof, and the precise form of the user, verifier and key-extraction devices 2 to 4 is largely irrelevant to fundamental operation of the cryptographic processes to be described.
- these devices are implemented by general-purpose computers, user computer 2 being a user pc and verifier and key extraction computers 3 , 4 being servers to which user pc 2 can connect over network 15 .
- Encoder logic 6 , verifier logic 9 and key extraction logic 12 are implemented here by respective computer programs which configure the host computers to perform the functions described. Suitable software will be apparent to those skilled in the art from the description herein.
- Verifier computer 3 is operated by a service provider (SP).
- SP service provider
- a user operating user computer 2 can connect over network 15 to SP computer 3 to buy access to a service.
- the identity of the user should not be revealed to the service provider in this process.
- the service provider requires users to be accountable for their purchases. Hence the service provider should be able to determine the identity of users who do not pay their bills in time.
- the service provider SP permits anonymous or pseudonymous access to the service, yet wants to ensure that he can hold the user accountable if payment is not made within a defined time period.
- the service provider requires the user to provide a cryptographic construction, encoding his identity data, which can be decoded by SP if the user does not pay by the end of the specified time period.
- a number of measures are employed in system 1 .
- time capsule the cryptographic construction encoding the user's identity has a decryption constraint which prevents SP (or anyone else) from decoding the construction before a time corresponding to the end of the allowed payment period.
- This cryptographic construction is referred to hereinafter as a “time capsule”.
- Time in system 1 is measured by an independent time server TS 5 which issues a succession of time symbols T(t i ) cryptographically encoding the current time t i at regular intervals.
- Time server 5 is trusted to release time symbols T(t i ) sequentially and on time, and not to reveal any T(t i ) for a time t i that has not yet occurred.
- the implementation of time server 5 is well known in the art and need not be discussed further here.
- a second user-protection measure provided in system 1 is that a decryption key for the time capsule can only be generated by key extraction computer 4 which is operated independently of service provider SP by a “revocation authority” (RA).
- the revocation authority RA manages the key-pairs used to encrypt and decrypt time capsules.
- the user U can communicate with this authority in order to encrypt a time capsule, and the service provider SP must communicate with RA to obtain the decryption key necessary to “open” a time capsule.
- the revocation authority RA can revoke decryptability of a time capsule if proof is received that appropriate payment has been made by the user.
- RA is trusted to not reveal any time capsule decryption key if it detects that the time capsule's contracted revocation condition (e.g. payment of a bill) has occurred.
- the time capsule's contracted revocation condition e.g. payment of a bill
- FIG. 2 indicates the key steps performed by user computer 2 on the left of the figure and SP computer 3 on the right when a user wishes to access the on-line service.
- a set-up procedure is performed in which the encoder logic 6 of user computer 2 communicates with the key extraction logic 12 of RA computer 4 to agree on the definition of various parameters to be used for generating the keypairs for encryption and decryption of time capsules. Parameters to be used by the logic 6 , 12 in this process are stored in the respective memories 7 and 13 of these computers.
- the user can open a communications channel to SP computer 3 to request access to the service as indicated in step (a) of FIG. 2 .
- step (b) the user and SP computers 2 , 3 implement an enrollment procedure in which the parties agree contract terms for access to the service. As part of this process, the time t ⁇ by which the user must make payment for the service is established.
- step (c) the encoder logic 6 of user computer 2 then generates a time capsule ⁇ .
- the time capsule ⁇ is produced by encoding the user's secret identity credential id U,IDP in accordance with a verifiable encryption process such that the resulting cryptographic construction has a decryption constraint dependent on the occurrence of a predetermined time event.
- encoder logic 6 uses parameters pre-agreed in the set-up procedure to generate the public key pk ⁇ of a public-private keypair pk ⁇ , sk ⁇ for the time capsule ⁇ .
- This keypair pk ⁇ , sk ⁇ is dependent on an event indicator.
- the event indication is time t ⁇ which represents the event on which the time capsule's decryption constraint depends.
- extraction of the private key sk ⁇ of the keypair is dependent on occurrence of this event, here availability of the time symbol T(t ⁇ ) for time t ⁇ .
- Encoder logic 6 then encodes the secret identity credential id U,IDP using the public key pk ⁇ to produce the time capsule ⁇ .
- the time capsule can also encode other data, and will typically encode at least a transaction identifier supplied by SP computer 3 for the user transaction, as illustrated in the more detailed example below).
- step (c) of FIG. 2 encoder logic 6 sends the time capsule ⁇ to SP computer 3 where it is received by verifier logic 9 and stored in memory 10 .
- step (d) the verifier logic 9 communicates with encoder logic 6 to implement a cryptographic verification protocol.
- This protocol stems from the verifiable encryption process used to generate the time capsule.
- the verifiable encryption process is such that it is possible to implement a cryptographic proof of knowledge demonstrating that the time capsule contains a valid identity credential without revealing the secret identity credential itself.
- This verifiable encryption process can be a committed blind anonymous identity-based encryption scheme, detailed below, which also allows logic 9 to verify that the time capsule can be opened if necessary.
- step (e) the verifier logic 9 then sends the user a token that permits access to the service.
- tokens are well known in the art and need not be described further here.
- the user can then access the service in step (f), and the verifier logic 9 awaits time t ⁇ when a check for payment will be conducted.
- the user U will arrange for payment to be made to the service provider SP, and will typically obtain proof of payment, such as an electronic bank receipt, by which the payment can be demonstrated to the revocation authority RA.
- proof of payment such as an electronic bank receipt
- such a receipt can simply be sent by the user to RA computer 4 where it will be received by key extraction logic 12 and stored in memory 13 .
- key extraction logic 12 can simply be sent by the user to RA computer 4 where it will be received by key extraction logic 12 and stored in memory 13 .
- a more sophisticated system for proving payment to the revocation authority will be described below.
- the next stage in operation of system 1 occurs at time t ⁇ when verifier logic 9 of SP computer 3 contacts RA computer 4 .
- FIG. 3 indicates the key steps performed by key-extraction logic 12 of RA computer 4 in the ensuing process.
- Operation commences at step 20 of FIG. 3 when the key-extraction logic receives a request for the time capsule decryption key sk ⁇ from verifier logic 9 .
- This request includes sufficient information to enable the appropriate transaction to be determined. This can comprise the transaction identifier mentioned earlier, though the information supplied here can partially determine the extent to which different user transactions are linkable by revocation computer 4 .
- the request comprises a portion of the time capsule ⁇ containing a blinded form of the transaction identifier.
- key extraction logic 12 responds to receipt of the request in step 21 by checking whether the contracted revocation condition, i.e. bill payment, has occurred for the transaction.
- step 22 logic 12 revokes decryptability of the corresponding time capsule ⁇ so that this time capsule can never be decrypted. This can be done, for example, by deletion from memory 13 of data necessary for extracting the decryption key sk ⁇ .
- RA computer 4 then notifies the SP computer 3 in step 23 that the user has paid his bill, and the process is complete. At this point, verifier logic 9 can delete the stored time capsule ⁇ from memory 10 .
- step 21 if key extraction logic 12 decides that the user has not paid his bill (“no” (N) at step 21 ), then operation continues to step 24 .
- logic 12 determines if the time symbol T(t ⁇ ) has been issued by TS computer 5 for the time t ⁇ . If not, then the permitted payment term has not yet expired. A message to this effect will then be sent to verifier logic 9 in step 23 , and the process terminates. Note that, even if an unscrupulous revocation authority acted in concert with the service provider to attempt extraction of key sk ⁇ before time t ⁇ , key extraction is not be possible due to the inherent decryption constraint on the time capsule.
- time symbol T(t ⁇ ) can not yet be issued and this time symbol is a required input for the cryptographic key extraction process. Only if T(t ⁇ ) is available at step 24 will it be determined that the user has breached the payment contract. In this case, key extraction logic 12 proceeds in step 25 with the extraction of decryption key sk ⁇ . This key is sent to verifier logic 9 in step 26 , whereupon the service provider SP can decrypt the time capsule to obtain the identity of the user and take action to obtain payment.
- the overall decoding condition for the time capsule is dependent on two events in the above embodiment.
- the first event is the issue of time symbol T(t ⁇ ) as determined by the time capsule's inherent decryption constraint
- the second event is bill-payment by the user.
- the check as to whether the decoding condition has been met (T(t ⁇ ) available (i.e. time t>t ⁇ ) AND bill unpaid) is embodied in steps 21 and 24 of FIG. 3 .
- User privacy is thus protected by both the time capsule decryption constraint and the provision for RA to revoke decryptability (step 22 of FIG. 3 ) when a contract has been satisfied.
- no party has full power to decrypt a time capsule as trust is distributed between SP, RA and TS in this system.
- the RA can extract time capsule decryption keys only when permitted by the time-dependent decryption constraint, but does not hold a copy of the time capsule itself. SP cannot decrypt any time capsule it holds unless a valid decryption key is available from RA.
- no party Before the predetermined release time t ⁇ , no party can decrypt ⁇ . If the user fulfills the revocation condition (bill payment) before time t ⁇ , neither SP nor any other party will be able to open the time capsule ⁇ . If the user does not fulfill the revocation condition before time t ⁇ , only SP can open ⁇ .
- the system 1 provides a highly effective distributed trust accountable privacy system based on time capsules containing user identity data.
- FIG. 4 shows the key components of the preferred system, indicated generally at 30 .
- the numbered arrows in the figure represent the basic processes involved in operation of the system 30 and show the information flow between system components.
- U, SP and RA correspond to computers 2 , 3 and 4 respectively in the FIG. 1 system. These computers operate substantially as described above except where contrary operation is defined in the following.
- TS corresponds to time server computer 5 in FIG. 1 .
- the system 30 additionally includes two further components represented in the figure by respective computers labeled SA and BB.
- SA represents a computer operated by a “satisfaction authority”, such as a bank, who can issue a “satisfaction token” confirming payment by user U to service provider SP. SA is trusted to honestly report when payment has occurred.
- BB represents a computer running a bulletin board.
- Bulletin boards are well known in the art and essentially provide a public forum in which items posted are available for anyone to download.
- BB is used to post satisfaction tokens by which the user proves payment for a contract.
- BB is trusted to report all items posted on the bulletin board (although this can also be checked by the user). The following explains the cryptographic processes involved in each numbered step of FIG. 4 with reference to the cryptographic building blocks introduced earlier.
- the RA performs IBESetup(1 k) and VESetup(1 k) by acting both as an Identity Based Encryption (IBE) Key Generation Center (KGC) as well as a participant in a verifiable cryptosystem.
- IBE Identity Based Encryption
- KGC Key Generation Center
- the RA then publishes the resultant public information (parIBE, parVE, pkSA).
- parIBE, parVE, pkSA public information
- RA issues a unique pseudonym id U,RA to user U, which can be used for multiple service contracts within the system. This value is used only in blinded form, thus multiple transactions with this same pseudonym are unlinkable.
- the pseudonym id U,RA will form a part of the time capsule's key.
- the pseudonym will be later used only in blinded form, preventing linkability between transactions.
- the user makes a contract with the service provider
- the user receives a token that permits use of the service
- the SP leaves the user with a mechanism to prove fulfillment of the contract (payment).
- the user leaves the service provider with a time capsule ⁇ that can be opened later to identify the user if the contract is not fulfilled.
- U and SP jointly compute a random transaction identifier id sat which is then known to both parties, and a blinded form of the same identifier known to neither U nor SP, but rather encrypted to SA and RA respectively: VEEnc(pk SA , id sat ′), VEEnc(pk RA , id sat ′).
- the joint computation of id sat which is then known to both parties can be realized using standard techniques.
- Joint computation of the blinded id sat ′ that is known to neither computing party, but is verifiably encrypted to other parties can be realized using standard homomorphic encryption techniques with the addition of blind anonymous verifiable encryption of the jointly computed value.
- U computes the public portion of a keypair (pk ⁇ , sk ⁇ ) which is generated such that the keypair depends on (id U,RA , t ⁇ , id sat ).
- the creation of a keypair that depends on the values (id U,RA , t 107 , id sat ) is possible by using those values, which include the event indicator t ⁇ , as the identity in the generation of a committed blind anonymous IBE.
- IBE pk ⁇ can be released, and an encryption against this key can be verified, without revealing the identity or corresponding sk ⁇ .
- the later extraction of sk ⁇ is a blind anonymous extraction that will not reveal these values.
- SP sends to U a token permitting access to the service.
- the satisfaction authority SA typically the bank
- SA provides a secure receipt that the user later publishes to prove payment of the bill.
- the receipt is blinded such that it can prove payment for the transaction without revealing the identity of the user.
- the protocol is:
- the satisfaction token minted by SP with respect to id sat ′ can be accomplished by encoding the satisfaction conditions (such as an amount of money to be paid, and the destination of that money) as attributes in an anonymous credential that has id sat ′ encoded as a committed attribute.
- SA can then sign a statement that the transaction id sat ′ has been fulfilled using any secure signature scheme.
- the user By publishing the receipt of payment the user prevents the service provider from being able to reveal his identity.
- Revoke(U, BB) the user publishes proof of payment to the bulletin board BB tok(id sat ′) and id sat ′.
- the user By broadcasting proof of payment on BB, the user revokes the ability of SP to open the time capsule. Since only id sat ′ and a signature on id sat ′ are broadcast, and since id sat ′ cannot be linked with the user, this satisfies the privacy requirements of the system.
- the revocation authority RA checks for revocation of 8 by searching the BB for the secure receipt, and verifying that it is a correct payment for the correct bill. If a receipt is found and verified, then the check succeeds indicating that revocation has occurred and the contract is complete. In other words, if check succeeds then ⁇ should never be opened.
- the RA checks for revocation by searching the BB for id sat ′ using protocol Check(RA(id sat ′), BB(id sat ′)) and verifying tok(id sat ′). If they are found and verified then the check succeeds, indicating that revocation has occurred and the contract is complete.
- id sat ′ is revealed to RA by decryption under sk RA . This suffices for RA to determine whether the contract has been satisfied, but RA cannot link the Enroll event for this transaction with this check, which provides the end-to-end unlinkability required for honest users.
- RA decrypts VEEnc(pk RA , id sat ′) to retrieve id sat ′ (which is not linkable by RA with any other data).
- RA performs Check (id sat ′). If Check succeeds, RA detects revocation and halts without returning sk ⁇ .
- SP decrypts and reveals id U,IDP . Only if: (i) a revocation is not detected by RA; and (ii) a key extraction is possible (e.g., it is after time t ⁇ ) will the sk ⁇ be revealed to SP. If the key is revealed to SP then the capsule can be opened and the user's true identity revealed. This satisfies the privacy properties and the accountability properties of the system.
- the event on which the decryption constraint depends can be something other than a time event.
- the decoding condition applied by the revocation authority can be dependent in general on one or more further events, and can be dependent in numerous ways on occurrence of the different events as desired for a given application.
- components represented by single computers in the embodiments described can be implemented in practice by more than one computer of a distributed computing system.
- any combination of the entities SA, BB, TS, and even SP and RA can be merged.
- Intrinsic decryption constraint provides improved accountable privacy compared to prior systems since no single entity has unlimited power to decrypt the secret data.
Abstract
Description
- This application claims priority under 35 U.S.C. §119 from European Patent Application No. 08105681.4 filed Oct. 28, 2008, the entire contents of which are incorporated herein by reference.
- 1. Field of the Invention
- This invention relates generally to cryptographic encoding and decoding of secret data in data processing systems. More particularly, the present invention relates to systems, methods and apparatus for verifiably encrypting data in order to prevent the decryption of the data until the occurrence of a predetermined event.
- 2. Description of Related Art
- Cryptographic encoding is used in a variety of security and privacy-sensitive applications where one party (hereinafter “user”) needs to send private data securely to another party (hereinafter “verifier”) in a potentially insecure data processing system, for example over an insecure network such as the Internet. Some applications necessarily involve the verifier decoding the private data. In other applications, it is desirable to keep the private data secret from the verifier, unless circumstances arise which necessitate disclosure of the private user information. A common example of the latter scenario is making an on-line purchase where users connect to a remote server via a data communications network to access some service or other resource. The privacy concerns of users and regulatory privacy requirements often demand that users have anonymity in such circumstances, i.e. that the identity of users is not revealed to the service provider. However, to protect the interests of the service provider, there should be a way for the service provider to obtain the identity of misbehaving users, e.g. users who do not pay their bills. This situation therefore demands for privacy protection coupled with user accountability.
- In these situations where secret user data should be revealed to a verifier only in certain circumstances, current systems rely on the user sending the verifier a cryptographic construction which encodes the secret data, and which can be decoded if necessary using a cryptographic key held by a trusted third party. For example, the cryptographic construction can be a credential generated using a cryptographic process by a trusted issuing party who has in some manner verified the information for which the credential is issued. The secret data should be encoded in the cryptographic construction using a “verifiable encryption process”, where this term refers generally herein to encryption processes employing cryptographic protocols which allow proofs to be made about the properties of encrypted data (often defined in terms of “attributes”) without revealing the data itself (the “attribute values”). In simple terms, if secret data X is encoded using a verifiable encryption process, then it can be cryptographically proven that the encrypted data contains the data X without actually revealing X. For example, if X is a user ID certified by a government agency, then it can be proven that the encrypted data contains a government-certified ID without revealing the ID itself. In the present scenario therefore, the verifier can cryptographically verify that the received construction contains the required secret data without the secret data itself being revealed. If valid circumstances arise for decrypting the secret data, the verifier can apply to the trusted third party, for example the police or other government agency, to obtain a decryption of the secret data. These systems require a high-level of trust to be invested in the key-holding party by both user and verifier. The need to involve such a highly-trusted authority can also be problematical in practice. For example, bringing a case before a law enforcement agency can be expensive and time consuming. Such systems can also be vulnerable to abuse by malicious verifiers who attempt to obtain unwarranted release of decryption keys.
- According to an aspect of the present invention, a method for cryptographically encoding secret data in a data processing system is provided. The method includes the step of encoding the secret data in accordance with a verifiable encryption process to produce a cryptographic construction (θ) having a decryption constraint dependent on the occurrence of a predetermined event.
- According to another aspect of the present invention, a computer readable article of manufacture tangibly embodying computer readable instructions is provided for causing a data processing system to execute the steps of the above method.
- According to another aspect of the present invention, an encoding apparatus for cryptographically encoding secret data is provided. The encoding apparatus includes control logic adapted to encode the secret data in accordance with a verifiable encryption process to produce a cryptographic construction (θ) having a decryption constraint dependent on the occurrence of a predetermined event.
- According to another aspect of the present invention, a decoding apparatus for receiving a cryptographic construction (θ) is provided. The decoding apparatus includes memory for storing the cryptographic construction and control logic adapted to (i) verify that the cryptographic construction contains secret data, (ii) determine the existence of a predetermined decoding condition which is dependent on the occurrence of at least one event including a predetermined first event, and (iii) decode the cryptographic construction as permitted by a decryption constraint if the at least one event occurred where the secret data is encoded in accordance with a verifiable encryption process such that the cryptographic construction has the decryption constraint which is dependent on the occurrence of the predetermined first event.
- According to another aspect of the present invention, a distributed trust data processing system for cryptographically encoding and decoding data is provided. The distributed trust data processing system includes a user computer, wherein the user computer is adapted to (i) generate a public key of a public-private keypair which is dependent on an event indicator (tω) indicative of a predetermined first event such that extraction of a private key (skθ) of the keypair is also dependent on occurrence of the event indicated by the event indicator (tω), (ii) use the public key to encode secret data in accordance with a verifiable encryption process which produces a cryptographic construction (θ) having a decryption constraint dependent on the occurrence of the predetermined first event, and (iii) send the cryptographic construction (θ) to the verifier computer via a data communications network; a key-extraction computer, wherein the key-extraction computer is adapted to respond to the request from the verifier computer by (i) determining if a predetermined decoding condition, dependent on occurrence of at least one event including the predetermined first event, exists (ii) extracting the private key (skθ) of the keypair and sending the private key (skθ) to the verifier computer if the predetermined decoding condition exists; and a verifier computer, wherein the verifier computer is adapted to (i) verify that the cryptographic construction (θ) contains the secret data, (ii) store the cryptographic construction (θ) in memory (10), (iii) communicate with the key extraction computer via the data communications network to request the private key (skθ) for the cryptographic construction (θ), and (iv) decode the cryptographic construction on receipt of the private key (skθ); where the user, verifier, and key-extraction computers are adapted for communication via the data communications network.
-
FIG. 1 is a schematic illustration of a first data processing system embodying the invention; -
FIG. 2 illustrates interaction between a user computer and a verifier computer in theFIG. 1 system; -
FIG. 3 illustrates operation of a key extraction computer in theFIG. 1 system; and -
FIG. 4 is a schematic illustration of a second data processing system embodying the invention showing steps involved in operation of the system. - With encoding methods embodying this invention, the verifiable encryption process used to encode the secret data is such that an event-dependent decryption constraint is built into the cryptography. That is, there is an intrinsic restriction on the ability to decrypt the encoded secret data, this restriction being dependent on the occurrence of a predetermined event. This event can be related to the circumstance under which it is deemed permissible to reveal the secret user data, allowing user accountability to be provided without relying wholly on a fully-trusted third party who has full power to decrypt the data. This technique thus offers stronger user privacy while reducing the investment of trust required for implementing user accountability. In particular, the event-dependent decryption constraint provides the basis for secure, efficient, and flexible distributed-trust data processing systems which provide accountability, as exemplified by preferred embodiments described below.
- As discussed earlier, the use of a verifiable encryption process means that a verifier can cryptographically verify that the cryptographic construction contains secret data with the required property or properties without the data itself being revealed to the verifier. If the secret data is a user ID for example, it can be cryptographically proven that the construction contains a valid user ID without disclosing the ID itself. The verifiable encryption process can of course involve encoding other elements as well as the secret data, so that the resulting cryptographic construction can comprise the encoded secret data and other encoded components. While alternatives can be envisaged, in preferred embodiments the verifiable encryption process is based on a system introduced by Camenisch and Shoup. Briefly, this allows the user to prove that the required secret data is encoded in the cryptographic construction, and that the construction can be decoded if required, via a zero-knowledge proof, i.e. a proof which does not reveal any other information than that which is to be proved. For instance, a user can use this system to encrypt her true identity to the authorities, provide this encrypted data to a verifier, and then convince the verifier in a zero-knowledge proof of knowledge that this encrypted data contains a valid user identity that can be opened by the authorities.
- In general, the decryption constraint on the cryptographic construction can comprise a single constraint term, e.g. that decryption is impossible before some event E has occurred or a plurality of component constraint terms, e.g. that decryption is impossible before event E1 and decryption is impossible after event E2. Thus, the decryption constraint can in general depend on one or a plurality of predetermined events. Various types of event can be envisaged here depending on the particular application. For example, an event can be a time event, where “time” here can be real clock time or measured in terms of any other ordered sequence of events such as the number of times that some particular action, e.g. a system access, occurs, or the issue of some numbered item such as a periodical magazine. Other types of event can include the satisfaction of some condition or the completion of some task, for instance payment of a bill, or the acquisition or issuance of some item such as a certificate proving a particular fact or occurrence.
- Those skilled in the art will appreciate that there are a variety of ways in which a cryptographic construction can be constructed so as to implement the decryption constraint. In the preferred embodiments to be described, this is achieved by generating the public key of a public-private keypair which is dependent on an event indicator indicative of the predetermined event such that extraction of the private key of the keypair is dependent on occurrence of the event indicated by the event indicator. The secret data is then encoded using this public key, whereby the resulting construction can only be decoded when the event-dependent key-extraction is possible. For example, extraction of the private key can require an input dependent on occurrence of the event indicated by the event indicator, e.g. some cryptographic symbol which is trusted evidence of occurrence of the event. A particular example of this will be described below.
- In a typical application the cryptographic construction, once generated, will be transmitted via a data communications channel to a receiving device of the data processing system where it will be subject to cryptographic verification and possible future decoding.
- A predetermined decoding condition can be dependent only on the occurrence of the predetermined first event. For example the condition can be that an event has occurred. In general, however, the condition can be dependent on one or more further events and can be dependent in numerous ways on the occurrence of the different events as desired for a given application.
- Where the secret data is encoded in the cryptographic construction using a public key of a public-private keypair dependent on an event indicator as described above, the control logic of the decoding apparatus preferably comprises: verifier logic for verifying that the cryptographic construction contains the secret data; and key extraction logic for extracting the private key of the keypair if the predetermined decoding condition exists. The verifier logic and key extraction logic can be under independent control here, thus further reducing the level of trust required of different components of the system. This provides the basis for highly flexible and efficient distributed trust data processing systems.
- With the functionality divided between the verifier computer and an independent key extraction computer, the private key can be unlinkable to a specific user at the key extraction computer, preventing infringement of any specific user's privacy by a key extraction authority. In such systems, trust is distributed between at least the verifier and key extraction computers, so that neither one need be trusted to the same degree as if the functionality of the two were combined. Indeed, particularly preferred embodiments can distribute trust among additional independent entities to provide, if desired, full end-to-end unlinkability.
- It will be understood that the term “computer” is used herein in the most general sense and includes any device, component or system having a data processing capability for implementing a computer program. Moreover, a computer program embodying the invention can constitute an independent program or can be an element of a larger program, and can be supplied, for example, embodied in a computer-readable medium such as a disk or an electronic transmission for loading in a computer. The program code means of the computer program can comprise any expression, in any language, code or notation, of a set of instructions intended to cause a computer to perform the method in question, either directly or after either or both of (a) conversion to another language, code or notation, and (b) reproduction in a different material form.
- In general, where features are described herein with reference to an embodiment of one aspect of the invention, corresponding features can be provided in embodiments of another aspect of the invention as appropriate.
- An embodiment of the present invention provides a verifier computer of a distributed trust data processing system. Another embodiment of the present invention provides a key extraction computer of a distributed trust data processing system.
- Preferred embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which:
- Before describing data processing systems embodying the invention, we first present various cryptographic building blocks which are employed in operation of the exemplary embodiments to be described.
- Strong RSA Assumption (See “A method for obtaining Digital Signatures and public-key Cryptosystems”, R. L. Rivest, A. Shamir, L. Adleman, Communications of the ACM, 21(2):120-126. February 1978, and “Statistical zero knowledge protocols to prove modular polynomial relations”, E. Fujisaki and T. Okamoto, in B. Kaliski, editor, Advances in Cryptology—CRYPTO '97, volume 1294 of Lecture Notes in Computer Science, pages 16-30, Springer Verlag, 1997): given an RSA modulus n and a random element g ε Z*n, it is hard to compute h ε Z*n and integer e>1 such that he≡g mod n. The modulus n is of a special form pq, where p=2p′+1 and q=2q′+1 are safe primes.
- We recall the Pederson commitment scheme (as detailed in “Non-interactive and Information-theoretic Secure Verifiable Secret Sharing”, T. P. Pedersen, in J. Feigenbaum, editor, Advances in Cryptology—CRYPTO '91, volume 576 of Lecture Notes in Computer Science, pages 129-140, Springer Verlag, 1992) in which the public parameters are a group G of prime order q, and generators (g0, . . . , gm). In order to commit to the values (v0, . . . , vm) ε Zq m, pick a random r ε Zq and set
-
- Damgård and Fujisaki (“An integer commitment scheme based on groups with hidden order”, I. Damgård and E. Fujisaki, http://eprint.iacr.org/2001,2001) show that if the group G is an RSA group and the committer is not privy to the factorization of the modulus, then in fact the Pedersen commitment scheme can be used to commit to integers of arbitrary size.
- We specify an abstract interface for integer commitments: Com(v1, . . . , vm; r)) for values vi and a random number r produces an integer commitment C on the values vi.
- In the common parameters model we use several known results for proving statements about discrete logarithms. When referring to such proofs, we will follow the notation introduced by Camenisch and Stadler (J. Camenisch and M. Stadler. “Efficient Group Signature Schemes for Large Groups”, J. Camenisch and M. Stadler, in B. Kaliski, editor, Advances in Cryptology—CRYPTO '97, volume 1296 of Lecture Notes in Computer Science, pages 410-424, Springer Verlag, 1997) for various proofs of knowledge of discrete logarithms and proofs of the validity of statements about discrete logarithms. For instance,
- denotes a “zero-knowledge Proof of Knowledge of integers α, β, and δ such that y=gα hβ and {tilde over (y)}={tilde over (g)}α{tilde over (h)}β holds, where u≦α≦v and where y, g, h, {tilde over (y)}, {tilde over (g)}, {tilde over (h)} are elements of some groups G=g=h and G={tilde over (g)}={tilde over (h)}. The convention is that Greek letters denote quantities of which knowledge is being proved, while all other values are known to the verifier. We apply the Fiat-Shamir heuristic (“How to prove yourself: Practical solutions to identification and signature problems”, A. Fiat and A. Shamir, in A. M. Odlyzko, editor, Advances in Cryptology—CRYPTO '86, volume 263 of Lecture Notes in Computer Science, pages 186-194. Springer Verlag, 1987) to turn such proofs of knowledge into signatures on some message m; denoted as, for example, SPK{(α): y=gα}(m). Given a protocol in this notation in the following description, the derivation of an actual protocol implementing the proof will be apparent to those skilled in the art.
- The exemplary embodiments to be described leverage Camenisch-Lysyanskaya (CL) signatures as high-level building blocks. CL signatures are described in detail in: “A Signature Scheme with Efficient Protocols”, J. Camenisch and A. Lysyanskaya, in S. Cimato, C. Galdi and G. Persiano editors, Security in Communications Networks, Third International Conference, SCN 2002, volume 2576 of Lecture Notes in Computer Science, pages 268-289, Springer Verlag, 2003. Briefly, however, the scheme consists of two secure protocols:
- (1) An efficient protocol between a user and a signer with keys (pkIDP, skIDP). (IDP here refers to an Identity Provider who issues identity credentials to a user. This entity might be a passport authority or similar, and implementations are well known in the art and need not be discussed further here). The common input consists of pkIDP and C, a Damgård and Fujisaki commitment as introduced above. The user's secret input is the set of values (v1, . . . , vl; r) such that C=Com(v1, . . . , vl; r) (mod n). As a result of the protocol, the user obtains a signature σpk
IDP (ν1, . . . , νl) on his committed values, while the signer does not learn anything about them. - (2) An efficient proof of knowledge of a signature protocol between a user and a verifier. The common inputs are pkIDP and a commitment C. The user's private inputs are the values (v1, . . . , vl, r), and σpk
IDP (ν1, . . . , νl) such that C=Com(v1, . . . , vl; r). These signatures are secure under the strong RSA assumption discussed above. - The CL scheme uses the integer commitment primitive Com( )introduced above which can be operated on by zero-knowledge proofs of knowledge. We provide an additional interface to the scheme:
- CLSetup(1 k) outputs parameters parCL.
- CLKeyGen(parCL) outputs a public key/private key keypair (pkIDP, skIDP).
- CLSign(U(pkIDP, C, (v1, . . . , vl, r)), IDP(pkIDP, skIDP;C)) outputs a CL signature on the user's values (v1, . . . , vl) to the user U and nothing to the IDP, iff C=Com(v1, . . . , vl, r). CLVerify(U(pkIDP, C, (v1, . . . , vl, r), σpk
IDP (ν1, . . . , νl)), V(pkIDP, C)) outputs valid to the verifier V and nothing to the user U iff C=Com(v1, . . . , vl, r). Otherwise, it outputs ⊥ to both principals. - An Identity-based Encryption (IBE) scheme is an encryption scheme that allows the public key of a recipient to be an identity string id. Examples could be the recipient's e-mail address, yet, also the identifier of a service transaction. IBE schemes rely on a trusted third party, the Key Generation Center (KGC), to derive the user's secret key for an identity skid. The function to generate this secret key from the identity string is called IBEExtract( ).
- We leverage an IBE scheme with two additional properties: anonymity and blind extraction. Anonymous IBE (introduced by Abdalla et al., “Searchable encryption revisited: Consistency properties, relation to anonymous ibe, and extensions”, in V. Shoup, editor, Advances in Cryptology—CRYPTO 2005, volume 3621 of Lecture Notes in Computer Science, pages 205-222, Springer Verlag, 2005) ensures that it is infeasible to derive the identity string id to which the message was encrypted from the ciphertext.
- Green and Hohenberger (“Blind identity-based encryption and simulatable oblivious transfer”, in ASIACRYPT, pages 265-282, 2007) introduced blind extract IBE, which provides the capability to generate the secret key to an identity skid in a blinded fashion. Where normal IBE schemes transfer the identity string in plain text to the Key Generation Center, Blind Extract IBE keeps the identity id confidential from it.
- Camenisch et al propose an IBE primitive that combines both properties in “Public key encryption with oblivious keyword search and its application to data retention”, IBM Research Report RZ 3708, IBM Research, May 2008, http://domino.research.ibm.com/library/cyberdig.nsf/index.html. Their Committed Blind Anonymous IBE allows for a blind extraction of the secret key skid by giving the Key Generation Center a commitment on the identity string. The user of the system may either disclose partial information about the identity string or prove statements with efficient Zero-Knowledge Proofs of Knowledge about the commitment. This may, for instance, convey statements about linear relations or range proofs. Clearly, such proofs can be easily combined with proofs over attributes certified by a CL signature as introduced above.
- We refer to the system interface of Camenisch et al in the IBM Research Report RZ 3708 reference above:
- IBESetup(1 k) outputs parameters par/BE and master secret msk.
- IBEBlindExtract(A(parIBE, id, open), KGC(msk, C)) generates the secret decryption key skid for a user A's identity id in an interactive key issuing protocol between A and the KGC. If C=Com(id, open), then the user's output is a decryption key skid and the output of the KGC is empty. Otherwise both parties output error.
- IBEEnc(parIBE, id, m) outputs ciphertext ct encrypting m under id.
- IBEDec(parIBE, skid, ct) outputs message m encrypted in ct.
- As discussed earlier, verifiable encryption schemes allow for proving properties about encrypted data. In their current form, they were introduced by Camenisch and Shoup (“Practical verifiable encryption and decryption of discrete logarithms”, in D. Boneh, editor, Advances in Cryptology—CRYPTO 2003, volume 2729 of Lecture Notes in Computer Science, pages 126-144, 2003) who provided the first efficient construction without resorting to cut-and-choose proofs. Their contribution focuses on discrete-log problems. It can be combined with Pedersen's as well as Damgård and Fujisaki's commitment schemes and the CL signature scheme introduced above. In brief, suppose a principal T owns a public key/secret key pair (pkT, skT). Suppose further that A encrypts a message m under the public key pkT, derives a ciphertext ct and sends it to B. A can prove a statement about the encrypted m in an efficient Zero-Knowledge Proof of Knowledge to B, while B cannot decrypt the ciphertext ct on its own. B may however gain confidence by A's proof that the ciphertext ct contains a valuable piece of information that principal T is able to retrieve. For instance, A may encrypt its own true identity idA under the public key pkT. It may prove in zero-knowledge that the ciphertext contains the very same identity string as certified in a credential A possesses. Then a receiving service B can be confident that it can have T decrypt the true identity of A if a dispute occurs.
- We use the following interface for Camenisch and Shoup's construction:
- VESetup(1 k) outputs parameters parVE and a public key/secret key pair (PkT, skT).
- VEEnc(pkT, m) Encrypts the message m to the public key pkT.
- VEDec(skT, ct) Decrypts the ciphertext ct with secret key skT.
- The proof statements about properties of encrypted messages are orthogonal to the verifiable encryption primitive. We can use the same efficient Zero-Knowledge Proof of Knowledge mechanisms as for proofs over commitments, CL signatures, or Committed Blind Anonymous IBE identity strings.
-
FIG. 1 is a simplified schematic of a first embodiment of a distributed trust data processing system showing the main components involved in operation of the system. Thedata processing system 1 includes auser computer 2 which embodies an encoding apparatus for encrypting secret user data, and a decoding apparatus implemented by averifier computer 3 and akey extraction computer 4. The system also includes a time server (TS) computer 5.User computer 2 includesencoder logic 6 for implementing the encoding process, memory 7, and acommunications interface 8.Verifier computer 3 includesverifier logic 9 for performing a verification process described below,memory 10, and acommunications interface 11.Key extraction computer 4 comprises key extraction logic 14 for implementing functions described below,memory 13, and a communications interface 14.Computers data communications network 15 via their respective communications interfaces (wherenetwork 15 can comprise a plurality of component networks and/or internetworks). Thecontrol logic extraction devices 2 to 4 is largely irrelevant to fundamental operation of the cryptographic processes to be described. In this example, however, we assume that these devices are implemented by general-purpose computers,user computer 2 being a user pc and verifier andkey extraction computers user pc 2 can connect overnetwork 15.Encoder logic 6,verifier logic 9 andkey extraction logic 12 are implemented here by respective computer programs which configure the host computers to perform the functions described. Suitable software will be apparent to those skilled in the art from the description herein. - In this illustrative example, the
system 1 is employed in an on-line purchasing scenario.Verifier computer 3 is operated by a service provider (SP). A useroperating user computer 2 can connect overnetwork 15 toSP computer 3 to buy access to a service. To protect user privacy, the identity of the user should not be revealed to the service provider in this process. However, the service provider requires users to be accountable for their purchases. Hence the service provider should be able to determine the identity of users who do not pay their bills in time. - An overview will now be given of the operation of
system 1 for achieving this accountable privacy requirement. The details of exemplary cryptographic processes underlying this operation will be described in connection with a later embodiment. - For operation of
system 1, we assume that the user (U) holds cryptographic identity credentials idU,IDP issued by an Identity Provider (IDP) such as a government agency. The implementation of such an IDP is well known in the art and need not be discussed further here. The service provider SP permits anonymous or pseudonymous access to the service, yet wants to ensure that he can hold the user accountable if payment is not made within a defined time period. Hence, for access to the service, the service provider requires the user to provide a cryptographic construction, encoding his identity data, which can be decoded by SP if the user does not pay by the end of the specified time period. However, to protect the user's privacy from an unscrupulous service provider attempting to decode his identity without good cause, a number of measures are employed insystem 1. - Firstly, the cryptographic construction encoding the user's identity has a decryption constraint which prevents SP (or anyone else) from decoding the construction before a time corresponding to the end of the allowed payment period. This cryptographic construction is referred to hereinafter as a “time capsule”. Time in
system 1 is measured by an independent time server TS 5 which issues a succession of time symbols T(ti) cryptographically encoding the current time ti at regular intervals. Time server 5 is trusted to release time symbols T(ti) sequentially and on time, and not to reveal any T(ti) for a time ti that has not yet occurred. The implementation of time server 5 is well known in the art and need not be discussed further here. - A second user-protection measure provided in
system 1 is that a decryption key for the time capsule can only be generated bykey extraction computer 4 which is operated independently of service provider SP by a “revocation authority” (RA). The revocation authority RA manages the key-pairs used to encrypt and decrypt time capsules. The user U can communicate with this authority in order to encrypt a time capsule, and the service provider SP must communicate with RA to obtain the decryption key necessary to “open” a time capsule. - As a third protection measure, the revocation authority RA can revoke decryptability of a time capsule if proof is received that appropriate payment has been made by the user. Hence, RA is trusted to not reveal any time capsule decryption key if it detects that the time capsule's contracted revocation condition (e.g. payment of a bill) has occurred. (Note that it is not necessary to trust that the RA will not reveal a time capsule's key before the contract, specifically the payment term, has expired since this is cryptographically enforced as mentioned above).
- The operation of
user computer 2,SP computer 3 andRA computer 4 is illustrated in more detail inFIGS. 2 and 3 .FIG. 2 indicates the key steps performed byuser computer 2 on the left of the figure andSP computer 3 on the right when a user wishes to access the on-line service. Prior to operation, a set-up procedure is performed in which theencoder logic 6 ofuser computer 2 communicates with thekey extraction logic 12 ofRA computer 4 to agree on the definition of various parameters to be used for generating the keypairs for encryption and decryption of time capsules. Parameters to be used by thelogic respective memories 7 and 13 of these computers. Subsequently, the user can open a communications channel toSP computer 3 to request access to the service as indicated in step (a) ofFIG. 2 . - In step (b) the user and
SP computers encoder logic 6 ofuser computer 2 then generates a time capsule θ. The time capsule θ is produced by encoding the user's secret identity credential idU,IDP in accordance with a verifiable encryption process such that the resulting cryptographic construction has a decryption constraint dependent on the occurrence of a predetermined time event. In more detail,encoder logic 6 uses parameters pre-agreed in the set-up procedure to generate the public key pkθ of a public-private keypair pkθ, skθ for the time capsule θ. - This keypair pkθ, skθ is dependent on an event indicator. Here, the event indication is time tω which represents the event on which the time capsule's decryption constraint depends. In particular, extraction of the private key skθ of the keypair is dependent on occurrence of this event, here availability of the time symbol T(tω) for time tω.
Encoder logic 6 then encodes the secret identity credential idU,IDP using the public key pkθ to produce the time capsule θ. (The time capsule can also encode other data, and will typically encode at least a transaction identifier supplied bySP computer 3 for the user transaction, as illustrated in the more detailed example below). - In step (c) of
FIG. 2 ,encoder logic 6 sends the time capsule θ toSP computer 3 where it is received byverifier logic 9 and stored inmemory 10. Next, in step (d) theverifier logic 9 communicates withencoder logic 6 to implement a cryptographic verification protocol. This protocol stems from the verifiable encryption process used to generate the time capsule. Specifically, the verifiable encryption process is such that it is possible to implement a cryptographic proof of knowledge demonstrating that the time capsule contains a valid identity credential without revealing the secret identity credential itself. This verifiable encryption process can be a committed blind anonymous identity-based encryption scheme, detailed below, which also allowslogic 9 to verify that the time capsule can be opened if necessary. Having performed the verification process, in step (e) theverifier logic 9 then sends the user a token that permits access to the service. Such tokens are well known in the art and need not be described further here. The user can then access the service in step (f), and theverifier logic 9 awaits time tω when a check for payment will be conducted. - Under normal circumstances, the user U will arrange for payment to be made to the service provider SP, and will typically obtain proof of payment, such as an electronic bank receipt, by which the payment can be demonstrated to the revocation authority RA. In simple embodiments, such a receipt can simply be sent by the user to
RA computer 4 where it will be received bykey extraction logic 12 and stored inmemory 13. A more sophisticated system for proving payment to the revocation authority will be described below. In any case, the next stage in operation ofsystem 1 occurs at time tω whenverifier logic 9 ofSP computer 3contacts RA computer 4.FIG. 3 indicates the key steps performed by key-extraction logic 12 ofRA computer 4 in the ensuing process. - Operation commences at
step 20 ofFIG. 3 when the key-extraction logic receives a request for the time capsule decryption key skθ fromverifier logic 9. This request includes sufficient information to enable the appropriate transaction to be determined. This can comprise the transaction identifier mentioned earlier, though the information supplied here can partially determine the extent to which different user transactions are linkable byrevocation computer 4. Hence, in the preferred system detailed below, the request comprises a portion of the time capsule θ containing a blinded form of the transaction identifier. In any case,key extraction logic 12 responds to receipt of the request instep 21 by checking whether the contracted revocation condition, i.e. bill payment, has occurred for the transaction. If so (“yes” (Y) at decision step 21), operation proceeds to step 22 wherelogic 12 revokes decryptability of the corresponding time capsule θ so that this time capsule can never be decrypted. This can be done, for example, by deletion frommemory 13 of data necessary for extracting the decryption key skθ.RA computer 4 then notifies theSP computer 3 instep 23 that the user has paid his bill, and the process is complete. At this point,verifier logic 9 can delete the stored time capsule θ frommemory 10. - Returning to
decision step 21, ifkey extraction logic 12 decides that the user has not paid his bill (“no” (N) at step 21), then operation continues to step 24. Herelogic 12 determines if the time symbol T(tω) has been issued by TS computer 5 for the time tω. If not, then the permitted payment term has not yet expired. A message to this effect will then be sent toverifier logic 9 instep 23, and the process terminates. Note that, even if an unscrupulous revocation authority acted in concert with the service provider to attempt extraction of key skθ before time tω, key extraction is not be possible due to the inherent decryption constraint on the time capsule. In particular, the time symbol T(tω) can not yet be issued and this time symbol is a required input for the cryptographic key extraction process. Only if T(tω) is available atstep 24 will it be determined that the user has breached the payment contract. In this case,key extraction logic 12 proceeds instep 25 with the extraction of decryption key skθ. This key is sent toverifier logic 9 in step 26, whereupon the service provider SP can decrypt the time capsule to obtain the identity of the user and take action to obtain payment. - It will be seen that the overall decoding condition for the time capsule is dependent on two events in the above embodiment. The first event is the issue of time symbol T(tω) as determined by the time capsule's inherent decryption constraint, and the second event is bill-payment by the user. The check as to whether the decoding condition has been met (T(tω) available (i.e. time t>tω) AND bill unpaid) is embodied in
steps FIG. 3 . User privacy is thus protected by both the time capsule decryption constraint and the provision for RA to revoke decryptability (step 22 ofFIG. 3 ) when a contract has been satisfied. Moreover, no party has full power to decrypt a time capsule as trust is distributed between SP, RA and TS in this system. The RA can extract time capsule decryption keys only when permitted by the time-dependent decryption constraint, but does not hold a copy of the time capsule itself. SP cannot decrypt any time capsule it holds unless a valid decryption key is available from RA. Before the predetermined release time tω, no party can decrypt θ. If the user fulfills the revocation condition (bill payment) before time tω, neither SP nor any other party will be able to open the time capsule θ. If the user does not fulfill the revocation condition before time tω, only SP can open θ. Thus thesystem 1 provides a highly effective distributed trust accountable privacy system based on time capsules containing user identity data. - The foregoing explains the basic operation of a distributed trust system embodying the invention. Particularly preferred embodiments employ additional measures to protect user privacy by ensuring that different user transactions are unlinkable by parties to the system. An example of such a system, offering full end-to-end unlinkability, will now be described. This description gives details of the underlying cryptographic processes which can be used to implement the functionality described for the foregoing as well as the following embodiment. Modifications to the following processes for implementing the simpler embodiment of
FIG. 1 will be apparent to those skilled in the art. In the following system, the unlinkability feature is that, if the revocation condition occurs before time tω, then no party will be able to link the user's transactions together, nor link any transaction to a specific user. This is a stronger notion of privacy than currently offered in existing systems. -
FIG. 4 shows the key components of the preferred system, indicated generally at 30. The numbered arrows in the figure represent the basic processes involved in operation of thesystem 30 and show the information flow between system components. U, SP and RA correspond tocomputers FIG. 1 system. These computers operate substantially as described above except where contrary operation is defined in the following. Similarly, TS corresponds to time server computer 5 inFIG. 1 . Thesystem 30 additionally includes two further components represented in the figure by respective computers labeled SA and BB. SA represents a computer operated by a “satisfaction authority”, such as a bank, who can issue a “satisfaction token” confirming payment by user U to service provider SP. SA is trusted to honestly report when payment has occurred. BB represents a computer running a bulletin board. Bulletin boards are well known in the art and essentially provide a public forum in which items posted are available for anyone to download. Insystem 30, BB is used to post satisfaction tokens by which the user proves payment for a contract. BB is trusted to report all items posted on the bulletin board (although this can also be checked by the user). The following explains the cryptographic processes involved in each numbered step ofFIG. 4 with reference to the cryptographic building blocks introduced earlier. - Prior to the numbered steps in the figure, the following system setup steps are performed. The RA performs IBESetup(1 k) and VESetup(1 k) by acting both as an Identity Based Encryption (IBE) Key Generation Center (KGC) as well as a participant in a verifiable cryptosystem. The RA then publishes the resultant public information (parIBE, parVE, pkSA). Hereafter we will implicitly assume that these public parameters are available to all principals.
- Setup—steps 1) and 2):
- (U(idU,RA))←Setup(U, RA)
- Setup(U, RA)→idU,RA
- RA issues a unique pseudonym idU,RA to user U, which can be used for multiple service contracts within the system. This value is used only in blinded form, thus multiple transactions with this same pseudonym are unlinkable. In particular, the pseudonym idU,RA will form a part of the time capsule's key. By using committed blind anonymous IBE, the pseudonym will be later used only in blinded form, preventing linkability between transactions.
- Enrollment—steps 3) and 4):
- (U(idsat), SP(θ))←Enroll(U(idU,RA, idU,IDP), SP)
- During enrollment the user makes a contract with the service provider, the user receives a token that permits use of the service, and the SP leaves the user with a mechanism to prove fulfillment of the contract (payment). The user leaves the service provider with a time capsule θ that can be opened later to identify the user if the contract is not fulfilled. In more detail:
- Enroll(U(idU,RA, idU,IDP), SP)
- i) U and SP jointly compute a random transaction identifier idsat which is then known to both parties, and a blinded form of the same identifier known to neither U nor SP, but rather encrypted to SA and RA respectively: VEEnc(pkSA, idsat′), VEEnc(pkRA, idsat′). The joint computation of idsat which is then known to both parties can be realized using standard techniques. Joint computation of the blinded idsat′ that is known to neither computing party, but is verifiably encrypted to other parties, can be realized using standard homomorphic encryption techniques with the addition of blind anonymous verifiable encryption of the jointly computed value.
- ii) U computes the public portion of a keypair (pkθ, skθ) which is generated such that the keypair depends on (idU,RA, tω, idsat). The creation of a keypair that depends on the values (idU,RA, t107 , idsat) is possible by using those values, which include the event indicator tω, as the identity in the generation of a committed blind anonymous IBE. Using this form of IBE pkθ can be released, and an encryption against this key can be verified, without revealing the identity or corresponding skθ. Additionally, the later extraction of skθ is a blind anonymous extraction that will not reveal these values.
- iii) U computes the time capsule as follows: θ=(VEEnc(pkθ, idU,IDP), VEEnc(pkRA, idsat′)) and sends θ to SP.
- iv) SP verifies in zero knowledge that 8 can be decrypted by skθ and that RA can derive skθ. The verifiable encryption shown by the Green and Hohenberger reference given earlier permits the properties that we require of the time capsule θ. In particular it is suitable for the encryption key pkθ such that the contents of the encryption and the decryptability under the secret values (idU,RA, tω, idsat) is possible with further zero knowledge proofs.
- v) SP verifies in zero knowledge that θ contains the user's identity with respect to the system: idU,IDP.
- vi) SP sends to U a token permitting access to the service.
-
- (U(tok(idsat′), idsat′), SA(idsat′))←Satisfy(U(idsat′), SA(skSA))
- The user invokes this protocol to fulfill the contract (pay the bill). The satisfaction authority SA (typically the bank) provides a secure receipt that the user later publishes to prove payment of the bill. The receipt is blinded such that it can prove payment for the transaction without revealing the identity of the user. In more detail, the protocol is:
- Satisfy(U(VEEnc(pkSA, idsat′)), SA(skSA))
- At the end of this protocol U has proven to SA that the revocation condition has occurred with respect to the blinded encrypted form of the satisfaction token VEEnc(pkSA, idsat′). The user receives from SA a revocation token tok(idsat′), and the now decrypted satisfaction token idsat′, which together prove that the contract with respect to the blinded satisfaction token has been fulfilled. This proof can be accomplished with standard anonymous credential techniques:
- i) The satisfaction token minted by SP with respect to idsat′ can be accomplished by encoding the satisfaction conditions (such as an amount of money to be paid, and the destination of that money) as attributes in an anonymous credential that has idsat′ encoded as a committed attribute.
- ii) When SA decrypts its copy of idsat′ it can verify that the correct amount of money is being paid to the correct entity, and that the transaction is securely linked to the blinded satisfaction token.
- iii) SA can then sign a statement that the transaction idsat′ has been fulfilled using any secure signature scheme.
- Publish—step 7):
- ( )←Publish(U(tok(idsat′), idsat′), BB)
- By publishing the receipt of payment the user prevents the service provider from being able to reveal his identity. In particular, to invoke the revocation condition Revoke(U, BB) the user publishes proof of payment to the bulletin board BB tok(idsat′) and idsat′. By broadcasting proof of payment on BB, the user revokes the ability of SP to open the time capsule. Since only idsat′ and a signature on idsat′ are broadcast, and since idsat′ cannot be linked with the user, this satisfies the privacy requirements of the system.
-
- (RA(tok(idsat′)))←Check(RA(idsat′), BB(idsat′))
- The revocation authority RA checks for revocation of 8 by searching the BB for the secure receipt, and verifying that it is a correct payment for the correct bill. If a receipt is found and verified, then the check succeeds indicating that revocation has occurred and the contract is complete. In other words, if check succeeds then θ should never be opened. The RA checks for revocation by searching the BB for idsat′ using protocol Check(RA(idsat′), BB(idsat′)) and verifying tok(idsat′). If they are found and verified then the check succeeds, indicating that revocation has occurred and the contract is complete. During the Check operation, idsat′ is revealed to RA by decryption under skRA. This suffices for RA to determine whether the contract has been satisfied, but RA cannot link the Enroll event for this transaction with this check, which provides the end-to-end unlinkability required for honest users.
-
- (SP(skθ))←Open(SP(θ), RA(skRA), TS(ti))
- In the open transaction the service provider attempts to gain knowledge of the user's real identity. The SP requests this knowledge by providing the revocation authority with a designated portion of the time capsule. If the user has not paid his bill, and the bill is overdue, the revocation authority will be able to extract the secret key that unlocks the rest of the time capsule. If the user has honestly paid the bill, however, this transaction will not succeed, and the service provider learns nothing. In more detail, in the protocol Open(SP(θ), RA(skRA), TS(ti):
- i) SP sends VEEnc(pkRA, idsat′) to RA and requests skθ. In the first step of opening, RA must perform an IBE key extraction of skθ in order to retrieve idsat′. Here we use the special anonymity properties of anonymous blind committed IBE to perform the key extraction without RA gaining knowledge of the user's true identity. Note that key extraction will only succeed if the time symbol for time tω is now available from TS. This satisfies the temporal constraint imposed in the system.
- ii) RA decrypts VEEnc(pkRA, idsat′) to retrieve idsat′ (which is not linkable by RA with any other data).
- iii) RA performs Check (idsat′). If Check succeeds, RA detects revocation and halts without returning skθ.
- iv) If ti<tω, RA halts without returning skθ.
- v) RA generates and returns skθ.
- vi) SP decrypts and reveals idU,IDP. Only if: (i) a revocation is not detected by RA; and (ii) a key extraction is possible (e.g., it is after time tω) will the skθ be revealed to SP. If the key is revealed to SP then the capsule can be opened and the user's true identity revealed. This satisfies the privacy properties and the accountability properties of the system.
- It will be appreciated that many changes and modifications can be made to the exemplary embodiments described above. By way of example, the event on which the decryption constraint depends can be something other than a time event. Further, the decoding condition applied by the revocation authority can be dependent in general on one or more further events, and can be dependent in numerous ways on occurrence of the different events as desired for a given application. As envisaged earlier, components represented by single computers in the embodiments described can be implemented in practice by more than one computer of a distributed computing system. In addition, depending on the particular level of privacy demanded for a given system, any combination of the entities SA, BB, TS, and even SP and RA, can be merged. Intrinsic decryption constraint provides improved accountable privacy compared to prior systems since no single entity has unlimited power to decrypt the secret data.
- While the secret data is user identity data in the exemplary scenarios above, embodiments of the invention can of course be applied to any secret data which should only be revealed to a receiving party under certain circumstances. Many other changes and modifications can be made without departing from the scope of the invention.
Claims (18)
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP08105681 | 2008-10-28 | ||
EP08105681.4 | 2008-10-28 | ||
EP08105681 | 2008-10-28 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100142704A1 true US20100142704A1 (en) | 2010-06-10 |
US8744077B2 US8744077B2 (en) | 2014-06-03 |
Family
ID=42231077
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/606,710 Expired - Fee Related US8744077B2 (en) | 2008-10-28 | 2009-10-27 | Cryptographic encoding and decoding of secret data |
Country Status (1)
Country | Link |
---|---|
US (1) | US8744077B2 (en) |
Cited By (48)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120005098A1 (en) * | 2010-06-30 | 2012-01-05 | International Business Machines Corporation | Privacy-sensitive sample analysis |
US8654975B2 (en) | 2011-04-29 | 2014-02-18 | International Business Machines Corporation | Joint encryption of data |
WO2015048042A1 (en) * | 2013-09-25 | 2015-04-02 | Amazon Technologies, Inc. | Data security using request-supplied keys |
US20150295710A1 (en) * | 2014-04-11 | 2015-10-15 | Thomson Licensing | Paillier-based blind decryption methods and devices |
US9178701B2 (en) | 2011-09-29 | 2015-11-03 | Amazon Technologies, Inc. | Parameter based key derivation |
US9197409B2 (en) | 2011-09-29 | 2015-11-24 | Amazon Technologies, Inc. | Key derivation techniques |
US9203613B2 (en) | 2011-09-29 | 2015-12-01 | Amazon Technologies, Inc. | Techniques for client constructed sessions |
US9215076B1 (en) | 2012-03-27 | 2015-12-15 | Amazon Technologies, Inc. | Key generation for hierarchical data access |
US9237019B2 (en) | 2013-09-25 | 2016-01-12 | Amazon Technologies, Inc. | Resource locators with keys |
US9258118B1 (en) | 2012-06-25 | 2016-02-09 | Amazon Technologies, Inc. | Decentralized verification in a distributed system |
US9258117B1 (en) | 2014-06-26 | 2016-02-09 | Amazon Technologies, Inc. | Mutual authentication with symmetric secrets and signatures |
US9262642B1 (en) | 2014-01-13 | 2016-02-16 | Amazon Technologies, Inc. | Adaptive client-aware session security as a service |
US9292711B1 (en) | 2014-01-07 | 2016-03-22 | Amazon Technologies, Inc. | Hardware secret usage limits |
US9305177B2 (en) | 2012-03-27 | 2016-04-05 | Amazon Technologies, Inc. | Source identification for unauthorized copies of content |
US9369461B1 (en) | 2014-01-07 | 2016-06-14 | Amazon Technologies, Inc. | Passcode verification using hardware secrets |
US9374368B1 (en) | 2014-01-07 | 2016-06-21 | Amazon Technologies, Inc. | Distributed passcode verification system |
US9407440B2 (en) | 2013-06-20 | 2016-08-02 | Amazon Technologies, Inc. | Multiple authority data security and access |
US9420007B1 (en) | 2013-12-04 | 2016-08-16 | Amazon Technologies, Inc. | Access control using impersonization |
US9521000B1 (en) | 2013-07-17 | 2016-12-13 | Amazon Technologies, Inc. | Complete forward access sessions |
US9660972B1 (en) | 2012-06-25 | 2017-05-23 | Amazon Technologies, Inc. | Protection from data security threats |
US10044503B1 (en) | 2012-03-27 | 2018-08-07 | Amazon Technologies, Inc. | Multiple authority key derivation |
US10116440B1 (en) | 2016-08-09 | 2018-10-30 | Amazon Technologies, Inc. | Cryptographic key management for imported cryptographic keys |
US10122689B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Load balancing with handshake offload |
US10122692B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Handshake offload |
US10181953B1 (en) | 2013-09-16 | 2019-01-15 | Amazon Technologies, Inc. | Trusted data verification |
CN109447791A (en) * | 2018-11-09 | 2019-03-08 | 北京邮电大学 | A kind of funds transaction method and device based on block chain |
US10243945B1 (en) | 2013-10-28 | 2019-03-26 | Amazon Technologies, Inc. | Managed identity federation |
US10326597B1 (en) | 2014-06-27 | 2019-06-18 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
US10355856B2 (en) * | 2015-06-09 | 2019-07-16 | Nippon Telegraph And Telephone Corporation | Key exchange method, key exchange system, key distribution device, communication device, and program |
US20190253235A1 (en) * | 2018-11-07 | 2019-08-15 | Alibaba Group Holding Limited | Blockchain data protection using homomorphic encryption |
US10397002B2 (en) * | 2017-02-10 | 2019-08-27 | International Business Machines Corporation | Signature scheme for homomorphic message encoding functions |
US10652019B1 (en) * | 2019-08-28 | 2020-05-12 | Qed-It Systems Ltd. | Atomic swap using zero-knowledge proofs, and applications thereof |
US10671738B2 (en) * | 2016-11-15 | 2020-06-02 | Adobe, Inc. | Controlled publication of sensitive content |
US10700850B2 (en) | 2018-11-27 | 2020-06-30 | Alibaba Group Holding Limited | System and method for information protection |
US10715500B2 (en) | 2018-11-27 | 2020-07-14 | Alibaba Group Holding Limited | System and method for information protection |
US10721184B2 (en) | 2010-12-06 | 2020-07-21 | Amazon Technologies, Inc. | Distributed policy enforcement with optimizing policy transformations |
US10726657B2 (en) | 2018-11-27 | 2020-07-28 | Alibaba Group Holding Limited | System and method for information protection |
US10771255B1 (en) | 2014-03-25 | 2020-09-08 | Amazon Technologies, Inc. | Authenticated storage operations |
US10938549B2 (en) | 2018-11-27 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US11032077B2 (en) * | 2018-09-20 | 2021-06-08 | Advanced New Technologies Co., Ltd. | Blockchain-based transaction method and apparatus, and remitter device |
US11050549B2 (en) | 2018-09-30 | 2021-06-29 | Advanced New Technologies Co., Ltd. | Blockchain-based transaction method and apparatus, and remitter device |
US11080694B2 (en) | 2018-11-27 | 2021-08-03 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US11102189B2 (en) | 2011-05-31 | 2021-08-24 | Amazon Technologies, Inc. | Techniques for delegation of access privileges |
US11102184B2 (en) | 2018-11-27 | 2021-08-24 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US11144918B2 (en) | 2018-08-06 | 2021-10-12 | Advanced New Technologies Co., Ltd. | Method, apparatus and electronic device for blockchain transactions |
US11295381B2 (en) * | 2017-12-29 | 2022-04-05 | Advanced New Technologies Co., Ltd. | Data auditing method and device |
US11720688B2 (en) * | 2016-06-13 | 2023-08-08 | CloudMode, LLC | Secure initiation and transfer of a cryptographic database and/or a cryptographic unit |
US11810095B1 (en) * | 2012-02-19 | 2023-11-07 | Charles Schwab & Co., Inc. | System and method for mobile payments |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109255247B (en) | 2018-08-14 | 2020-08-14 | 阿里巴巴集团控股有限公司 | Multi-party security calculation method and device and electronic equipment |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050071657A1 (en) * | 2003-09-30 | 2005-03-31 | Pss Systems, Inc. | Method and system for securing digital assets using time-based security criteria |
US20070061569A1 (en) * | 2005-09-15 | 2007-03-15 | Samsung Electronics Co., Ltd. | Inter-entity coupling method, apparatus and system for service protection |
US20070234046A1 (en) * | 2006-03-30 | 2007-10-04 | Murata Kikai Kabushiki Kaisha | Communication Device with Revocation List Acquiring Function |
US20080044027A1 (en) * | 2003-10-29 | 2008-02-21 | Koninklijke Philips Electrnics, N.V. | System and Method of Reliable Foward Secret Key Sharing with Physical Random Functions |
US7596530B1 (en) * | 2008-09-23 | 2009-09-29 | Marcelo Glasberg | Method for internet payments for content |
-
2009
- 2009-10-27 US US12/606,710 patent/US8744077B2/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050071657A1 (en) * | 2003-09-30 | 2005-03-31 | Pss Systems, Inc. | Method and system for securing digital assets using time-based security criteria |
US20080044027A1 (en) * | 2003-10-29 | 2008-02-21 | Koninklijke Philips Electrnics, N.V. | System and Method of Reliable Foward Secret Key Sharing with Physical Random Functions |
US20070061569A1 (en) * | 2005-09-15 | 2007-03-15 | Samsung Electronics Co., Ltd. | Inter-entity coupling method, apparatus and system for service protection |
US20070234046A1 (en) * | 2006-03-30 | 2007-10-04 | Murata Kikai Kabushiki Kaisha | Communication Device with Revocation List Acquiring Function |
US7596530B1 (en) * | 2008-09-23 | 2009-09-29 | Marcelo Glasberg | Method for internet payments for content |
Cited By (97)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8825555B2 (en) * | 2010-06-30 | 2014-09-02 | International Business Machines Corporation | Privacy-sensitive sample analysis |
US20120005098A1 (en) * | 2010-06-30 | 2012-01-05 | International Business Machines Corporation | Privacy-sensitive sample analysis |
US11411888B2 (en) | 2010-12-06 | 2022-08-09 | Amazon Technologies, Inc. | Distributed policy enforcement with optimizing policy transformations |
US10721184B2 (en) | 2010-12-06 | 2020-07-21 | Amazon Technologies, Inc. | Distributed policy enforcement with optimizing policy transformations |
DE102012206341B4 (en) | 2011-04-29 | 2022-06-23 | International Business Machines Corporation | Joint encryption of data |
US8654975B2 (en) | 2011-04-29 | 2014-02-18 | International Business Machines Corporation | Joint encryption of data |
US8661240B2 (en) | 2011-04-29 | 2014-02-25 | International Business Machines Corporation | Joint encryption of data |
US11102189B2 (en) | 2011-05-31 | 2021-08-24 | Amazon Technologies, Inc. | Techniques for delegation of access privileges |
US9197409B2 (en) | 2011-09-29 | 2015-11-24 | Amazon Technologies, Inc. | Key derivation techniques |
US9178701B2 (en) | 2011-09-29 | 2015-11-03 | Amazon Technologies, Inc. | Parameter based key derivation |
US9954866B2 (en) | 2011-09-29 | 2018-04-24 | Amazon Technologies, Inc. | Parameter based key derivation |
US10721238B2 (en) | 2011-09-29 | 2020-07-21 | Amazon Technologies, Inc. | Parameter based key derivation |
US11356457B2 (en) | 2011-09-29 | 2022-06-07 | Amazon Technologies, Inc. | Parameter based key derivation |
US9203613B2 (en) | 2011-09-29 | 2015-12-01 | Amazon Technologies, Inc. | Techniques for client constructed sessions |
US11810095B1 (en) * | 2012-02-19 | 2023-11-07 | Charles Schwab & Co., Inc. | System and method for mobile payments |
US11146541B2 (en) | 2012-03-27 | 2021-10-12 | Amazon Technologies, Inc. | Hierarchical data access techniques using derived cryptographic material |
US10356062B2 (en) | 2012-03-27 | 2019-07-16 | Amazon Technologies, Inc. | Data access control utilizing key restriction |
US10044503B1 (en) | 2012-03-27 | 2018-08-07 | Amazon Technologies, Inc. | Multiple authority key derivation |
US9872067B2 (en) | 2012-03-27 | 2018-01-16 | Amazon Technologies, Inc. | Source identification for unauthorized copies of content |
US9215076B1 (en) | 2012-03-27 | 2015-12-15 | Amazon Technologies, Inc. | Key generation for hierarchical data access |
US9305177B2 (en) | 2012-03-27 | 2016-04-05 | Amazon Technologies, Inc. | Source identification for unauthorized copies of content |
US10425223B2 (en) | 2012-03-27 | 2019-09-24 | Amazon Technologies, Inc. | Multiple authority key derivation |
US9660972B1 (en) | 2012-06-25 | 2017-05-23 | Amazon Technologies, Inc. | Protection from data security threats |
US9258118B1 (en) | 2012-06-25 | 2016-02-09 | Amazon Technologies, Inc. | Decentralized verification in a distributed system |
US10904233B2 (en) | 2012-06-25 | 2021-01-26 | Amazon Technologies, Inc. | Protection from data security threats |
US9407440B2 (en) | 2013-06-20 | 2016-08-02 | Amazon Technologies, Inc. | Multiple authority data security and access |
US10090998B2 (en) | 2013-06-20 | 2018-10-02 | Amazon Technologies, Inc. | Multiple authority data security and access |
US11115220B2 (en) | 2013-07-17 | 2021-09-07 | Amazon Technologies, Inc. | Complete forward access sessions |
US9521000B1 (en) | 2013-07-17 | 2016-12-13 | Amazon Technologies, Inc. | Complete forward access sessions |
US11258611B2 (en) | 2013-09-16 | 2022-02-22 | Amazon Technologies, Inc. | Trusted data verification |
US10181953B1 (en) | 2013-09-16 | 2019-01-15 | Amazon Technologies, Inc. | Trusted data verification |
US9311500B2 (en) | 2013-09-25 | 2016-04-12 | Amazon Technologies, Inc. | Data security using request-supplied keys |
US9819654B2 (en) | 2013-09-25 | 2017-11-14 | Amazon Technologies, Inc. | Resource locators with keys |
US10037428B2 (en) | 2013-09-25 | 2018-07-31 | Amazon Technologies, Inc. | Data security using request-supplied keys |
WO2015048042A1 (en) * | 2013-09-25 | 2015-04-02 | Amazon Technologies, Inc. | Data security using request-supplied keys |
US10936730B2 (en) | 2013-09-25 | 2021-03-02 | Amazon Technologies, Inc. | Data security using request-supplied keys |
US9237019B2 (en) | 2013-09-25 | 2016-01-12 | Amazon Technologies, Inc. | Resource locators with keys |
US11146538B2 (en) | 2013-09-25 | 2021-10-12 | Amazon Technologies, Inc. | Resource locators with keys |
US10412059B2 (en) | 2013-09-25 | 2019-09-10 | Amazon Technologies, Inc. | Resource locators with keys |
US11777911B1 (en) | 2013-09-25 | 2023-10-03 | Amazon Technologies, Inc. | Presigned URLs and customer keying |
US10243945B1 (en) | 2013-10-28 | 2019-03-26 | Amazon Technologies, Inc. | Managed identity federation |
US9420007B1 (en) | 2013-12-04 | 2016-08-16 | Amazon Technologies, Inc. | Access control using impersonization |
US11431757B2 (en) | 2013-12-04 | 2022-08-30 | Amazon Technologies, Inc. | Access control using impersonization |
US10673906B2 (en) | 2013-12-04 | 2020-06-02 | Amazon Technologies, Inc. | Access control using impersonization |
US9906564B2 (en) | 2013-12-04 | 2018-02-27 | Amazon Technologies, Inc. | Access control using impersonization |
US9699219B2 (en) | 2013-12-04 | 2017-07-04 | Amazon Technologies, Inc. | Access control using impersonization |
US20160301682A1 (en) * | 2014-01-07 | 2016-10-13 | Amazon Technologies, Inc. | Distributed passcode verification system |
US10855690B2 (en) | 2014-01-07 | 2020-12-01 | Amazon Technologies, Inc. | Management of secrets using stochastic processes |
US9985975B2 (en) | 2014-01-07 | 2018-05-29 | Amazon Technologies, Inc. | Hardware secret usage limits |
US9369461B1 (en) | 2014-01-07 | 2016-06-14 | Amazon Technologies, Inc. | Passcode verification using hardware secrets |
US9967249B2 (en) * | 2014-01-07 | 2018-05-08 | Amazon Technologies, Inc. | Distributed passcode verification system |
US9292711B1 (en) | 2014-01-07 | 2016-03-22 | Amazon Technologies, Inc. | Hardware secret usage limits |
US9374368B1 (en) | 2014-01-07 | 2016-06-21 | Amazon Technologies, Inc. | Distributed passcode verification system |
US9262642B1 (en) | 2014-01-13 | 2016-02-16 | Amazon Technologies, Inc. | Adaptive client-aware session security as a service |
US9270662B1 (en) | 2014-01-13 | 2016-02-23 | Amazon Technologies, Inc. | Adaptive client-aware session security |
US10313364B2 (en) | 2014-01-13 | 2019-06-04 | Amazon Technologies, Inc. | Adaptive client-aware session security |
US10771255B1 (en) | 2014-03-25 | 2020-09-08 | Amazon Technologies, Inc. | Authenticated storage operations |
US20150295710A1 (en) * | 2014-04-11 | 2015-10-15 | Thomson Licensing | Paillier-based blind decryption methods and devices |
US9882900B2 (en) | 2014-06-26 | 2018-01-30 | Amazon Technologies, Inc. | Mutual authentication with symmetric secrets and signatures |
US9258117B1 (en) | 2014-06-26 | 2016-02-09 | Amazon Technologies, Inc. | Mutual authentication with symmetric secrets and signatures |
US10375067B2 (en) | 2014-06-26 | 2019-08-06 | Amazon Technologies, Inc. | Mutual authentication with symmetric secrets and signatures |
US11546169B2 (en) | 2014-06-27 | 2023-01-03 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
US11811950B1 (en) | 2014-06-27 | 2023-11-07 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
US10326597B1 (en) | 2014-06-27 | 2019-06-18 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
US10355856B2 (en) * | 2015-06-09 | 2019-07-16 | Nippon Telegraph And Telephone Corporation | Key exchange method, key exchange system, key distribution device, communication device, and program |
US10122692B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Handshake offload |
US10122689B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Load balancing with handshake offload |
US11720688B2 (en) * | 2016-06-13 | 2023-08-08 | CloudMode, LLC | Secure initiation and transfer of a cryptographic database and/or a cryptographic unit |
US11184155B2 (en) | 2016-08-09 | 2021-11-23 | Amazon Technologies, Inc. | Cryptographic key management for imported cryptographic keys |
US10116440B1 (en) | 2016-08-09 | 2018-10-30 | Amazon Technologies, Inc. | Cryptographic key management for imported cryptographic keys |
US10671738B2 (en) * | 2016-11-15 | 2020-06-02 | Adobe, Inc. | Controlled publication of sensitive content |
US10397003B2 (en) * | 2017-02-10 | 2019-08-27 | International Business Machines Corporation | Signature scheme for homomorphic message encoding functions |
US10397002B2 (en) * | 2017-02-10 | 2019-08-27 | International Business Machines Corporation | Signature scheme for homomorphic message encoding functions |
US11295381B2 (en) * | 2017-12-29 | 2022-04-05 | Advanced New Technologies Co., Ltd. | Data auditing method and device |
US11144918B2 (en) | 2018-08-06 | 2021-10-12 | Advanced New Technologies Co., Ltd. | Method, apparatus and electronic device for blockchain transactions |
US11295303B2 (en) | 2018-08-06 | 2022-04-05 | Advanced New Technologies Co., Ltd. | Method, apparatus and electronic device for blockchain transactions |
US11032077B2 (en) * | 2018-09-20 | 2021-06-08 | Advanced New Technologies Co., Ltd. | Blockchain-based transaction method and apparatus, and remitter device |
US11050549B2 (en) | 2018-09-30 | 2021-06-29 | Advanced New Technologies Co., Ltd. | Blockchain-based transaction method and apparatus, and remitter device |
AU2018348319B2 (en) * | 2018-11-07 | 2020-10-01 | Advanced New Technologies Co., Ltd. | Blockchain data protection using homomorphic encryption |
US20190253235A1 (en) * | 2018-11-07 | 2019-08-15 | Alibaba Group Holding Limited | Blockchain data protection using homomorphic encryption |
US10615960B2 (en) * | 2018-11-07 | 2020-04-07 | Alibaba Group Holding Limited | Blockchain data protection using homomorphic encryption |
TWI718585B (en) * | 2018-11-07 | 2021-02-11 | 開曼群島商創新先進技術有限公司 | Blockchain data protection using homomorphic encryption |
CN109447791A (en) * | 2018-11-09 | 2019-03-08 | 北京邮电大学 | A kind of funds transaction method and device based on block chain |
US11277389B2 (en) | 2018-11-27 | 2022-03-15 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10715500B2 (en) | 2018-11-27 | 2020-07-14 | Alibaba Group Holding Limited | System and method for information protection |
US11282325B2 (en) | 2018-11-27 | 2022-03-22 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10885735B2 (en) | 2018-11-27 | 2021-01-05 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10892888B2 (en) | 2018-11-27 | 2021-01-12 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10748370B2 (en) | 2018-11-27 | 2020-08-18 | Alibaba Group Holding Limited | System and method for information protection |
US10726657B2 (en) | 2018-11-27 | 2020-07-28 | Alibaba Group Holding Limited | System and method for information protection |
US11218455B2 (en) | 2018-11-27 | 2022-01-04 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10700850B2 (en) | 2018-11-27 | 2020-06-30 | Alibaba Group Holding Limited | System and method for information protection |
US11080694B2 (en) | 2018-11-27 | 2021-08-03 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US11127002B2 (en) | 2018-11-27 | 2021-09-21 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10938549B2 (en) | 2018-11-27 | 2021-03-02 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US11102184B2 (en) | 2018-11-27 | 2021-08-24 | Advanced New Technologies Co., Ltd. | System and method for information protection |
US10652019B1 (en) * | 2019-08-28 | 2020-05-12 | Qed-It Systems Ltd. | Atomic swap using zero-knowledge proofs, and applications thereof |
Also Published As
Publication number | Publication date |
---|---|
US8744077B2 (en) | 2014-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8744077B2 (en) | Cryptographic encoding and decoding of secret data | |
Dodis et al. | Breaking and repairing optimistic fair exchange from PODC 2003 | |
US6282295B1 (en) | Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers | |
Park et al. | Constructing fair-exchange protocols for E-commerce via distributed computation of RSA signatures | |
US5606617A (en) | Secret-key certificates | |
US6389136B1 (en) | Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys | |
US6202150B1 (en) | Auto-escrowable and auto-certifiable cryptosystems | |
US7730319B2 (en) | Provisional signature schemes | |
US8654975B2 (en) | Joint encryption of data | |
Frankel et al. | Fair off-line e-cash made easy | |
US8015398B2 (en) | Set membership proofs in data processing systems | |
EP2686978B1 (en) | Keyed pv signatures | |
US6243466B1 (en) | Auto-escrowable and auto-certifiable cryptosystems with fast key generation | |
CN102301643B (en) | Methods and system for managing dynamic cryptographic credentials in data processing system | |
JP3513324B2 (en) | Digital signature processing method | |
AU8656498A (en) | Auto-recoverable auto-certifiable cryptosystems | |
Camenisch et al. | Rethinking accountable privacy supporting services | |
EP2384563B1 (en) | Verification of data items in data processing systems | |
Shao et al. | Certificate‐based verifiably encrypted RSA signatures | |
Persiano et al. | A secure and private system for subscription-based remote services | |
Xu et al. | Timed‐release oblivious transfer | |
Bultel et al. | Improving the efficiency of report and trace ring signatures | |
Fan et al. | Anonymous fair transaction protocols based on electronic cash | |
Camenisch et al. | Accountable privacy supporting services | |
Sakuraii et al. | A key escrow system with protecting user's privacy by blind decoding |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION,NEW YO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CAMENISCH, JAN LEONHARD;GROSS, THOMAS R;HEYDT-BENJAMIN, THOMAS SCOTT;SIGNING DATES FROM 20091009 TO 20091026;REEL/FRAME:023757/0416 Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CAMENISCH, JAN LEONHARD;GROSS, THOMAS R;HEYDT-BENJAMIN, THOMAS SCOTT;SIGNING DATES FROM 20091009 TO 20091026;REEL/FRAME:023757/0416 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551) Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20220603 |