Distributed Systems

1
Distributed Systems

• lecture 14 - 06/11/07
• Security

2
Worst case assumptions and design guidelines

• Interfaces are exposed
• Networks are insecure
• Limit the lifetime and scope of each secret
• Algorithms and program code are available to
  attackers
• Attackers may have access to large resources
• Minimize the trusted base

3
Scenario 1 Secret communication with a shared
secret key

• Alice and Bob share a secret key KAB.
• Alice uses KAB and an agreed encryption function
  E(KAB, M) to encrypt and send any number of
  messages MiKAB to Bob.
• Bob reads the encrypted messages using the
  corresponding decryption function D(KAB, M).
• Alice and Bob can go on using KAB as long as it
  is safe to assume that KAB has not been
  compromised.

• Issues
• Key distribution How can Alice send a shared key
  KAB to Bob securely?
• Freshness of communication How does Bob know
  that any Mi isnt a copy of an earlier
  encrypted message from Alice that was captured by
  Mallory and replayed later?

4
Authentication Based on a Shared Secret Key
5
Authentication Based on a Shared Secret Key

• The reflection attack.

6
Scenario 2 Authenticated communication with a
server

• Bob is a file server Sara is an authentication
  service. Sara shares secret key KA with Alice and
  secret key KB with Bob.
• Alice sends an (unencrypted) message to Sara
  stating her identity and requesting a ticket for
  access to Bob.
• Sara sends a response to Alice. TicketKB,
  KABKA. It is encrypted in KA and consists of a
  ticket (to be sent to Bob with each request for
  file access) encrypted in KB and a new secret key
  KAB.
• Alice uses KA to decrypt the response.
• Alice sends Bob a request R to access a file
  TicketKB, Alice, R.
• The ticket is actually KAB, AliceKB. Bob uses
  KB to decrypt it, checks that Alice's name
  matches and then uses KAB to encrypt responses to
  Alice.

A ticket is an encrypted item containing the
identity of the principal to whom it is issued
and a shared key for a communication session.

7
Authentication Using a Key Distribution Center

• a ticket.

8
Authentication Using a Key Distribution Center

• The Needham-Schroeder authentication protocol.

9
Authentication Using a Key Distribution Center

• Protection against malicious reuse of a
  previously generated session key in the
  Needham-Schroeder protocol.

10
The NeedhamSchroeder secret-key authentication
protocol
NA is a nonce. Nonces are integers that are added
to messages to demonstrate the freshness of the
transaction. They are generated by the sending
process when required, for example by
incrementing a counter or by reading the
(microsecond resolution) system clock.
Weakness Message 3 might not be fresh - and KAB
could have been compromised in the store of A's
computer. Kerberos addresses this by adding a
timestamp or a nonce to message 3.
11
Mutual authentication in a public-key
cryptosystem.

• Mutual authentication in a public-key
  cryptosystem.

12
Scenario 3 Authenticated communication with
public keys

• Bob has a public/private key pair ltKBpub, KBprivgt
• Alice obtains a certificate that was signed by a
  trusted authority stating Bob's public key KBpub
• Alice creates a new shared key KAB , encrypts it
  using KBpub using a public-key algorithm and
  sends the result to Bob.
• 3. Bob uses the corresponding private key KBpriv
  to decrypt it.
• (If they want to be sure that the message hasn't
  been tampered with, Alice can add an agreed value
  to it and Bob can check it.)

• Mallory might intercept Alices initial request
  to a key distribution service for Bobs
  public-key certificate and send a response
  containing his own public key. He can then
  intercept all the subsequent messages.

13
Digital Signatures

• Digital signing a message using public-key
  cryptography.

14
Digital Signatures

• Digitally signing a message using a message
  digest.

15
Scenario 4 Digital signatures with a secure
digest function

• Alice wants to publish a document M in such a way
  that anyone can verify that it is from her.
• Alice computes a fixed-length digest of the
  document Digest(M).
• Alice encrypts the digest in her private key,
  appends it to M and makes the resulting signed
  document (M, Digest(M)KApriv) available to the
  intended users.
• Bob obtains the signed document, extracts M and
  computes Digest(M).
• Bob uses Alice's public key to decrypt
  Digest(M)KApriv and compares it with his
  computed digest. If they match, Alice's
  signature is verified.

16
notation
17
Birthday attack

• 1. Alice prepares two versions M and M' of a
  contract for Bob. M is favourable to Bob and M'
  is not.
• Alice makes several subtly different versions of
  both M and M' that are visually indistinguishable
  from each other by methods such as adding spaces
  at the ends of lines. She compares the hashes of
  all the versions of M with all the versions of
  M'. (She is likely to find a match because of the
  Birthday Paradox).
• When she has a pair of documents M and M' that
  hash to the same value, she gives the favourable
  document M to Bob for him to sign with a digital
  signature using his private key. When he returns
  it, she substitutes the matching unfavourable
  version M', retaining the signature from M.

