Skip to content

Commit

Permalink
Update EIP-4519: Make a few wording changes (#5889)
Browse files Browse the repository at this point in the history 
* Update eip-4519.md

* Apply suggestions from code review

Co-authored-by: Javier Arcenegui Almenara <[email protected]>

* Replace all html subs with tex

* Missed a few $

* Fix a few typos

* Apply suggestions from code review

Co-authored-by: Javier Arcenegui Almenara <[email protected]>

* Update EIPS/eip-4519.md

Co-authored-by: Javier Arcenegui Almenara <[email protected]>

* Minor changes

Co-authored-by: Javier Arcenegui Almenara <[email protected]>
  • Loading branch information
@Pandapip1 @Hardblock-IMSE-CNM
Pandapip1 and Hardblock-IMSE-CNM committed Nov 10, 2022
1 parent 218be6b commit abd0795
Showing 1 changed file with 34 additions and 33 deletions.
67 changes: 34 additions & 33 deletions EIPS/eip-4519.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,66 +12,60 @@ requires: 165, 721
---

## Abstract
This EIP proposes a standard interface for non-fungible tokens that represent physical assets, such as Internet of Things (IoT) devices. An [EIP-4519](./eip-4519.md) NFT is tied to a physical asset that can check if the tie is authentic or not. The EIP-4519 NFT can include an Ethereum address of the physical asset and, consequently, the physical asset can sign messages or transactions. The physical asset can operate with an operating mode that is defined by its EIP-4519 NFT with an attribute named state. The token state can define if the token owner or the token user can use the asset or not. A cryptographically secure mutual authentication process can be carried out between the physical asset and its owner or its user. EIP-4519 NFTs extend [EIP-721](./eip-721.md) non-fungible tokens, which only allow representing assets by a unique identifier, but not by an Ethereum address. Moreover, EIP-4519 NFTs extend EIP-721 NFTs to include users in addition to owners.

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 EIP-4519 NFT was developed because the EIP-721 NFT does not include the users of an asset (only include the owners) and does not include the Ethereum address of the asset. Smart assets (for example, IoT devices) are increasing nowadays. If smart assets are tied to EIP-4519 NFTs then they can be managed in a secure and traceable way. The reason is that EIP-4519 NFTs, unlike EIP-721 NFTs, allow establishing secure communication channels between the physical asset and its owner and its user. In this way, assets, owners and users can be assured of exchanging information with trusted parties.

**Secure Physical Asset Tied to an EIP-4519 NFT**
Current non-fungible tokens are associated with passive assets, either virtual or physical things, but they do not include any standardized mechanism to tie the non-fungible token to the asset. Tying physical assets to NFTs is interesting because the asset can know anytime its owner, user, operating mode, and how to establish secure communication channels with its owner and user. The assets, owners and users are identified by their Ethereum addresses and the Ethereum address of the asset can be obtained from a unique physical property of the physical asset (for example, using a physical unclonable function). The asset can be an active part in any transfer of ownership and use. In addition, the asset is smart, for example to not obey orders from a non-authorized user, or to be inoperative if a successful authentication with the user or the owner has not been fulfilled.

**User Management Mechanism**
EIP-4519 NFTs allow implementing a new and useful user management mechanism. In the last few years, many projects concerning assets sharing (for example, vehicles) have been created and developed. EIP-4519 NFTs incorporate the Ethereum address of the user as another attribute of the token in order to distinguish between the user, who employs the asset for a specific application, and the owner, who assigns the token to users. Hence, both users and owners of an asset can be traced.

**Secure Key Exchange Mechanism**
The engagement of the asset with an owner or a user is carried out after a mutual authentication protocol (for example, based on elliptic curve Diffie-Hellman key exchange protocol). This protocol can be employed for a key agreement between the asset and its owner, in the one side, and between the asset and its user, in the other side.
This standard was developed because [EIP-721](./eip-721.md) 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 EIP-4519 NFT 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 EIP-4519 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`.

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)](../assets/eip-4519/images/Figure1.jpg)

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)](../assets/eip-4519/images/Figure2.jpg)

Finally, if both the attributes `addressAsset` and `addressUser` are defined, the states of the EIP-4519 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.
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](../assets/eip-4519/images/Figure3.jpg)

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. EIP-4519 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.
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 EIP-4519 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<sub>O_A</sub> and a Public Key PK<sub>O_A</sub>, so that PK<sub>O_A</sub> = SK<sub>O_A</sub>*P. To generate the shared key between the owner and the asset, K<sub>O</sub>, the public key of the asset, PK<sub>A</sub>, is employed as follows:
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<sub>O</sub>=PK<sub>A</sub>*SK<sub>O_A</sub>
$$K_O = PK_A*SK_{O_{-}A}$$

Using the function `startOwnerEngagement`, PK<sub>O_A</sub> is saved as the attribute `dataEngagement` and the hash of K<sub>O</sub> as the attribute `hashK_OA`. The owner sends request engagement to the asset, and the asset calculates:
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<sub>A</sub> = SK<sub>A</sub>*PK<sub>O_A</sub>
$$K_A = SK_A*PK_{O_{-}A}$$

If everything is correctly done, K<sub>O</sub> and K<sub>A</sub> are the same since:
If everything is correctly done, $K_O$ and $K_A$ are the same since:

K<sub>O</sub>=PK<sub>A</sub>\*SK<sub>O_A</sub>=(SK<sub>A</sub>\*P)\*SK<sub>O_A</sub>= SK<sub>A</sub>\*(SK<sub>O_A</sub>\*P)=SK<sub>A</sub>\*PK<sub>O_A</sub>
$$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<sub>A</sub> obtained 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` is 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.
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](../assets/eip-4519/images/Figure4.jpg)

