CONTRACTS

FIELD OF THE INVENTION:

An invention is disclosed pertinent to the field of internet security, more particularly means and methods to provide secure blockchain smart contracts.

BACKGROUND

Smart contracts are programs stored on a blockchain that run when predetermined conditions are met. They are typically used to automate the execution of an agreement so that all participants can be immediately certain of the outcome, without any intermediary’s involvement or time loss. Smart contracts can also automate a workflow, triggering the next action when conditions are met. Smart contracts include a “suspend” function that pauses all activity in the case of a security breach

An example of a suspend function is the selfdestruct function provided by Ethereum smart contracts to destroy a contract on the blockchain system. However, it is a double-edged sword for developers. On the one hand, using selfdestruct function enables developers to remove smart contracts (SC) from Ethereum and transfers Ethers when emergency situations happen, e.g. being attacked. On the other hand, this function can increase the complexity for the development and open an attack vector for attackers. (Ref):

Why Do Smart Contracts Self-Destruct? Investigating the Selfdestruct Function on Ethereum* JIACHI CHEN, Monash UniversityACM Trans. Softw. Eng. Methodol., Vol. 1, No. 1, Article 1. Publication date: January 2021.

LifeScope detects the self-destruct issues at source code level, which utilizes AST (abstract syntax tree) to parse the smart contracts and extract related information to detect Unmatched ERC20 Standard. For Limits of Permission, LifeScope first transfers the contract to a TF-IDF representation and then utilizes machine learning algorithms to predict this problem. These two problems are not only limited to contracts that contain the selfdestruct function. Any smart contracts can be analyzed with LifeScope to detect these two problems before deploying them to the Ethereum This solution runs monitoring code outside the blockchain to detect suspicious activity and then use an administrator key to pause activity. LifesScope and similar solutions use Machine learning for detecting suspicious activity which is often complex and is therefore not suitable for running inside blockchain smart contracts, and is therefore run by default outside the blockchain. The problem with this approach is that the administrator key itself has the power to pause the smart contracts and freeze funds and activities mid-flights, and this poses an additional target which may not have existed before.

In US11042804B2 (Kikinis) there is provided a system and method providing a security gateway for high security blockchain systems, that acts as a firewall (and manages users, rules, data access, transactions, fees, etc.), has the ability to understand and enforce blockchain business processes policies (access policy and transaction policy of a blockchain solution that may or may not support smart contracts), and can understand tokens and their functionality, without totally disabling code execution, for example from smart contracts or tokens enabled by smart contracts. Such a system however is complex and multi-tiered.

In light of the above, there is a long felt and unmet need for systems and methods for monitoring attacks on smart contracts and suspending smart contracts when appropriate. https ://www .ledger.com/soft-launching-ledger-sgx-enclave

SUMMARY

It is an objective of the present invention to disclose a method for monitoring and suspending smart contracts in blockchain comprising steps of

Configuring 210 a trust relationship between a secure enclave and smart contract, the smart contract provided with a unique enclave signature enabling calls based on the unique enclave signature to be accepted

Configuring 220 a data monitoring application within the secure enclave including 230 within Smart contract application a “pause” function that can only be instigated by specific enclave running specific pre-defined monitoring code submitting 240 a hardware secure enclave originated attestation request to the processor manufacturer attestation 140 module

Relaying 250 and witnessing 260 blockchain smart contract activity to the secure enclave Verifying 270 the transaction from the blockchain

Monitoring 280 by the application, data from the blockchain relayer

Detecting 290 suspicious activity in the smart contract and

Instigating 300 the pause function to pause the smart contract and halt potential attack

It is an objective of the present invention to disclose the aforementioned method wherein the verifying the transaction requires state proofs selected from the group consisting of PoW, PoS, consortium proofs or private proofs or any other consensus mechanism.

It is an objective of the present invention to disclose the aforementioned method wherein verifying the transaction is carried out via a light client.

It is an objective of the present invention to provide a system for monitoring and suspending smart contracts in blockchain comprising:a hardware processor enclave containing a specific monitoring code ; and a modular application including a non-transitory computer readable medium storing machine readable instructions that when executed by the processor 150 cause the processor to initiate a 'pause function" when called by the specific hardware secure enclave containing the specific monitoring code, using a key only present inside the hardware secure enclave.

It is an objective of the present invention to provide the aforementioned system wherein the enclave is configured to submit an attestation request for enclave and application source code hash

It is an objective of the present invention to provide the aforementioned system wherein the system comprises a relayer module for witnessing and transmitting data on blockchain smart contract activity to the secure enclave

DETAILED DESCRIPTION OF THE PRESENT INVENTION

Figure 1 provides an illustration of the basic elements of the present invention.

