CA3173536A1

CA3173536A1 - 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

Info

Publication number: CA3173536A1
Application number: CA3173536A
Authority: CA
Inventors: Hamish Sadler
Original assignee: Secure Wallet Technology Pty Ltd
Current assignee: Secure Wallet Technology Pty Ltd
Priority date: 2020-02-29
Filing date: 2020-02-29
Publication date: 2021-09-02
Also published as: AU2020432497A1; WO2021168497A1; GB202214079D0

Abstract

Provided herein are effective cryptosystem, systems, methods and applications that make it possible to personalize the offers that are applicable to individuals according to their purchase history without the individuals' purchase history ever being know to any parties. The proposal includes an end-to-end encrypted communication protocol, novel transaction marking and digital signature schemes as well as applications that facilitate the population of a private purchase history via the end-to-end encrypted transfer of statements (e.g. receipts or pharmaceutical scripts). The proposed protocol assures recipients' privacy and anonymity as well as statement integrity via digital signatures while enabling issuers to bundle issued statements received by the same recipients via cryptographically-generated transaction markers. A private analysis and trend extraction scheme against the populated private purchase history are disclosed that facilitate the mining of individuals' applicable offers without their private purchase history being disclosed or known to any other parties.

Description

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
TECHNICAL FIELD
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).
BACKGROUND
The foundation of personalization of offers and deals in digital marketing and loyalty management is the existence of a history of purchasing behaviour which is deducted from a history of purchases for individuals. This implies that for the individualization to take place, there must be a mechanism of somehow deducting trends and patterns from the individual's purchase history.
At the moment, in digital marketing, there is an implied need of trust between the individual and the marketing intermediary or platform to have access to such a history (at least partially) even though the individual may not have explicitly provided their consent, hence regulations like the General Data Protection Regulation (GDPR) or the new California Consumer Privacy Act (CCPA) are enforcing this to be explicitly announced to the individuals that their private information is used by an intermediary.
The need that has been left unaddressed in the previous art is that the individual should not have to trust the marketing intermediary in a zero-knowledge zero-trust setting.
In other words, 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.

2 In an overall view, 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 current art is yet to provide a practical solution to this paradox hence regulations like GDPR and CCPA can be viewed as a mechanism of privacy protection in a setting where there is no practical way to maintain privacy and allow the use of private information except for making it unlawful to disclose information without prior notice.
Consumer statements like receipts or scripts, on the other hand, carry significant private information about individuals' purchases and they are still paper-based in many occasions which puts a tremendous pressure on the environment (e.g. in the U.S
alone, every year, up to 10 million trees are killed to be turned into paper receipts (Breyer, 2019).
The experience of using paper statements is not ideal either with them getting lost, fading out, or being hard to manage, track, analyse, or find whenever needed. With the significant role of receipts in the population of purchase history as an enabler of marketing and loyalty management, except for an early and very limited solution proposed by the inventor in Australia (Sadler, 2019a, Sadler, 2019b), the previous art does not currently have a clear answer on how to digitize paper receipts without loss of privacy and anonymity to the extent that lack of a clear solution in private anonymous receipt digitization resulted in Bill 161 (bill to ban paper receipts in California) getting rejected due to privacy concerns (Gutierrez, 2019). Current simple solutions to email or text receipts to recipients simply requires the recipient to provide identifying information to the issuer (e.g.
email addresses or phone numbers) which invalidates the anonymity requirements apart from impracticality or implementation difficulty (e.g. the inconvenience and time it takes to provide such details as well as chances of mistakes and or loss of privacy).
Accordingly, there is a clear need in the art to provide a solution for zero-knowledge anonymously-individualized marketing and loyalty management in which the marketing intermediary remains unaware of individuals' private purchase history but yet remains able to personalize offers for each individual based on their purchase history. With the connections this problem has with receipt and statement digitization, there is also a

3 need for a solution for statement digitization with preservation of privacy that has been left unaddressed in previous art.
SUMMARY OF INVENTION
The problem stated above is that for the individualization of offers for marketing and loyalty management intermediaries, there is a need for the intermediary to have access to one's purchase history in order to deduct trends, rules and patterns but this leads to the need for the individual to have to trust the marketing intermediary that their purchase history is protected and that if information is shared with other parties, the individual remains aware of it (as per regulations like GDPR or CCPA).
Previous art has not yet proposed a marketing and loyalty management model in which personalization of offers does not lead to the necessity of trusting the party that identifies and proposes such offers.
In the proposed invention, 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. In other words, 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.
In an embodiment, 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. In this embodiment, 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

4 facilitate the end-to-end encryption and transfer of statements from such stations to recipients who are using application(s) to receive their statements.
In this embodiment, 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. Upon claiming, 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.
In all embodiments, the recipient and issuer must generate multiple asymmetric cryptographic keys the public component of which must be shared with the other parties.
In one embodiment, the statement transfer process is started by issuers which involves some form of scanning performed by the recipient (e.g. OR codes, bar codes or RFID
scans) to create a private communication channel address. In another embodiment, the statement transfer is started by recipients which may involve some form of scanning performed by statement issuers (e.g. OR codes, bar codes or RFID scans). In another embodiment, 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. through a payment intermediary which provides a list of transactions with their identifiers to the recipient, like an electronic payment card issuing bank's internet banking system). As a result, 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

5 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.
This seamless interaction-less multi-step end-to-end encrypted transfer of statements is an important novel aspect of the invention.
1 0 Whilst the proposed invention inherently solves the bigger problem of zero-knowledge anonymously-individualized marketing and loyalty management, it also provides an answer to anonymity and privacy preservation in statement, receipt and script digitization, solving more than one problem in this space.

6 DESCRIPTION OF THE DRAWINGS
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.

7 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.

8 DETAILED DESCRIPTION OF INVENTION
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.
Referring to Figure 1, 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. In one embodiment, 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. 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. As will be discussed in details, 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.

9 In one embodiment, with the goal to minimize implementation and integration hassles, 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.
In one embodiment, when private statement history (e.g. receipt or script or purchase history) is built and collected in the statement recipient's space 203 over time in an isolated and private fashion, without the data leaving statement recipient's space 203 at all, and with data only entering statement recipient's space 203, 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). Then 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. Depending of the inclusions of the rule, 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. Upon applicability of a rule or the extraction of patterns from 5 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

10 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 !earnings 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. As will be discussed, 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. In one embodiment, if 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.
In one embodiment, to facilitate the population of a private statement history for a recipient at client side, 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 key concerns to address through this protocol include a) In order for

11 Statement Recipients to receive their Statement from the Statement Issuer, they must not have to provide identity-revealing or personal details to the Issuers; b) before data enters the communication channel with Transport Layer Security (TLS), no data must leave Statement Issuer's Space or Statement Recipient's Space without first being encrypted with keys that can only be known to the Statement Issuer and the Statement Recipient; c) Encryption and decryption of data must be performed privately, at client side, in Statement Issuer's Space and Statement Recipient's Space, using private encryption keys that are agreed upon between Issuers and Recipients through the Secure Statement Transfer Protocol, involving the transfer and exchange of public keys between them; d) The creation of the encryption keys agreed upon between Issuers and Recipients must depend on owning private keys that are generated and maintained securely in Statement Issuer's Space and Statement Recipient's Space; e) The Data Transfer Intermediary must not be able to have access to the contents of the statements that it transfers between Statement Issuers and Statement Recipients hence preserving Statement Issuers' and Statement Recipients' privacy, especially protecting Recipient's private statement history (e.g.
purchase history), from all parties; f) Despite transactions being signed by both Issuers and Recipients, the Data Transfer Intermediary must not be able to determine who the Statement Recipient of a transaction is hence protecting the Recipient's anonymity.
In one embodiment of a secure statement transfer protocol fulfilling the requirements highlighted above, 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. The request 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 OR 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

