T HE CAST

D ISTRIBUTED S YSTEMS [COMP9243]

The Good Guys:
➜ Alice, Bob
Lecture 10: Security
➜ Want to communicate securely

Slide 1 ➀ Introduction Slide 3 The Bad Guys:

➁ Cryptography ➜ Eve
➂ Secure protocols and communication ➜ The eavesdropper — tries to thwart Alice and Bob’s plans
➃ Authentication
The Alice and Bob After Dinner Speech:
➄ Authorisation
➜ google it for more about Alice and Bob

S ECURITY IN D ISTRIBUTED S YSTEMS

Confidentiality: information disclosed/services provided only
Slide 2 to authorised parties Slide 4
Integrity: alterations can only be made in an authorised way

Availability: system is ready to be used by authorised parties

T HE CAST 1 AUTHORISED ACTIONS 2

 B REAKING S ECURITY
Vulnerability:
AUTHORISED ACTIONS
A vulnerability is a weakness in the system that could
Security is about making sure that only authorised potentially be exercised (accidentally triggered or
actions are performed in the system. intentionally exploited) to cause a breach or violation
Example Actions: of the system’s security policy.
➜ Reading data
Slide 5 ➜ Modifying data (writing, creating, deleting) Slide 7 Attack:
➜ Using a service When a vulnerability is exercised we call this an
➜ Managing a service
attack.
All of these could be abused if performed in
unauthorised ways. Threat:

Examples? A threat is a possible breach of security policy. A

concrete threat consists of a threat-source and an
exercisable vulnerability.

S ECURITY P OLICY
Security is a question of tradeoffs S ECURITY T HREATS
Security Policy: Interception: unauthorised party has gained access to a
➜ A statement of security requirements service or data
➜ Describes which actions entities in a system are allowed to take
Interruption: service or data become unavailable, unusable,
and which ones are prohibited
destroyed, etc.
Slide 6 • Entities: users, services, data, machines, etc. Slide 8
• Operations: read, write, send, start, stop, etc. Modification: unauthorised changing of data or tampering
with a service (so that it no longer adheres to its
Example:
specifications)
➜ Everyone (staff and students) has an account
➜ Access to course accounts must be approved Fabrication: additional data or activity are generated that
➜ Only course accounts can modify grades would normally not exist

Anything missing?

B REAKING S ECURITY 3 ATTACKING A D ISTRIBUTED S YSTEM 4

 S ECURITY M ECHANISMS
ATTACKING A D ISTRIBUTED S YSTEM
Good Mechanisms:
Attacking the Communication Channel:
➜ Eavesdropping Encryption: transform data into something an attacker
➜ Masquerading cannot understand
➜ Message tampering • A means to implement confidentiality
➜ Denial of service • Support for integrity checks (check if data has been
Slide 9 Slide 11 modified)
Attacking the Interfaces:
➜ Unauthorised access Signatures and Digests support for integrity, authentication
➜ Denial of Service Secure Protocols support for authentication, authorisation
Attacking the Systems: Secure Communication support confidentiality and integrity
➜ Applications
Security Architecture based on sound principles such as:
➜ OS
small TCB, Principle of Least Privilege, support for
➜ Hardware
authorisation

P ROTECTING A D ISTRIBUTED S YSTEM

Authentication: verify the claimed identity of an entity
Less Good Mechanisms:
Authorisation: determine what actions an authenticated
Slide 10 entity is authorised to perform Slide 12 Obscurity: count on system details being unknown
Auditing: trace which entities access what Intimidation: count on fear to keep you safe
Message Confidentiality: secret communication

Message Integrity: tamperproof messages

S ECURITY M ECHANISMS 5 W HY S ECURITY IS H ARD 6

 W HY S ECURITY IS H ARD
