Authentication protocols
This presentation is the property of its rightful owner.
Sponsored Links
1 / 62

Authentication Protocols PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on
  • Presentation posted in: General

When this message is received by the server, the identity of the client is not known. Client. Server. At this point the client knows the identity of the server since it decrypted x. ClientID, E(x, CHK). E(x+1, SHK), E(y, SHK). E(y+1, CHK).

Download Presentation

Authentication Protocols

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Authentication protocols

When this message is received by the server, the identity of the client is not known

Client

Server

At this point the client knows the identity of the server since it decrypted x

ClientID, E(x, CHK)

E(x+1, SHK), E(y, SHK)

E(y+1, CHK)

At this point the server knows the client because it was able to decrypt y

E(SK, SHK)

A new session key is exchanged so CHK and SHK aren’t as vulnerable to attacks

Authentication Protocols

CHK, SHK are keys known by both sides

  • Three-way handshake


Three way handshake

Three Way Handshake

  • Assumes both sides know CHK and SHK

  • This could correspond to a password

  • We still need a way to distribute keys assuming the client and server share no keys


Kerberos

A Asks S for a key to communicate with B

A proves it knows the encryption key K

Forwarded from S

S responds encoding the session key K and timestamp T and length of time to expire L

A can’t decrypt the second message

B Proves it was able to decrypt message from S

Kerberos

B

S shares KA with A, but B does not know KA, A does not know KB

S

A

  • Trusted third party (Kerberos)

A, B

E((T,L,K,B),KA),

E((T,L,K,A),KB)

E((A,T),K), E((T,L,K,A),KB)

E(T+1,K)


Kerberos1

Kerberos

  • K is used like a DES session Key

  • Key exchange depends on a trusted 3rd party


Public key authentication

Public key authentication

A

B

E(x, Public )

B

x


Message integrity protocols

Message Integrity Protocols

  • Digital signature using RSA

    • special case of a message integrity where the code can only have been generated by one participant

    • compute signature with private key and verify with public key


Don t send same text to several destinations

Don’t send same text to several destinations

Suppose that RSA is used to send a message m to three recipients, who have relatively prime encryption moduli n1, n2, n3. All three recipients use the same encryption exponent e=3, a once-popular choice as it makes encryption very fast. Show that someone who intercepts all three messages c1=m3mod n1, c2=m3mod n2, c3=m3mod n3 can efficiently decipher m.

The Chinese remainder theorem implies that you can efficiently find a c such that c= c1mod n1,c= c2mod n2, c= c3mod n3. Assume this and show that it implies c= m3mod n1 n2 n3.


Keyed md5

Keyed MD5

  • Sender and receiver share key k

  • sender

    m + MD5(m + k)

  • receiver

    • applies MD5 to the concatenation of random key message

    • compares result with checksum sent with message

  • Man-in-the middle can not recompute MD5 because he doesn’t have secret key k


Keyed md51

Keyed MD5

  • sender

    m + MD5(m + k) + E(k, private)

  • receiver

    • recovers random key using the sender's public key

    • applies MD5 to the concatenation of this random key message

    • compares result with checksum sent with message

  • Man-in-the middle can intercept k, change message, change checksum, and the receiver wont know


Authentication protocols

Fixed Keyed MD5

  • Sender

  • m + MD5(m + k) + E(E(k, r-public), s-private)

  • receiver

    • recovers random key using the sender's public key and receivers private key

    • applies MD5 to the concatenation of this random key message

    • compares result with checksum sent with message

    • Authenticates sender

  • Man-in-the middle can not intercept k because it is encrypted with the public key of the receiver

  • Only works for one receiver


Authentication protocols

What about this?

  • Sender

  • m + MD5(m + k) + E(k, r-public)

  • receiver

    • recovers random key using the receivers private key

    • applies MD5 to the concatenation of this random key message

    • compares result with checksum sent with message

  • Man-in-the middle can make up a new key and send it using the receivers public key


Authentication protocols

