WO2023195920A1

WO2023195920A1 - Smart contract evaluation

Info

Publication number: WO2023195920A1
Application number: PCT/SG2023/050217
Authority: WO
Inventors: Yi Li; Ye Liu
Original assignee: Nanyang Technological University
Priority date: 2022-04-06
Filing date: 2023-03-31
Publication date: 2023-10-12

Abstract

Systems and methods for identifying a permission bug in a contract by performing role- mining to recover role structures of the contract based on a user permission assignment (UPA) obtained from transaction history. The UPA contains a set of observed permissions assigned to each user. Further, creating an access control policy specification based on the recovered role structures of the contract and identifying the permission bug by conformance testing based on the access control policy specification.

Description

Smart Contract Evaluation

Technical Field

[0001] This disclosure generally relates to methods and systems for the evaluation or testing of smart contracts deployed or deployable on a Blockchain network.

Background

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Contents of this background section are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] A Blockchain is a public database that is updated and shared across many computers in a network. "Block" refers to data and state being stored in consecutive groups known as "blocks". "Chain" refers to the fact that each block cryptographically references its parent. Blockchains are structured so that the data in a block cannot change without changing all subsequent blocks, which would require the consensus of the entire network. Every computer in the network must agree upon each new block and the chain as a whole. These computers are known as "nodes". Nodes ensure everyone interacting with the Blockchain has the same data using a consensus mechanism.

[0004] A smart contract is a program that runs on a Blockchain. It is a collection of code (its functions) and data (its state) that resides at a specific address on the Blockchain. Smart contracts form part of decentralized applications that may facilitate transactions in the real world which may involve valuable resources of significant value. Smart contracts and decentralized applications provide a trustless execution environment in which smart contracts can be analyzed and are guaranteed to execute in predictable ways, without the need to trust a central authority. For brevity, smart contracts may also be referred to as contracts in this disclosure.

[0005] Ethereum and EOS are among the most popular Blockchain platforms which support smart contracts and have them applied in many areas, such as finance, supply chain, identity management, games, etc. As of January 20, 2022, there are over 48 million smart contracts deployed on Ethereum, which is a 2.3-fold increase from just two years ago. These smart contracts have enabled 3,886 decentralized applications (DApps) serving about 180.13k daily active users. [0006] Smart contracts are susceptible to security issues that stem from high-level security policy design and enforcement. Such security issues are quite subtle in the way they are introduced into the smart contracts and are often difficult for programmers or bug discovery programs to automatically identify. In particular, as the number of roles and the complexity of the access control patterns governed by a smart contract increases, it becomes increasingly difficult for developers or bug discovery programs to identify security issues efficiently.

Summary

[0007] Some embodiments relate to a method of identifying a permission bug in a contract, comprising: performing role-mining to recover role structures of the contract based on a user permission assignment (UPA) obtained from transaction history, wherein the UPA contains a set of observed permissions assigned to each user; creating an access control policy specification based on the recovered role structures of the contract; and identifying the permission bug by conformance testing based on the access control policy specification.

[0008] In some embodiments, when the contract is undeployed, the transaction history are configured to be generated through user acceptance testing.

[0009] In some embodiments, performing role-mining to recover the role structures of the contract comprises: computing an average frequency vector AFV(r) of a plurality of candidate roles r, AVF(r) representing how frequently users associated with the respective candidate role r exercise different permissions,

wherein n(r, pi) denotes the total number of times the permission p_t e P gets exercised by the candidate role r's users. [0010] In some embodiments, performing role-mining to recover the role structures of the contract comprises minimizing the maximum of the cosine similarities between any pair of the AFVs of the plurality of candidate roles r, wherein the maximum of the cosine similarities between any pair of the AFVs (SimErr) is computed according t

[0011] In some embodiments, performing role-mining to recover the role structures of the contract comprises minimizing the number of mismatches between mined role structures (UA, PA) and the UPA so as to minimize role-consistency error, wherein the role-consistency error (DeltaErr) is according to

where Il-Il! denotes the L¹ norm, ® refers to Boolean matrix multiplication, UA refers to a matrix of user to candidate role assignment, PA refers to a matrix of candidate role to permission assignment and UPA refers to a matrix of observed permissions assigned to users.

[0012] In some embodiments, performing role-mining to recover the role structures of the contract comprises minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA, PA) at least include the permissions in the UPA by solving an optimization problem according to

where a and p are relative weights.

[0013] In some embodiments, minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA, PA) at least include the permissions in the UPA comprises: grouping a set of users that share the largest set of permissions together so as to form a set of candidate roles

encoding a solution to the optimization problem as a chromosome Chr[x] in the form of

here x_t is the gene of rp and guiding a search to find a solution following a fitness function

[0014] In some embodiments, conformance testing comprises: initializing a plurality of test sequences; and performing conformance testing for each test sequence.

[0015] In some embodiments, conformance testing for each test sequence comprises: constructing symbolic paths for each of the plurality of test sequences; and checking each respective symbolic path for conformity with the recovered role structures.

[0016] In some embodiments, constructing symbolic paths for the test sequences comprises concatenating function-level symbolic paths generated from symbolic execution.

[0017] In some embodiments, when the symbolic paths are unable to be satisfied, the conformance testing is skipped for the respective test sequence.

[0018] The method of some embodiments further comprise generating an attack test sequence corresponding to the permission bug based on results of conformance testing.

