alexanderkjeldaas
commented
6 years ago The document "ARTS XML Digital Receipt Technical Specification Version 3.1." states:
"3.3 Benefits of Digital Receipt as compared to POSLog The ARTS Data Model and ARTS XML Schemas are all taken as elements of a data processing system within a retail enterprise. As such, the primary usage of the information is processing by other applications within the enterprise."
However, the use-cases in the document include receipts sent by email which is clearly outside of a retail enterprise, a hostile environment where the majority of the traffic consists of fake data, spam, and various ways of phishing money out of victims.
The RFID use-case is similarly doing insecure communication with the customer, outside the retail enterprise. This likewise needs a way to verify the authenticity of the receipt.
I suggest that a mandatory W3 standard XMLDSIG (Wikipedia) or similar be added as a requirement for the swedish digital receipts.
For digital signatures, validating a signature through a certificate mechanism is often a separate issue (one needs a certificate from some trusted third party). But in a retail situation, even without any certificate authority that issues trusted certificates to merchants, signatures would be very valuable:
A merchant that just creates a certificate that is not issued by anyone (a self-signed certificate) will still be valuable because a user would be able to know that a set of receipts are from the same merchant, even if the identity of that merchant cannot be proven. This is valuable, because it means that an adversary must succeed in injecting bad/fake the first time a customer receives a receipt. Any subsequent receipts that are faked would be detected. Also, if an attacker succeeds in sending a fake receipt for a given organization once, the first time a non-fake receipt is received from the same organization, a processing system will be able to see an inconsistency and order a manual review of older receipts.
Self-signed certificates and XMLDSIG seems to reasonably solve the requirements needed to be able to do accounting based on insecure delivery mechanisms such as email, or at least significantly reduce the likelihood of this standard being exploted.
UC_Customer_sales describes a use-case where a receipt it sent by email.
Let's say this is a corporate email account where further processing of the receipt is done. How can the email system verify that the receipt is real and not fake?
This is touched upon in the use case where the customer returns merchandise. "However it uses a digital receipt provider with the capability to verify the receipt and to connect the sales and return receipt."
Similarly to how the merchant needs to verify a digital receipt, a customer has the same need to verify that a received receipt is valid.
For example, taking a fake digital receipt sent by email and putting that into an accounting system is fraudulent and a crime.
In the document "ARTS XML Digital Receipt Technical Specification Version 3.1.0" section 7.1 there's an example of a digital receipt void of any kind of signature that I can see. Is this handled by some sort of envelope?
In the "ARTS XML Digital Receipt Technical Specification Version 3.1.0" there is no section discussing the threat model or security of the digital receipt system. I think this is required for this type of standard.