Another Keyed MD5

  • Sender m + E(MD5(m + k) +k, s-private)

  • receiver

    • recovers random key using the sender's public key

    • applies MD5 to the concatenation of this random key message

    • compares result with checksum sent with message

  • Man-in-the middle can not change message because checksum is encrypted with the private key of the sender


Md5 with rsa signature

MD5 with RSA signature

  • sender

    • m + E(MD5(m), s-private)

  • receiver

    • decrypts signature with sender's public key

    • compares result with MD5 checksum sent with message


Certificates

Certificates

CA

Certified Entity

Register with CA, send client Public Key

Albert Levi

Albert

Levi

CA-Publickey and

Certificate with

RSA(client Public Key,CA-privatekey)

Certificate

Verifier

Decrypt senders public key using CA-publickey

Albert Levi


Hierarchical pki example

Hierarchical PKI Example

RSA(UserPubK,CAPriK)

RSA(CAPubK.UCAPriK)

RSA(UCAPubK,RootCAPriK)


Pem encryption illustrated

Create a random secret key

k

Original message

Encrypt message using

Decrypt message using

DES with secret key

k

DES with secret key

k

Encrypt

k

using RSA with

Decrypt

E

(

k

) using RSA with

recipient

s public key

my private key ->

k

Encode message +

E

(

k

)

Convert ASCII message

in ASCII for transmission

T

ransmitted message

PEM Encryption Illustrated


Pem message integrity and authentication

Sender identity and message

integrity confirmed

if checksums match

Calculate MD5 checksum on

received message and compare

Calculate MD5 checksum

over message contents

against received value

Sign checksum using RSA

Decrypt signed checksum

with sender

s private key

with sender

s public key

T

ransmitted message

PEM message integrity and authentication

m+E(MD5(m),privatesender)


Pem certificates

IPRA

=

Internet Policy

IPRA

Registration Authority (root)

PCA

n

=

policy certification authority

CA

=

certification authority

PCA1

PCA2

PCA3

CA

CA

CA

CA

CA

CA

User

User

CA

User

User

User

CA

User

User

User

PEM Certificates


Tls ssl https

TLS,SSL,HTTPS

Transport Layer Security, Secure Socket Layer


Authentication protocols

