Chapter 9 Security - EJB Tutorial

1

Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

DISTRIBUTED SYSTEMSPrinciples and Paradigms

Second EditionANDREW S. TANENBAUM

MAARTEN VAN STEEN

Chapter 9Security


Security Threats, Policies, and Mechanisms

Security implies dependability, confidentiality, and integrity.

Types of security threats to consider:• Interception – an unauthorized party gains access

to data or service• Interruption – situation where data or service

becomes unavailable• Modification – unauthorized changig of data or

tampering with a service so that it no longer adheres to its spec.

• Fabrication – situation where data or activity generated that normally would not exist.


Security Threats, Policies, and Mechanisms

Security policy – describes which actions the entities in a system are allowed to take (and which are prohibited)

Security mechanism – way to enforce policy1. Encryption – data confidentiality, data

integrity2. Authentication – verify the claims of a user,

client, server or host3. Authorization – see if an authenticated client

is allowed to perform the requested action4. Auditing – logging access


Example: The Globus Security Architecture (1)

Globus is a system supporting large scale distributed computations computational grid

The Globus security policy consists of rules:• The environment consists of multiple

administrative domains.• Local operations are subject to a local domain

security policy only.• Global operations require the initiator to be

known in each domain where the operation is carried out.

2


Example: The Globus Security Architecture (2)

4. Operations between entities in different domains require mutual authentication.

5. Global authentication replaces local authentication.

6. Controlling access to resources is subject to local security only.

7. Users can delegate rights to processes.8. A group of processes in the same domain can

share credentials.


Example: The GlobusSecurity Architecture (3)

Figure 9-1. The Globussecurity architecture defines four protocols that implement the given policy


Design Issues

• Focus of control– data integrity– access control– role-based approaches

• Layering of security mechanisms – at what layer are the mechanisms implemented?

• Trusted Computing Base – set of all security mechanisms that are needed to enforce a security policy

• Simplicity


Focus of Control (1)

Figure 9-2. (a) Protection against invalid operations –emphasis is on data integrity.

3



Figure 9-2. (b) Protection against unauthorized invocations. Typically relies on access control mechanisms



Figure 9-2. (c) Protection against unauthorized users. Roles define what type of access users have.


Layering of Security Mechanisms (1)

Figure 9-3. The logical organization of a distributed system into several layers.


Distribution of Security Mechanisms