[0019] Some embodiments relate to a system of identifying a permission bug in a contract, comprising a plurality of processors configured for: performing role-mining to recover role structures of the contract based on a user permission assignment (UPA) obtained from transaction history, wherein the UPA contains a set of observed permissions assigned to each user; creating an access control policy specification based on the recovered role structures of the contract; and identifying the permission bug by conformance testing based on the access control policy specification.

Brief Description of the Drawings

[0020] Some embodiments of systems and methods for the evaluation or testing of smart contracts, in accordance with the present disclosure, will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which: [0021] Figure 1 illustrates a schematic diagram of a method of identifying a permission bug in a contract;

[0022] Figure 2 illustrates a security lattice based on the roles in ProfitSharingRewardPool contract;

[0023] Figure 3 illustrates a flowchart of a method of identifying a permission bug in a contract; and

[0024] Figure 4 illustrates a system for identifying a permission bug in a contract.

Detailed Description

[0025] Smart contracts are deployed on permissionless Blockchains such as Ethereum. Such smart contracts are accessible to any user with access to the trustless environment. Most smart contract applications implement access control policies to protect their valuable assets from unauthorized access or to limit actions performed by one or more groups of users. The systems and methods of the embodiments mine past transactions associated with a smart contract to determine the role structures of the contract. The systems and methods for smart contract evaluation are also referred to as SPCon. SPCon effectively mines more accurate user roles compared to state-of-the-art role-mining tools. Experimental evaluation on real-world smart contract benchmark and access control CVEs (Common Vulnerabilities and Exposures) indicated that SPCon advantageously detects potential permission bugs while providing better scalability and a lower false-positive rate compared to state-of-the-art security tools. Permission bugs comprise bugs wherein users with access to a smart contract can perform operations that they are not intended to be able to perform according to the intent of the logic of the smart contract. Permission bugs may comprise bugs wherein a user accesses a resource such as a value stored on a Blockchain that they are not authorized to access. Alternatively, permission bugs may comprise bugs wherein a user is able to perform a transaction that they are not authorized to perform according to an intended logic of a smart contract.

[0026] SPCon performs role-mining operations based on data of past transactions associated with a target smart contract (100 of Fig. 1 ). Because of the transparency and immutability of Blockchain transactions, the transaction history of a smart contract application from its initial deployment is always available. These historical transactions (1 10 of Fig. 1 ) contain benign user interactions that provide the basis for role-mining. [0027] As illustrated in Fig. 1 , SPCon methods first perform role-mining 120 on the transaction history to reverse engineer role structures 130. The role structures 130 comprise a specification or description of the different user groups, the permissions entitled to each group, and potential hierarchies among them as stipulated by the program code of the target smart contract 100. Then, access-control policy specification 140 is constructed based on the role structures and relevant information flow policies. The information flow policies may include policies of integrity or separation of duty etc. Through conformance testing 160, SPCon validates the actual contract implementation against the policy specifications. Historical transactions may under-approximate the behaviours allowed by the contract implementation, any discrepancy discovered during conformance testing indicates potential policy violations (permission bugs 170) that may occur in the future.

[0028] Figure 3 illustrates a flowchart of the method of identifying a permission bug in a contract executable by system 400 of Figure 4. The system 400 comprises one or more processors 410 and a memory 420 accessible to the processors. Memory 420 comprises program code embodying the instructions to implement the method of Figure 3. System 400 of access transaction history records 430 from a Blockchain network 440. Alternatively, system 400 may access simulated transaction history records 432 from a smart contract testing environment 450. The transaction history records comprise details of transactions that may include one or more identifiers of users associated with transactions, changes in values of variables associated with the transaction etc. As illustrated in Fig. 4, SPCon may be used in two scenarios. First, it can be used for detecting bugs in smart contracts deployed on a Blockchain based on an existing transaction history. Second, it can be used as an automated bug detector during the development phase of a smart contract. In the second scenario, transaction data generated during testing may be used to perform vulnerability detection.

[0029] SPCon advantageously obtains a high-quality role structure that allows the detection of more subtle and complex to detect permission bugs or vulnerabilities. SPCon generates the role structures by characterizing this task as an optimization problem in which two quality metrics are optimized. The metrics are role similarity error and role consistency error. SPCon implements a genetic algorithm (GA) to find a solution to the role-mining problem. [0030] To improve the performance of the GA, the optimization model may be subjected to additional constraints which may include: (1 ) the mined role model must subsume all observed user permissions from the historical transactions, and (2) users that share similar permission patterns can be represented by the same role. The experimental results on labelled smart contract role-mining benchmark demonstrated that SPCon is able to mine role structures from contracts’ historical transactions with better accuracy than existing state-of-the-art role-mining approaches. Moreover, the experimental evaluation on real-world smart contract benchmarks, namely, SB^wild and access control CVEs, indicates that SPCon effectively detects potential permission bugs while having better scalability and a lower false-positive rate compared to state- of-the-art security tools. The policy specifications 140 produced by SPCon can be used to enhance existing testing tools. SPCon’s bug detection capability was evaluated on real- world smart contract benchmark SB^wild. The results demonstrated that SPCon achieved the highest accuracy of permission bug detection and finds 1 1 previously unknown permission bugs in SB wild. Moreover, SPCon detected six more previously confirmed CVEs that cannot be found by existing tools.

Permission Bug Example

[0031] On May 7, 2021 , a smart contract ProfitSharingRewardPool, used by a Decentralized Finance (DeFi) platform named ValueDeFi, was hacked due to missing a line of code and lost around six million dollars. ProfitSharingRewardPool was written in Solidity with the simplified source code reproduced below.