Weakest Link:
➜ Security of a system is only as strong as its weakest link
➜ Need to make sure all weak links are removed F OUNDATIONS
➜ One bug is enough
➜ Cryptography
➜ People are often the weakest link
• Ciphers
Complexity:
• Signatures and Digests
Slide 13 ➜ Security involves many separate subsystems Slide 15
• Secure Communication
➜ Complex to set up and use
• Security Protocols
➜ People won’t use complex systems
➜ Authentication
Pervasiveness: ➜ Authorisation
➜ Application level
➜ Middleware level
➜ Network level
➜ OS level, Hardware Level

C RYPTOGRAPHY
H OW T O M AKE I T E ASIER The Basic Idea:
Passive intruder Active intruder Active intruder
Distribution of Mechanisms: only listens to C can alter messages can insert messages

➜ Trusted Computing Base (TCB): those parts of the system that

are able to compromise security
➜ The smaller the TCB the better.
Slide 14 Slide 16
➜ May have to implement key services yourself Encryption Ciphertext Decryption
Plaintext, P Plaintext
method C = EK (P) method
V Physically separate security services from other services
Encryption Decryption
Simplicity: key, E K key, D K Receiver
Sender
➜ Simplicity contributes to trust
➜ Map cleartext (or plaintext) T to ciphertext (or cryptogram) C
➜ Very difficult to make a simple secure system
➜ Mapping is by a well-known function parameterised by a key K
➜ T infeasible to reconstruct from C without knowledge of key

F OUNDATIONS 7 C RYPTOGRAPHY 8
 E NCRYPTION
The essence of encryption functions:

Find a function E that is easy to compute, but for which it is

More formally:
➜ E(KE , T ) = EKE (T ) = {T }KE : encryption of T with key KE
Slide 17
➜ D(KD , C) = DKD (C) = {C}KD : decryption of C with key KD
➜ D(KD , E(KE , T )) = T for cognate (matching) keys KD , KE
hard to compute T from {T }KE without a matching
decryption key KD for KE .
➜ “Hard to compute” means that it must take at least hundreds of
Slide 19 years to reverse E without knowledge of KD or to compute KD
➜ Such functions are known as one-way functions.

Cipher must be resilient to:

➜ Ciphertext only attacks
➜ Known plaintext attacks
➜ Chosen plaintext attacks
➜ Brute-force attacks

What properties should a good cipher possess?

➜ Confusion and Diffusion
Cryptographer: ➜ Confusion: every bit of key influences large number of
➜ Uses cryptography to convert plaintext into ciphertext ciphertext bits
➜ Diffusion: every bit of plaintext influences large number of
Cryptanalyst:
ciphertext bits
Slide 18 ➜ Uses cryptanalysis to attempt to turn ciphertext back into Slide 20
➜ Fast to compute, ideally in hardware. Is this always good?
plaintext
➜ Not critically depend on users selecting “good” keys
➜ Cryptanalysis: the science of making encrypted data
➜ Have been heavily scrutinised by experts
unencrypted
➜ Based on operations which are provably “hard” to invert
➜ Easy to use

E NCRYPTION 9 E NCRYPTION 10
 Symmetric ciphers:

Encrypt
In practice, keys are of finite length. Consequences?
➜ Finite key space ⇒ susceptible to exhaustive search Cipher
➜ Longer keys ⇒ more time needed for brute-force attack
Plaintext K text
• Time to guess a key is exponential in the number of bits of
Slide 21 Slide 23
the key Decrypt
X Longer keys also make E and D more expensive
➜ Cipher must be secure against any systematic attack ➜ Secret key: KE = KD
significantly faster than exhaustive search of key space V fast ⇒ suited for large data volumes
X Secure channel is needed to establish the shared, secret key
➜ How many keys needed for N agents?
➼ For any two agents, one key is needed

