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>

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

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

Why Intrusion-Tolerance?

Firewall Fallacy

NetworkRouter

Firewall“Inside” comfy, safe

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

“Outside” threatening

(issue 1) Reverse Proxy

NetworkRouter

Firewall

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

botnet

attackmonitoring

weak smart plug

registry

registereavesdrop

replayReverse Proxy

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

admin:admin

(issue 2) Mixed System Boundaries

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

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

Aspects of SecurityConfidentiality

No information leak

Integrity Preserve correct state

Availability Provide operation (no DoS)

Authentication “Are you truly you?”

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

The Replicated Register

Service

Client A Client B

add(10) mult(5)

(5+10)*5 =

(5*5)+10 =

The Replicated Register

Service Replicas

Client A Client B

add(10) mult(5)coordination

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

Consistency &

Total Order

Replicated Register

Client A Client B

add 10

mult 55

Server S15

Server S2

357525

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

Client A Client B

add 10

mult 55

Server S15

Server S2

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

Client A Client B35

Server S1 Server S235

remove clients

add more replicas

?Server S3 Server S4

?Server S2

??Server S1 Server S5

majority

Replicated Register

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

Replicated Register

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?

?Server S2

majority

Replicated Register

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

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

op1op2

(#,op2)

(#,op2) (#,op2)

(#,op1)(#,op1)

promise(op1)

take overtake over

op1 op1 op1

Quorums

(#,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

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

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

Byzantine FaultsConcretely

broadcasting <info> as part of an algorithm

<info>

good case

<info>

omission

wrong info

different values

<fakenews> from Guan Yu!

fake identity

correctfaulty crash

faulty Byzantine

: http

Byzantine Generals

[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

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

req(xx)

set A = {S1,S2,S3}

servers;

Non-blocking

n f = fC+fBfCfB

servers;

Non-blocking have crashed

n f = fC+fBfCfB

servers;

never reply

n f = fC+fBfCfB

servers;

never reply

Intersection

n f = fC+fBfCfB

fBn−f

servers;

never reply

Intersection includes lies

n f = fC+fBfCfB

servers;

never reply

Intersection includes lies; at least one correct value

n f = fC+fBfCfB

fBcorrect val. 1

servers;

never reply

Intersection includes lies; at least one correct value

n f = fC+fBfCfB

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

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

Blockchain

blockchain

append page

Ledger

47 image source: chibabank.co.jp

Distributed Ledger

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

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

I Want a Blockchain!

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

Yes<Yes

likely to be attacked or censored?

YesYes>

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

Self-Stabilization

Systems

system state

initial state(s)

legitimate (legal) states

Systems

system statealgorithm transitions

initial state(s)

Classical Fault-Tolerance

initial state(s)

degraded statesfault

Self-Stabilization

initial state(s)

Self-Stabilization

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

Illustration: BFS tree

(C,0)(B,0)

(A,0)(D,0)

(E,0)(root, depth)

C,0C,0

C,0F,0 D,0

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

(A,0)(D,0)

min {(root, depth)}

(C,0)(B,0)

(A,0)(D,0)

F,0 D,0B,0

min {(root, depth)}

(B,1)(B,0)

(A,0)(D,0)

(C,0)F,0 D,0

min {(root, depth)}

(B,1)(A,1)

(A,0)(C,1)

(B,1)(A,1)

(A,0)(C,1)

(A,2)(A,1)

(A,0)(B,2)

(A,2)(A,1)

(A,0)(B,2)

(A,2)(A,1)

(A,0)(A,3)

(A,2)(A,1)

(A,0)(A,3)

(A,2)(A,1)

(A,0)(A,3)

(A,2)(B,0)

(A,0)(A,3)

(B,1)(B,0)

(A,0)(A,3)

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

(B,1)(B,0)

(A,0)(B,2)

(B,2)(A,4)

(B,1)(B,0)

(A,0)(B,2)

Wrapup

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

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

Documents

Paubox encrypted email

Encrypted Mobile Communications

Retrieving Encrypted Mail Retrieving Encrypted Email via a.....

Search Able Encrypted

Encrypted Encrypted Encrypted 16799 ·...

防衛省とサイバーセキュリティ - Keio University...

Reseller Opportunity Encrypted Mobile · Encrypted Mobile.....

Encrypted Mag+

Un Encrypted

サイバーセキュリティ人材の...

防衛省とサイバーセキュリティjsp.sfc.keio.ac.jp...

自動車サイバーセキュリティ：...

我が国のサイバーセキュリティ戦略 ·...

Conditional Encrypted Mapping and Comparing Encrypted...

Encrypted Traffic Mining

サイバーセキュリティの概念サイバーセキュ...