Authenticity and Transaction Integrity of Physical Goods
Or How to Track & Trace your real Gucci Bag in a Blockchain
Joint article with Sebastian Gajek
Counterfeit consumer products are a major issue in many industries. European companies have an annual harm of around 60 million euros yearly due to product fraud. One of the reasons is that present anti-fraud methods do not allow consumers to validate the authenticity of products. Can the properties of an enterprise blockchain in combination with modern cryptographic NFC tags solve this issue? How does the cryptographic protocol need to be designed in order to eliminate the need for a middleman while achieving the highest level of security in the real world? It is these types of questions we discuss in the post and give a blueprint in Hyperledger Fabric how to securely implement a track & trace use case.
Introduction
Having a digital copy, for example, of a bag, car or building, sounds quiet futuristic at first, as there is a natural gap between the real and digital world. A physical good is real. One can touch and feel it. In contrast, a digital good is a simple sequence of 0’s and 1’s. The concept to link a physical object with a digital representation is known as digital twin. And a digital twin has versatile applications in the field of blockchains. In fact, the blockchain is a game-changing technology when it comes to tracking & tracing goods in an ecosystem with multiple stakeholders. Following the principal “Trust, but Verify!” the blockchain provides the common ground to track ownership, status and origin of a good/product — be it food or be it a luxury bag. The result is a unique, unclonable fingerprint of the good’s quality and quantity. Hence a deviation from this fingerprint is a strong indicator for fraud!
In the following, we discuss the required cryptographic protocols in conjunction with hardware-based security technologies to securely realize the anti-fraud mechanism with help of a (permission-based) blockchain technology.
The Setup — The Product Journey to the Customer
The life-cycle of a product begins with the manufacturing handled by a producer. A producer may be a company or any legal entity. After manufacturing, the product goes on a journey through several warehouses handed over by a multitude of transportation partners. Finally, the product is delivered to a store. A retailer (trader) aims to sell the product to a buyer (consumer). As the buyer may later on resell the good, the roles of retailer and buyer somewhat overlap.
In the following example use case, we assume Alice (consumer) buys a bag from Bob (retailer) who sells product’s of Charly (producer).
Note that this use case is specifically designed for a in-person to person trade. It is purposely not aligned for online transactions. The participants have to be physically in presence of the product. We also note that the technology can be easily adapted to a machine-to-machine scenario where the human actions are automated.
Goal — Detect & Prevent fraudulent Trades
Before buying the product, Alice wants to validate the authenticity of the product. That is, Alice wants to buy a bag manufactured from Charly. Put in other words, Alice aims to avoid to buy a fake bag from bogus Malory.
Requirement Analysis
We now specify the key functional requirements of the prototype.
- Information Storage: As a producer, Charly wants to store specific product information (so called meta data) in an immutable database.
The product information are available to anyone with read access to the blockchain and include an image, a product description, and references to the owner of the product. The data is the least minimal information to verify ownership and origin of the product. Further information may be added varying from use case.
- Product Type: As a producer, Charly wants to continuously add new products or new variants (types) of existing product lines. Each product has a unique cryptographic identifier (e.g. serial number/key).
Product types enhance and facilitate the registration of products with varying configuration. For example, there could exist several GUCCI bags of the type “GG Marmont Super-Mini”. They would all be of the same type and thereby look the same and also have the same description.
- Wallet: As a trader/producer/consumer, any party wants to overview the products in her belonging.
This should be a given, considering that a wallet within a blockchain is common practice.
- Check Ownership: As a trader/producer/consumer, any party wants to validate the current owner of the product.
The ownership check will mainly be important for further processes, but can also be useful when a product gets lost and has to be returned to the true owner.
- Product Verification: As a trader/producer/consumer, any party wants to be able to confirm the authenticity of a product.
To protect the parties against possible fake products, the product verification is fully integrated into the process. The product should be uniquely identifiable and verifiable.
- Product Transaction: As a trader and owner of a product, the parties want to pass the ownership.
Representing a typical transaction between two participants, the blockchain shall be used as a common board of truth.
2. The Architecture and Technology Choices
We have chosen a mobile app solution to interface with consumer and retailer due to the wide adaption and general acceptance in the consumer domain (Fig. 1). The app also acts as a communication middle layer between the blockchain and a NFC chip, encoding the digital twin identity of the product.
Therefore the smartphone is not necessarily required to be a trusted device. It will not store any information besides client information and does not execute any relevant logic beside an offline verification, but the user should normally trust his own device. The verification could also be outsourced to the blockchain, which would result in the security being solely based on the blockchain and the chip.
2.1 Blockchain
A public, permission-based blockchain will be used. It has to store the product data and implement protocols for product registration, validation and ownership transfer. We have chosen Hyperledger Fabric as the underlying blockchain framework and leveraged the Composer Playground for rapid prototyping.
2.2 NFC Chip
The NFC chip will be physically attached to a specific product. Force will need to be applied in order to remove the chip. Removing the chip implies a significant damage of the product. After extensive research and testing of several other NFC chips (including a DESFIRE EV1 and NTAG413), we have chosen a programmable JavaCard. The project was initially based upon the assumption that chips with the property of physical unclonable functions (PUF) are easily accessible for development purposes. This was sadly not the case! The main argument for the JavaCard was the universal programability. We exploited that freedom for the computation of RSA signatures in order to authenticate the NFC chip. More specifically, the NFC tag needs to be able to sign messages with a securely stored private key. Upon chip initialization, a public and private key pair is generated once. Another advantage of the JavaCard was NFC communication with a commercially available card reader. The JavaCard SDK was used to develop applets in the form of a .cap File which subsequently were written to the JavaCard. ISO7816 APDU commands were used to test and communicate with the applet.
3. The Protocols — The Tricky Party
3.1 Product Registration Protocol
Upon product registration, the ID and the public key of the chip will be stored and associated with the new product in the blockchain. It will be owned by the participant who triggers the registration. When the chip has been initialized correctly, the public key should be retrievable via the JavaCard applet. This will be important for further verification.
Another important aspect of the registration is the consideration of product types. During registration, new product types can be created or already existing types can be chosen. Essentially creating a 1:n relationship between the product type and the product itself. Therefore each new product should be unique and identifiable. The identifier (ID) needs to be stored in the blockchain, such that it can later be used to authenticate the physical product. The chip will be associated with a new product instance of the type. The creator of a new product instance will be defined as the first owner. Note that the registration is meant to be performed by manufacturers and producers.
3.2 Product Verification Protocol
The product validation is a crucial part of the application and should be based on a cryptographic signature from the product. It will be included passively in every process and the user will be notified if he is interacting with a fake product. To verify the authenticity of a product, a challenge-response approach is used. We chose a SHA-1 RSA 1024-byte algorithm to sign a random challenge which was generated by the smartphone of the verifier. If the user already has stored the verification key from the chip, a fast offline validation is enabled. Otherwise the verification key for a specific product identified by its chip ID can always be read from the blockchain.
Since the majority of products is expected to be authentic, this process will hiddenly be handeld by the smartphone app and the user will only be made aware of fake products. This protocol is triggered on nearly every interaction with the product.
3.3 Trade Protocol
Trading with authentic products should be handled in a well thought-through way. This next protocol has gone through many design iterations, but this is the final (so far) draft:
A step-by-step explanation:
- Both participants (buyer and seller) have to verify the product first. This is required to make sure that both are fully aware of which product they intend to trade and of course also that this product is authentic.
- The blockchain offers a transaction ID for the product which can be retrieved from both parties. This prevents replay-attacks and multiple buy offers should not impede an honest trading process. Existing transaction IDs are made obsolete when a product was successfully transferred.
- Since the buyer has to disclose his trading intention to the seller on location, we chose to add a QR-code as the third communication channel to our application, now consisting of HTTPS-Requests, NFC and the QR-code as optical channel, making it even harder for a malicious participant to compromise all channels during a transaction. After successful authentication of the product, the buyer can now approach the seller in person and discuss the trade details.
- If the seller agrees, he can simply scan the generated QR-code which contains the buyers ID, the chip ID and a signature of both. Now the seller can request the transaction ID from the blockchain and transmit his selling commitment.
- The buyer now waits for the blockchain to confirm that the sellers commitment has arrived successfully and thereby intends to transfer the product over to him. When the confirmation arrives, also he sends his commitment of purchase to the chain.
- The blockchain verifies the two commitments and both parties get redirected to an updated product detail page which now displays the change of ownership.
Further details on how the verification and commitments are handled by the blockchain can be read in our paper.
5. Screenshots of the Prototype
6. Security Analysis — Why The Protocols Do what they should Do
Our protocols have gone through many iterations and various attacking scenarios have been considered to bulletproof the design. By now we are pretty confident that the following security properties are achievable.
Tampering between the communication channel from the purchaser/owner to the chip can be detected once the response arrives. Integrity and device authentication of the chip is given through the unforgeability properties of the signature.
Every message to the blockchain is signed by the current user context. Integrity and entity authentication is achieved as well, when the purchaser and owner communicate over the blockchain.
Through HTTPS a level of transaction privacy is achieved. When the purchaser transfers his buying intention to the owner over the QR-code, the ID and a signature is included amongst the data; again guaranteeing entity authentication and integrity. Immutability is achieved through the optical channel. The lightwaves emitted from the smartphone should not be mutable.
These properties enable the following security guarantees:
- Unreplayability: As long as the chain can be trusted, only honest owners can initiate the transfer of their product.
- Mutual Consent: Ownership transfer is only possible if both participating parties agree on transferring the product.
- Traceability: The history and authenticity of any given product can be traced back over all owners to the manufacturer.
If you feel like we have missed something here, please comment below to open up for a discussion.
7. Outlook
While the result of the project is a solid prototype with a defendable cryptographic protocol, there is always room for further steps and improvement. One next step is to study further use cases in the track & trace domain. For example, if products get lost, stolen or broken, they should be marked as such. But what party has the privilege to report the event? As already mentioned in the NFC-Chip section, including a PUF chip would be desirable too. This way, the proof-of-concept would achieve the strongest form of unclonability of the digital twin associated with the product.
Acknowledgement
The prototype implementation was joint efforts with Torben Ulrich, Andrej Ott, and Oliver Kampf.