[0032] ValueDefi used this pool contract for profit sharing with its users. The contract defines several modifiers to restrict user access, including “onlyOperator” (Line 9) and “notlntialized” (Line 12). Unlike most other contracts, ProfitSharingRewardPool required an explicit initialization after the contract deployment because it did not provide a specialized constructor. Before the initialization, the “initialized” flag remains false, while other fields remain uninitialized (Lines 3 to 7).

[0033] To properly initialize the contract, the contract owner should invoke the “initialize” function (Lines 14 to 24), which comes with the “notlnitialized” modifier to restrict other users’ access after the initialization is performed (Line 12). Apart from configuring the staked and liquidity tokens (Lines 18 to 19), the contract owner may configure administrator roles — “reserveFund” and “operator” — during the initialization stage. Yet, since the statement “initialized = true” (Line 23) was missing, a malicious user could successfully reinitialize the contract. The attacker can modify the token configurations and perform privilege escalation by setting himself as the “operator”. [0034] Conventional smart contract security analysis tools rely on generic bug patterns; thus, they may face challenges in detecting this permission bug without an accurate contract specification. More specifically, pattern-based approaches may fail because, (1 ) the “initialize” function is already protected by a modifier, therefore a tool searching for the “unrestricted write” pattern would not raise an alarm, and (2) one has to realize that the condition “initialized == false” always holds regardless of user inputs, in order to invalidate the protecting modifier. Yet, this kind of reasoning is beyond the scope of existing bug patterns. Bug patterns targeting common low-level coding errors may miss design flaws and fail to reveal many permission bugs. To address these challenges, SPCon first derives access control policy specifications through role-mining. The access control policy specifications are used to perform conformance testing to detect designlevel permission bugs. The reference to the ValueDeFi permission bug is merely illustrative and is not intended in any way to limit the nature of permission bugs identifiable by the embodiments.

[0035] The overall workflow of SPCon consists of two overarching steps: role-mining and conformance testing as illustrated in Fig. 1 and Fig. 3. First, during role-mining (120 of Fig. 1 and 320 of Fig. 3), SPCon recovers role structures of the contract based on the observed user permission assignments (UPA) from the transaction history. Benign transaction history records are readily available for a deployed contract. For undeployed contracts, transactions are generated through user acceptance testing operations. Second, SPCon performs conformance testing (160 of Fig. 1 and 340 of Fig 3) to validate contract implementation against the access control policy specification defined based on the mined role structures.

Role-Based Access Control (RBAC)

[0036] A role is properly viewed as a semantic construct around which access control policy is formulated. RBAC is policy neutral and can be used to implement various types of security policies. This owes to the flexible granularity of the permission concept, which could either be a coarse-grained job function or a fine-grained data read/write. In the smart contract context, permissions can be enforced at both the function and statement level. Table 1 reproduced below illustrates the access control model of a ProfitSharingReward-Pool smart contract. There are four roles, namely, “Operator”, “ExchangeProxy”, “ReservFund”, and “Normal Users”. Each role is granted a set of permissions for example, “Normal Users” can only call permissionless functions such as “deposit” and “withdraw”, while “Operator” can initialize the contract, set users for other roles, etc.

Table 1 : Role structures of ProfitSharingRewardPool

Information Flow Policy

[0037] Information flow policies are concerned with the flow of information from one object to another. In smart contracts, the objects of interest are contract state variables recording critical information such as the balance values, role assignments, and asset prices. An important class of information flow policies can be defined on top of a security lattice. As RBAC is policy neutral, it can be used to articulate a wide range of information flow policies. We may recover a security lattice from the role structures, such that the security labels correspond to roles (R) and the dominance relation is defined over the write sets of roles: i. e., n > g if and only if write(n) 2 write(rj) , where write(n) denotes the set of variables that n can write. For example, Fig. 2 illustrates a security lattice based on the roles in ProfitSharingRewardPool, where “Operator” and “Normal Users” are the top and bottom roles, respectively. If an integrity policy is to be enforced among them, i. e., lower roles should not be able to write data owned by higher roles, then normal users should not write to “stakeToken”, etc. Yet, due to the buggy “intialize” function, normal users are able to re-initialize the contract, thus violating the integrity policy.

Role-mining

[0038] The purpose of role-mining as performed at steps 120, 320 is to utilize the observed or simulated user access information captured by the user permission assignment matrix (UPA), to infer the decomposed user roles (UA - user to role assignment, PA - role to permission assignment), such that the decomposition exactly describes the UPA and the number of roles are minimized. In other words, role-mining is intended to discover or infer the roles defined by the smart contract based on historical transactions or simulated transactions generated by testing operations.

[0039] Let a_tj denote the entry (i,j) of UPA. Then a_tj = 1 indicates that the user i has the j permission. Typically, users sharing the same set of permissions should be classified into the same role. A more generalized version of the role-mining problem (RMP) allows noises in the decomposition.

[0040] Given a set of users U, a set of permissions P, and a user-permission assignment matrix UPA, the problem of 5-RMP is to find a set of roles R, a user-to-role assignment matrix UA, and a role to permission assignment matrix PA such that the number of roles |R| minimized and the following inequality is satisfied:

refers to Boolean matrix multiplication.

[0041] A solution to 5-RMP allows a limited number of mismatches below the given threshold 8. Conventional role-mining approaches assume a fully-observed user permission assignment and find solutions satisfying 5 = 0. In contrast, SPCon's rolemining approach aims to reverse engineer high-quality roles based on the limited partial observations from historical transactions. SPCon allows a non-zero 5, at the same time, optimizes various quality metrics to obtain high-quality roles.

Partial-Observation Role-mining (PORM)

