Improvised Intrusion Tolerant Systems Computer Science Essay

Published Date: 02 Nov 2017

Yousuf Syed, Department Of Computer Engineering, MIT AOE, University of Pune, India.

Guide: Ms.Rachana Nemade, Professor MIT AOE.

ABSTRACT

In this paper byzantine fault-tolerant state machine

replication algorithm, improvising previous algorithm

in terms of several metrics is presented i.e

BftPlus.For understanding purpose, lets breat this

Into three simpler points First it requires only 2f+1

replicas, instead of the usual 3f+1.Secondly,the

trusted service in which this reduction of replicas is

based is quite simple, making a verified implementa-

tion straightforward.Third,in nice executions the algo-

rithm runs in the minimum number of communication

steps for non-speculative and speculative algorithm,

respectively four and three steps. Also we have the

obvious benefits in terms of cost, resilience and man-

agement complexity-fewer replicas to tolerate a certain

number of faults, this algorithm is significantly simpler

than the previous ones, being closer to crash fault-

tolerant replication algorithms.

1 INTRODUCTION

The complexity and extensibility of current computer sys-

tems have been causing a plague of exploitable software

bugs and configuration mistakes,putting computer security

at grave risk.To counter this challenge,asynchronous byzan-

tine fault-tolerant algorithms have been proposed,these al-

gorithms automatically allow systems to continue operating

correctly, even if some of its components exhibit arbitrary,

possibly malicious beahaviour.

This paper presents a novel BftPlus algorithm.Its nov-

elty comes from these algorithms improving previous ones

in terms of three metrics:number of replicas, trusted service

simplicity, and number of communication steps. This algo-

rithm is efficient, in this sense that they are equal to or better

previous algorithms in terms of these metrics.

Number of replicas. BFT algorithms require typically

3f+1 servers to tolerate f byzantine servers.They are based

on the idea that correct replicas can overcome faulty repli-

cas in a sequence of votes and for this to happen, they

would need atleast f+1 correct replicas,in a total of 2+1 repli-

cas.however this algorithm requires only f more servers than

the minimum.

Trusted service simplicity. This algorithm requires that

the system is enhanced with a tamperproof distributed com-

ponent called trusted timely computing base(TTCB),it pro-

vides an ordering service used to implement an atomic mul-

ticast protocol that is the core of the application scheme.

Number of communication steps.The dealy in com-

munication tends to have a major impact on the latency of

the algorithm,hence its an important metric. To tolerate dis-

asters and large scale attacks such as Dos-based denial of

services(DDOS), replicas have to deployed at different sites.

BftPlus follows a similar messsage exchange pattern as fol-

lowed by the PBFT.

This is a significant part where replicas move through

succession of configurations called views.Each view has a

primary replica and the others are back-ups.

2 USIG SERVICE

The USIG service stands for Unique Identifier Genera-

tor(USIG),it is basically a local service that exists in every

server. Its function is to assign to messages(i.e arrays of

bytes) the value of a counter and sign it. Identifiers are

unique, monotonic, and sequential for that server. These

three properties imply that the USIG

1)It will never assign the same identifier to two different

messages(Uniqueness).

2)It will never assign an identifier that is lower than the

previous one(Monotonicity).

3)it will never assign an identifier that is not the successor

of the previous one(sequnetiality).

The above three properties are guaranteed even if the

server is compromised, so the service has to be imple-

mented in a tamperproof module.

This interface of the service has two significant functions:

• CreateUI(m)

Consider any message m, for this message m CreateUI re-

turns a unique identifier UI and certifies that this UI was cre-

ated by this tamperproof component for the message m. The

unique identifier is essentially a reading of the monotonic

counter, which is incremented whenever CreateUI is called.

• VerifyUI(PK,UI,m)

this function does nothing but basically just verifies if the

unique identifier UI is valid for message m.

i.e if the USIG certificate matches the message and the

reset of the data inUI.

To implement this service,there are two basic options

depending on the certificate being based on cryptographic

hashes or public-key cryptography:

1

2.1 USIG-Hmac

Hmac stands for Hash-based message authentication

