Slides 09

Distributed Systems
(4th edition, version 01)
Chapter 09: Security

Security Introduction to security
Dependability
Basics
A dependable system provides availability, reliability, safety, maintainability,
confidentiality, and integrity.
• Confidentiality: refers to the property that information is disclosed only
to authorized parties.
• Integrity: alterations to a system’s assets can be made only in
an authorized way, ensuring accuracy and completeness.
Security threats, policies, and mechanisms

Dependability
Basics
A dependable system provides availability, reliability, safety, maintainability,
confidentiality, and integrity.
• Confidentiality: refers to the property that information is disclosed only
to authorized parties.
• Integrity: alterations to a system’s assets can be made only in
an authorized way, ensuring accuracy and completeness.
Alternative
We attempt to protect against security threats:
1. Unauthorized information disclosure (confidentiality)
2. Unauthorized information modification (integrity)
3. Unauthorized denial of use (availability)

Security mechanisms
• Encryption: transform data to something an attacker cannot understand,
or that can be checked for modificatons.
• Authentication: verify a claimed identity.
• Authorization: check an authenticated entity whether it has the
proper rights to access resources.
• Monitoring and auditing: (continuously) trace access to resources

Security principles
• Fail-safe defaults: defaults should already provide good
protection. Infamous example: the default “admin,admin” for edge
devices.
• Open design: do not apply security by obscurity: every aspect of
a distributed system is open for review.
• Separation of privilege: ensure that critical aspects of a system can
never be fully controlled by just a single entity.
• Least privilege: a process should operate with the fewest
possible privileges.
• Least common mechanism: if multiple components require the same
mechanism, then they should all be offered the same implementation of
that mechanism.
Design issues
Where to implement security mechanisms?
Observation
We are increasingly seeing end-to-end security, meaning that mechanisms
are implemented at the level of applications.
Design issues
Where to implement security mechanisms?
Observation
We are increasingly seeing end-to-end security, meaning that mechanisms
are implemented at the level of applications.
Issue: which layer do we trust?

Trusted Computing Base: The set of all security mechanisms in a
(distributed) computer system that are necessary and sufficient to enforce a
security policy.
Design issues
On privacy
Observation
Privacy and confidentiality are closely related, yet are different. Privacy can
be invaded, whereas confidentiality can be breached ⇒ ensuring
confidentiality is not enough to guarantee privacy.
Design issues
On privacy
Observation
Right to privacy
The right to privacy is about “a right to appropriate flow of personal
information.” Control who gets to see what, when, and how ⇒ a person
should be able to stop and revoke a flow of personal information.
Design issues
On privacy
Observation
Right to privacy
The right to privacy is about “a right to appropriate flow of personal
information.” Control who gets to see what, when, and how ⇒ a person
should be able to stop and revoke a flow of personal information.
General Data Protection Regulation (GDPR)

The GDPR is a comprehensive set of regulations aiming to protect
personal data.
Design issues
GDPR: Database perspective

GDPR regulation Impact on database systems
Attributes Actions
Collect data for explicit purposes Purpose Metadata indexing
Do not store data indefinitely TTL Timely deletion
Inform customers about GDPR metadata Purpose, TTL, Metadata indexing
associated with their data Origin, Sharing
Allow customers to access their data Person id Metadata indexing
Allow customers to erase their data TTL Timely deletion
Do not use data for objected reasons Objections Metadata indexing
Allow customers to withdraw from Automated Metadata indexing
algorithmic decision-making decisions
Safeguard and restrict access to data Access control
Do not grant unlimited access to data Access control
Audit operations on personal data Audit trail Monitor and log
Implement appropriate data security Encryption
Share audit trails from affected systems Audit trail Monitor and log
Design issues
Security Cryptography
Cryptography
Basic concepts
• Plaintext: the original message or data (P)
• Ciphertext: the encrypted version of the the plaintext (C)
• Encryption key: input EK to a function for encryption: C = EK (P)
• Decryption key: input DK to a function for decryption: P = DK (C)

Basics
Cryptosystems
Symmetric : if P = DK (EK (P)) then DK = EK .
Asymmetric : if P = DK (EK (P)) then DK ̸= EK .

