Let's start by defining the system for which our encryption scheme and our protocol were developed. We define the considered threat environment. Typically, the ABE usage model considers a data source (DS), which produces and encrypts data, a consumer data (RQ) that receives the data and decrypts it, and finally a trusted authority (TA) responsible for the management of keys and attributes.
Concretely, we adopt the scenario of medical surveillance of the state of individual using connected sensors. The data collected is transmitted to Cloud for their processing, storage and especially sharing with authorized entities. This scenario integrates the context of the Internet of Things and the Cloud into its architecture as well as strong constraints of confidentiality and preservation of private life. We consider that the data sources (DS) are limited in computing capacity, memory and energy. Hence an architecture including an entity for outsourcing certain process, operations, rated (PR) for proxy. In a real situation, these entities are instantiated by Fog computing technologies. Finally, RQ can be the attending physician with cryptographic proof attesting to its attributes, for example a smart card issued by a trusted authority. This proof allow him, among other things, to attest to his attributes. For key sharing, a simple (but realistic) solution was using mail electronic and RSA encryption.
Threat model
To define a threat model, it is necessary to consider the reality of the world in order, on the one hand not to underestimate the threat and on the other hand not to overestimate it. In indeed, any unnecessary overestimation will result in an additional unnecessary security cost. The aim of the solution we are proposing is to preserve the patient's privacy in the scenario considered. The analysis of this scenario makes it possible to identify a first threat induced by the communication. Often we use wireless communications, easily intercepted.
A model that takes this threat into account is the model which considers the network to be an intruder. Thus, an attacker can listen, delete, replay and edit a message. However, the attacker will not be able to decipher a message if he does not do not have the decryption key. Then, given that the outsourcing infrastructures (Cloud, Edge, Fog, etc.) under the control of a third party who may not be completely sure, we adopt the same model, which considers these

infrastructures as honest actors but curious. This means that the cloud, for example, correctly instantiates the protocol but can try to infer information about the patient. In addition, this model supports the realistic threat posed by the context of the Cloud, in which it can be the target of malicious entities. It can also be the subject inadvertent leakage of personal information. Finally, we consider the Trusted Authority (TA) to be completely honest.
Attribute-based encryption with IT in foe (FCCP-ABE)
To achieve access control with fine granularity and ensure the protection of stored data, we offer a new encryption scheme based on encryption by attributes and which we have proven to be reliable under an adaptive attack on selected lights. This scheme is an attribute-based encryption with an access policy, adapted to the environment of foggy computing or Fog-Compiiting Cipher-Policy Attribute-Based Encryption, abbreviated as FCCP-ABE. Aware that limiting resources is a major concern of the IoT, we offer a design of encryption with a deportation mechanism for greedy tasks.
The security model in the system considered
We assume that cloud or fog computing service providers are honest but curious. They are only allowed to run the protocols correctly, but they are not allowed to know private data. Also, a property important security required in our system is the ability to resist attacks by collusion between users. The latter may attempt to combine their rights in order to increase their privileges. Finally, the communication channels are assumed to be insecure. We define the security for the FCCP-ABE scheme by an experiment, involving a challenger B and an attacker A. With regard to the security objectives and the capacity adversary, we adopt the clear text security model chosen for our system.
• Init: The probabilistic adversary (algorithm) A, running in polynomial time, chooses a set of attributes to generate a P challenge access structure * and sends it to challenger B.
• Setup: Challenger B executes the Setup algorithm to generate the parameter public PK and forwards it to opponent A.
• Phase 1: The opponent repeats, as much as he considers necessary and adaptively, requests to generate secret keys, each time with a new set of attributes If.
• Challenge: The opponent submits two messages of equal length, mO and ml, and provides a challenge access structure A* , so that none of the Si sets of the phase 1 does not satisfy the given access structure. The challenger randomly draws a value y E {1, 0} and digit mY under A* by running the EncryptCons algorithms and

