Sirine Sayadi
email: sirine.sayadi@yahoo.fr

Tarek Abbes
email: tarek.abbes@enetcom.usf.tn

Adel Bouhoula
email: adel.bouhoula@supcom.rnu.tn

Detection of Covert Channels over ICMP Protocol

Keywords: Network Security, Covert Channel, Storage Channel, Traffic analysis, ICMP protocol, ICMP Tunneling, Tunneling Detection

With the growing complexity of networks and communications protocols that become increasingly enormous and extensive, we are confronted with the problem of covert channel that affects the confidentiality and integrity of data sent in the network. Covert channels also known as hidden channels can elude basic security systems such as Intrusion Detection Systems (IDS) and firewalls. We propose in this work a method to monitor and detect the presence of hidden channels that are based on an essential monitoring protocol "Internet Control Message Protocol" (ICMP). We undergo the network traffic with a set of verifications ranging from simple fields verification to more complex pattern matching operations. To validate our idea, we have installed Ptunnel, a tool that allows to tunnel TCP connections to a remote host using ICMP echo request and reply packets. Our experimental results show the possibility to discover such malicious traffic with high performance.

I. INTRODUCTION

The evolution of computer networks in recent years has led to the development of new technologies and services but also the emergence of new threats that destroy our data. According to Lampson [START_REF] Lampson | A note on the confinement problem[END_REF], attacking covert channels occurs when the communication of information between two parties is secretly done via a chain which is not intended for the sending of information. The purpose of using hidden channels is to send data in the network while ensuring that the sending is unnoticed by a third party and without alerting any firewalls or Intrusion Detection Systems (IDS) on the network. This is done for several purposes such as (a) using the resources of others to send secret data, (b) data leakage, (c) installation, distribution and control of malicious software, (d) bypass security devices such as firewall, etc.

In the literature, covert channels can be classified into two categories, timing and storage channels [START_REF] Okhravi | Design, implementation and evaluation of covert channel attacks[END_REF]:

• A Timing Channel is a covert channel in which a process reports information to another process while manipulating the time it takes to perform a given operation. The other process can observe to understand what happened.

• Storage Channels are based on shared data storage areas such as Unused or optional protocol fields. They include all means that would allow the direct or indirect writing at the storage area by a process and the direct or indirect reading of it by another one.

With the increased use of hidden channels that violates security policies, it has become necessary to find counter measures to detect this type of attacks. Several research works were done to defeat covert channels. They are mainly two countermeasure approaches. The first one relies on actively modifying optional and unused protocol fields whether there is or not a covert channel. The method has the drawbacks to change even safe traffic, introduces some delays and consumes computing resources. The second approach passively supervises network traffic and undertakes some controls looking for suspicious activities. In this case, it notifies the administrator about the presence of covert channels. In this work, we are interested in storage covert channels and we apply the passive monitoring approach to tackle this problem. We conduct many verification controls:

• Check ICMP messages size.

• Check the number of Echo Reply messages for a given Echo Request.

• Check if there is a spike in the number of ICMP messages.

• Check patterns.

The remainder of this paper is structured as follows: Section II describes some related works. Section III explains ICMP protocol and presents our detection method. Section IV discusses the experimental results. We devote Section V to assess the detection performance of our method. We draw in Section VI the conclusion and we mention some future works.

II. RELATED WORKS

Several researchers have oriented their research axes to detect covert channel attacks using multiple methods and techniques. Covert channels can be divided into Timing covert channels and Storage covert channels. In a timing covert channel, the bits of the covert information are represented by varying the time interval between the sent packets. S. Gianvecchio and H.Wang in [START_REF] Gianvecchio | An entropy-based approach to detecting covert timing channels[END_REF] propose a detection system that measures changes in entropy and in corrected conditional entropy (CCE) within the network to determine if timing channels are being used. A change in the entropy of a process provides a critical clue for covert timing channel detection. P. L. Shrestha et al [START_REF] Shrestha | undefined, undefined, undefined, and undefined, "A support vector machine-based framework for detection of covert timing channels[END_REF] provide a framework based on Support Vector Machine (SVM) classifier to detect covert timing channel. They derive four popular fingerprints (K-S test, regularity score, entropy, and corrected conditional entropy) from the traffic under investigation to form the SVM classifier.

By mounting storage covert channels, the hidden data is written in optional or unset protocol fields. The research works can be grouped according to the exploited network protocol. Using TCP protocol, E. Tumoian and M. Anikeev analyzed the accuracy of a neural network to detect the covert channel in the TCP Initial Sequence Number (ISN) field [START_REF] Tumoian | Network based detection of passive covert channels in tcp/ip[END_REF]. First, the neural network was formed to predict successive ISNs for different operating systems. Then, they monitored the ISNs used and compared them to the prediction models by measuring their statistical deviance. If an ISN sequence did not match any pattern indicating a normal deviation of the generated ISN then it may be a covert channel. H. Song and X. Li calculated an anomaly score that corresponds to the sum of weighted frequencies on all flag combinations in one second [START_REF] Song | Collaborative detection of covert storage channels[END_REF]. A high score indicates a suspect traffic. Then, the authors monitored and tested the decrease of TCP sequence numbers, considered as abnormal. They completed their traffic analysis by calculating the variance of TCP sequence numbers within a moving time window then compared it against the variance baseline for a normal traffic. A deviation may reveal the presence of hidden channels.

Using ICMP protocol as a medium for a covert channel, Sohn, et al. [START_REF] Shon | Covert channel detection in the ICMP payload using support vector machine[END_REF] proposed a detection method based on Support Vector Machine (SVM) to learn ICMP packets payload characteristics. They used Loki2 to generate abnormal ICMP packets and Tcpdump to capture network traffic. They preprocessed collected packets to extract the characteristic of ICMP packets headers and payloads. After a training phase, they built an SVM classifier able to discern suspect ICMP packets. In [START_REF] Stokes | ICMP Covert Channel Resiliency[END_REF] K. Stokes et al. tested the efficiency of firewalls and IDS to detect ICMP based hidden channels. They concluded that covert channels can easily defeat many modern security appliances if ICMP protocol is permitted. In [3] D. N. Muchene et al. transformed the covert channels to a secure reporting system of security alerts. They considered that this covert network communication combined with sophisticated insider threat monitoring tools, will improve security level and raise the costs and risks for intruders.