[0042] Conventional role-mining techniques assume a fully-observed user permission assignment (UPA), i. e., UPA contains all permissions assigned to each user. This assumption does not work well in smart contract settings. In particular, a user is unlikely to access all functions within her permission, especially for permissionless functions as implemented in a smart contract, and different users of the same role (e. g., normal users) may access different subsets of their permissions. Treating the transaction history of smart contracts as a fully-observed permission assignment will likely result in more roles than necessary and incorrect role assignments.

[0043] SPCon advantageously performs partial-observation-based role-mining (PORM). In PORM the permission assignment is assumed to contain only partial information. To derive high-quality estimates of the role structures, SPCon relies on an optimal balance between the two quality metrics, namely, the role-similarity error and the role-consistency error, to guide the role-mining process.

[0044] SPCon computer Average Frequency Vector (AFV) of a role that serves as a measure of how frequently its users exercise different permissions, which serves as a signature of the role and should vary across different roles. The desired roles should distinguish users of different access patterns, therefore, resulting in low AFV similarities between different roles.

[0045] Definition of AFV: Let r e R be a role, |r| be the number of users assigned role r, and P be the permission set. The permission set is effectively the set of all the potential permissions associated with a specific smart contract. Let n(r, pi) denote the total number of times permission p_t e P gets exercised by the users of role r in a transaction history dataset. The AVF of r, denoted by AVF(r), is a |P| dimensional vector AFV is effectively a measure of how frequently each of

the permissions in the permission set is exercised by users of role r.

[0046] Role similarity error (SimErr) may be defined as a maximum of the cosine similarities between any pairs of roles' AVFs, calculated as:

[0047] The SimErr metric is intended to capture the similarity between roles or candidate roles as they are initialized/instantiated at the beginning of role-mining. If two candidate roles are significantly similar, then it will be beneficial to merge the two roles during the role-mining operation.

[0048] In addition to minimizing SimErr, SPCon aims to minimize the number of mismatches between the mined role structures (UA, PA) and the given user permission assignment UPA, namely the 8 value of 5-RMP. Role consistency error is defined as:

where UPA is the user permission assignment matrix and (UA, PA) are the mined role structures, | |. | |_t denotes L¹ norm an

efers to Boolean matrix multiplication.

PORM as an Optimization Problem [0049] The computation of RMP and 5-RMP are both NP-Complete problems. The complexity of the PORM is at least as hard as that of the 5-RMP. The approach of SPCon advantageously improves the generalizability of roles with SimErr, while maintaining good consistency with DeltaErr. PORM is posed as a multi-objective optimization problem to produce likely role structures achieving a good trade-off between the two error metrics.

[0050] Given a set of users U of size m, a set of permissions P of size n, and a userpermission assignment matrix UPA of size m x n, PORM comprises inferring the unknown RBAC configuration (UA, PA), where R is a set of roles of size k, UA is a user-role assignment matrix of size m x k, and PA is a permission-role assignment matrix of size k x n, which satisfies, i Si E /3 D l E (3)

where a and are relative weights on the two error metrics. Equation (3) constraints that the mined roles UA ® PA should at least include the permissions appearing the partial observations UPA.

A Solution Based on a Genetic Algorithm

[0051] SPCon incorporates a genetic algorithm (GA) to find an optimum solution to the PORM. The GA takes UPA as an input, which can be obtained from the smart contract transaction history at step 310 of Fig. 3. Since a valid solution needs to satisfy Eq. (3), SPCon first groups the largest possible number of users sharing the largest set of permissions together as basic roles (candidate roles). This helps reduce the search space significantly. The basic roles are guaranteed have 5 = 0 and thus satisfy Eq. (3). Subsequently in the GA, basic roles are randomly merged to form larger roles (composite roles), which increases 5, and therefore Eq. (3) is not violated as the GA is executed.

[0052] Chromosome: Given a set of basic roles mbodiments encode the solution as a chromosome Chr[x] in the

following form where x_t serves as a gene representative of r_t. Each gene consists of log₂k

bits, so there are at most k different gene values. Each gene value represents a specific cluster of basic roles. For example, if after a few rounds of evolution, in a particular chromosome xt = Xj the two basic roles , and r₇- are merged to generate a merged role. [0053] Fitness function: SPCon uses the following fitness function to guide the search: fitness(x) = (a. SlmErr + /3. DeltaErr)^-1 (4) where SimErr and DeltaErr are defined in Eqs. (1 ) and (2), respectively.

[0054] Selector, Crossover and Mutator: During the execution of the GA, selection, crossover and mutation operations are performed to evolve the population of chromosomes towards the optimal role structures. Selection is performed according to a tournament selection method wherein a subset of winner chromosomes identified based on the fitness function is selected for subsequent crossover operations. In some embodiments, a single-point crossover is performed to exchange the encoded role structures of two chromosomes (parents) to generate offspring in a manner where the front and back of the crossover point for the two chromosomes is exchanged. Mutation in some embodiments comprises performing a gene-level mutation, which flips a bit of a gene or swaps two genes in a chromosome. The initial population of the GA may be randomly generated. In some embodiments, the GA is executed in a manner to retain one best individual from a current generation to carry over to the next generation as a form of elitist selection to guarantee that the solution quality obtained by the GA does not decrease. At the conclusion the evolution, a final fittest chromosome is obtained. The fittest chromosome embodies the role structures that are the most optimal roles obtained at the conclusion of the execution of the GA. The role structure encoded in the fittest chromosome (mined role structure) serves as the basis for subsequent validation and conformance testing. The mined role structure may be represented as a combination of UA and PA matrices. UA refers to a matrix of user to role assignment and PA refers to a matrix of role to permission assignment.

