Security and Reliability Issues
in Distributed Systems
Chan Hing Wing, Anthony
MPhil Term 1,
CSE CUHK
December 11, 1998
Presentation Outline


Introduction
Distributed system security
 Common
requirements and
approaches
 The SSL protocol
 CORBA Security

Distributed system reliability
 Common
requirements and
approaches


Summary
Questions and Answers
Introduction
Distributed systems developed rapidly
over the past two decades

E.g., WWW, automatic teller machines,
distant learning

As distributed systems become widely
used, their security and reliability
becomes very important

Distributed Systems: hardware
(autonomous computers, the linking
network) and software (distributed
system software)
 Security and Reliability both have
hardware aspect and software aspect

Distributed System Security
Hardware Vs Software:

Hardware security: keys, locks, cards,
visitor monitoring, etc. (not main focus)

Software security:
(in terms of user requirements)
 integrity: message transmitted over network
must be identical to the original
 confidentiality: message transmitted must not
be readable to unintended entities
 availability: the system must not be
unavailable due to security attacks
 accountability: user actions that is securitycritical must be traceable
Common Approaches

Cryptography
encryption
Data
decryption
Secret-form data
The secret-form data must be unreadable
without prior knowledge of a secret / key
(confidentiality), but recoverable with
knowledge of the secret (availability)
Usually the secret-form data cannot be
decrypted successfully if it is tampered
it can be used to ensure the integrity of data,
(e.g., message authentication codes (MACs),
digital signatures)
Common Approaches

Cryptography (cont’d)
Secret-key cryptography: the same key is
used in encryption and decryption, e.g.,
DES, block/stream ciphers, MACs
 Public-key cryptography: different keys
are used, e.g., RSA, digital signatures
 Public keys (PK) Vs Secret keys (SK)

PK do not require distribution of shared
secret
 more convenient for distributed systems
 PK rely heavily on the computational
unfeasibility to solve some hard problems
(e.g., factoring, travelling salesman)
 breakable if these problems were solved

Common Approaches

Authentication
the process of verifying a claimed identity
 the entity to be authenticated may be a
person (e.g., in password checking), a
message (i.e., integrity) or a program (e.g.,
client/server authentication)
 usually make use of cryptography, in which
a secret (key) of the entity of the owner of it
is used to verify its identity
 authentication protocols

ways for two components in a DS to ensure
each other is the intended entity
 usually by negotiating a short-term key for
communication (e.g., Needham/Schroeder)

Common Approaches

Authorization / Access Control
the process of granting suitable rights to
legitimate users
 usually by means of access control lists
(ACLs) (e.g., permissions in UNIX NFS)


Logging

logging security-critical activities of
users (e.g., “su” logs in UNIX), so that
any internal security attacks can be
accounted for
The SSL protocol



Secure Socket Layer, by Netscape
Provides security for applications
over the insecure Internet
Overview:
Application 1
(e.g., telnet, ftp)
Application
data protocol
SSL handshake
protocol
SSL record protocol
Application 2
Application
data protocol
SSL handshake
protocol
SSL record protocol
Reliable transport protocol (e.g., TCP)
The SSL Protocol The Three Components

Record protocol






SSL handshake protocol



encapsulate higher level protocols
divide messages into blocks
compresses message blocks
applies MAC to message blocks
encrypts and transmits message blocks
allow the client to authenticate the server, and
the server to authenticate the client
negotiate an encryption algorithm and key for
application data transmission
Application data protocol

transmits data from applications to the record
layer, which then sends the data securely
The SSL Handshake Protocol
•An authentication protocol
•A sample session:
“Hello! I want to connect with you.
I understand encryption algorithms like DES, RC4, IDEA, etc.…”
“Hello, then let’s use DES.
This is my certificate. Please check. Please also send yours.”
CLIENT
(Client authenticate server by verifying server’s certificate...)
“Alright, here is my certificate, and I’ve generated a DES
master key. Here I encrypt it with your public key and send
it to you I’m finished..”
(Server authenticate client by verifying client’s certificate...)
(Server decrypts the DES key received from client…)
Ok, I received your key. I’m finished.
Data encrypted with the DES master key
.
.
.
SERVER
The SSL Protocol - Implementation