code(Hmac), which is obtained using the message and a se-

cret key owned by this USIG but known by all the others, for

them to be able to verify the certificates generated.

2.2 USIG-Sign

The certificate contains a signature obtained using the mes-

sage and the private key of this USIG.

Firstly discussing about USIG-Hmac, the properties of the

service (e.g.,Uniqueness) are based on the secretness of

the shared keys,while in USIG-Sign the properties are based

on the secretness of the private keys. Therefore , while for

USIG-Hmac both functions CreateUI and VerifyUI must be

implemented inside the tamperproof component, for USIG-

Sign the verification requires only the public-key of the USIG

that created the certificate, so this operation can be done

outside of the component.in both the cases keys have to be

shared for the verification to be done in servers other than

the one where createUI was called.The implementation of

this service is very specifically based on an isolated, tamper-

proof component that is assumed that it cannot be corrupted.

This component contains essentially a counter and either an

HMAC primitive(for USIG-Hmac) or a digital signature primi-

tive(for USIG-Sign).

3 BFTPLUS

This Section presents BftPlus, the non speculative 2f+1 BFT

algorithm. BftPlus follows a message exchange pattern sim-

ilar to PBFT’s (refer figure).

The servers move through successive configurations

called views. Each view has a primary replica and the rest

are back-ups. The primary is the server Sp with p=v mod n,

where v is the current view number. Clients issue requests

with operations.

In the event of a normal case operation, the sequence is

observed:-

1) At the start, client sends a request to all the servers;

2) Now, here the primary assigns a sequence number

(execution order number) to the request and sends it to all

servers in a PREPARE message;

3) Each server multicasts a COMMIT message to other

services when it receives a PREPARE message from the pri-

mary;

4) when a server accepts a request, it executes the cor-

responding operation and returns a reply to the client ; and

5) the client waits for f+1 matching replies for the request

and completes the operation.

When these f+1 servers or backups suspect that the pri-

mary is faulty, view change operation is executed, and a new

server S’p with p=v’ mod n becomes the primary(v’ >v is

the new view number). This mechanism provides liveness

by allowing the system to make progress when the primary

is faulty.

Figure 1: Number of communication steps

3.1 Clients

A client c makes a request for execution of an operation op

by sending the message (REQUEST, c, seq, op) sigma c to

all servers where seq is the request identifier that is used to

ensure exactly one semantics: 1) The servers store in a vec-

tor Vreq the sequence of the latest request they executed

for each client;2) Requests with seq lower than the latest

executed are discarded and any request received while the

previous one is being executed. Requests are signed with

private key of the client,those with invalid signatures are dis-

carded. A client waits for f+1 replies (REPLY,s,seq,res) from

different servers s with matching results res ,which ensures

that at least one reply comes from the correct server. In an

event when the client doesn’t receive enough correct replies

during the time interval read in its local clock, requests are

retransmitted. If the requested request has already been pro-

cessed then the servers resend the cached reply.

3.2 Servers-Normal case Operation

The processing of the PREPARE and COMMIT messages is

the core of the algorithm executed by the servers. BftPlus

comprises of only two communications steps: 1)primary re-

ceives client request, it uses a PREPARE message to multi-

cast the request to all servers. The main role that the primary

plays is of assigning a sequence number to each request,

which is the counter value returned by the USIG service in

the UI. When the primary does not change, these numbers

are sequential but this changes in the event of a view change

which is discussed later in this paper.

The basic idea is that a request m is sent by the primary

Si to all servers in a message (COMMIT,v,Sj,Si,m,UIi,UIj),

where UIj is obtained by calling the CreateUI function. Each

2

message sent, whether it is COMMIT or PREPARE message

has a UI, so no two messages can have a same identifier.

Servers check these identifiers if they are valid or invalid

for the messages received using verifyUI function. If some

backup server Sk did not receive a PREPARE message but

received a commit message with a valid UI generated by the

sender, then it sends its commit message. This can happen

if the sender is faulty and does not send the PREPARE mes-

sage to server Sk (but sends it to other servers) or if the pre-

pare message is simply late and is received after the commit

message. A requests m is accepted by a server following the