Existing research works consider that security technologies such as Firewalls and IDS cannot detect exactly the attacks of covert channels. Besides, exploited protocols are fundamental, so they cannot be deactivated. Regarding the capital importance of these protocols and the fact that they are very much used, we propose a detection method of hidden channels that rely on ICMP protocol.

III. PROTOCOL DESIGN

A. ICMP Overview

Internet Control Message Protocol (ICMP) is one of fundamental protocols of TCP/IP stack. It operates in the network layer and is mainly used to send control and error messages between endpoints. An ICMP packet is usually generated as a result of a diagnosis by another network protocol or a failure of transmission. As shown in Figure 1, ICMP header is composed of several fields that are Type, Code and Checksum. Other fields may be defined in the Data part such as the Identifier, sequence numbers in ICMP echo request (type 8) and reply (type 0).

The size of fields "type" and "code" is one byte. These latter indicate the purpose of the ICMP packet. The Checksum field is useful to check the integrity of the ICMP message. The identifier number and the sequence number are encoded with two bytes. They allow to match the ICMP echo reply messages to the echo request messages. Finally, the content of the Data can be filled by fixed bytes padding that depends on the operating system.

For Linux, the ICMP Echo Request payload contains 56 bytes, among them 8 bytes are used as a timestamp and the remainder match a fixed pattern. For the Windows operating system, the ICMP payload contains 32 bytes of sorted alphabets.

Type

Code Checksum Data Header

Data Payload

Fig. 1: ICMP frame format

B. Proposed Method

In order to discover covert channels, we apply two categories of verification. In the first step, we control the shape of ICMP messages. If suspicious activity is revealed, we pursue our inspection through pattern matching operations, which are considered greedier in term of computing resources. Figure 2 resumes the different verification controls that we will perform. We use the sliding window principle to calculate the ICMP message rate with respect to the whole traffic. Fig. 3 shows the computing inside the sliding window. Each window is composed of fixed number of time intervals (IT). Detection is only triggered with the reception of an ICMP packet. Besides, we use the previous ICMP packet to calculate the window's shift. For example, the interarrival time between two consecutives ICMP packets is about 3 interval times in Fig. 3. In this case, we have to update only IT0, IT1 and IT2 and keep IT3 to compute the ICMP messages rate at window 2. We present in Algorithm 1 the different tests achieved during the stage 1. We define the two functions "count icmp pkt" and "count all pkt" to compute respectively the number of ICMP messages and all received packets. Besides, the function "count icmp same addr Id" calculates the number of ICMP messages that have the same identifier or sequence number as the current analyzed packet "p". If we succeed in one test of stage 1, then we use the function "phase2 inspection(p)" to start stage 2.

2) Stage 2 -Analysis of ICMP messages content:

We are looking in this stage at the content of ICMP messages. Mostly, the operating systems use a constant payload to build the ICMP message. For example, Microsoft Windows uses the pattern "0x61 0x62 ... 0x77" while Linux employs the pattern "0x08 0x09 ... 0x37". We can inspect We define another content verification using the hash function MD5. Indeed, we compute for each pattern its hash value on 128 bits. Then, for each analyzed packet, we check if the hash of the packet content is identical to one of the two possible hash values. In case of equality, we decide that the packet is legitimate, else we mark the packet as a part of a covert channel. We describe this verification in Algorithm 3.

A. Experimental environnment

In order to mount our experiment, we setup two virtual machines on VMWAR. Besides, we install an attack tool called Ptunnel on two machines to serve as a Ptunnel client and a Ptunnel server (See Fig. 4). Ptunnel allows to reliably tunnel TCP connections to a remote host through ICMP packets. Traffic can be analyzed on an intrusion detection system deployed between the machines. It's also possible to retrieve traffic at the destination machine (Ptunnel server) as the latter can be considered as the target of the attack. The configuration of the Ptunnel client varies regarding the intended traffic to vehiculate. For example, if we would like to tunnel http traffic, we have to reconfigure the browser proxy on the client machine to localhost:8000. Besides, we execute the command " Ptunnel -p addr serv -lp 8000 -da dest addr -dp dest port" where lp, da and dp represent respectively the listen port, the destination address after reaching the proxy and the port that the proxy should use to tunnel the TCP connection. Fig. 5 gives the result of such execution when we would like to reach the url "www.google.tn". We can notice that the number of echo reply messages exceeds the one of echo requests. Besides, the ICMP payload contains the string "HTTP 1.0".

Fig. 5: Captured packets after the execution of ptunnel

We can also tunnel other types of traffic. For example, the command " Ptunnel -p addr serv -lp 8000 -da ssh dest addr -dp 22 " permits to vehiculate ssh traffic through ICMP messages.

To discern the existence of hidden channels, we have to capture network traffic and to conduct our analysis. The inspection is done on 2 stages. First of all, we look for unusual ICMP messages size, abundance of ICMP echo reply messages with the same identifier and a spike of the number of ICMP packets. Then, we confirm our inspection by filtering the ICMP data field searching for habitual patterns.

During our experiments, we execute Wireshark to capture network traffic. We export collected packets into PDML file. PDML is a structured XML document that contains details about packets dissection. We develop our proper program to parse XML using DOM (Document Object Model) programming API.

B. Exeprimental results and discussion