B ASIC C IPHERS
Substitution Ciphers:
➜ Each plaintext character replaced by a ciphertext character
➜ Caesar cipher: shift alphabet x positions
T INY E NCRYPTION A LGORITHM (TEA)
• Easy to break using statistical properties of language Symmetric encryption algorithm by Wheeler & Needham:
➜ Book cipher: replace words by location of word in book ➜ Encode a 64-bit block (text) consisting of two 32-bit integers
• Knowledge of book is the key ➜ Using a 128-bit key (k) represented by four 32-bit integers
Slide 22 Slide 24 ➜ Despite its simplicity, TEA is a secure and reasonably fast
One Time Pads:
➜ Random string XORed with plaintext encryption algorithm
➜ Information theoretically secure ➜ Can easily be implemented in hardware
➜ Random string must: ➜ Approximately three times as fast as DES
• Have no pattern or be predictable ➜ Achieves complete diffusion
• Not be reused
• Not be known by cryptanalyst
➜ Key distribution problem

B ASIC C IPHERS 11 T INY E NCRYPTION A LGORITHM (TEA) 12

 void encrypt (unsigned long k[], unsigned long text[])
{ O THER S YMMETRIC C IPHERS
unsigned long y = text[0], z = text[1]; Data Encryption Standard (DES):
unsigned long delta = 0x9e3779b9, sum = 0; int n; ➜ Developed by IBM for US government
for (n = 0; n < 32; n++) { ➜ 56 bit key. No longer considered safe.
sum += delta;
➜ Triple DES: 2x56 bit key. encrypt-decrypt-encrypt
y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]);
z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); International Data Encryption Algorithm (IDEA):
Slide 25 } Slide 27 ➜ Uses 128-bit key to encrypt 64-bit blocks
text[0] = y; text[1] = z;} ➜ Approximately three times as fast as DES
➜ 32 rounds: shift and combine the halves of text with the four ➜ Same function for encryption and decryption (like DES)
parts of the key Advanced Encryption Standard (AES):
➜ Constant delta is used to obscure the key in portions of the
➜ Defined in 2001, to replace DES
plaintext that do not vary
➜ Variable block and key length; specification 128, 192, or 256 bit
➜ Confusion (xor operations and shifting of the text) and diffusion
keys and 128, 192 or 256 bit blocks
(shifting and swapping of the two halves of the text)

Asymmetric ciphers:

void decrypt (unsigned long k[], unsigned long text[])

KE
{
unsigned long y = text[0], z = text[1];
Encrypt
unsigned long delta = 0x9e3779b9, sum = delta << 5; int n; Cipher
for (n = 0; n < 32; n++) { Plaintext text
Slide 26 z -= ((y << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]); Slide 28 Decrypt
y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]);
sum -= delta;
} KD
text[0] = y; text[1] = z;
} ➜ Due to Diffie & Hellman & Merkle (1976)
➜ Instead of one secret key per pair of agents, one public/private
key pair per agent
➜ KE 6= KD , KD infeasible to compute from KE

OTHER S YMMETRIC C IPHERS 13 OTHER S YMMETRIC C IPHERS 14

 Block ciphers:
T i + C i-1
T + Block cypher Ci

➜ each agent can publish public key KE =: KP ,

Register
keep private key KD =: Kp secret
Slide 29 ➜ Too slow to encrypt large volumes of data Slide 31 ➜ Encrypt fixed-size blocks of data (e.g., 64 bits), one at a time
➜ Examples: RSA and variants of Diffie & Hellman’s original
➜ Requires some padding in the last block why is this a weakness?
algorithm, such as ElGamal
➜ Blocks of ciphertext are independent
• Attacker may spot repeating patterns and infer relationship
to plaintext how?
➜ Cipher block chaining

Stream cipher:
keystream
number
generator E(K,M) ciphertext
stream
XOR
How they work: plaintext
➜ Trap-door functions: one-way functions with a secret exit stream