Policy Validation via Conformance Testing

[0055] With the mined role structures, SPCon is able to derive a set of access control policy specifications (steps 140, 330) and perform conformance testing (steps 160, 340) on the contract implementation. Since the mined role structures are based on benign user behaviors, any discrepancy between the policy specification and the actual allowed behaviors indicates a potential permission bug. The combination of role-mining and testing solves the problem of missing roles specifications for smart contracts and provides a rich set of test oracles specialized for permission violation bugs. Algorithm 1 is an exemplary algorithm for conformance testing reproduced below:

[0056] The inputs to Alg. 1 include the contract functions (F), state variables (V), a snapshot of the initial concrete contract state (So), the mined role structures (UA, PA), and a user-defined bound for the test sequence length (k). The output is either a test sequence that exploits a permission bug, where access control policies are bypassed, or an empty sequence indicating no bug is found within the given bound.

[0057] The conformance testing procedure iterates through each test sequence, consisting of k functions from F (Line 2). In each iteration, the algorithm initializes the contract state S using So and sets the initial symbolic path condition fl to true (Line 3). The algorithm progressively constructs symbolic paths with increasing lengths, and checks against the information flow policy defined over the mined role structure (Lines 4 to 9). On Line 5, the algorithm constructs a global path fl by concatenating function-level symbolic paths generated from symbolic execution (i. e., SymbExe in Alg. 1 ). The algorithm also substitutes the state variables (v e V) with their updated values captured in S, which is either concrete values inherited from So or symbolic expressions as a result of previous function (symbolic) executions. If fl is not satisfiable, the algorithm skips the current test and start a new test sequence. Otherwise, the algorithm checks fl against the given information security policy A defined on the security lattice (Line 7).

[0058] The security lattice L is constructed according to the mined roles R and the partial order over the set of state variables written by each role. Each role is associated with a set of permissions (functions) given by PA. Accordingly, the algorithm maps roles to their write sets via data-dependency analysis on the corresponding functions (Line 15). Note that, the write set of a function contains the written state variables excluding the ones read. A permission bug is reported if the information flow policy is violated on the path fl (Line 17). The algorithm also returns the shortest test sequence leading to the bug (Line 8). Otherwise, S is updated, to take into account the state changes introduced by the function fi (Line 9). The conformance testing process continues, till all the test sequences have been tested or a permission bug is found.

[0059] Examples of the security policies evaluated by SPCon include integrity and separation of duty. Integrity policies comprises rules to prevent critical information flowing from a low-security role to a high-security role, while separation of duty ensures that the privileged information owned by a role cannot be modified by other incompatible roles.

Table 2: Illustration of the discovery of the ProfitSharingRewardPool attack by SPCon

[0060] Table 2 above illustrates the process how SPCon detects the “initialize” attack to ProfitSharingRewardPool, which violates the integrity of the security lattice (see motivating example above). Following conventional practice, attackers may be assumed from the lowest-security role, namely “Normal User”. In Table 2, there are four test sequences where each consists of two functions. The deployed contract is assumed to have been initialized once by the owner. Therefore, the initial state records the current concrete values of the state variables, such as “stakeToken” and “token Balance”. The first and the second test sequences, namely, tsi and tS2, are infeasible, and there is no change made to S. This is because the attacker’s address will be rejected by the permission checks for “exchangeProxy” and “reserveFund”, respectively. The sequence tss is feasible, and the attacker’s token balance in S is updated to X and X-Y after “deposit” and “withdraw”, respectively. Yet, this does not result in any policy violation yet. In tS4, the buggy “initialize” function is executed first, where the value of “stakeToken” modified in S, thus breaking the integrity policy. Therefore, SPCon reports the shortest attack test sequence — “(initialize)” — as an indication of the permission bug (step 350 of Fig. 3). The shortest attack test sequence may serve as a basis debugging of the smart contract for developers.

[0061] SPCon may set up a testing environment with a mirrored contract deployment from a peer node using the developer APIs provided by Etherscan, for example. In the testing environment, SPCon can fetch the most up-to-date contract states (So in Alg. 1) faithfully. The function-level symbolic execution may be implemented using Manticore, a symbolic execution tool for analysis of binaries and smart contracts. During symbolic execution, SPCon substitutes symbolic state variables with their concrete values captured in So. This avoids false positives from spurious contract configurations. As the number of possible test sequences grows exponentially with length k, some embodiments may perform partial order reduction on the test sequences according to their control flow dependencies, which further reduces unnecessary test cases.

Evaluation

[0062] To explore the capability of SPCon, we evaluated it based on the following questions, comparing its performance to the state of the art tools for smart contract evaluation:

Q1 : How accurately and efficiently does SPCon learn the likely RBAC model? This question was evaluated using smart contracts with ground truth RBAC models that served as a benchmark for evaluating the accuracy and efficiency of SPCon.

Q2: How does SPCon perform in detecting permission bugs? This question was evaluated using the benchmarks SC^wild and access control CVE.

Q3: Why do existing tools fail to detect many permission bugs, and how does the SPCon approach improve on this?

Experimental Setup [0063] To evaluate SPCon with respect to Q1 , a role-mining benchmark for smart contracts with ground truth RBAC information was prepared. In some embodiments, smart contracts which use the AccessControl template of OpenZeppelin were used because these contracts have to explicitly define their roles following the template. In some experiments 4,719 smart contracts on Ethereum that use the AccessControl template in their source code formed part of the dataset for evaluating Q1 . Contracts used in the experiments incorporated “onlyRole” and “hasRole” modifiers to label each privileged function with the corresponding roles. The ground truth RBAC was largely derived based on these labels.