Figure 9-5. The principle of RISSC (Reduced Interfaces for Secure System Components as applied to secure distributed systems.

4


Cryptography (1)

Figure 9-6. Intruders and eavesdroppers in communication.


Cryptography • Sender uses encryption key EK on plaintext P:

C = EK(P) • Receiver uses decryption key DK on C to recreate P:

P = DK(C)

• Passive listener cannot easily read messages it sees• Active intruder cannot easily alter or create messages without

detection.

• Symmetric cryptosystem: single key such that P = K(K(P))

• Asymmetric cryptosystem requires two keys such that P = DK(EK(P)). One key is public; other is private.

• Text talks about DES, RSA, MD5 and hashing based approaches. We will only talk about RSA.


RSA Encryption - 1

RSA – named after inventers Rivest, Shamir and Adleman (1978)

Relies on the fact that no methods are known to efficiently find the prime factors of large numbers.

Asymmetric system: Public & private keys are constructed from very large prime numbers (hundreds of decimal digits).


Public-Key CryptosystemsIn the scenarios below, both A and B have

public and private keys• If A wants to send a confidential message to

B, the message should be encrypted using B’s public key (hence only B can decrypt).

• If B wants to be sure that a message received is from A, A encrypts using its private key. If B can successfully decrypt using A’s public key, it is authentic.

• If A sends a message to B that is first encrypted with B’s public key and then with A’s private key, the result is a confidential message that B can authenticate.

5


RSA Encryption - 2To find a key pair e, d: 1. Choose two large prime numbers, P and Q (each greater than 10100), and

form:N = P x Q Z = (P–1) x (Q–1)

2. For d choose any number that is relatively prime with Z (that is, such that dhas no common factors with Z).

We illustrate the computations involved using small integer values for P and Q:

P = 13, Q = 17 –> N = 221, Z = 192 d = 5

3. To find e solve the equation:e x d = 1 mod Z

That is, e x d is the smallest element divisible by d in the series Z+1, 2Z+1, 3Z+1, ... .

e x d = 1 mod 192 = 1, 193, 385, ...385 is divisible by de = 385/5 = 77


RSA Encryption - 3To encrypt text using the RSA method, the plaintext is divided

into equal blocks of length k bits where 2k < N (that is, such that the numerical value of a block is always less than N; in practical applications, k is usually in the range 512 to 1024).

k = 7, since 27 = 128 (N = 221)The function for encrypting a single block of plaintext M is:

E'(e,N,M) = Me mod Nfor a message M, the ciphertext is M77 mod 221

The function for decrypting a block of encrypted text c to produce the original plaintext block is:

D'(d,N,c) = cd mod N


Secure Channels - 1Client/server systems rely on the idea of a

secure channel between a client and a server:

– Authentication of communicating parties, message integrity, confidentiality

– Determining whether a client is authorized to perform the given request.

– Secure channels set up with authentication as part of the process.

– One option is for the client and server to share a secret key and use challenge-response protocols to authenticate.


Authentication Based on a Shared Secret Key (1)

Figure 9-12. Challenge-response protocol that assumes A and B already share a secret key KA,B.

A wants to set up a secure channel with B.

6



Figure 9-12. Challenge-response protocol that assumes A and B already share a secret key KA,B. RB is a random number challenge.

B verifies that it is talking to A if A can correctly encode the challenge number.



Figure 9-12. Protocol completes with A issuing a challenge to authenticate B.



Figure 9-13. Authentication based on a shared secret key, but using three instead of five messages. This ‘optimization’ is open to a reflection attack.



Figure 9-14. The reflection attack where C (Chuck) tries to convince B (Bob) of identity A (Alice).

C does not know KA,B and cannot answer the challenge.

7



Figure 9-14. C starts a new session with B where it now uses B’s challenge number.



Figure 9-14. Now C knows the answer to B’s challenge and can complete the protocol. Note that this can’t happen with the original challenge-response protocol.


Secure Channels - 2Session keys –

• Shared secret key that is used to encrypt message for integrity.

• Typically, only used as long as the channel exists – destroyed when channel is closed.

• One benefit is that if the secret key is compromised, the damage is limited to a single session.

• Also, the less time a key is used, the less likely it will be revealed to the wrong party. The more messages that exist using a particular key, the more likely that it will be broken.

• Needs to be a secure way to generate this session key – Trusted third party can be used.


Key Distribution Center (KDC)• Trusted third party• Each host shares a single key (KX, KDC ) with

the KDC (but not with each host unless actively communicating)

• Scalability: Assume N hosts, without a system like this, :

– Each host must manage n-1 keys (one for each other host)

– Total # keys: N(N-1)/2

• Responsible for assigning session key KA,B–for each session between A and B

8


Authentication Using a Key Distribution Center (1)

Figure 9-15. The principle of using a KDC. When A wants to communicate with B, the KDC generates a session secret key which it passes to A and B



Figure 9-16. Using a ticket and letting Alice set up a connection to Bob. This ensures that Bob gets the shared key before A starts sending messages.



Figure 9-17. The Needham-Schroeder authentication protocol. 1) A requests a session with B. The KDC returns a newly generated shared key along with a ticket for B.

requested session key

nonce – random number to serve as session id(makes replay attacks more difficult)

Including B’s identity in reply means a third party can’t tamper with message 1 and have the KDCset up a session with someone else.



Figure 9-17. The secure channel is set up. A starts with sending the ticket along with a challenge that only B should be able to decode.

requested session key

9



Figure 9-17.

B shows that it decrypts the challenge (showing it could acquire the shared key from the ticket) and issues one of its own



Figure 9-17.



Figure 9-18. One weakness in the protocol is that the keys between hosts and the KDC can be compromised and used for replays. To protect against this, we can have B and the KDC associate a nonce with each key. In the above, A is requesting this

information from B in order to set up the channel.Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5


Figure 9-18. A includes the information from B in the session key request. The KDC includes this in the ticket for B so that B will know that A’s

information comes from a current request for a session.

10



Figure 9-18.


Authentication in a PKI system

Figure 9-19. Public key systems can also be used to generate session keys using mutual authentication.


SSL – Secure Socket Layer

Figure 12-22. SSL, which was never formalized, resulted in the TLS (Transport Layer Security) protocol for secure channels. The position of TLS in the Internet protocol stack.


SSL protocol

Figure 12-23. TLS with mutual authentication.

Phase 1: agreement on the characteristics of the channel

Phase 2: server andeach authenticateusing a certificatecontaining their publickeys. Client generates a random session number encrypted withserver’s public key.This session number isused for constructing asession key.