We carried out a set of experiences in presence of normal ICMP as well as covert channels. The hidden channel can be the result of interaction with a Web server or a SSH server. We compare in the first experiment the size of Data field of the ICMP messages. As shown in Fig. 6, the normal ICMP traffic has two possible sizes: 32 bytes in case of a Windows operating system and 56 bytes when dealing with a Linux machine. A covert channel interacting with a Web server modifies the common size of ICMP data field. Indeed, when tunneling the protocol HTTP, the ICMP data field has the size 28 bytes if it carries HTTP requests, and different bigger sizes (above 500 bytes in our case) if it encapsulates HTTP replies. Fig. 6 displays also the effect of tunneling a SSH session inside an ICMP based covert channel. The size of ICMP data field varies from 28 bytes to 200 bytes. Small packets are explained by the interactive nature of SSH application. Accumulation of sent bytes is possible thanks to Nagle Algorithm. Our second experiment verifies the occurrence of the same ICMP sequence number. We notice in Fig. 7 that in normal traffic each sequence number figures twice, one for the echorequest message and another for the echo-reply message. However, the number of utilization becomes variable in presence of covert channels interacting either with HTTP or SSH servers. Eventually, we evaluate the rate of ICMP messages with respect to the rest of traffic. The computation is done within a window size of 4 seconds with a step equals to 1 second. Fig. 8 shows that in normal conditions, ICMP traffic is not too present, and never exceeded in our experimentation 0.37. Hence, we choose this value as a threshold to mark an abnormal ICMP traffic. Covert channel toward a HTTP server leads the ICMP messages rate to reach 0.9, whereas the interaction with a SSH server, can bring this rate up to 0.7. DoS attacks can be misinterpreted as hidden channels since they also cause a spike of ICMP packets. To avoid this false alarm, we verify in Phase 2 of the detection process, the content of ICMP messages. We applied our detection method on a traffic generated by standard ping, personalized ping and the Ptunnel tool. Standard pings are issued from Windows and Linux operating systems. Besides, under Linux, we employ two options that modify the standard ping, the packet size (-s packetsize) and the payload (-p pattern). Ptunnel is used to communicate with a HTTP server and a SSH server. In total, we have 1266 ICMP packets, scattered in the network traffic. There are 751 ICMP messages that belong to covert channels, the other part (515 ICMP packets) is normal ICMP exchanges.

We show in Table I the confusion matrix to depict our detection results. In this execution, we choose to rely on the hashing test to ensure the phase 2 of our inspection. We succeed to reveal all malicious ICMP packets (751 messages), without generating any false negatives. False negatives are still possible since we could have collision with MD5 hashing, but this is very scarce. However, we detect 8 false positives due to changing the size of ICMP messages. We draw in Table II our detection results when using random pattern matching. In this execution, we detect only 745 malicious ICMP packets. The obtained 6 false negatives are due to a tricky modification of the ICMP messages pattern. In fact, the intruder inserts a secret message, just after the common pattern used by the operating system. Besides, we get 7 false positives because a legal modification of the ICMP data field. We compare in Table III the performance of the two ICMP content analysis methods. We give successively the True Positive Rate (TPR) or precision, the True Negative Rate (TNR), the False Positive Rate (FPR), the False Negative Rate (FNR), the accuracy and the time execution. The two methods present almost the same performance. Random Pattern Matching generates more false negatives but it is faster than hashing function. Since covert channels may require many packets to transfer information, we can rely on Random Pattern matching to discover them. Occasionally we execute MD5 hashing to prevent possible false negatives.

VI. CONCLUSION AND FUTURE WORK

A covert channel is a stealth communication mechanism that allows two or many participants to exchange unauthorized data. It represents a real and dangerous threat that affects the confidentiality and availability in an information system. In addition to data leakage, covert channel can be a means to bypass security devices and to control remote machines.

We propose in this paper a promising method to detect ICMP based covert channels. We undergo the received traffic a series of tests that begin with a simple size verification. Besides, we inspect in a sliding window, the ICMP messages rate as well as the replication of ICMP sequence numbers. In case of suspect traffic, we pursue our analysis by conducting a fast random pattern matching or a more accurate hashing verification test. Our experimentation shows that the two detection methods have almost the same accuracy and precision. However random pattern matching is faster.

As a future work, we will investigate the generalization of our method to discover other types of covert channels using any network protocol. Besides, we will conduct time series analysis in order to tackle the problem of temporal covert channel.

Fig. 3 :

 3 Fig. 3: Sliding Window

Algorithm 1 :

 1 Stage 1 all bytes in ICMP data field. However, such action will consume a lot of memory and time. To resolve this problem, we introduce two heuristics to ensure the verification. Our first strategy is to compare N successive random bytes from a random position pos. We present in Algorithm 2 such verification. Let pattern Linux the constant content of an ICMP message sent by a Linux machine ; Let pattern W in the constant content of an ICMP message sent by a Windows machine; N=rand mod 8+1; Pos=rand mod 24 +1; Sub pattern Linux= substring(pattern Linux,N,pos); Sub pattern Win= substring(pattern Windows,N,pos); Sub pkt Linux =substring (p.data+8,N,pos); Sub pkt win=substring (p.data,N,pos); Find Linux=match(Sub pkt Linux,Sub pattern Linux); Find Win=match(Sub pkt Win,Sub pattern Win) ; if Find Linux or Find Win then Then p is normal; else p is a covert channel at p.timestamp; end Algorithm 2: Stage 2 using random pattern matching

Let

  pattern Linux the constant content of an ICMP message sent by a Linux machine ; Let pattern W in the constant content of an ICMP message sent by a Windows machine; Hash Linux=MD5(P.data+8); Hash Win=MD5(P.data); Find Linux=compare(Hash Linux,Hash pattern Linux); Find Win=compare(Hash Win,Hash pattern Win); if Find Linux or Find Win then Then p is normal; else p is a covert channel at p.timestamp; end Algorithm 3: Stage 2 using MD5 hashing IV. EXPERIMENTATION

FirewallFig. 4 :

 4 Fig. 4: Ptunnel Setup

Fig. 6 :

 6 Fig. 6: ICMP Data Size in Normal Traffic and Covert Channels

Fig. 7 :

 7 Fig. 7: Number of Utilization of the Same ICMP Sequence Number

