Security Service 1

Security Service

Why do we need security in distributed system? Examples: banking, e-commerce, personal info, classified info

Distributed systems are inherently insecure network

Security Service 2

Security Service

Security Requirements Confidentiality Integrity Accountability Availability

threats to Security Gaining access directly Obtaining authorized user info and access Obtaining info through monitoring the comm. Channel Modifying messages on the comm. Channel Performing untraceable malicious actions Denying participations

Security Service 3

Security Service Categories of threats

Leakage: unauthorized disclosure of information Tempering: unauthorized modification of information Resource stealing: unauthorized use of computing resources Vandalism: destruction of information Combined threats

Methods of Attack Masquerading: obtain the identity of legitimate users Eavesdropping: listen to and decode request message Tampering : modify request messages Replaying: repetition of request messages Infiltration:

Attacks by legitimate users Obtaining a legitimate user’s identity Smuggling client or server objects, virus,worms

Security Service 4

Security Service

Security Service Features Identification and authentication Authorization and access control Auditing Communications security Non-repudiation Administration of security policy

Encryption Encryption uses an algorithm and a key to convert plain text into cypher text

and vice versa Secrete key Public key

Security Service 5

Secrete Key Encryption Secrete keys are known to two parties and not disclosed to any others Use the same key for both encrypting and decrypting messages Encryption and decryption functions may be public The encryption and decryption are performed after the stubs have completed

request marshalling and unmarshalling and it has been recognized that the server object is not local

Encryption can be kept entirely transparent for client and server programmer Encryption is done by middleware or by stubs that are created by middleware Distribution of secrete keys to large numbers of objects is too complex

Client A Server B

Caller Called

StubStub

1. Acquire Kab2. f(Kab, M) {M}kab3. send

{M}kab1. Acquire Kab2. Receive3. f’(Kab, {M}kab) M

Security Service 6

Public Key Encryption Public key encryption generate pairs of keys of which one is made publicly

available and the other is kept private Number of keys is only linear in relation to the number of objects The execution of encryption and decryption function is more complex

Client A Server B

Caller Called

StubStub

1. Acquire Kab2. f(Kpb, M) {M}kpb3. send

{M}kpb1. Generate (Kpb, Ksb)2. Publish Kpb3. Receive4. g(Ksb, {M}kpb) M

Security Service 7

Key Distribution Secure key distribution mechanisms are needed for both secret

and public key encryption Key distribution service

Service has to be a trusted service The registration of object with that service has to be trustworthy Needham/Schroeder protocol

Security Service 8

Key Distribution Distributing secrete keys

ClientC

ServerS

Key DistributionServer AS

1:C,S,NC

2:{NC, S, KCS, {KCS, C}KS}KC

3:{KCS, C}KS

4:{NS}Kcs

5:{NS-1}Kcs

Security Service 9

Key Distribution Distributing public keys

ClientC

ServerS

Key DistributionServer AS

1:C,S

2:{KPS, S}KSAS

4:S, C

5:{KPC, A}KSAS

3:{NC, C}KPS

6:{NC, NS}KPC

7:{NS}KPS

Security Service 10

Higher-Level Security Services

Security Service Features Firewalls Identification and authentication Authorization and access control Auditing Non-repudiation Communications security Administration of security policy

Security Service 11

Firewalls

Firewalls are gateways that tightly control message traffic between private and public networks

Levels of control can vary Monitor and audit network traffic Allow/disallow certain types of packet through Does not impact a distributed object systems if comm. does not pass through

firewall (both in private network, or both in public network, etc). Distributed object firewalls that understand the message traffic exchanged

between clients and servers Firewalls between distributed objects have to understand the encoding of

object request Firewalls have to be integrated with encryption techniques

FirewallPrivateNetwork

PublicNetwork

Security Service 12

Firewalls

Client Server

FWC1 FWC2 FWS1 FWS2

outbound firewalls inbound firewalls

enclave C1 enclave S2

enclave C2 enclave S1

Security Service 13

Types of Firewalls Packet Filtering

Allow all kinds of packets, but only to this IP address and this port Allow incoming traffic only from the specified IP subnets

Application-level gateways (Figure 12.4) CORBA and Firewalls

HTTP Tunneling: an IIOP request is enclosed in an HTTP envelope and sent via the HTTP protocol (Figure 12.5)

GIOP Proxies: callbacks

Security Socket Layer A protocol on top of TCP/IP that adds security capabilities SSL API is an extension to the TCP/IP socket API Encryption of messages Authentication of the server based on digital certificates and signatures Optional authentication of the cleint

Security Service 14

Authentication Authentication techniques establish trust in a principal and its

credentials Both client and server objects are necessary to be authenticated Authentication is implemented using encryption Challenge-response protocol