[0064] For Q2, experiments were performed to evaluate the accuracy of SPCon on real-world smart contract benchmark SBwild with a public data set consisting of 47,518 contracts from the Ethereum blockchain. Specifically, SBwild includes 3,801 contracts marked as having access control bugs. For comparison, the access control bugs were also detected by symbolic execution-based analysis tools such as Maian, Manticore and Oyente and program analysis tools including Security (dataflow properties), Slither (taint tracking) and SmartCheck (AST-level rules), as well as a hybrid analysis tool, Mythril. Moreover, as of December 23, 2021 , there are 531 smart contract CVEs, 19 of which contain access-control-related CVEs. Experiments used these 19 CVEs to evaluate the capability of SPCon.

Results of Experiments

[0065] Results for Q1 : To answer Q1 , we evaluated three combinations of a and, /3 namely, (0.4, 0.5), (0.5, 0.5) and (0.6, 0.4), for the fitness function — see Eq. (4) — used by SPCon. The different combinations were intended to experiment with different weight of SimErr and DeltaErr in PORM. As for the GA parameters, the population size is set to be 100, and the number of generations is 200. The mutation rate of the GA population is set to be 0.10 to avoid being stuck in a local optimum, and the crossover rate is 0.99. The role-mining time budget is 20 minutes per contract for all the role-mining tools. The hyper parameters of the GA algorithm may be varied to suit different datasets to attain optimal results.

[0066] The experiments compared SPCon with existing role-mining tools HPr, ORCA, HM, and GO on the 50 sampled smart contracts of the role-mining benchmark. Experiments compared the mined roles and the ground truth roles using two metrics: Num Ratio and Sim(mined_roles, groundtruth roles). Num Ratio is the ratio of the number of the mined roles to the number of roles in the ground truth. Sim(mined_roles, groundtruth roles) measures the similarity between the roles of the mined result and the roles of the ground truth at a user-given threshold t (c. f. Def. 4). Table 3 shows the evaluation on the role-mining results. The first column is the role-mining approach; we use the three afore- mentioned settings for SPCon. The next three columns show the average time cost, average number of roles, and average Num Ratio per contract. The first four columns of the rest show the average similarity between the mined roles with respect to the ground truth at different given thresholds. Since privileged roles are critical to a security policy, the last four columns also present the similarity be- tween mined privileged roles and the privileged roles of the ground truth, removing all the permissionless functions.

Table 3: Evaluation result on the 50 sampled smart contracts of the role-mining benchmark

[0067] GO takes the longest time, around three minutes on average, while HPr is the fastest algorithm. ORCA generates the most roles (about 22 on average) and thus has the highest ratio of mined roles per actual role (7.17 on average). The reason is that ORCA uses a simple clustering analysis without any minimization goals. HM and GO also generate many more roles than the ground truth, with the ratio being 6.37 and 4.86, respectively. Although HPr has the best role similarity among the four existing tools, SPCon (0.4, 0.6) outperforms HPr in all metrics except for the runtime. This implies that SPCon (0.4, 0.6) mined more accurate roles than HPr, as SPCon (0.4, 0.6) also mined fewer unnecessary roles. SPCon (0.5, 0.5) generates fewer roles than SPCon (0.4, 0.6) with a similarity loss to some extent. We argue that SPCon (0.5, 0.5) is still better than HPr in the sense that SPCon (0.5, 0.5) reports much fewer roles than HPr, and the similarity of SPCon (0.5, 0.5) is comparable to that of HPr. SPCon (0.6, 0.4) has the lowest similarity for privileged roles, which downgrades the role-mining accuracy. The reason is that, with higher weightage a, SPCon (0.6, 0.4) could attempt to cluster different privileged roles to achieve a higher fitness score. In summary, SPCon significantly reduces the number of mined roles compared to other role-mining approaches. SPCon outperforms the existing role-mining approaches with respect to accuracy when we choose suitable

combinations, such as (0.4, 0.6) or (0.5, 0.5). Moreover, SPCon runs efficiently, taking only half a minute on average for the examples. Due to the random nature of the GA, 10 role-mining experiments were performed using SPCon (0.4, 0.6), and the mean and variance of the number of roles, ratio of the mined roles to the groundtruth roles, and similarity (t=1 ) are (6.776, 0.05), (2.193, 0.004), (0.553, 0.00008), which implies that the results are robust.

[0068] Answer to Q1 : SPCon can accurately and efficiently reverse engineer likely RBAC models of smart contracts.

[0069] Results for Q2. To answer Q2, experiments evaluated SPCon on the contracts of SB^wild with at least 50 transactions for the observation of a diversity of user behavior to mine high-quality roles for conformance testing. For SPCon, the length of test sequence k is 2 which is same as the default setting of Manticore and Mythril and the test time budget for permission bug detection is set to 10 minutes per contract.

Table 4: Permission bug detection result on SB^wild

[0070] Table 4 above illustrates the evaluation result on permission bug detection of SBwild of six pattern-based tools and SPCon. To avoid bias, the experiments reused the original detection result of Slither, Security, SmartCheck, Mythril, Maian and Manticore. The columns in Table 4 show the different tool names, the number of reported permission bugs. The number of reported permission bugs agreed on by at least one other existing tool with the corresponding percentage, and the true-positive rate.

