Lecture 8: Internet Control Protocols Reading: Section 4.1 ? CMSC 23300/33300 Computer Networks .
Lecture 18: Security Reading: Chapter 8 (Some material thanks to William Perrizo) ? CMSC 23300/33300...
-
Upload
jemimah-bertha-alexander -
Category
Documents
-
view
215 -
download
0
Transcript of Lecture 18: Security Reading: Chapter 8 (Some material thanks to William Perrizo) ? CMSC 23300/33300...
Lecture 18: Security
Reading: Chapter 8
(Some material thanks toWilliam Perrizo)
?
CMSC 23300/33300
Computer Networks
http://dsl.cs.uchicago.edu/Courses/CMSC33300
2
Taxonomy of Network Security
Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant Integrity: assure message is unaltered
All based on encryption Key distribution is a cross-cutting problem
Security
Cryptography
algorithms
Public
key
(e.g., RSA)
Secret
key
(e.g., DES,AES, IDEA)
Message
digest
(e.g., MD5)
Security
services
AuthenticationPrivacy Message
integrity
3
Need for Security
Some people who cause security problems and why
4
The Encryption Model (for a Symmetric-key Cipher)
5
Cryptographic Algorithms
Secret key DES: Data Encryption Standard Other more recent variations: AES-Advanced
Encryption Standard; IDEA-Int’l Data Encryption Alg) Public key
RSA method (Rivest, Shamir, Adleman) Message Digest (keyless)
MMD5: based on cryptographic checksum
6
Cryptographic Functions
Cryptography algorithms can be used to implement a number of functions, including Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant
(including service to which a request is to be sent) Integrity: assure message is unaltered
Other functions are also of interest, e.g. Nonrepudiation Authorization …
7
DES (Data Encryption Standard)
Key needs to be secret but not the algorithm itself DES makes the algorithm so complex that none of the
structure of the plaintext remains in the ciphertext (attacker must get key)
Derives its security from complexity (not completely secure these days)
Can be broken if the attacker finds the factors of a number which is the product of two large primes
Computationally costly – at least it was! With a Beowulf cluster of 3000 high end PCs, could be
cracked in ~ 6 months
8Plaintext
Encrypt withsecret key
Ciphertext
Plaintext
Decrypt withsecret key
Initial bitpermutation
Rnd 1
Rnd 2
Rnd 16
56-bitkey
Final Permutation(inverse of original)
… 64-bit key(56 + 8-bit parity)
64-bit block of plaintext
Block1
IV
DES
Cipher1
Block2
DES
Block3
DES
Block4
DES
+
Cipher2
Cipher3
Cipher4
+++
CBC: cipher block chainingRepeat for large messages
Initialization Vector
+
F
L
i – 1
R
i – 1
R
i
K
i
L
i
Differentsubkey each round = XOR
Li = Ri-1
Ri = Li-1 F(Ri-1 , Ki)
CombinerFunction (a mess)
DES
9
Encrypt using public key and Decrypt using private key, both 512-bit keys.
Encryption: c = memod n Decryption: m = cdmod n
n = p*q, (p and q large prime numbers - each roughly 256 bits).
e is relatively prime to (p - 1) x (q - 1) (encryption key)
d = e-1mod ((p - 1) x (q - 1)) (decryption key)
public key = (e, n)
private key = (d, n)
Ignoring the mod functions, subsituting c=me into cd gives med = mee-1 =m
So it remains to show that the same arithmetic holds under the mod functions. Why?
Plaintext
Encrypt with
Ciphertext
Plaintext
Decrypt with
Public keyc = memod n
Private keym = cdmod n
RSA is too slow to be very useful in encrypting data messages (n ~ 2512 ~ 1051)It’s used to encrypt small things, e.g., secret keys, hash values.
RSA
10
Hash Functions Hash functions always map a data
space, S, into a fixed-size hash space, H E.g., size M at right
In DBMSs the goal is to reduce size and to provide a fast look up function E.g., mod functions
In Security the goal is to produce a functional value that does not reveal the domain data value from which it was computed I.e., inverse function is uncomputable
data-value(from S)
hashfctn
hash-value space, H
2
0
M-1
11
Cryptographic Checksums or Message Digests
Complex hash functions that compute a fixed length checksum from arbitrarily long messages Regular checksums protect the receiver from accidental changes to the
message. Cryptographic checksums protect the receiver from malicious changes to
the message One-way function
Given a cryptographic checksum for a message, it is virtually impossible to figure out what message produced that checksum; it is not computationally feasible to find two messages that hash to the same cryptographic checksum
If you have checksum of a message and you can compute same checksum from that message, then it is highly likely this message produced the checksum you were given
12
MD5
Roughly MD5 goes like this: Pad message to multiple of 512B 1st pass: 512B segments digested 2nd pass: similar but uses different fctn 3rd pass: yet another fctn (XOR based) 4th pass: another fctn (XOR,OR,NOT based) Resulting in a mangled digest which is: added to digest from previous stage! …
Transform
Initial“digest“(constant)
Message (padded)
Transform
Transform
Message digest
512 bits512 bits 512 bits■ ■ ■
13
3-way handshake (DES based)
Assume secret key, sk, has been exchanged
Client: select a random number x, encrypts (using sk) it and sends it
Client Server
C-id, DES(x,sk)
DES(x+1,sk) DES(y,sk)
DES(y+1,sk)
DES(sk,SessKey)
Server: decrypt (with sk); add 1; encrypt (with sk).
Gen random number y, encrypt; send bothClient: decrypt 1st part to verify x+1
(client now has authenticated server).
Decrypt 2nd part; add 1; encrypt; send.
Server: Send client a Session Key (sk encrypted)
to be used for all data messages
(so sk will be less vulnerable)
Server: Decrypt to verify y+1
(server now has authenticated client).
Authentication: Method 1
14
Assume A shares secret key, ska, with AS;
B shares secret key, skb, with AS
A (unencrypted) identifies itself and B to ASAS B
DES((T,L,SK,A),skb)DES((A,T),SK)
A,B
DES((T,L,SK,B),ska)DES((T,L,SK,A),skb
DES(T+1,SK)
A
AS sends a 2-part message to A:
DES((TimeStamp, LifeTime, SessKey, B), ska)
DES((TimeStamp, LifeTime, SessKey, A), skb)
B, upon seeing that A and T are the same in both (decrypts passed-along message 1st to get SessionKey, SK, to decrypt other part), replies with DES(T+1, SessKey)
A decrypts 1st part with its secret key, ska;
passes 2nd part, with DES((A, T), SessKey) to B
When is B authenticated to A? Vice versa?
A variation of T3P is used in Kerberos
(MIT developed TCP/IP-based security system)
Authentication: Method 2Trusted 3rd Party (Auth. Server, AS)
15
Authentication: Method 3Public Key Authentication (uses RSA)
A B
RSA(x, BPubKey)
x
A generates random number, x Sends RSA((x, BPublicKey) to B
B decrypts with BPrivateKey. Sends x back to A.
A can authenticate itself to B in the same way.
16
Message Integrity Protocols
Sometimes two participants do not care whether an eavesdropper is able to read the message,
but they are worried about an imposter claiming to be one of them (i.e., they want to ensure the integrity of their messages)
One way: encrypt using DES and cipher block chaining, then use CBC residue (last CBC block) as a hash or
checksum or message integrity code (MIC) If the receiver cannot reproduce the attached MIC using
the secret key then either the message was not sent by sender or it was modified since it was transmitted
17
Message Integrity Protocols#1 of 3: Digital Signature using RSA
Participant is the only one with the private key so he uses this key to produce the signature Any other participant can verify this signature using the public key
Thus, to send a message, encrypt with private key To verify a signature, you decrypt using public key of purported
sender RSA is ~3 orders of magnitude slower than DES Observe that this use of RSA keys is just the opposite of its use
in privacy For integrity, sender encrypts with its private key (rather than with
receiver’s public key) Receiver decrypts with sender’s public key (rather than with
receiver private key)
18
Message Integrity Protocols using MD5
Keyed MD5 Assumes sender and receiver already share a secret key, k
Sender runs MD5 over the concatenation of the message, m, and
key, k transmits m + MD5(m+k) (+ means concatenation)
Receiver runs MD5 on m (all but final 64 bits of what was received)
concatenated with k – i.e., MD5(m+k). If result matches (the last 64-bits of what was received)
then m was sent by key holder There are many variations of this protocol!
19
2nd MD5 Message Integrity Protocol: MD5 with RSA Signature
m + RSA[MD5(m), PrivateKey] is sent (where m is message it wants to protect integrity of) I.e., sender doesn’t sign entire message, just checksum
The receiver verifies the message by Running MD5 algorithm on the received message Decrypting the signed checksum with the sender’s
public key Comparing the two checksums
If they match, the message was not modified since the time the sender computed the MD5 checksum and signed it
20
Public Key Distribution (X.509)
Key Distribution: get keys to people so they can be sure the key is legitimate I.e., it belongs to the entity it’s purported to belong to
Can’t just use email or use a bulletin board Without A’s public key B has no way to authenticate the key
as having come from A Can exchange public keys in person
Has limitations too – have to be together in person Basic solution is to use Digital Certificates (DC)
A document, digitally signed by X, that says “I certify that public key in this document belongs to entity Y”
X = anyone with the public key of the entity named
21
Public Key Distribution, contd.
Usually X=Certification Authority Administrative entity in business of issuing certificates
DCs are only useful to participant already holding X’s public key (to decrypt the signature)
Thus, DCs do not solve the key distribution problem entirely
Once you have a public key for one entity, you can start to accumulate more public keys from participants who have DCs from X
22
Digital Certificate Chain of Trust
If X certifies that a public key belongs to Y, and then Y goes on to certify that another public key belongs to Z, then a chain of certificates from X to Z exists even though X and Z may never have met
Z can provide his public key to A, and the complete chain of certificates (the certificate for Ys PK issued by X and the certificate for Zs PK issued by Y)
If A has PK for X he can use the chain to verify that they are legitimate
A popular way to build chains of trust is to arrange them in a tree structure
23
Digital Certificate Chain of Trust
IPRA (Internet Policy Registration Authority)
PCA-1
CA/ \
user user
CA |
user
CA |
user
PCA-n
CA CA
CA
user
user
What is being certified? Binding between identity and public key (Is Jon Smith a well-defined identity?)
Certificates must be used in a well-defined name space (e.g., email names) E.g., the Domain Name Space (DNS)
24
Certificate Standards
E.g., X.509, which specifies components such as The name of the entity The public key of the entity The name of the certificate authority A digital signature (many different digital signature algs) Expiration time
Possession of a certificate says nothing about your identity: certificates can and must be freely copied and distributed to be useful
To prove that you are the entity named in the certificate you need to show you have the private key corresponding to the public key contained in that certificate: the authentication problem
25
Certificate Revocation
If your Private Key is stolen you need to revoke your certificate There may be many certificates asserting that you are
the owner of the public key corresponding to that private key
Person who has your private key has everything he needs to impersonate you
CAs issue certificate revocation lists (CRL), a digitally signed list of revoked certificates Periodically updated and made public
26
Example Systems
Components required to build a secure system include cryptographic algorithms, authentication protocols, and key distribution mechanisms.
Some systems that use these components are: IP Security (IPSEC) operates at the network layer (IP
layer) Transport Layer Security (TLS) (built from the older -
Secure Socket Layer or SSL) Secure Shell (SSH) application-level secure remote login
facility
27
Secure Shell (SSH)
Secure remote login and file transfer Provides strong client/server authentication Also supports message integrity and confidentiality
SSH version 2 has 3 protocols E.g., SSH-TRANS provides encrypted channel on top of TCP as
follows: Upon remote login, Client authenticates server using RSA Client and Server establish session key to encrypt data Client authenticates itself to Server
Supports other TCP applications (e.g., Xwindows, IMAP mail reader...) through SSH tunnels
Applicationclient
Applicationserver
SSH SSHForwarded connection
Direct connection
Host A Host B
28
IETF Transport Layer Security (TLS)
Looks to the user just like TCP, except that it provides privacy, integrity and authentication.
When HTTP is used over TLS, it is known as HTTPS (secure HTTP) In fact, HTTPS is just exactly HTTP over TLS
instead of TCP (port=443 instead of 80) TLS is broken down into two parts
(handshake & record protocols) Handshake protocol to negotiate parameters
Crypto algorithms, certificate, session keys, init vectors…)
Two RTTs
Application (e.g., HTTP)
Secure transport layer
TCP
IP
Subnet
Client Server
Hello
Hello[Certificate,Keys,CertificateRequest]HelloDone
Finish
Data
29
TLS, contd.
Record protocol defines set of formats/procs by which app messages are fragmented or coalesced into the right sized blocks for: optimal compression integrity protection using a hash such as MD5 encryption passing to lower layer (TCP) for transmission
TLS offers “resume session” feature - very useful for HTTP. TLS does not specify key infrastructure. TLS uses a single CA, whose public key is included in web
browsers Therefore it is popular for credit card applications.
30
Taxonomy of Network Security
Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant Integrity: assure message is unaltered
All based on encryption Key distribution is a cross-cutting problem
Security
Cryptography
algorithms
Public
key
(e.g., RSA)
Secret
key
(e.g., DES,AES, IDEA)
Message
digest
(e.g., MD5)
Security
services
AuthenticationPrivacy Message
integrity
31
Caveat
“If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology."
— Bruce Schneier
32
Further Reading
Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson
Security: Secret & Lies, Digital Security in a Networked World, by Bruce Schneier