Also called public-key systems with a publicly known key PK
and secret key SK
Examples
Let PKX denote public key of X and SKX the associated secret key.
Confidential message : if m is to be kept private: C = PKreceiver (m).
Authenticated message : if m is to be authenticated: C = SKsender (m).
Homomorphic encryption
Mathematical operations on plaintext can be performed on the
corresponding ciphertext: if x and y are two numbers, then
EK (x ) ⋆EK (y ) = EK (x ⋆y )
Symmetric and asymmetric cryptosystems

Hash functions
Description
A hash function H takes a message m of arbitrary length as input
and produces a bit string h having a fixed length as output:
h = H(m) with length of h fixed.
Example: digital signature

Alice computes a digest from m; encrypts the digest with her private
key; encrypted digest is sent along with m to Bob:
Alice: send [m, sig] with sig = SKA(H(m)).
Bob decrypts digest with Alice’s public key; separately calculates the
message digest. If both match, Bob knows the message has been signed by
Alice:
Bob: receive [m, sig], compute h′ = H(m) and verify h′ = PKA(sig).
Hash functions
Key management
Essence
How do Alice and Bob get the correct (often shared) keys so that they can
set up secure channels?
Diffie-Hellman key exchange

Assume two large, nonsecret numbers p and g (with specific
mathematical properties):
Key management
DH key exchange: example

Multiparty computation
Can we protect private data while computing statistics? Who has the
highest salary without revealing salaries? Can we compute the number of
votes cast for a specific candidate without revealing who voted for whom?
Key management

Oblivious transfer
Alice has n secret messages m1,.., mn . Bob is interested (and allowed) to
know only message mi . Which message he wants to know should be kept
secret to Alice; all messages mj ̸= mi should be kept secret to Bob.
Key management

Oblivious transfer
Alice has n secret messages m1,.., mn . Bob is interested (and allowed) to
know only message mi . Which message he wants to know should be kept
secret to Alice; all messages mj ̸= mi should be kept secret to Bob.
Key management
1-out-of-2 oblivious transfer
Key management
Example, continued
Preliminaries
• P1 and P2 need to compute F (a, b).
• Parameter a is secret and known only to P1; secret b known only to P2 .

• a ∈ X and b ∈ Y; X and Y are finite.
• Construct a |X|×|Y| matrix F.
• F[i, j ] = F (xi , yj ) for each pair (xi , yj ) ∈ X × Y.
Solution
• P1 generates |X| · |Y| unique key pairs (Ki , Kj )
• Construct F∗[i, j ] = Ki (Kj (F (xi , xj ))). Assume a = xi ).
• P1 permutes F∗ and sends it along with Ki to P2
• P1 sends Q using a 1-out-of-|Y| oblivious transfer.
• Assume b = yj . Using Q, P2 can construct Kj , and only Kj
•
Key management ∗
What is needed to distribute

keys
Symmetric-key distribution
Observation
In general, we will need a secure channel to distribute the secret key to
the communicating parties.
Key management
What is needed to distribute

keys
Public-key distribution
Observation
No need for a scure channel in the case of the public key, but you do need
to know that the key is authentic ⇒ have the public key be signed by a
certification authority. Note, we do need to trust that authority, or otherwise
make sure that its signature can be verified as well.
Key management
Security Authentication
Authentication
Essence
Verifying the claimed identity of a person, a software component, a device,
and so on.
Means of authentication
1. Based on what a client knows, such as a password or a
personal identification number.
2. Based on what a client has, such as an ID card, cell phone, or
software token.
3. Based on what a client is, i.e., static biometrics such as a fingerprint
or facial characteristics.
4. Based on what a client does, i.e., dynamic biometrics such as
voice patterns or typing patterns.
Introduction to authentication
Authentication versus message integrity

