CUGS: Distributed Systems. 1. CUGS: Distributed Systems ... Architecture issues
(Coulouris et al., Ch. 2) ... Most real-time systems are distributed. ▫ Inherently ...
CUGS: Distributed Systems
Distributed real-time systems
Contents – Lecture day #6
Distributed real-time systems n Issues, dependability concepts (Mullender, Ch. 16 ) n Architecture issues (Coulouris et al., Ch. 2)
n
Distributed real-time systems n n
Issues, dependability concepts Real-time communication
n
n
Security
n
n Authentication, confidentiality, cryptography Naming n Motivation, requirements, implementation
Spring 2005
n
CUGS: Distributed Systems
n
1
Real-Time System Components Operator
interface
Spring 2005
CUGS: Distributed Systems
2
Real-time system n Dependable n Time-constrained
Keyboard/display
I/O
Real-time communication issues (Mullender, Ch. 17) [recommended reading]
Real-Time Concepts
Operator interface Real-time controller
Event ordering Quality of Service
Storage, Other comm. netw., I/O RTC, etc.
n n
Predictable resource requirements Sufficiently efficient
Environment interface (special I/O) Environment
Spring 2005
Sensors/actuators
(c.f. B&W, Mull. fig. 16.2)
CUGS: Distributed Systems
3
Most real-time systems are distributed n Inherently, due to proximity / processes n To achieve fault tolerance => View as processing nodes + real-time communication system n Real-time protocol: must have known (sufficiently small) max. execution time CUGS: Distributed Systems
CUGS: Distributed Systems
4
Classification of Real-Time Systems by Use
Real-Time Concepts, cont.
Spring 2005
Spring 2005
5
Classification according to use (c.f. fig. 16.3) Soft R-T systems Real-time systems Hard R-T systems Spring 2005
High integrity
Telephone switching Online banking
Fail safe
Railroad control
Fail operational
Flight control
High availability
CUGS: Distributed Systems
6
Basic Dependability Attributes n
Reliability (absence of failure) n
n
n n
Hypothesis: Model DRTS by mapping to DS n physical reality -> computer world n sensors/actuators -> variables/registers n real time -> timestamps => apply known concepts for distribution
Prob. R(t) of continuous correct service at t
Safety (in case of failure) n
n
Prob. S(t) of no catastrophic failure at t
Maintainability (after failure) Availability (reliability + maintainability) Security (secrecy/integrity + availability) n n
Pay special attention to n physical interaction (special device I/O) n replica management, etc.
Prevent unauthorized access/damage Ensure authorized access to data
Spring 2005
CUGS: Distributed Systems
DRTS Model
7
Spring 2005
CUGS: Distributed Systems
Input: Environment state
E.g., temperature, pressure, position.
DRTS Model - Actors n
n
Real-time entity (sensor/actuator)
“physical sensor/actuator”
Representative: observes sensor entity, acts on actuator entity n
n
Sensors Distributed system
Real-time entity: environment state n
Representative (virtual node) Computing element (virtual node)
“I/O driver”
Computing element: processes sensor data, computes action, triggers actuators n
Spring 2005
Actuators
“control program”
CUGS: Distributed Systems
9
Spring 2005
CUGS: Distributed Systems
10
Event-state duality: Information flow in ET system
Event Triggered (ET) n Reacts (when required) to each stimulus directly, immediately Time Triggered (TT) n Reacts (when required) to accumulated stimuli at pre-specified instants
*
Event (e.g. sporadic, aperiodic)
R-T entity (sensor) Representative
*
(c.f. fig 16.10)
Information flows up to center
Message interrupts Computing element
S
State Representative
Use DRTS model to compare CUGS: Distributed Systems
E.g., valve pos., stepping motor, heating current.
Output: Environment state
Design Approaches/Paradigms
Spring 2005
8
Advantages + temporary overload + unexpected events Disadvantages - event showers
R-T entity (actuator) 11
Spring 2005
CUGS: Distributed Systems
12
Event-state duality: Information flow in TT system *
(c.f. fig 16.11)
Event (e.g. periodic)
R-T entity (sensor) S
Information is throttled in the periphery
Representative State fragment State messages
State Representative R-T entity (actuator)
Spring 2005
Advantages + no flooding + guarantees are feasible Disadvantages - a priori knowledge - inflexible
CUGS: Distributed Systems
Sensors, actuators, etc. Required properties n dependability n timeliness
Computing element S
Input/Output
13
Input/Output, cont.
Spring 2005
CUGS: Distributed Systems
Input/Output: Actuators 1(2)
Dependability: “Trusted” valve (fig. 16.14) n n
14
single failure redundant flow, redundant cut-off
n
single drive
simplex single drive n
both reliable (or not essential)
simplex control
“stuck-at” n
simplex multiple drive n
stuck open
n n
Spring 2005
CUGS: Distributed Systems
15
Input/Output: Actuators 2(2) n
fully redundant n n n n
Spring 2005
CUGS: Distributed Systems
multiple drives
16
Input/Output, cont. A reliable actuator: Fully redundant hardware voting (masks errors, but no error detection)
multiplex control
most expensive 2 replicas: fail-safe (comparison) 3+ replicas: fail-operational (vote) static replication, active replicas
CUGS: Distributed Systems
Spring 2005
computer unreliable sensor/actuator expensive requires fail-stop
17
Spring 2005
open
CUGS: Distributed Systems
18
Security (Coulouris et al., Ch. 1)
Input/Output, cont. A reliable sensor (c.f. Fig. 16.16) Fully redundant n e.g., “Byzantine agreement”
Environment
n
n n n
n
Consensus
Spring 2005
CUGS: Distributed Systems
19
Security – examples n
n
n
Authentication: how do we know for sure that the user is a teacher who should have access to the data?
Scenario 2: Sending a credit card number over the Internet n
n n n n n
Spring 2005
n
CUGS: Distributed Systems
CUGS: Distributed Systems
n
n
21
Disruption of a service by bombardment of messages
Security of mobile code n
Introduction Security threats Design of secure systems Cryptography (Access control) Digital signatures
Unpredictable effects Trojan horse behavior (need not be a virus)
Spring 2005
CUGS: Distributed Systems
CUGS: Distributed Systems
n
Requirements n
Security policies n n n
n
n
Spring 2005
Define security rules E.g., only university staff may enter the office building Independent of security mechanisms
Security mechanisms n
23
22
Introduction
n
Spring 2005
20
Denial of service attacks n
Confidentiality: no-one other than the recipient should be able to read the data
Security (Coulouris et al., Ch. 7) n
The challenge: sending sensitive information in a network message in a secure manner
Solution: cryptography
Spring 2005
Confidentiality Integrity Availability
Security – unsolved problems
Scenario 1: Accessing exam information via a network file system n
Three components:
Enforce the rules E.g., card and passcode required to enter the office building; only staff members have Needs an underlying security policy
CUGS: Distributed Systems
24
Security model
Methods of attack Access rights
n
Eavesdropping
n
Masquerading
Object
n
invocation Client result
Principal (user)
Network
Server
n
n
Principal (server)
n
•Verify identity of client, check access rights •Verify identity of server for response Spring 2005
CUGS: Distributed Systems
n
25
n
n
n
Storing and re-sending intercepted messages May be effective despite encryption/authentication
Spring 2005
n
n
27
Cryptography n n
n n n n n
CUGS: Distributed Systems
E.g., cryptography keys
Spring 2005
The hardware and software that must be secure and trusted CUGS: Distributed Systems
28
Cryptography, cont.
Cryptography: study of encryption/decryption Cryptanalysis: trying to break encrypted message Cryptographic strength: how hard to break Encryption function E(K,T) Decryption function D(K,T) K1 and K2 are cognate if D(K 2 , E(K1 , T)) = T K is symmetric if D(K, E(K, T)) = T
Spring 2005
26
Make encryption/authentication algorithms public! Minimize the trusted computing base n
Flooding a resource to deny access for authorized users CUGS: Distributed Systems
CUGS: Distributed Systems
Limit a secret’s scope and lifetime n
Denial of service n
Spring 2005
Interception of message containing encryption keys Reading and re-encrypting subsequent messages
Design guidelines
Replaying n
Intercepting and altering messages Man-in-the-middle attack n
Methods of attack, cont. n
Using a false identity when sending or receiving messages
Message tampering n
Figure 2.13
Obtaining message copies without authority
29
n
Minimum properties of a cryptosystem n
n
n
Spring 2005
Without K2 it should be very difficult to recover T from E(K1 ,T) Given T and E(K 1 ,T) it should be difficult to recover K1 In an asymmetric system, given K1 it should be difficult to recover K2
CUGS: Distributed Systems
30
Asymmetric cryptosystems n
Also known as public key cryptography n
n
A principal keeps one key secret (K1) and publishes the other (K2)
n
A signed message is not confidential by itself
n
CUGS: Distributed Systems
n
n
Attacks on Cryptosystems n
n
n
n
n
n
Can read and copy any message Inject any bit pattern into the network
n
Spring 2005
Use long-term keys to send short-term keys
33
Digital signatures
n
n
n n
Spring 2005
n
Used to ensure authenticity of a document
CUGS: Distributed Systems
Authentic n
n
n
Fixed-length value Produced by a secure digest function Similar to checksums
n n
n
CUGS: Distributed Systems
35
Spring 2005
Convinces recipient that the signature or document have not been altered Convinces recipient that signer deliberately signed the document
Unforgeable Convinces recipient of signer’s identity Convinces recipient that the signature was made on the document in question
Non-repudiable n
Spring 2005
34
Signatures (digital and physical) need to be n
Binding of document or digest to a private secret of the signer Digest: compressed form of the message n
Proof of identity Common technique: Kerberos
Digital signatures, cont.
Similar to real-world signatures n
32
Requires a trusted third-party 1. A→S A, B 2. S→A E(Kas,(Ts, Kab, B, E(K bs, (Ts, Kab, A))) 3. A→B E(Kbs, (Ts, Kab, A)), E(Kab, (A, Ta)) 4. B→A E(Kab, (Ta + 1))
Known-plaintext attacks Chosen-plaintext attacks
CUGS: Distributed Systems
CUGS: Distributed Systems
n
Defense: Short-term vs. long-term keys n
n
Spring 2005
Attacks on the algorithm n
Authentication Key distribution
Authentication
The enemy n
Use asymmetric encryption only for n
31
Depends on secrecy of the key
Symmetric encryption is much faster than asymmetric (100-1000 times)
Most confidential messages also signed ⇒ E(R2, E(S 1, M))
Spring 2005
Gives a signature and confidentiality n
Encrypt using recipient's public key n
Same key used to encrypt and decrypt n
The principal signs a message using K1 n
n
Symmetric cryptosystem
Signer cannot deny that the signature is his CUGS: Distributed Systems
36
Digital signatures, cont. n
Bind a secret known only to the signer to the document n n
n
Digital signing
n
n
n
Time-stamping Non-repudiation
n
How to prevent copying of signed data
n
CUGS: Distributed Systems
n n
37
Security: Summary n n
n
n
Secret-key Public-key Protection domains n n
n
Spring 2005
CUGS: Distributed Systems
Capabilities Access control lists
Digital signatures n
Spring 2005
Digest functions CUGS: Distributed Systems
39
Spring 2005
CUGS: Distributed Systems
Names (self-study)
Summary
Coulouris et al., Chapter 9
n
n n
n
Purpose of names Name services Case study: Global Name Service
n
CUGS: Distributed Systems
Issues, dependability concepts Real-time communication
Security Authentication, confidentiality, cryptography Naming n Motivation, requirements, implementation n
n
Spring 2005
40
Distributed real-time systems n
n
38
Coulouris et al., p. 274, 1st paragraph: n The XOR operation is symmetric – two applications of it produces the original value. n (c.f. idempotent – produces the same value each time it is applied)
Access control n
Sign with private key Anyone can verify signature More useful in practice
Correction
Security threats Cryptography n
Requires both parties to know secret Only trusted principals can verify the signature
Public key n
Deliberate revealing of secret
Spring 2005
Secret key n
Physical analogy: handwriting pattern Digital signature more complex
Problems n
n
41
Spring 2005
CUGS: Distributed Systems
42