12 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). In the Issuer-Initiated mode, apart from public cryptographic keys that are generated by the recipient, 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. Upon the reception of the Key Exchange Message, 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 issuer to acknowledge the reception of the Statement and providing Recipient's Digital Signature and Transaction Marker to the issuer. 3) "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. 4) "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 key requirement to make the end-to-end-encrypted transfer of Statements possible is that the Issuer must receive a Key Exchange message from the Recipient which includes public cryptographic keys needed for the end-to-end encryption process to work. This translates into the fact that the recipient in the Secure Statement Transfer protocol is not a passive receiver of information and that the Issuer is not a passive sender of information either. A number of implementation constraints will be

13 resulted by this important requirement that have to be considered (e.g.
involving a real-time communication backend to facilitate this two-way communication between issuers and recipients).
In one embodiment which we call Issuer-Initiated Transfer Mode, the Issuer initiates the Statement transfer process as illustrated in Figure 3. As a result, 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 OR 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. an order pick-up after the purchase being dependent on the presentation of a statement or receipt) making this scenario the most universal case that does not require integration with banking, payment, health or medical care systems nor is requiring electronic transactions (e.g. payments). In this mode, following the generation of the necessary cryptographic key pairs (which will be discussed later), 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.
Next, 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. In return, the recipient then compiles a statement signing message 309 back to the issuer which leads to the update of state by the issuer 310.
In one embodiment which we call Recipient-Initiated Transfer Mode, the recipient initiates the statement transfer process. As a result, 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

14 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 Host Card Emulation (HCE), 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. 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.
2. Cases where the Recipient introduces themselves to the Issuer. This mode can be implemented via the creation of a reusable or temporary secure statement wallet.
Examples include 2.1 via OR 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);
3. cases where the Issuer has access to payment identifiers before the recipient (if recipient can have access to such data at all). Examples include transactions based on electronic payments in which no transfer of information like OR codes, barcodes, or RF
scan happens between the recipient and issuer (case of a "seamless" transfer of a statement). In this mode, common pieces of information from the transaction details can be used to derive common addresses for communication between issuers and recipients which will then facilitate connecting the parties to communicate. This mode can only be implemented through the creation of a reusable secure statement wallet per each electronic payment card and using a one-way secure mechanism to derive addresses for the card. Another pre-requisite to implement this mode is the possibility to map payment identifiers to an electronic card holder. One way to achieve this is to integrate with the systems of a card issuing bank or organization through APIs to perform such mappings.
5 In one embodiment, as depicted in Figure 4, in the Recipient-Initiated Transfer using Once-Off Secure Statement Wallets can include the following steps: 1) When the payment identifier 403 is known by the recipient 401, a Secure Statement Wallet Address 408 is generated as follows:
AddressSecure Statement Walletstatement Equation 1 = SHA512(Unique Transaction Identifierstatement) 10 2) Using the address above, 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:
AddressSecure Statement Walletstatement Equation 2 = SHA512(Unique Transaction Identifierstatement) 4) Using the address calculated above, the issuer then downloads the Key Exchange Message which was uploaded by the recipient. 5) 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. 6) 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. 7) Upon receiving a Statement Transfer Message 420, it downloads the Statement Transfer Message 420, calculates the same symmetric encryption keys and decrypts the Statement and saves it locally in secure storage 423. 8)The recipient then generates a Statement Signing Message 420 after generating the Recipient's Digital Signature and the Transaction Marker and uploads it to the intermediary server using the address calculated above. 9) Periodically (or using an asynchronous publish-subscribe mechanism, the issuer checks for Statement Signing Messages 426. Once downloaded, it decrypts the contents, and reflects the transaction marker and recipient's signature locally 430.
Another embodiment which we call Recipient-Initiated Transfer using Reusable Secure Statement Wallets, as depicted in Figure 5, 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. via 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. 2.3) The intermediary then 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. 2.4) 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. 2.5) 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:
Secure Statement Wallet AddressPermanent Statement walletstatemem = SHA512 (Random Recipient IDcard) Equation 3 The important benefit of this scheme is that no card details would need to be shared with the intermediary to derive a Secure Statement Wallet Address from. More importantly, an attacker with the possibility of brute-forcing the Secure Statement Wallet Address will not be able to reach useful information from the Secure Statement Wallet Address.
The fact of being unable to reach useful identifying information from the otherwise-useless Random Recipient ID is also applied to the intermediary who will not be able to derive any useful information about the recipient by owning such a Random Recipient ID. In this scenario, the card issuing organization would also need to expose an API to be used by the intermediary that would receive unique payment transaction identifiers and return the Random Recipient ID of the relevant card used for the transaction, as follows:
Random Receipient ID Lookup API (Unique Transaction Identifier) = Random Recipient ID card used for the transaction Equation 4 This lookup will be carried out by statement issuer as part of a separate process after payment transaction details are known by them. This will result in both issuer and recipient to derive the same address 506 despite not having shared any information between each other. As a result, after calling the Random Recipient ID Lookup API, the issuer can calculate the same Secure Statement Wallet Address as follows:
Secure Statement Wallet AddressPermanent Statement Walletumque Transaction Identifier = SHA512 (Random Card IDUnique Transaction Identifier) Equation 5 4) In a non-recommended undesired case, 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:
Secure Receipt Wallet AddressPermanent Receipt Walletcard = Hash (Card Detailscõd) Equation 6 An example of Card Details for a credit card can be as follows:
Card Details = Card Holder's Details II Card Expiry Date II Personal Account Number (PAN) Equation 7 II Card Verification Value (CVV) The big downfall of this scheme is the fact that the recipient will have to share their payment card details with the intermediary which is not optimum nor desired nor recommended. The important aspect is that the same Secure Statement Wallet Address can be then looked up by calling APIs from the card issuing organization by feeding them the payment transaction details. This lookup will be carried out by statement issuer as part of a separate process after payment transaction details are known by them.
This will result in both issuer and recipient to derive the same address despite not having shared any information between each other. The APIs that card issuing organizations would need to expose to facilitate this process will receive payment transaction details (e.g. ARQCs) and return the same one-way slow-hashed version of card details. Due to computational costs involved in the one-way slow-hashed function, it would be recommended for the organization to reuse the calculated hash for their cards. Logistically, this would be as complex as issuing a Random Recipient ID per each card and using the first card registration method discussed above. As a result, on top of security issues, the use of card details also come with a range of implementation complexities that are not optimum. 5) 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.
Application Programming Interfaces (APIs) provided by 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:
Secure Statement Wallet AddressStatement = Random Recipient ID Lookup API(Transaction Identifierstatement) Equation 8 It is obvious that 7.1) 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. 8) 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. 10) At a later time (or using an asynchronous publish-subscribe mechanism), as part of a synchronization scheme 516, 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 5 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.
In an embodiment, the recipient's app can receive the identifier(s) of transaction(s) 10 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

