chapter 7 security
TRANSCRIPT
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.
Viewing: These slides must be viewed in slide show mode.
Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001.
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.
Viewing: These slides must be viewed in slide show mode.
Distributed Systems Course
Security
Chapter 2 Revision: Security model
Chapter 7: 7.2 Overview of security techniques7.3 Cryptographic algorithms7.4 Digital signatures7.5 Cryptography pragmatics7.6 Case studies
2
Learning objectives
Security model– Types of threat
Basic techniques– Cryptographic techniques
Secrecy Authentication Certificates and credentials Access control
– Audit trails
Symmetric and asymmetric encryption algorithms
Digital signatures
Approaches to secure system design
Pragmatics and case studies
*
3
Principal (user) Principal (server)
Chapter 2 Revision: Objects and principals
Access rights
Network
invocation
resultClient
Server
Object
Object (or resource)– Mailbox, system file, part of a commercial web site
Principal– User or process that has authority (rights) to perform actions
– Identity of principal is important
Figure 2.13
*
4
Chapter 2 Revision: The enemy
Communication channel
Process p Process q
The enemym’
Copy of m
m
Attacks– On applications that handle financial transactions or other information
whose secrecy or integrity is crucial
Enemy (or adversary)
Threats– To processes, to communication channels, denial of service
Figure 2.14
*
5
Chapter 2 Revision: Secure channels
Properties Each process is sure of the identity of the other Data is private and protected against tampering Protection against repetition and reordering of data
Employs cryptography Secrecy based on cryptographic concealment Authentication based on proof of ownership of secrets
Cryptographic concealment is based on:
Confusion and diffusion
Ownership of secrets:
Conventional shared crypto keys
Public/private key pair
Figure 2.15
*
Principal A
Secure channelProcess p Process q
Principal BThe enemyCryptography
6
Threats and forms of attack
Eavesdropping– obtaining private or secret information
Masquerading– assuming the identity of another user/principal
Message tampering– altering the content of messages in transit
man in the middle attack (tampers with the secure channel mechanism)
Replaying– storing secure messages and sending them at a later date
Denial of service– flooding a channel or other resource, denying access to others
*
7
Threats not defeated by secure channels or other cryptographic techniques
Denial of service attacks– Deliberately excessive use of resources to the extent that they are not
available to legitimate users E.g. the Internet 'IP spoofing' attack, February 2000
Trojan horses and other viruses– Viruses can only enter computers when program code is imported.– But users often require new programs, for example:
New software installation Mobile code downloaded dynamically by existing software (e.g. Java
applets) Accidental execution of programs transmitted surreptitiously
– Defences: code authentication (signed code), code validation (type checking, proof), sandboxing.
*
9
Alice and Bob share a secret key KAB.
1. Alice uses KAB and an agreed encryption function E(KAB, M) to encrypt and send any number of messages {Mi}KAB to Bob.
2. Bob reads the encrypted messages using the corresponding decryption function D(KAB, M).
Alice and Bob can go on using KAB as long as it is safe to assume that KAB has not been compromised.
Scenario 1: Secret communication with a shared secret key
Issues:
Key distribution: How can Alice send a shared key KAB to Bob securely?
Freshness of communication: How does Bob know that any {Mi} isn’t a copy of an earlier encrypted message from Alice that was captured by Mallory and replayed later?
*
10
Bob is a file server; Sara is an authentication service. Sara shares secret key KA with Alice and secret key KB with Bob.
1. Alice sends an (unencrypted) message to Sara stating her identity and requesting a ticket for access to Bob. �
2. Sara sends a response to Alice. {{Ticket}KB, KAB}KA. It is encrypted in KA and consists of a ticket (to be sent to Bob with each request for file access) encrypted in KB and a new secret key KAB.
3. Alice uses KA to decrypt the response.
4. Alice sends Bob a request R to access a file: {Ticket}KB, Alice, R.
5. The ticket is actually {KAB, Alice}KB. Bob uses KB to decrypt it, checks that Alice's name matches and then uses KAB to encrypt responses to Alice.
Scenario 2: Authenticated communication with a server
This is a simplified version of the Needham and Schroeder (and Kerberos) protocol.
Timing and replay issues – addressed in N-S and Kerberos.
Not suitable for e-commerce because authentication service doesn't scale…
A ticket is an encrypted item containing the identity of the principal to whom it is issued and a shared key for a communication session.
*
11
Bob has a public/private key pair <KBpub, KBpriv>
1. Alice obtains a certificate that was signed by a trusted authority stating Bob's public key KBpub
2. Alice creates a new shared key KAB , encrypts it using KBpub using a public-key algorithm and sends the result to Bob.
3. Bob uses the corresponding private key KBpriv to decrypt it.
(If they want to be sure that the message hasn't been tampered with, Alice can add an agreed value to it and Bob can check it.)
Scenario 3: Authenticated communication with public keys
Mallory might intercept Alice’s initial request to a key distribution service for Bob’s public-key certificate and send a response containing his own public key. He can then intercept all the subsequent messages.
*
12
Alice wants to publish a document M in such a way that anyone can verify that it is from her.
1. Alice computes a fixed-length digest of the document Digest(M).
2. Alice encrypts the digest in her private key, appends it to M and makes the resulting signed document (M, {Digest(M)}KApriv) available to the intended users.
3. Bob obtains the signed document, extracts M and computes Digest(M).
4. Bob uses Alice's public key to decrypt {Digest(M)}KApriv and compares it with his computed digest. If they match, Alice's signature is verified.
Scenario 4: Digital signatures with a secure digest function
The digest function must be secure against the birthday attack
*
13
1. Alice prepares two versions M and M' of a contract for Bob. M is favourable to Bob and M' is not.
2. Alice makes several subtly different versions of both M and M' that are visually indistinguishable from each other by methods such as adding spaces at the ends of lines. She compares the hashes of all the versions of M with all the versions of M'. (She is likely to find a match because of the Birthday Paradox).
3. When she has a pair of documents M and M' that hash to the same value, she gives the favourable document M to Bob for him to sign with a digital signature using his private key. When he returns it, she substitutes the matching unfavourable version M', retaining the signature from M.
Birthday attack
– If our hash values are 64 bits long, we require only 232 versions of M and M’ on average.
– This is too small for comfort. We need to make our hash values at least 128 bits long to guard against this attack.
Birthday paradoxStatistical result: if there are 23 people in a room, the chances are even that 2 of them will have the same birthday.
*
14
Certificates
1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv
Figure 7.4 Alice’s bank account certificate
Figure 7.5 Public-key certificate for Bob's Bank
1. Certificate type: Public key
2. Name: Bob’s Bank
3. Public key: KBpub
4. Certifying authority: Fred – The Bankers Federation
5. Signature: {Digest(field 2 + field 3)} KFpriv
Certificate: a statement signed by an appropriate authority.Certificates require:
• An agreed standard format• Agreement on the construction of chains of trust (see Section 7.4.4).• Expiry dates, so that certificates can be revoked.
*
15
X509 Certificate format
Subject Distinguished Name, Public Key
Issuer Distinguished Name, Signature
Period of validity Not Before Date, Not After Date
Administrative information Version, Serial Number
Extended Information
Figure 7.13
16
Certificates as credentials
Certificates can act as credentials– Evidence for a principal's right to access a resource
The two certificates shown in the last slide could act as credentials for Alice to operate on her bank account– She would need to add her public key certificate
*
Figure 7.5 Public-key certificate for Bob's Bank
1. Certificate type: Public key2. Name: Bob’s Bank3. Public key: KBpub
4. Certifying authority: Fred – The Bankers Federation5. Signature: {Digest(field 2 + field 3)} KFpriv
1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv
Figure 7.4 Alice’s bank account certificate
17
Access control
Protection domain– A set of <resource, rights> pairs
Two main approaches to implementation:– Access control list (ACL) associated with each object
E.g. Unix file access permissions � For more complex object types and user communities, ACLs can become
very complex
– Capabilities associated with principals Like a key Format: <resource id, permitted operations, authentication code> Must be unforgeable Problems: eavesdropping, difficulty of cancellation
drwxr-xr-x gfc22 staff 264 Oct 30 16:57 Acrobat User Data-rw-r--r-- gfc22 unknown 0 Nov 1 09:34 Eudora Folder-rw-r--r-- gfc22 staff 163945 Oct 24 00:16 Preview of xx.pdfdrwxr-xr-x gfc22 staff 264 Oct 31 13:09 iTunes-rw-r--r-- gfc22 staff 325 Oct 22 22:59 list of broken apps.rtf
*
18
Credentials
Requests to access resources must be accompanied by credentials:– Evidence for the requesting principal's right to access the resource– Simplest case: an identity certificate for the principal, signed by the
principal.– Credentials can be used in combination. E.g. to send an authenticated
email as a member of Cambridge University, I would need to present a certificate of membership of CU and a certificate of my email address.
The speaks for idea– We don't want users to have to give their password every time their
PC accesses a server holding protected resources.– Instead, the notion that a credential speaks for a principal is
introduced. E.g. a user's PK certificate speaks for that user.
*
19
Delegation
Consider a server that prints files:– wasteful to copy the files, should access users' files in situ– server must be given restricted and temporary rights to access
protected files
Can use a delegation certificate or a capability– a delegation certificate is a signed request authorizing another
principal to access a named resource in a restricted manner.– CORBA Security Service supports delegation certificates.– a capability is a key allowing the holder to access one or more of the
operations supported by a resource.– The temporal restriction can be achieved by adding expiry times.
*
20
Cryptographic Algorithms
Symmetric (secret key)E(K, M) = {M}K D(K, E(K, M)) = M
Same key for E and DM must be hard (infeasible) to compute if K is not known. Usual form of attack is brute-force: try all possible key values for a known pair
M, {M}K. Resisted by making K sufficiently large ~ 128 bits
Asymmetric (public key)Separate encryption and decryption keys: Ke, Kd
D(Kd. E(Ke, M)) = M
depends on the use of a trap-door function to make the keys. E has high computational cost. Very large keys > 512 bits
Hybrid protocols - used in SSL (now called TLS)Uses asymmetric crypto to transmit the symmetric key that is then used to
encrypt a session.
*
Message M, key K, published encryption functions E, D
21
Cipher blocks, chaining and stream ciphers
n
n+3 n+2 n+1 XOR
E(K, M)
n-1n-2n-3
plaintext blocks
ciphertext blocks
Figure 7.6 Cipher block chaining (CBC)
XOR
E(K, M)number generator n+3 n+2 n+1
plaintext stream
ciphertext stream
buffer
keystream
Figure 7.7 Stream cipher
Most algorithms work on 64-bit blocks.Weakness of simple block cipher:- repeated patterns can be detected.
*
22
Symmetric encryption algorithms
These are all programs that perform confusion and diffusion operations on blocks of binary data
TEA: a simple but effective algorithm developed at Cambridge U (1994) for teaching and explanation. 128-bit key, 700 kbytes/sec
DES: The US Data Encryption Standard (1977). No longer strong in its original form. 56-bit key, 350 kbytes/sec.
Triple-DES: applies DES three times with two different keys. 112-bit key, 120 Kbytes/sec
IDEA: International Data Encryption Algorithm (1990). Resembles TEA. 128-bit key, 700 kbytes/sec
AES: A proposed US Advanced Encryption Standard (1997). 128/256-bit key.
There are many other effective algorithms. See Schneier [1996].
The above speeds are for a Pentium II processor at 330 MHZ. Today's PC's (January 2002) should achieve a 5 x speedup.
*
23
TEA encryption function
void encrypt(unsigned long k[], unsigned long text[]) {unsigned long y = text[0], z = text[1];unsigned long delta = 0x9e3779b9, sum = 0; int n;for (n= 0; n < 32; n++) {
sum += delta;y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]); 5z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6
}text[0] = y; text[1] = z;
}
Lines 5 & 6 perform confusion (XOR of shifted text)and diffusion (shifting and swapping)
*
Figure 7.8 key 4 x 32 bitsplaintextand result 2 x 32
Exclusive OR
logical shift
24
TEA decryption function
void decrypt(unsigned long k[], unsigned long text[]) {unsigned long y = text[0], z = text[1];unsigned long delta = 0x9e3779b9, sum = delta << 5; int n;for (n= 0; n < 32; n++) {
z -= ((y << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]);y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]);sum -= delta;
}text[0] = y; text[1] = z;
}
Figure 7.9
*
25
TEA in use
void tea(char mode, FILE *infile, FILE *outfile, unsigned long k[]) {/* mode is ’e’ for encrypt, ’d’ for decrypt, k[] is the key.*/
char ch, Text[8]; int i;while(!feof(infile)) {
i = fread(Text, 1, 8, infile); /* read 8 bytes from infile into Text */if (i <= 0) break;while (i < 8) { Text[i++] = ' ';} /* pad last block with spaces */switch (mode) {case 'e':
encrypt(k, (unsigned long*) Text); break;case 'd':
decrypt(k, (unsigned long*) Text); break;}fwrite(Text, 1, 8, outfile); /* write 8 bytes from Text to outfile */
}}
Figure 7.10
*
26
Asymmetric encryption algorithms
RSA: The first practical algorithm (Rivest, Shamir and Adelman 1978) and still the most frequently used. Key length is variable, 512-2048 bits. Speed 1-7 kbytes/sec. (350 MHz PII processor)
Elliptic curve: A recently-developed method, shorter keys and faster.
Asymmetric algorithms are ~1000 x slower and are therefore not practical for bulk encryption, but their other properties make them ideal for key distribution and for authentication uses.
A trapdoor provides a secret way into a room. If you're inside, the way out is obvious, if you're outside, you need to know a secret to get in.
They all depend on the use of trap-door functionsA trap-door function is a one-way function with a secret exit - e.g. product of two large numbers; easy to multiply, very hard (infeasible) to factorize.
*
See Section 7.3.2 for a description and example of the RSA algorithm.
29
Digital signatures
Requirement:– To authenticate stored document files as well as messages
– To protect against forgery– To prevent the signer from repudiating a signed document (denying their
responsibility)
Encryption of a document in a secret key constitutes a signature- impossible for others to perform without knowledge of the key- strong authentication of document- strong protection against forgery- weak against repudiation (signer could claim key was compromised)
*
30
Secure digest functions
- Encrypted text of document makes an impractically long signature- so we encrypt a secure digest instead- A secure digest function computes a fixed-length hash H(M) that characterizes
the document M - H(M) should be:
- fast to compute- hard to invert - hard to compute M given H(M)- hard to defeat in any variant of the Birthday Attack
- MD5: Developed by Rivest (1992). Computes a 128-bit digest. Speed 1740 kbytes/sec.
SHA: (1995) based on Rivest's MD4 but made more secure by producing a 160-bit digest, speed 750 kbytes/second
Any symmetric encryption algorithm can be used in CBC (cipher block chaining) mode. The last block in the chain is H(M)
*
31
Digital signatures with public keys
Signing
hH(doc)
D(Kpub,{h}) h'
h = h'?authentic:forged
Figure 7.11
Verifying
M
H(M)
128 bits
h E(Kpri, h){h}Kpri
M
signed doc
M
{h}Kpri
*
32
MACs: Low-cost signatures with a shared secret key
Signing
Verifying
M
K
Figure 7.12M
K
h = h'?authentic:forged
h
M
signed doc
H(M+K) h
h'
H(M+K)
*
Signer and verifier share a secret key K
MAC: Message Authentication Code
33
Performance of encryption and secure digest algorithms
Key size/hash size(bits)
Extrapolatedspeed
(kbytes/sec.)
PRB optimized speed
(kbytes/s)
TEA 128 700 -
DES 56 350 7746
Triple-DES 112 120 2842
IDEA 128 700 4469
RSA 512 7 -
RSA 2048 1 -
MD5 128 1740 62425
SHA 160 750 25162
PRB = Preneel, Rijmen and Bosselaers [Preneel 1998]
Algorithm
Publickey
Secret key
Digest
speeds are for a Pentium II processor at 330 MHZFigure 7.14
*
34
Case study: Needham - Schroeder protocol
In early distributed systems (1974-84) it was difficult to protect the servers – E.g. against masquerading attacks on a file server
– because there was no mechanism for authenticating the origins of requests– public-key cryptography was not yet available or practical
computers too slow for trap-door calculations RSA algorithm not available until 1978
Needham and Schroeder therefore developed an authentication and key-distribution protocol for use in a local network– An early example of the care required to design a safe security protocol– Introduced several design ideas including the use of nonces.
*
35
Header Message Notes
1. A->S: A, B, NAA requests S to supply a key for communicationwith B.
2. S->A: {NA , B, KAB,
{KAB, A}KB}KA
S returns a message encrypted in A’s secret key,containing a newly generated key KAB and a‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in responseto the preceding one. A believes that S sent themessage because only S knows A’s secret key.
3. A->B: A sends the ‘ticket’ to B.
4. B->A: B decrypts the ticket and uses the new key KAB toencrypt another nonce NB.
5. A->B: A demonstrates to B that it was the sender of theprevious message by returning an agreedtransformation of NB.
{KAB, A}KB
{NB}KAB
{NB - 1}KAB
Ticket
The Needham–Schroeder secret-key authentication protocol
NA is a nonce. Nonces are integers that are added to messages to demonstrate the freshness of the transaction. They are generated by the sending process when required, for example by incrementing a counter or by reading the (microsecond resolution) system clock.
Figure 7.15
*
Weakness: Message 3 might not be fresh - and KAB could have been compromised in the store of A's computer. Kerberos (next case study) addresses this by adding a timestamp or a nonce to message 3.
36
Case study: Kerberos authentication and key distribution service
Secures communication with servers on a local network– Developed at MIT in the 1980s to provide security across a large
campus network > 5000 users– based on Needham - Schroeder protocol
Standardized and now included in many operating systems– Internet RFC 1510, OSF DCE– BSD UNIX, Linux, Windows 2000, NT, XP, etc.– Available from MIT
Kerberos server creates a shared secret key for any required server and sends it (encrypted) to the user's computer
User's password is the initial secret shared with Kerberos
*
37
ServerClient
DoOperation
Authenticationdatabase
Loginsession setup
Ticket-granting
service T
Kerberos Key Distribution Centre
Serversession setup
Authen-tication
service A
Servicefunction
System architecture of Kerberos
3. Request forserver ticket
4. Server ticket
Step B
5. Service request
Request encrypted with session key
Reply encrypted with session key
Step C
1. A->S: A, B, NA
2. S->A: {NA , B, KAB,
{KAB, A}KB}KA
3. A->B:
4. B->A:
{KAB, A}KB
{NB}KAB
Needham - Schroeder protocol
5. A->B: {NB - 1}KAB
Step B once per server session
Step C once per server transaction
*
Figure 7.16
Step A once per login session
1. Request forTGS ticket
2. TGSticket
Step A
TGS: Ticket-granting service
38
Kerberized NFS
Kerberos protocol is too costly to apply on each NFS operation
Kerberos is used in the mount service:– to authenticate the user's identity
– User's UserID and GroupID are stored at the server with the client's IP address
For each file request:– UserID and GroupID are sent encrypted in the shared session key– The UserID and GroupID must match those stored at the server – IP addresses must also match
This approach has some problems– can't accommodate multiple users sharing the same client computer– all remote filestores must be mounted each time a user logs in
*
39
Case study: The Secure Socket Layer (SSL)
Key distribution and secure channels for internet commerce– Hybrid protocol; depends on public-key cryptography– Originally developed by Netscape Corporation (1994)– Extended and adopted as an Internet standard with the name Transport
Level Security (TLS)– Provides the security in all web servers and browsers and in secure
versions of Telnet, FTP and other network applications
Design requirements– Secure communication without prior negotation or help from 3rd parties– Free choice of crypto algorithms by client and server– communication in each direction can be authenticated, encrypted or both
40
SSL protocol stack
SSLHandshake
protocol
SSL ChangeCipher Spec
SSL AlertProtocol
Transport layer (usually TCP)
Network layer (usually IP)
SSL Record Protocol
HTTP Telnet
SSL protocols: Other protocols:
Figure 7.17
*
negotiates cipher suite, exchanges certificates and key masters
changes thesecure channel to a new spec
implements the secure channel
41
ClientA
ServerB
ClientHello
ServerHello
SSL handshake protocol
Establish protocol version, session ID, cipher suite, compression method, exchange random start values
Certificate
Certificate Request
ServerHelloDone
Optionally send server certificate and request client certificate
Certificate
Certificate VerifySend client certificate response if requested
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Change cipher suite and finish handshake
*
Figure 7.18
Includes key master exchange.Key master is used by both A and Bto generate:2 session keys 2 MAC keys
KAB MAB
KBA MBA
Component Description Example
Key exchangemethod
the method to be used forexchange of a session key
RSA with public-keycertificates
Cipher for datatransfer
the block or stream cipher to beused for data
IDEA
Message digestfunction
for creating messageauthentication codes (MACs)
SHA
Cipher suite
42
SSL handshake configuration options
Component Description Example
Key exchangemethod
the method to be used forexchange of a session key
RSA with public-keycertificates
Cipher for datatransfer
the block or stream cipher to beused for data
IDEA
Message digestfunction
for creating messageauthentication codes (MACs)
SHA
Figure 7.19
*
43
SSL record protocol
Application data abcdefghi
abc def ghiRecord protocol units
Fragment/combine
Compressed units
Compress
MAC
Hash
Encrypted
Encrypt
Figure 7.20
TCP packet
Transmit
*
44
Summary
It is essential to protect the resources, communication channels and interfaces of distributed systems and applications against attacks.
This is achieved by the use of access control mechanisms and secure channels.
Public-key and secret-key cryptography provide the basis for authentication and for secure communication.
Kerberos and SSL are widely-used system components that support secure and authenticated communication.
*
45
[p. 260]
Worst case assumptions and design guidelines
Interfaces are exposed
Networks are insecure
Limit the lifetime and scope of each secret
Algorithms and program code are available to attackers
Attackers may have access to large resources
Minimize the trusted base