➜ Easy to compute in one direction, but infeasible to invert unless
Slide 30 a secret (secret key) is known
➜ Key pair is usually derived from a common root (such as large
prime numbers) such that it is infeasible to reconstruct the root
from the public key
➜ Encode a given plaintext bit by bit (e.g., voice)
Slide 32 ➜ Xor a keystream (sequence of ’random’ bits) with the plaintext
➜ Security of ciphertext same as keystream
➜ Keystream: Output of a random number generator encoded
with a block cipher algorithm
➜ How does the receiver reconstruct the plaintext?
• Generate the same keystream and xor it with the ciphertext
• requires starting value of RNG and the secret key
➜ Under which conditions can partial message loss be tolerated?

Note: This is not the same as a One Time Pad

OTHER S YMMETRIC C IPHERS 15 D IGITAL S IGNATURES & D IGESTS 16

 Must be resilient to:
➜ Collision:
D IGITAL S IGNATURES & D IGESTS
• find m1 and m2 such that H(m1 ) = H(m2 )
Cryptographically ensure message integrity and • related to birthday attack
authenticate originator. ➜ Pre-image:

How can we check whether a message has been altered? • given h, find m such that H(m) = h

Slide 33 Slide 35 ➜ Second pre-image:

➜ Secure digest or hash
➜ Fixed-length value condensing information in the message • given m1 find m2 such that H(m1 ) = H(m2 )
➜ Given message M and hash H(M ), it must be very hard to find Does a hash provide:
M ′ with H(M ) = H(M ′ )
➜ confidentiality?
➜ If hash H(M ) is the same after transmission, message is
➜ integrity?
unaltered with very high likelihood
➜ authenticity?
➜ non-repudiation?

Hash functions:
128-bit constant Padded message (multiple of 512 bits)

Digest
512 bits

What guarantees are provided by a signed document in a

Digest sealed envelope?
512 bits
➜ Authentication: receiver wants to be sure of the sender’s
Message digest
identity
Slide 34 ➜ Not unlike encryption functions, but not information preserving Slide 36
➜ Confidentiality: transmitted information is kept private
➜ Most widely used algorithms: MD5 and SHA ➜ Integrity: message could not have been altered
➜ Rivest’s MD5 algorithm: 128-bit digest; more efficient than SHA ➜ Non-repudiation: sender cannot credibly deny having signed
➜ SHA is standardised, more secure (produces 160-bit digest) the message
➜ Any symmetric encryption algorithm could be used as hashing
function with cipher block chaining, but
• less efficient and
• requires use of a key

D IGITAL S IGNATURES & D IGESTS 17 D IGITAL S IGNATURES & D IGESTS 18

 Digital Signature: S ECURE P ROTOCOLS
➜ How to verify who sent the message
Protocol: rules governing communication
Sender: Security protocol: protocol that performs a security-related
Kpri function (usually authentication)

hash H(M) Goal: Survive malicious attacks:

Message Encrypt
function signature
➜ Lies
Slide 37 Slide 39 ➜ Modifying data
Message ➜ Injecting data
➜ Malicious behaviour

➜ Given a message M and sender private key Kpri , signed Threat Assumptions:
message: ➜ Can communication channel be intercepted?
➜ Can data stream be modified?
(M, {H(M )}Kpri )
➜ Are participants malicious?

H OW TO B UILD A C RYPTOGRAPHIC P ROTOCOL

Receiver:
Use:

Message hash ➜ encryption ➜ signatures

h’
function ➜ secure digest ➜ random number generators

h = h’? Protocol mechanisms:

➜ Challenge-Response
signature Decrypt h • nonce – used to uniquely relate two messages together
Slide 38 Slide 40 What properties should a nonce have?
➜ Ticket – secured information to be passed to another party Why
Kpub
is this useful?
➜ Recipient uses matching public key Kpub to recover digest ➜ Session keys – for secure communication Why is this useful?
➜ Compare recovered digest to result of computing H(M ) Principles:
➜ If same, sent message must be unaltered and sender the owner ➜ A message must contain all relevant information
of Kpri ➜ Don’t allow parties to do things identically
➜ Don’t give away valuable information to strangers

S ECURE P ROTOCOLS 19 A S IMPLE P ROTOCOL 20

 A S IMPLE P ROTOCOL
