Articulo IEEE
Articulo IEEE
Articulo IEEE
RESUMEN A lo largo de los años y conforme avanza la tecnología hemos visto como dos grandes empresas como lo son
Linux y Windows dominan en parte el mercado de los sistemas operativos y que han ido adaptándose a las necesidades del
consumidor conforme avanzan los tiempo y aún más con la revolución Industria 4.0 se refiere a la cuarta revolución industrial,
con las tres primeras marcadas por la mecanización, la electricidad y las tecnologías de la información, donde cada día es más
importante el uso de las nuevas tecnologías y aumenta la necesidad de contar con sistemas operativos eficientes, autónomos,
agiles que permitan desarrollar las labores cotidianas de forma ágil y sencilla.
Por esta razón en el presente articulo veremos algunas de las opciones de sistemas operativos más recientes de estas
empresas, los beneficios que nos brindan, sus cualidades y atributos.
Con el fin de ser una fuente de información que nos permita encontrar el sistema operativo adecuado a nuestras necesidades.
El desarrollo de sistemas operativos es una actividad que combina diferentes disciplinas, como las matemáticas, la informática
y principalmente la automatización. El importante papel del software libre en la definición de muchas de las herramientas que
usamos hoy en día es el tema central del desarrollo informático actual. El propósito de este trabajo es describir brevemente las
últimas tecnologías para construir diferentes tipos de sistemas operativos y evaluar el uso de una tecnología que ha demostrado
tener una aplicabilidad importante: el desarrollo personalizado. Finalmente, se presentó un caso de estudio en el que se
evaluaron los resultados obtenidos por la aplicación Buildroot para la implementación de la investigación.
ABSTRACT Over the years and as technology advances we have seen how two major companies such as Linux and
Windows dominate part of the operating systems market and have been adapting to consumer needs as time goes by and even
more with the revolution Industry 4. 0 refers to the fourth industrial revolution, with the first three marked by mechanization,
electricity and information technologies, where every day is more important the use of new technologies and increases the need
for efficient, autonomous, agile operating systems that allow to develop daily tasks in an agile and simple way.
For this reason in this article we will see some of the most recent options of operating systems of these companies, the
benefits they offer us, their qualities and attributes.
In order to be a source of information that allows us to find the right operating system for our needs.
The development of operating systems is an activity that combines different disciplines, such as mathematics, computer
science and mainly automation. The important role of free software in the definition of many of the tools we use today is the
central theme of current computer development. The purpose of this paper is to briefly describe the latest technologies for
building different types of operating systems and to evaluate the use of a technology that has shown significant applicability:
custom development. Finally, a case study was presented in which the results obtained by the Buildroot application for the
implementation of the research were evaluated.
INDEX TERMS Ubuntu, Linux, Operating System, Windows, Scripting Languages, Server.
III. PRELIMINARIES
In this section, we formally define the preliminaries used
in our blockchain-based data sharing system among
untrusted parties. We highlight the blockchain network
with side- blocks as part of individual components in addition
to triggers put in place to achieve the system. A brief
outline on the
supposed behavior of cryptographic behavior required for the to execute specified tasks relating to the security of a
system is further described. framework. For the blockchain-based data sharing scheme,
A. BLOCKCHAIN NETWORK
The blockchain is a distributed database that contains an
ordered list of records linked together through chains,
on blocks. Blocks can be defined as individual components
that contain information relating to a particular transaction.
An example of such information can be a log on a single
event (requestor needing data from the system). A blockchain
network maintains a continuous growing list of records which
are immutable. Due to this reason, many systems built on
the blockchain technology achieve secured distribution of
assets among untrusted clients.
For our data sharing among untrusted parties’ system,
the processing and consensus nodes are entirely responsible
for broadcasting blocks into the blockchain network after
processing requests. Forms generated per request are devel-
oped into blocks and later broadcast during the process of
delivering package to a requestor. This action culminates
the completion of a block and permits the broadcast of the
block into the blockchain network. There are multiple threads
of blockchains in the network, identified uniquely using a
requestor’s identity. Threading blocks to their parent blocks
are used to keep a contiguous log of well-ordered logs
devel- oped from requests by different requestors. In
structuring the network this way, we point to the fact that
each block in a particular string represents different
instances of request made. These are indexed and updates by
the smart contracts in a particular child-block are appended
to the parent block as a side-block. The importance of
implementing side-blocks is to maintain an effective log and
efficient fetching of blocks with instances on questioning
and investigation for an occurrence of breach of terms by
the data owner to requestor of the data. Side-blocks
appended to their parent blocks contain reports from the smart
contract reports that are indexed thereby main- taining
accuracy on identical reports with violations stored
concurrently in a smart contract permissions database. The
structure of creating multiple threads for our blockchain
net- work and creating side-blocks on parent blocks,
aggregates
to a comprehensive collection of reports.
As mentioned earlier, a block is developed from a form
created from a request. An entire block is made up of a
single request which spans from when it was made till
when the package is ready for delivery. The processing and
consensus node is responsible for the maintenance of the
blocks and blockchain network. As a matter of fact,
processing and consensus nodes are the only entities with
direct access to the blockchain network. Whilst monitoring
the blocks with side-blocks, nodes alert the system on
breaches to the use of data.
B. CRYPTOGRAPHIC KEYS
Cryptographic keys indicate the sets of keys highlighted
we highlight keys needed to achieve confidentiality for updates the process
trans- actions between systems via untrusted channels.
These keys help to guarantee for a level of security of the
scheme.
For our system, there is the need to adopt cryptographic
primitives for secured transfer of query results between
untrusted data sharing parties to prohibit the influence of
malicious individuals and eavesdroppers on a transaction
between the sharing parties. A description on the
primitives and keys that would best suit the system are
enlightened. The keys include:
• Requestor private key, generated by a requestor and
digitally used to sign requests for data access.
• Requestor public key, generated by a requestor and
sent to data owners authenticator to be used as
verification of requestors identity for data access. The
requestors public key is also used to encrypt a package
to be sent to the requestor by the authenticator.
• Authenticator contract key, key pair generated by
authenticator and attached to smart contract in a package
used for encrypting reports that leave the requestor’s
system to data owner’s system.
For a requestor who wants access to set of records from
a data owner, the requestor generates a key pair (Requestor
private and public keys), stores the private key and shares
the public key with the data owner or other data owner the
requestor might access data from in the future. The
requestor creates, sign using the requestor private key and
send a request to a data owner. On reception, the data
owner con- firms the request by verifying the signature with
the requestor public key.
Results on computations on data requested are tagged on
the data and further processed by data owner by
appropriate entities in the data owner’s system. The data
owner encrypts the whole package (final processed data
to be delivered to requestor) with an authenticator
contract key and shares the package with the requestor. On
reception, the requestor decrypts the encrypted package
and uses the data.
To adequately secure the transfer of actions performed
on the data from the requestor to the data owner, the
reporting of actions generated from the cryptographic
functions flagged on the data should be encrypted using
the authenticator con- tract key tagged to the contracts
generated from the data orig- inator (owner) which would
be sent to a database a secured database.
C. TRIGGERS
Triggers are entities that connect processes between the query
structure and the blockchain environment. The key impor-
tance of implementing triggers for our system is to enable
smart contracts to directly connect from outside the system
to our system since smart contracts cannot directly interact
with structures outside of its environment, thus the blockchain
network. Triggers hold no information and just act as an
intermediary between the query layer and the data
structuring and provenance layer of the system. The trigger
incorporates interfaces internally and externally and
states to and from the query system by the inbound and out- actions to and from the smart-contract
bound smart contracts based on external and internal environment
features of the contract.
V. CONSTRUCTION OF MEDSHARE
In this section, we present a construction of entities and
functions of components necessary for the secured sharing
of data among untrusted parties. We outline designed struc-
system which aims to provide a suitable sharing scheme requestors.
whilst preserving the required security properties of the
blockchain.
A. DESIGN APPROACH
• System setup:
A user sends a request for data access to a sys-
tem. The data request is signed by the user using a
‘‘pre-generated’’ requestor private key. First of all,
the request is received by the query system an entry
point for recording and processing requests. The query
system forwards the request to the data structuring and
prove- nance layer by the triggers since triggers
translate the query (request) into a structure that can be
understood by the data structuring and provenance
layer. The authenti- cator receives the request and
verifies the legitimacy by verifying the signature
using the requestors public key which was generated
and shared before the request was sent. If the signature
is valid, the process is accepted else dropped for invalid
requests.
• Request file:
For a valid request, the authenticator forwards the
request to the processing and consensus nodes where
processing of requests into forms are completed. The
form generated contains a hash of the timestamp of
when the request was received and a hash of the
ID of the requestor. The purpose for the data request
is tagged to the form and then forwarded to the
existing database infrastructure. The existing database
infrastruc- ture receives the form, retrieves the data
and sends the retrieved data to the data structuring
and provenance layer. This is received by the
processing and consensus node and a hash of this
timestamp is concatenated to the existing record of a
hashed timestamp for the request. The processing and
consensus nodes send a request to the smart contract
center for appending sets of rules to the requested
data. A smart contract is generated and tagged to the
form which contains the data indexed to form some
sort of adjacency with the related block.
• Package delivery:
Results of the processed data are then sent to the
authen- ticator to generate an authenticator contract
key and tag the encryption key of this generated set to
the smart contract on the data. The importance of
tagging the smart contracts to the data is to ensure
data auditing and traceability is achieved. The
processing and consensus node process a block based
on the information relating to the request and
broadcasts the block into a blockchain network. The
block forms a part of already existing blocks in
relations to the requestor and is tagged with an
identity to uniquely identify the different blocks in the
network. This is achieved through chronology and
per- fect ordering. The data is encrypted, forming a
package encrypted, and tagged with the ID of the
requestor. The result is forwarded to the query system
through triggers and is finally distributed to respective
Package refers to a completely processed data file Algorithm 1 Smart Contract on Data
along with certain parameters intended for the requestor.
A package contains a data ID, payload (data) and a Require: Initialization of parameters:
smart contract. A package is created from processing getAction, getSensitivity, getRequestorID, getOwnerID,
on received data from the existing database getDataID, getKey, getMetaIndex, retrieve, encrypt,
infrastructure by the consensus nodes. Monitoring of com- ment, report, accessControl.
the lifeline of a package is made effective by attaching Ensure: Setting up functions:
a smart contract to the package. The completion of a func (getSensitivity)
package is culmi- nated by the authenticator by func (getAction)
encrypting the package into a format which can only func (comment)
be readable by a valid and appropriate requestor with func (accessControl)
the right private key. MONITORING OF PACKAGE:
• Auditing and provenance: for func (getAction) == decrypt do
The requestor receives the package and decrypts the func (comment) ← Potray, Data with DataID has
encrypted file using the requestor private key. To ensure been decrypted.
the efficiency of every computation tagged to the retrieve (getKey)
data (smart contracts), decryption of the data should encrypt (comment)
activate the smart contract to retrieve the encryption report (comment ||getRequestorID |getOwnerID)
key tagged to itself and encrypt an action of decrypted end for |
data which is sent to the query system to appropriately if func (getSensitivity) == Low then
forward the report to the data structuring layer to the func (getAction) ← Exemptions on data.
processing and consensus node. The processing and con- ignore
sensus node processes the report into a side-block and else if func (getSensitivity) == Low then
appends the result to the parent block pertaining to that func (getAction) ← Not exemptions on data (violation).
particular data request as part of traces on actions for func (comment) ← Data violation concatenated with
the data. The received report is sent to activate DataID
violation actions that can be applied to the received func (accessControl) ← Revokes access to data.
data from the data owner’s system executed by the retrieve (getKey)
requestor. Success in the acquisition of a report named encrypt (comment)
decrypted data portrays the ability of every action report (comment ||getRequestorID |getOwnerID)
being performed on the data to activate a condition else {func (getSensitivity)
| == High}
specified in the smart contract which generates a func (getAction) ← Violation.
comment to be encrypted and sent to the data owner’s func (comment) ← Data violation concatenated with
system by the smart con- tract. This property is used to DataID
effectively check for data auditability. Again, we stress func (accessControl) ← Revokes access to data.
on the fact that a side- block is created on the parent retrieve (getKey)
block that records actions pertaining to the data encrypt (comment)
reported by the smart contract into the blockchain report (comment ||getRequestorID |getOwnerID)
network. These are all indexed along with the data end if |
stored in the smart contract permissions database.
B. SMART CONTRACTS
Smart contract acts as a finite state machine executing laid We initialize sets of actions that can be applicable to any
down instructions when an action has been activated based on form of data retrieved from the data owner’s system. The
an instance. In this work, we employ smart contracts to basic action sets are read, write, delete, duplicate, move and
report actions completed by a requestor on a data requested copy. These sets of actions when performed on the data would
from a data owner’s system. These enable data owners to trigger the smart contracts to send a report based on the
completely gain assurance and control on data provenance rules established for that particular data. Monitoring of
since the entire lifeline of the sent data would be monitored actions are conveyed in smart contract scripts by a function
in a controlled in a trustworthy environment where the data getAction.
owner needs no assurance of trust from the requestor. The sensitivity of the data is categorized into two lev-
Data reported to the data owner’s system are processed, els which are high and low. These levels of sensitivity are
indexed and broadcast into a blockchain network. In some derived from processing by consensus nodes based on data
instances, reports are reported and stored in a smart contract sets acquired from the database infrastructure. Based on the
permissioned database and indexed based on the data ID of sensitivity of a package, certain actions performed in the
the requested and used data where sets of actions from the data are either exempted from the violations list or serve as
data owner are applicable on the data used by the requestor. violations. For low sensitive level for a data, the data
owner, based on the requested data, can modify the smart
contracts
to ignore actions to avoid reporting of extraneous data from data to the consensus node. The consensus node receives the
being stored. For data with high sensitivity level, the smart duplicated data and creates a package out of it. The package
contract is required to report all actions categorized in the
initialization of getAction to effectively monitor operations
performed on the data, ensuring the detection of breaches
on data. Identities necessary to facilitate the efficient
identifica- tion of unique blocks are classified for a requestor,
data owner and the particular data sent. The advantage of
specifying these in the smart contracts is to create an
efficient means for processing and consensus nodes to
match, process and verify specific blocks. Comments are
generated as statements to describe the actions that were
performed on the data. These are usually violation and
exemption comments. A retrieve statement is paired with a
getAction statement to extract an encryption key to encrypt
comments that would be reported to the data owner’s smart
contract database. An action on encrypt is called to finalize
this process. The action of sending the comments to
processing and consensus nodes is instan- tiated by the
report statement in the smart contract script. The function
accessControl signifies the permissions set by the data
owner that would be carried out in conjunction with the
smart contract permissioned database. On violating the data
contract, access to the data is revoked and pending review
by the data owner who has the choice to re-grant access or
retrieve data back from the requestor.
Embedding statements executable on the reception and
usage of the data by requestor as an assurance of efficient
operation of a smart contract is deemed important. As a matter
of fact, a decryption function activated to generate a report
on decryption of a package will be evident in smart contract
scripts, validating the workability of the smart contract.
Smart contracts on reception of violations revoke the
access of the data for the requestor and sends a report
which is pro- cessed accordingly and permits data owner to
deal with such violations by choice through the smart
contract permissions database. Figure 2 is a brief
description of smart contracts as a finite state machine.
E. SIDE-BLOCK STRUCTURE
A side block is made up of a format which is derived by
appending a section of the main blocks ID to a
generated ID by consensus node to the side block. This
is followed by the block size which contains the entire size
of the side block. Side blocks also have headers which are
made up of six components. These are the version number
which uniquely identifies the reports used to create the
side block, previous side block hash, merkle root of all
side blocks for a particular parent block, timestamp, target
difference and a nonce. These components have same
properties as their parent block but relates to side blocks.
The side block has an action counter whose function is
to record the violations recorded on a single report.
Preceding the action counter is the transaction which is
made up of the timestamp of violation (TSV), data owner
identity (OID), requestor identity (RID), violation (VLN),
processing node identity (NID) and signature of processing
node (Nsig). The block is timelocked and broadcast unto
the blockchain by appending it to the parent block. Traces
of the report and the data can now be traced. Figure 5
describes structure of the side block.
FIGURE 5. Structure of Side-Block.
VI. DISCUSSION increase as request per cloud service provider increases. This
This section evaluates the performance of implementing our is due to the trade of between achieving security over low
system on real-case scenarios where cloud service providers latency. The tuple size and pro- cessing and anonymisation
share data among other cloud providers. Monitoring of of data contribute to the increase in latency however,
action applicable on data and data revocation on instances efficiency is achieved in MedShare.
of breaches are implemented as smart contracts in solidity. Table 2 below compares our MeDShare system to other
Algorithm 1 describes the formulation of a smart contract. existing systems and literature presented in this paper.
In simulating interactions on a cloud service provider,
access policies stored as records in blocks and the
permissions database assigns different permissions to users
for available services (access to specific data). Analysis on
request of data, data retrieval and processing (includes the
generating of smart contracts and tagging of smart contracts
on package) and monitoring of actions on data is completed
by using JMeter. Number of active requestors between 5 and
100 users for periods of 2 minutes, 5 minutes, 8 minutes,
10 minutes,
20 minutes and 30 minutes are achieved using JMeter.
Vulnerabilities in MedShare are detected via access control
violations on accessed data which serves as threats to the
MedShare system. Vulnerability analysis is achieved if
Med- Share can detect any inconsistencies and violations
under substantial amounts of usage load. The algorithms in
Med- Share should be able to detect all attacks based on the
number of users thus, number of simulated attacks
corresponds to the number of users simulated in MedShare
data request.
Latency in MedShare has been evaluated by analysing
the time taken to deliver a package after a request has been
sent. This includes all steps required to process a request by
all entities in the MedShare system. The latency for
MedShare is represented in table 1 and Figure 6. An
important observation on the latency is its considerable
With the various metrics derived from the carefully
analogy of data usage and data accumulation, a conclusion
can be drawn that MedShare as compared to the systems
presented has greater advantages.
VII. CONCLUSION
Data sharing and collaboration via cloud service
providers is a stronghold with the increasing advancement
of modern technologies driving today’s society. The
demand of pattern recognition and big data analysis forms
a key component in this advancement as new remedies are
developed from the analysis of medical data. Several
methods and mechanisms have been put in place to
regulate the flow of data from point(s) to point(s) as
medical data in the hands of malicious entities can cause
severe unthinkable damages on all parties related directly
or indirectly to the data.
In this paper we design a data sharing model between
cloud service providers using the blockchain. The design
employs the use of smart contracts and an access control
mechanism to effectively trace the behaviour of the data as
well as revoke access to violated rules and permissions on
data. We analyse the performance of our system as well as
compare with current cutting-edge solutions to data
sharing among cloud service providers. By implementing
the pro- posed model, cloud service providers will be able
to securely achieve data provenance and auditing whilst
sharing medical data among other cloud service providers
as well as entities such as research and medical institutions
without any risk on data privacy.
REFERENCES science from the Kwame Nkrumah
University of Science and Technology,
Bijker, W., Hughes, T., y Pinch, T. 1987. The Social Ghana, in 2014. He is currently
Construction of Technological Systems: New pursuing the mas- ter’s degree in
Directions in the Sociology and History of computer science and technology with
Technology. MIT Press, Cambridge. the University of Science and
Pinch, T. 1997. La construcción social de la Technology of China. His current
tecnología: una revisión. Innovación tecnológica y research includes blockchain
technology and big data security.
procesos culturales: Nuevas perspectivas teóricas, 20–
38. Universidad Autónoma de México - Fondo de
Cultura Económica, México.
JIANBIN GAO received the Ph.D.
degree in computer science from the
University of Elec- tronic Science and
Technology of China (UESTC) in
2012. He was a Visiting Scholar with
the Uni- versity of Pennsylvania,
QI XIA received the B.Sc., M.Sc., and Philadelphia, PA, USA, from 2009 to
Ph.D. degrees in computer science 2011. He is currently an Associate
from the Univer- sity of Electronic Professor with UESTC.
Science and Technology of China
(UESTC) in 2002, 2006, and 2010,
respec- tively. She was a Visiting
Scholar with the Uni- versity of
Pennsylvania, Philadelphia, PA, USA,
from 2013 to 2014 and has published
over twenty papers. She is the PI of
the National Key Research and
Development Program of China in
Cyber Security. She is the Vice Dean
of the Center for
Cyber Security and currently an Associate Professor with
UESTC. She won the National Scientific and
Technological Progress Second Prize in 2012.