:Client :AuthenticationServer

authenticate()

challenge

response()

credentials

Security Service 15

Credentials

Credentials

Unauthenticatedattributes

authenticated attributes

Identityattributes

Privileges

Security Service 16

Access Control Access control mechanisms decide whether or not an object

request can be granted to a client object A principal is a human user or a system entity that is registered in and

authenticated to a system Credentials contain the security attributes of a principal Object invocation access policies determine whether a particular principal is

allowed to perform an object request Two forms of access policies:

Object invocation access policies are implemented by the object-oriented middleware

Application object access policies are enforced at an application level and implemented by the application developer

Security Service 17

Perspective on Access Control

Client’s perspective A request is either granted or not

Server’s perspective Object invocation access policy is used: access control is transparent to the

server programmer --- implemented by middleware Application object access policy is used: server programmer must implement

the access decision function. Input to the function is: Credentials of the principal that requested an operation execution Reference of the server object from which an execution is requested Request operation Parameters of the requested operation

Admin’s Perspective Object invocation access policy is not transparent to admin. Access rights define the modes of access that principals have to server objects Access rights are often defined for types rather than objects

Security Service 18

Security Service

Privileges and Privilege Delegation Scheme Own privilege Caller’s privilege Combined privilege

Use both Combine and generate new credentials

Security Service 19

Security Model

ORB Security ORB Security

Access Control Access Control

Secure InvocationSecure Invocation

ORB CORE

Binding

Client

Credentials

Current

Credentials

CurrentTargetObject

Security Service 20

Security Service

Security Model Clients, target objects, operation invocations Building request transmitting the request executing an operation

sending a reply Figure 12.8 Security Service is closely tied with ORB and is not an

independent object service, but an ORB service Security-aware applications vs Security-unaware applications

Principles and Security Attributes (Figure 12.9) Establish a security association:

usually, client trust, server authenticate Binding between client and target Security service provide current execution context (current)

Target object or Security Service decides operation permissions based on the current. (Access control …)

Auditing through auditing channel if required.

Security Service 21

Security Conformance Levels Security Conformance Levels

Level allows ORB security to be applied to applications that are not security-aware: authentication; security policies; provision of message integrity and confidentiality; access control policy

Level 2 = level 1 + enhanced integrity + trust + auditing

Security Service 22

Security Service Higher-Level Security Services

Firewalls: gateways that tightly control message traffic between private and public network

Authentication: establish trust in a principal and its credentials Access control: decide whether or not an object request can be granted to a

client object Client: request is either granted or not Server:

– Performed by middleware (invocation policy define on object)– Server application make access control decisions based on the data:

Request credentialsReferences to server objectsRequested operationsParameters to the requested operations

Admin:– Define the modes of access that principals have to server objects– Access rights are defined for types rather than objects

Security Service 23

Security Service

Non-repudiation Services Evidence Generation and Verification Evidence Storage and Retrieval Delivery Authority

Security Service 24

Non-repudiation Services

Nonrepudiation Services

Evidence Generation and Verification

Delivery Authority

Evidence Storage and Retrieval

AdjudicatorServiceReq./Rep.

Object A

Object BDispute/Judgement

Service Req./Rep.

Security Service 25

Security Service

Security Domains Security Policies:

Hierarchy Overlap Conflict

Finding the Security Features of an ORBGet_service_information()

Authentication of a User Principal Selecting Privileges

Credentials: get_credentials(); set_privileges()

Making a Security InvocationAccess_Decision object, access_allowed();

AuditDecision object, audit_needed(); audit_channel()

Security Service 26

Security Service

Non-repudiation Generate_token(): generate an unforgeable token to be used in the evidence Verify_evidence(): check if evidence is valid Form_complete_evidence(): use original token to generate further evidence,

Security Service 27

Security Service

Application Security Interfaces Common Security Types Security Level 1 (for security-unaware applications)

Interface Current:CORBA:Current{//PIDL

Security::AttributeList get_attributes(in Security::AttributeTypeList attributes);

};

For level 1, only allow the client to know what attributes are available

Security Level 2 (for security-aware applications)Current interface inherits the one form SecurityLevel1, extends functionality with

references to the following objects: RequiredRights, AccessDecision, AuditDecision, and PrincipalAuthenticator, and Credentials objects.

Security Service 28

Security Service RequiredRights

Get_required_rights() Set_required_rights()

PrincipalAuthenticator Get_supported_authen_methods(); Authenticate(); Continue_authentication();

Credentials Copy() Destroy() Get_security_feature() Get_attributes() Set_privileges(); Is_valid(); Refresh();

Security Service 29

Security Service

Object Get_policy() Get_domain_managers() Set_policy_overrides()