Upload
sylvia-ware
View
39
Download
2
Embed Size (px)
DESCRIPTION
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. Security Requirements Confidentiality Integrity Accountability Availability - PowerPoint PPT Presentation
Citation preview
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()