INTRODUCTION
In modern society, art is mostly seen as a luxury. Art ownership often implies the wealth and social status of an individual because of the high price fine art objects typically carry, especially those that are popular or were made by well-known artists among art appreciators. The role that art assumes in society has made the business of art forgery a highly profitable field. Art counterfeiting is by no means a new phenomenon [1]. However, in the modern era, where accessibility to art ownership is greatly increased and technology massively advanced, forging becomes easier, and the quality of counterfeits can be controlled and improved in a less complicated manner. Methods including printing and art printing are used to create reconstructions of existing art objects such as paintings, sculptures, and decorative arts [2].
From a legal standpoint, art counterfeit distribution is a serious violation of the law [2]. On the other hand, the economic damage of a forgery could be massive, as art objects are often sold at a high price. As a case example, around 80 million USD worth of scams shut down Knoedler & Co., one of the oldest galleries in Manhattan, in what was dubbed ‘the biggest art con in NYC history’ in 2011 [3]. The scam lasted from 1994 to around 2009, bringing light to the concerning truth that most people, especially those lacking expertise in art, cannot easily distinguish fake artworks from the original due to the quality and similarity of the two.
With the support of new technological inventions, digital art has since begun surfacing [4]. This type of art is no exception to counterfeiting. However, with the simultaneous development of distributed ledger technology (DLT), a blockchain-based solution using non-fungible tokens (NFT) on Ethereum was introduced. Digital artwork documentation is now able to be stored in blockchain as digital assets and marketplaces such as OpenSea further enable secure and authenticated trading using cryptocurrency. This solution is based on the tamper-resistance and traceability features of blockchain. However, while this solution seems to sufficiently provide authenticity assurance for digital art, it is not as straightforwardly applicable to physical art, or any type of art that is not stored digitally. This gap could become a breeding ground for art counterfeits. As previously established, the art counterfeiting business is heavily interlinked with the law and economy in both national and international markets, making this problem crucial to solve. Therefore, it is important to find a way to make use of the advancements in digital art to make its physical counterpart's authentication more accessible to the general public.
The traditional approach to providing authenticity assurance is through a certificate of authenticity (COA), a document that provides a certain level of guarantee that a product or a work is what it is being advertised as. This method aims to establish trust between buyer and seller and could work in preventing fraud. However, as a hardcopy document, the certificate can also be subject to forgery by irresponsible parties [5]. Furthermore, these certificates are not physically attached to the artwork, which means that there is not enough assurance that they truly belong to the artwork and vice-versa. This issue demands the use of other technologies to enhance reliability.
One modern effort to identify counterfeits is by using Radio-frequency Identification (RFID) or its subset, near-field communication (NFC), to provide unique identifiers for individual items or batches [6]. Both RFID and NFC have seen their use to replace the traditional barcode as a product identification method and could be straightforwardly applied in the artwork field. However, despite the seemingly higher degree of security it provides, there are still multiple attack vectors that come with it such as the use of fake tags. Therefore, there being no direct way to verify the origin of information inside the tags becomes another problem to consider. These problems further justify the need for a secure and practical system to ensure artwork authenticity.
The work of Mostarda et al. [7] included the implementation of RFID tags to ensure the authenticity of cultural assets. However, there are two underlying problems with their approach, which are: 1) The exclusion of minor art in the proposed solution, and 2) The lack of prevention for duplicate tags, which makes the effectiveness of the whole solution debatable. The exclusion of minor art is reflected by the use of latitude and longitude to store the geographical location of the physical asset in the algorithm, which would only be useful in the specific case that the writers brought up, which is assets stored in permanent sites, such as historical pieces in museums. This does not reflect well for artworks that are traded in the market, as they are not meant to be tied to a specific geographical location. As for the second problem, which is the lack of consideration for tag duplication scenarios, we believe that it was not explored at the time due to technology limitations.
In this paper, we propose a reliable solution that allows users with NFC-enabled smartphones to verify artwork authenticity by accessing their respective COA stored in the Ethereum blockchain. The main challenge of this work is how to integrate various technology components to provide layered protection of COA for artwork authenticity, and at the same time, the solution and flows need to be user-friendly even for those who are not well-versed in technology. We address this challenge by investigating all the implementation details of the technologies used and designing the flows based on the technologies and platforms (e.g. mobile apps) that are easy to adopt and accessible by normal end users. Our contributions are as follows:
- We design and implement an anti-counterfeit system that is suitable for physical artworks. The proposed system integrates emerging technologies, including blockchain, smart contracts, non-fungible tokens (NFT), and inter-planetary file system (IPFS), for providing the authenticity assurance of artworks.
- To enable the certificate of authenticity to be stored on blockchains, we adopt the eight core categories in the categories for the description of works of art (CDWA) standard into the creation of artwork digital certificates and map it in OpenSea-supported NFT metadata.
- The proposed system is secure, tamper-evident, usable, flexible, and has a reliable role-based identification mechanism. Users can easily verify the physical artwork's authenticity with the implemented ArtProtect mobile app using NFC-enabled smartphones. Our evaluation result shows that the proposed system is cost-effective and inexpensive to be deployed as a real-world application.
The remainder of this paper is organized as follows. Section 2 reviews existing literature on product counterfeiting solutions, both in general and in the artwork sector. Section 3 presents the design and architecture of the proposed system and the technologies used for the implementation. Section 4 contains a detailed explanation of the implementation of each system module. Section 5 details the system testing and analyses the system limitations. Finally, Section 6 concludes the work and discusses future enhancements that can be made to the existing system.
RELATED WORK
Anti-counterfeiting techniques
Counterfeiting becomes more harmful when it involves presenting the product in the market as being genuine to gain profit. Such type of counterfeited product is called a deceptive counterfeit. The existence of deceptive counterfeits has made it important to provide the general public with a way to distinguish between a fake product and a real one. Several workarounds for this have been proposed since decades ago. The traditional approach is to present a paper-based COA, which is an official document stating facts and descriptive information about the item, including its ownership or origin. However, paper-based COA has been said to be insecure because it can easily be lost or stolen, prone to physical damage, and can be forged with minimum effort.
Since then, this type of COA has been complemented with digital COA, which refers to a copy of it in the form of an electronic document. While digital COA mitigates the possibility of loss and damage, it does not necessarily protect forging and deception. The underlying reason is that there is no straightforward way to bind unique certificates to the genuine product, thus allowing scenarios such as genuine certificates being attached to fake products and certificate replicas being claimed as genuine.
The research of anti-counterfeiting measures then expands to the mitigation of document forgery, in this case, the COA forgery. With hardcopy certificates, the technique of optical character recognition (OCR) can be used to recognize and make comparisons from the written text in the document. However, this alone does not guarantee sufficient accuracy, as the average accuracy of character recognition ranges from 90% to 95% [5].
With digital copies being taken into account, the use of watermarks and two-dimensional (2D) barcodes has also been explored [8]. Watermark provides a certain degree of integrity assurance to the document. However, when its readability is disabled, it becomes ineffective against copying and forgery. Meanwhile, barcodes, along with other item identifiers such as QR codes, RFID, and NFC tags, are considered more secure when complemented with other technologies such as cryptographic techniques, including digital signatures and hash functions [9].
Anti-counterfeiting solutions in the artwork sector
Neri and Artuso [10] proposed Safeart, a system based on digital signatures to identify fake artwork. The system uses a device containing a wireless chip that is glued on the artwork (e.g. on the canvas) to prevent its removal. This device will be contacted by a PC that will issue a command to generate a pair of public and private keys. These keys, along with the public key of the device, the digital signature of the artist, and a timestamp will be sent to the PC to be stored in a database. One of the weaknesses of this proposal lies in the use of databases to store information. A database, even an encrypted one, is unsafe for recordkeeping because it is highly vulnerable to attacks such as SQL injection, VM image leaks, and even full-system compromises.
The approach of embedding an RFID tag for authenticity assurance of cultural assets was taken, implemented, and validated in the CUSPIS European Project by Mostarda et al. [7]. However, their proposed approach is only applicable to artworks that are kept in permanent sites. Also, it lacks of record-keeping method and digital representation of artwork. This work was later referenced in a more recent research paper by Steinberg et al. [11] that mentions the use of electronic tags in the world of art and culture in scenarios such as enhancing visitor experience in galleries and inventory management. The paper itself explored the use of such tags for long-term preventive care of fine art but did not cover the authenticity of the art objects.
Schirripa Spagnolo [12] brought up the possibility of using Hylemetric methods for artwork authentication. This method is similar to biometric authentication for humans, where some unique features of artworks are extracted to identify the original artworks. Schirripa Spagnolo et al. [13] proposed to use craquelure (i.e. a network of crack patterns on a painted artwork) as a unique feature in their artwork authentication system. They also integrated with RFID and smartphones for the artwork authentication process. However, this method requires the experts to identify and extract the corresponding unique features of the artworks.
Another approach based on the physical characteristics of artwork for detecting counterfeit artwork is using hyperspectral imaging [14]. This method detects light within the range of ultraviolet and far-infrared and analyses the spectral features for artwork authentication. Using this approach may require special equipment for the spectral analysis and it may not be suitable for normal end users that do not have a strong technical background.
As technology progressed, the authenticity assurance method for a wider range of media, including multimedia, began to be researched. The problem of multimedia copyright and security breaches was addressed by Vishwa and Hussain [15] in a paper that proposed a decentralized data management framework using blockchain and smart contracts. The use of this supporting technology solves the problem of using traditional databases for recordkeeping. The framework allows users to store, query, share, and audit multimedia data. User authenticity in the framework is checked through digital signature, and a smart contract is used to verify the access permission of the querying user and check whether data transfer is allowed by its owner. For data storage, an off-blockchain centralized cloud storage called data lake is used, and data partitioning and user authentication techniques are used to secure the stored data.
The works of Bacciu et al. [16] and Sung [17] both suggested the use of a combination of interplanetary file system (IPFS) and blockchain for minor artwork protection and copyright preservation, respectively. This combined technology is seen as effective since it allows for a hash comparison of the digital file of a copyrighted work in an uncomplicated manner. However, Bacciu et al.’s application mainly serves as a record-keeping system that lacks of physical linkage of the actual artwork to its digital representation in the blockchain.
Anti-counterfeiting solutions in other sectors
Traditional anti-counterfeiting solutions using RFID and NFC have been explored in areas such as international trading [18] and Halal food certificate authentication [19]. The common limitation of this approach is the insecurity of their centralized database. More recently, blockchain has been introduced into the solutions to counter this problem as seen in [20–23], where the authors came up with anti-counterfeiting systems for supply chains. This novel solution is proven to be more traceable and secure.
In fields other than supply chain management, similar anti-counterfeit solutions involving blockchain and smart contracts have also been proposed over the years. Some of the fields where the solutions can be applied are healthcare [24–26], academics [27, 28], real estate management [29, 30], and wine industry [31, 32].
All the recently suggested methods seem to conclude that RFID/NFC is a reliable technology for identification, and at the same time, blockchain can provide sufficient storage and transaction security to prevent counterfeiting.
THE PROPOSED SYSTEM
This work proposes a complete COA-reliant system for artwork anti-counterfeiting based on blockchain and NFC. Relevant artwork metadata that acts as a certificate of authenticity is stored in the blockchain and made accessible to anyone through a public mobile app. In the system, agents provide unique NFC tags to be embedded inside the original artwork. The unique NFC tags are digitally signed and associated with the COA stored in the blockchain. This provides a way for users to verify the authenticity of artwork by simply scanning the NFC tag using their smartphone. Based on the system's needs, several design characteristics are emphasized in the system:
Security: The system must be protected against malicious actions such as unauthorized modifications to the COA.
Tamper-evidence: Unauthorized tampering with the COA must be easily detectable.
Reliable role-based identification: The system must recognize different users based on their role to prevent unauthorized system use.
Ease-of-use: The system must be easy to understand, operate, and navigate without the need for a strong technical background.
Flexibility: The system must be supported by a wide variety of devices, including recent technologies such as newer smartphones.
In the following sections, we first describe the technologies used in the proposed system. We then go over the proposed system architecture and its operation flow.
Technologies used in the system
Blockchain
Blockchain technology has become a heavily researched field since its reintroduction by Nakamoto [33], and its later adoption in cryptocurrency. Put simply, a blockchain is a distributed ledger technology (DLT) in the form of an ever-growing chain of blocks containing records of transactions, linked together using an implementation of hash pointers. Each block in the blockchain contains a reference to the previous block in the form of a cryptographic hash of the previous block's transaction data in its header. This results in an overall digital fingerprint of the entire set of transactions and enables efficient and accurate verification without the need to know the complete content of the transactions involved.
The characteristics of blockchains, such as immutability, tamper-evidence, transparency, and flexibility, enable blockchains to have better security and versatility compared to other recordkeeping systems such as the traditional database [34]. In particular, the characteristic of immutability ensures that the content of blocks in the chain cannot be changed due to the nature of hashing, where even small changes in the data will result in big changes in the hash.
Ethereum and smart contracts
In July 2015, the blockchain platform Ethereum was introduced, marking the start of blockchain 2.0. In Ethereum, users can send transactions to other users. The resource allocation cost required to perform a transaction over the network is called gas. This cost is essentially the computational cost of using an Ethereum virtual machine (EVM). Gas value is calculated in Ethereum cryptocurrency ether (ETH), otherwise referred to as gwei. When a transaction is sent over the network, its gas limit is set. A gas limit is a value set by senders indicating the maximum amount of gas they are willing to pay for the transaction. The standard gas limit for an ETH transfer is 21,000 units of gas.
A smart contract is a piece of code written using JavaScript-like languages deployable on the blockchain, that possesses similar characteristics to classes in object-oriented programming. A smart contract can take input, store data, hold a state, gain information from external services, exchange digital assets, and express business logic. In Ethereum, smart contracts are written in the Turing-complete language, Solidity. First, users will write a smart contract using Solidity, and then translate it into Ethereum bytecode. This bytecode will then be added to a transaction and deployed on the Ethereum network. Every time a transaction is called from an instance of this deployed smart contract, its bytecode will be run in the EVM. This way, users can interact with a smart contract and perform operations such as read, write, and verify by sending the required information based on the rules of the smart contract in the transaction.
Ethereum smart contracts are treated as an account in the Ethereum network, except they are not controlled by users. A user-controlled account is called an external owner account (EOA). Smart contracts have similar properties to EOAs, such as balance and the ability to send transactions.
NFTs
In the context of blockchain, a token is a unit of data stored in the chain. It is an ownable and tradeable asset that can be used by blockchain users. Two types of tokens can be stored in blockchain: fungible and non-fungible. Fungible tokens are divisible and do not have a unique property that sets different tokens apart. On the other hand, NFT are unique, indivisible virtual assets. Each token is characterized by a unique identifier that makes it one of a kind.
The main difference between a fungible token and an NFT is the content stored in them. Fungible tokens store value, whilst NFTs store data. This makes NFTs more suitable to be used as collectible and tradeable virtual assets, and at the same time can also represent a unique physical asset. Ethereum has ERC-20, ERC-721, and more recently, ERC-1155 token standards. ERC-20 tokens are fungible, while both ERC-721 and ERC-1155 are mainly non-fungible.
IPFS
Storing data directly in the blockchain, often referred to as on-chain storage, can be costly, especially for large volumes of data. This is where the concept of off-chain storage is introduced. Off-chain data is defined as non-transactional data, structured or unstructured, that is stored outside of the blockchain. IPFS is a commonly used distributed system for file storage and access off-chain.
The files in IPFS are content-addressable, which means that they can be retrieved based on their content instead of location. When a file is uploaded to IPFS, a hash value of the file is generated. This hash value is then used to identify the corresponding file and keep track of which nodes have copies of the file. Due to the nature of hashing, no different files can have the same hash value. In this way, unique files can reside within the IPFS network. There are two ways to store files in the IPFS network, which are by running a local node or running a node provided by third parties such as Infura.
Digital signatures
In a public network such as a public blockchain, there is a need for a verification method to ensure an action is done by a legitimate or authorized party. This is where digital signatures come into the picture. Each node in a network is assigned its unique pair of cryptographic keys that consists of a private key and a public key. The private key can only be accessed by the owner as it is confidential, while the public key is accessible by other nodes.
ECDSA (elliptic curve digital signature algorithm) is among one of the most commonly used algorithms for blockchain digital signatures. This is because compared to schemes like RSA (Rivest–Shamir–Adleman) and DSA (digital signature algorithm), ECDSA can achieve the same level of security with significantly shorter key length and simpler computational requirements. ECDSA achieves this by using elliptic curves over finite fields in the algorithm. It is also based on discrete logarithm problems instead of prime factorization problems. Currently, both Bitcoin and Ethereum use ECDSA as their digital signature algorithm. Libraries such as web3.js and ethers.js also use this algorithm as a basis for their signing and verification methods.
NFC
NFC is a form of short-range, contactless communication protocol of two electronic devices. NFC enables fast and reliable read, write, and transfer of information between devices in the vicinity. NFC is a type of RFID that allows two-way communications instead of one-way. Its system architecture consists of three main components: a tag, a reader, and a controller.
Records stored in an NFC tag follow the NFC data exchange format (NDEF), a standardized data format to exchange information to or from NFC tags. It consists of NDEF messages and NDEF records. An NDEF message is a container for NDEF records and a basic mechanism for data transportation. One message can contain multiple records of varying types.
Artwork metadata and certificate of authenticity
Certificate of authenticity (COA) originally refers to a proprietary paper-based certificate with an official seal or signature of an established expert proving that the item or product associated with the particular certificate is authentic. Nowadays, this term can refer to both the paper-based document and its digital counterpart. A COA contains key information or metadata about the product, such as its name, origins, date of creation or issuance, measurements, and other verifiable documentation, to support the proof that the product is genuine. For different types of products, different sets of metadata might be needed to serve this purpose.
The digital certificate of authenticity of each artwork contains relevant metadata that is sufficient to prove the legitimacy of the piece. According to categories for the description of works of art (CDWA), which is an XML schema or guideline released by J. Paul Getty Trust [35] that sets a standard for data content of visual arts and related disciplines, there are 31 description categories for a work of art in a broad sense, eight of them being core categories, and the rest additional. The eight core categories in the XML schema are explained below:
Object/work: Identification of the artwork in a logical view based on its nature and components.
Classification: Placement of artwork in groups based on a known classification scheme.
Titles or names: The given titles or names to identify the particular artwork.
Creation: The description of the creation, design, execution, or production of artwork and its components. This category includes two core subcategories, which are creator description and creation date.
- -Creator description: The core descriptions that shall be included in this subcategory are creator identity and creator role.
- -Creation date: A description of the date or time frame when the artwork was produced.
Measurements: Quantitative information on the size, shape, scale, and dimensions of artwork.
Materials/techniques: Description of the substances or materials involved in the creation process of the artwork, along with the techniques or methods used (e.g. oil on canvas, wool and cotton, gelatin silverprint etc.).
Subject matter: The narrative, iconographic, or non-objective meaning description of the content of the artwork.
Current location: Information on the name and geographic location of the repository that the work is currently in.
This work adopts the eight core categories in the CDWA standard for artwork in the creation of digital certificates of authenticity. The certificates will be stored in the Ethereum blockchain as tokens with the aid of IPFS. Because each artwork is unique and only one original copy can exist at a time, the certificates are most suitable to be stored as NFTs in the form of ERC-721 tokens with the help of OpenSea.
As the first and largest NFT marketplace, OpenSea makes it easier to fetch and trade ERC-721 tokens and the information stored in each of them, as seen in its popular use in digital art trading. However, OpenSea has its own supported metadata standards for ERC-721, which does not necessarily equate to the CDWA categories. In total, there are nine OpenSea-recognizable metadata properties, including image, image_data, external_url, description, name, attributes, background_color, animation_url, and youtube_url. Only the following three metadata properties are suitable to be mapped for the eight CDWA categories in this work (as shown in Table 1):
Name: The title or name of the NFT item.
Description: A human-readable description of the NFT item.
Attributes: Custom attributes that can be added to expand the description of the NFT item.
Each attribute can have its trait type and value.
TABLE 1 The mapping of CDWA categories to OpenSea NFT metadata properties.
| CDWA category | OpenSea metadata property | Attribute trait type | Data type |
| Object/work and classification | Attributes | Object/work type | String |
| Titles or names | Name | – | String |
| Creator description | Attributes | Creator | String |
| Creation date | Attributes | Created | String |
| Measurements | Attributes | Measurements | String |
| Materials/techniques | Attributes | Materials/techniques | String |
| Subject matter | Description | – | String |
| Current location | Attributes | Current location | String |
System architecture and operation flow
Figure 1 shows the architecture of the proposed system. The entities who interact with the system can be categorized into four different roles below:
[IMAGE OMITTED. SEE PDF]
- Administrator: The person in charge of system operations. An administrator can enrol artists and agents into the system and check whether a certain wallet address is registered as an artist or an agent.
- Artist: The individual or group who produces the artwork or has copyright ownership of the artwork. In this system, an artist provides all the details and authenticity proof of their artwork, as well as signs the unique NFC tags.
- Agent: The trusted party that represents the artists and connects artists to users in a transaction. Agents are responsible for the authenticity of the artworks they promote. In this system, the agent performs their role of uploading and minting artwork as NFT, writing and digitally signing the unique NFC tags, and embedding the tags on the physical artwork. An agent could be a representative of a gallery or other legitimate art institutions.
- User: The individual or group who is interested in knowing the legitimacy of artworks for the sake of ensuring authenticity in a transaction. In this system, the user can scan the embedded NFC tag of artwork with a smartphone and verify the legitimacy of the digital signature by accessing the corresponding certificate of authenticity stored on the blockchain using the proposed ArtProtect mobile app.
Overall, there are three main processes in the system: client enrolment, artwork registration and tag writing, and artwork authenticity verification. Each process will be explained in more detail below.
- Client enrolment: Figure 2 shows the sequence diagram of the complete client enrolment process. The term client refers to the agents and artists that are involved in the system. Before performing any operation, a client has to be enrolled into the system by the administrator. The administrator enrols agents and artists by calling the functions setAgentInfo() and setArtistInfo() respectively from the enrolment smart contract and passing their name and wallet address to the functions. This process will take place every time a new agent or artist registers to the system.
- Artwork registration: Figure 3 shows the sequence diagram of the complete artwork registration process. The main process begins when an enrolled artist wishes to register their artwork to the system through an agent. As a prerequisite, the artist must provide the metadata required for the certificate of authenticity in the form of a JSON file, as well as a clear picture of either the artwork or the creative process documentation to serve as legitimacy proof.
[IMAGE OMITTED. SEE PDF]
[IMAGE OMITTED. SEE PDF]
Upon receiving all necessary details from the artist, the agent will first upload the artwork image to IPFS and place its URL into a complete metadata JSON file that will be uploaded to IPFS, then use the returned URL as a parameter to mint the artwork to the Ethereum chain through an NFT smart contract. Upon minting, the NFT will become accessible through the NFT marketplace. This NFT data will be fetched by the web server through the marketplace API, and a dedicated page displaying its metadata attributes will be generated in the system mobile app.
The item ID of the newly minted artwork is then used as a message to be written into the NFC tag. This message requires signing by both the agent and the artist using their Ethereum wallet address. Thus, the final NFC tag will contain the item ID, agent wallet address, agent signature, artist wallet address, and artist signature. Now that the message has been written and signed in the NFC tag, the tag will be locked to prevent unauthorized tampering with its content. Then, it is embedded into or onto the corresponding artwork.
- Artwork authenticity verification: Figure 4 shows the sequence diagram of the complete artwork authenticity verification process. Artwork verification is done on the user side. With the existence of the NFC tag on an artwork, any user who wants to verify the authenticity of the artwork can use their NFC-enabled smartphone to access the NFC scanner webpage and perform scanning. The system will read the content inside the NFC tag and perform the following steps:
[IMAGE OMITTED. SEE PDF]
Check whether the agent wallet address is enrolled in the system. If it is not enrolled, the tag is considered invalid. If it is, proceed to step 2.
Check whether the artist's wallet address is enrolled in the system. If it is not enrolled, the tag is considered invalid. If it is, proceed to step 3.
Check whether the agent's signature is valid by verifying the signature against the agent's wallet address. If it is invalid, the tag is considered invalid and the artwork might be fake. If it is, proceed to step 4.
Check whether the artist's signature is valid by verifying the signature against the artist's wallet address. If it is invalid, the tag is considered invalid and the artwork might be fake. If it is, proceed to step 5.
Take the item ID and redirect the user to the corresponding certificate of authenticity page.
IMPLEMENTATION
This section discusses how each system module is implemented. The system implementation is mostly written in JavaScript, HTML/CSS, and solidity. The system uses the blockchain Ethereum as its back-end operating system. The smart contracts are deployed on Ethereum's Rinkeby Testnet, and the minted NFTs are fetched using OpenSea Testnet API. The user interface is a mobile application called ArtProtect, originally written in react JS, and migrated into a mobile app using android capacitor. The NFC tag used for storing information is an ST25TA tag developed by STMicroelectronics, which is a type 4A—ISO/IEC 14443A tag.
Client enrolment system
The administrator has control over the list of clients, namely agents and artists. The two lists are implemented and maintained separately, albeit in the same smart contract. The lists can be appended by adding new clients, searched, or edited, and items inside them can be ‘nullified’ or removed. Only the administrator is granted permission to perform actions such as adding new clients, editing client information, and removing clients. However, the search functions are publicly callable. This access control mechanism is implemented by importing the contract ownable from the OpenZeppelin contracts library.
The smart contract ‘enrolment’ was written to implement the enrolment module. In the contract (refer to Appendix 1(a) and (b)), the structs AgentInfo and ArtistInfo are declared to store and manage the information of all agents and artists, respectively. The AgentInfo (resp. ArtistInfo) struct is mapped to AllAgents (resp. AllArtists) by the key agent ID (resp. key artist ID). In total, there are five main algorithms used in the contract, each one implemented for both the agent and the artist.
The administrator can enrol new clients using the algorithm SetClientInfo (Algorithm 1). If the new client is an agent, the function SetAgentInfo() should be called. Likewise, if it is an artist, the function to be called is SetArtistInfo(). Both of these functions use separate counters to set IDs and take the inputs of the client name and client wallet address. The idCounter global variable is first incremented and set to an internal variable currentID. This value will become the ID of the newly added client. The variable currentID is used as a value to locate the new client data position in the client struct and set their name and walletAddress attributes to the input values.
ALGORITHM
SetClientInfo
| Permission: onlyOwner | |
| Input: clientName, clientWalletAddress | |
| 1: | Increment idCounter |
| 2: | currentID ← idCounter |
| 3: | AllClients[currentID].isActive ← true |
| 4: | AllClients[currentID].clientID ← currentID |
| 5: | AllClients[currentID].name ← clientName |
| 6: | AllClients[currentID].walletAddress ← clientWalletAddress |
Oftentimes, the administrator would need to edit enrolled client data. This is why the algorithm ChangeClientInfo (Algorithm 2) is needed. The algorithm takes the client ID and first checks whether the client with that ID is active in the struct. If the client is not active, that means they have been removed before or does not exist. In such cases, changes are not allowed to be made. If and only if the client is marked as active, their name and wallet address attributes will be replaced by the new input values.
ALGORITHM
ChangeClientInfo
| Permission: onlyOwner | |
| Input: clientID, newClientName, newClientWalletAddress | |
| 1: | if AllClients[clientID] is active |
| 2: | AllClients[clientID].name ← newClientName |
| 3: | AllClients[currentID].walletAddress ← newClientWalletAddress |
The algorithm GetClientInfo (Algorithm 3) is used when one wants to check a client's information stored in the struct by their client ID. It takes client ID as input and retrieves the name and wallet address of the client with that ID. Note that only active records can be retrieved. If the ID maps to an inactive client, their data will not be retrieved as they were either removed or do not exist. Instead, an invalid message will be shown. This prevents potential adversaries from gaining access to deleted records, which in rare cases may contain inaccurate or sensitive information if the removal was not properly done.
ALGORITHM
GetClientInfo
| Input: clientID | |
| 1: | if !(AllClients[clientID] is active) |
| 2: | return client invalid |
| 3: | else return AllClients[clientID].name, AllClients[clientID].walletAddress |
As a mechanism to check the existence of a client based on their wallet address is necessary for the digital signature verification that will take place later on in the process, the algorithm ClientExists (Algorithm 4) was designed to accommodate this function. It is included in the smart contract to avoid extensive processing in the client-side application. The function simply returns a Boolean that holds the value true if the client exists in the struct, and false if they do not.
ALGORITHM
ClientExists
| Input: queriedWalletAddress | |
| 1: | clientExists ← false |
| 2: | counter ← 0 |
| 3: | currentID ← idCounter |
| 4: | while (counter < = currentID) |
| 5: | if (AllAgents[counter] is active && AllAgents[counter].walletAddress = = queriedWalletAddress |
| 6: | clientExists ← true |
| 7: | Increment counter |
| 8: | return clientExists |
The final functionality in the contract is to remove a client (Algorithm 5). Due to the nature of structs and mappings, the removal works more like record nullifying by setting every attribute of the item to empty, null, or zero, instead of deleting the entire item. This implies that there still exists a client with the particular ID, but it is marked as inactive and its data has been nullified. The key to this removal is the attribute isActive. Once this attribute is set to false, it is irreversible as no function allows users to set its value back to true. This means that once a record is removed or nullified, it cannot be recovered anymore. If the administrator wants to add a removed client back to the system, they would need to create a new client using the SetClientInfo functions.
ALGORITHM
RemoveClient
| Permission: onlyOwner | |
| Input: clientID | |
| 1: | AllClients[clientID].isActive ← false |
| 2: | AllClients[clientID].name ← empty string |
| 3: | AllClients[currentID].walletAddress ← empty wallet address |
Mint NFT
NFT smart contract implementation
Minting is the process of turning an asset into a part of the Ethereum blockchain. It can be said that minting is the creation process of an NFT. Before any of the minting processes started, an NFT smart contract was written and deployed to Ethereum. This contract contains the function that will later be called to mint a token. The implementation of this contract requires importing the following contracts from the OpenZeppelin Contracts library:
Ownable — This contract is used to provide a basic access control mechanism that will be used to limit the use of smart contract functions only to its owner (the address of the contract deployment transaction sender).
ERC721URIStorage — This contract is used to provide the implementation of the ERC721 token with storage-based token URI management. This contract contains the functions used to mint tokens and set token URI.
The NFT smart contract has one main function MintNFT, which is based on the MintNFT algorithm. The MintNFT algorithm takes a recipient address and a token URI as inputs. Recipient address refers to the address of the user that will receive the newly minted NFT and become the asset owner. In this case, it should be the address of the administrator, from where all assets will be fetched. Meanwhile, the token URI should link to the file where all metadata of a token is stored. In the implemented function, both functions that are used to mint NFT and set token URI are imported from the ERC721URIStorage library. The MintNFT algorithm is shown in Algorithm 6.
ALGORITHM
MintNFT
| Permission: onlyOwner | |
| Input: recipientAddress, tokenURI | |
| 1: | Increment idCounter |
| 2: | newItemId ← idCounter |
| 3: | _mint(recipientAddress, newItemId) |
| 4: | _setTokenURI(newItemId, tokenURI) |
| 5: | return newItemId |
NFT minting process
Figure 5 shows the complete flowchart of the NFT minting process. This process involves communication with IPFS and the NFT smart contract that has been deployed and explained in the previous section. The proposed system handles all storing of data in IPFS using the third-party web application Pinata [36], as it is specifically built to support the uploading of NFT data to IPFS while providing a relatively simple GUI. Going by the numbers in Figure 5, the minting process is described below:
[IMAGE OMITTED. SEE PDF]
Off-chain storage of the artwork image in the IPFS network. This generates the file URL which contains its hash.
Generation of NFT metadata JSON. Following the mapping of CDWA core attributes to supported OpenSea metadata standards that were defined in Table 1, the metadata JSON example is shown in Appendix 1(c). Previously, we obtained the artwork image URL from its upload process to the IPFS. This value is pasted inside the metadata JSON under the attribute “image”.
The uploading of NFT metadata JSON to IPFS. In the same way, the artwork image was uploaded to the IPFS network, the complete metadata JSON file also needs to be uploaded to the network to obtain its file URL.
Pasting of metadata JSON URL as tokenURI input in the MintNFT function call. The process of minting will be handled by a ‘mint-nft’ script, which will be responsible for calling the MintNFT function from our NFT smart contract.
NFT minting. The NFT is minted via the ‘mint-nft’ script by sending a transaction to the NFT smart contract. The transaction is defined as shown in Appendix 1(d).
The information in the transaction is explained as follows:
- from — The wallet address of the sender. In this case, it refers to the agent's wallet address (public key).
- to — The address of the receiver. Because we are interacting with a smart contract, this field should contain the address of the deployed NFT smart contract.
- nonce — The nonce of the sender's account which includes the number of transactions sent from their address.
- gas — The estimation of gas price needed to perform the transaction.
- data — The function to be called from the NFT smart contract. Because we are calling the MintNFT method, which requires the parameters recipient address and token URI, these values must be passed here. The recipient address refers to the wallet address where the NFT is to be minted. In this case, it is the wallet address of the administrator.
The transaction is signed by the agent, as the sender of the transaction, using their private key. Signing is done by calling the method signTransaction from the web3.eth.accounts library.
The generation of NFT. The process of minting may take a while to finish. Once it is finished, the minted NFT is listed under the receiver wallet's assets and can be viewed on interfaces such as OpenSea or the MetaMask mobile app.
Agent-side and artist-side
Item ID retrieval
After an artwork NFT is successfully minted, the next process is to take its item ID. This item ID will be the message to be stored in the NFC tag. An item ID has the following structure:
COLLECTION-NAME/ID
This format of item ID pertains to the path of the COA page in the user-side application. The collection name is the name of the collection that the NFT is a part of. Meanwhile, the ID is retrieved by running the JavaScript shown in Appendix 1(e) in a terminal. First, a variable containing the asset's OpenSea API URL is declared. The original URL structure if the contract was deployed in the Ethereum mainnet is shown as follows:
However, since the contract used for this work was deployed in Ethereum Rinkeby Testnet, the URL becomes the following:
The contract address in the API URL refers to the address of our NFT contract, as this is where the NFT is stored. Meanwhile, the token ID is that of the specific NFT that is going to be retrieved. Token ID is not to be confused with ID, as they are different attributes of an NFT. Both contract address and token ID are public and can be seen on OpenSea or other asset-viewing interfaces.
Running the script in Appendix 1(e) in the terminal will return the ID of the NFT token. Combining this value with the collection name, we get the final item ID, which will be the message stored in the NFC tag.
Message signing with metamask wallet
Before the item ID is written into an NFC tag, it is first hashed with the Keccak-256 hash function, and then both the agent and the artist have to sign it. The complete process of digital signature generation is shown in Figure 6. Each Ethereum account has a public key, which is their wallet address, and a private key. This private key can be exported only by its owner through their wallet. This work uses MetaMask as a wallet service, as it is the most popular crypto wallet to interact with Ethereum. MetaMask uses a Web3 Provider window.ethereum to inject a global API into websites that are open in browsers that support MetaMask plug-ins (e.g. Google Chrome). This provider allows the website to request Ethereum accounts and signatures by opening a separate window for users to log in to their MetaMask wallet. Thus, users do not have to manually input their public key and private key, as both information will be retrieved from their wallet after they log in.
[IMAGE OMITTED. SEE PDF]
Algorithm 7 shows the message signing module. For signing, the system uses a Signer from the library ethers.js, which is designed to interact with the Ethereum blockchain and can connect to Ethereum nodes over APIs such as JSON RPC, Infura, and Alchemy. The Signer used is JsonRpcSigner, a part of the JSON-RPC Ethereum API. Ethereum signing uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with a 256-bit key length, which is the length of an Ethereum private key. The output of the SignMessage algorithm is a set containing the original message, the signed message (signature), and the signer's address. In this case, the message will be the item ID.
ALGORITHM
SignMessage
| Input: message | |
| 1: | Request Ethereum account |
| 2: | signer ← get signer account |
| 3: | signature ← signer.signMessage(message) |
| 4: | address ← signer.getAddress() |
| 5: | return message, signature, address |
NFC tag writing and locking
This work uses ST25TA NFC tags manufactured by STMicroelectronics. A ready-made app by the tag manufacturer is used for tag writing purposes. This app was chosen because it is specially built for ST25 NFC tags, and it has all the necessary operations required for this work, including tag reading/writing and tag locking, which is included in area security. The app also provides additional features such as area management for memory configuration. In total, there are five plain text NDEF records that are stored in the tag, each with the following content in this specific order: Record 1— Item ID, Record 2 — Agent's wallet address, Record 3 — Agent's signature, Record 4 — Artist's wallet address, Record 5 — Artist's signature. Figure 7(a–e) show the details of these records.
[IMAGE OMITTED. SEE PDF]
After the tag is properly written, it will be permanently write-locked, which means that the content inside the tag will not be able to be rewritten, edited, or deleted by anyone. In the ST25 mobile app, the security and access control are managed in terms of areas. Areas are memory configurations in an NFC tag. The tags used for this work only utilize a single memory area, thus the entire Area1 will be permanently write-locked.
User-side
The user-side implementation is a mobile app called ArtProtect as shown in Figure 8. This app was written in React JS and migrated into an Android app using capacitor. The mobile app provides gallery and tag verification functions.
[IMAGE OMITTED. SEE PDF]
Gallery function
The gallery of ArtProtect displays all registered artworks, as shown in the screenshot of Figure 9. Each item links to its respective COA, which is a dedicated page in the app. The Rinkeby API fetching in the app is centralized in App.js. The fetching is done from the following URL:
[IMAGE OMITTED. SEE PDF]
Thus, there are two ways to access a COA, which are by scanning the correct tag or opening it through the ArtProtect gallery.
NFC tag verification
Overall, the NFC tag verification process is divided into two sub-processes: tag reading and digital signature verification. Tag reading is implemented with the aid of the ionic-native NFC plugin. After the records are successfully read and stored in variables, the digital signature verification process commences. The process follows Algorithm 8 shown below:
ALGORITHM
VerifyMessage
| Input: message, agentWalletAddress, agentSignature, artistWalletAddress, artistSignature | |
| 1: | agentIsValid ← verifyMessage(message, agentWalletAddress, agentSignature) |
| 2: | artistIsValid ← verifyMessage(message, artistWalletAddress, artistSignature) |
| 3: | if !(agent exists && artist exists) |
| 4: | throw error |
| 5: | else if (agentIsValid && artistIsValid) |
| 6: | redirect to COA page |
| 7: | else throw error |
Similar to the signing, digital signature verification also uses a JsonRpcSigner method, verifyMessage(). This method takes in three parameters: message, wallet address, and signature. Thus, the verification of agent signature and artist signature are handled separately and stored in the Boolean variables agentIsValid and artistIsValid, which values are true if the signatures are valid, and false otherwise.
The function first checks whether the respective agent and artist addresses are enrolled in the system. This is done by calling the AgentExists() and ArtistExists() methods from the enrolment smart contract. If any of them are not enrolled, the system sets an error message that will be displayed to the user. Otherwise, if both are valid, the function proceeds to check if both the agentIsValid and artistIsValid Boolean variables are true, which means that both the agent and artist signatures are valid. Only upon confirmation that both values are true will the system redirect users to the COA page. Otherwise, it sets an error message that will be displayed on the page.
For redirection in case all the verification passes, the system will take the item ID (Record 1). This item ID is part of the path of its COA page. The COA page can be accessed through the following path:
/gallery/COLLECTION-NAME/ID
Note that COLLECTION-NAME/ID is the format of an item ID. Thus, by appending the item ID retrieved from the valid NFC tag to the first part of the path, the routing to the corresponding page can be done straightforwardly.
TESTING AND EVALUATION
The testing and performance analysis were conducted on two platforms: one personal computer (PC) for smart contract and web application testing, and a mobile device for mobile app and NFC testing. The specifications of the devices are listed as follows:
- PC. ASUS VivoBook A442U, Intel Core i7-8550U CPU @ 1.80 GHz 1.99 GHz processor, 8 GB installed RAM, Windows 10 operating system.
- Mobile. Samsung Galaxy Note 9, 128 GB RAM with 32 GB external memory, Android Version 10.
Tag verification testing
The following four scenarios are used to test the tag verification function in our system.
- Case 1: Normal flow. The normal operation flow requires both wallet addresses of agent and artist to be enrolled in the system, and both signatures of agent and artist to be valid. In this scenario, the system redirects users from the validation page to the COA of the respective artwork. This redirection is based on the item ID stored in the NFC tag. The screenshot of Figure 10 shows an example of the system behaviour under a normal operation flow.
- Case 2: Invalid wallet address. Case 2 assumes the signatures are valid, but one or all of the wallet addresses are not enrolled. In this scenario, the system responds as shown in the screenshot of Figure 11. The user is notified through an error message that the tag issuer is not recognized, which means that the artwork is likely to be counterfeit, as unrecognized wallet addresses may indicate that the tag is forged by a malicious party using their wallet address.
- Case 3: Invalid signature. Case 3 observes system behaviour under the assumption that both the agent's and artist's wallet addresses are recognized, but one or all signatures provided were invalid. In this scenario, the system responds as shown in the screenshot of Figure 12. An error message that informs the user that the tag signature is invalid is generated, indicating that the artwork might be a counterfeit. Invalid signatures may serve as a sign that the tag integrity was compromised.
[IMAGE OMITTED. SEE PDF]
[IMAGE OMITTED. SEE PDF]
[IMAGE OMITTED. SEE PDF]
- Case 4: Missing record(s). A missing records case refers to a case where not all five records are present in the scanned NFC tag. This may indicate that the tag was compromised or does not belong to the system. In other words, a user could be scanning a completely unrelated NFC tag that does not contain the five required records in it. The system behaviour in response to this case is shown in the screenshot of Figure 13 which notifies the user about the invalidity of tag contents.
[IMAGE OMITTED. SEE PDF]
Cost evaluation
The overall cost of system operation is calculated by summing the individual cost of every smart contract transaction involved in the process, and the cost of an NFC tag. In total, there are two smart contracts deployed, enrolment and NFT. The fee of each deployment was estimated using Remix with Injected Web3 environment. Remix is an IDE for the development of solidity decentralized application (DApp) that is run in a web browser. With the Injected Web3 environment provided by this IDE, it is possible to connect to the MetaMask wallet and investigate the estimated gas fee for each transaction. Then, the actual transaction fee is observed via Etherscan. Table 2 shows the estimated gas fee for the deployment of both smart contracts compared to the actual fees of deployment in our implementation. The actual transaction fee did not see much deviation from the estimated gas fee. Thus, it can be said that every deployment of a similar contract is likely to result in a similar fee.
TABLE 2 Estimated gas fee of smart contract deployments.
| Smart contract | Estimated gas fee | Actual transaction fee in implementation |
| Enrolment | 0.00357537 ETH | 0.003586814467619808 ETH |
| NFT | 0.00692099 ETH | 0.0069240130979667 ETH |
The deployment fee will be paid once during the initial contract deployment. Then, some function calls will require more cost upon every transaction. This cost largely depends on the size of input the function takes as a parameter. For example, a longer string will make the transaction cost higher compared to a shorter one. In our functions, the inputs that may vary in length include name (string) and token URI (string). For the sake of testing, all name variables will be 25 characters in length, and token URI variables will be 80 characters in length, which are realistic values. Table 3 lists the estimated gas fees for each transaction calling the smart contract functions. Note that not all functions will be used in a normal operation at all times. For example, the change and remove functions will only be called whenever necessary. However, their values still need to be taken into account.
TABLE 3 Estimated gas fee of smart contract function calls.
| Function | Smart contract | Estimated gas fee |
| SetAgentInfo() and SetArtistInfo() | Enrolment | 0.000343 ETH |
| ChangeAgentInfo() and ChangeArtistInfo() | Enrolment | 0.000233 ETH |
| RemoveAgent() and RemoveArtist() | Enrolment | 0.000084 ETH |
| MintNFT() | NFT | 0.000464 ETH |
Table 4 shows the estimated fee of each transaction involved in the system and what they would amount to in US Dollars (USD). Note that the conversion rate between ETH to USD frequently fluctuates, sometimes extremely. The calculation in Table 4 is based on the rate at the time of writing (18 May, 2023) and is purely calculated to better illustrate the transaction cost. From Table 5, it is apparent that the initial deployment cost paid by the administrator is 0.01049636 ETH (19.18 USD). Then, the operation cost is calculated. With two clients (an agent and an artist) and one NFT, the total blockchain use cost is 0.00115 ETH (2.10 USD). The cost of an NFC tag ranges approximately from 0.05 to 0.5 USD per tag, bringing the total operations cost to between 1.2 USD to 2.05 USD. From this amount, 0.000686 ETH (1.25 USD) for enrolment is paid by the administrator, and 0.000464 ETH (0.85 USD) for minting is paid by the agent. Thus, it can be said that the total cost of using our system for artwork anti-counterfeiting is minimal for small amounts of records.
TABLE 4 Approximate cost of blockchain use.
| Transaction | Approximate cost (ETH) | Approximate cost (USD) |
| Contract deployments | 0.01049636 ETH | 19.18 USD |
| Client enrolment | ||
| 1 client | 0.000343 ETH | 0.63 USD |
| 10 clients | 0.00343 ETH | 6.27 USD |
| 100 clients | 0.0343 ETH | 62.67 USD |
| NFT minting | ||
| 1 NFT | 0.000464 ETH | 0.85 USD |
| 10 NFT | 0.00464 ETH | 8.48 USD |
| 100 NFT | 0.0464 ETH | 84.78 USD |
| Client information modification (per function call) | 0.000233 ETH (cost only applies when the function is called) | 0.43 USD |
| Client removal | 0.000084 ETH (cost only applies when the function is called) | 0.15 USD |
TABLE 5 Comparison of ArtProtect to previous works.
| Work | Limitation | ArtProtect solution |
| Mostarda et al. [7] | Reliance on geographical location unsuitable for minor art, lack of recordkeeping method and digital representation of artwork | High system accessibility through the use of open platforms, the use of blockchain, and tokens to represent and keep artwork in the digital space |
| Neri and Artuso [10] | The use of traditional databases for recordkeeping | Replacement of the database with the more reliable blockchain |
| Schirripa Spagnolo [12] | Expert requirement, complicated implementation | High usability with no expert requirement, simple implementation |
| Huang et al. [14] | High user technical background requirement, complicated implementation | Low user technical background requirement, simple implementation |
| Vishwa and Hussain [15], Bacciu et al. [16], Sung [17] | Lack of physical connection between artwork and its digital representation in the blockchain | The use of NFC tags with digital signatures to establish a strong and secure physical connection between artwork and its digital blockchain counterpart |
Discussion
The proposed system has achieved the following design goals established in Section 3:
Security is achieved by the use of blockchain and IPFS, which effectively provides decentralization to the system and avoids a single point of failure. IPFS prevents unauthorized parties from locating a file without knowledge of its hash, while blockchain immutability or tamper-proofness prevents unauthorized tampering with records. Additionally, tag security is achieved by permanently locking the tags after a successful write.
Tamper-evidence is achieved by the use of digital signatures as an additional layer of protection. A digital signature is like a package seal that will be broken if its content is broken into and altered. In this case, if an adversary modifies the NFC tag content, it will easily be detected during the digital signature verification. A 256-bit ECDSA digital signature is implemented in this proposed system which achieves a similar security strength as a 3072-bit RSA signature [37]. Also, the Keccak-256 hash function used in the signing algorithm is an instance of the secure hash algorithm-3 (SHA-3) standard which outputs 256 bits of hash value and satisfies the principal security properties of collision resistance, preimage resistance, and second preimage resistance [38].
Reliable role-based identification is achieved by the implementation of the enrolment system using smart contracts, which gives the system the ability to recognize agents and artists by their wallet addresses. This way, if an adversary wants to write their own NFC tag, it will be detected as invalid by the system.
Ease-of-use is reflected in the mobile app ArtProtect, which provides clear instructions on how to verify an artwork, as well as comprehensive error messages when invalidity is detected in a tag as shown in Section 5.2.
Flexibility is reflected in the system's ability to be used on any NFC-enabled Android smartphone.
Table 5 details how the accomplishment of these design goals in the proposed system has improved the previous works that aim for the same purpose. However, despite its advantages, ArtProtect still comes with its own set of limitations, one of them being that it provides minimal protection against tag cloning, where a tag that appears genuine is embedded in a counterfeit artwork. This could happen if the exact content of a genuine tag is copied and written into a new tag, or under a more unlikely scenario, an adversary somehow got hold of both the agent's and artist's wallet account login details.
The system also works under the assumption that all agents are honest. In the case where dishonesty is involved, an agent could place a legitimate tag on an artwork counterfeit. The likeliness of this scenario is indeed lowered because the artist also signs the NFC tag. However, it is still possible that after the signing process is completed, the agent moves the tag to another item.
CONCLUSION AND FUTURE WORK
Counterfeiting is a concerning problem in the artwork field as it threatens law obedience and the economy. In this paper, an anti-counterfeiting system based on the Ethereum blockchain and NFC technology is proposed and successfully implemented. The system leverages the use of Ethereum smart contracts and IPFS to store artwork COA and display them in a mobile app called ArtProtect. It also introduces digital signatures in the NFC writing process. Due to the nature of the technologies involved, the implemented system is secure, tamper-evident, usable, flexible, and has a reliable role-based identification mechanism. It is also relatively cheap to implement and deploy. Thus, the proposed work is believed to be effective and efficient to serve as a solution for artwork anti-counterfeiting.
Currently, the purpose of the system is solely to provide authenticity assurance. While this functionality can stand on its own, it is most beneficial in the artwork market. Thus, in the future, a system expansion to cover a complete process of artwork trading, including payment and ownership tracking, would improve its usefulness. Since OpenSea, which is already a part of the implemented system, is a popular marketplace for digital artwork trading, its potential to provide this additional functionality can be explored more straightforwardly.
To improve tag security, an implementation of unique identifiers (UIDs) could be a viable solution against tag cloning. Recently, STMicroelectronics has also introduced TruST25, a digital signature and UID-based solution applicable to the ST25 tags [39]. However, more thorough research and analysis must be done to ensure its effectiveness, as the technology is still fairly recent.
The solution proposed in this paper has the potential to be extended to various other types of intellectual property. For example, in literature, it could be used to combat pirated books from being freely distributed. In the field of artistic work and inventions, which covers items such as art installations, sculptures, and tools, it could also be used to distinguish genuine items from potential counterfeits. However, the adoption of similar techniques in different fields still needs to be further researched as it comes with its own sets of challenges and unique conditions.
AUTHOR CONTRIBUTIONS
All authors read and approved the final manuscript. Cindy Handoko Tantowibowo: Conceptualization; methodology; software; validation; investigation; writing—original draft preparation; visualization. Wei-Chuen Yau: Conceptualization; methodology; validation; writing—reviewing and editing; supervision; funding acquisition.
ACKNOWLEDGEMENTS
Wei-Chuen Yau is supported by the Xiamen University Malaysia Research Fund under Grant XMUMRF/2019-C4/IECE/0011.
CONFLICT OF INTEREST STATEMENT
The authors declare no conflicts of interest.
DATA AVAILABILITY STATEMENT
The data that support the findings of this study are available from the corresponding author upon reasonable request.
APPENDIX
CODE SNIPPETS
struct AgentInfo {
bool isActive;
uint256 agentId;
string name;
address walletAddress;
}
mapping (uint256 => AgentInfo) AllAgents;
(a) Code snippet of Agents struct in the Enrolment smart contract.
struct ArtistInfo {
bool isActive;
uint256 agentId;
string name;
address walletAddress;}
mapping (uint256 => ArtisInfo) AllArtists;
(b) Code snippet of Artists struct in the Enrolment smart contract.
{
“attributes”: [
{
“trait_type”: “Creator”,
“value”: “Cindy Handoko”
},
{
“trait_type”: “Object / Work Type”,
“value”: “Drawing”
},
{
“trait_type”: “Created”,
“value”: “December 2020”
},
{
“trait_type”: “Measurements”,
“value”: “60 cm × 40 cm”
},
{
“trait_type”: “Materials / Techniques”,
“value”: “Watercolour pencil on 120gsm art paper”
},
{
“trait_type”: “Current Location”,
“value”: “Surakarta, Indonesia”
}
],
“description”: “A drawing of a snake with a 3D effect.”,
“image”: “https://gateway.pinata.cloud/ipfs/QmWkt95r8JCCCqT2AnNR6QbbREj73yqtMvNQFTYtZ6F8jA”,
“name”: “Slither Weather”
}
(c) An example of metadata JSON format for NFT minting.
const tx = {
from: PUBLIC_KEY,
to: contractAddress,
nonce: nonce,
gas: 500000,
data: nftContract.methods.MintNFT(RECIPIENT_ADDRESS, tokenURI).encodeABI(),
}
(d) Code snippet of transaction setup.
var url = ASSET-API-URL;
var XMLHttpRequest = require('xhr2');
var xhr = new XMLHttpRequest();
var response;
xhr.open(“GET”, url);
xhr.onreadystatechange = function () {
if (xhr.readyState = = = 4) {
response = xhr.responseText;
var stringify = JSON.parse(response);
console.log(stringify[“id”]);
}};
xhr.send();
(e) Code snippet of ID retrieval JavaScript.
Lenain, T.: Art Forgery: The History of a Modern Obsession. Reaktion Books, London (2012)
Rim, S., Kim, K., Byun, S.: A review of counterfeit artwork controversies and civil case practices. J. Arbitration Studies 28(3), 75–88 (2018)
Malesevic, D.S.: The biggest art con in NYC history: How a brazen $80 M scam that fooled collectors with fake Pollock and Rothko masterpieces shook the art world and brought down Manhattan's oldest gallery. https://www.dailymail.co.uk/news/article‐9011295/New‐documentary‐Look‐examines‐60‐fake‐paintings‐sold‐80‐million.html (2020). Accessed 23 Jan 2022
Sintellyapp: The Rise of Digital Art. https://sintelly.com/articles/the‐rise‐of‐digital‐art (2020). Accessed 23 Jan 2022
Dlamini, N., Mthethwa, S., Barbour, G.: Mitigating the challenge of hardcopy document. In: 2018 International Conference on Advances in Big Data, Computing and Data Communication Systems (icABCD), pp. 1–6. IEEE, Piscataway, NJ (2018)
Khalil, G., Doss, R., Chowdhury, M.: A comparison survey study on RFID based anti‐counterfeiting systems. J. Sensor Actuator Networks 8(3), 37 (2019). [DOI: https://dx.doi.org/10.3390/jsan8030037] (2021). Accessed 23 Jan 2022
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
© 2024. This work is published under http://creativecommons.org/licenses/by-nc-nd/4.0/ (the "License"). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.
Abstract
Counterfeit artwork presents a significant risk to copyright holders and the economy. Without expertise in art, it is not straightforward to distinguish an artwork counterfeit from a genuine piece. This work designs and implements a reliable solution that enables users with near‐field communication‐enabled Android smartphones to verify artwork authenticity by accessing its respective certificate of authenticity stored in the Ethereum blockchain. To represent a physical artwork, the artwork image and metadata are stored in an inter‐planetary file system and minted as an ERC721 non‐fungible token to a smart contract deployed in Ethereum Rinkeby Testnet. The mobile app ArtProtect was developed to generate certificate of authenticity based on each non‐fungible token fetched through OpenSea Testnet API. Users access this information by scanning an near‐field communication tag embedded into the artwork. The content of the tag is signed by the respective artwork's artist and responsible agent by using Ethereum signing with their Ethereum wallet accounts. Through testing and analysis, the implemented work is secure, tamper‐evident, usable, flexible, and inexpensive to be applied to a real‐world scenario.
You have requested "on-the-fly" machine translation of selected content from our databases. This functionality is provided solely for your convenience and is in no way intended to replace human translation. Show full disclaimer
Neither ProQuest nor its licensors make any representations or warranties with respect to the translations. The translations are automatically generated "AS IS" and "AS AVAILABLE" and are not retained in our systems. PROQUEST AND ITS LICENSORS SPECIFICALLY DISCLAIM ANY AND ALL EXPRESS OR IMPLIED WARRANTIES, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES FOR AVAILABILITY, ACCURACY, TIMELINESS, COMPLETENESS, NON-INFRINGMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Your use of the translations is subject to all use restrictions contained in your Electronic Products License Agreement and by using the translation functionality you agree to forgo any and all claims against ProQuest or its licensors for your use of the translation functionality and any output derived there from. Hide full disclaimer
Details
1 School of Computing and Data Science, Xiamen University Malaysia, Sepang, Selangor, Malaysia