If the asset consults Ethereum and the state of its EIP-4519 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<sub>U_A</sub>, as the attribute `dataEngagement` and the hash of K<sub>U</sub>=PK<sub>A</sub>*SK<sub>U_A</sub> as the attribute `hashK_UA` in the EIP-4519 NFT.
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<sub>A</sub> = SK<sub>A</sub>*PK<sub>U_A</sub>
$$K_A = SK_A*PK_{U_{-}A}$$

If everything is correctly done, K<sub>U</sub> and K<sub>A</sub> are the same since:
If everything is correctly done, $K_U$ and $K_A$ are the same since:

K<sub>U</sub>=PK<sub>A</sub>\*SK<sub>U_A</sub>=(SK<sub>A</sub>\*P)\*SK<sub>U_A</sub>= SK<sub>A</sub>\*(SK<sub>U_A</sub>\*P)=SK<sub>A</sub>\*PK<sub>U_A</sub>
$$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<sub>A</sub> 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.
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](../assets/eip-4519/images/Figure5.jpg)

Since the establishment of a shared secret key is very important for a secure communication, EIP-4519 NFTs include the attributes
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.

```solidity
Expand Down Expand Up @@ -195,30 +189,37 @@ pragma solidity ^0.8.0;
```

## Rationale
The demand for EIP-4519 NFTs, which allow user management and a tie to a physical asset are growing (for example, in the context of the Internet of Things). Therefore, it is essential to establish a standard capable of including all these options working together or separately. The incorporation of an Ethereum address of the user or an Ethereum address of a physical asset to the EIP-4519 NFT is optional. However, it does not make sense that the EIP-4519 NFT does not include any of them because, in that case, the EIP-4519 NFT would be an EIP-721 token. Since some functions such as `startUserEngagement` are available only if both addresses are implemented, a single interface with all the options is proposed.

**EIP-4519 NFT**
This EIP proposes a non-fungible token tied to a physical asset. The asset is able to generate an Ethereum address and authenticate its user and its owner. Hence, the asset can be considered as a smart asset associated with an NFT. If the asset and the token are regarded as one thing, we can talk about an EIP-4519 NFT.
### Authentication

**Authentication**
This EIP proposes using the smart contract to verify the mutual authentication process between the physical asset and the owner or the user by verifying the hash of a shared key.
This EIP uses smart contracts to verify the mutual authentication process since smart contracts are trustless.

### Tie Time

**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-based

[EIP-721](./eip-721.md) 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](../assets/eip-4519/PoC_SmartNFT/README.md).

## 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](../assets/eip-4519/sensors-21-03119.pdf), 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.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

0 comments on commit abd0795

Please sign in to comment.