Figure 2 provides an illustration of aspects of the present invention. Blockchain smart contacts present a method for managing, holding, transferring and generally applying business logic to digital assets (also known as tokens) stored in a distributed ledger (also known as a blockchain).

The advantages of smart contracts include the fact that they operate relatively autonomously. The smart contracts are executed and validated by the nodes that comprise a blockchain 110 network. Typically, all nodes in a network must execute and agree on the validity and results of the smart contract execution in order for the execution to be accepted and for the results of the smart contract execution to update the state of the assets registered in the blockchain ledger.

Smart contracts also present a challenge, in that, because they are comprised of code that handles digital assets relatively autonomously, any errors, bugs or vulnerabilities in the smart contract code offer a potential attacker access to the digital assets, often valued at tens or hundreds of millions of dollars (see Parity error, Wormhole attack etc.).

In order to mitigate such attacks, smart contract developers try to use proven, well tested code, as well as code analysis tools in order to identify any vulnerabilities ahead of deployment. Smart contract code security audits are performed by third parties in order to further identify vulnerabilities.

Once the smart contract code is deployed and begins to transact and store value on a blockchain, any vulnerabilities that remain will be difficult to detect, and if an attacker does begin an attack, it will be difficult to identify or halt such an attack before a significant number of funds or assets have been compromised.

In the cybersecurity realm, numerous machine and network scanning tools are available to monitor and detect unusual behaviour by potential attackers, alert, and automatically halt access or halt systems in order to mitigate the damage of a potential attack.

In the present invention, figure 1 illustrates a system and method for making blockchain smart contracts more secure. The smart contracts are monitored by a monitoring code running inside a hardware secure enclave 120 that cannot be modified without the smart contract itself being modified first. Only if an issue is detected by the enclaved monitoring code, is the contract paused or suspended. DEFINITIONS:

The term "Secure Enclave" is herein described with particular relevance to the present invention.

A secure enclave provides CPU hardware-level isolation and memory encryption on every server, by isolating application code and data from anyone with privileges, and encrypting its memory. With additional software, secure enclaves enable the encryption of both storage and network data for simple full stack security. Secure enclave hardware support is built into all new CPUs from Intel and AMD.

Enclaves are solutions which are built into the CPU and provide hardware security. Using a dedicated set of instruction codes, enclaves are isolated regions of memory which are protected from processes running at any privilege level, including the operating system.

The term and product "Intel Software Guard Extensions (SGX)" is herein described with particular relevance to the present invention.

Intel Software Guard Extensions (SGX) is a set of security-related instruction codes that are built into some Intel central processing units (CPUs). They allow user-level and operating system code to define private regions of memory, called enclaves, whose contents is inaccessible from the outside. SGX is designed to be useful for implementing secure remote computation, secure web browsing, and digital rights management (DRM). Other applications include concealment of proprietary algorithms and of encryption keys. SGX involves encryption by the CPU of a portion of memory (the enclave).

SGX is designed to be useful for implementing secure remote computation, secure web browsing, and digital rights management (DRM). Other applications include concealment of proprietary algorithms and of encryption keys.

