Essentials of Security

Zachary G. IvesUniversity of Pennsylvania

CIS 455 / 555 – Internet and Web Systems

April 21, 2023

Administrivia

Midterm results returned today

After +15 points bonus credit: Mean 88, StDev 14.8 Max 115, Min 62

Please read PNUTs paper for Monday

2

3

Distributed Security and E-Commerce

Transactions make sure things happen when we want them to…

Security makes sure things don’t happen when we don’t want them to! Let’s look at some essentials of security in

distributed environments

4

Basic Terminology

Authorization: determines mode of access allowed Common solutions: access control lists, capabilities, … We previously discussed how views could be used to

define authorization levels Authentication: means of verifying identity

Common cases: password/UID, PIN, fingerprint, demonstration of ability to encrypt with private key, etc.

Encryption: used to protect data A common notation, used in the chapter from

Lewis/Bernstein/Kifer that appears in your reader:ciphertext = Ksender[plaintext]

plaintext = Kreceiver[Ksender[plaintext]]

Let’s look at encryption in detail…

5

Authorization (Access Control)

Capabilities Special, hard-to-forge “handles” or “pointers” to

objects/services Independent of authentication of who a user is Possessing a capability you can use the service/object

e.g., pass-phrase; SHA-1 key; private key; etc. Capabilities are easy to pass on to others, but hard to

revoke

Access Control Lists (ACLs) During each access to an object/service,

authorization is checked against a list Usually a notion of different groups, rights e.g., Unix or Windows file system; most databases

Easy to revoke rights; hard to pass them on Requires a scheme for authenticating a user

Most commonapproachtoday

6

Granularity: What to Control

In a file system, ACLs are checked at the granularity of an open, a read, a write, etc. to a whole file Analogous process holds HTTP server, when we

protect directories, files This is great for large, atomic units, e.g., images

But sometimes we need finer-grained detail If exporting XML, we may want to expose different

data to marketing than we do order fulfillment Add access control lists over views of the data,

i.e., query results

7

Hypothetical View-BasedProtection Example

define function MarketingView() returns purchase*{

for $p in doc(“purchases.xml”)/purchases/purchasewhere $p/date() >= fn:todays-date() –

fn:dateInterval(0,1,0)return <purchase>

{ $p/isbn }{ $p/addr/state }

</purchase>}define function OrderFulfillmentView() returns purchase*{

for $p in doc(“purchases.xml”)/purchases/purchasereturn $p

}grant permission read on MarketingView to MarketerGroupgrant permission read on OrderFulfillmentView to WarehouseGroup

8

View-Based Security

Views restrict attributes and values that are visible Thus restricting the queries that can be posed Much more powerful than simply restricting documents

Caveat: not always enough to guarantee security – sometimes information is inadvertently “leaked” Might correlate info from multiple tables with different

attributes Might know, e.g., that there’s only one customer in a given

state…

OK, so how do we enforce that data is limited only to those who are authorized to access it? Let’s look at some attacks…

Common Single-Machine Attacks

“Social engineering” – e.g., phishing, malware – enables a machine to authenticate as you Often, this enables it to do things – e.g., purchase items as

you (on the Internet), or modify your files (on your machine)

Privilege escalation – finding a design flaw in software allowing normally-disallowed privileges e.g., finding a way to get root permissions through an

exception

Code injection – finding a way to send data to a system, such that it will execute it as code e.g., SQL injection, stack smashing, cross-site scripting (one

site injects data that gets interpreted as JavaScript in another protection zone)

9

Network-Centric Attacks

How do we ensure, on a TCP/IP network: We know who we’re talking to, so we give

them the right permissions? Nobody can eavesdrop on our communication

and steal our data?

Let’s start with some vulnerabilities

10

11

Message-Dropping Attacks

Can happen if someone manages to get between “us” and whomever we’re conversing with How might this happen?

By and large, our protocols are resilient to occasional dropped messages Not much happens without

acknowledgement – we frequently time out

C S

C S

“order”

“confirm?”

12

Replay Attacks

A very simple attack Intruder doesn’t

need to understand or alter the contents of a message – just send it multiple times Can be all at once, or

can play the message again a week later…

C S

“buy 5 copies”

I

“buy 5 copies”

13

Message Forging Attacks

Generally more difficult than the first two classes Needs the ability to

modify messages from the sender C S

“buy 5 copies”

I

“buy 5000 copies,ship to Hawaii”

14

“Man in the Middle” Attacks

The intruder impersonates both the client and the sender Sometimes, this is by

“IP spoofing” – pretending that packets originate from a different host

Intruder can masquerade as the client from then on

C S

“Hi, amazon.com,my passwordis 1234”

I

“Welcome toamazon.com”

schuylkill.com amazon.com

“Hi, amazon.com,my passwordis 1234…”

“… andI’d like tobuy a redMazdaMiata…”

15

Distributed Security

Generally, we’re going to: Try to ensure that messages can’t be replayed Try to ensure that messages are unforgeable See if we can avoid most man-in-the-middle

attacks

16

Encryption/Decryption

Illustration from Lewis/Bernstein/Kifer

17

Symmetric Cryptography

Uses the same key for encryption and decryption Aka secret key crytography

Block cipher: block of text ciphertext block Substitution cipher – simple substitutions of char(s) for

char(s) Transposition cipher – reorder the chars in the block DES (Data Encryption Standard) – only 56b key

Sequence of stages that encrypt one another’s output Makes it less vulnerable to frequency analysis attack

Non-block cipher Bitstream cipher

XORs plaintext with pseudo-random numbers generated when key is used as seed value

What if the random number generator isn’t very random?

18

Asymmetric Encryption

This is public/private-key encryption (public key cryptography)

Here:M = KC

priv [KC

pub [M]]

For two-way communication, use a second key-pair (Often public key algorithm is commutative, though)

First proposed public-key encryption scheme was Diffie-Hellman ’76

But we generally use RSA

19

RSA Algorithm

1. Create two large, e.g. 1024b, relatively prime numbers, p and qChoose decryption int. d relatively prime to (p - 1)(q - 1)Choose encryption int. e so gcd(e, d) = 1 (commonly 3, 17, or 65537)

2. Break message into blocks, M, treated as ints from 0 to pq – 1

Encryption key = (e, pq)Decryption key = (d, pq)

3. To encrypt, C = Me (mod pq)4. To decrypt, M = Cd (mod pq)

Works because M = (Me (mod pq))d (mod pq) due to “elementary number theory”

Relies on fact that factoring pq is (believed to be) expensive

20

Digital Signatures -- I/II

Frequently, we need to sign a message to verify it came from us (or our server)

Can use asymmetric cryptography if M = KC

pub [KC

priv [M]] Encrypt message with private key; validate

with public key (Obviously, others need to get the public key)

21

Digital Signatures – II/II

Less costly: message digests Compute a one-way hash, f(M) , with these

properties: All values in f’s range are equally likely

Unlikely that we can find M’ where f(M) = f(M’) because large number of Ms map to same region

If any bit of the message is changed, every bit in f(M) has a 50% chance of changing

f(M), f(M’) aren’t same simply because M, M’ are similar

Encrypt this, KCpriv[f(M)] and send with M

Just given this, what attacks might be possible?

22

Nonces Prevent Replay Attacks

To prevent replay attacks, we need to ensure that a message would be different each time it’s sent, and we keep track of what we’ve already seen

A nonce is a special bit string that’s difficult to forge but easy to authenticate Commonly, the client or server will pick some value N and

encrypt it Responses will return N+1 (encrypted), etc.

Frequently, the initial N is a timestamp or message counter

A form of a nonce called salt is often added not for authentication, but to make it harder to guess the message content

23

Key Distribution

Whether public or secret key cryptography is used, must be able to tell who we’re talking with: Need to negotiate a session key (Kerberos) or need to get a public key (SSL)

Why is authentication critical?

24

The Kerberos Protocol (from MIT)

Used commonly to authenticate to a server Relies on a trusted third party, a Key

Distribution Server Users and servers have kerberos authentication keys,

KC,KDS, KS,KDS, used to authenticate with the KDS The KDS creates a session key and distributes it in a

ticket that’s used for conversing with the server S Can also provide single sign-on: one

authentication that’s shared across machines Give a ticket-granting ticket that is used to talk

with a ticket-granting server in a way that’s similar

25

Tickets and Kerberos

Illustration from Lewis/Bernstein/Kifer

names of C, S in cleartextKC,KS[Ksess, S, TTL]

KS,KS[Ksess, C, TTL]

KC,KS = f(PC)

Ksess[C, time]

26

E-Commerce

Clearly, one of the biggest uses of authentication on the Web today

B2B: can often negotiate secret keys between pairs

Selling to consumer (B2C/C2B) often requires several levels of authorization and authentication: Want to authenticate the user Want to authenticate the credit card company server Want to check for user authorization to purchase

… And obviously, want to prevent eavesdropping and replay!

27

Secure Sockets Layer (SSL)

Like Kerberos, relies on a trusted third party Certificate authority (CA) issues certificates to

certify a server and its public key Verisign is perhaps the best known of these

A server S generates public-private keypair Sends the public key, other info (plus $$$) to

Verisign (etc.) Gets back a certificate with:

CA name S’s name, URL, public key Timestamp and expiration info

28

Example Certificate

Owner: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

Issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

Serial number: 1a3

Valid from: Fri Feb 23 23:01:00 GMT 1996 until: Thu Feb 23 23:59:00 GMT 2006

Certificate fingerprints:MD5: C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58SHA1: 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6:89:64

29

The SSL Protocol

Client C connects to server S from enterprise E S sends E’s certificate (cleartext) C validates the certificate using the CA (e.g.,

Verisign)’s public key C generates and sends to S a session key

encrypted with E’s public key

Java has built-in support for SSL (Java Secure Socket Extension, integrated in 1.4) and a tool for managing certificates (keytool)

30

So…

The client and server know each other given SSL How do we go ahead and make a purchase?

Most commonly: you enter your credit card number Sometimes this is stored in the retailer’s system for future

purposes! Best case:

The CC info is stored in a special, firewalled server, not part of the web site

Web server has other account info about you When a transaction goes through, web site sends order to

this special server, which combines it with CC info and sends it onward

But often it’s not quite so secure!

Protocols have been proposed (e.g., SET from VISA) that don’t use credit card info – but not really adopted