Introduction
We express our gratitude to the Rejuve team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Rejuve
- Audited By
- , Viktor Raboshchuk
- Approved By
- Przemyslaw Swiatowiec
- Website
- -
- Changelog
- 16/06/2024 - Preliminary Report, 03/07/2024 - Final Report
- Platform
- Polygon
- Language
- Solidity
- Tags
- ERC721
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope
- Commit
- 9a6d492
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
Technical description is provided.
NatSpec is sufficient.
Code quality
No code quality issues were identified.
Test coverage
Code coverage of the project is 100% (branch coverage):
Deployment and basic user interactions are covered with tests.
System Overview
Rejuve is an ERC721 token (a standard for non-fungible tokens on the Ethereum blockchain) with additional features for identity management.
IdentityToken.sol — Is an ERC721 token, the contract uses several mappings to keep track of identities and their owners, registration statuses, and used nonces. It also emits events when identities are created and destroyed.
DataManagement.sol – This contract is designed to manage data submission and data access permissions.
Privileged roles
For the DataManagement.sol contract:
Owner: The owner is set to the account that deploys the contract (in the constructor of Ownable). The owner has the highest level of privilege. In this contract, the owner has the ability to pause and unpause the contract execution using the pause() and unpause() functions. These functions use the onlyOwner modifier from the Ownable contract, which restricts their use to the owner only.
Registered Users: The contract also has a concept of registered users. The isRegistered modifier checks if a user is registered before allowing them to submit data or get permission. The registration check is done by calling the ifRegistered function of the _identityToken contract (which is of type IIdentityToken). The details of how a user is registered or not is abstracted away in this contract and depends on the implementation of the IIdentityToken contract.
Data Owners: Users who have submitted data are considered data owners. They are identified by their Ethereum address and their identity token ID. They can submit data and grant permissions for their data.
Requesters: Users who request access to the data. They need to be registered and need to provide a valid signature from the data owner to get permission to access the data.
For the IdentityToken.sol contract:
Identity Owner: An identity owner is a user for whom an identity token has been created. They are identified by their Ethereum address. An identity owner can burn their identity token using the burnIdentity function. The function uses the require statement to ensure that only the owner of an identity token can burn it.
Contract Owner: The contract owner is the account that deploys the contract. This role is inherited from the Ownable contract from OpenZeppelin. The contract owner has the ability to pause and unpause the contract execution using the pause() and unpause() functions. These functions use the onlyOwner modifier from the Ownable contract, which restricts their use to the owner only.
Risks
The audit covered two contracts, DataManagement.sol, and IdentityToken.sol. While it was noted that these audited contracts do not interact with others in the codebase, there remains a potential risk from off-chain interactions, which were out of the audit's scope. These interactions were not validated in this audit.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
F-2024-3805 | Unauthorized identity creation | Fixed | Critical | |
F-2024-3900 | Using abi.encodePacked() with dynamic types for keccak256 hashing | Fixed | Low | |
F-2024-3824 | Unregistered signer vulnerability | Fixed | Low | |
F-2024-3820 | Zero address identity creation | Fixed | Observation | |
F-2024-3802 | Unindexed event parameters | Fixed | Observation | |
F-2024-3801 | Floating pragma | Fixed | Observation |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details
- Commit
- 9a6d492
- Whitepaper
- -
- Technical Requirements
- https://github.com/Rejuve/rejuve-platform-contracts/blob/main/README.md→
Contracts in Scope
contracts/DataManagement.solcontracts/IdentityToken.sol