Observation
Authentication without integrity (and vice versa) is meaningles:
• Consider a system that supports authentication but no mechanisms to
ensure message integrity. Bob may know for sure that Alice sent m,
but how useful is that if he doesn’t know that m may have been
modified?
• Consider a system that guarantees message integrity, but does not
provide authentication. Can Bob be happy with a guaranteed
unmodified message that states he just won $1,000,000?
Authentication protocols
Using a shared secret key
Steps
1. Alice announces she wants to talk to Bob.
2. Bob returns a nonce.
3. Alice encrypts the nonce with the shared key KA,B , thus proving that
she owns KA,B ⇒ Bob knows he’s talking to Alice.
4. Alice sends a nonce to Bob.
5. Bob returns proof that he owns the shared secret key as well ⇒
Alice knows she’s talking to Bob.
About optimizations
Let’s reduce the num-

ber of messages
About optimizations
Let’s reduce the num-

ber of messages
We just broke the

protocol
Using a Key Distribution

Center
Basics
Every client has a secret key shared with the KDC.
1. Alice tells the KDC that she wants to talk to Bob
2. The KDC sends a fresh secret key, shared by Alice and
Bob
Using a Key Distribution

Center
Basics
Using a ticket is practically better:
1. Alice tells the KDC that she wants to talk to Bob
2. The KDC sends a fresh secret key, shared by Alice and Bob
3. Alice tells Bob that she wants to talk, along with the key to be
used.
The Needham-Schroeder protocol
Important observation
In the case of request-response messages, you want to make sure that
the received response, is associated with the sent request. Mitigates
replay attacks.
General principle
Use nonces to relate any combination of request-response messages.
Mitigate against reuse of

keys
Some observations
• Note how B1 ties message #2 to #5
• Note that by returning RA2 − 1 in #6, Bob proves he knows KA,B
• And, likewise, in the case of Alice in #6 (by modifying RB2 ).
Using public keys
Steps
1. Alice tells Bob she wants to talk, sending a nonce RA, and encrypting
the message with Bob’s public key.
2. Bob generates a shared secret session key KA,B , proves he is the
owner of PKB by decrypting RA, and challenges Alice to prove she
owns PKA.
3. Alice decrypts the response, and proves to Bob that she is Alice by
then sending Bob’s nonce back encrypted with the generated session
key KA,B .
Practical example: Kerberos
Essence
1,2 Alice types in her login name.
3 The Authentication Service returns a ticket KAS,TGS (A, KA,TGS ) that she
can use with the Ticket Granting Service.
4,5 To be able to decrypt the message, Alice must type in her password.
She is then logged in. Using the AS in this way, we have a single sign-
on system.
6,7 Alice wants to talk to Bob, and requests the TGS for a session key.
Transport Layer Security
• G denotes a specific set of parameter settings, called a group

(e.g., values for p and g).
Transport Layer Security
• The client uses a nonce RC ; the server uses RS

• H(m1|m2 ) denotes the hash over the concatenation of m1 and m2
Security Trust in distributed systems
On trust
Definition
Trust is the assurance that one entity holds that another will perform
particular actions according to a specific expectation.
Important observation
• Expectations have been made explicit ⇒ no need to talk about trust?
• Example: Consider a Byzantine fault-tolerant process group of size n
• Specificiation: the group can tolerate that at most k ≤ (n − 1)/3
processes go rogue.
• Realisation: for example PBFT.
• Consequence: if more than k processes fail, all bets are
simply off.
• Consequence: it’s not about trust, it’s all about
meeting specifications.
• Observation: if a process group often does not meet its
specifications, one may start to doubt its reliability, but this is
something else than (dis)trusting the system.
Trust in the face of Byzantine failures
Sybil attack
Essence: Just create multiple identities, but owned by one entity
• In the case of a peer-to-peer network:
1 H = s e t o f honest nodes
2 S = s e t o f Sybil nodes
3 A = Attacker node
4 d = minimal f r a c t i o n o f Sybil nodes needed f o r an a t t a c k
5
6 while True:
7 s = A.createNode() # c re a te a S y b i l node
8 S.add(s) # add i t t o t h e s e t S
9
10 h = random.choice(H) # p i c k an ar bitr ar y honest node
11 s.connectTo(h) # connect t h e new s y b i l node t o h
12
13 i f len(S) / len(H) > d : # enough s y b i l nodes f o r. . .
14 A.attack() # . . . a n attac k
Trusting an identity
Sybil attack
Essence: Just create multiple identities, but owned by one entity
• In the case of a peer-to-peer network:
1 H = s e t o f honest nodes
2 S = s e t o f Sybil nodes
3 A = Attacker node
4 d = minimal f r a c t i o n o f Sybil nodes needed f o r an a t t a c k
5
6 while True:
7 s = A.createNode() # c re a te a S y b i l node
8 S.add(s) # add i t t o t h e s e t S
9
10 h = random.choice(H) # p i c k an ar bitr ar y honest node
11 s.connectTo(h) # connect t h e new s y b i l node t o h
12
13 i f len(S) / len(H) > d : # enough s y b i l nodes f o r. . .
14 A.attack() # . . . a n attac k
• In the case of a Web-of-trust:

• Endorse a public key without an out-of-band check.
• Bob checks with k > 1 others that they have endorsed Alice’s
key.
• Alice creates k > 1 identities each stating her key is valid.
Eclipse attack
Essence: Try to isolate a node from the network
Example: a hub attack in the case of a gossip-based service. In this case,
when exchanging links to other peers, a colluding node returns links only
to other colluders.
Affected node: has links only to colluders.
General solution
Use a centralized certification authority.
Preventing Sybil attacks: Blockchain solutions

Essence: creating an identity comes at a cost
In the case of permissionless blockchains:
• Proof-of-Work: Let validators run a computational race. This approach
requires considerable computational resources
• Proof-of-Stake: Pick a validator as a function of the number of tokens
it owns. This approach requires risking loss of tokens.
Preventing Sybil attacks: Decentralized accounting

A simple example
• Each node P maintains a list of nodes interested in doing work for P:
the choice set of P (choice(P)).
• Selecting Q ∈ choice(P) depends on Q’s work for others (i.e.,
its reputation).
• P maintains a (subjective) view on reputations. Of course, P knows
precisely what it has done for others, and what others have done for
P.
• P can compute a capacity (cap(Q):
cap(Q) = max{MF (Q, P) −MF (P, Q), 0}
with MF (P, Q) the amount of work that P has, or could have

contributed to work done for Q, including the work done by others.

Essence: Keep track of work that nodes do for each other
• Assume R directly contributed 3 units of work for Q, and R had
processed 7 units for P ⇒ P may have contributed 3 units of work for
Q, through R.
• Reasoning: R may never have been able to work for Q, if it had
not worked for P.

How Sybil attacks are prevented
• Let Q ∈ choice(P) create n Sybil nodes Q∗,.., Q∗; Q = Q∗
1 n 0
• For work by Q∗ for Q∗ to increase cap(Q∗):
i j
i
1. Q∗
j needs to have worked for some node R
2. R needs to have worked for P
In other words: Q can successfully attack only if it had worked for
honest nodes. Also, honest nodes have to work for Q: the total capacity
Tcap(Q) of the Sybils must grow, with
n
Tcap(Q) = ∑ cap(Qk∗)
k =0
• Assume that P works 1 unit for Qi∗ ⇒ MF (P, Qi ∗) increases by 1 unit

⇒
cap(Q∗i ) drops by 1 unit, and so does Tcap(Q).
• As soon as Tcap(Q) drops to 0, P will look at other nodes.
Trusting a system: Blockchains

Essence
One needs to know for sure that the information in a blockchain has not
been tampered with: data integrity assurance. Solution: make sure that no
change can go unnoticed (recall: a blockchain is an append-only data
structure).
Observation
Any change of block Bk , will affect its hash value, and thus that of Bk + 1 ,
which would then also need to be changed, in turn affecting the hash value
of Bk + 2 , and so on.
Trusting a system
Security Authorization
Access control: General model

Authorization
Making sure that authenticated entities have only access to specific
resources.
Observation
The reference monitor needs to be tamperproof: it is generally
implemented under full control of the operating system, or a secure server.
General issues in access control

Protection
...against invalid operations ...against unauthorized access
...against unauthorized
invokers
Access control policies

1. Mandatory access control: A central administration defines who gets
access to what.
2. Discretionary access control: The owner of an object can change
access rights, but also who may have access to that object.
3. Role-based access control: Users are not authorized based on
their identity, but based on the role they have within an
organization.
4. Attribute-based access control: Attributes of users and of objects
they want to access are considered for deciding on a specific access
rule.

Access control matrix

Theory
Construct a matrix in which M[s, o] describes the access rights subject s has
with respect to object o. Impractical, so use access control lists or
capabilities.
Access control list
Capabilities

Special case: Attribute-based Access Control

Distinguish different classes of attributes:
• User attributes: name, data of birth, current roles, home address,
department, qualifiers obtained, contract status, etc. May also depend on
role (e.g., teacher or student).
• Object attributes: anything – creator, last-modified time, version
number, file type, file size, but also information related to its content.
• Environmental attributes: describe the current state of the system, e.g.,
date and time, current workload, maintenance status, storage
properties, available services, etc.
• Connection attributes provide information on the current session, e.g.,
IP address, session duration, available bandwidth and latency
estimates, type and strength of security used.
• Administrative attributes: reflect global policies, e.g., minimal security
settings, general access regulations, and maximum session
durations.
Attribute-based access control

Example: the Policy Machine

Essence
A server maintains sets of (atrribute,value) pairs, distinguishing users,
applications, operations, and objects. At the core, we formulate access
control rules.
Access control rules
• Assignment: A user u can be assigned to an attribute ua: u → ua.
An object to an attribute: o → oa; an attribute to an attribute: ua1 →
ua2 (meaning that if u → ua1, then u → ua2 . Leads to rules like
allowed(ua, ops, oa): users assigned to ua are allowed to execute
operations in ops on objects assigned to oa.
• Prohibition: explicitly state what is not allowed, such as
denied(u, ops, os). Also: denied(u, ops, ¬os), meaning denial when u
wants to perform o assigned to ops on an object not in os.
• Obligation: automated action upon an event, such as denying copying
of information:
when u read s f ∈ fs then denied(u,{write}, ¬fs).
Attribute-based access control
Delegation
What’s the issue?
Alice makes use of an e-mail service provider who stores her mailbox. She
is required to log in to the provider to access her mail. Alice wants to use her
own local mail client. How to allow that mail client to act on behalf of Alice?
How to delegate Alice’s access rights to her mail client?
Observation
It is not a good idea to hand over all user credentials to an application:
why would the application or the machine be trusted? ⇒ use a security
proxy.
Delegation
Security proxy
How it works
1. Alice passes some rights R to Bob, together with a secret key SKproxy
2. When Bob wants to exercise his rights, he passes the certificate
3. The server wants Bob to prove he knows the secret key
4. Bob proves he does, and thus that Alice had delegated R.
Delegation
Example: Open Authorization (OAuth)

Four different roles
• Resource owner: typically an end user.
• Client: an application that one would like to act on behalf of the
resource owner,
• Resource server: An interface through which a person would
normally access the resource.
• Authorization server: an entity handing out certificates to a client
on behalf of a resource owner.
Initial steps
1. The client application registers itself at the authorization server
and receives its own identifier, cid .
2. Alice wants to delegate a list R of rights ⇒
Client: send [cid, R,H(S)]
with a hash of a temporary secret S

Delegation
Completing the process

Final steps
3. Alice is required to log in and confirm delegation R to the client.
4. Server sends a temporary authorization code AC to client.
5. Client requests a final access token:
Client: sends [cid, AC, S].
Sending S to the authorization server allows the latter to verify the

identity of the client (by computing H(S).
The authorization server has now (1) verified that Alice wants to delegate
access rights to the client, and (2) has verified the identity of the client ⇒
it returns an access token to the client.
Delegation
Example: decentralized authorization

WAVE (and keeping it very simple)
Essence: Alice delegates rights to Bob, Bob delegates some of those rights
to Chuck.
• When Check wants to exercise his rights, there should be no need
for Alice or Bob to be online.
• No one but Alice, Bob, and Chuck need to be aware of the
delegation.
Decentralized authorization: an example

Security Monitoring
Firewalls
Essence
Simply prevent anything nasty coming in, but also preventing
unwanted outbound traffic.
Different types of firewalls

• Packet-filtering gateway: operates as a router and makes filters
packets based on source and destination address.
• Application-level gateway: inspects the content of an incoming or
outgoing message (e.g., gateways filtering spam e-mail).
• Proxy gateway: works as a front end to an application, filtering like
an application-level gateway (e.g., Web proxies).
Firewalls
Security Monitoring
Intrusion detection systems

Two flavors
• Signature-based: matches against patterns of known network-level
intrusions. Problematic when series of packets need to be matched, or
when new attacks take place.
• Anomaly-based: assumes that we can model or extract typical behavior
to subsequently detect nontypical, or anomalous behavior. Relies
heavily on modern artificial-intelligence technologies.
Intrusion detection: basics

Security Monitoring
Intrusion detection systems

Two flavors
• Signature-based: matches against patterns of known network-level
intrusions. Problematic when series of packets need to be matched, or
when new attacks take place.
• Anomaly-based: assumes that we can model or extract typical behavior
to subsequently detect nontypical, or anomalous behavior. Relies
heavily on modern artificial-intelligence technologies.
Using sensors
Key idea is to manage false and true positives (FP/TP) as well as false
and true negatives (FN/TN). Maximize accuracy and precision:
TP + TN
Accuracy:
TP + TN + FP + FN
TP
Precision:
TP + FP
Intrusion detection: basics

Slides 09

Uploaded by

Copyright:

Available Formats

Slides 09

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slides 09

Uploaded by

Copyright:

Available Formats

Distributed Systems

(4th edition, version 01)

Chapter 09: Security

Security threats, policies, and mechanisms

Security threats, policies, and mechanisms

Security threats, policies, and mechanisms

Where to implement security mechanisms?

Where to implement security mechanisms?

Issue: which layer do we trust?

General Data Protection Regulation (GDPR)

GDPR: Database perspective

• Decryption key: input DK to a function for decryption: P = DK (C)

Asymmetric : if P = DK (EK (P)) then DK ̸= EK .

Confidential message : if m is to be kept private: C = PKreceiver (m).

Authenticated message : if m is to be authenticated: C = SKsender (m).

Symmetric and asymmetric cryptosystems

h = H(m) with length of h fixed.

Example: digital signature

Alice: send [m, sig] with sig = SKA(H(m)).

Bob: receive [m, sig], compute h′ = H(m) and verify h′ = PKA(sig).

Diffie-Hellman key exchange

DH key exchange: example

DH key exchange: example

DH key exchange: example

1-out-of-2 oblivious transfer

• Parameter a is secret and known only to P1; secret b known only to P2 .

• Construct F∗[i, j ] = Ki (Kj (F (xi , xj ))). Assume a = xi ).

• P1 permutes F∗ and sends it along with Ki to P2

• P1 sends Q using a 1-out-of-|Y| oblivious transfer.

• Assume b = yj . Using Q, P2 can construct Kj , and only Kj

What is needed to distribute

What is needed to distribute

Authentication versus message integrity

Using a shared secret key

Let’s reduce the num-

Let’s reduce the num-

We just broke the

Using a Key Distribution

Using a Key Distribution

The Needham-Schroeder protocol

Mitigate against reuse of

• And, likewise, in the case of Alice in #6 (by modifying RB2 ).

Using public keys

Practical example: Kerberos

Transport Layer Security

• G denotes a specific set of parameter settings, called a group

Transport Layer Security

• The client uses a nonce RC ; the server uses RS

• In the case of a Web-of-trust:

Affected node: has links only to colluders.

Preventing Sybil attacks: Blockchain solutions

Preventing Sybil attacks: Decentralized accounting

cap(Q) = max{MF (Q, P) −MF (P, Q), 0}

with MF (P, Q) the amount of work that P has, or could have

Preventing Sybil attacks: Decentralized accounting

Preventing Sybil attacks: Decentralized accounting

• Assume that P works 1 unit for Qi∗ ⇒ MF (P, Qi ∗) increases by 1 unit

Trusting a system: Blockchains