• Phase 2: Phase 1 is repeated provided that no set of attributes selected Sj does not satisfy the access structure provided as a challenge.
• Guess: The adversary must decide which of the two messages has been encrypted, he generates an estimate y ' Of y.
System for preserving privacy based on Blockchain
In our work, the management of access control messages is done with a Blockchain, a decentralized solution to overcome the critical problem of the uniqueness of the point of failure (in terms of trust). Fine-grained access control and storage security are achieved through a new encryption scheme based on attributes combined with cloud computing (FCCP-ABE). In this section we describe the design based on the Blockchain paradigm.
Modeling of the blockchain access authorization register (RA2-Blockchain)
The Blockchain is used as a distributed, persistent and tamper-proof database to manage access control messages. In addition, one of the advantages of using the Blockchain is to provide a solution for the revocation of access rights. Before describing our system, we present our access authorization record on the Blockchain in the form of a token, called a token, representing a pseudo cryptocurrency. token (idx, @ st, @ rq, @do): is an identification data structure used to specify an authorization by the owner of the Blockchain @do address (and who sign this token) so that the owner of the @rq address can access stored data in @st (Blockchain address of the storage provider) and identified by the index idx. We also define an applicable digital asset, denoted idx, which represents an index to identify a recording in the Cloud. In addition, the attachment of this value to a Blockchain address of the owner of the @do data in the Blockchain, will record the ownership of the data immutable. The generation of the idx is done by calculating the hash of a sequence of bits. For our system, idx = Hash (CTone) Where CTone is the intermediate cipher text.
We also define the following two transactions for our Blockchain:
1. idxGenT rans (idx, @st, @src, @do): is the source transaction which generates objects idx. Once the idx value is calculated by a proxy (PR) with an address Blockchain @src, the proxy broadcasts this transaction to transfer idx to the account data - owner who has a Blockchain @dst address. The proxy also records a Blockchain @st address corresponding to the data storage service in the Cloud.
2. grantT rans (token (idx, @st, @rq, @do), @src, @dst): This transaction is used to transfer the token of the Blockchain account from one actor to another. In our system, tokens

Requestor (@rq) sends it to the storage provider (@st) which returns it to the data owner (do). This process, as we can see it in Figure 1, guarantees the traceability of the request and the non-duplication of the request, while maintaining a certain anonymity on the Blockchain.
Figure 2 shows the different interactions within the Blockchain. The generation of the idx object is performed by the proxy, which can be a Cloudlet, or any other node deportation (PR). When transferring encrypted data to the cloud, the proxy (PR) computes idx = Hash (CTone) and broadcasts the transaction idxGenT rans (idx, @st, @src, @dst), to each access request approved.
Personal data protection protocol, centered on the data owner with decentralized control and encryption adapted to the environment IoT / Cloud
Our data owner-centric protocol is used to protect its personal data and strengthen its power in the management of its data. The Blockchain is used as a distributed, persistent and tamper-proof database for monitoring and checking the validity of management messages. FCCP-ABE provides access control fine-grained data that can be implemented within limited devices in resources. The following phases of the protocol are illustrated in Figures 3 and 4.
• Phase 1, System initialization: During this step, a parameter security X and a universe of attributes are chosen before executing the procedure Setup (k) is executed to generate the public and private parameters of FCCPABE (Msk, P k). Additionally, Data Source (DS) devices are configured with the symmetric key Ks and Fog-proxy (PR) with P k.
• Phase2, Data recording (See Figure 3): The data source (the device limited in resources), noted DS, encrypts the data:
EncryptCons (data, P k, Ks) —► CTone and transfers CTone to the Fog-proxy (PR) as well as C2 to the Data-Owner. Once received, PR performs
EncryptUncons (CTone, T, P k) —* CTtwo , calculates idx = Hash (CTone) and finally stores the results at the Provider level storage (CLD). At the same time, PR broadcasts the transaction idxGenT rans (idx, @CLD, @P R, @DO).
• Phase 3, Access authorization: When a user requests data from the Data-owner DO,
he first authenticates himself to the DO itself with its whole S attributes. It uses a PKI
or any other authentication technique, even face to face (during a medical visit, for
example). If this authentication step is successfully completed, DO executes the
Key Gen algorithm with the parameters correspondents:

and sends this secret key to RQ via a secure channel. Simultaneously, DO generates the token token (idx, @st, @rq, @do) and broadcasts the grantT rans transaction:
grantT rans (token (idx, @st, @rq, @do), @do, @rq).
When this transaction is approved by the Blockchain, it means that DO authorizes RQ to access data identified by idx and stored in CLD.
• Phase 4, Data access: When RQ receives authorization to access data (phase 3), it broadcasts a grantT rans transaction (token, @rq, @st) to transfer the token (idx, @st, @rq, @do) to the storage service (the Cloud), having the address Blockchain @st. The Cloud can then verify that the owner of the @rq address is an entity legitimately authorized to access the data identified by idx. Finally, after RQ proves that it has the secret key associated with the Blockchain address @rq (with a simple nonce-challenge protocol, not detailed here), the Cloud sends the CT two cipher text to RQ and broadcasts the grantT rans transaction in order to return the token to @do and inform him that his data has been accessed. Finally, RQ uses its secret key Ks to retrieve data.
Thus, we first presented our encryption solution based on the attributes, with the possibility of deportation of heavy treatments to the nodes of IT in fog. Then we integrated this encryption scheme into a protocol, for which the validity of exchanges is checked via the Blockchain. The Blockchain allows secure exchanges in a decentralized manner and ensures the anonymity of trades.

1. Typically, the ABE usage model considers a data source (DS), which produces and encrypts data, a consumer data (RQ) that receives the data and decrypts it, and finally a trusted authority (TA) responsible for the management of keys and attributes. Hence an architecture including an entity for outsourcing certain process, operations, rated (PR) for proxy. In a real situation, these entities will be instantiated by Fog computing technologies.
2. In our work, the management of access control messages is done with a Blockchain, a decentralized solution to overcome the critical problem of the uniqueness of the point of failure (in terms of trust). Fine-grained access control and storage security are achieved through a new encryption scheme based on attributes combined with cloud computing (FCCP-ABE). In this section we describe the design based on the RA2 Blockchain paradigm to access authorization register.
3. Modeling of the blockchain access authorization register (RA2-Blockchain) of claim 2 define the following two transactions for our Blockchain:
idxGenT rans (idx, @st, @src, @do) grantT rans (token (idx, @st, @rq, @do), @src, @dst)
Personal data protection protocol, centered on the data owner with decentralized control and encryption adapted to the environment IoT / Cloud
4. Our data owner-centric protocol is used to protect its personal data and strengthen
its power in the management of its data. The Blockchain is used as a distributed,
persistent and tamper-proof database for monitoring and checking the validity of
management messages. FCCP-ABE provides access control fine-grained data that can
be implemented within limited devices in resources. The following phases of the
protocol are illustrated in Figures 3 and 4.
• Phase 1, System initialization
• Phase2, Data recording
• Phase 3, Access authorization
5. In Phase 1, System initialization of claim 4, a parameter security A and a universe of
attributes are chosen before executing the procedure Setup (A) is executed to
generate the public and private parameters of FCCPABE (Msk, P k). Additionally,

Data Source (DS) devices are configured with the symmetric key Ks and Fog-proxy (PR) with P k.
6. In Phase2, Data recording (See Figure 3) of claim 4, the data source, noted DS,
encrypts the data:
• EncryptCons (data, P k, Ks) -> CTone and transfers CTone to the Fog-proxy (PR) as well as C2 to the Data-Owner. Once received, PR performs
• EncryptUncons (CTone, x, P k) -> CTtwo , calculates idx = Hash (CTone) and finally stores the results at the Provider level storage (CLD). At the same time, PR broadcasts the transaction idxGenT rans (idx, @CLD, @P R, @DO).
7. In Phase 3, Access authorization of claim 4, when a user requests data from the Data-
owner DO, he first authenticates himself to the DO itself with its whole S attributes.
It uses a PKI or any other authentication technique, even face to face (during a
medical visit, for example). If this authentication step is successfully completed, DO
executes the KeyGen algorithm with the parameters correspondents: