1. Security
• In most systems security is an important
concern
– Communications should be secure against
eavesdropping and tampering
– Servers/clients should be able to verify the
identity of their clients/servers
– The originator of a message should be
verifiable after the message has been delivered
04/29/12 ICSS420 - Security 1

2. Policy vs. Mechanism
• Security policies
– Who can access what resource
– Defines the appropriate levels of security
• Security Mechanisms
– Techniques used to implement the security
policies
04/29/12 ICSS420 - Security 2

3. Principal
• The agents accessing the information or resources
– Human beings
– Servers
– Applications
• Principals with the same access rights are often
collected together in groups
• Each principal has a unique user identifier
associated with it
04/29/12 ICSS420 - Security 3

4. Threats
• Security threats common to computer
systems fall into four broad classes
– Leakage
• Acquisition of information by unauthorized parties
– Tampering
• The unauthorized alteration of information
– Resource Stealing
– Vandalism
04/29/12 ICSS420 - Security 4

5. Methods of Attack
• Some common methods of attack include
– Eavesdropping
• Information in transit
• Information in storage
– Masquerading
• Sending/receiving messages using the identity of another user
– Message Tampering
– Replaying
• Storing messages and sending them at a later date
– Denial of Service
04/29/12 ICSS420 - Security 5

6. Infiltration
• Attacker must have access to the system in
order to attack
– Password cracking
– Virus
• Attaches itself to an existing program
– Worm
• Standalone program
• Not always nasty!!
– Trojan Horse
04/29/12 ICSS420 - Security 6

7. Morris Worm
rsh attack
finger attack
Grappling hook
sendmail attack
Request for worm
Worm sent
Worm Worm
Target System Target System
04/29/12 ICSS420 - Security 7

8. Security in a Network
• In a networked system
– The principal threats to security come from the
openness of communication channels
– Potential violators are not easily identifiable, so
we must not assume trust. Assume
untrustworthy until proven otherwise
– The mechanisms used to implement security
must be validated to a high standard
04/29/12 ICSS420 - Security 8

9. Techniques
• Security mechanisms are based on three
techniques
– Cryptography
• Used to conceal information
• Used in support of authentication
• Used to implement digital signatures
– Authentication
• Validate the identity of the sender
– Access Control
• Allow resources to access only by authorized individuals
04/29/12 ICSS420 - Security 9

10. Cryptography
• Information can be encoded using a key
when it is written (or transferred)
– encryption
• It is then decoded using a key when it is
read (or received)
– decryption
• Very widely used for secure network
transmission
04/29/12 ICSS420 - Security 10

11. More on Cryptography
encryption
plaintext ciphertext
decryption
04/29/12 ICSS420 - Security 11

12. More on Cryptography
Ke Kd
C = EKe(plaintext)
plaintext Encrypt Decrypt plaintext
04/29/12 ICSS420 - Security 12

13. More on Cryptography
Ke Kd
C = EKe(plaintext)
plaintext Encrypt Decrypt plaintext
Side information Invader plaintext
Cryptanalysis
04/29/12 ICSS420 - Security 13

14. Cryptographic Systems
Cryptographic Systems
Conventional Systems Modern Systems
•Ke and Kd are
essentially the Private Key Public Key
same
•Ke and Kd are •Ke is public
private •Kd is private
04/29/12 ICSS420 - Security 14

15. Private Key Systems
• In private key systems, such as the US Federal
Data Encryption Standard (DES), a single key is
used for both encryption and decryption
• This means that both parties must know the key(s)
before communication can take place
– write it down ahead of time
– have some sort of physical key
– exchange key(s) via secure channels
04/29/12 ICSS420 - Security 15

16. Block Ciphers
• Many commonly used ciphers are block
ciphers.
– This means that they take a fixed-size block of
data (usually 64 bits)
– Transform it to another 64 bit block using a
function selected by the key.
04/29/12 ICSS420 - Security 16

17. Block Cipher Modes
• If the same block is encrypted twice with the same
key, the resulting ciphertext blocks are the same
– It is desirable to make identical plaintext blocks encrypt
to different ciphertext blocks.
• Two methods are commonly used for this:
– CFB mode: a ciphertext block is obtained by
encrypting the previous ciphertext block, and xoring
the resulting value with the plaintext.
– CBC mode: a ciphertext block is obtained by first
xoring the plaintext block with the previous ciphertext
block, and encrypting the resulting value.
04/29/12 ICSS420 - Security 17

18. Secret Key Systems
• DES
– Developed in the 1970s adopted as a standard by the
US government
– DES is a block cipher with 64-bit block size. It uses 56-
bit keys.
– This makes it fairly easy to break with modern
computers or
– A variant of DES, Triple-DES or 3DES is based on
using DES three times (normally in an encrypt-decrypt-
encrypt sequence with three different, unrelated keys).
04/29/12 ICSS420 - Security 18