15 provide extra details about transactions without owning or having access to the contents of statements.
In an embodiment, 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 20 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.
In one embodiment, and as one important novel step, as shown in Figure 9 and Figure 10, to achieve the goals of recipient's anonymity, statement integrity, statement tamper-resistance and to create the possibility for the statement issuer to group their copies of statements based on the same recipient in an anonymous way, the following steps are taken: 1) In Issuer-Initiated mode where the issuer takes the first step to announce they have a statement to be transferred to a recipient using a Statement Transfer Request, the recipient first verifies that the request is coming from a valid source.
In order to do so, it uses the 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. 2) Upon reception 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. 3) Upon the compilation of a Statement Transfer Message at later stages of the transfer, 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. 3) 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. 4) 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. To compile the recipient's digital signature, 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. To create the recipient's digital signature, 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.
Owning this signature and the statement issuer's digital signature 911 does not make it possible for an attacker (or the intermediary) to identify who the signer of the transaction is since the generation of the recipient digital signature is dependent upon private keys only known to the recipient and the issuer (unknown to the attacker), hence, preserving recipient's anonymity. Also, as per Figure 10, upon receiving a statement, the recipient generates a private transaction marking key 1001 which is generated upon the first interaction between an issuer and the recipient and reused in later interactions. This key is kept securely on the client side without being shared with any parties. It is then fed into a hash-based key derivation function (HKDF) 1002 the result of which is then used as a key in HMAC-SHA256 1004 to sign the statement issuer identifier 1003 and generate the transaction marker 1005. Obviously, in all instances where the recipient receives statements from the same issuer, the same transaction marker is generated since the inputs of the marker calculation process remain the same. Having access to a transaction marker does not enable an attacker or the data transfer intermediary to know who the recipient is since the generation of the transaction marker is dependent upon keys only known to the recipient; hence preserving the anonymity of the recipient. 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.
In one embodiment, a software system accessed by statement issuers, which we call Issuer's Portal, 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. However, the philosophy behind the invention is to assure intermediary's zero knowledge against statements data, even against the issuer's copy.
For this goal to be achieved, after each statement is transferred to a recipient through the secure statement transfer protocol, 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. For the issuer and their employees to be able to access their copy of statements in the Issuer's Portal, after they log into the portal, all these independent keys need to become available to them, at client side, for them to be able to view and browse through past statements.
This goal is achieved through the following steps: a) 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)). b) 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. c) The private key 606 is made available to the user to download and save securely.
Alternatively, as illustrated in Figure 6, to facilitate portability and ease of use, 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. This generated private key out of the Master Password is then used to locally encrypt the private RSA key using the symmetric Advanced Encryption System (AES) scheme 608 and then to upload the encrypted form of the private key in issuer's portal user's private personal key vault 609.
The Master Password 601 is not saved in back-ends in any form or shape.
Consequently, it cannot be reset; it can only be changed after providing the original Master Password, or alternatively, if the portal user has saved the original private RSA identity key locally, they 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) Periodically, 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. Upon the transfer of each receipt, as illustrated in Figure 7, 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. This results in the statement encryption key being encrypted independently with each issuer's portal user's public RSA key and then saved in the issuer's portal key vault 705 belonging to each respective user, alongside with the statement identifiers. As a result, 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. On the other hand, each encrypted copy of the statement is also uploaded to the issuer's portal only once 707.
Obviously, 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. As illustrated in Figure 8, when 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.
With the private RSA identity key of the user available, issuer's portal application can then perform AES decryption 809 of independent statement encryption keys 808 as they are downloaded from the portal. These 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.
In an embodiment, instead of generating unique random symmetric keys per statement to be used with the AES encryption scheme and then using RSA key pairs (belonging to the users of the issuer's portal) to encrypt and decrypt such symmetric keys at different stages, and saving such symmetric keys in encrypted format, as herein discussed, instead of an RSA key pair, an elliptic curve key pair can be generated for the issuer portal users. In order to encrypt each statement before uploading them to the issuers' portal, instead of generating a random symmetric key, 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.
At the time of needing to decrypt a statement, 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.
5 In an embodiment, with the goal to minimize dependence on the Recipients' App 1113 in mobile or desktop form and to make it possible for the recipient to have access to their statements under web anywhere in a portable manner through a web-based system, which we call Statement Recipients' Portal 1115, the Recipients' App 1113 can engage in a synchronization process with the Statement Recipients' Portal without the privacy of the 10 recipient being compromised and without the intermediary who is developing and running these apps to aware become aware of the contents of the statements. To make this happen, as part of the setup process, 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. As part of the setup process, the recipient's app also asks the recipient to choose 15 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 20 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. Then 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. As long as the recipient can log 25 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. Once the recipient's app receives a statement from a statement issuer, as described in previous chapters, and saves it in the local secure storage 1108, 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 11 01 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 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)).
In an embodiment, in the recipient's portal, instead of generating unique random symmetric keys per statement to be used with the AES encryption scheme and then using RSA key pairs (belonging to the recipient) to encrypt and decrypt such symmetric keys at different stages, and saving such symmetric keys in encrypted format, as herein discussed, instead of an RSA key pair, an elliptic curve key pair can be generated for the recipient. In order to encrypt each statement before uploading them to the recipients' portal, instead of generating a random symmetric key, 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. At the time of needing to decrypt a statement, 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. This scheme for encrypting and decrypting statements while uploading them to recipient's portal eliminates the need for RSA keys and makes it possible to use elliptic curve keys with smaller sizes and faster operations.
In one embodiment of the secure statement transfer protocol, the following detailed steps can be taken to generate the four messages described above, as listed in Table 1. In alternate embodiments, elliptic curve (EC) or RSA (Rivest-Shamir-Adleman) cryptography can be employed to implement the protocol, as discussed in Table 1. This embodiment is heavily inspired by the open-source "X3DH" (or "Extended Triple Diffie-Hellman") Key Agreement Protocol (Moxie Marlinspike, 2016), with a number of novel important differences and additions, including 1) Unlike X3DH in which both ends of the transfer protocol share the same roles of being a sender or recipient, in Secure Statement Transfer Protocol, the issuer is always the sender of the statement and the statement recipient is always the recipient hence the Secure Statement Transfer Protocol is not symmetric. 2) Unlike X3DH in which both senders and recipients have long-term identity keys, in Secure Statement Transfer Protocol, only the issuer owns long-term identity keys the public component of which remain available perpetually for the purpose of verifying issuers' digital signatures that are part of the statement digitization process. 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) Instead of the recipient owning a long-term identity key, each statement in Secure Statement Transfer Protocol owns an independent "Statement Transfer Key", which is not persisted by the data transfer intermediary. 4) As part of the handshake and key agreement in Secure Statement Transfer Protocol and unlike X3DH, some extra private keys and/or identifiers are derived in Secure Statement Transfer Protocol to facilitate recipient's digital signatures that must make it possible a) to prove a purchase by the recipient when needed, b) for the recipient's signature to remain unlikable to a recipient for the intermediary, untraceable and un-brute-forceable by the intermediary (and all universe for that matter), c) for the recipient to generate transaction markers that must remain the same for the same issuer without being traceable and linkable to the recipient for the intermediary (and all universe for that matter).
This embodiment comprises the following steps and messages communicated between Statement Recipient R, AND, a Statement Issuer operating a Statement Issuing Station/Machine/System, S/S (e.g. a Point of sale station).
Table 1 Detailed steps of the secure statement transfer protocol.
STEP Description Step i Upon setting up and initial configuration, the following asymmetric key pairs are generated by the Issuer on the statement issuing station SIS. All PRIVATE keys are then saved locally in secure encrypted formats using the relevant secure persistence APIs available through the Operating System or hardware-backed secure key-chains while the PUBLIC keys are persisted on back-end servers through calls made to APIs, as Table 2 illustrates.
Table 2 Initial key pairs generated on the statement issuing station SIS
Key Description !KsIs Long-term identity key pairs that are not comprising /Ksispublic changed after the initial installation and configuration of and I/Cs-Ls-private the SIS (until next re-installation or re-configuration).
These keys are saved securely and locally on the SIS
hardware. IKsispublic will be then uploaded to back-end servers at the time of setting-up to become available to query publicly through an API using the Statement Issuer Identifier and the SIS Machine Identifier and a Key Index. In each Statement that is generated, these three parameters are embedded so that, at the time of verifying the digital signatures of statements, the public key used to create the signature can be looked up from a trusted source, potentially owned by the intermediary operating the entire marketing/statement digitization ecosystem/platform.
One important consideration is that the same SIS may be re-installed or re-configured, in which case, even though the Statement Issuer Identifier and the SIS
Machine Identifier will remain the same but a different Key Index will be used when a new /1(515 is created to ensure that those statements generated in the past remain verifiable after re-configuring or re-installation.
SPICsis The Signed Pre-Key which is digitally signed comprising using either ECDSA (if elliptic curve keys are used) or SPK.sispubii, and RSA (if RSA keys are used) against /Ksisprivate upon SPIG T CPrVate the initial configuration on each SIS.
SPKsispublic can be looked up through APIs using the Statement Issuer Identifier and the SIS Machine Identifier.
OTKsis The One-Time Pre-Keys of the SIS, generated comprising in a set of 100 key pairs, each used in ONE handshake with all private keys saved securely locally, and all OTKsfsPublic and public keys saved on back-ends with their "index"
defining which one is referred to.
OTKsfsprivcite With each Statement transfer handshake, the one-time pre-key used gets deleted from both back-ends and from the local secure storage. Once all are used, a new set of 100 get generated and the process continues.
The collection of IKsispublic ' SPKsispiimic, OT Ks'sPublic' Index of OTKsisPublic ' Signature of SPKsyspublic is called a Pre-Key bundle for a SIS and can be looked up from back-end APIs using the Statement Issuer Identifier and the SIS Machine Identifier and the Key Index of I Ksispublic-Step ii When a statement is ready to be submitted from a SIS to a recipient, in Issuer-Initiated transfer mode, a "Statement Transfer Request" is compiled by the Statement Issuer, comprising a. "Random Statement ID", generated randomly using a cryptographically-secure random generator per statement, unique per statement b. "Statement Time Stamp", generated per statement based on the moment of generation c. "Statement Issuer Identifier", set when configuring the SIS, unique per Statement Issuer d. "SIS Machine Identifier", set when configuring the SIS, unique per SIS.
e. "Statement Transfer Request Signature", which is a digital signature against the contents for the Statement Transfer Request, calculated using either ECDSA or RSADSA, as follows as illustrated in Figure 9:
SISprivate) Statement Transfer Request Signature = ECDSA or RSADSA (RTR, IK
Equation 9 where RTR represents the contents of the Statement Transfer Request in byte-serialized format. A recipient can verify the contents of a given Statement Transfer Request by looking up the public identity keys of the relevant issuer and SIS.
Step iii A "Local Return Address" is calculated by the issuer which will be used by the recipient to reach back to the SIS to perform key agreement handshakes. The recipient also generates their own local address at a later stage.
The Local Return Address can be calculated as follows:

Local Return Address = SHA512 (Statement Issuer Identifier II SIS Machine Identifier II Random Statement ID
Equation 10 II Statement Time Stamp II Statement Transfer Request Signature) The use of a one-way hash function using the Statement Transfer Request Signature as an input assures that the intermediary will have no way of deriving the input parameters by having access to a Local Return Address. The fact that Statement Transfer Request Signature requires a private identity key to be calculated prevents the intermediary from being able to brute-force the other input parameters easily, if at all.
Step iv The generated "Statement Transfer Request" is sent to the Recipient through applicable means in Issuer-Initiated Mode (e.g. a OR Code, barcode, or using any other mechanism, including but not limited to emailing links, radio frequency scans, wireless scanning or even manual entry on recipient's devices or direct sending through the Internet network using addresses derived from common payment related identifiers like ARQCs etc..).
Step v The Statement Issuer then starts listening on (or subscribing to) the previously-generated "Local Return Address" for the incoming "Key Exchange" message(s) after persisting details of the generated "Statement Transfer Request".
Step vi Upon the reception of the "Statement Transfer Request" in Issuer-Initiated transfer mode, or, at the beginning of the transfer process in Recipient-Initiated transfer mode, after the recipient creates once-off or reusable Secure Statement Wallets, the recipient performs the following steps:
1. In Issuer-Initiated transfer mode, the recipient looks up the "Pre Key Bundle" of the SIS from intermediary servers using "SIS Machine Identifier" of the SIS provided in the previous step hence retrieving 7 SIS public I KSISpublic SP K OT Ksis public, Index of OT Ksis public 7 Signature of 513Ksispubil, for the provided "SIS Machine Identifier". It may be the case that no OT Ksis public and Index of OTKsispublic are left to return on the intermediary server which does not create a problem as these values will be left blank.
2. In Issuer-Initiated transfer mode, the Recipient then verifies the signature of SP KsisPublic by checking the return value of the following function:
ECDSAVerify or RSAVerify (Signature of SPKsis Public' I ICSIS Public) In case of failing to verify, protocol execution stops with errors.

3. It generates a fresh ephemeral key pair which we call "Statement Transfer Key Pair", RT KR, comprising the public key RTKRpublic and the private key RTKRprivate, saving the private key on hardware-backed keychain-based secure local storage on the device.
RTKR,,,rivate should be maintained and saved securely as long as the Statement exists on Recipient's device and can be used later on to verify digital signatures and purchase.
4. The Recipient then generates a fresh ephemeral key pair which we name "Session Ephemeral Key"EKR, comprising public key EKRpubit, and private key EKRpriõõ. It then saves the private key EKRõiõõ on local secure storage as part of the session data.
5. The Recipient also saves the public identity key index of /Ksispubiic, which can be used (e.g. as part of a OR code or alternative methods) to retrieve the SIS identity public key used during the transfer of the Statement. This can lead to the calculation of a common "Recipient-Issuer Verification Code" between the parties so that in future, both parties can independently validate they were the original parties involved in the transfer of the Statement.
Recipient ¨ Issuer Verification Code = IKsispumic I IRTKRpublic Equation 11 6. The Recipient then compiles a "Key Exchange Message" including the following items:
a. "Local Return Address", which is a communication address used by the issuer to reach the Recipient, generated by a cryptographically secure random generator.
b. "Random Statement ID" set from the previously-received "Statement Transfer Request"
c. "Statement Time Stamp" set from the previously-received "Statement Transfer Request"
d. Index of OTKsispublic used, if applicable e. Public "Statement Transfer Key" RTKRpublic f. EKthu, which is the public key of the ephemeral session key generated as part of the key exchange scheme g. If RSA keys are used, the followings are also included:
i. If applicable, i.e. an issuer's one-time pre-key has existed and been downloaded for this Statement, EncRandSymKey_OTK which is calculated as follows:
EncRanSymKey_OTK = PublicEncrypt (OTKSISpublic' Equation RandSymKey_OTK) where RandSymKey_OTK is a securely-generated random key.
EncRandSymKey_IK which is calculated as follows:
EncRanSymKey_IK = PublicEncrypt (IKcicPublic' RandSymKey_IK) Equation ¨

where RandSymKey_IK is a securely-generated random key.
EncRandSymKey_SPK which is calculated as follows:
EncRanSymKey_SPK = PublicEncrypt (SPKSISpublic' Equation RandSymKey_SPK) where RandSymKey_SPK is a securely-generated random key.
7. The Recipient then sends the generated "Key Exchange Message" to the Issuer using the "Local Return Address" of the original "Statement Transfer Request" through a message which could be real-time or offline.
8. In Issuer-Initiated transfer mode, to ensure Statements can still be transferred in an offline mode (e.g. where internet connection drops after the initial step of "Key Exchange Message" transfer), both Issuer and Recipient, upon start-up, start listening to the local addresses of those Statements that have not been yet delivered in full for a limited. That ensures, half-left transfers can be continued after re-connection without the need to re-engage with the handshake. The use of offline pre-keys saved on online servers also allows the protocol not to need full real-time connectivity to work, as per the characteristics of X3DH key exchange protocol.
Step Upon the reception of the "Key Exchange Message" that contains RTKRpublic and vii EKRP.b1ic' the Issuer calculates the "Master Secret" as follows:
1. If elliptic curve keys are used:
MasterSecret = ECDH(SPKsispriõte' RTKRpubnc) II ECDH(IKSISPrivate EKRPublic) Equation 15 ECDH(SPKsisprivate, EKRpublic) ECDH(OTKSISPrivate' EKRPublic) The last ECDH call using OTK57spriPate is only made if "Index of OTICsisPublic" is present in the "Key Exchange Message".
2. If RSA keys are used:
MasterSecret = RandSymKey_SPK II RandSymKey_RTK
II RandSymKey_IK II RandSymKey_EK
II RandSymKey_SPK II RandSymKey_EK) Equation 16 II RandSymKey_OTK II RandSymKey_EK) Where RandSymKey_OTK
= PrivateDecrypt (OTKSISprivate Equation 17 EncRandSymKey_OTK) and RandSymKey_IK
= PrivateDecrypt (IKsisprivate, Equation 18 EncRandSymKey_IK) sisprivate' and RandSymKey_SPK = PrivateDecrypt (SPK
Equation 19 EncRandSymKey_SPK) and RandSymKey_RTK and RandSymKey_EK are generated randomly by secure random generators.
The final two concatenations (RanSymKey_OTK and RandSymKey_EK) are performed only if "Index of OTKs/spubi,," is present in the "Key Exchange Message".
Step Then the Issuer calculates the "Chain Key" as follows:
Viii ChainKey HKDF(length: 64, /Initial Key Material: MasterSecret, Equation 20 = Last 32 bytes of Salt: salt, info: InitialSeed0) where InitialSeed0 is a 32-byte fixed previously-selected set of bytes, the same as the ones used by the Recipient and salt is a 32-byte array of zeros.
Step ix The Issuer then calculates "Statement Encryption Key" as follows:

BaseKeyMaterial = HMAC(ChainKey,0x01) Equation 21 and then Statement Encryption Key, Statement MAC Key, Statement Encryption Initialization Vector, Recipient Digital Signature MAC Key, Statement Signing Message Encryption Key, Statement Signing Mes Equation 22 Statement Signing Message MAC Key = HKDF (Salt: salt, Initial Key Material: BaseKeyMaterial ,) info: InitialSeed, length: 192 where salt is a 32-byte array of zeros, and InitialSeed is a previously-selected set of bytes, the same as the one used by the Recipient.
Statement Encryption Key (32 bytes) will be used as the encryption key for the Statement Transfer Message.
Statement MAC Key (32 bytes) will be used alongside with HMAC-SHA256 for authenticating the Statement Transfer Message.
Statement Encryption Initialization Vector (16 bytes) will be used as the initialization vector within the AES256 scheme in Cipher Block Chaining (CBC) mode to encrypt the Statement Transfer Message.
Recipient Digital Signature MAC Key (16 bytes) will be used alongside HMAC-5HA256 for privately signing the Issuer's Digital Signature by the recipient to form the Recipient's Digital Signature.
Statement Signing Message Encryption Key (32 bytes) will be used at a later stage to encrypt the Statement Signing Message.
Statement Signing Message Initialization Vector (16 bytes) will be used at a later stage as the initialization vector to encrypt the Statement Signing Message.
Statement Signing Message MAC Key (16 bytes) will be used with HMAC-SHA256 to authenticate the Statement Signing Message.
Step x The Issuer then retrieves the full Statement record.
Step xi The issuer then creates the Issuer's Digital Signature for the Statement as follows:
SISprivate Issuer's Digital Signature = ECDSA or RSADSA (s, IK ) Equation 23 Where s represents the byte-serialized format of the statement data.
Statement Digital Signature can provide a number of important properties, including 1. It provides a mechanism of authenticating the contents of the statement and ensuring the contents have not been changed after the issuance by the Statement Issuer.
2. It provides a mechanism to verify that the statement has been genuinely issued by the Issuer included and cited in the Statement.
Step The Issuer serializes the Statement into a binary format, then uses the "Statement Encryption Key" to encrypt it and compiles a "Statement Transfer Message" and uses the "Local Return Address" field of the previously-received "Key Exchange Message" to send the "Statement Transfer Request" to the Recipient.
"Key Exchange Message" is accompanied by HMAC-5HA256 signature of its entire serialized form to be verified by the Recipient to ensure the message is transferred correctly. The calculated "MAC Key" is used in the generation of the HMAC-5HA256 signature of the statement by both parties.
Step If RSA keys are used, then Statement Transfer Message also includes the xiii followings:
EncRandSymKey_EK = PublicEncrypt (EKR, Equation 24 RandSymKey_EK) EncRandSymKey_RTK = PublicEncrypt (RTKR, Equation 25 RandSymKey_RTK) Step Upon the reception of the "Statement Transfer Message", the Recipient xiv 1. Verifies HMAC-5HA256 signature of the entire serialized form of the message to ensure contents are correct, 2. Using the "Pre-Key Bundle", the Recipient generates a Master Secret as follows:
a. If elliptic curve keys are used, the Recipient calculates a "Master Secret" as follows:
MasterSecret = ECDH(RTKRprivate' SPKSISPublic ) II ECDH(EKRprivate ' 1KSISPublic ) II ECDH(EKRPrivate SPKsispublic Equation 26 ¨
II
ECDH(EKRpriva,e, OTKsispublic if OTKsispublicis not available, the last ECDH() call is not made.
It then deletes EKRõivate.
b. If RSA keys are used, the Master Secret is calculated as follows:

MastcrSccrct = RandSymKcy_SPK II RandSymKcy_RTK
II RandSymKey_IK I I RandSymKey_EK
II RandSymKey_SPK I I RandSymKey_EK) Equation 27 II RandSymKey_OTK I I RandSymKey_EK) Where RandSymKey_RTK
= PrivateDecrypt (RTKR, EncRandSymKey_RTK) Equation 28 Ran dSymKey_EK
= PrivateDecrypt (EKR, EncRandSymKey_EK) Equation 29 and EncRandSymKey_EK and EricRandSymKey_RTK are included in the incoming Statement Transfer Message.
3. The Recipient then generates a "Chain Key", as follows:
ChainKey = Last 32 bytes of ((HKDE(length: 64, Initial Key Material: MasterSecret, Salt: salt, Equation 30 info: InitialSeed0))) where InitialSeed0 is a 32-byte fixed previously-selected set of bytes, the same as the ones used by the Issuer and salt is a 32-byte array of zeros.
The Recipient then generates the "Statement Encryption Key" which it will use to decrypt the Statement data that it will receive from the Issuer in future.
The same key will be derived by the Issuer as per the protocol. The Statement Encryption Key, as well as Mac Key and AES Initialization Vector, totalling 80 bytes of data, are calculated as follows:
BaseKeyMaterial = HMAC(ChainKey, Ox01) Equation 31 and then Statement Encryption Key, Statement MAC Key, Statement Encryption Initialization Vector, Recipient Digital Signature MAC Key, Statement Signing Message Encryption Key, Statement Signing Mes: Equation 32 Statement Signing Message MAC Key = HKDF(Salt: salt, Initial Key Material: BaseKeyMaterial , Info: InitialSeed, Length: 192) where salt is a 32-byte fixed non-changing array of zeros, and InitialSeed is a previously-selected fixed set of bytes.

4. Uses the already-calculated "Statement Encryption Key" to decrypt the message, 5. Persists it locally on its local secure encrypted storage, 6. Updates its state and shows the Statement to the user.
7. It then compiles a Statement Signing Message to include the followings:
a. Random Statement ID
b. Statement Time Stamp c. Transaction Marker, for the calculation of which, the Recipient generates an at least 256-bit random "Reusable Transaction Marking Private Key"
RTMPK for the issuer (if it is the first Statement ever received from the issuer), or, retrieves the previously-generated key (if it is not the first time a Statement is being received from the issuer).
It then uses it to generate a "Transaction Marker", as follows:
Transaction Marker = HMAC ¨ SHA256 Kcy = HKDF( RTMPK), Equation 33 Message = Statement Issuer Identifier It is obvious that the Transaction Marker is derived from the Statement Issuer Identifier and for the same issuer-recipient pair will remain the same. This is equivalent to the same recipient marking statements with the same markers. The equality of these markers over time will enable the issuer to dice and slice their sales data based on the same purchaser whilst there remains no way for the intermediary and the issuer to trace back to the identity of the purchaser hence preserving recipients' identity, anonymity and privacy.
The private Reusable Transaction Marking Key remains secure and not shared with any parties.
It is obvious that the message passed to HMAD-5HA256 is the identifier of the issuer which could be known by an attacker. However, the use of the one-way HKDF ensures over a private Transaction Marking Key assures that the Signing key remains private which prevents possibilities of brute forcing a transaction marker to identify a recipient.
d. "Recipient Digital Signature", which acts as the private digital signature of the transaction provided by the statement recipient.
It helps a future mechanism to verify that the recipient claiming they are the ones who received the statement are the ones who actually did so. In the context of claiming a purchase and or claiming loyalty or marketing offers applicable to a buyer, this signature can have a pivotal role.
Accordingly as illustrated in Figure 9:

Recipient Digital Signature = HMAC ¨ 5HA256( Key = Recipient Digital Signature MAC Key, Equation 34 Message = Issuer's Digital Signature) It is obvious that unlike Issuer's Digital Signature on the statement which is based on their private identity key and therefore is a publicly verifiable signature, Recipient Digital Signature is derived from an agreed-upon Recipient Digital Signature MAC Key, only and only known to the issuer and recipient hence protecting the identity of the recipient from all parties, including but not limited to the intermediary.
Step Upon the reception of the Statement Signing Message from the recipient, the xv issuer 1. Stops listening to the its own "Local Return Address" and hereby, the temporary communication channel ceases to exist 2. Decrypts and verifies the authenticity of the incoming Statement Signing Message using Statement Signing Message Encryption Key, Statement Signing Message Initialization Vector and Statement Signing Message MAC Key calculated in the previous steps.
3. The issuer uses the Recipient Digital Signature MAC Key and the Issuer's Digital Signature it calculated in the past for the relevant Statement to calculate its own version of the Recipient's Signature and compare it with the supplied one. If both are equal, the transaction is over. If they are not equal, the transfer stops with an error.
4. It then reflects the Transaction Marker and Recipient's Digital Signature on the relevant Statement record and informs the successful delivery of the Statement.
Step Statement Owner Verification Process:
xvi It can be verified that a person with a statement and an Issuer were the ones involved in the initial transfer of the Statement at the time of statement issuance at two levels:
1. Via "Statement-Issuer Verification Code" which can be calculated and saved by both issuer and recipient in common and represented as a OR code, (numeric code or any other applicable form), as follows:
Statement ¨ Issuer Verification Code = lKsIspUbljC II RTKR
¨Public Equation 35 Optimally, when both recipients and issuers calculate the same code based on their version of records, it can be deducted that the parties involved in the original transfer of the statement are the ones owning these public keys.
Checking these values can be made possible by Recipient's App which can scan the Statement Verification Code generated by the Statement Issuer's Portal for a Statement as a OR code which can be then compared to a code that can be generated against local recipient's data.
Alternatively, it can be fed into a key derivation function to calculate a numeric value that can be checked by both parties visually and manually as a guarantee that both parties checking the verification code are the same parties at the time of the reception of the statement.
2. Using an "Interactive Verification Challenge", the process comprising a. An operator on behalf of a Statement Issuer looks up a Statement that needs to be verified using the identifier of the Statement provided by a Recipient b. The Issuer then looks up the Statement and the RTKRpõbii, used to transfer it. It then generates a random string "Verification Challenge" and represents it as a code that can be either scanned as a QR code by the Recipient, or, entered numerically and manually.
The OR code will include a secured random ephemeral return "Local Return Address" that can be used by the Recipient to send back the Verification Challenge Response to the Issuer.
c. The Recipient then looks up RT KR pri,õõ used to transfer the Statement and calculates a digital signature against the provided "Verification Challenge", as follows:
Verification Challenge Response = ECDSA or RSADSA (Verification Challenge, RTKRprivate) Equation 36 It then uses the included "Local Return Address" in the OR Code to send back the Verification Challenge Response to the Issuer.
d. Upon receiving the Verification Challenge Response, the Issuer stops listening on the provided "Local Return Address" and checks the validity of the provided Verification Challenge Response as follows:
SigfnatureVerify (Verification Challenge Response, Equation 37 R
RTK
-Publid Where ECDSA Verify is used for Sig fnatureVerify when elliptic curve cryptography is used for implementation and RSADSA Verify is used when RSA is used for implementation.
If true, it can be proved that the party sending the Verification Challenge Response has access to the private key used during the original transfer of the Statement hence proving that the recipient is the party involved in the original transfer of the Statement at hand.
Step Transport Security:
xvii All traffic between all components like Issuers (SIS stations) and server back-ends, or between SIS SDK instances and Recipients, or between Recipients and server back-ends, or between web browsers and server back-ends must be secured using Transport Layer Security of at least v1.2 REFERENCES
BREYER, M. 2019. The surprising impact of paper receipts [Online]. Available:
https://www.treehuggercomienvironmental-policy/surprising-impact-paper-receipts.html [Accessed].
GUTIERREZ, M. 2019. Long paper receipts can stay for now, as California lawmakers reject ban [Online]. Available: https://www.latimes.comicalifomialstory/2019-30/Iong-paper-receipts-calitornia-lawmakers-reject-ban [Accessed].
MOXIE MARLINSPIKE, T. P. 2016. The X3DH Key Agreement Protocol [Online].
Available: htt halm* idoesis ecificationsix3dhl [Accessed].
MOZILLA.ORG. 2019. Web Crypto API [Online]. Available:
https://developermozilla.arg/en-US/docs/Web/API/Web Crypt API [Accessed].
SADLER, H. 2019a. Digital Invoice Wallet: Methods, Applications, Systems and Processes for Transferring Invoices to Buyers Seamlessly in Digital Format without the Need for Buyers to Share Their Personal Details [Online]. Available:
http://pericles.ipaustralia.gov.aulds/auspat/applicationDetails.do?applicationN
o-20 19100146 [Accessed].
SADLER, H. 2019b. 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 [Online]. Available:
httplipericles.ipaustralia.gov.au/olsiauspatlapplicationDetails.do?applicationN
a=20 19100775 [Accessed].

Claims

- 43 -1. A cryptosystem, systems, methods and applications for transferring end-to-end encrypted statements (e.g. receipts or pharmaceutical scripts), marketing and loyalty management, comprising a. A private cryptographically-protected history of statements that can only be known to the recipients of the statements b. Statement Issuers, who may operate one or many statement issuing stations (e.g. point of sale or medical scripting systems etc...) c. Statement Recipients d. A data transfer, marketing and loyalty management intermediary, operating the proposed cryptosystem, systems, methods and applications e. A Secure Statement Transfer Protocol, facilitating the end-to-end encrypted transfer of statements from statement issuers to statement recipients;
assuring the zero knowledge of the data transfer and marketing intermediary against the contents of the statements; making the inherently-opposing characteristics of "anonymity" and "individualization" possible at the same time in the context of loyalty management and marketing, with features comprising i. Defining message structures, steps, stages, conditions, conventions, conversations and actions taken between statement Issuers and statement recipients to securely agree upon independent common shared secrets and encrypt/decrypt statements ii. End-to-end client-side encryption of statements and their transfer (both in real-time and in offline mode) between statement issuers and statement recipients with each statement being encrypted with its own independent key(s) only known to issuers and recipients iii. Making use of a range of symmetric and asymmetric keys, the key agreement scheme comprising 1. Long-term asymmetric identity key pairs for issuers, issued per each issuing station, the public component of which is uploaded and accessible on intermediary servers, renewable upon choice 2. Mid-term asymmetric signed key pairs the public component of which is uploaded and accessible on intermediary servers 3. A number of optional one-time temporary asymmetric pre-keys generated in bunches the public components of which are uploaded to intermediary servers 4. Per-statement-independent asymmetric receipt transfer key pair, the public component of which is exchanged with issuers to derive multiple private keys 5. Per-statement independent asymmetric ephemeral session key pair, the public component of which is exchanged with issuers to derive multiple private keys 6. Up to three public keys from issuers being used alongside with the two public keys for each receipt to derive up to four intermediary common keys (e.g. using ECDH), which are then fed into key derivation functions after concatenation to derive multiple private keys used for different purposes like encryption and decryption and digital signature generation, such keys comprising a. Statement Encryption Key, b. Statement MAC Key, c. Statement Encryption Initialization Vector, d. Recipient Digital Signature MAC Key, e. Statement Signing Message Encryption Key, f. Statement Signing Message Initialization Vector, g. Statement Signing Message MAC Key iv. Marking transactions anonymously so that transactions made by the same statement recipient are marked equally for the same statement issuer without traceability back to the recipient's identity by any party including the data transfer and marketing intermediary v. Assuring statement recipients' privacy and anonymity that lay the foundations of "anonyniously-individualized loyalty management and marketing" in which, despite end-to-end encryption of statement data and statement history, and a 31-6 party's zero knowledge over an individual's statement history, individualized deals and offers, influenced by and deducted from the buyer's statement history, are mined and presented to them vi. Digitally singing statements by issuers to assure integrity, tamper-resistance and authenticity of statements as well as issuer's non-repudiability vii. Digitally singing transactions by recipients so that the identity of the recipient remains unknown to the issuer, as well as for the data transfer and marketing intermediary and possible attackers despite providing proofs of reception for statements viii. Making possible zero-knowledge deduction of rules, trends, patterns and theories against a private encrypted history of statements (like receipts) that are issued by issuing systems (e.g. Point of Sale (POS) systems or medical scripting systems) and transferred to recipients via a number of methods like QR code or RFID scans made by recipients, or made by issuers, or, seamless transfer that does not involve any scanning, involving or not involving an intermediary f. Optional "Abstract Anonymous Loyalty/Marketing Rules" which are anonymous rules that if fulfilled, certain deals/offer would become applicable to certain parties, with them being advertised publicly and downloaded by Recipient's Apps (i.e. software system used by the recipient, as will be discussed). An example of a rule can be as follows:
"For purchases between 1-Jul-18 to 1-Aug-18, OR, in the recent 45 days, those who have purchased (Item X, AND, Item Y) OR (Item A, AND, Item B) can receive a 10% discount with their next purchase until 30-Jun-19".
g. Optional Statement Issuing System (e.g. Point of Sale (POS)) Software Development Kits (SDKs) Instance which is an instance of the tools and software libraries installed on a statement issuing system, with features comprising i. Exposing libraries and functions that can be called by issuing systems for issuing statements based on the Secure Statement Transfer Protocol ii. The transfer of staternent data from issuing systems to statement recipients in an end-to-end encrypted fashion using independent encryption keys per each statement as per the Secure Statement Transfer Protocol iii. Locally encrypting and uploading issuer's copies of statements to the Statement Issuer's Portal using Independent-Per-Statement Issuer's Portal Upload Keys with issuer's copies of statement data being completely anonymous and not containing recipient's identifying inforrnation, as per the Secure Statement Transfer Protocol. These copies are uploaded to the Issuer's Portal in end-to-end encrypted fashion to enable portal issuers to manage billing, searching, and grouping, report generation and marketing/loyalty campaign creation in a centralized dashboard, all without the data transfer and marketing interrnediary having any knowledge of the contents of statements.
h. Statement Recipients' software application ("Recipient's App") with features comprising i. Reception of end-to-end encrypted statements from statement issuers ii. Secure storage of statements, encrypting data at rest making use of hardware-backed key-chain storage of personal devices, or any other applicable mechanism for secure storage iii. Searching, labelling and categorizing statements iv. Notifying user of quotas and expense management limits being approached, or GPS-based reminders of items to be returned v. Downloading optional publicly-advertised "Abstract Anonymous Loyalty/Marketing Rules" from online- back-ends, vi. Perforrning local, offline, non-server-side dynamic mining of offers by either checking the applicability of the downloaded public optional Abstract Anonymous Loyalty/Marketing Rules against the securely-saved local statement history (which is not shared with any parties, not even with the data transfer intermediary), or, by locally applying statistical models against the local statement history, or, by analysing categories statements have been categorized under and proposing offers from similar categories, or, by applying any other applicable local analysis schemes leading to the proposal of unique deals and offers to the recipient.
vii. Verifying statements correctness, integrity, tamper-resistance via verifying their digital signatures viii. Engaging in statement look-up with the Issuer's Portal and facilitating statement verification and purchase proofs ix. Claiming and helping honour applicable loyalty and marketing offers x. Re-encrypting, uploading and synchronizing the received statements with an online always-available cloud-based anywhere-available Recipient's Portal in such a way that the data transfer and marketing intermediary operating the portal remains unaware of the contents of statements using keys only known to the recipient.
i. Optional Application Programming Interfaces (APIs) which are publicly or privately available back-ends providing functionality around user or statement issuing machine registration or transfer of data between statement issuing machines and recipients j. Optional real-time communication back-end which provides facilities for the issuers (and their statement issuing systems) and recipients' app through any applicable means (including but not limited to point-to-point or Internet-Of-Things real-time publish/subscribe messaging protocols like Message Queue Telemetry Transport (MQTT)) k. Optional Statement Issuer's Portal, a web-based application, with features comprising i. Browse, view, download, categorize, group, generate reports and intelligence against the statements issued by the issuer the access to which is dependent on private keys only owned by the authorized users of the portal (e.g. the issuer or the employees of the issuing entity) hence assuring the zero-knowledge of the party operating the portal over the contents of the statements. Following the transfer of statements to recipients by each statement issuing station, such statements are encrypted with independent keys and uploaded to the issuer's portal by each issuing station with the encryption keys remaining known only to the authorized users of the portal, with the method to access statements in the issuer's portal comprising 1. The use of asymmetric key pairs (e.g. RSA) with the public key saved in the user key vault in the issuer's portal and shared with statement issuing stations 2. Statement issuing stations using the public asymmetric key of each portal user to locally encrypt statement encryption keys and saving them in a user's key vault for each statement 3. Statement issuing stations saving the encrypted staternents commonly for all portal users 4. The portal user being able to either own and provide the private asymmetric key when logging into the portal or alternatively, having their private asymmetric key saved in their key vault in locally-encrypted form for portability and ease of use 5. Optionally, portal users to own a Master Password, which is fed to configurable rounds of slowed key derivation functions like PBKDF2 to derive a hard-to-brute-force key for the user which will be used to locally encrypt and decrypt the private asymmetric key and uploading it to the user's key vault (if they choose to have it saved in their key vault) hence providing portability and ease of use without needs to maintain a private asymmetric key by portal users.
ii. Account and billing management for statement issuers iii. Create and manage optional "Abstract Anonymous Loyalty/Marketing Rules"
iv. Create loyalty and marketing campaigns v. Look-up statements and engage with the recipient's app on verifying statements, purchase proofs and loyalty/marketing offer claims vi. Honour applicable loyalty and marketing campaign offers without revealing or requiring recipients' identities I. Optional Recipient's Portal, an optional always-available from-anywhere-available web-based portal with features comprising i. Making use of a combination of asymmetric and symmetric cryptography to synchronise an always available list of a recipient's statements with statements received by and persisted on multiple instances of recipient's app on multiple devices in such a way that the operator of the portal (i.e. statement data transfer and marketing intermediary) will remain unaware of the contents of such statements;
the method comprising

1. The use of asymmetric key pairs (e.g. RSA) with the public key saved in the user key vault in the recipient's portal and shared with the recipient's app which will use it to encrypt the intendent-per-statement encryption keys used to encrypt each statement before uploading them to the recipient's portal.
2. Recipient's app using the public asymmetric key to locally encrypt statement encryption keys and saving them in a user's key vault for each statement 3. Recipient's app uploading the encrypted statements to the recipient's portal which will be saved in backend server-side databases 4. The recipient being able to either own and provide the private asymmetric key when logging into the portal or alternatively, having it saved in their key vault in locally-encrypted form for portability and ease of use 5. Optionally, the recipient to own a Master Password, which is fed to configurable rounds of slowed key derivation functions like PBKDF2 to derive a hard-to-brute-force key which will be used to locally encrypt and decrypt the private asymmetric key of the recipient in the recipient's key vault in the recipient's portal (if they choose to have it saved in their key vault) hence providing portability and ease of use without needing to maintain a private asymmetric key by the recipient.
ii. Browse, view, download, categorize, group, generate reports and intelligence against the statements issued by the issuer the access to which is dependent on private keys only owned by the authorized users of the portal (e.g. the recipient) hence assuring the zero-knowledge of the party operating the portal over the contents of tho statements iii. Account managernent iv. Import, export and synchronization of statements with multiple devices v. Client-side deduction of rules, patterns, trends and patterns over statement history and deducting anonymously-individualized offers and deals based on querying a local protected and private list of statements vi. Possibility to make claims against the mined offers and deals vii. Providing a possibility to the recipient to validate mined deals and prove applicability

2. The systems, methods and applications of claim 1 wherein the following core requirements are met:
a. Recipients' privacy and anonymity preservation as well as statement issuers' privacy preservation with their transactions history remaining completely private against data transfer and marketing intermediary, b. Issuers' bundling of statements received by the same recipient without getting to know the identity of the recipient, c. Data transfer and marketing intermediary's zero knowledge against the contents of the statements transferred and against the identity of the recipient in a transfer (if transfer involves an intermediary), d. Deducting individualized deals and offers based on recipients' private statement history without the history being disclosed to any parties or known to any parties, including the data transfer and marketing intermediary, e. Each statement being encrypted with keys that are independent, preserving the forward secrecy requirement of the transfer scheme, f. Statement integrity, correctness, and tamper-resistance as well as issuer's non-repudiablity against statements, g. Recipient's proof of receiving the statements in a way that protects the anonymity of the recipient against the data transfer and marketing intermediary and all other parties.

3. The systerns, methods and applications of claim 1 wherein an optional virtual printer driver captures statements data during a simulated print action, making calls to SDKs and APIs to abstract and hide the integration complexities of such SDKs and APIs from the perspective of a statement issuing system (e.g. a point of sale system) to minimize adoption and integration hassles.

4. The systems, methods and applications of claim 1 wherein all the requirements mentioned in claim 2 are fulfilled in settings and modes comprising a. The statement issuer starts the end-to-end encrypted staternent transfer process using QR codes or bar codes or Near Field Communication or RFID
scans performed by the recipient;
b. The statement recipient starts the end-to-end encrypted statement transfer process using QR codes or bar codes or Near Field Communication or RFID
scans performed by the issuer;
c. The statement recipient starts the end-to-end encrypted statement transfer process as part of an electronic payment or medical claim system where the recipient can have access to payment or transaction identifiers before the issuer without the need to perform any types of extra scans (e.g. a payment app on the recipient's device generating or having access to payment or transaction identifiers (e.g. ApplePay, GooglePay or the like operating an RFID or NFC scan or lhe like); or, We recipienl logging into an ihlernel banking or medical management system owned and operated by their banks or health care organization and the recipient having access to transaction identifiers as part of such systems) in which case the recipient would first create temporary statement wallet(s) and use them for the transfer of encrypted statements;
d. The statement recipient starts the end-to-end encrypted statement transfer process without performing any scans in which the recipient creating reusable statement wallets against their payment or health card(s) and uses them to receive statements from issuers.