11


Digital Signatures• Message integrity

– Think e-commerce!– If A sends a message to B over a secure channel,

there is no assurance that B won’t modify the message later and make claims about A.

– B may need to be sure that A won’t later deny sending the message.

• Digital signatures provide assurances– using PKI on entire message– can sign a message digest (less expensive than

encrypting a large message)• Issues:

– What happens when public/private keys are changed?Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Digital Signatures (1)

Figure 9-20. Digital signing a message using public-key cryptography. B knows the message came from A since it was encoded with KA (B can keep a copy). A is protected from tampering as well.

-


Digital Signatures (2)

Figure 9-21. Digitally signing a message using a message digest. The message m can be in plain-text accompanied by KA(H(m))-


Securing Process Groups• It is often necessary to set up secure

communication within a process group. • Using a single shared key for this implies

that all members of the process group can be trusted.

– One solution is to use keys between each pair but scalability may be an issue.

– Can use public/private keys for each member – this scales better

• In either case, if one member of the group proves trustworthy, it can be removed from the communication without compromising any other keys

12


Secure Replicated Servers (1)• Client issues request to a group of replicated

servers. What happens if one or more of these servers has been successfully corrupted?

• Client could collect responses from all servers and uses majority – sacrifices replication transparency.

• In secret sharing between multiple entities, no single entity knows the entire secret which is only available if all the parts pool their answers.

• At most k of the N replicated servers can produce an incorrect answer, and of those k, at most c <= k have been corrupted k fault tolerant.


Secure Replicated Servers (2)

Figure 9-22. Assuming we want to be able to tolerate as many as 2 corruptservers (of the 5), the client chooses 3 signatures to consider.


Access Control (1)Once secure communication between a client

and server has been established, we now have to worry about access control – when the client issues a request, how do we know that the client has authorization?

Figure 9-25. General model of controlling access to objects.


Access Control Mechanisms

Figure 9-26. Comparison between ACLs and capabilities for protecting objects. (a) Using an ACL. (b) Using capabilities

13


Protection Domains

Figure 9-27. The hierarchical organization of protection domains as groups of users. Rights are associated with different parts of the hierarchy. A related approach is the use of roles.


Firewalls

Figure 9-28. Firewalls serve as a specialized type of reference monitor, only letting some things through.


Mobile Code (1)Securing mobile code involves protecting the local site from code

created remotely. – ‘Sandboxes’ allow downloaded programs to be run in such a

way that each executed instruction is carefully controlled either by static analysis before executing the code or by inserting dynamic checks (or both).

– Java uses byte code verification, specialized loaders for remoteclasses, and a security manager

• byte code verifiers – check Java byte code for illegal instructions or for parts of the code that do not conform to some format standards.

• specialized loaders – prohibit certain types of instructions that may allow things like additional loading of (potentially unchecked) classes

• Security manager – runtime checks – acts as a reference manager.

• The text discusses various ways to implement security policy: capabilities, stack introspection, name space management.


Protecting the Target (1)

Figure 9-29. Java Sandbox

14


Protecting the Target (2)

Figure 9-30. A playground is a separate designated machine that can be used to run untrusted code.


Denial of Service attacks• Bandwidth depletion

– Typically accomplished by sending many message to a single machine, making it difficult for the normal messages to be processed.

• Resource depletion– Attempting to tie up resources that are needed by normal

processes.

• One thing that makes the problem particularly difficult is that attackers use innocent users by secretly installing code on their machine.

• Detecting/stopping DoS attacks typically involves monitoring of message traffic.


Web-based SecurityXML Security Specifications: Signature, Encryption, and Key

Management (W3.org)• XML Signature - XML compliant syntax used for representing

the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures

• XML Encryption - develop a process for encrypting/decrypting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intended recipient to decrypt it.

• XML Key Management (XKMS) - developed a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, management or trust data) from a web service. PKI based. Major players: Microsoft, Verisign


Web-based SecuritySecurity Assertion Markup Language (SAML)

– XML exchange of authentication and authorization information – Enabling technology for single-sign-on– OASIS – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

XML Trust Axiom Markup Language (XTAML)– Layered on SAML– Delegation, online-verification of trust– Verisign (not sure if this is still ‘live’)

XML Access Control Markup Language (XACML)– XML specification for expressing policies for information

access– Can deal with both coarse- and fine-grain access policies– OASIS – http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

Chapter 9 Security - EJB Tutorial

Documents

Transcript of Chapter 9 Security - EJB Tutorial