19. Secret Key Systems
• Blowfish
– An algorithm developed by Bruce Schneier.
– It is a block cipher with 64-bit block size and variable
length keys (up to 448 bits).
– No attacks are known against it.
• IDEA (International Data Encryption Algorithm)
– Developed at ETH Zurich in Switzerland.
– Uses a 128 bit key, and is considered to be very secure.
– No practical attacks on it have been published despite
numerous attempts to analyze it.
04/29/12 ICSS420 - Security 19

20. Secret Key Systems
• RC4
– The algorithm is very fast.
– Its security is unknown, but breaking it does not seem
trivial either.
• SAFER
– Developed by J. L. Massey (a developer of IDEA).
– It is claimed to provide secure/fast encryption
• Enigma
– The cipher used by the Germans in World War II.
– This cipher is used by the unix crypt(1) program
04/29/12 ICSS420 - Security 20

21. Public Key Systems
• In public key cryptosystems, everyone has two
related complementary keys, a publicly revealed
key and a secret key
• Each key unlocks the code that the other key
makes. Knowing the public key does not help you
deduce the corresponding secret key
• The public key can be published and widely
disseminated across a communications network
• This protocol provides security without the need
to reveal the private key
04/29/12 ICSS420 - Security 21

22. Public Key Systems
Public Key
Database
Kpublic Kprivate
C = EKpublic(plaintext)
plaintext Encrypt Decrypt plaintext
04/29/12 ICSS420 - Security 22

23. RSA
• Rivest, Shamir and Adelman (RSA)
– To find a key pair e and d:
• Chose two large prime numbers, P and Q (each
greater than 10100), and form
– N=PxQ
– Z = (P-1) x (Q-1)
• For d chose any number relatively prime to Z
• To find e solve the equation
– e x d = 1 mod Z
04/29/12 ICSS420 - Security 23

24. Comparison
• Secret and public key systems
– With suitable keys both are secure enough
– Public-key systems are more convenient to
implement because they do not require a secure
channel to exchange keys
– Secret-key systems are faster
04/29/12 ICSS420 - Security 24

25. Establishing a Shared Key
• In order for a symmetrical system to work,
both parties need to know a shared key
• Is it possible for two parties to safely use
the network to agree on a shared key?
– To put this another way, can two machines
agree on a common number such that anyone
who listens to that conversation can determine
the number?
04/29/12 ICSS420 - Security 25

26. Diffie-Hellman Key Exchange
n and g, both are prime, public and special. A picks x
in private, B picks y in private
n, g, gx mod n
A gy mod n B
Compute (gy mod n)x mod n = Compute (gx mod n)y mod n =
gxy mod n gxy mod n
04/29/12 ICSS420 - Security 26

27. It Works!!
• n=47, g=3
• I’ll pick a small x, you pick a small y
• I send to you
– (47, 3, 9)
• You send to me
– 3y mod 47 (call it z)
• I compute zx mod 47
• You compute 9y mod 47
04/29/12 ICSS420 - Security 27

28. To Break it
• You know
– n = 47, g = 3
• You also know
– gx mod n = 9
– gy mod n = z
• You need to solve the equation
– zx mod 47 = 9y mod 47
04/29/12 ICSS420 - Security 28

29. Bucket Brigade
Also known as the person in
the middle attack
n, g, gx mod n
gq mod n
A X B
n, g, gq mod n
gy mod n
Session key S Session key R
04/29/12 ICSS420 - Security 29

30. Key Distribution Center
• With the previous example, you would need n
different keys to talk to n different people
– Perhaps the same key could be used for an entire
session
• An alternative approach is to use a key distribution
center (KDC)
– The KDC stores a single key for each user
– Authentication and session key management goes
through the KDC
04/29/12 ICSS420 - Security 30

31. KDC
A, KA(B,KS) KB(A,KS)
KDC
A, KA(C,KS) KC(A,KS) B
A
KS(message1)
C
KS(message2)
04/29/12 ICSS420 - Security 31

32. Analysis
• Authentication comes for free
– The KDC knows the message came from A
– B knows the first message came from the KDC
– B knows the third message came from A
04/29/12 ICSS420 - Security 32

33. Replay Attack
A, KA(B,KS)
KDC
KB(A,KS)
A KS(message) B
KB(A,KS)
C
KS(message)
04/29/12 ICSS420 - Security 33

34. Solutions
• Timestamp messages
– Obsolete messages are discarded
– Clocks cannot be perfectly synchronized
– So timestamps are valid for an interval
• Unique message numbers (nonce)
– Each party remembers all previous nonces
– Messages with used nonces are rejected
– Nonces have to be remembered forever
04/29/12 ICSS420 - Security 34

