1. Distributed Systems: Security CS 654 Lecture 21 December 4, 2006
2. Authentication Using Public Key Cryptography What could happen if K+B (public key) is fake?
How can we assure that it is not?
Is there some way to digitally “sign” a piece of information?
3. Message Integrity Suppose you are conducting a transaction through e-mail, and Alice promises to buy your fake moustache collection for $500.
Your girlfriend said only a loser would have a fake moustache collection.
Say you send Alice your collection, and she said you $300 check. You are being ripped-off. How can you prove that she agreed to $500?
Say that you try to get back at her, and claim that she actually offered $700. How can she prove that she only offered $500?
Two things need to be taken care of:
You can’t claim that she actually offered $700.
She can’t deny sending the offer.
4. Digital Signatures How can you verify that a document is real?
What do we use in the real world?
What if we really need to be certain?
What if it were encrypted with the private key of of the sender?
You could decrypt it with A’s public key. If it decrypted properly, then A must have encrypted it.
5. Digital Signatures Signing by encrypting the whole message.
6. Optimization Encrypting with PKC is slow. Can we leverage hashes somehow?
Compute hash of the message (message digest). Encrypt the hash.
This known as a digital signature.
7. Digital Signatures Signing just the hash.
8. Secure Replicated Servers Figure 9-22. Sharing a secret signature in a group of replicated servers.
9. Example: Kerberos Ticket Granting Service (TGS), and Authentication Server (AS).
A ticket is a special message used to convince a server that the client is who he or she claims to be.
User A and AS share a secret key (derived from password). AS and TGS share a key.
10. Setting Up A Secure Channel First send message to Bob, with timestamp to prevent replay attacks.
Bob sends back, also to prevent replay attacks.
11. Access Control
12. Access Control Imagine a server with a number of entities (which we will call objects) under its control. Requests come in, but are allowed only if the sender has sufficient access rights.
Authorization is how to grant rights. Access control is how to verify rights. Very similar, and frequently used interchangeably.
13. General Model Reference monitor is like a security perimeter.
14. Access Control Matrix To model the rights, use a matrix. Each row is a subject, each object is a column. So M[s,o] is an entry, which contains the allowed methods.
15. Access Control Lists Matrix is large, and often empty. So use a list instead, granting or removing rights.
Bob, read Alice, write Chuck, check timestamp
16. Capabilities ACLs require the server to keep track. This can be cumbersome, especially if the authority granting rights is different.
Capabilities grant rights, they are like a “ticket”, or a voucher.
If you have the capability, you are allowed the operation.
How can we implement this? PKI? Kerberos?
17. Protection Domains Figure 9-27. The hierarchical organization of protection domains as groups of users.
18. Firewalls Figure 9-28. A common implementation of a firewall.
19. Mobile Code Suppose you have an agent moving around for you, trying to find the best airplane ticket, visiting different airlines.
As the mobile agent moves around, who/what might need protection?
20. Protecting Mobile Agents Can we protect a mobile agent from being destroyed?
How about detecting modifications?
Suppose you are sending an agent out to book airline tickets. Your agent first goes to Chuck’s Cheap Planes, then will go to Alice’s Safety-Last. Could Chuck change your agent so that it will think it already went to Alice’s?
Detect changes to read-only state.
Sign the state, so when it arrives, can detect modifications. How good?
Cannot detect if it was using this during execution, though.
Append only logs.
Initially, log is empty: Cinit = K+owner(N)
If a server S appends new data X, S appends X to log, and computes new checksum: Cnew = K+owner(Cold, sig(S, X), S)
Selective revealing of state.
Provide an array of data items. Each entry is only for a designated server, and is encrypted with that servers public-key.
21. Protecting the Target (Host) What kinds of malicious mobile code might attack your computer?
“Applets”, ActiveX controls, etc.
How do you protect your computer against malicious mobile code?
Sandboxing: two steps
Make sure that retrieving the remote code is secure (secure classloader).
Verifying the byte code
What could happen if the first step was not secure?
22. Protecting the Target Class loaders are trusted, verified.
Class verifier to make sure that no illegal things are done. Such as?
A security manager is used at run-time. What will it allow/disallow?
What if it needs local files for state, etc.?
A sandbox is very restrictive. “Jail” is probably a better term.
23. Playgrounds It makes sense that an untrusted agent should be able to create a file in its own space. Playgrounds allow a group of untrusted agents to create and use local resources.
Should it be a separate machine?
Another policy is to authenticate source, and use a specific security policy based on source. In other words, tailor the sandbox to the degree of trust. If very trusted, then no need for sandbox.
24. Object References as Capabilities This fine-grained control might be implemented using capabilities via object refs.
25. Stack Introspection How about more fine-grained?
All calls to a method m of a resource first call enable_privilege to check authorization. Upon return, call disable_privilege.
Java interpreter can handle this automatically.
Can also use this to check chains. Suppose O1 can call O2, but the specific method is not allowed to the original invoker of O1. Stack introspection can check this.
26. Distributed Denial of Service What is it?
Can be classified into two kinds, roughly. Denying bandwidth and hogging up server resources.
How does a typical DDoS work? How can we protect against them?
27. Distributed Denial of Service No single way to protect, need comprehensive plan.
Protect machines from getting taken over.
Monitor egress routers.
Monitor ingress (how well does this work?)
Monitor overall network.
28. Security Management
29. Key Establishment Figure 9-33. The principle of Diffie-Hellman key exchange.
30. Key Distribution (1) Figure 9-34. (a) Secret-key distribution. [see also Menezes et al. (1996)].
31. Public Key Distribution Earlier we talked about how we can be assured that a publiic key is genuine.
Public key distributed with authentication. Private with confidentiality and authentication.
32. PK Certificates How do we generate a PPK pair, for use in PKI? How do we verify that the public key is real?
User generates pair.
Encrypts cert request (containing public key) with public key of CA.
How do we know the public key is correct?
Send it to the CA.
CA decrypts it, then sends back a signed document.
A user, when it needs a public key for Bob, can now ask for a certificate. It computes the hash, then decrypts the hash in the cert with the public key of the CA. If there is a match, then the public key must be valid.
33. Digital Certificates Verification How can you verify that the public key you have for Bob is the real one?
Compute the hash. Decrypt the signature with the public key of the signer. If it matches, must be correct.
What would it take to break?
Can’t change, because don’t know private key.
Can we create a message that has the same hash?
34. Hierarchies of Trust Suppose you are a CA, and there are 1000 requests per week going to you from, say SUNY Albany. That is too many! What do you do?
Delegate. Tell them to be their own CA. What is the disadvantage?
Multiple trusted root CA certs.
Instead, use chains of trust.
35. Trust Chains There is no solution. Eventually you must trust.
So, use a chain of trust. Assume that you have the public key of the root authority, RA, and that you got it in a way that you trust it is correct.
If you have a PK of B, that you can verify was encrypted with RA’s private key, then RA vouches for the authenticity of B’s public key.
You can chain this trust, so RA encrypts RA1’s public key, RA1 encrypts RA2’s public key, etc.
36. Secure Group Management Figure 9-35. Securely admitting a new group member.
37. Capabilities and Attribute Certificates (1) Figure 9-36. A capability in Amoeba.
38. Capabilities and Attribute Certificates (2) Figure 9-37. Generation of a restricted capability from an owner capability.
39. Delegation (1) Figure 9-38. The general structure of a proxy as used for delegation.
40. Delegation (2) Figure 9-39. Using a proxy to delegate and prove ownership of access rights.