Fig. 8 :

 8 Fig. 8: ICMP messages rate

  During the stage 1 of our inspection, we start the verification with the size of ICMP data field. Mostly, this size must be equal to 32 bytes (Windows) or 56 bytes (Linux). If it is not the case, we trigger the second stage of inspection. Otherwise, we execute a second verification control at stage 1. During this test, we compute the number of ICMP echo replies associated to the same echo request. Association is ensured if there is a correspondence between the identifier and the sequence number. Usually, it must be only one association. If it is not the case, we start Stage 2 with pattern matching operations. Otherwise, we execute the last verification control in stage 1. In this case, we calculate the rate of ICMP messages regarding the rest of network traffic in a fixed size sliding window. If we notice a large increase if this rate, we start stage 2 of inspection. Else, we consider that the ICMP message is normal.

	1) Stage 1 -Analysis of ICMP messages shape:
	Incomming ICMP packets within a
	specified period of time
	Check the common size	False
	of ICMP messages
	True
	Check if there is	False
	only one reply for a given	Check Patterns
	echo request
	True		False
		True
	Check the absence of	False	Cover channel
	spike of ICMP messages
	True
	Normal channel
	Fig. 2: Proposed Method

  foreach packet p in logfile do X=count all pkt(p, prev, Win.size); if p.proto=ICMP then Y=count icmp pkt(p, prev, Win.size); Z=count icmp same addr Id(p,prev,Win.size); if (p.size =32) and (p.size =56) then

	stage2 inspection(p);
	else
	if Z > 2 then
	stage2 inspection(p);
	else
	if Y / X > Threshold then
	stage2 inspection(p);
	else
	p is normal;
	end
	end
	end
	end
	end

TABLE I :

 I Confusion Matrix using Hashing Function

	Prediction →	Covert channel	Normal traffic
	Actual traffic ↓
	Covert channel	751	0
	Normal traffic	8	507

TABLE II :

 II Confusion Matrix using random Pattern Matching

	Prediction →	Covert channel	Normal traffic
	Actual traffic ↓
	Covert channel	745	6
	Normal traffic	7	508

TABLE III :

 III Performance of Covert Channel Detection

		TPR	TNR	FPR	FNR	Accuracy	run time
	Hashing function	1	0.98	0.015	0	0.99	353 ms
	Random Pattern	0.99	0.98	0.013	0.008	0.98	4 ms
	Matching


Sirine Sayadi
email: sirine.sayadi@supcom.tn

Sonia Ben Rejeb
email: sonia.benrejeb@supcom.tn

Ziéd Choukair
email: z.choukair@supcom.tn

Blockchain Challenges and Security Schemes: A Survey

Keywords: Blockchain, Security, Technology, Smart Contracts, Consensus

With the increasing number of connected devices and the number of online transactions today, managing all these transactions and devices and maintaining network security is a research issue. Current solutions are mainly based on cloud computing infrastructures, which require servers high-end and broadband networks to provide data storage and computing services. These solutions have a number of significant disadvantages, such as high maintenance costs of centralized servers, critical weakness of Internet Of Things applications, security and trust issues, etc. The blockchain is seen as a promising technique for addressing the mentioned security issues and design new decentralization frameworks. However, this new technology has a great potential in the most diverse technological fields. In this paper, we focus on presenting an overview of blockchain technology, highlighting its advantages, limitations and areas of application.

The originality of this work resides in the comparison between the different blockchain systems and their security schemes and the perspective of integrating this technology into secured systems models for our comfort and our private life.

I. INTRODUCTION

The current network model connects multiple computing devices and will continue to support small-scale Internet of Things networks that will not be able to meet the growing needs of tomorrow's large ecosystems. Centralized cloud servers will remain a bottleneck. throttling and a point of failure that can disrupt the network.

In this context, Blockchain technology appeared in 2009 by Nakamoto [START_REF] Nakamoto | Bitcoin,Apeer-to-peer electronic cash system[END_REF] "Bitcoin Developers" as a storage technology serving decentralized large registers and as a security technique for authenticating, authorizing and verifying data generated.

With blockchain technology the concept of consensus has emerged as a mechanism that ensures trust in communication between two entities without the intervention of an intermediary. We can use blockchain in cryptocurrency, smart contracts, digital identity management, internet of things, access control applications, automated peer-to-peer insurance, in banks and in many other applications [START_REF] Pilkington | Blockchain technology: principles and applications[END_REF].

Since its inception, from the initial cryptocurrency to the current smart contract, blockchain technology has shown promising prospects in many areas of application.

This proposed paper will be a state-of-the-art study on blockchain technology. Section 2 will present an overview of blockchain technology. Section 3 will describe a semantic study of the potential of blockchain technology. We present in Section 4 some cases of use of this technology. Then we will examine the security threats, some real attacks for this technology, and its security enhancement solutions in Section 5 and finally we will conclude our paper by suggesting future directions.

II. OVERVIEW OF BLOCKCHAIN TECHNOLOGIES

This section presents a complete visualization of blockchain technology, how it works, its structure and existing types.

A. Blockchain Process

The Blockchain process is described as a transaction between users on the network that are grouped into blocks. The block is validated and saved on the network by a «minor » according to cryptographic techniques that depend on the rules of the type of blockchain used.

In the bitcoin blockchain this technique is called the "Proof-of-Work", (POW), and "proof-of-stake" (POS) in the blockchain ethereum. If the block is validated, it is time stamped and added to the block chain. The transaction is then visible to the receiver as well as the entire network. This process takes some time depending on the blockchain (about 10 minutes for bitcoin, 15 seconds for Ethereum) [START_REF] Kosba | The blockchain model of cryptography and privacy-preserving smart contracts[END_REF].

Each blockchain is identified by its cryptographic hash and carries a list of transactions and a hash to the previous block.

The exception to this is the first block in the chain, called "genesis", which is common to all clients in a blockchain network and has no parent. This establishes a link between the blocks, thus creating a chain of blocks, or blockchain. Any node having access to this ordered and back-linked block list can read it and understand what is the current global state of the data exchange on the network.

ComNet'2018 1570469703

B. Blockchain Structure

A block is composed of two main parts which are the Block Header and the transactions (see Figure 1). The Block header contains several fields, the most important among them are the block version, the Merkle tree Root Hash, time stamp, nBits, Nonce and parent block hash. Transactions are the data saved in the block [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF]. These fields will be detailed below (see figure 2):

Block Version: Specifies the set of block validation rules to follow [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF].

Merkle tree Root Hash : is a condensed digital fingerprint of all transactions in the block. The slightest modification of a transaction in the block modifies this root. Its principle is to calculate the hash of a node from a hash of his sons [START_REF]Application of Cryptographic Techniques[END_REF].