SSLeay






A commonly used implementation of the SSL protocol
(2.0 and 3.0)
Written by Eric Young in Australia
Contains library functions for making SSL
communications (e.g., SSL_connect, SSL_free,
SSL_get_certificate, SSL_get_cipher)
Includes many encryption algorithms:
 ciphers (e.g., DES, RC4, RC2, IDEA)
 digests (MD5, MD4, SHA-1)
 public keys (RSA, DSA, Diffie-Hellman)
Applications built on top of SSLeay: SSLtelnet, SSLftp,
SSLhttpd, etc., by Tim Hudson in Australia
Patches (< 100 K size) to some existing server and
client programs that support SSLeay
CORBA Security


Security is provided as a kind of CORBA
services (not part of the core ORB)
Two levels of security defined:
level 1: does not change IDL definition;
applications are unaware of the security
mechanism. Users may be authenticated
before calling an application, and then security
is enforced automatically during object
invocation
 level 2: new IDL definition introduced;
applications can make use of objects such as
credentials and Principal-Authenticators to
define their own security policies

CORBA Security

The security model:
User
Server
Client
requests
Message
protection,
access control
device, etc.
ORB
Security Implementation
enforcing security policy
Message
protection,
access control
device, etc.
•All object invocations are mediated by the
security implementation
•No specific security policy defined in the model,
so that a wide variety of different policies can be
defined according to different needs
CORBA Security

Principals


Human users or system entities (e.g., the
client acting for a user) registered in and
authentic to the system
Credentials




Each principal in a CORBA environment with
Security Service is associated with
credentials
Credentials contain security attributes of an
object, e.g., its identity and privileges (like
gate-passes)
Credentials are used for access controls,
authentication, etc.
An object may have several credentials,
representing privileges in different domains
CORBA Security
invoker

Delegation
Passing of credentials from one object to
another, so that the receiving object
(intermediate) can invoke a third object
(target) on behalf of the passing object
(invoker)
 Options of delegation:

Client credentials
intermediate
Client credentials /
intermediate
credentials / mixed,
according to different
options
targe
no delegation
 simple delegation
 composite delegation
 combined delegation
 traced delegation

CORBA Security

Non-repudiation service

provide services that make users / principals
accountable for their actions
Object A
Object B
Dispute/judgement
Non-repudiation service
Evidence
generation
&
verification

Evidence
storage
&
retrieval
Adjudicator
Delivery
Authority
Service
requests /
responses
Implementation: SSL services come with
Orbix; separate purchase for Visigenic
Distributed System Reliability

Reliability:
broad meaning (dependability):
 security
 availability
 fault tolerance
 recoverability
 correctness
 consistency
 timeliness
Reliability

A narrower definition (J. Stankovic):
Fault: a mechanical or algorithmic defect
which may generate an error
 Error: an item of information which will
produce a failure
 Failure: an event at which a system
violates its specifications
Reliability: the degree of tolerance
against errors and faults

Reliability
Hardware Vs Software:

Hardware reliability
 hardware
redundancy, high-quality IC,
wires, UPS, etc. (not main focus)

Software reliability
 fault
tolerance
 error recovery
 data / code redundancy
Common Approaches

Replication
keeping > 1 copies of data / programs in
system, increase availability
 Fault masking:



Majority voting:


masking out the effects of faults by data /
program redundancy in replicas
process requests on different servers, and
produce the most possible results by
voting on results from different servers
Crash recovery

E.g., by logging, checkpointing
Common Approaches

Reliable transmission protocols
 protocols
with error detection,
correction e.g., TCP/IP

Concurrency control
 locking
 ordering
Summary

Security requirements and
approaches in distributed systems
 The
SSL protocol
 CORBA Security Service

Reliability requirements and
approaches in distributed systems
Next Steps



Know more about distributed
system reliability
Study the CORBA Security Service
specification; investigate existing
implementations of the spec.
Probably implement a system that
demonstrates security & reliability
in the CORBA environment
The End
Questions and Answers session