XCO.T473 サイバーセキュリティ概論 …...2020/05/29 · (issue 2) Mixed System Boundaries 5 Network Router Firewall ual em boundary Physical system boundary encrypted communication

第8回目

XCO.T473 サイバーセキュリティ概論

Xavier DéfagoSchool of Computing

Tokyo Institute of Technology

Intrusion-Tolerant Computer Systems 耐侵入コンピュータシステム

86(51$0(3$66:25'

<latexit sha1_base64="aDu3di/oXBVEY7jBgW6BaMd3Cac=">AAACd3icZVFbaxNBFJ5svdR4S+2jDw6GSvFhL1VR+lRakKIoEUxbaJYwe/YkO3Z2Zp052xiW/BJ/ja/6C/wpvjm5IKY9MPDxndt3vskqJR3F8e9WsHHj5q3bm3fad+/df/Cws/XoxJnaAvbBKGPPMuFQSY19kqTwrLIoykzhaXZxNM+fXqJ10ujPNK0wLcVYy5EEQZ4adl4NvlowOTYFUeX2o2gymYRgjM1DCP08hCIUEH6pIohgmvlJCNFs2OnGYbwIfh0kK9Blq+gNt1rPB7mBukRNoIRz50lcUdoISxIUztqD2mEl4EKM8dxDLUp0abO4b8Z3PJPzkbH+aeIL9v+ORpTOTcvMV5aCCnc1Nyf/5XbWVtHoTdpIXdWEGpabRrXiZPjcLZ5Li0Bq6oEAK71YDoWwAsg7sSb60Kj8rVeXNt/w6N17f5FD8qAUUs9VN8fSirHUhn+QGgrDe9Z8XLu7Wf7ErO3dTa56eR2c7IXJi3Dv08vuweHK5032mD1luyxhr9kBO2Y91mfAvrMf7Cf71foTPAmeBbvL0qC16tlmaxEkfwGef8Df</latexit>

<latexit sha1_base64="aDu3di/oXBVEY7jBgW6BaMd3Cac=">AAACd3icZVFbaxNBFJ5svdR4S+2jDw6GSvFhL1VR+lRakKIoEUxbaJYwe/YkO3Z2Zp052xiW/BJ/ja/6C/wpvjm5IKY9MPDxndt3vskqJR3F8e9WsHHj5q3bm3fad+/df/Cws/XoxJnaAvbBKGPPMuFQSY19kqTwrLIoykzhaXZxNM+fXqJ10ujPNK0wLcVYy5EEQZ4adl4NvlowOTYFUeX2o2gymYRgjM1DCP08hCIUEH6pIohgmvlJCNFs2OnGYbwIfh0kK9Blq+gNt1rPB7mBukRNoIRz50lcUdoISxIUztqD2mEl4EKM8dxDLUp0abO4b8Z3PJPzkbH+aeIL9v+ORpTOTcvMV5aCCnc1Nyf/5XbWVtHoTdpIXdWEGpabRrXiZPjcLZ5Li0Bq6oEAK71YDoWwAsg7sSb60Kj8rVeXNt/w6N17f5FD8qAUUs9VN8fSirHUhn+QGgrDe9Z8XLu7Wf7ErO3dTa56eR2c7IXJi3Dv08vuweHK5032mD1luyxhr9kBO2Y91mfAvrMf7Cf71foTPAmeBbvL0qC16tlmaxEkfwGef8Df</latexit>

https://www.coord.c.titech.ac.jp/c/cybersec

Xavier Défago. 耐侵入コンピュータシステム XCO.T473 サイバーセキュリティ概論. 第8回目

Why Intrusion-Tolerance?

2


Firewall Fallacy

3

NetworkRouter

Firewall“Inside” comfy, safe

86(51$0(3$66:25'

“Outside” threatening


(issue 1) Reverse Proxy

4

NetworkRouter

Firewall

86(51$0(3$66:25'

botnet

attackmonitoring

weak smart plug

registry

query

registereavesdrop

replayReverse Proxy

86(51$0(3$66:25'

admin:admin


(issue 2) Mixed System Boundaries

5

NetworkRouter

Firewall

Actual system boundary

Physical system boundary

encrypted communication

per-device protection


Phases of an Attack

6system boundary

86(51$0(3$66:25'

Attacker

attack

infiltration

86(51$0(3$66:25'

foothold

expansion disruption, tampering

spying

86(51$0(3$66:25'

propagation


Typical Countermeasures

firewall(s)

encryption (net.)

authentication

7system boundary


spying

86(51$0(3$66:25'

propagation

infiltration

86(51$0(3$66:25'

foothold



intrusion detection

8system boundary


spying

86(51$0(3$66:25'

propagation

infiltrationAttacker

86(51$0(3$66:25'


Intrusion Detection

9

infiltration

attacker

inside

recoverydetection

86(51$0(3$66:25'

Detection time is very long!



intrusion detection

long delays meanwhile:

10system boundary


spying

86(51$0(3$66:25'

propagation


86(51$0(3$66:25'

What happens?



encryption (data)

encryption (net.)

11system boundary

Attacker86(51$0(3$66:25'


spying

86(51$0(3$66:25'

propagation

infiltration



multi-versioning

port blocking

repair / recover

12system boundary


spying

86(51$0(3$66:25'

propagation


86(51$0(3$66:25'



… none yet …

13system boundary


spying

86(51$0(3$66:25'

propagation


86(51$0(3$66:25'

Service



Service = ? authentication? intrusion detection? …

14system boundary


spying

86(51$0(3$66:25'

propagation


86(51$0(3$66:25'

Service


Keep System Integrity

15


Aspects of SecurityConfidentiality

No information leak

Integrity Preserve correct state

Availability Provide operation (no DoS)

Authentication “Are you truly you?”

16


Data / System IntegrityRequirements

No tampering of data / system Distributed system: preserve consistency

“Outside” Threat Attacker has no secret initially Attacker uses public service interface in unexpected ways

“Inside” Threat Attacker passes as legitimate node / server (eludes detection) Attacker has access to all information

17


The Replicated Register

18

Service

Client A Client B

add(10) mult(5)

575

35

(5+10)*5 =

(5*5)+10 =

75


The Replicated Register

19

Service Replicas

Client A Client B

add(10) mult(5)coordination

5 51575(5+10)*5 = = (5*5)+10

S1 S2

2535


Consistency &

Total Order

20


Replicated Register

21

Client A Client B

25

add 10

mult 55

35

Server S15

Server S2

357525

15

total order broadcast

all messages delivered in the same order

total order broadcast equivalent to:

distributed agreement (consensus)

(strict) group membership

transaction commit

replicated state-machine

distributed log / ledger


Replicated Register

22

Client A Client B

25

add 10

mult 55

35

Server S15

Server S2

3525

question: “how to enforce total order?”

(at the servers)

0 init 5 51 mult 5 252 add 10 353 ???4

context: stream of incoming operations

question: “which next?” (at position 3)


0 init 5 51 mult 5 252 add 10 353 ???4

Replicated Register

23

Client A Client B35

Server S1 Server S235

remove clients

add more replicas


?Server S3 Server S4

?Server S2

??Server S1 Server S5

?

majority

majority

Replicated Register

24

op1op2

prepare(op1)prepare(op2)

(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)

accept(op2)

learn(op2)commit(op2)

promise(op2)promise(op1)

(#,op2) (#,op2)

op2 op2 op2 op2 op2



?Server S2


?

majority

majority

Replicated Register

25

op1op2


(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)

accept(op2)

learn(op2)commit(op2)


(#,op2) (#,op2)

op2 op2 op2 op2 op2

(over-)simplified version of Paxos protocol

Lamport [TOCS 1998] (tutorial) Meling [OPODIS 2013]


Quorums Why majority?

26



?Server S2


?

majority

Replicated Register

27

op1op2


(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)

accept(op2)promise(op2)

promise(op1)

take over

op2 op2 op2 op2

assumes at most

crashes⌊n/2⌋for serversn



?Server S2


?

majority

Replicated Register

28

op1op2


(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)


take over

op1 op1 op1 op1op2 op2 op2 op2


Server S2? ?

Server S3 Server S4??

Server S1 Server S5?

majority

Quorums

29

op1op2


(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)

promise(op1)

take overtake over

op1 op1 op1


Quorums

30

(#,op2)

(#,op1)

grid quorum majority quorum

(#,op1)

(#,op2)

|system| = n (servers)

|maj. A| =

servers

⌊n/2⌋+1

|maj. B| =

servers

⌊n/2⌋+1

at least one serverat least two servers


Recovery (take over)Terminology

servers; faulty (crash);

Recovery (take over) accept (#,op2) by majority (A) recovery with info. from majority (B) at least one process from A

Non-blocking broadcast message

wait for at most replies

n f n ≥ 2f+1

n−f31

(#,op1)

(#,op2)


|maj. A| =

servers

⌊n/2⌋+1

|maj. B| =

servers

⌊n/2⌋+1

at least one server


Byzantine Fault-Tolerance

32


Data / System IntegrityRequirements

No tampering of data / system Distributed system: preserve consistency

“Outside” Threat Attacker has no secret initially Attacker uses public service interface in unexpected ways

“Inside” Threat Attacker passes as legitimate node / server (eludes detection) Attacker has access to all information

33


Byzantine FaultsFault

behavior deviates from specification

Fault Modes Crash stops working permanently

Omission misses sending/receiving of messages

Rational (selfish) (mis)behavior that maximizes local benefit

Byzantine (accidental / malicious) any type of misbehavior

34


Byzantine FaultsConcretely

broadcasting <info> as part of an algorithm

35

<info>

good case

<info>

omission

<LIE>

wrong info

<LIE1><LIE2>

different values

<fakenews> from Guan Yu!

fake identity

correctfaulty crash

faulty Byzantine

imag

e so

urce

: http

s://w

ww

.mos

s247

.com


Byzantine Generals

36

[LSP82] Lamport, Shostak, Pease: The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst. 4(3): 382-401 (1982)


Byzantine QuorumTerminology

servers;

number of crash faults

number of Byzantine faults

n f = fC+fBfCfB

37

set B

set A

|system| = n (servers)S1 S2 S3 S4 S5

req(xx)

set A = {S1,S2,S3}



servers;



Non-blocking

n f = fC+fBfCfB

38

set A




servers;



Non-blocking have crashed

n f = fC+fBfCfB

fC

39

set A


fC



servers;




never reply

n f = fC+fBfCfB

fCfB

40

set A


fC

fB

n−f



servers;




never reply

Intersection

n f = fC+fBfCfB

fCfB

41

set A


fC

fB

set B

fC

fBn−f

n−f



servers;




never reply

Intersection includes lies

n f = fC+fBfCfB

fCfB

42

set A


fC

fB

set B

fC

fB

fB



servers;




never reply

Intersection includes lies; at least one correct value

n f = fC+fBfCfB

fCfB

43

set A


fC

fB

set B

fC

fB

fBcorrect val. 1



servers;




never reply

Intersection includes lies; at least one correct value

n f = fC+fBfCfB

fCfB

44

set A


fC

fB

set B

fC

fB

fBcorrect val. 1

n ≥ 2fC+3fB+1


Practical Byzantine Fault ToleranceContext

described in client/server model state-machine replication similarities with Paxos Byzantine-tolerant uses crypto hash function

45

[CL01] Castro, Liskov: Practical Byzantine Fault-Tolerance and Proactive Recovery. ACM Trans. Comput. Syst. 20(4): 398-461 (2001)


Blockchain

46


blockchain

block

append page

Ledger

47 image source: chibabank.co.jp

page 1

page 2

page 3

page 4


Distributed Ledger

48

Root

assumed final/stable & agreed upon

arbitrary depth (typ. 5-6 blocks for Bitcoin)

new block

append to block with

best "survival" chance

very unlikely in practicefinality

not guaranteed

sybil attack create many identities

overcome reputation system circumvent incentive mechanism


Distributed Ledger

49

Root

assumed final/stable & agreed upon

arbitrary depth (typ. 5-6 blocks for Bitcoin)

new block

append to block with

best "survival" chance

entry := operationTotal Order on operations

⎫⎪⎪⎪⎬⎪⎪⎪⎭


ComparisonByzantine fault-tolerance

strong consistency always safe; mostly live partition: majority-only finality: commit => permanent

Blockchain mostly safe; always live partition: loss at merge finality: high probability

Overall each serves purpose address different issues not mutually exclusive BFT used in blockchain (PoS) tradeoff: CAP theorem consistency availability partition-tolerance

50


I Want a Blockchain!

51

2+ participants will update the data?

you and all participants trust each other?

you and all participants can trust a 3rd party?

control who changes blockchain software?

data needs to be kept private?

might need permissioned blockchain

don’t need blockchain

might need public blockchain

No

<Yes

<Yes

No>No

Yes<Yes

No

No

likely to be attacked or censored?

YesYes>

No

traditional database can meet your needs?

YesNo>

Source: M.E.Peck. Do you need a blockchain? IEEE Spectrum, 54(10):38-39, Oct 2017.


Summing UpDistributed Ledger

state-machine replication quorums, agreement problem equivalence

Byzantine fault-tolerance Byzantine faults strong consistency finality

Blockchain distributed ledger eventual consistency no finality

52


Self-Stabilization

53


Systems

54

system state

initial state(s)


legitimate (legal) states

Systems

55

system statealgorithm transitions

initial state(s)

fault



Classical Fault-Tolerance

56


initial state(s)

degraded statesfault



Self-Stabilization

57


initial state(s)



Self-Stabilization

58


initial state(s)

self-repairself-configuration


Self-StabilizationDefinition

a system S is self-stabilizing with respect to predicate P if it satisfies:

Closure P is closed under the execution of S. Intuitive: always legal state —> legal state

Convergence starting from an arbitrary global state, S is guaranteed to reach a global state satisfying P within a finite number of state transitions. Intuitive: any state eventually —> legal state

59


Illustration: BFS tree

60

A

B

D

F

C

E



61

A

B

D

F

C

E

(C,0)(B,0)

(F,0)

(A,0)(D,0)

(E,0)(root, depth)



62

A

B

D

F

C

E

C,0C,0

C,0F,0 D,0

B,0 (C,0)(B,0)

(F,0)

(A,0)(D,0)

(E,0)

min {(root, depth)}



63

A

B

D

F

C

E

(C,0)(B,0)

(F,0)

(A,0)(D,0)

(E,0)

F,0 D,0B,0

min {(root, depth)}



64

A

B

D

F

C

E

(B,1)(B,0)

(F,0)

(A,0)(D,0)

(E,0)

(C,0)F,0 D,0

B,0

min {(root, depth)}



65

A

B

D

F

C

E

(B,1)(A,1)

(A,1)

(A,0)(C,1)

(D,1)

(B,0)

(F,0)

(D,0)

(E,0)

(C,0)



66

A

B

D

F

C

E

(B,1)(A,1)

(A,1)

(A,0)(C,1)

(D,1)



67

A

B

D

F

C

E

(A,2)(A,1)

(A,1)

(A,0)(B,2)

(A,2)

(B,1)

(C,1)

(D,1)



68

A

B

D

F

C

E

(A,2)(A,1)

(A,1)

(A,0)(B,2)

(A,2)



69

A

B

D

F

C

E

(A,2)(A,1)

(A,1)

(A,0)(A,3)

(A,2)

(B,2)



70

A

B

D

F

C

E

(A,2)(A,1)

(A,1)

(A,0)(A,3)

(A,2)



71

A

B

D

F

C

E

(A,2)(A,1)

(A,1)

(A,0)(A,3)

(A,2)



72

A

B

D

F

C

E

(A,2)(B,0)

(A,3)

(A,0)(A,3)

(A,2)

(A,1)

(A,1)



73

A

B

D

F

C

E

(B,1)(B,0)

(B,1)

(A,0)(A,3)

(A,4)(A,3) (A,2)

(A,2)



74

A

B

D

F

C

E

(B,1)(B,0)

(B,1)

(A,0)(B,2)

(B,2)(A,4)

(A,3)



75

A

B

D

F

C

E

(B,1)(B,0)

(B,1)

(A,0)(B,2)

(B,2)


Wrapup

76


SummaryIntrusion-Tolerance

work in spite of traitors covers for long detection time complementary with other approaches (security in depth)

Distributed Agreement cornerstone deal with potential traitors

Byzantine agreement robust but expensive

Blockchain weak but flexible

Self-stabilization attractive property non-masking fault-tolerance

77

XCO.T473 サイバーセキュリティ概論 …...2020/05/29 · (issue 2) Mixed System Boundaries 5 Network Router Firewall ual em boundary Physical system boundary encrypted communication

Documents