Authentication
➜ Alice knows it’s Bob, Bob knows it’s Alice

Reflection:
1
A ➜ Use Alice to respond to Alice’s challenge
2 ➜ Alice → Eve: challenge
Slide 41 RB Slide 43
➜ Alice ← Eve: challenge
➜ Alice → Eve: response
Alice

3
K A,B (RB )

Bob
➜ Alice ← Eve: response
4
RA

5
K A,B( RA)

H OW TO B REAK A P ROTOCOL
Replay:
Man-in-the-Middle: ➜ Re-use Bob’s old message to respond to Alice’s challenge
➜ Take on the role of Alice to Bob and Bob to Alice ➜ Alice → Bob: challenge
Slide 42 ➜ Alice → Eve: challenge Slide 44
➜ Alice ← Eve ← Bob: response
➜ Eve → Bob: challenge ➜ Alice → Eve: challenge
➜ Eve ← Bob: response ➜ Alice ← Eve: response
➜ Alice ← Eve: response

H OW TO B REAK A P ROTOCOL 21 H OW TO B REAK A P ROTOCOL 22

 O PTIMISING THE P ROTOCOL

Message Manipulation: 1
A, RA
➜ Change the message from Alice to Bob
➜ Alice sends: let’s meet at 3pm by the bridge

Alice
2
➜ Eve intercepts and changes

Bob
RB , K A,B( RA)
Slide 45 ➜ Bob receives: let’s meet at 2pm by the oak Slide 47

Changed Environment/Assumptions: 3
K A,B (RB )
➜ Bob is no longer trustworthy
➜ Bob sells Alice’s secrets to the tabloid press!

Oops!
➜ Vulnerable to reflection attack

A S IMPLE P ROTOCOL : R EVISITED

Authentication

1
A, RC
1 First session
A 2
RB , K A,B( RC)

2
RB 3

Chuck
A, RB

Bob
4 Second session
Slide 46 Slide 48 RB2 , K A,B( RB)
Alice

3
K A,B (RB )
Bob

5
K A,B (RB ) First session
4
RA

5
K A,B( RA)
Is this different from Man-in-the-middle?

Vulnerable?

O PTIMISING THE P ROTOCOL 23 K EY D ISTRIBUTION 24

 K EY D ISTRIBUTION Properties of the symmetric key distribution protocol:
➜ Ticket and challenge implicitly authenticate A and B.
A set of keys provides a secure channel for communication. ➜ Nonce and challenge protect against replay attacks.
How does the secure channel get established in the first ➜ D is centralised resource (hierarchical scheme possible).
place? ➜ Every agent must trust D.
Slide 49 ➜ Use separate channel to establish keys Slide 51 ➜ D maintains highly sensitive information (secret keys),
compromising D compromises all communication.
➜ Use key distribution protocols
➜ Large number of keys required (one per pair of agents),
➜ Protocols vary depending on whether symmetric or asymmetric
manufactured by D on-the-fly.
encryption is used
➜ D must take care to make key sequence non-predictable.
➜ Often symmetric keys are communicated over a channel using
an asymmetric cipher Any vulnerabilities?

D ISTRIBUTION OF S YMMETRIC K EYS (N EEDHAM -S CHROEDER )

Key Distribution
Centre
agent key
A KA
B KB
... ...
m 1: [A, B, N A]
S ECURE C OMMUNICATION
m 2: [{N A , B, KAB, {A,KAB }K }K ]
B A

Ticket Properties of a Secure Channel:

Slide 50 m 3: [{A, KAB} K ]
B
Slide 52 ➜ Authentication
A m 4: [{N B} K ] B
m 5: [{N B -1} K
AB

]
➜ Message confidentiality
AB

➜ Message integrity
➜ Central key distribution centre D
➜ Each agent A shares a (symmetric) key KA with D
➜ A wants to communicate with B, asks D for session key KAB
➜ After key distribution protocol, both A and B know that they
share a key provided by D.