[0071] SPCon reported 44 permission bugs among SB^wild while Slither reported the most, namely 2,356 contracts. The agreement result shows that SPCon achieves the best precision. 75% of the results of SPCon are agreed upon by at least one other tool. In the experiments, SPCon achieved the best in the result accuracy, namely, 81 .8 % of the detected permission bugs are true positives. Moreover, SPCon found 1 1 previously unknown permission bugs in SB^wild.

[0072] For a detailed comparison, experiments were perfumed to evaluate SPCon and other tools on the detection of permission CVEs. Table 5 shows the detection results of Slither, Oyente, Maian, SmartCheck, Manti- core, Mythril, Security, Ethainter, and SPCon. SPCon does not apply (“N/A”) to CVE-2018-19830, CVE-2018-19833, and CVE- 2018-19833 since they have only one, four and three transactions, respectively. Ethainter is a newly proposed security analyzer for information flow vulnerabilities caused by access control bugs.

Table 5: Evaluation results on the 17 permission CVEs

[0073] Table 5 illustrates that neither Oyente, Manticore, Security, nor Ethainer could detect any permission CVEs. Slither and SmartCheck detected one permission CVE, which is due to the misuse of tx. origin, while Mythril and Maian found two and four, respectively. SPCon detected nine permission CVEs, which is more than all of the other tools combined and includes six CVEs that existing tools cannot find. This indicates that SPCon has an advantage over pattern-based approaches and can complement these to achieve better results.

[0074] Answer to Q2: SPCon exceeded state-of-the-art vulnerability detection capabilities, showing higher accuracy on finding existing access-control bugs. It found 1 1 unknown permission bugs and six access-control CVEs that no other tool finds. [0075] Results for Q3. To understand the causes of previously unknown permission bugs, experiments were performed on a permission bug that was found only by SPCon. A simplified code of the EDU token contract is reproduced below:

[0076] It has two sensitive variables, “ownerAddress” and “certifier” (Lines 2 to 3). The user having the address of “ownerAddress” is in charge of the contract; “certifier” is a contract instance which should implement the interface “Certifier”. The “certifier” instance is used to certify incoming participants via the fallback function (Lines 11 to 17). However, unauthorized users can reset “certifier” by calling the updateCertifier function (Lines 8 to 10).

[0077] Existing vulnerability patterns used to detect permission bugs cannot capture this scenario, because they all capture behaviors that do not apply here. Some patterns used by Maian, Manticore, Mythril, Slither and Security look for Ether withdrawal, which does not occur in EDU. Similarly, Manticore, Mythril, and Slither also check if unauthorized users can taint delegatecall, but this instruction is not used in the contract. Another pattern, used by Maian, Manticore, Mythril and Slither, checks if unauthorized users can destroy a smart contract. However, EDU contains no selfdestruct instruction. Finally, a pattern to check the misuse of tx. origin used by Manticore, Mythril and SmartCheck, is not applicable in EDU either as it does not use tx. origin in its code. Security also failed to flag this vulnerability. In function updateCertifier, certifier=Certifier(_address) (Line 9) is a type conversion statement to covert “_address” from an ordinary address type to “certifier” of the “Certifier” interface type. As the implementation of this interface is not available at compile time, Security cannot analyze it. SPCon addresses this problem by using a role-based information security lattice as the expected behavior of smart contract. SPCon found that only high-security level roles can write to the “certifier” variable from the partial observation transaction history of EDU. With its conformance testing, SPCon confirmed that unauthorized users can write to “certifier”, which constitutes the permission bug.

[0078] SPCon flags exploitable permission bugs. The bugs are exploitable in the sense that users can replay the attack on the on-chain smart contracts. Most of the existing pattern-based tools aim to detect a bug but without any guarantee if the bug can be exploited or not. However, vulnerable code does not imply that the contract is exploitable. Simplified code of VoipToken.2 is reproduced below:

[0079] In the experiments, this permission bug was reported by Maian but not by

SPCon. The constructor function name of the VoipToken contract has a typo, and it should be “VoipToken()” instead of “VoipTken()” (Lines 11 to 14). The latter can be used to modify the value of “owner” (Line 12). When attacker calls the function VoipTken, function distr (Lines 18 to 20) will be invoked to manage the distribution of tokens to users. The distr function is guarded by the modifier canDistr (Lines 5 to 7), which requires distributionFinished to be false (Line 6). For the on-chain smart contract VoipToken, however, the current value of distributionFinished is true. Therefore, an attacker cannot exploit the buggy constructor function VoipTken. SPCon can identify exploitable permission bugs for the on-chain smart contracts with higher accuracy and can alert the contract administrator before attacks cause a money loss.

[0080] Answer to Q3: SPCon complements existing pattern-based tools and finds previously unknown permission bugs while achieving a higher accuracy in detection of vulnerabilities.

[0081] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavor to which this specification relates.

[0082] Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

[0083] The scope of this disclosure encompasses all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of this disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates respective embodiments herein as including particular components, elements, feature, functions, operations, or steps, any of these embodiments may include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere herein that a person having ordinary skill in the art would comprehend. Although this disclosure describes or illustrates particular embodiments as providing particular advantages, particular embodiments may provide none, some, or all of these advantages.

Claims

1 . A method of identifying a permission bug in a contract, comprising: performing role-mining to recover role structures of the contract based on a user permission assignment (UPA) obtained from transaction history, wherein the UPA contains a set of observed permissions assigned to each user; creating an access control policy specification based on the recovered role structures of the contract; and identifying the permission bug by conformance testing based on the access control policy specification.

