+ All Categories
Home > Documents > Security Introduction Class 11 18 February 2003. Overview Security Properties Security Primitives ...

Security Introduction Class 11 18 February 2003. Overview Security Properties Security Primitives ...

Date post: 23-Dec-2015
Category:
Upload: nathaniel-parrish
View: 219 times
Download: 0 times
Share this document with a friend
Popular Tags:
38
Security Introduction Class 11 18 February 2003
Transcript

Security Introduction

Class 11

18 February 2003

Overview

Security Properties

Security Primitives

Sample Protocols

Introducing Protocol Participants

Alice (usually the protocol initiator) Bob, Alice’s friend Eve the eavesdropper Mallory the malicious adversary Trent the trusted server

Security Properties Confidentiality (secrecy)• Eve cannot get any information• Semantic security–Even if Eve knows plaintext/ciphertext pairs, she

cannot learn any new information

Integrity• Prevent modification

Authentication• Prevent impersonation• Bob knows that Alice sent message

Security Properties (cont)

Non-repudiation• Alice cannot deny having created message

Freshness• Bob knows that Alice’s message is recent

• Replay protection–Mallory cannot replay Alice’s messages

Security Primitives Asymmetric (public-private key)• Diffie-Hellman key agreement

• Public-key encryption

• Digital signature

Symmetric (shared-key, same-key)• Block cipher (pseudo-random permutation PRP)

• Stream cipher (pseudo-random generators PRG)

• Message authentication code (MAC)

Others (unkeyed symmetric)• One-way function

• Cryptographic hash function

Asymmetric Primitives

Diffie-Hellman key agreement• Public values: large prime p, generator g

• Alice has secret value a, Bob has secret b

• A B: ga (mod p)

• B A: gb

• Bob computes (ga)b = gab

• Alice computes (gb)a = gab

• Eve cannot compute gab

Asymmetric Primitives II Problem: man-in-the-middle attack Mallory can impersonate Alice to Bob,

Bob to Alice• A M: ga (mod p)

• M A: gm

• M B: gm

• B M: gb

• Bob computes (gm)b = gbm

• Alice computes (gm)a = gam

Asymmetric Primitives III

Public-key encryption El-Gamal encryption• Public values: large prime p, generator g

• Alice has public key ga (mod p), private key a

• Bob wants to send message M to Alice

• Bob picks random x, computes (ga)x = gax

• B A: gx, Mgax

Asymmetric Primitives IV Digital Signatures RSA signature• Alice has large secret primes p, q• Pick e, compute d s.t. ed = 1 mod (pq)• Public key N=pq, e• Private key p, q, d

• Signature generation of message M

= H(M)d mod N

• Signature verification:

e = H(M)ed = H(M)1 + K(pq) = H(M) (mod N)

Symmetric Primitives

Block cipher is a pseudo-random permutation (PRP), each key defines a one-to-one mapping

Encryption: EK(plaintext) = ciphertext

Decryption: DK(ciphertext) = plaintext

We write {plaintext}K for EK(plaintext)

Encrypt each block separately Examples: DES, Rijndael

Symmetric Primitives II Stream ciphers use pseudo-random

generators (PRG) PRG• Input: seed• Output: pseudo-random stream

Encryption: use shared key k and initialization vector IV for the seed ciphertext = plaintext PRG( k, IV )

Send IV, ciphertext Examples: RC4, SEAL

Symmetric Primitives III

Message authentication codes (MAC) “Cryptographic checksum”, keyed hash Provides authentication, integrity Send M, MAC( K, M ) Example: HMAC-MD5• HMAC-MD5(K, M ) = MD5(K opad ||

MD5(K ipad || M))

• ipad = 3636..36, opad = 5C5C..5C

Cryptographic Hash Functions Maps arbitrary-length input into finite

length output Properties of a secure hash function• One-way: Given y = H(x), cannot find

x’ s.t. H(x’) = y• Weak collision resistance: Given x, cannot

find x’ ≠ x s.t. H(x) = H(x’)• Strong collision resistance: Cannot find x, x’

s.t. H(x) = H(x’) Example: MD5, SHA-1

One-Way Hash Chains Versatile cryptographic primitive Construction• Pick random rN and public one-way function F• ri = F(ri+1)• Secret value: rN , public value r0

Properties• Use in reverse order of construction: r1 , r2 … rN • Infeasible to derive ri from rj (j<i)• Efficiently authenticate ri knowing rj (j<i):

verify rj = Fi-j(ri)• Robust to missing values

K5 K6 K7K4K3FFF

K5F

Comparison Sym vs Asym Crypto

Symmetric crypto 72 bit key for high

security (2000) ~1,000,000 ops/s

10x speedup in HW

Asymmetric crypto 1024 bit key for high

security (RSA) ~100 signatures/s

~1000 verify/s (RSA) Marginal speedup in

HW

Sample Protocols

Sensor network encryption protocol

(SNEP)

Broadcast authentication TESLA

PayWord

MicroMint

SPINS Assumptions Communication• Frequent node-base station exchanges