D ISTRIBUTION OF S YMMETRIC K EYS (N EEDHAM -S CHROEDER ) 25 E XAMPLE : SSL ( AND TLS) 26

 E XAMPLE : SSL ( AND TLS) S ECURE G ROUP C OMMUNICATION

Secure Socket Layer: Two types:

➜ Application level protocol for secure channel Confidential group communication:
➜ Handshake protocol: establish and maintain session ➜ All group members share the same secret key
Slide 53 ➜ Record protocol: secure channel Slide 55
X Need to trust all members
➜ Flexible: can choose ciphers to use ➜ Separate keys for each pair
➜ Most widely used to secure HTTP (https: URLs) X Scalability problem
➜ TLS (Transport Layer security): IETF standard based on SSL 3.0 ➜ Public key cryptography
➜ TLS 1.0: RFC 2246 X Everyone knows each others keys

SSL Handshake Protocol:

Client Server

ClientHello
Establish protocol version, session
ID, cipher suite, compression
Secure replicated servers:
ServerHello method, exchange random values
➜ Secure Replicated Servers: protecting from malicious group
Certificate
members
Optionally send server certificate
Server Key Exchange
and request client certificate ➜ Collect responses from all servers and authenticate each
Certificate Request Not transparent
ServerHelloDone
Slide 54 Slide 56 ➜ Secret sharing:
Certificate
Send client certificate response ➜ All group members know part of a secret.
Client Key Exchange if requested
➜ Recipient combines answers from k members, decrypts with
Certificate Verify
special decryption function D.
Change Cipher Spec Change cipher suite and finish ➜ If successful: these k members are honest.
handshake
Finished ➜ If not: try other combination of answers.
Change Cipher Spec

Finished

S ECURE G ROUP C OMMUNICATION 27 AUTHENTICATION 28

 AUTHENTICATION
K ERBEROS
Verify the claimed identity of an entity (principal)
➜ Commercial authentication system developed at MIT
Authentication Requires: ➜ Based on Needham and Schroeder protocol
➜ Representation of identity ➜ Integrates symmetric key encryption, distribution and
• Unix user id, email address, student number, bank account authentication into commercial computer systems.
➜ Some way to verify the identity ➜ Assumptions:
Slide 57 Slide 59 • secure central server
• Password, reply to email, student card, PIN
➜ Different levels of authentication • insecure network
→ never transmit cleartext passwords
Credentials: • insecure workstations (shared between users)
➜ Speaks for a principal → hold user passwords on workstations for very short periods
➜ Example: certificate stating identity of a principal only
➜ Combine credentials → hold no system keys on workstations
➜ Role-based credentials