Timestamp: current time in seconds in universal time since January 1, 1970 [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF]. nBits: target threshold of a valid block hash.

Nonce: A 4-byte field, which usually starts with 0 and increases for each hash calculation. On receipt of the new block, the complete nodes compute the header hash only once, to see if the Nonce is valid [START_REF] Jesus | A Survey of How to Use Blockchain to Secure Internet of Things and the Stalker Attack[END_REF].

Parent block hash: The nodes save the data of the block's. Thus, all the nodes have the hash of the block 31, if the block 32 is received by a node, it will determine that the block 32 is the child of 31 by checking this field [START_REF] Jesus | A Survey of How to Use Blockchain to Secure Internet of Things and the Stalker Attack[END_REF]. Public blockchain from which everyone can participate in the process of reaching consensus and verifying the transaction. Like Bitcoin [4] and Ethereum [5].

Consortium blockchains: In this type, the node can be chosen in advance if the data in blockchain can be public or private. They can be considered as partially decentralized like Hyperledger [6].

Private blockchain has strict management authority over access to data. Nodes are restricted, not all nodes can participate in this blockchain like Ripple [START_REF] Zhegu | [END_REF].

Table 1: Comparative table of blockchain types [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF] All types of blockchain have advantages. The choice of blockchain type depends on our needs and our proposed services.

III. POTENTIELS OF BLOCKCHAIN

Blockchain technology is not only a technique, but it is a technological revolution with very important security features, its operating model using consensus and its shared ledger to solve the problems of traditional centralized models.

A. Basic Security Techniques

We detail in this section the different basic security principle by specifying how Blockchain technology can perfectly guarantee them.

Integrity: it to ensure that the information has not been changed, only by those authorized to make changes. Blockchain uses cryptographic mechanisms to guarantee that operations are immutable with the purpose of verifying integrity.

Availability: it ensures the availability of data for every need. the service is always active at the request of a legitimate users. Blockchain allows users to maintain blocks in a decentralized manner with various copies on the blockchain.

Pivacy: is the guarantee that only authorized persons can access to the information. The Blockchain uses a pseudo-anonymization mechanism (hash functions) to hide user identities to ensure confidentiality.

Authentication: a procedure by which a computer system certifies the identity of a person or a computer to allow that person to access certain secure resources.

The Blockchain technology provides this function by providing private keys for users who are authorized to carry out transactions.

Non-repudiation: Is the impossibility, for a person or any other entity engaged in a communication, to deny having received or sent a message, and this is ensured by blockchain technology.

B. Shared Ledger

This is the basic feature of blockchain technology, it means that blockchain does not have a centralized node, data is processed, stored and updated in a decentralized way. This avoids the problems of single deffain point and offers a peer to peer communication such that all nodes are interconnected and all participants in the network are equal without a central node.

C. Smart Contract

The smart contract is autonomous computer programs that once started, automatically execute pre-defined conditions with conditional statements of the type « if .... Then .... » Using the information available on the blockchain. These contracts must be able to reduce audit costs, execution, arbitration and fraud. They may have to manage funds or authenticate external entities [START_REF] Kosba | The blockchain model of cryptography and privacy-preserving smart contracts[END_REF].

D. Consensus

A consensus is a secure fundamental trust mechanism. It characterizes a general agreement of existence of the members of a group. It allows you to make a decision without the need of an intermediary or a trusted authority.

In the existing blockchain system, there are several consensus mechanisms. We will quote the best known below:

PoW (Proof of Work) :

Method used to validate Blockchain network blocks. This method requires users to use their computing power to validate a block. Minors compete against each other. As a result, the higher the computational power (combining several computers, to increase computing power), the more likely they are to find the result of a "Hash" function and thus validate the block. In the Bitcoin blockchain it is necessary to count a validation every 10 minutes approximately [START_REF] Zheng | Blockchain challenges and opportunities: A survey[END_REF].

PoS (Proof of Stake):

A chance to validate a block is based on how much of a stake (or cryptocurrency) the miners have. For example, if you had 5% of the cryptocurrency, you could extract 5% of all its transactions. People with more currency are thought to be less likely to attack the network. Its operating principle based on the richest person has more power in the network is unfair because the power here depends on the balance held in the account [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF]. The PoS save more energy (reduces the amount of calculation) but increases the flow. Unfortunately, if the operating cost is close to zero, attacks could result.

PBFT (Practical Byzantine Fault Tolerance) :

The problem of Byzantine generals is a metaphor that deals with questioning the reliability of transmissions and the integrity of the interlocutors. A Byzantine fault is therefore a failure that consists of the presentation of erroneous or inconsistent information. The consensus "Practical Bizantine Fault Tolerance" (PBFT) is a state machine replication protocol that tolerates arbitrary, or "Byzantine" faults. It is fault-resistant, fast, long-lived and an attack does not impact its performance too much. This protocol consists of three phases: pre-preparation, preparation & validation, it requires 3f + 1 replicates to tolerate f simultaneous Byzantine faults. When a message is sent on the platform, the nodes retransmit the transaction to all peers. If at least 2/3 of the nodes confirm the validity of the transaction it is confirmed. The platform allows users to transfer peer-to-peer ownership regardless [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF].

Many other consensus mechanisms can be found , such as DPoS (Delegated Proof of Stake), PoB (Proof of Bandwidth) [START_REF] Ghosh | A torpath to torcoin, proof-of-bandwidth altcoins for compensating relays[END_REF], PoEt (Proof of Elapsed Time) [START_REF]Intel, Proof of elapsed time[END_REF], PoA (Proof of Authority) [START_REF] Technologies | Proof of authority chains[END_REF], Ripple [48], Tendermint[49] etc. that are used in some blockchain systems.

A comparison between some of the most used consensus algorithms is presented in table 2 [START_REF] Zheng | An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends[END_REF].

With these advantages presented in this section from the basic security techniques, smart contracts, shared ledger and the consesus, blockchain technology has attracted attention in several areas.. In the next section, we will introduce some areas of use of blockchain technology as a solution concept.

IV. CASES USE OF BLOCKCHAIN AND APPLICATIONS

