Wolfgang Security
Emmerich, 2000
12-1
Outline
Security Attacks s Encryption s Higher-level Security Services
s
s
Firewalls Authentication Access Control Non-Repudiation Security Auditing
Wolfgang Emmerich, 2000
Security Services in Object-Oriented Middleware
12-2
Security Attacks
Wolfgang Emmerich, 2000
12-3
1
Motivation
More vital/secret data handled by distributed components. s Security: protecting data stored in and transferred between distributed components from unauthorised access. s Security is a non-functional requirement that cannot be added as a component but has to be built into all components.
s
Wolfgang Emmerich, 2000
12-4
Why are Distrib. Systems insecure?
Distributed components rely on messages sent and received from network s Public Networks are insecure! s Is client component secure? s Is client component who it claims to be? s Are users of calling components really who they claim to be?
s
Wolfgang Emmerich, 2000
12-5
Effects of Insecurity
s
Confidential Data may be stolen, e.g.:
corporate plans. new product designs. medical/financial records (e.g. Access bills....).
s
Data may be altered, e.g.:
finances made to seem better than they are. results of tests, e.g. on drugs, altered. examination results amended (up or down).
Wolfgang Emmerich, 2000
12-6
2
Need for Security
Loss of confidence: above effects may reduce confidence in systems. s Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice. s Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record.
s
Wolfgang Emmerich, 2000 12-7
Threats
Categorisation of attacks (and goals of attacks) that may be made on system. s Four main areas:
s
s
leakage: information leaving system. tampering: unauthorised information altering. resource stealing: illegal use of resources. vandalism: disturbing correct system operation.
Used to specify what the system is proof, or secure, against.
12-8
Wolfgang Emmerich, 2000
Methods of Attack
Eavesdropping: Obtaining message copies without authority. s Masquerading: Using identity of another principle without authority. s Message tampering: Intercepting and altering messages. s Replaying: Storing messages and sending them later.
s
Wolfgang Emmerich, 2000
12-9
3
Infiltration
s
Launch of attack requires access to the system.
Launched by legitimate users. Lauchend after obtaining passwords of known users.
s
Subtle ways of infiltration:
Viruses Worms Trojan horses.
Wolfgang Emmerich, 2000
12-10
Encryption
Wolfgang Emmerich, 2000
12-11
Introduction
Cryptography: encode message data so that it can only be understood by intended recipient. s Romans used it in military communication s Given knowledge of encryption algorithm, brute force attempt: try every possible decoding until valid message is produced. s Computers are good at this! s Modern schemes must be computationally hard to solve to remain secure.
s
Wolfgang Emmerich, 2000
12-12
4
Cryptographic Terminology
Plain text: the message before encoding. Cipher text: the message after encoding. s Key: information needed to convert from plain text to cipher text (or vice-versa). s Function: the encryption or decryption algorithm used, in conjunction with key, to encode or decode message. s Key distribution service: trusted service which hands out keys.
s s
Wolfgang Emmerich, 2000 12-13
Encrpytion
Encrypting data prevents unauthorised access and modification to the data (i.e. prevents eavesdropping and tampering). s If encrypted data can only be decrypted with a matching key, this can be used to prove sender's identity (i.e prevents masquerading). s Likewise, it can be used to ensure that only intended recipients can use the data. s Two main ways: secret key & public key.
s
Wolfgang Emmerich, 2000 12-14
Secret Keys
One key is used to both encrypt and decrypt data s Encryption and decryption functions are often chosen to be the same s Security should not be compromised by making function well-known as security comes from secret keys
s
Wolfgang Emmerich, 2000
12-15
5
Using Secret Keys
Sender and recipient exchange keys through some secure, trusted, nonnetwork based means. s Sender encodes message using function and sends, knowing that only the holder of key (the intended recipient) can use it. s Recipient decodes message and knows that only sender could have generated it. s Message can be captured but is of no use.
s
Wolfgang Emmerich, 2000 12-16
Using Secret Keys in Object Request
Client A Caller Server B Called
Stub
AB 2. f(K ,M) -> {M} AB KAB 3. send 1. acquire K
Stub
1. acquire K
{M} KAB
AB 2. receive ) M 3. f -1 (K ,{M} A B KAB ->
Wolfgang Emmerich, 2000
12-17
Public Keys
Gives 'one-way' security. s Two keys generated, one used with decryption algorithm (private key) and one with encryption algorithm (public key). s Generation of private key, given public key is computationally hard. s Do not need secure key transmission mechanism for key distribution.
s
Wolfgang Emmerich, 2000 12-18
6
Using Public Keys
Recipient generates key pair. Public key is published by trusted service. s Sender gets public key, and uses this to encode message. s Receiver decodes message. s Replies can be encoded using sender's public key from the trusted distribution service. s Message can be captured but is of no use.
s s
Wolfgang Emmerich, 2000 12-19
Using Public Keys in Object Request
Client A Caller Server B Called
Stub
1. acquire KPB 2. f(KPB ,M)-> {M}K 3. send
Stub
1. generate (KPB ,KSB ) 2. publish KPB 3. receive 4. g(KSB ,{M}K ) ->M
PB
PB
{M}K
PB
Wolfgang Emmerich, 2000
12-20
Problem: How to distribute keys?
Key distribution by non-networked means is impractical for distributed object systems s Key distribution is a problem for both secret and public keys
s
Secret keys: Obvious Public keys: How do we know the principal that gives us a public key is who we assume the principal is?
s
Use trusted key distribution service and secure key distribution protocol!
12-21
Wolfgang Emmerich, 2000
7
Needham/Schroeder Protocol
Provides a secure way for pairs of components to obtain keys to be used during communication. s Based on an authentication server:
s
maintains a name and a secret key for each component. can generate keys for peer-to-peer communications.
s
Secret keys are used for communication with server.
12-22
Wolfgang Emmerich, 2000
Needham/Schroeder Protocol
s
For Secret Keys:
Key Distribution Server AS 2: {NC,S,KCS,{KCS,C}KS}KC 3: {KCS,C}KS Client C 4: {NS}KCS 5: {NS-1}KCS Server S
1: C, S, NC
Wolfgang Emmerich, 2000
12-23
Needham/Schroeder Protocol
s
For Public Keys:
1: C, S
Key Distribution Server AS 5: {KPC, A}KSAS
4: S,C
2: {KPS, S}KSAS
3: {NC,C}KPS Client C 6: {NC,NS}KPC 7: {NS}KPS Server S
Wolfgang Emmerich, 2000
12-24
8
Secure Socket Layer (SSL)
Secure Transport between Browser and Web-Server s Also used for object-oriented middleware s Based on RSA public key technology s Client generates secret session key s Client uses public key of server to encrypt session key and transmit it to the server s Session key is used to encrypt any communication between client and server
s
Wolfgang Emmerich, 2000 12-25
Higher-level Security Services
Wolfgang Emmerich, 2000
12-26
What's needed for secure requests?
Separating public and private networks (firewalls) s Establishing security association between client & server (authentication) s Deciding whether principal may perform this operation (access control) s Making the principal accountable for having requested the operation (auditing) s Protecting request and response from eavesdropping in transit (encryption) s Proving that you have delivered a particular service (non-repudiation)
s
Wolfgang Emmerich, 2000 12-27
9
Firewalls
Private Network
Firewall
Public Network
Wolfgang Emmerich, 2000
12-28
Firewalls
Firewalls are gateways that tightly control message traffic between private and public networks s Firewalls between distributed objects have to understand the encoding of object requests s Firewalls have to be integrated with the encryption mechanisms used to secure transport
s
Wolfgang Emmerich, 2000 12-29
What is Authentication?
Authentication: Proving you are who you claim to be. s In centralised systems: Password check at session start. s In distributed systems:
s
Use of authentication server or Based on ability to encrypt/decrypt a message (c.f. Needham/Schroeder Protocol)
Wolfgang Emmerich, 2000
12-30
10
Principals
Humans or system components that are registered in and authentic a to distributed system. s Principal has an identity used for:
s
Making principal accountable for its actions Obtaining access to a protected component Identifying the originator of a message Identifying who to charge for service provision.
12-31
Wolfgang Emmerich, 2000
Credentials
s
Information the system has about principals:
Credentials authenticated attributes unauthenticated (public) attributes
identity attributes
privilege attributes
Wolfgang Emmerich, 2000
12-32
Establishing Security Association
s
Involves
Establishing trust in one another's identities
Client authenticating server's identity Server authenticating client's identity
Making client credentials available to server Establishing the security context used for protecting requests and replies in transit (e.g. distributing private keys)
Wolfgang Emmerich, 2000
12-33
11
Authentication Server
s
Challenge-Response Protocol and its use for authentication
:Client authenticate() challenge() response() credentials() :Authentication Server
Wolfgang Emmerich, 2000
12-34
Access Control
Basic question addressed by access control: Can this operation be executed for the principal, who requested it? s Relies on authentication: It is assumed that principal and its credentials have been validated s Two forms:
s
Object invocation access policies Application object access policies
Wolfgang Emmerich, 2000 12-35
Object Invocation Access Policies
s
Access decision functions enforce object invocation access policies:
client-side access decision functions and/or server-side access decision functions
s
Decisions are based on
operation to be performed privilege attributes of principal control on principal's privilege attributes (e.g. time valid) server control attributes
Wolfgang Emmerich, 2000
12-36
12
Application Access Policies
In previous case access control is transparent to client and server objects s In this case client and/or server objects implement access control themselves s Application access policies
s
can take into account the particular data being accessed can take into account the semantics of request parameters
Wolfgang Emmerich, 2000 12-37
Access Control Privilege Attributes
s
Privilege attributes of principals for access control include:
principal's identity roles (related to the principal's job functions) groups (related to organizational structure in which principal is embedded) security clearance capabilities of server objects that the principal is allowed to use others...
Wolfgang Emmerich, 2000
12-38
Server Control Attributes
s
Access Control Lists (ACLs) identifying permitted users by
name or privilege attributes
Information for label-based schemes s Control attributes are generally shared by groups of operations of an object or even by groups of objects
s
Wolfgang Emmerich, 2000
12-39
13
Non-Repudiation
Makes principals accountable for their actions s Irrefutable evidence about events/actions is generated s Used to settle disputes about the occurrence or non-occurrence of an event s Example: Electronic commerce
s
Wolfgang Emmerich, 2000
12-40
Non-Repudiation Service
:Client :Adjudicator :Server
Non-Repudiation Service Evidence Generation and Verification Evidence Storage and Verification
Delivery Authority
Wolfgang Emmerich, 2000
12-41
Components of Evidence
Depend on non-repudiation policy. s Examples include:
s
Type of action or event A timestamp obtained from a trusted authority Parameters related to action or event Proof of origin of parameters
Wolfgang Emmerich, 2000
12-42
14
Common Types of Evidence
s
Proof of creation of a message
Protects against originator's false denial of having created a message
s
Proof of receipt of a message
Protects against receiver's false denial of having received a message
Wolfgang Emmerich, 2000
12-43
Security Auditing
Assists in detection of attempted or actual security breaches s By recording details of security relevant events
s
Writing event details into a log file Generating a security alert Taking other actions
s
Two levels of auditing
system-level application-level
Wolfgang Emmerich, 2000
12-44
Security Auditing Policies
Potentially a large number of events could be recorded s Security auditing policies restrict the set of events to those that are critical for the particular environment s System auditing policies log all security relevant events, even from security unaware applications
s
Wolfgang Emmerich, 2000
12-45
15
Security Services in ObjectOriented Middleware
Wolfgang Emmerich, 2000
12-46
Security Services
CORBA Security service provides most extensive support and implements the principles discussed above s Two levels
s
Level-1 Security is mandatory for compliance and needs to implement authentication, access control and auditing Level-2 Security is optional and concerns non-repudiation
Wolfgang Emmerich, 2000
12-47
CORBA Authentication
s
Credentials are lists of privilege attributes given to a principal:
Wolfgang Emmerich, 2000
interface Credentials { Credentials copy(); void destroy(); ... boolean set_privileges( in boolean force_commit, in AttributeList requested_privileges, out AttributeList...