WO2021168497A1 - Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts - Google Patents
Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts Download PDFInfo
- Publication number
- WO2021168497A1 WO2021168497A1 PCT/AU2020/050189 AU2020050189W WO2021168497A1 WO 2021168497 A1 WO2021168497 A1 WO 2021168497A1 AU 2020050189 W AU2020050189 W AU 2020050189W WO 2021168497 A1 WO2021168497 A1 WO 2021168497A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- statement
- recipient
- statements
- key
- issuer
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/383—Anonymous user system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0224—Discounts or incentives, e.g. coupons or rebates based on user history
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0613—Third-party assisted
- G06Q30/0615—Anonymizing
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- 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
-
- 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/0841—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 Diffie-Hellman or related key agreement protocols
-
- 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
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
- Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
- Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
- Y04S40/20—Information technology specific aspects, e.g. CAD, simulation, modelling, system security
Definitions
- This invention relates to cryptography. To be more specific, this invention pertains to zero knowledge deduction of rules and trends against an encrypted history of statements (like receipts or scripts).
- the art does not include a solution for digital marketing and loyalty management in which the marketing or loyalty management intermediary remains unaware of individuals’ private purchasing behaviour but yet remains capable of personalizing offers available to individuals based on their purchase history.
- privacy and individualization of marketing are difficult to co-exist since without knowledge over one’s purchase history, it becomes impossible to personalize offers derived from such a history. This leads to an individualization-privacy paradox with opposing requirements.
- the population of an individual’s purchase history is carried out in their private space which is provided and protected by an application and remains cryptographically isolated from the universe.
- the purchase history is populated by transferring statements, like receipts, in an end-to-end encrypted fashion that makes it impossible for the intermediary that develops such an application and transfers the statements between statement issuers and recipients from having access to the contents of the statements.
- an end-to-end encrypted statement transfer protocol is used for transferring statements which includes steps, messages, key generation, key agreement and key rotation steps as well as novel digital signatures and transaction marking schemes that assure recipients’ privacy and anonymity and the tamper-resistance, correctness and non-repudiability against the statements, that are fundamental requirements in statement digitization; all without the recipient having to provide identifying details to statement issuers.
- software development kits SDKs are provided to be used on each statement issuing station (e.g. a point-of-sale system or medical scripting system) to facilitate the end-to-end encryption and transfer of statements from such stations to recipients who are using application(s) to receive their statements.
- the statement issuers can use a portal to define their abstract loyalty and marketing rules that are then broadcasted to all statement recipients’ applications. These rules define the conditions under which an offer becomes applicable to someone (e.g. customers who buy n number of item x and m number of item y can receive p% discount for item z in the next 30 days).
- the application in return, would download all such rules based on recipients’ and issuers’ preferences and performs a local query and analysis against the recipients’ purchase history to check if the broadcasted conditions are fulfilled by the recipient, in which case, the application will announce the mined offer to the recipient privately without the intermediary ever being disclosed the purchase history or the mined offers.
- the recipients’ app and the issuers’ portal start an end-to- end encrypted conversation to verify purchase proofs and the applicability of the claimed offers, all with intermediary’s zero knowledge against the contents of purchase history and claimed offers.
- the recipient and issuer must generate multiple asymmetric cryptographic keys the public component of which must be shared with the other parties.
- the statement transfer process is started by issuers which involves some form of scanning performed by the recipient (e.g. QR codes, bar codes or RFID scans) to create a private communication channel address.
- the statement transfer is started by recipients which may involve some form of scanning performed by statement issuers (e.g. QR codes, bar codes or RFID scans).
- the statement transfer is started by recipients without the need of any extra forms of scans or interactions between the statement issuers or recipients both of whom develop a common communication channel address from electronic transaction identifiers (e.g. payment identifiers) which the recipient becomes aware of through a different channel (e.g.
- the recipient can generate their communication channel address from transaction identifiers and then utilize intermediary offline servers to upload their public keys which, later on, will be downloaded by the issuer who on their own, without needing to perform a real-time conversation with recipients, calculate the same communication channel address from transaction identifiers.
- the issuer can then generate their own cryptographic keys, perform end-to-end encryption against statement data and upload the encrypted form of the statement using the same derived communication channel address, which later on, gets downloaded and extracted by the recipient, hence enabling a delayed but seamless transfer of statements to recipients that does not involve any additional scanning or interaction except for the payment interaction.
- Figure 1 is a high-level conceptual model for secure statement transfer protocol.
- Figure 2 demonstrates the data flow and actions showing how individualized loyalty and marketing deals are “mined” against the data that no one except the recipient has access to.
- Figure 3 illustrates the issuer-initiated end-to-end encrypted transfer of statements in secure statement transfer protocol.
- Figure 4 illustrates the recipient-initiated mode of end-to-end encrypted statement transfer using a temporary secure statement wallet for each statement.
- Figure 5 illustrates the recipient-initiated mode of end-to-end encrypted statement transfer using a reusable secure statement wallet and card issuer integration for seamless statement transfer.
- Figure 6 illustrates the process to create a private key vault for an issuer's portal user and saving the private RSA key of the vault in encrypted form based on a master password for portability.
- Figure 7 illustrates how statements get encrypted with independent keys and uploaded to issuer’s portal with keys persisted in each issuer portal user’s independent key vault.
- Figure 8 illustrates how the encryption key for each statement is looked up from the recipient’s key vault in the issuer’s portal in encrypted form, and then gets decrypted using recipient’s master password that decrypts the private RSA key of a user’s key vault.
- Figure 9 illustrates digital signature generation in secure statement transfer protocol.
- Figure 10 illustrates transaction marking in secure statement transfer protocol.
- Figure 11 illustrates the data flow and how recipient's copy of end-to-end encrypted statements become portably accessible through the Recipients’ Portal under web without the need for a mobile or desktop application.
- the inventor hereby proposes a novel method for individualization of marketing and loyalty offers/deals applicable to individuals without the individual’s purchase history ever being known by any parties other than themselves.
- the present invention is described in enabling detail in the following examples, which may represent more than one embodiment of the present invention.
- the foundation of the proposed invention for zero-knowledge anonymously-individualized marketing and loyalty management is the population of an individual’s purchase history in their private space 103, the access to which has been made cryptographically impossible for all parties except the individual since such access has been made dependent on owning private cryptographic keys only known to the individual.
- the population of one’s private purchase history in their private space is done via the end-to-end encrypted transfer of their statements (e.g. receipts, pharmaceutical scripts etc%) from statement issuers 101 to their private space 103.
- a statement recipient's space 103 and statement issuer's space 102 are private and isolated in the sense that access to data in these spaces is dependent on owning private cryptographic keys that are only known to their respective owners and that there are controls in place to ensure data does not leave these spaces without the knowledge of their owners. Accordingly, a statement (e.g. receipt or script) issuer 101 operating in statement issuer's space 102 can utilize software development kit (SDK) libraries 105 to perform end-to-end encryption on the statement data before the data leaves the statement issuer's space 102. Similarly, a statement recipient 104 owning and operating in statement recipient's space 103 can use SDK libraries 106 to perform end-to-end decryption of the statement data they like to receive from statement issuers 110.
- SDK software development kit
- This transfer of data requires the exchange of public information through the public internet network 108 and may or may not be facilitated via a data transfer intermediary.
- the communication protocol between the issuer and recipient will assure the complete isolation of access against the statement data outside of statement recipient's space 103 and statement issuer's space 102 despite the exchange of public information through the intermediary or the public internet network 108.
- the statement issuing systems 112 instead of the statement issuing systems 112 (e.g.
- Point of Sale systems or medical scripting systems being changed to integrate with SKDs to submit a statement to a recipient, they can still transfer statements to recipients by sending the statement print job to a virtual printer driver 111 that extracts the contents of the statements by simulating a real physical printing process to the issuing system(s), eliminating the need for such systems to have to be changed to be equipped with smart digital statement generation features.
- the virtual print driver can then compile a statement from the intercepted data and make calls to SDKs to transfer the end-to-end encrypted statement to its recipient without the issuing system having to be changed hence promoting a zero-change integration model to facilitate easier adoption in the industry.
- a statement issuer 201 operating a statement issuing system e.g. a point of sale or medical scripting system etc...) 204 in statement issuer's space 202, can use SDK libraries 205 and its local secure storage 206 (making use of local hardware-backed key-chain storage to securely maintain private cryptographic keys 214) to perform end-to-end encryption on the statement data and send them to a recipient's app 213.
- Recipient's app then utilizes its own secure storage 207 (making use of local hardware-backed key-chain storage) to maintain private cryptographic keys 215 to perform end-to-end decryption against the received encrypted statement and save it locally, privately and securely.
- a statement issuer 208 can then define abstract anonymous loyalty management and marketing rules and available offers 216 (e.g. customers who have purchased item x in the last y days, receive z% discount against any new purchase). These rules/offers are designed in issuer's portal 209 and are then broadcast to all recipient's apps 218 (depending on preferences set by the issuer or the recipient).
- a local rules and patterns engine 210 can use the broadcast rules to perform applicability checking 211 of such rules against the recipient's private list of statements, saved in secure storage 207.
- This applicability checking can be performed by querying the local private purchase history, locally, without sending out any information.
- This querying can include the identifier of the advertising statement issuer (i.e. offer provider) and the identifiers of all items included in the conditions of the included marketing and loyalty rules.
- the applicability engine will run the relevant query conditions against the local private statement history to check if the rule conditions are fulfilled or not.
- the rule Upon applicability of a rule or the extraction of patterns from the private statement history locally, the rule is then materialized/mined into a deal/offer 212 and the recipient is then informed of its creation or mining.
- Full client-side private processing of private statement history using the local rules and patterns engine 210 may not require the download of any set of rules in which case patterns are mined and offers are generated by deducting compatibility or predicting future needs against the private data without such private data ever leaving the recipient’s space.
- This applicability checking may or may not be performed using Artificial Intelligence (Al) enabled engines that may receive and save a history of previous learnings locally in the recipient’s space without the recipient’s private statement history ever leaving the recipient’s private space, or without such an Al engine needing to rely upon local private information for training or any other purposes.
- Alternate analysis models may depend on the category identifiers of each statement item as well as statistical models to offer applicable offers of interest, or, any other applicable means or methods of local processing and analysis of statement history. If a data transfer intermediary transfers statement data, they will not have any way to know which deals have been mined due to not having access to the private statement history despite having access to the public abstract anonymous loyalty and marketing rules.
- the secure statement transfer protocol and its digital signatures can be used to establish proof of purchase and proof of fulfillment against the requirements of abstract anonymous loyalty and marketing rules when a "claim" is made by a recipient against a rule.
- the recipient's app is a native app running on a private device (e.g. a mobile, tablet or desktop)
- the generation of private cryptographic keys 215 happens on the client side without sending any private keys to any external servers or repositories.
- an end-to-end encrypted transfer protocol for statements can be used which assures that a) the statement history is private and protected; and b) anyone other than the issuer and the recipient will have zero knowledge of the contents of the statements.
- the following message types can be transferred between the statement issuer and statement recipient: 1) “Statement Transfer Request” which is a pre-handshake message sent from the Issuer to the Recipient, only applicable in cases where the Issuer is the initiator of the transfer process (i.e. Issuer-Initiated Transfer mode), highlighting that there is a Statement that the issuer needs to transfer to the recipient.
- the details in the Statement Transfer Request are used to find the public cryptographic keys that belong to the issuer for the next stages of the protocol.
- issuer also comes with issuer’s digital signatures for the Statement-to-be-transferred used to verify the request has been created by the right issuer.
- the physical transfer of the request could be performed through the generation of a QR code, or bar code by the issuer which then gets scanned by the recipient, or through radio frequency scan which is performed by the issuer leading to the transfer of information to the recipient, or through any other possible means and methods.
- 2) “Key Exchange Message” which in the Issuer-Initiated mode, is a response to a Statement Transfer Request. In the Recipient-Initiated mode, this message (or messages) are the first messages in the transfer process transferred from the recipient to the issuer through different means (e.g. upload to an intermediary server to be picked up by the issuer at later stages or times).
- the Key Exchange Message also includes the random communication address on which the recipient has started listening on in order to receive the next messages from the issuer.
- the issuer uses the included public cryptographic keys alongside with its own public keys to derive symmetric cryptographic keys which includes a) Statement Encryption Key which will be used for encrypting the Statement; b) Statement Encryption Initialization Vector (IV) which will be used in the symmetric encryption of the Statement; c) Statement Encryption Mac Key which will be used to digitally sign the physical message to be checked for integrity by the recipient; d) Recipient’s Private Statement Signing Mac Key, which will be used by the recipient to privately sign the Statement which leads to the generation of Recipient’s Digital Signature; d) Statement Signing Message Encryption Key and Initialization Vector which will be used to encrypt the upcoming Statement Signing Message which is sent from the Recipient to the issue
- “Statement Transfer Message” which is the response from the issuer to the recipient after receiving the Key Exchange Message from the recipient and includes symmetrically-encrypted statement data and authenticity signatures. The handshake assures both parties have generated the same symmetric encryption keys throughout the process by sharing multiple public keys through a public communication channel to agree upon common symmetric encryption keys.
- “Statement Signing Message” which is an encrypted message used to send back the Recipient’s Digital Signature as well as a one way Transaction Marker to the issuer for marking the transaction. It is also used as an acknowledgement for the issuer to ensure the Statement has been successfully received by the recipient.
- the Issuer initiates the Statement transfer process as illustrated in Figure 3.
- the handshake process starts with the generation of a Statement Transfer Request by the Issuer and then making it available to the Recipient.
- Examples include 1. Cases where the Issuer generates the Statement Transfer Request and provides them to the Recipient via QR codes or bar codes or other data transfer mechanisms like radio frequent scans, RFID-enabled scans, Near-Field Communication (NFC) schemes, including 1.1. Cases that involve payments made with cash, or, 1.2. Cases where there is a need for near-real time transfer of Statements (e.g.
- a Statement Issuer 301 compiles and sends a statement transfer request 303 to a statement recipient 302 which in return looks up the issuer's pre-key bundle 304 which leads to the return of the pre-key bundle and the deletion of the one-time pre-keys 305.
- the issuer's pre-key bundle 306 is used to compile and send a key exchange message 307 by the statement issuer 302, upon the reception of which the statement issuer then compiles and sends a statement transfer message 308 to the recipient.
- the recipient then compiles a statement signing message 309 back to the issuer which leads to the update of state by the issuer 310.
- the recipient initiates the statement transfer process.
- the handshake starts from the “Key Exchange Message” being transferred by the Recipient to the Issuer.
- This mode involves the creation of either “temporary once-off” or “reusable statement wallets” that could be viewed as offline “buckets” in which encrypted statements can be placed in, with only the recipient being able to access them and decrypt the statements, as will be described in next chapters.
- Example scenarios that the Recipient-Initiated Transfer Model can be helpful in include the followings: 1. Cases with electronic payment methods where the Recipient has access to a unique transaction identifier before the Issuer.
- This scenario can include cases where a mobile application in Statement Recipient’s Space processes the payment and generates such payment identifiers (e.g. via providing Near-Field Communication (NFC) centric Flost Card Emulation (FICE), or integration with other payment methods like what is used in payment systems like ApplePay and GooglePay or SamsungPay), in which case such identifiers like Authorization Request Cryptogram (ARQCs) or other transaction related details are created as part of payment processing and can be known by the recipient.
- NFC Near-Field Communication
- FICE Flost Card Emulation
- ARQCs Authorization Request Cryptogram
- Another example of this case relates to a situation in which such identifiers can be passed from an electronic payment card issuer via systems like internet banking systems to the recipient’s app (examples include but are not limited to by URI schemas and inter-process communication schemes monitored by and listed to by the recipient’s app and called by internet banking systems or apps).
- This case can be handled by the creation of a once-off secure statement wallet by the recipient whose address can be derived from the transaction identifiers by both the recipient and the issuer.
- Examples include 2.1 via QR codes or bar codes or other data transfer mechanisms like radio frequent scans, RFID-enabled scans, Near-Field Communication schemes that are scanned by the Issuer.
- 2.2 via providing a once-off or reusable “secure statement wallet address”, like 2.2.1 as part of an online electronic purchase form where the “secure statement wallet address” can be entered in to facilitate the reception of a statement in offline mode; 2.2.2 where the recipient physically provides their “secure statement wallet address” to the issuer upon making a purchase (e.g. when no electronic device (e.g. mobile phones) is available to them but they need an electronic copy of their statements);
- a Secure Statement Wallet Address 408 is generated as follows:
- the recipient then creates a temporary secure statement wallet 409 on an intermediary server and uploads a Key Exchange Message into it; 3)
- the issuer receives the same payment identifier 411 from the card processing unit (e.g. Point of Sale electronic card reader terminal or medical card transaction processing device). It calculates the same Secure Statement Wallet Address as follows:
- the issuer then downloads the Key Exchange Message which was uploaded by the recipient.
- It then uses the Statement Transfer Key and Ephemeral Session Key of the Key Exchange Message 415 (all described in details in following chapters) alongside its own public identity key and signed pre-key and one-time pre-key to calculate a range of symmetric encryption keys which will be used to encrypt the statement and compile a Statement Transfer Message 417, which is then uploaded to the same Secure Statement Wallet using the address calculated before.
- the recipient periodically (or using an asynchronous publish-subscribe mechanism) checks 419 for new Statement Transfer Messages delivered to the temporary Secure Statement Wallet it created.
- Recipient-Initiated Transfer using Reusable Secure Statement Wallets can include the following steps: 1) The Recipient 501 creates a reusable secure statement wallet 503 on an intermediary server 504, to which issuers can send statements using a Secure Statement Wallet Address. This address can be either selected by the user which will have to be unique (e.g. for cases where the recipient can supply their Secure Statement Wallet Address to an issuer to send the statement to in an offline mode), or, it can be created for an electronic payment, health or health card that the recipient owns. 2) Recipient Registration (e.g.
- a user identifier like a Payment or Health Card 502 which is the process to create or derive an address for a reusable secure Statement wallet for a user identifier, which can be extracted from a payment or health card, includes the following steps: 2.1) The card issuing bank or organization generates a random identifier for the recipient (which we name Random Recipient ID) and shares it with the card holder that would, in all other cases, be absolutely useless to own by other parties. 2.2) The recipient then introduces their card to the intermediary by supplying the Random Recipient ID and the name or identifier of the issuing bank or organization.
- the intermediary attempts to verify the Random Recipient ID by referring to the card issuing bank or organization through some verification APIs that should return a Time-Bound Random Verification Id. The intermediary then persists the Time-Bound Random Verification Id against the Random Recipient ID.
- the organization Upon receiving an API call, the organization would need to use on-file card holder’s mobile numbers of email addresses to deliver the same Time-Bound Random Verification Id to the mobile or email box or other applicable communication channel of the relevant card holder.
- the card holder would have to supply the received Time-Bound Random Verification Id to the intermediary.
- the intermediary in return, would compare the supplied verification id with the Time-Bound Random Verification Id it persisted in previous steps against the Random Recipient ID. If they are equal, the supplied Random Recipient ID is deemed correct. 3) The Address of a reusable Secure Statement Wallet for a payment card would then be calculated as the deterministic one-way hash of Random Recipient ID using SHA512, as follows:
- Random Receipient ID Lookup API (Unique Transaction Identifier)
- the Secure Statement Wallet Address for a card can be derived from card details (e.g. in case of a payment card, via concatenation of Personal Account Number, Expiry, Card Holder Name and all other details on the card, or, in case of a health card by concatenating card number, expiry or other applicable details on the card) which are then fed to a cryptographically-secure deterministic one-way inherently-slowed hash function (e.g. Argon2 or PBKDF2 with high-enough computational costs set), as follows:
- the Recipient periodically, generates a number of Key Exchange Messages 503. This number should depend upon the frequency at which the Recipient receives Statements (e.g. a business recipient receiving hundreds of Statements a day will require a larger number as opposed to an individual receiving one Statement a day). 6) The Recipient then uploads all the Key Exchange Messages they create and distribute them among all their “Reusable Statement Reception Wallets”. 7) Having established integration with banking or healthcare systems and upon the availability of the relevant mechanisms (e.g.
- APIs Application Programming Interfaces
- payment or health card organizations when a statement is generated by the issuer, upon having access to the payment identifiers in the statement, the Issuer looks up the Secure Statement Wallet Address 507 of the right reusable secure statement wallet by passing payment identifiers to the Issuing organization of a payment or health care card, as follows:
- the card issuing organization already holds a mapping between payment identifiers and the “identity” of the card holder and is in a position to know that a transaction between the card holder and the merchant (i.e. Statement issuer) has happened even though they are not in a position to know the details of the transaction.
- the Secure Statement Transfer protocol cannot change this existing situation in which the information that a transaction between the merchant and the cardholder has happened is already given away to the payment card issuing organization. However, in this mode, still the anonymity of the recipient against the Data Transfer Intermediary is preserved (unless Data Transfer Intermediary and the card issuer are the same party). This is due to the fact that the intermediary only gets a chance to look up a Secure Statement Wallet Address for a given transaction in a way that is not reversible or convertible to card holder details. 7.2) The organizations can be assured that they are not giving away any personal details of their customers to the Data Transfer Intermediary due to the uselessness of the Random Recipient ID.
- the Issuer then refers to the looked up Secure Statement Wallet Address 507 to the Data Transfer Intermediary and downloads the next available Key Exchange Message 512 from the relevant reusable statement reception wallet. If no Key Exchange Message is available, it must retry later until one becomes available, as part of a batch processing scheme (or using an asynchronous publish-subscribe mechanism). 9) Once a Key Exchange Message is downloaded, the issuer then generates symmetric encryption keys 513 using it, encrypts the statement, creates a Statement Transfer Message 514 and uploads it using the same Secure Statement Wallet Address that it calculated, which will also include the Key Exchange Message ID.
- the Recipient checks the reusable statement reception wallets that have new statements in them and downloads them 517. Using the relevant Key Exchange Message ID, the Recipient will be able to generate the same encryption keys as generated and used by the Issuer and decrypt the Statement by using the locally-saved private keys relevant. 11) The recipient, then compiles an encrypted Statement Signing Message 521 and uploads it to the same Secure Statement Wallet using the relevant Secure Statement Wallet Address.12) The issuer, periodically (or using an asynchronous publish-subscribe mechanism, checks 523 for the existence of Statement Signing Messages in the secure statement wallets it has uploaded statements to previously. Upon downloading Statement Signing Messages 524, it reflects the acknowledgement, Transaction Markers and Recipient’s Signatures in local storage 527.
- the recipient's app can receive the identifier(s) of transaction(s) or statement(s) through inter-process communication schemes in the recipient's private space (e.g. methods including but not limited to URL schemas which the recipient's app registers itself against) from another app or system (e.g. internet banking systems) which in return will lead to the recipient's app finding the statement related to the passed identifiers and demonstrating them to the recipient, making it possible for such systems to provide extra details about transactions without owning or having access to the contents of statements.
- inter-process communication schemes in the recipient's private space e.g. methods including but not limited to URL schemas which the recipient's app registers itself against
- another app or system e.g. internet banking systems
- recipient's portal can receive the identifier(s) of transaction(s) or statement(s) through a URI with a pre-defined format from another app or system (e.g. internet banking systems) which in return will lead to the recipient's portal finding the statement related to the passed identifiers and demonstrating them to the recipient, making it possible for such systems to provide extra details about transactions without owning or having access to the contents of statements. If the recipient has not logged into the recipient’s portal, the portal will guide the recipient to log in and then demonstrate the related statement to the recipient.
- a URI e.g. internet banking systems
- Statement Transfer Request Signature which is calculated by concatenating the issuer identifier 901 , the statement identifier 903, statement timestamp 904 and the statement issuing station identifier 902 to compile a message and feed it to an elliptic curve or RSA digital signature function 907 (depending on which has been adopted in the implementation).
- the result is deemed Statement Transfer Request Signature which is provided to the recipient as part of the Statement Transfer Request.
- the recipient downloads the relevant public identity key of the statement issuing system (using the provided key index) from intermediary servers and verifies the provided signature before progressing to the next step of the transfer process.
- statement data 909 alongside with the private identity key of the statement issuing station, on the station are fed to an elliptic curve or RSA digital signature function 910, which then creates the statement issuer's digital signature which can be used to verify the correctness, integrity and tamper-resistance of the statement after delivery by the recipient.
- the verification process of the statement issuer's digital signature will need the recipient to download the public identity key of the relevant statement issuing station from backend servers.
- the recipient Upon receiving the statement and verifying its correctness and verifying it has been issued by the correct issuer, the recipient then compiles a statement signing message which includes the recipient's digital signature and recipient's transaction marker.
- the recipient uses the Recipient Digital Signature Mac Key 912 which has been created as part of the private key agreement process with the issuer.
- the generation of the Recipient Digital Signature Mac 912 is dependent upon private keys that only the issuer and recipient own and therefore the data transfer intermediary cannot have access to it.
- the recipient uses the recipient digital signature mac key as the key which is passed to HMAC-SHA256 913 alongside with the statement issuer's digital signature 911 , as the data to be signed. In effect, the recipient, signs the signature of the issuer, which itself is derived from the contents of the receipt, which results in recipient's digital signature 914.
- HKDF hash-based key derivation function
- the transaction marker is sent to the issuer as part of the statement signing message which is then reflected to the issuer's copy of the statement hence enabling the issuer to bundle statements that were received by the same recipients in an anonymous manner, without revealing the identity of the recipient to the issuer, nor to the intermediary.
- a software system accessed by statement issuers can be used to manage the history of the issued statements by issuers and to enable a statement issuer to view the list of their issued statements and be able to dice and slice, group statements based on their buyers in an anonymous way (based on transaction markers), as well as being able to manage their bills, create loyalty management and marketing campaigns.
- Statement Issuer’s Portal can be a web-based application hosted in the cloud accessible from everywhere that can be accessed by statement issuers or their employees. This portal effectively works with issuers’ copy of statement data that does not include any meaningful identifying information belonging to the statement recipients. Flowever, the philosophy behind the invention is to assure intermediary’s zero knowledge against statements data, even against the issuer’s copy.
- the issuer’s copy of statements are then encrypted using keys that are different and independent from the keys that are used to transfer statements to recipients and are independent per each statement.
- the encrypted form of the issuer’s copy of a statement is then uploaded to the cloud to the issuer’s portal.
- Each user in the Issuer’s portal get their own RSA identity key pair 605 which is generated upon their first sing-in, at client side, in their web browsers, using client-side cryptographic libraries (e.g. WebCrypto API (mozilla.org, 2019)).
- client-side cryptographic libraries e.g. WebCrypto API (mozilla.org, 2019)
- the public key gets saved in the Issuer’s portal 607.
- Private keys 606 are NOT shared with Secure statement Wallet in any form or shape
- the private key 606 is made available to the user to download and save securely.
- Issuer’s Portal users are given the option to encrypt their private identity key using a Master Password 601 , which then is fed into a slow key derivation function 603 (e.g. PBKDF2) with high complexity parameter (circa 1 ,000,000) to derive an encryption key 604.
- PBKDF2 slow key derivation function
- AES symmetric Advanced Encryption System
- the Master Password 601 is not saved in back-ends in any form or shape.
- the portal user can use that copy to set a new password and re-encrypt the same private RSA key and re upload the encrypted RSA key in their key vault d)
- the public RSA keys belonging to all users defined in an issuer’s account are then broadcasted to all statement issuing stations within an issuer’s account forming a distributed network that is kept synchronized with the back-ends.
- the issuer’s SDK libraries encrypt issuer’s copy of statements 701 using independent keys based on AES 706 and then use the public RSA keys 703 belonging to all users defined in an issuer’s account to perform “public encryption” 704 of independent statement encryption keys.
- each issuer’s portal user will have a copy of the independent statement encryption keys that are only available to them to decrypt.
- the initialization vectors used to encrypt statements based on AES in CBC mode are also saved alongside with the encrypted statements with each statement.
- each encrypted copy of the statement is also uploaded to the issuer’s portal only once 707.
- the statement encryption key is saved independently for each issuer’s portal user and this facilitates not having to persist different copies of the statement per each issuer’s portal user.
- an issuer’s portal user logs into the portal, they are asked to either provide their private RSA identity key, or, to enter their Master Password 801 to download their encrypted private RSA identity key 805 from their key vault and perform a client-side AES decryption 806 of the private RSA key.
- issuer’s portal application can then perform AES decryption 809 of independent statement encryption keys 808 as they are downloaded from the portal.
- independent statement encryption keys 810 are then used to perform AES decryption 811 of the encrypted statements 807 as they are downloaded from the issuer’s portal, resulting in the decrypted statement data 812. All such decryption activities are performed at client side, assuring encryption keys are only created at client side.
- an elliptic curve key pair can be generated for the issuer portal users.
- an independent-per- statement elliptic curve key pair is generated, the public component of which is saved at the backend instead of the encrypted symmetric key in the RSA scheme.
- the private component of the independent-per-statement elliptic curve key pair is then fed into the ECDH function alongside with the portal user’s public elliptic curve key, which leads to the generation of an intermediate key.
- the intermediate key is then fed into a key derivation function the output of which is used as an AES symmetric key for encryption.
- the public independent-per-statement elliptic curve key and issuer portal user’s private elliptic curve key are fed into the same ECDH function which leads to the generation of the same intermediate key that was generated at the time of encrypting the statement.
- the intermediate key is then fed into the same key derivation function to re-create the same AES symmetric encryption key at the time of encrypting the statement.
- This scheme for encrypting and decrypting statements while uploading them to issuer's portal eliminates the need for RSA keys and makes it possible to use elliptic curve keys with smaller sizes and faster operations.
- the Recipients' App 1113 can engage in a synchronization process with the Statement Recipients' Portal without the privacy of the recipient being compromised and without the intermediary who is developing and running these apps to aware become aware of the contents of the statements.
- the recipient’s app 1113 generates a once-off asymmetric recipient's public key 1100 and recipient's private key 1101 using the RSA scheme.
- the recipient's app also asks the recipient to choose a Master Password 1105, which has to be a strong password, and is not saved in backends in any form or shapes or derivations. It then uses the recipient's identifier as the salt 1106 to feed the master password 1105 to a slow key derivation function 1104 (e.g. PBKDF2 with a high complexity cost selection). The output of the key derivation function is then used as the key in the AES symmetric encryption scheme to encrypt recipient's private RSA key 1101. This private key can only be decrypted by the recipient since it is locally encrypted using keys only known to and derived from recipient's passwords at client side without being persisted at the backend.
- a slow key derivation function 1104 e.g. PBKDF2 with a high complexity cost selection.
- the output of the key derivation function is then used as the key in the AES symmetric encryption scheme to encrypt recipient's private RSA key 1101. This private key can only be decrypt
- recipient's portable private master key in encrypted format 1132 alongside with recipient's public RSA key 1100 are uploaded to recipient's secure key vault 1102 in recipient's portal 1115.
- recipient can log into the recipient's portal, for which they will have to own an online account within the portal, they can have access to recipient's private RSA key 1101 by performing a client- side decryption, in a portable manner.
- statement data 1107 is encrypted using an independent-per-statement random encryption key 1109 which is generated in client side within recipient's app without being shared with the intermediary.
- Recipient's copy of encrypted statement 1129 is uploaded to recipient's online statements vault 1111. Since each statement is encrypted using an independent key before uploading, at the time of accessing the statement via the recipients' portal, the recipient must have access to statement's independent encryption key 1109 for each statement. To make this possible, and to ensure that only the recipient and recipient only can have access to statement's independent encryption key 1109 for each statement, each statement's independent encryption key 1109 is encrypted using RSA public encryption via recipient's public RSA key 1100 which results in the creation of recipient's per-statement encryption key in encrypted format 1130 which can only be decrypted using recipient's private RSA key 1101 at later stages.
- Recipient's per- statement encryption key in encrypted format 1130 is also saved in recipient's secure key vault 1102 for portable accessibility. Given that the recipient has successfully created their recipient's portal online user credentials 1133 and has successfully logged into the recipient's portal 1115, they are then asked to provide their master password 1116, which is separate from their normal credentials. Once provided, at client side, without sharing the password with backends or the intermediary, the master password 1116 and recipient's identifier 1117 are then fed into the same slow key derivation function 118 (e.g. PBKDF2 with high complexity factors, similar to 1104), which results in the re-generation of the same derived key created at the time of setting up the master password.
- the same slow key derivation function 118 e.g. PBKDF2 with high complexity factors, similar to 1104
- the derived key alongside with the recipient's portable private master key in encrypted format 1120 which is downloaded from the secure key vault 1102 are then passed to the AES decryption function which leads to the re-generation of the recipient's portal private master key in decrypted format 1121 , which, alongside with recipient's per-statement encryption key in encrypted format 1122, for each statement, are passed to an RSA private decryption function 1123, which then leads to the re-creation of recipient's per-statement encryption key 1124 for each statement.
- This key is what the recipient needs to decrypt the encrypted statements that they are downloaded from recipient's online statements vault 1111 to be decrypted into recipient's statement in plain format 1127.
- the proposed encryption and decryption scheme makes accessing statement contents dependent upon ownership of private RSA keys only known to the recipient without any chance of them being shared with the intermediary (as they are all generated and re-created at client side), hence maintaining intermediary's zero knowledge of the contents of statements irrespective of persisting them on user devices (e.g. mobile apps) or online backends (e.g. recipient's online statements vault 1111).
- All client-side cryptographic operations in recipient’s portal which is a web-based system can be performed using JavaScript libraries (e.g. WebCrypto API (mozilla.org, 2019)).
- an elliptic curve key pair can be generated for the recipient.
- an independent-per-statement elliptic curve key pair is generated, the public component of which is saved at the backend instead of the encrypted symmetric key in the RSA scheme.
- the private component of the independent- per-statement elliptic curve key pair is then fed into the ECDH function alongside with recipient's public elliptic curve key, which leads to the generation of an intermediate key.
- the intermediate key is then fed into a key derivation function the output of which is used as an AES symmetric key for encryption.
- the public independent-per-statement elliptic curve key and recipient's private elliptic curve key are fed into the same ECDH function which leads to the generation of the same intermediate key that was generated at the time of encrypting the statement.
- the intermediate key is then fed into the same key derivation function to re-create the same AES symmetric encryption key at the time of encrypting the statement.
- the following detailed steps can be taken to generate the four messages described above, as listed in Table 1.
- elliptic curve (EC) or RSA (Rivest-Shamir-Adleman) cryptography can be employed to implement the protocol, as discussed in Table 1.
- the issuer remains able to renew such keys (e.g. when setting up a statement issuing station (like a POS station) again with the same identifiers) without losing the capability to verify the integrity and signatures of previously-issued statements. 3)
- each statement in Secure Statement Transfer Protocol owns an independent “Statement Transfer Key”, which is not persisted by the data transfer intermediary.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Marketing (AREA)
- Game Theory and Decision Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Power Engineering (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Document Processing Apparatus (AREA)
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/AU2020/050189 WO2021168497A1 (en) | 2020-02-29 | 2020-02-29 | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts |
CA3173536A CA3173536A1 (en) | 2020-02-29 | 2020-02-29 | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or script |
AU2020432497A AU2020432497A1 (en) | 2020-02-29 | 2020-02-29 | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts |
GBGB2214079.2A GB202214079D0 (en) | 2020-02-29 | 2020-09-29 | Cryptosystem, system, method and aplications for zero-knowledge anonymously-individualized markerting and loyalty management based on end-to-end encrypted |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/AU2020/050189 WO2021168497A1 (en) | 2020-02-29 | 2020-02-29 | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021168497A1 true WO2021168497A1 (en) | 2021-09-02 |
Family
ID=77489789
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/AU2020/050189 WO2021168497A1 (en) | 2020-02-29 | 2020-02-29 | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts |
Country Status (4)
Country | Link |
---|---|
AU (1) | AU2020432497A1 (en) |
CA (1) | CA3173536A1 (en) |
GB (1) | GB202214079D0 (en) |
WO (1) | WO2021168497A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113965331A (en) * | 2021-12-22 | 2022-01-21 | 鹏城实验室 | Secret state prediction verification method, device, equipment and storage medium |
CN115664799A (en) * | 2022-10-25 | 2023-01-31 | 江苏海洋大学 | Data exchange method and system applied to information technology security |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020049681A1 (en) * | 2000-07-20 | 2002-04-25 | International Business Machines Corporation | Secure anonymous verification, generation and/or proof of ownership of electronic receipts |
WO2002087148A1 (en) * | 2001-04-23 | 2002-10-31 | International Business Machines Corporation | Non-transferable anonymous digital receipts |
WO2013062481A1 (en) * | 2011-10-24 | 2013-05-02 | Nachiappan Nachiappa | Anonymous collection, presentment and reverse auction of payment receipt items |
US20140025516A1 (en) * | 2012-07-23 | 2014-01-23 | Wal-Mart Stores, Inc. | Transferring digital receipt data to mobile devices |
CN104811311A (en) * | 2015-04-09 | 2015-07-29 | 深圳市中润四方信息技术有限公司 | Electronic invoice safety delivery method and system |
AU2019100775A4 (en) * | 2019-07-17 | 2019-08-22 | Sadler, Hamish MR | Secure Receipt Transfer Protocol: Cryptosystem, Communication Protocol, Systems, Methods and Smartphone Applications for End-To-End Encrypted Transfer of Tamper-Resistant Receipts as an Enabler for Anonymously-Individualized Marketing and Loyalty Management with Preservation of Buyers’ Anonymity and Privacy |
-
2020
- 2020-02-29 CA CA3173536A patent/CA3173536A1/en not_active Abandoned
- 2020-02-29 AU AU2020432497A patent/AU2020432497A1/en not_active Abandoned
- 2020-02-29 WO PCT/AU2020/050189 patent/WO2021168497A1/en active Application Filing
- 2020-09-29 GB GBGB2214079.2A patent/GB202214079D0/en not_active Ceased
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020049681A1 (en) * | 2000-07-20 | 2002-04-25 | International Business Machines Corporation | Secure anonymous verification, generation and/or proof of ownership of electronic receipts |
WO2002087148A1 (en) * | 2001-04-23 | 2002-10-31 | International Business Machines Corporation | Non-transferable anonymous digital receipts |
WO2013062481A1 (en) * | 2011-10-24 | 2013-05-02 | Nachiappan Nachiappa | Anonymous collection, presentment and reverse auction of payment receipt items |
US20140025516A1 (en) * | 2012-07-23 | 2014-01-23 | Wal-Mart Stores, Inc. | Transferring digital receipt data to mobile devices |
CN104811311A (en) * | 2015-04-09 | 2015-07-29 | 深圳市中润四方信息技术有限公司 | Electronic invoice safety delivery method and system |
AU2019100775A4 (en) * | 2019-07-17 | 2019-08-22 | Sadler, Hamish MR | Secure Receipt Transfer Protocol: Cryptosystem, Communication Protocol, Systems, Methods and Smartphone Applications for End-To-End Encrypted Transfer of Tamper-Resistant Receipts as an Enabler for Anonymously-Individualized Marketing and Loyalty Management with Preservation of Buyers’ Anonymity and Privacy |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113965331A (en) * | 2021-12-22 | 2022-01-21 | 鹏城实验室 | Secret state prediction verification method, device, equipment and storage medium |
CN115664799A (en) * | 2022-10-25 | 2023-01-31 | 江苏海洋大学 | Data exchange method and system applied to information technology security |
CN115664799B (en) * | 2022-10-25 | 2023-06-06 | 江苏海洋大学 | Data exchange method and system applied to information technology security |
Also Published As
Publication number | Publication date |
---|---|
CA3173536A1 (en) | 2021-09-02 |
GB202214079D0 (en) | 2022-11-09 |
AU2020432497A1 (en) | 2022-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20240095713A1 (en) | Method, client device and pos terminal for offline transaction | |
US7822688B2 (en) | Wireless wallet | |
US20200044831A1 (en) | Systems and methods for using distributed attestation to verify claim of attestation holder | |
Yang | Security Enhanced EMV‐Based Mobile Payment Protocol | |
CN110050435A (en) | Key pair architecture for security message transmitting-receiving | |
US11182783B2 (en) | Electronic payment method and electronic device using ID-based public key cryptography | |
CN105684346A (en) | Method for securing over-the-air communication between a mobile application and a gateway | |
CN111131416A (en) | Business service providing method and device, storage medium and electronic device | |
EP3874677A1 (en) | Efficient authentic communication system and method | |
AU2019100775A4 (en) | Secure Receipt Transfer Protocol: Cryptosystem, Communication Protocol, Systems, Methods and Smartphone Applications for End-To-End Encrypted Transfer of Tamper-Resistant Receipts as an Enabler for Anonymously-Individualized Marketing and Loyalty Management with Preservation of Buyers’ Anonymity and Privacy | |
AU2020432497A1 (en) | Cryptosystem, systems, methods and applications for zero-knowledge anonymously-individualized marketing and loyalty management based on end-to-end encrypted transfer of statements like receipts or scripts | |
US10664612B2 (en) | System and method for controlling operations performed on personal information | |
Suryotrisongko et al. | A novel mobile payment scheme based on secure quick response payment with minimal infrastructure for cooperative enterprise in developing countries | |
US20200311246A1 (en) | Enhanced consumer device validation | |
CN107409043A (en) | Distributed treatment of the data storage based on center encryption to product | |
Hassinen et al. | Strong mobile authentication | |
CA2892457C (en) | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction | |
M'Raı̈hi et al. | E-commerce applications of smart cards | |
US20220337581A1 (en) | Authenticated messaging session with contactless card authentication | |
CN111131227B (en) | Data processing method and device | |
Jayasinghe et al. | Enhancing emv tokenisation with dynamic transaction tokens | |
CN107636664A (en) | For to the method and system of mobile device supply access data | |
Ali et al. | A new design of Mobile Payment system based on NFC Technology | |
EP3699849A1 (en) | A method of supporting identification of a customer using a payment card of said customer and a server arranged for supporting said method | |
Woo et al. | Verification of receipts from M-commerce transactions on NFC cellular phones |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20920941 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 3173536 Country of ref document: CA |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2020432497 Country of ref document: AU Date of ref document: 20200229 Kind code of ref document: A |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 20920941 Country of ref document: EP Kind code of ref document: A1 |