In our days, Blockchain technology is used in many areas, not only in the financial application, but also in other areas such as supply chain traceability, identity certification, insurance, International payments, the Internet Of Things and the protection of privacy etc [START_REF] Luu | secure sharding protocol for open blockchains[END_REF][START_REF] Tsai | system view of financial blockchains[END_REF][START_REF]ACMInternational Joint Conference on Pervasive and Ubiquitous Computing, UbiComp[END_REF][START_REF][END_REF][START_REF]Proceedings of the USENIX Annual Technical Conference[END_REF][START_REF]IEEE Security and PrivacyWorkshops[END_REF].

We detail in this section some uses of blockchain technology:

1) Digital Currency :

Several transaction systems have been built recently by blockchain technology, which makes a revolution in digital currency and online payment system. With these digital currencies and the crypthography technique, transfers can be made without the need of the central bank.

For example, we can send and receive bitcoins using public keys, with all anonymity we can record transactions.

Several other cryptocurrency like ethereurm, ripple, litecoin and etc [27].

2) Smart Contract:

Smart Contract is a digital contract that runs automatically through a computer system. It controls the digital assets of the user, by formulating a set of rules containing the rights and obligations of the users. Smart Contract is like an automatic trusting authority among participants [START_REF] Kosba | The blockchain model of cryptography and privacy-preserving smart contracts[END_REF]. Ethereum is an open source blockchain platform offering a decentralized virtual machine based on the Smart Contract. To manage these contracts Ethereum uses its digital currency called ETH, users can create many applications, services or different contracts on this platform [START_REF] Watanabe | \Blockchain contract: Securing a blockchain applied to smart contracts[END_REF].

3) Hyperledger :

Hyperledger is an open source blockchain platform, launched by the Linux Foundation in December 2015 with the aim of improving reliability and performance. It aims to support global business transactions of large technology, financial and supply chain companies etc [START_REF] Lin1 | A Survey of Blockchain Security Issues and Challenges[END_REF].

4) Blockhcain To Ensure privacy, Access control and Integrity

Protecting our personal information and our private life is a challenge in our day. [START_REF]ACS International Conference of Computer Systems and Applications, AICCSA 2016[END_REF][36] uses blockchain technology based POW in IOT applications to ensure integrity and confidentiality. Blockchain can also be used for access control. Just save the history daily in blockchain as a signed transaction specifying public keys with access rights. Only minors authetified with his private keys can include this transactions in their blocks [START_REF] Jesus | A Survey of How to Use Blockchain to Secure Internet of Things and the Stalker Attack[END_REF].

Based on blockchain technology, Ouaddah and al. [START_REF]new Blockchain-based access control framework for the Internet of 5943 5964[END_REF] presented the FaiAccess framework with its different parts to allow users to control their data. Zyskind et al. [START_REF]IEEE Security and PrivacyWorkshops[END_REF] exploited the access control option provided by the blockchain with storage in a distributed hash table of several selected nodes. The Blockchain is used here for data location management and their access.

Ali and al. [START_REF]Proceedings of the USENIX Annual Technical Conference[END_REF] used blockchain to build "Blockstack ID" which is an identity system and a decentralized PKI. This system consists of a control plane that is a name registration protocol and links and a data plan that is responsible for storing the data that must be signed by the name owner's key.

5) Blockchain For Eletronic Transactions

The Blockchain can be used as a base that will support the shared economy, based on machine-to-machine (M2M) communication. Several propositions in the theme [START_REF]he Conference on Intelligence in Next Generation Networks, ICIN 2015[END_REF][START_REF] Crosby | [END_REF][START_REF]ACM International Joint Conference on Pervasive and Ubiquitous Computing, UbiComp[END_REF]41,42]. Blockchain technology allows agents to autonomously perform a variety of transactions and to store the history of each transaction with transaparance and no deffiliation.

Sun et al. [41] specifies that Blockchain technology leads to the Internet of decentralized and autonomous objects. The blockchain supports all processing transactions between devices and each device can manage its behaviors and roles in an autonomous way.

Using the Bitcoin network, [START_REF]ACM International Joint Conference on Pervasive and Ubiquitous Computing, UbiComp[END_REF] described a model of data exchange by electronic money, between a sensor and a client. [START_REF]he Conference on Intelligence in Next Generation Networks, ICIN 2015[END_REF] described a Bitcoin-based e-commerce model for IOT devices. This composite model consists of 4 layers (the technical layer for the management of the Blockchain module, the infrastructure layer containing the smart contract platforms and IoT services, the content layer containing the participants and the IOT products and the layer exchange that contains the P2P transaction system).

We can find many other proposals that use Blockchain technology for economic transactions for IoT like ADEPT [43], Filament [START_REF] Crosby | [END_REF], Waston IoT platform [START_REF][END_REF], IOTA [42] etc.

6) Blockchain To Secure Smart Home :

Dorri et al. [45,50] proposed a lightweight blockchain solution adopted for IoT without cryptocurrency to illustrate a smart home containing a power computer that is responsible to control and audit communications and provide access control between devices. It maintains a private blockchain and is considered minor without the need for the proof of work concept because only this computer is responsible for managing the blockchain. Other devices receive a private key and a public key to perform transactions. For example, if a sensor wants to open the faucet, it will send a transaction to the faucet, which will check in Blockchain if that sensor is allowed to open it.

A smart home is the best example for IoT Blockchain combination. The services offered by blockchain technology can be contribute to shared economies and to the smart cities where objects connect seamlessly and anonymously to exchange and share data.

V. SECURITY ISSUES OF A BLOCKCHAIN TECHNOLOGIE

We describe in this section some recently encountered limitations that can affect the good functioning of blockchain technology by presenting some models in the form of the proposed improvement solutions to limit these risks.

A. Risks to Blockchain 1) 51% Vulnerability:

The consensus mechanism has a vulnerability of 51%, which can be exploited by attackers to manipulate the blockchain.

In PoW, if the hash power of a minor> 50% of the blockchain's total hash power, the 51% attack can be initiated. As a result, mining resources concentrated in a few mining pools can cause fears, as a single pool controls more than half of all computing power [START_REF] Hajdarbegovic | Bitcoin miners ditch ghash.io pool over fears of 51% attack[END_REF].