algorithm if the server receives f+1 valid COMMIT messages

from different servers for m.

A correct server Sj multicasts a commit message in re-

sponse to message (PREPARE,v,s,m,UIi) only if three addi-

tional conditions are satisfied:1)v is the correct view number

on Sj and the sender of the PREPARE message is the pri-

mary of v; 2) The request m contains a valid signature pro-

duced by requesting the client (to prevent a faulty primary

from forging requests) ; and 3) Sj already accepted request

m’ with counter value cv’=cv-1, where cv is the counter value

in UI (to prevent a faulty primary from creating holes in the

sequence of messages). This last condition ensures that not

only the requests are executed in the order defined by the

counter of the primary, but also that they are accepted in

the same order. Therefore when the request is accepted, it

can be executed immediately (there is never the necessity of

waiting for requests with lower numbers ). The only exception

is that if the server is faulty it can "order" the same request

is twice. So when a server accepts a request, it firsts checks

in Vreq if the request was already executed and executes it

only if not.

3.3 Servers:Garbage Collection And Checkpoints

Messages sent by a server are kept in a message log in

case they have to be resent. To discard messages from this

log, BftPlus uses a garbage collection mechanism based on

checkpoints, similar to PBFT’s.

Servers generate checkpoints periodically when a re-

quest sequence number (the counter value in the UI pro-

duced by the primary) is divisible by the constant cp (check-

point period). After the server sj produces the checkpoint it

multicasts (CHECKPOINT; sj; UIlatest; d; UIj) where UIlat-

est is the unique identifier of the latest executed request, d is

the hash of the server’s state and UIj is obtained by calling

createUI for the checkpoint message itself. A server consid-

anism is for a single view. When there is a view change, a

new checkpoint is generated and the log is cleaned.

3.4 Servers view change operation

In normal case operation, the primary assigns sequence

numbers to the requests it receives and multicasts these

numbers to the backups using PREPARE messages. This

algorithm strongly constrains what a faulty primary can do:

it cannot repeat or assign arbitrarily higher sequence num-

bers. However, a faulty primary can still prevent progress by

not assigning sequence numbers to some requests, or even

to any requests at all. When the primary is faulty, a view

change has to be executed and a new primary chosen. View

changes are triggered by timeout. When a backup receives

a request from a client, it starts a timer that expires after

Texec. When the request is accepted, the timer is stopped.

If the timer expires, the backup suspects that the primary is

faulty and starts a view change.

When a timer in backup si times out, si sends a message

(REQVIEW- CHANGE; si; v; v’) to all servers, where v is

the current view number and v’=v+1the new view number.

When a server si receives f+1 REQ-VIEW-CHANGE mes-

sages, it moves to view v+1 and multicasts (VIEWCHANGE;

si; v’; Clatest;O; UIi), where Clatest is the latest stable check-

point certificate andOis a set of all messages sent by the

replica since the latest checkpoint was generated (PRE-

PARE, COMMIT, VIEW-CHANGE and NEW-VIEW mes-

sages). At this point, that replica stops accepting messages

for v. The VIEW-CHANGE message takes a unique identifier

UIi obtained by calling createUI. The objective is to prevent

faulty servers from sending different VIEW-CHANGE mes-

sages with different Clatest and O to different subsets of the

servers, leading to different decisions on which was the last

request of the previous view. Faulty servers still can do it, but

they have to assign different UI identifiers to these different

messages, which will be processed in order by the correct

servers, so all will take the same decision on the last request

of the previous view.

Correct servers only consider (VIEWCHANGE; si; v’;

Clatest;O; UIi) messages that are consistent with the sys-

tem state: 1) the checkpoint certificate Clatest contains at

least f+1 validUI identifiers; 2) the counter value (cvi) in UIi

is cvi=cv+1, where cv is the highest counter value of the

UIs signed by the replica in O; if O is empty the highest

counter value will be the UI in Clatest signed by the replica

when it generated the checkpoint; and 3) there are no holes

ers that a checkpoint is stable when it receives f+1 CHECK- in the sequence number of messages in O. When the new

POINT messages signed by different replicas with the same