2. The method of claim 1 , wherein when the contract is undeployed, the transaction history are configured to be generated through user acceptance testing.

3. The method of claim 1 or 2, wherein performing role-mining to recover the role structures of the contract comprises: computing an average frequency vector AFV(r) of a plurality of candidate roles r, AVF(r) representing how frequently users associated with the respective candidate role r exercise different permissions , wherein the AFV(r) is a |P|-dimensional vector x e ]R^|P|, wherein X{ = n(r, p_i')/\r\, wherein n(r, pi) denotes the total number of times the permission p_t e P gets exercised by the candidate role r's users.

4. The method of claim 3, wherein performing role-mining to recover the role structures of the contract comprises minimizing the maximum of the cosine similarities between any pair of the AFVs of the plurality of candidate roles r, wherein the maximum of the cosine similarities between any pair of the AFVs (SimErr) is computed according to:

5. The method of claim 4, wherein performing role-mining to recover the role structures of the contract comprises minimizing the number of mismatches between mined role structures (UA, PA) and the UPA so as to minimize role-consistency error, wherein the role-consistency error (DeltaErr) is according to:

where Il-Il! denotes the L¹ norm, ® refers to Boolean matrix multiplication, UA refers to a matrix of user to candidate role assignment, PA refers to a matrix of candidate role to permission assignment and UPA refers to a matrix of observed permissions assigned to users. The method of claim 5, wherein performing role-mining to recover the role structures of the contract comprises minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA, PA) at least include the permissions in the UPA by solving an optimization problem according to:

where a and are relative weights. The method of claim 6, wherein minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA, PA) at least include the permissions in the UPA comprises: grouping a set of users that share the largest set of permissions together so as to form a set of candidate role

encoding a solution to the optimization problem as a chromosome Chr[x] in the form o e gene of r_t ; and

guiding a search to find a solution following a fitness function

The method of claim 7, wherein conformance testing comprises: initializing a plurality of test sequences; and performing conformance testing for each test sequence. The method of claim 8, wherein conformance testing for each test sequence comprises: constructing symbolic paths for each of the plurality of test sequences; and checking each respective symbolic path for conformity with the recovered role structures. The method of claim 9, wherein constructing symbolic paths for the test sequences comprises concatenating function-level symbolic paths generated from symbolic execution. The method of claim 9 or 10, wherein when the symbolic paths are unable to be satisfied, the conformance testing is skipped for the respective test sequence. The method of any one of claims 1 to 11 , further comprising generating an attack test sequence corresponding to the permission bug based on results of conformance testing. A system of identifying a permission bug in a contract, comprising a plurality of processors configured for: performing role-mining to recover role structures of the contract based on a user permission assignment (UPA) obtained from transaction history, wherein the UPA contains a set of observed permissions assigned to each user; creating an access control policy specification based on the recovered role structures of the contract; and identifying the permission bug by conformance testing based on the access control policy specification. The system of claim 13, wherein when the contract is undeployed, the transaction history are configured to be generated through user acceptance testing. The system of claim 13 or 14, wherein performing role-mining to recover the role structures of the contract comprises: computing an average frequency vector AFV(r) of a plurality of candidate roles r, AVF(r) representing how frequently user associated with the respective candidate role r exercise different permissions wherein AFV(r) is a |P|-dimensional vector x e ]R^|P| , wherein x_t = n(r, p_i')/\r\, wherein n(r, pt) denotes the total number of times the permission pt e P gets exercised by the candidate role r's users. The system of claim 15, wherein performing role-mining to recover the role structures of the contract comprises minimizing the maximum of the cosine similarities between any pair of the AFVs of the plurality of candidate roles r, wherein the maximum of the cosine similarities between any pair of the AFVs of the candidate roles r (SimErr) is computed according to:

The system of claim 16, wherein performing role-mining to recover the role structures of the contract comprises minimizing the number of mismatches between mined role structures (UA. PA} and the UPA so as to minimize role-consistency error, wherein the role-consistency error (DeltaErr) is according to:

where Il-Il! denotes the L¹ norm and 0 refers to Boolean matrix multiplication, UA refers to a matrix of user to candidate role assignment, PA refers to a matrix of candidate role to permission assignment and UPA refers to a matrix of observed permissions assigned to users. The system of claim 17, wherein performing role-mining to recover the role structures of the contract comprises minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA. PA} at least include the permissions in the UPA by solving an optimization problem according to:

where a and ft are relative weights. The system of claim 18, wherein minimizing SimErr and DeltaErr while satisfying that the mined role structures (UA, PA) at least include the permissions in the UPA comprises: grouping a set of users that share the largest set of permissions together so as to form a set of candidate roles

encoding a solution to the optimization problem as a chromosome Chr[x] in the form of where xt is the gene of 77 ; and

guiding a search to find a solution following a fitness function: fitness (x) = (a • SimErr + /3 ■ DeltaErr) ¹. The system of claim 19, wherein conformance testing comprises: initializing a plurality of test sequences; and performing conformance testing for each test sequence. The system of claim 20, wherein conformance testing for each test sequence comprises: constructing symbolic paths for each of the plurality of test sequences; and checking each respective symbolic path for conformity with the recovered role structures. The system of claim 21 , wherein constructing symbolic paths for the test sequences comprises concatenating function-level symbolic paths generated from symbolic execution. The system of claim 21 or 22, wherein when the symbolic paths are unable to be satisfied, the conformance testing is skipped for the respective test sequence. The system of any one of claims 13 to 23, wherein the plurality of processors are further configured for generating an attack test sequence corresponding to the permission bug based on results of conformance testing.