In the PoS, if the number of cryptocurrencies owned by a single by a single miner is greater than 50% of the total blockchain. A 51% attack can occur which an attacker can arbitrarily manipulate information from the blockchain [START_REF] Li | A survey on the security of blockchain systems[END_REF].

An attacker can exploit this vulnerability to carry out attacks; we will mention some of each after following [15]: Run a double spending by modifying the transaction data (same coins are spent multiples times). Change the order of transactions.

Prevent normal mining operations of other miners (Denial of service attack).

2) Double Spending attack:

A customer provides a seller with a signed transaction; the seller verifies the validity with a peer who confirms the transaction. If the client is malicious, it can create a conflicting transaction by generating a double spend (the same crypto currency spent twice) and having it validated by another peer before the first transaction has spread across the network. Both transactions are therefore proposed for mining. Depending on which will be treated first, it is this truth that will be imposed on the entire network by registration in one block and invalidate the other. In this case, if the seller had delivered before validation by the minor, he was robbed ... resulting in a double spending [14] [47].

3) Smart Contracts Risks

Dependency of the transaction order:

In order to update the blockchain, in each era, each miner will propose his own block. Since a block can contain multiple transactions, the state of the blockchain can change several times during an epoch. This attack can be triggered if two successive transactions of the same block invoke the same smart contract. The order of execution of these two successive transactions affects the final state because the execution of the smart contract is associated with a single state [START_REF] Li | A survey on the security of blockchain systems[END_REF].

The time stamp dependency:

Each block in the blockchain contains a timestamp field. Some conditions for triggering smart contracts depend on the timestamp, which is defined by the minor according to the time of his local system. Smart contracts depend on time stamp fields are vulnerable, if they can be changed by attackers [START_REF] Li | A survey on the security of blockchain systems[END_REF].

Under-Optimized Smart Contract :

The gas value corresponds to the computing resources exploited by the bandwidth operation, memory occupancy and many other parameters used in Ethereum as a function of time.

We can find some resource-intensive operations such as dead code operations and the use of loops by exchanging the gas value according to the cryptocurrency. [START_REF] Li | A survey on the security of blockchain systems[END_REF].

4) Denial Of Service Attack

An attacker can launch a DoS (Denial of Service) attack by exploiting a set of operations executed in a single transaction. This is because some heavy operations require too low gas values. This can cause a waste of resources [START_REF] Rivlin | Vitalik buterin on empty accounts and the ethereum state[END_REF].

5) Selfish Mining Attack:

This attack is conducted by mining in order to obtain undue rewards or to waste the computing power of honest minors [START_REF] Solat | Zeroblock: Preventing selsh mining in bitcoin[END_REF]. The attacker holds the blocks discovered in private and then tries to forge a private channel. The authors in [START_REF] Eyal | Majority is not enough: Bitcoin mining is vulnerable[END_REF] proposed a Selfish-Mining attack, which attract other honest miners to dispel their computing resources unnecessarily to keep working on blocks that lead to a stalemate instead of attaching them to the longest chain.

6) Reentrancy Attack:

It is the fact of exploiting a recursive sending for example the biggest flight about 60 million US dollar of the contract CAO by this attack just after its deployment of 20 days [START_REF] Atzei | A survey of attacks on ethereum smart contracts (sok)[END_REF].

7) Liveness Attack

In [START_REF] Kiayias | On trees, chains and fast transactions in the blockchain[END_REF] the authors proposed this attack to exploit the dilation of the confirmation duration in order to obtain a target transaction.

8) The Balance Attack

Christopher and al. [START_REF] Natoli | The balance attack against proof-of-work blockchains: The r3 testbed as an example[END_REF] proposed this attack based on PoW blockchain, which consists of identifying subgroups of miners with similar mining power and delaying messages passed between them in order to mine blocks before them.

B. Security Improvements 1) Smart Pool

L. Luu et al [START_REF] Luu | Smart pool: Practical decentralized pooled mining[END_REF] proposed a new Smart Poll mining pool system, implemented as a smart contract. It is a decentralized mining protocol that replaces the centralized pool operator.

It retrieves client transactions that contain information about mining tasks. Then the miner performs a hash calculation and returns the completed shares to the smartpool. A threshold sets an amount, if the shadow of actions made reaches this threshold, the miners will be committed to a smartpool contract that verifies the actions and delivers rewards to the customer [START_REF] Li | A survey on the security of blockchain systems[END_REF].

2) Quantitative Framework

In [START_REF] Gervais | On the security and performance of proof of work blockchains[END_REF] the authors proposed a quantitative framework is used to analyze the performance and security provisions of the blockchain. it is a blockchain simulator and a security model that mimics its execution to evaluate basic security and performance.

This model specifically focuses on the attacks of selfish and double-spending mining by taking into consideration the consensus protocol used and network parameters such as block propagation delays, block sizes, delays network, block rate and the mechanism of propagation of information etc.

3) Oyente

Loi and al. [START_REF] Luu | Making smart contracts smarter[END_REF] proposed a new program called Oyente that tracks errors in smart contracts. This tool can also detect bugs and injection attacks in smart contracts.

Oyente analyzes the bytecode of smart contracts and follows the EVM execution model [START_REF] Li | A survey on the security of blockchain systems[END_REF].

VI. CONCLUSION AND PERSPECTIVES

In this paper, we presented an overview of Blokchain technology. We have described its different security potentials by specifying a comparison between some of the most widely used consensus algorithms in different blockchain systems. We have also clarified the fields of use of this technology because in recent years, it has shown its potential in several applications and this is due to the advantages of this technology and its decentralized nature. These applications permeate everyday life, business and society as a whole, transforming the world into a more efficient world. And finally, we indicated that many maneuvers of this technology, then specifying the improvement solutions proposed to defend them.

Blockchain then presents many promising opportunities that open up many paths for the future and for a connected world in complete security. However, the challenges remain in the resources and consensus models used.

That's why, we aims in future work to leverage the benefits, limitations of blockcahin technology, and enhancement solutions to produce a new secure system model that integrates this technology with the Internet Of Things technology for a connected and secure world.