35. Needham-Schroeder
RA, A, B
KDC
KA(RA, B, KS, KB(A,KS))
Not a replay Who the Ticket
ticket is for
A Challenge B KB(A,KS), KS(RA2) B
Must be B, Challenge A KS(RA2-1), RB
KS(RB-1) Must be A
KS(message)
04/29/12 ICSS420 - Security 35

36. Attack
Obtains an old
session key
Replays old message (RA2 could
be different)
X Challenge B KB(A,KS), KS(RA2) B
Must be B, Challenge A KS(RA2-1), RB
KS(RB-1) Must be A
KS(message)
04/29/12 ICSS420 - Security 36

37. Otway-Rees
A, B, R, KA(A,B,R,RA)
A, KA(A,B,R,RA),
B, KB(A,B,R,RB)
A B
KDC KB(RB,KS)
KA(RA,KS)
04/29/12 ICSS420 - Security 37

38. Kerberos
Authentication
Server
Client
Trusted server, repository of
keys, protected by a nasty three-
headed dog (Kerberos of Greek
mytholodgy) Server
04/29/12 ICSS420 - Security 38

39. Kerberos
Authentication Encrypted for client
Server Encrypted for server
Ticket
Client ID Client
Session Key
Session Key After message arrives,
user is prompted for
password which is used Server
to decrypt the message
04/29/12 ICSS420 - Security 39

40. Kerberos
Authentication Encrypted for client
Server Encrypted for server
Session Key Client
Ticket
Client ID
Session Key Server
04/29/12 ICSS420 - Security 40

41. Kerberos
Authentication Encrypted for client
Server Encrypted for server
Session Key
Client
Ticket
Client ID Server
Session Key
04/29/12 ICSS420 - Security 41

42. Kerberos
Authentication Encrypted for client
Server Encrypted for server
Session Key
Client
Server
Client ID
Session Key
04/29/12 ICSS420 - Security 42

43. Kerberos
Authentication Encrypted for client
Server Encrypted for server
Encrypted for session
Client
Message
Server
04/29/12 ICSS420 - Security 43

44. Authentication
• User/process authentication
– Is this user/process who it claims to be?
• Passwords
• More sophisticated mechanisms
• Authentication in networks
– Is this computer who it claims to be?
• File downloading
• Obtaining network services
04/29/12 ICSS420 - Security 44

45. Public-Key Authentication
PublicB(A,RA)
A Must be B PublicA(RA,RB, KS) B
KS(RB) Must be A
04/29/12 ICSS420 - Security 45

46. Challenge Response
A
RB
KAB(RB)
A B
RA
KAB(RA)
KAB(Message)
04/29/12 ICSS420 - Security 46

47. Challenge Response
A, RA
A RB, KAB(RA) B
KAB(RB)
04/29/12 ICSS420 - Security 47

48. Reflection Attack
A, RX
RB, KAB(RX)
Needs KAB(RB)
X A, RB B
RB2, KAB(RB)
KAB(RB)
04/29/12 ICSS420 - Security 48

49. The Lesson
• Designing a correct authentication protocol
is harder than it looks
• General rules
– Have the initiator prove who they are before the
responder has to
– Have the initiator and responder use different
keys for proof
– Have the initiator and challenger draw their
challenges from different sets
04/29/12 ICSS420 - Security 49

50. Digital Signatures
• Public key systems can also be used to provide
message authentication:
– The sender’s secret key can be used to encrypt a
message, thereby signing it
– This creates a digital signature of a message, which the
recipient (or anyone else) can check by using the
sender's public key to decrypt it.
– This proves that the sender was the true originator of
the message, and that the message has not been
subsequently altered by anyone else
04/29/12 ICSS420 - Security 50

51. Secure Shell
• Secure Shell (ssh/ssh2) is a tool for improving
Internet security by providing
– Strong authentication
– All communications are automatically and
transparently encrypted
– X11 connection forwarding provides secure X11
sessions
– Arbitrary TCP/IP ports can be redirected over the
encrypted channel in both directions.
– The client RSA-authenticates the server machine in the
beginning of every connection
04/29/12 ICSS420 - Security 51

52. How It Works
• SSH uses both authentication and
encryption
– Authentication is done using RSA
public/private keys
– Encryption can be done using a variety of
algorithms
• IDEA (default)
• DES
• 3DES
• Blowfish
04/29/12 ICSS420 - Security 52

53. SSH in Action
Random string encrypted with
public key for mordor Public/private keys
stored on mordor
Mordor returns unencrypted string
If the string matches what was sent,
mordor has been authenticated
Public key for
mordor available
on laptop
Both hosts authenticate themselves!!
04/29/12 ICSS420 - Security 53

54. User Authentication
• User name and password sent to remote
host encrypted with host’s public key
• Host sends random session key encrypted
with user’s public key
• Session key is decrypted
• User is authenticated
• Rest of conversation is encrypted using
IDEA
04/29/12 ICSS420 - Security 54