ERC-4519: Non-Fungible Tokens Tied to Physical Assets

Interface for non-fungible tokens representing physical assets that can generate or recover their own accounts and obey users.

Metadata

Status: FinalStandards Track: ERCCreated: 2021-12-03

Authors

Javier Arcenegui (@Hardblock-IMSE-CNM), Rosario Arjona (@RosarioArjona), Roberto Román (roman@imse-cnm.csic.es), Iluminada Baturone (@lumi2018)

Requires

EIP-165, EIP-721

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP standardizes an interface for non-fungible tokens representing physical assets, such as Internet of Things (IoT) devices. These NFTs are tied to physical assets and can verify the authenticity of the tie. They can include an Ethereum address of the physical asset, permitting physical assets to sign messages and transactions. Physical assets can operate with an operating mode defined by its corresponding NFT.

Motivation

This standard was developed because EIP-721 only tracks ownership (not usage rights) and does not track the Ethereum addresses of the asset. The popularity of smart assets, such as IoT devices, is increasing. To permit secure and traceable management, these NFTs can be used to establish secure communication channels between the physical asset, its owner, and its user.

Specification

The attributes addressAsset and addressUser are, respectively, the Ethereum addresses of the physical asset and the user. They are optional attributes but at least one of them should be used in an NFT. In the case of using only the attribute addressUser, two states define if the token is assigned or not to a user. Figure 1 shows these states in a flow chart. When a token is created, transferred or unassigned, the token state is set to notAssigned. If the token is assigned to a valid user, the state is set to userAssigned.

Figure 1 : Flow chart of the token states with addressUser defined (and addressAsset undefined)

In the case of defining the attribute addressAsset but not the attribute addressUser, two states define if the token is waiting for authentication with the owner or if the authentication has finished successfully. Figure 2 shows these states in a flow chart. When a token is created or transferred to a new owner, then the token changes its state to waitingForOwner. In this state, the token is waiting for the mutual authentication between the asset and the owner. Once authentication is finished successfully, the token changes its state to engagedWithOwner.

Figure 2 : Flow chart of the token states with addressAsset defined (and addressUser undefined)

Finally, if both the attributes addressAsset and addressUser are defined, the states of the NFT define if the asset has been engaged or not with the owner or the user (waitingForOwner, engagedWithOwner, waitingForUser and engagedWithUser). The flow chart in Figure 3 shows all the possible state changes. The states related to the owner are the same as in Figure 2. The difference is that, at the state engagedWithOwner, the token can be assigned to a user. If a user is assigned (the token being at states engagedWithOwner, waitingForUser or engagedWithUser), then the token changes its state to waitingForUser. Once the asset and the user authenticate each other, the state of the token is set to engagedWithUser, and the user is able to use the asset.

Figure 3 : Flow chart of the token states with addressUser and addressUser defined

In order to complete the ownership transfer of a token, the new owner must carry out a mutual authentication process with the asset, which is off-chain with the asset and on-chain with the token, by using their Ethereum addresses. Similarly, a new user must carry out a mutual authentication process with the asset to complete a use transfer. NFTs define how the authentication processes start and finish. These authentication processes allow deriving fresh session cryptographic keys for secure communication between assets and owners, and between assets and users. Therefore, the trustworthiness of the assets can be traced even if new owners and users manage them.

When the NFT is created or when the ownership is transferred, the token state is waitingForOwner. The asset sets its operating mode to waitingForOwner. The owner generates a pair of keys using the elliptic curve secp256k1 and the primitive element P used on this curve: a secret key SK_{O_A} and a Public Key PK_{O_A}, so that PK_{O_A} = SK_{O_A} * P. To generate the shared key between the owner and the asset, K_O, the public key of the asset, PK_A, is employed as follows:

K_O = PK_A * SK_{O_A}

Using the function startOwnerEngagement, PK_{O_A} is saved as the attribute dataEngagement and the hash of K_O as the attribute hashK_OA. The owner sends request engagement to the asset, and the asset calculates:

K_A = SK_A * PK_{O_A}

If everything is correctly done, K_O and K_A are the same since:

K_O = PK_A * SK_{O_A} = (SK_A * P) * SK_{O_A} = SK_A * (SK_{O_A} * P) = SK_A * PK_{O_A}