UIlatest and d. We call this set of messages a checkpoint

certificate, which proves that the server’s state was correct

until that request execution. Therefore, the replica can dis-

card all entries in its log with sequence number less than the

counter value of UIlatest. The checkpoint is used to limit the

number of messages in the log. We use two limiters: The

low water mark (h) and the high water mark (H). The low wa-

ter mark is the sequence number of the latest stable check-

point. Replicas discard received messages with the counter

primary for view v0 receives f+1 VIEWCHANGE messages

from different servers, it stores them in a set Vvc, which is the

new-view certificate. Vvc must contain all requests accepted

since the previous checkpoint, and can also include requests

that only were prepared. In order to define the initial state for

v0, the primary of this view uses the information in the Clat-

est and O fields in the VIEWCHANGE messages to define

S, which is the set of requests that were prepared/accepted

since the checkpoint. To compute S, the primary starts by

selecting the most recent (valid) checkpoint certificate re-

value less than h. The high water mark is H=h+L where L ceived in VIEW-CHANGE messages. Next, it picks in VIEW-

is the maximum size of the log. Replicas discard received

messages with the counter value greater than H. This mech-

CHANGE messages the requests in O sets with UI counter

values greater than the UI counter value in the checkpoint

3

certificate.

After this computation, the primary multicasts a message

(NEW-VIEW; si; v’; Vvc; S; UIi). When a replica receives a

NEW-VIEW message, it verifies if the new-view certificate is

valid. All replicas also verify if S was computed properly do-

ing the same computation as the primary. A replica begins

the new view v’ after all requests in S that have not been ex-

ecuted before are executed. If a replica detects that there

is a hole between the sequence numbers of the latest re-

quest that it executed and of the first request in S, it requests

to other replicas the commit certificates of the missing re-

quests to update its state. If due to the garbage collection

the other replicas have deleted these messages, there is a

state transfer (using the same protocol of PBFT). In previous

BFT algorithms, requests are assigned with sequential ex-

ecution order numbers even when there are view changes.

This is not the case in BftPlus as the sequence numbers are

provided by a different tamperproof component (or USIG ser-

vice) for each view. Therefore, when there is a view change,

the first sequence number for the new view has to be de-

fined. This value is the counter value in the unique identifier

UIi in the NEW-VIEW message plus one. The next PRE-

PARE message sent by the new primary must follow the UIi

in the NEW-VIEW message. When a server sends a VIEW-

CHANGE message, it starts a timer that expires after Tvc

units of time. If the timer expires before the server receives a

valid NEW-VIEW message, it starts another view change for

view v+2. If additional view changes are needed, the timer

is multiplied by two each time, increasing exponentially un-

til a new primary responds. The objective is to avoid timer

expirations forever due to long communication delays.

4 IMPLEMENTATION

I have chosen java for Implementation purpose here.Java

was chosen basically for three reasons. First, I expect that

avoiding bugs and vulnerabilities will be more important than

performance in most of the BFT deployments, and Java of-

fers significant features like sandboxing, type safety, and

memory safety that can make a BFT implementation more

dependable and efficient. The second reason is to improve

the system portability, making it easier to get deployed in dif-

ferent environments. Additionally, we have also used recent

Java features such as nonblocking I/O and the concurrent

API (from packages java.nio and java.util.concurrent). Fi-

nally, we used TCP sockets. Options for implementing the

tamperproof component.Several options have been dis-

cussed in papers about the TTCB and A2M. The TTCB can

be seen as one of the earlier attempts at achieving isolation

between general host services (including operating system)

and a security kernel hosting trustworthy services.A2M is

another such example.

5  CONCLUSION

Bft algorithm typically require 3f+1 servers to tolerate f byzan-

tine servers which involves considerable costs in hardware,

software, and administration. Therefore reducing the num-

ber of replicas has a very important impact on the cost of the

system. It been shown that using a simple trusted service, its

is possible to reduce the number of replcias preserving the

same properties of safety and liveness of traditional BFT al-

gorithms. The BftPlus algorithm is better in terms of number

of replicas, and trusted service used, but also of communi-

cation steps in nice executions.