SGX involves encryption by the CPU of a portion of memory (the enclave'). Data and code originating in the enclave are decrypted on the fly within the CPU, protecting them from being examined or read by other code, including code running at higher privilege levels such the operating system and any underlying hypervisors. While this can mitigate many kinds of attacks The terms "witnessing or witness" are herein defined as signatures attesting to authenticity of data. An example would be a bitcoin transaction in which the witness is the contents of the signature scripts, which are what proves that the transaction is authentic.

The terms "pausing, pause, pause function, suspend or suspending" are used interchangeably and are explained briefly below:

"Pausing" or "suspending" a smart contract:

When a smart contract is "paused," nothing can be done with it (it can't be transferred). Only the contract deployer can pause or unpause the contract. This individual can also add more "pauser" accounts to the contract.

In some use cases, disabling options are used on critical contract functionality in case of an emergency.

The term "Multisignature (multisig)" is used herein and briefly explained below

Multisignature (multisig) wallets are smart contracts that allow multiple signers to review and agree on an action on the blockchain before the action is executed.

The term "Light clients" is defined herein:

Light clients or light nodes help users access and interact with a blockchain in a secure and decentralized manner without having to sync the full blockchain. A light client or light node is a piece of software that connects to full nodes to interact with the blockchain. Unlike their full node counterparts, light nodes don’t need to run 24/7 or read and write a lot of information on the blockchain. Light clients do not interact directly with the blockchain; they instead use full nodes as intermediaries. Light clients rely on full nodes for many operations, from requesting the latest headers to asking for the balance of an account. The term "Consensus mechanisms" are defined herein:

Consensus mechanisms of blockchain Smart contract systems covered in the present invention in a non limiting manner:

Blockchain systems vary considerably in their design, particularly with regard to the consensus mechanisms used to perform the essential task of verifying network data. The most common consensus mechanisms are Proof of Work (PoW), Proof of Stake (PoS), and methods used by private and consortium blockchains. Each design has different implications for the underlying blockchain’s security, accessibility, and sustainability.

With proof-of-stake (POS), cryptocurrency owners validate block transactions based on the number of coins a validator stakes.

Proof-of-stake (POS) was created as an alternative to Proof-of-work (POW), the original consensus mechanism used to validate a blockchain and add new blocks.

A private blockchain is a blockchain controlled by a centralized entity which determines who can interact with the blockchain, verify transactions, and who can view the information recorded on the blockchain. A consortium blockchain is a distributed ledger controlled by several entities, each of which operates a network node, participates in consensus, and has permissions to view certain types of data.

GENERAL DESCRIPTION OF THE PRESENT INVENTION

The blockchain-based smart contract lacks privacy, since the contract state and instruction code are exposed to the public.

It is acknowledged herein that the core of the present invention is to provide a system and method ensuring that a suspend function or pause function of a smart contract within a blockchain can only be activated by a specific secure enclave (Intel SGX) instance running specific predefined monitoring code Combining smart contract execution with Trusted Execution Environments provides an efficient solution, called TEE-assisted smart contracts (TCSC), for protecting the confidentiality of contract states.

It is further acknowledged that any change to the secure enclave monitoring code requires a redeploy of the smart contract

It is further acknowledged herein that if contract code change affects monitoring, any change to the contract requires an update to the secure enclave monitoring code to resume smart contract activity following suspension a predefined administrator key (or multi-sig) is required

It is acknowledged herein that the aforementioned system and method is useful for monitoring cybersecurity risks and token theft in smart contracts (e.g. DeFi liquidity pools) in order to trigger pausing of contracts suspected to be under attack

It is further acknowledged herein that the system and method of the present invention is useful for monitoring general performance of DeFi (Decentralized Finance) and DAO (Decentralized Autonomous Organization) smart contracts (e.g. balance of lending vs borrowing, collateral and pricing) in order to trigger behaviour in other contracts (e.g. investing strategies)

The method of the present invention is to run the monitoring code in a hardware secure enclave 120, such as Intel SGX. Such an environment includes a code and enclave attestation 140 feature, whereby the enclave manufacturer provides a cryptographic attestation that the enclave is theirs, and therefore the code signed by the enclave is therefore present in that enclave (represented by a hash of the enclave). This allows us to set up an enclave with a blockchain smart contract such that the smart contract will only trust a specific enclave running specific code. If the enclave code is modified, then the blockchain smart contract will no longer accept messages from that enclave.

Reference is now made to fig 1 disclosing a system for monitoring and suspending smart contracts in blockchain comprising:a hardware processor enclave 120 containing a specific monitoring code ; and a modular application including a non-transitory computer readable medium storing machine readable instructions that when executed by the processor cause the processor to initiate a 'pause function" when called by the specific hardware secure enclave containing the specific monitoring code, using a key only present inside the hardware secure enclave.

Reference is now made to the aforementioned system wherein the enclave is configured to submit an attestation request for enclave and application source code hash

Reference is now made to the aforementioned system wherein the system comprises a relayer module 160 for witnessing and transmitting data on blockchain smart contract activity to the secure enclave.

Reference is made herein of a system characterized by a blockchain 110 smart contract 130 including an emergency “pause” function, that can only be called by a specific hardware secure enclave containing specific monitoring code, using a key only present inside the hardware secure enclave 120. This presents an attacker from accessing the key that could pause the smart contract 130, or from modifying or manipulating the monitoring code in order to attempt to attack the smart contract 130 by pausing it.

Reference is now made to fig 2 disclosing a method for monitoring and suspending smart contracts in blockchain comprising steps of

Configuring 210 a trust relationship between a secure enclave and the smart contract, the smart contract provided with a unique enclave signature enabling calls based on the unique enclave signature to be accepted

Configuring 220 a data monitoring application within the secure enclave

Including 230 within Smart contract application a “pause” function that can only be instigated by specific enclave running specific pre-defined monitoring code submitting 240 a hardware secure enclave originated attestation request to the processor manufacturer attestation module

Relaying 250 and witnessing 260 blockchain smart contract activity to the secure enclave

Verifying 270 the transaction from the blockchain

Monitoring 280 by the application, data from the blockchain relayer

Detecting 290 suspicious activity in the smart contract and

Instigating 300 the pause function to pause the smart contract and halt potential attack Reference is now made to an embodiment of the aforementioned method wherein verifying the transaction requires state proofs selected from the group consisting of PoW, PoS, consortium proofs or private proofs or any other consensus mechanism.

Reference is now made to an embodiment of the aforementioned method wherein the verifying the transaction is carried out via a light client.