Kerberos Authentication:
Approaches to Authentication:
Key Distribution Centre
Authentication Ticket Granting
Shared secret key: challenge and response encoded with Service A Service T
shared secret key m1 : [C; T ; n℄

m2 : [ Kf CT ; ngKC ; fhC; T igKT ℄

Key distribution centre: keys stored at KDC, never sent over
Slide 58 Slide 60
network Login f
m3 : [ C; t gKCT ; fhC; T igKT ; S; n℄
Session Setup
Public key: exchange session key encoded with public keys Server f CS ; ngKCT ; fhC; S igKS ℄
m4 : [ K

Session Setup
Hybrid: use public keys to set up a secure channel and then Work f
m5 : [ C; t gKCS ; fhC; S igKS ; request; n℄

authenticate m6 : [ service; fngKCS ℄

Client C Server S

K ERBEROS 29 K ERBEROS 30
 root CA
root CA Kpub
C1 CA
C1 Kpub
C2 CA
➜ Central KDC contains 0 signature root C2 Kpub
Alice
• Authentication service A, signature C1 Alice Kpub
3
knows all user logins and their passwords (secret keys) signature C2
2
as well as identity and key of T ;
Bob
• Ticket granting service T , 1
Slide 61 knows all servers and their secret keys Slide 63
Checking of certificates is recursive:
➜ Kerberos protocol has three phases: ➜ To establish trust in Alice’s certificate signed by C2 , Bob may
➀ login session setup (user authentication)
need to obtain C2 ’s certificate
➁ server session setup (establishing secure channel to server)
➜ Bob uses the public key of C2 to validate Alice’s certificate
➂ client-server RPC
➜ C2 is signed by C1
➜ Uses time-limited tickets
➜ This may lead to a chain of certificates
➜ Terminated by self-signed certificate of a root certification
authority (who Bob trusts)

D ISTRIBUTION OF P UBLIC K EYS

Major weakness of Needham-Schroeder and Kerberos:
➜ Key distribution centre as a central authority
➜ Compromised keys can be used to decrypt past
How to communicate certificates to clients?
communication ➜ Secure channel between certificates server and client?
➜ Digital signatures establish the validity of certificates
Public Key Infrastructure (PKI):
➜ Formatted according to X509.1 standard or PGP format
Slide 62 ➜ Public keys can be exposed without risk Slide 64
➜ Distribution centre only establishes link between identities and Whose signature?
public keys ➜ Certification authorities sell certification as a service
➜ Alternatively, web of trust avoids any central authority
Certificates and certification authorities:
➜ A certificate links an identify with a public key
➜ Distribution centres are called certificate servers or certificate
directories

D ISTRIBUTION OF P UBLIC K EYS 31 D ISTRIBUTION OF P UBLIC K EYS 32

 Ensuring that authorisation and access control are
respected

Non-distributed Protection:
Are certificates valid forever? ➜ Global mechanisms
➜ Certificates may have an expiry date to reduce risk of security ➜ Global policies
breach ➜ Examples:
➜ After a certificate expires, a new one must be generated and
Slide 65 Slide 67 • Users
signed
• File permissions
➜ Alternatively, certificates may be revoked
• Separate address spaces
➜ Revocation is only effective if receiver regularly checks the
certificate server Distributed Protection:
➜ Service specific
• Web servers and .htaccess: authentication, access control
➜ Application specific

ACCESS C ONTROL M ATRIX

AUTHORISATION AND ACCESS C ONTROL Objects
Subjects O1 O2 O3 O4
Determine what actions an authenticated entity is
S1 terminate wait, signal, read
authorised to perform
send
Access Rights: S2 wait, signal, read, execute
➜ The rights required to access (perform an operation on) a given terminate write, control
Slide 66 Slide 68
resource S3 wait, signal,
receive
Two aspects:
S4 control execute write
Access Control: verify access rights

Authorisation: grant access rights

➜ Access permissions of a given subject to a given object
➜ Specifies allowed operations

AUTHORISATION AND ACCESS C ONTROL 33 ACCESS C ONTROL M ATRIX 34

 Access control lists (ACLs):

Object Subjects
Properties of the access matrix: S1 S2 S3 S4
➜ Rows define subjects’ protection domains /etc/passwd read read, write – read
➜ Columns define objects’ accessibility ➜ Column-wise representation of the access matrix
➜ Dynamic data structure: frequently changes ➜ Each object associated with a list of (subject, rights) pairs
Slide 69 Slide 71
• permanent changes (e.g. chmod) ➼ requires explicit authentication
• temporary changes (e.g. setuid flag) ➜ Usually supports concept of group rights (domain classes)
➜ Matrix is very sparse with many repeated entries (granted to each agent belonging to the group)
➼ usually not stored explicitly ➜ Often simplified to a simple fixed-size list
(e.g., UNIX user-group-others or VMS system-owner-group-world)
➜ Can have negative rights as well
(e.g., to simplify exclusion from groups)

Design considerations in a protection system:

➜ Propagation of rights:
➼ Can someone act as an agent’s proxy?
➜ Restriction of rights: Properties of ACLs:
➼ Can an agent propagate a subset of their rights?
➜ Propagation: meta-right to change ACL (e.g., owner can chmod)
➜ Amplification of rights:
➜ Restriction: meta-right to change ACL
➼ Can an unprivileged agent perform some privileged
Slide 70 Slide 72 ➜ Amplification: (e.g., setuid)
operations?
➜ Revocation: remove from ACL
➜ Revocation of rights:
➜ Object accessibility: explicit in ACL
➼ Can a right, once granted, be remove from an agent?
➜ Protection domain: hard (if not impossible)
➜ Determination of object accessibility
➼ Who has which rights on an object?
➜ Determination of agent’s protection domain
➼ What is the set of objects an agent can access?

ACCESS C ONTROL M ATRIX 35 ACCESS C ONTROL M ATRIX 36

 Three basic approaches to making caps tamper-proof:
Capabilities: ➜ Tagged capabilities:
➜ An element of access matrix • protected by hardware (tag bit)
➜ Capabilities list (C-list) associated with each subject, which • controlled by OS (only kernel can turn on tag bit)
defines a protection domain • used in most historical capability systems (Plessey 250, CAP,
➜ Each capability can confer a single or a set of rights Hydra, System/38)
Slide 73 ➜ Capabilities can confer negative rights Slide 75 ➜ Partitioned (segregated) capabilities:
➜ Capabilities must be protected against forgery and theft • protected by OS: Capabilities kept in kernel space
➜ Capability used as an object name: • used in Mach, Grasshopper, EROS, seL4
• evidence of access permission ➜ Sparse capabilities:
• independent of authentication • protected by sparseness (obscurity)
• don’t need to trust intermediary • used in Monash Password Capability System, Amoeba,
Mungi

Signature capabilities:

Object ID Access rights

Properties of capabilities:
➜ Propagation: copy capability (but need to be careful about
confinement)
E(K,C) Encrypted capability
➜ Restriction: may be supported by derived capabilities
Slide 74 ➜ Amplification: may have amplification capabilities
Slide 76
➜ Revocation: difficult, requires invalidation
➜ Object accessibility: hard (if not impossible) Object ID Access rights Signature

➜ Protection domain: explicit in C-list

V tamper proof via encryption with secret kernel key
V can be freely passed around
X need to encrypt on each validation

ACCESS C ONTROL M ATRIX 37 ACCESS C ONTROL M ATRIX 38

 H OW TO B REAK S ECURITY ?
Password capabilities:
Encryption:
➜ Invented for Monash U’s Password Capability System
➜ find weaknesses in algorithms
➜ “Random” bitstring is password, not derived from other parts of
➜ find weaknesses in implementations
capability.
➜ attack underlying intractable problem
➜ Validation requires checking against global object table.
➜ brute force
Object ID Password Protocols:
Slide 77 Slide 79
➜ try man-in-the-middle, reflection attacks
➜ find vulnerability in implementation
OID access password
Authentication:
➜ find keys or passwords
➜ social engineering

Global object table Authorisation and Access Control:

➜ find and exploit bugs to escalate privileges

F IREWALLS
Properties:
➜ When communicating with untrusted clients/servers ‘
➜ Disconnects part of system from outside world
➜ Incoming communication inspected and filtered R EADING LIST
Two types:
Slide 78 Slide 80 Ross J. Anderson Security Engineering: A Guide to Building
➜ Packet-filtering gateway
Dependable Distributed Systems. Covers many pitfalls of
➜ Application-level gateway
building secure systems, with many real-world examples.
Three Myths of Firewalls:
➀ We’ve got the place surrounded
➁ Nobody here but us chickens
➂ Sticks and Stones may break my bones, but words will never hurt
me

H OW TO B REAK S ECURITY ? 39 H OMEWORK 40

 H OMEWORK
Look up how protocols have been broken in the past. Find
examples where:
Slide 81
➜ the protocol was broken
➜ the cryptography was broken
➜ the implementation was broken

Slide 82

H OMEWORK 41