18

• If our hash values are 64 bits long, we require
  only 232 versions of M and M on average.
• This is too small for comfort. We need to make
  our hash values at least 128 bits long to guard
  against this attack.

19
(No Transcript)
20
example

• a secure and transparent interaction with a
  (replicated) server some of the replica are
  faulty/corrupted
• hint.distributed secret ?

21

• Group communication
• A unique secret key
• pairs of secret key
• Public key cryptosys
• Majority mechanism authentication

22

• Secret sharing
• N server, k out of N produce incorrect answer and
  c lt k are corrupted
• Design requirement tolerate c corrupted replicas

23
first solution

• Consider all the combination of (N-c) answers
  from the N replicated server
• Find an ri such that all the N-c server agree

24
Secure Replicated Servers

• Sharing a secret signature in a group of
  replicated servers.

25
second solution

• Broadcast solution among servers
• Compute signature from c1 messages
• Send the answer and the set of signatures

26
General Issues in Access Control

• A general model

27
a matrix-based solution
28

• Space problems due to scalability
• A two approaches
• Column-wise
• Row-wise

29
..ACL

• an Access Control List is a key allowing the
  object to know the subjects that want to access
  its method.
• Format ltsubject id, required operationsgt
• Problems eavesdropping, difficulty of
  cancellation

30
a simple implementation

• Like the Unix file access permissions

drwxr-xr-x gfc22 staff 264 Oct 30 1657
Acrobat User Data -rw-r--r-- gfc22 unknown
0 Nov 1 0934 Eudora Folder -rw-r--r-- gfc22
staff 163945 Oct 24 0016 Preview of
xx.pdf drwxr-xr-x gfc22 staff 264 Oct 31
1309 iTunes -rw-r--r-- gfc22 staff 325
Oct 22 2259 list of broken apps.rtf
31
Access Control Matrix

• Using an ACL for protecting objects.

32
Capability

• a capability is a key allowing the holder to
  access one or more of the operations supported by
  a resource.
• Format ltresource id, permitted operations,
  authentication codegt
• Problems eavesdropping, difficulty of
  cancellation

33
Access Control Matrix

• Using capabilities for protecting objects.

34

• For more complex object types and user
  communities, ACLs, as well as capabilities, can
  become very complex and very difficult to manage

35
Access control

• Protection domain
• A set of ltresource, rightsgt pairs

36
Protection Domains

• The hierarchical organization of protection
  domains as groups of users.

37

• certificates
• roles

38
Firewalls

• A common implementation of a firewall.

39

• packet filtering gateway
• application-level gateway
• proxy gateway

40
(No Transcript)
41
Modalità desame e appelli

• ... Esame orale classico, negli appelli
  ufficiali...(dicembre-gennaio, marzo,
  agosto-settembre)
• Lesame consiste in una prova orale
• Ogni studente può sempre scegliere la modalità
  standard
• nessun vincolo alla partecipazione ai 5 appelli

42
... in alternativa ...

• Prova scritta, mercoledì 28 novembre alle 8.30
  (durata 1 ora e mezza), aula Be
• Approfondimento relativo ad un articolo
  scientifico apparso su conferenze recenti (2007)

43

• Presentazione 25 minuti 5 minuti per domande.
  in sessioni di 6 presentazioni, a partire dal 10
  dicembre, con calendario da concordare ...
• Si valuta
• la comprensione
• Linquadramento nella letteratura corrente
• la valutazione critica

44

• Individuato larticolo di interesse, inviare una
  mail al docente e attendere una conferma
  definitiva
• via email...subject SD07
• Entro il 26 novembre
• Pubblicazione calendario ...ultima settimana di
  lezione

45
alcune conferenze

• Twenty-Sixth Annual ACM SIGACT-SIGOPS Symposium
  on Principles of Distributed Computing (PODC
  2007) http//www.podc.org/podc2007/
• ICDCS 2007 The 27th International Conference on
  Distributed Computing Systems http//www.eecg.utor
  onto.ca/icdcs07
• OPODIS'07, 11th International Conference On
  Principles Of Distributed Systems
• The Thirteenth International Conference on
  Parallel and Distributed Systems (ICPADS 07)

46
Some topics ...

• Ubiquitous Computing
• Web Services
• Peer-to-peer Computing
• Collaborative Computing
• Pervasive Computing
• Cluster Computing
• Distributed Agents
• Distributed Databases

47
...more topics...

• Distributed Storage
• Distributed Media
• Distributed Sensing
• Distributed Algorithms
• Distributed Filesystems
• Grid computing
• Globus
• Real-Time and Embedded Systems

48
... more and more topics

• Software architectures
• Application deployment
• Languages
• Extension to shared memory
• Dependable Systems
• Massively parallel systems
• Mobile and wireless issues
• Security issues
• .........

49
Distributed Systems

• End of lecture 14