Figure 1 :

 1 Figure 1: Blockchain Process

Figure 2 :

 2 Figure 2: Simplified Block Structure

Table 2 :

 2 Comparison between some consensus algorithms

	Property	POW	POS	PBFT
	Identity	Without	Without	With
	management	permission	permission	permission
	of nodes
	Energy saving	No	partial	yes
	Power	<25%	<51%	<33,3%
	tolerated	computing	stake	Defective
		power		replicas
	Example	Bitcoin	Ethereum	Hyperledger


Jasmin Christian Blanchette
email: j.c.blanchette@inria.fr

Daniel El Ouraoui
email: daniel.el-ouraoui@inria.fr

Pascal Fontaine
email: pascal.fontaine@inria.fr

Cezary Kaliszyk
email: cezary.kaliszyk@uibk.ac.at

Machine Learning for Instance Selection in SMT Solving

SMT solvers are among the most suited tools for quantifier-free first-order problems, and their support for quantified formulas has been improving in recent years. To instantiate quantifiers, they rely on heuristic techniques that generate thousands of instances, most of them useless. We propose to apply state-of-the-art machine learning techniques as classifiers for instances on top of the instantiation process. We show that such techniques can indeed decrease the number of generated useless instances. We envision that this could lead to more efficient SMT solving for quantified problems.

Satisfiability-modulo-theories (SMT) solvers are among the best backends for verification tools and "hammers" in proof assistants. When proof obligations contain quantified formulas, SMT solvers rely on instantiation, replacing quantified subformulas by sets of ground instances. Three main techniques have been designed: enumerative [START_REF] Reynolds | Revisiting enumerative instantiation[END_REF], trigger-based [START_REF] De | Efficient E-matching for SMT solvers[END_REF], and conflictbased [START_REF] Reynolds | Finding conflicting instances of quantified formulas in SMT[END_REF] instantiation. Among these, only conflict-based instantiation computes instances that are guaranteed to be relevant, but it is incomplete and is normally used in combination with other techniques. Enumerative and trigger-based techniques are highly heuristic and generate a large number of instances, most of them useless. As a result, the search space of the solver explodes. Reducing the number of instances could improve the solver's efficiency and success rate within a given time limit.

We propose to use a state-of-the-art machine learning algorithm as a predictor over the generated set of instances to filter out irrelevant instances, and thus decrease the number of instances given to the ground solver. The predictor is invoked after each instantiation round to rate the potential usefulness of each generated instance. Several strategies are then used to build a subset of potentially relevant instances that are immediately added to the ground solver. Adding the other instances is postponed.

We conducted our experiment in veriT [START_REF] Bouton | veriT: an open, trustable and efficient SMT-solver[END_REF], an SMT solver that implements all three instantiation techniques described above. We chose as predictor the XGBoost gradient boosting toolkit [START_REF] Chen | XGBoost: a scalable tree boosting system[END_REF] with the binary classification objective. This configuration had already been used successfully in the context of theorem proving [START_REF] Jakubuv | ENIGMA: efficient learning-based inference guiding machine[END_REF][START_REF] Piotrowski | ATPboost: Learning premise selection in binary setting with ATP feedback[END_REF].

Choosing a suitable set of features is crucial for effective machine learning. The features determine how precise the representation of the problem is. Previous works already investigate features for theorem proving [START_REF] Allamanis | Learning continuous semantic representations of symbolic expressions[END_REF][START_REF] Irving | DeepMath-deep sequence models for premise selection[END_REF][START_REF] Jakubuv | ENIGMA: efficient learning-based inference guiding machine[END_REF][START_REF] Kaliszyk | Efficient semantic features for automated reasoning over large theories[END_REF][START_REF] Loos | Deep network guided proof search[END_REF][START_REF] Piotrowski | ATPboost: Learning premise selection in binary setting with ATP feedback[END_REF]. Our features are more specifically inspired by ENIGMA [START_REF] Jakubuv | ENIGMA: efficient learning-based inference guiding machine[END_REF] and RLCoP [START_REF] Kaliszyk | Reinforcement learning of theorem proving[END_REF]. They are basically term symbols and term walks with symbol sequences projected to features using Vowpal Wabbit hashing. Term variables and Skolem constants are translated analogously to constants. The model is further enriched with abstract features such as term size, term depth, and the number of instances.

To encode our problem into sparse vectors, we use three kinds of information available to the solver: the ground part of the formula (set of literals l 1 , . . . , l m ), the quantified formula In the learning phase, to discriminate useful instances from others in the run of the solver, we consider the pruned proof with only the relevant facts. An instance produced in the run is tagged as useful if it also occurs in the pruned proof. To train the predictor, we used the SMT-LIB benchmarks in the UF category. We ran veriT on 1866 SMT formulas randomly divided into two sets: 560 for the test set (30%) and 1306 for the training set (70%). One run of the solver generates many more useless instances (99%) than useful ones (1%). Consequently, we used undersampling to obtain a balanced data set for learning.

Figure 1 compares the numbers of generated instances for two versions of the veriT solver: with instance selection (x-axis) and without (y-axis). The fewer instances, the better. The left-hand side shows the results of the solvers on the entire data set (training and test), whereas the right-hand side shows the results only on the test set. In both plots, a cluster of points is forming along the line corresponding to the equation f (x) = 2x. On average, instance selection allows veriT to find proofs with about half the number of instances. On the other hand, a time comparison would not look good for instance selection, because the current prototype relies on extremely time consuming external calls to the predictor.

These results show that our approach seems to be suitable to substantially reduce the number of generated instances. The implementation of this first prototype is suboptimal. We are now working on an implementation of the predictor inside veriT, hoping to make the prediction cost close to negligible. We hope that the good results in terms of number of instances required will eventually translate into strong performance.

Figure 1 :

 1 Figure 1: Comparison of veriT configurations on UF SMT-LIB benchmarks

Acknowledgement The work has received funding from the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation program (grant agreement No. 713999, Matryoshka). Experiments were carried out using the Grid'5000 testbed (https://www.grid5000.fr/), supported by a scientific interest group hosted by Inria and including CNRS, RENATER, and several universities as well as other organizations.