SSL

  • Each browser is configured with a root CA

  • When a session is initiated, server and client agree on security capabilities. (most clients are 40 bit encryption, but 128 bit encryption is available on many strong servers

  • The server is authenticated by the certificate authority

  • Using the server public key from the CA, the client sends a DES key to the server

  • The DES key is used to encrypt the session


Ipsec

IPSEC

  • Optional in IPv4, mandatory in IPv6

  • Data Confidentiality---The IPSec sender can encrypt packets before transmitting them across a network.

  • Data Integrity---The IPSec receiver can authenticate packets sent by the IPSec sender to ensure that the data has not been altered during transmission.

  • Data Origin Authentication---The IPSec receiver can authenticate the source of the IPSec packets sent. This service is dependent upon the data integrity service.

  • Anti-Replay---The IPSec receiver can detect and reject replayed packets.


Firewall

Rest of the Internet

Firewall

Local site

Firewall


Firewall1

Remote

company

user

W

eb

Internet

Firewall

Company net

server

Random

external

user

Firewall


Proxy firewall

Firewall

External

Local

client

server

Proxy

External HTTP/TCP connection

Internal HTTP/TCP connection

Proxy Firewall


System vulnerabilities

system vulnerabilities

  • Almost all vulnerabilities come from bugs in the implementation of, or misconfigurations of, the OS and/or apps

  • Rarely, a problem with a protocol itself

  • Vulnerabilities can lead to:

    • Unauthorized access: attacker gains control of the victim’s machine (attacker can log in, read files, and/or make changes to the system)

    • Denial of Service against host (attacker can crash the computer, disable services, etc.)

    • Denial of Service against network (attack can disrupt routing, flood the network, etc.)


Statistics

Statistics

  • 2000 CSI/FBI Computer Crime and Security Survey

  • 90% of respondents (primarily large corporations and government agencies) detected computer security breaches within the last twelve months.

  • 70% reported a variety of serious computer security breaches other than the most common ones of computer viruses, laptop theft or employee "net abuse"--for example, theft of proprietary information, financial fraud, system penetration from outsiders, denial of service attacks and sabotage of data or networks.

  • 74% acknowledged financial losses due to computer breaches.

  • 42% were willing and/or able to quantify their financial losses. The losses from these 273 respondents totaled $265,589,940 (the average annual total over the last three years was $120,240,180).


Federal computer incident response center 2002

Federal Computer Incident Response Center (2002)


Who is the enemy

Mitnick

Simpson

who is the enemy?

  • The Troubled Genius

    • Has a deep understanding of systems

    • Capable of finding obscure vulnerabilities in OS’s, apps, and protocols, and exploiting them

    • Extremely skilled at evading countermeasures

    • Can dynamically adapt to new environments

  • The Idiot

    • Little or no true understanding of systems

    • Blindly downloads & runs code written by T.G.

    • Can usually be stopped by calling his mother

Who do you think causes more damage?


Authentication protocols

d’oh!

  • The idiots collectively cause more damage because there are a vast number of them

  • Every security incident analyzed at NIH was the work of an idiot

  • Every time smart hackers find a new security hole, they make it public -- they have a publish or perish “ethic”

  • Each time, hordes of idiots pounce on it and break into every system they can find


Publish or perish or good help is not hard to find

publish or perishor, good help is not hard to find


The never ending game

the never-ending game

1.New bugs are found; exploits are published

2.Hordes of idiots cause damage using those exploits

3.Vendors are pressured to come out with fixes

4.Users install the fixes (sometimes? rarely?)

5.Go to step 1.

The big questions are:

1.How can we protect a large site? (The site is only as strong as its most poorly administered machine.)

2.How can we pro-actively protect against attacks that we have never seen before, to avoid Step 2 damage?


Buffer overflows on the stack

func 2’s address

func 1’s address

buf

c, d

a, b

func_3()

{

char buf[100];

read_user_input(buf);

}

func_2()

{

int c, d;

func_3();

}

func_1()

{

int a, b;

func_2();

}

buffer overflowson the stack


Buffer overflows on the stack1

func 2’s address

buf’s address

func 1’s address

buf

c, d

a, b

evil_assembly_code()

func_3()

{

char buf[100];

read_user_input(buf);

}

func_2()

{

int c, d;

func_3();

}

func_1()

{

int a, b;

func_2();

}

buffer overflowson the stack

Attacker is supplying input to buf… so buf gets a very carefully constructed string containing assembly code,

and overwriting func 2’s address with buf’s address.

When func3 returns, it will branch to buf instead of func2.


Securing your system the quick easy way

securing your systemthe quick & easy way

It’s easy to run a secure computer system. You just have to disconnect all dial-up connections and permit only direct-wired terminals, put the machine and its terminals in a shielded room, and post a guard at the door.

F.T. Grampp and R.H. Morris

(Great! Let’s go to the router room with some bolt cutters.)


Firewalls not as good as bolt cutters but

firewalls(not as good as bolt cutters, but…)

  • Routers: easy to say “allow everything but…”

  • Firewalls: easy to say “allow nothing but…”

  • This helps because we turn off access to everything, then evaluate which services are mission-critical and have well-understood risks

  • Note: the only difference between a router and a firewall is the design philosophy; do we prioritize security, or connectivity/performance? (configurability, logging)


Typical firewall setup

typical firewall setup

evil Internet

DMZ

internal network

Diagram courtesy of CheckPoint Software Tech, www.checkpoint.com


The firewall setup

the firewall setup

  • Firewall ensures that the internal network and the Internet can both talk to the DMZ, but usually not to each other

  • The DMZ relays services at the application level, e.g. mail forwarding, web proxying

  • The DMZ machines and firewall are centrally administered by people focused on security full-time (installing patches, etc.); it’s easier to secure 20 machines than 20,000

  • Now the internal network is “safe” (but not from internal attacks, modems, etc.)


Firewall politics

Dear Professor _____________ ,

Our firewall has detected your attempt to use the network

protocol ________. This protocol is not supported under

the USC Security Policy. Please cease these activities at

once. Any further infractions will result in your

disconnection from our network.

Cordially,

UCS

Clement

PIM

firewall politics

  • In a corporate environment, firewalls are great. The network user is an employee of the network service provider; it’s in the provider’s power to say “Thou Shalt Not Use Any Internet Services Except For These...”

  • How well do you think that would work here?


Firewall details

Firewall Details

  • Rules based on

    • IP Source Address

    • IP Destination Address

    • Encapsulated Protocol

    • TCP/UDP destination port

    • TCP/UDP source port

TCP DPort

TCP SPort

TCP Hdr

Eth Dest

Eth Src

Eth Hdr

IP Dest

IP Src

IP Hdr

Data


Compared to proxy

Pros

Good Performance

Easy to support new protocols

Cons

IP TCP/UDP headers cant be trusted

Most attacks spoof IP TCP/UCP ports

Must look at other application signatures

Compared to Proxy


Application proxy

Application Proxy

  • Changes source address so that responses come to proxy from web server

  • Proxy is more secure than internal nodes

  • Performance degradation


Big brother is watching

big brother is watching

  • “Bro” passively monitors the network at some key location (say, the border router)

  • Reconstructs flows and searches for known “attack signatures” -- a manually created database, based on known network attacks

  • Provides real-time notification of security personnel when it sees something suspicious

  • Future versions may actively terminate connections by sending forged TCP RST

ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z


Thoughts on bro

thoughts on bro

  • It provides a nice site-wide view of security

  • It’s not disruptive to users

  • It’s centrally administered

  • Unlike a firewall, which stops badness before it starts, bro’s alarm may come too late

  • It can’t flag attacks that are not in its database of known attack signatures

  • It can not reliably determine what an end-station is seeing, for a variety of reasons


Subverting bro we ll start with the easy ones

subverting bro(we’ll start with the easy ones)

  • Let’s say we’re trying to scan for the string “su root”.

    • What if I type “su me^H^Hroot”?

    • What if I type “su<telnet option> root”?

    • What if I type “alias blammo su”, then type “blammo root”?


Reconstructing flows

TCP:

HDR

USER

HDR

root

HDR

HDR

US

HDR

ER

HDR

HDR

ro

IP:

HDR

ot

reconstructing flows

  • Let’s say you want to search for the text “USER root”. Is it enough to just search the data portion of TCP segments you see?

USER root

(Uh oh… we have to reassemble frags and resequence segs)


Fun with fragments

HDR

HDR

US

HDR

ER

HDR

HDR

ro

HDR

ot

fun with fragments

Imagine an attacker sends:

1.

2.

3. 1,000,000 unrelated fragments

4.

5.

Think of the entire campus as being a massively parallel computer.

That supercomputer is solving the flow-reconstruction problem.

Now we’re asking a single host to try to solve that same problem.


More fragment fun

HDR

HDR

US

HDR

ER

HDR

HDR

HDR

HDR

ro

fo

HDR

ot

more fragment fun

Imagine an attacker sends:

Seq. #

1.

Time

2.

3a.

3b.

4.

Should we consider 3a part of the data stream “USER root”?

Or is 3b part of the data stream? “USER foot”!

-- If the OS makes a different decision than the monitor: Bad.

-- Even worse: Different OS’s have different protocol interpretations,

so it’s impossible for Bro to agree with all of them


Trickery

trickery

  • Non-standard parts of standards

    • IP fragment overlap behavior

    • TCP sequence number overlap behavior

    • Invalid combinations of TCP options

  • Other ways to force a disparity between the monitor and the end-station

    • TTL

    • Checksum

    • Overflowing monitor buffers

See http://www.secnet.com/papers/ids-html/ for detailed examples


Is bro useless

is bro useless?

  • Of course not.

    • Remember, most of the problems are caused by idiots; they don’t know how to subvert bro and the techniques can’t be pre-packaged easily.

  • It doesn’t cost us anything.

    • Just because the monitor can be subverted doesn’t mean we can’t use it. Using it doesn’t mean we are making a tradeoff, so why not?

  • There is no silver bullet.

    • Don’t expect anysystem to single-handedly “solve” the security problem. Take what you can get.


The reverse approach

the reverse approach

  • Systems like Bro define “bad” -- anything they don’t recognize, therefore, is assumed to be good.

    • Problem: Your “bad” list is always out of date

  • Other systems attempt to define “good” -- anything they don’t recognize is “bad”

    • Now, new badness is automatically caught!

    • Problem: How do you define “good”?


The immune system

the immune system

  • Stephanie Forrest et al were inspired by biological immune systems.

    • A biological immune system doesn’t have a catalog of all viruses that exist in the world

    • They have a strong sense of “self”, allowing them to identify and attack non-self entities

  • Is the same thing possible on the computer?

  • Motivation: UNIX processes; there is a well-known and easy technique for getting almost any buggy program to execute arbitrary code by just sending it carefully!

http://www.cs.unm.edu/~steveah/research.html


Getting to know yourself

getting to know yourself

1.Find a metric that characterizes the system.

2.Build up a database of normal values for that metric when the system is working as it should.

3.Continually monitor the metric; set off an alarm if it deviates from the database.

4.Test the metric for false positives/negatives.


Applying the method

applying the method

  • First target application: sendmail (infamous for many security holes)

  • First metric: system call traces

  • Normal database to be built up by recording sendmail’s behavior in a wide variety of everyday tasks (many types of messages)


System call traces

callcall+1call+2call+3

openread,mmapmmap

system call traces

Sample call sequence:

open, read, mmap, mmap, open, getrlimit, mmap, close

readmmapmmapopen

mmapmmap,open,getrlimit,

open,getrlimitmmap

close

getrlimitmmapclose

close


Database in training

database in training


The normal database

the normal database

  • Using a window size of 6, running sendmail through its paces produced a database of only 1500 entries and was stable!

  • This is only 5x10-5% of all possible entries

  • The small size of the database is critical:

    • Big database = variability in “normal” = difficulty in detecting anomalies

    • Big database = no realtime monitoring


Results

results

Anomaly%Num

sunsendmailcp4.195

syslog:

remote 14.2470

remote 21.5137

local 14.2398

local 23.4309

decode0.324

lprcp1.412

sm565a0.436

sm5x1.7157

forward loop1.858

(sm565a and sm5x were unsuccessful attacks; forward loop was

nonmalicious anomalous behavior; others were successful breakins.)


Discussion

discussion

  • Programs seem to exhibit remarkable amounts of find-grained consistency when operating normally; this can be used to detect anomalies.

  • Since we now know what’s “good”, we can report badness that we have never seen before

  • Will not help to do things like determine that a user has stolen another user’s password

  • A solution for one host, not an entire site

  • Current system runs off-line (on-line planned)


Related work

related work

  • Various expert systems for analyzing logs

    • Systems remain vigilant even given megs of log data every day, where humans throw away data

  • NIDES (ftp://ftp.csl.sri.com/nides)

    • Defines a set of events (e.g. directory modification, password file access, etc.)

    • Complex statistical algos for reporting anomalies while still adaptively learning new user behavior

  • Keystroke Dynamics - knows how users type


Bringing it all together

bringing it all together

  • Bro is powerful in that it can monitor an entire site, but weak in that it can’t predict what future attack profiles will look like

  • Forrest’s work, and other systems mentioned, all suggest you can do well by adaptively learning “normal” and reporting deviations

  • Forrest’s work shows that surprisingly high-level characteristics of a system can become evident by looking at events on an extremely low level, fine grain, and small time scale


Another idea

another idea

  • Based on motivations mentioned in the previous slide, a new type of network intrusion detector:

    • Monitors network traffic at the packet level

    • Creates per-flow packet traces similar to system call traces (e.g. SYN -> SYNACK -> ACK; ACK -> DATA -> ACK)

    • Uses various other metrics (e.g. % of total traffic that is SYN, ACK, RST; ratio of ACKs to data; packet size distribution; distribution of source and destination port numbers)

    • Adaptively learns what is “normal” for both traces and other metrics; reports abnormalities


  • Login