Using the function ownerEngagement, the asset sends the hash of K_A, and if it is the same as the data in hashK_OA, then the state of the token changes to engagedWithOwner and the event OwnerEngaged are sent. Once the asset receives the event, it changes its operation mode to engagedWithOwner. This process is shown in Figure 4. From this moment, the asset can be managed by the owner and they can communicate in a secure way using the shared key.

Figure 4: Steps in a successful owner and asset mutual authentication process

If the asset consults Ethereum and the state of its NFT is waitingForUser, the asset (assuming it is an electronic physical asset) sets its operating mode to waitingForUser. Then, a mutual authentication process is carried out with the user, as already done with the owner. The user sends the transaction associated with the function startUserEngagement. As in startOwnerEngagement, this function saves the public key generated by the user, PK_{U_A}, as the attribute dataEngagement and the hash of K_U = PK_A * SK_{U_A} as the attribute hashK_UA in the NFT.

The user sends request engagement and the asset calculates:

K_A = SK_A * PK_{U_A}

If everything is correctly done, K_U and K_A are the same since:

K_U = PK_A * SK_{U_A} = (SK_A * P) * SK_{U_A} = SK_A * (SK_{U_A} * P) = SK_A * PK_{U_A}

Using the function userEngagement, the asset sends the hash of K_A obtained and if it is the same as the data in hashK_UA, then the state of the token changes to engagedWithUser and the event UserEngaged is sent. Once the asset receives the event, it changes its operation mode to engagedWithUser. This process is shown in Figure 5. From this moment, the asset can be managed by the user and they can communicate in a secure way using the shared key.

Figure 5: Steps in a successful user and asset mutual authentication process

Since the establishment of a shared secret key is very important for a secure communication, NFTs include the attributes hashK_OA, hashK_UA and dataEngagement. The first two attributes define, respectively, the hash of the secret key shared between the asset and its owner and between the asset and its user. Assets, owners and users should check they are using the correct shared secret keys. The attribute dataEngagement defines the public data needed for the agreement.

Rationale

Authentication

This EIP uses smart contracts to verify the mutual authentication process since smart contracts are trustless.

Tie Time

This EIP proposes including the attribute timestamp (to register in Ethereum the last time that the physical asset checked the tie with its token) and the attribute timeout (to register the maximum delay time established for the physical asset to prove again the tie). These attributes avoid that a malicious owner or user could use the asset endlessly.

When the asset calls updateTimestamp, the smart contract must call block.timestamp, which provides current block timestamp as seconds since Unix epoch. For this reason, timeout must be provided in seconds.

EIP-721-based

EIP-721 is the most commonly-used standard for generic NFTs. This EIP extends EIP-721 for backwards compatibility.

Backwards Compatibility

This standard is an extension of EIP-721. It is fully compatible with both of the commonly used optional extensions (IERC721Metadata and IERC721Enumerable) mentioned in the EIP-721 standard.

Test Cases

The test cases presented in the paper shown below are available here.

Reference Implementation

A first version was presented in a paper of the Special Issue Security, Trust and Privacy in New Computing Environments of Sensors journal of MDPI editorial. The paper, entitled Secure Combination of IoT and Blockchain by Physically Binding IoT Devices to Smart Non-Fungible Tokens Using PUFs, was written by the same authors of this EIP.

Security Considerations

In this EIP, a generic system has been proposed for the creation of non-fungible tokens tied to physical assets. A generic point of view based on the improvements of the current EIP-721 NFT is provided, such as the implementation of the user management mechanism, which does not affect the token's ownership. The physical asset should have the ability to generate an Ethereum address from itself in a totally random way so that only the asset is able to know the secret from which the Ethereum address is generated. In this way, identity theft is avoided and the asset can be proven to be completely genuine. In order to ensure this, it is recommended that only the manufacturer of the asset has the ability to create its associated token. In the case of an IoT device, the device firmware will be unable to share and modify the secret. Instead of storing the secrets, it is recommended that assets reconstruct their secrets from non-sensitive information such as the helper data associated with Physical Unclonable Functions (PUFs). Although a secure key exchange protocol based on elliptic curves has been proposed, the token is open to coexist with other types of key exchange.