• Frequent network flooding from base

• Node-node interactions infrequent

Base station• Sufficient memory, power

• Shares secret key with each node

Node• Limited resources, limited trust

SNEP Security Goals

Secure point-to-point communication• Confidentiality

• Secrecy

• Authenticity

• Integrity

• Message freshness to prevent replay

Existing protocols use expensive asymmetric crypto (e.g. SSL/TLS, IPSEC)

Basic Crypto Primitives

Code size constraints code reuse

Uses block cipher encrypt function

• Counter mode encryption

• Cipher-block-chaining message

authentication code (MAC)

• Pseudo-random generator

SNEP Protocol Details

A and B share

• Encryption keys: KAB KBA

• MAC keys: K'AB K'BA

• Counters: CA CB

To send data D, A sends to B:

A B: {D}<KAB, CA> ,

MAC( K'AB , [CA || {D}<KAB, CA>] )

SNEP Properties

Secrecy & confidentiality• Semantic security against chosen ciphertext attack

• Strongest security notion for encryption

Authentication

Replay protection

Code size: 1.5 Kbytes

Strong freshness protocol

Need to Stretch?

Broadcast Authentication Broadcasts data over wireless network

Packet injection usually easy

Each receiver can verify data origin

Sender

Bob

M

Carol

M

DaveAliceMM

Authentication Needs Asymmetry

SenderK

AliceK

BobK

Msg, MAC(K,Msg)

Forged Msg, MAC(K, Forged Msg)

Msg, MAC(K,Msg)

MAC: Message Authentication Code (authentication tag)

K = shared key

Digital Signatures Do Not Work

Signatures are expensive, e.g., RSA 1024:

• High generation cost (~10 milliseconds)

• High verification cost (~1 millisecond)

• High communication cost (128 bytes/packet)

Very expensive on low-end processors

If we aggregate signature over multiple

packets, intolerant to packet loss

TESLA

Timed Efficient Stream Loss-tolerant

Authentication

Uses only symmetric cryptography

Asymmetry via time

• Delayed key disclosure

• Requires loose time synchronization

Published in IEEE Security and Privacy 2000,

NDSS 2001 [PCST]

Basic Authentication Mechanism

t

F(K)AuthenticCommitment

P

MAC(K,P)

Kdisclosed

1: Verify K

2: Verify MAC

3: P Authentic!

F: public one-way function

Security Condition

Receiver knows key disclosure schedule

Security condition (for packet P):

on arrival of P, receiver is certain that sender

did not yet disclose K

If security condition not satisfied, drop packet

TESLA Keys disclosed 2 time intervals after use Receiver setup: Authentic K3, key

disclosure schedule

K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K4K3

P2

K5

P1

K3

Authentication of P1: MAC(K5, P1 )

Verify MAC

FFF

Authenticate K5

K5

Time 3

F

TESLA: Robust to Packet Loss

K4 K5 K6 K7

tTime 4 Time 5 Time 6 Time 7

K3

P5

K5

P3

K3

P2

K2

P1

K2

Verify MACs

P4

K4

FF

Authenticate K5

TESLA Summary

Low overhead• Communication (~ 20 bytes)• Computation (~ 1 MAC computation per packet)

Perfect robustness to packet loss Independent of number of receivers Delayed authentication Extensions:• TIK: Instant key disclosure• Heterogeneous receivers• Instant authentication (sender buffers data)

PayWord and MicroMint

PayWord: a credit-based scheme using one-way hash chain: w0 w1 w2 w3 ...

MicroMint: digital coins as k-way hash

function collisions: x1 x2 x3 x4

y

PayWord Payment Model

Broker model to intermediate and aggregate

Broker

VendorUser

1. Obtain authorization orcoins

2. Purchase information from vendor; pay.

3. Redeem payments

Banks and Credit-cardcompanies

(Inner loop)

PayWord Broker signs User’s public key (certificate) User creates one-way hash chain to buy

goods from vendor, c0 , …, cN Each one-way chain element has value v User signs c0 and sends it to vendor User can incrementally pay by revealing

successive elements ci Vendor redeems payment by cashing

largest element cj , value = v*j

MicroMint A digital coin should be:• Hard to produce [except by Broker]• Easy to verify [by anyone]

Digital signatures “work,” but are relatively expensive

MicroMint uses hash functions only (no public-key crypto)

Broker utilizes economy of scale to produce MicroMint coins cheaply (as with a regular mint)

Economy of Scale in MicroMint

Number of balls thrown

Pro

bab

ility

of

fin

din

g c

olli

sio

n

Minting MicroMint Coins Pick a one-way hash function F, mapping

inputs to n-bit outputs A valid coin is a k-way collision Find v1, …, vk, s.t. F(v1) = … = F(vk) Verification is very efficient Producing first 2-way collision requires time

2n/2 (birthday paradox) Producing first k-way collision requires time

Nk = 2n(k-1)/k Time cNk yields ck coins; once threshold of

Nk is passed, coins are produced rapidly


Recommended