RITAS: Services for Randomized Intrusion

kindlyminnowΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

69 εμφανίσεις

RITAS: Services for Randomized Intrusion

Tolerance

Abstract

Randomized agreement protocols have been around

for more than
two decades. Often assumed to be inefficient

due to their high expected
communication and computation

complexities, they have remained
overlooked by the
community at
-

large as a valid solution for the
deployment of fault
-
tolerant

distributed systems. This paper aims to
demonstrate that randomization

can be a very competitive approach even
in hostile

enviro
nments where arbitrary faults can occur. A stack of

randomized intrusion
-
tolerant protocols is described and its

performance
evaluated under several settings in both LAN

and WAN environments.
The stack provides a set of relevant

services ranging from basic

communication primitives up through

atomic broadcast. The
experimental evaluation shows that the

protocols are efficient, especially
in LAN environments where

no performance reduction is observed
under certain Byzantine

faults.







Architecture


Existing System

Intrusion into a part of the system should give access only to non
-
significant information
,

intrusion
-
tolerant distributed systems, there is an
essential problem:
consensus

Existing Protocols only
Behavior
-
based (or
anomaly detection)
systems

Knowledge
-
based (or misuse detection)
systems
.


Proposed System

This paper describes the implementation of a stack of

randomized
intrusion
-
tolerant protocols and evaluates their

performance under
different fault loads. One of the main

purposes is t
o show that
randomization can be efficient and

should be regarded as a valid solution
for practical intrusion

tolerant

distributed systems.


The paper has two main contributions: (1) it presents the

design and
implementation of a stack of randomized
intrusion

tolerant

protocols,
discussing several optimizations


to the

best of our knowledge, the
implementation of a stack with

the four structural properties above is
novel; (2) it provides a

detailed evaluation of RITAS in both LAN and
WAN settings,

sh
owing that it has interesting latency and throughput
values.


Randomization is only one of the techniques that can be

used to
circumvent the FLP impossibility result. Other techniques

include failure
detectors
,
partial synchrony

and
distributed wormholes
.
Some of

these
techniques have been employed in the past to build other

intrusion
-
tolerant protocol suites.


Modules

1. RITAS
Intrusion Tolerance




T
he notion of handling


react, counteract, recover, mask


a
wide set of faults encompassing intentional and malicious faults
(intrusions), which may lead to failure of the system security
properties if nothing is done to counter their effect on the system
s
tate



I
nstead of trying to prevent every single intrusion, these are
allowed, but tolerated



T
he system has the means to trigger mechanisms that prevent the
intrusion from generating a system failure


Intrusion Tolerance Methods




Theft of privilege:



an
unauthorised increase in privilege, i.e., a change in the
privilege of a user that is not permitted by the system’s
security policy



Abuse of privilege:



a misfeasance, i.e., an improper use of authorised operations



Usurpation of identity:



impersonation
of a subject
a
by a subject
i
, who with that
usurps
a
’s privilege


2.

Single
-
threaded and
multi
-
threaded approach
Operation



Multi
-
threaded

protocol stack, every instance of

a specific protocol is
handled by a separate thread. Usually,

there is a
pivotal thread that reads
messages from the network

and instantiates protocol threads to handle
messages that are

specific to them. Another option is to avoid the pivotal
thread,

and have the protocol threads reading messages directly from

the
network.


Th
e multi
-
threaded approach may be simpler to implement

since each
context is self
-
contained in a given thread, and

there is virtually no need
for protocol demultiplexing since

messages can be addressed directly to
the threads handling

them. This leads to a
cleaner implementation (i.e.,
more

verbatim translations from pseudocode) because the protocol

code
has only to deal with one protocol instance (the context

is implicit).
Nevertheless, in a loaded system, with potentially

several hundreds of
threads, the c
onstant context switching and

synchronization between
threads poses a serious performance

impact on the stack, and may
provoke an unfair internal

scheduling.


3. Control Blocks and Protocol Handlers


The protocol handler is the set of functions that
implement

the operation
of the protocol. It is formed by initialization

and destruction functions,
input and output functions, and

one or more functions that export the
protocol functionality.

The purpose of the initialization and destruction
functions is,

respectively, to allocate a new control block and initialize
all

its variables and data structures, and to destroy the internal data

structures and the control block itself. The input and output

functions are
used for inter
-
protocol
communication

and both

receive as parameters
the r
espective control block and
to be processed.


4. Rabin
-
style approach,


A

Rabin
-
style approach, and

in practice terminates in

one or two
communication steps
.

The protocols, however, depend heavily on
public
-
key cryptography

primitives like digital and threshold signatures.
The

implementation of the stack is in Java and uses several threads.

RITAS uses a different approach, Ben
-
Or
-
style, and resorts

only to fast
cryptographic operations such as hash functions.

Randomization is

only
one of the techniques that can be

used to circumvent the FLP
impossibility result. Other techniques

include failure
detectors
,
partial
synchrony

and
distributed wormholes
. Some of

these techniques have
been employed in the past to build other

intrusi
on
-
tolerant protocol
suites.


Software Requirements:



Hardware Requirement:





Minimum 1.1 GHz PROCESSOR should be on the computer.



128 MB RAM.



20 GB HDD.



1.44 MB FDD.



52x CD
-
ROM Drive.



MONITORS at 800x600 minimum resolution at 256 colors
minimum.



I/O, One or two button mouse and standard 101
-
key keyboard.




Software Requirement:




Operating System :

Windows 95/98/2000/NT4.0.




Technology


: JAVA, JFC(Swing)




Development IDE : Eclipse 3.x