CENG 520 Lecture Note VI

Hash Functions
condenses arbitrary message to fixed size
h = H(M)

usually assume hash function is public hash used to detect changes to message want a cryptographic hash function
computationally infeasible to find data mapping to specific hash (one-way property) computationally infeasible to find two data to same hash (collision-free property)

Cryptographic Hash Function

Hash Functions & Message Authentication

Hash Functions & Digital Signatures

Other Hash Function Uses

to create a one-way password file
store hash of password not actual password

for intrusion detection and virus detection

keep & check hash of files on system

pseudorandom function (PRF) or pseudorandom number generator (PRNG)

Two Simple Insecure Hash Functions

consider two simple insecure hash functions bit-by-bit exclusive-OR (XOR) of every block
Ci = bi1 xor bi2 xor . . . xor bim a longitudinal redundancy check reasonably effective as data integrity check

one-bit circular shift on hash value

for each successive n-bit block
rotate current hash value to left by1bit and XOR block

good for data integrity but useless for security

Hash Function Requirements

Attacks on Hash Functions

have brute-force attacks and cryptanalysis a preimage or second preimage attack
find y s.t. H(y) equals a given hash value

collision resistance
find two messages x & y with same hash so H(x) = H(y)

hence value 2m/2 determines strength of hash code against brute-force attacks
128-bits inadequate, 160-bits suspect

Birthday Attacks
might think a 64-bit hash is secure but by Birthday Paradox is not birthday attack works thus:
given user prepared to sign a valid message x m/ opponent generates 2 2 variations x of x, all with essentially the same meaning, and saves them m/ opponent generates 2 2 variations y of a desired fraudulent message y two sets of messages are compared to find pair with same hash (probability > 0.5 by birthday paradox) have user sign the valid message, then substitute the forgery which will have a valid signature

conclusion is that need to use larger MAC/hash

Hash Function Cryptanalysis

cryptanalytic attacks exploit some property of alg so faster than exhaustive search hash functions use iterative structure
process message in blocks (incl length)

attacks focus on collisions in function f

Block Ciphers as Hash Functions

can use block ciphers as hash functions
using H0=0 and zero-pad of final block compute: Hi = EMi [Hi-1] and use final block as the hash value similar to CBC but without a key

resulting hash is too small (64-bit)

both due to direct birthday attack and to meet-in-the-middle attack

other variants also susceptible to attack

Secure Hash Algorithm

SHA originally designed by NIST & NSA in 1993 was revised in 1995 as SHA-1 US standard for use with DSA signature scheme
standard is FIPS 180-1 1995, also Internet RFC3174 nb. the algorithm is SHA, the standard is SHS

based on design of MD4 with key differences produces 160-bit hash values recent 2005 results on security of SHA-1 have raised concerns on its use in future applications

Revised Secure Hash Standard

NIST issued revision FIPS 180-2 in 2002 adds 3 additional versions of SHA
SHA-256, SHA-384, SHA-512

designed for compatibility with increased security provided by the AES cipher structure & detail is similar to SHA-1 hence analysis should be similar but security levels are rather higher

SHA Versions
SHA-1 Message digest size Message size Block size Word size SHA-224 SHA-256 SHA-384 SHA-512

160
< 264 512 32 80

224
< 264 512 32 64

256
< 264 512 32 64

384
< 2128 1024 64 80

512
< 2128 1024 64 80

Number of steps

SHA-3
SHA-1 not yet "broken
but similar to broken MD5 & SHA-0 so considered insecure

SHA-2 (esp. SHA-512) seems secure

shares same structure and mathematical operations as predecessors so have concern

NIST announced in 2007 a competition for the SHA-3 next gen NIST hash function
goal to have in place by 2012 but not fixed

SHA-3 Requirements
replace SHA-2 with SHA-3 in any use
so use same hash sizes

preserve the online nature of SHA-2

so must process small blocks (512 / 1024 bits)

evaluation criteria
security close to theoretical max for hash sizes cost in time & memory characteristics: such as flexibility & simplicity

Message Authentication
message authentication is concerned with:
protecting the integrity of a message validating identity of originator non-repudiation of origin (dispute resolution)

will consider the security requirements then three alternative functions used:
hash function (see Ch 11) message encryption message authentication code (MAC)

Symmetric Message Encryption

encryption can also provides authentication if symmetric encryption is used then:
receiver know sender must have created it since only sender and receiver now key used know content cannot of been altered if message has suitable structure, redundancy or a checksum to detect any changes

Public-Key Message Encryption

if public-key encryption is used:
encryption provides no confidence of sender
since anyone potentially knows public-key

however if
sender signs message using their private-key then encrypts with recipients public key have both secrecy and authentication

again need to recognize corrupted messages but at cost of two public-key uses on message

Message Authentication Code (MAC)

generated by an algorithm that creates a small fixed-sized block
depending on both message and some key like encryption though need not be reversible

appended to message as a signature receiver performs same computation on message and checks it matches the MAC provides assurance that message is unaltered and comes from sender

Message Authentication Code

a

small fixed-sized block of data generated from message + secret key MAC = C(K,M) appended to message when sent

Message Authentication Codes

as shown the MAC provides authentication can also use encryption for secrecy
generally use separate keys for each can compute MAC either before or after encryption is generally regarded as better done before

why use a MAC?

sometimes only authentication is needed sometimes need authentication to persist longer than the encryption (eg. archival use)

note that a MAC is not a digital signature

MAC Properties
a MAC is a cryptographic checksum
MAC = CK(M) condenses a variable-length message M using a secret key K to a fixed-sized authenticator

is a many-to-one function
potentially many messages have same MAC but finding these needs to be very difficult

Requirements for MACs

taking into account the types of attacks need the MAC to satisfy the following:
1. knowing a message and MAC, is infeasible to find another message with same MAC 2. MACs should be uniformly distributed 3. MAC should depend equally on all bits of the message

Security of MACs
like block ciphers have: brute-force attacks exploiting
strong collision resistance hash have cost
m/ 2 2

128-bit hash looks vulnerable, 160-bits better

MACs with known message-MAC pairs

can either attack keyspace (cf key search) or MAC at least 128-bit MAC is needed for security

Security of MACs
cryptanalytic attacks exploit structure
like block ciphers want brute-force attacks to be the best alternative

more variety of MACs so harder to generalize about cryptanalysis

Keyed Hash Functions as MACs

want a MAC based on a hash function
because hash functions are generally faster crypto hash function code is widely available

hash includes a key along with message original proposal:

KeyedHash = Hash(Key|Message) some weaknesses were found with this

eventually led to development of HMAC

HMAC
specified as Internet standard RFC2104 uses hash function on the message:
HMACK(M)= Hash[(K+ XOR opad) || Hash[(K+ XOR ipad) || M)] ] where K+ is the key padded out to size opad, ipad are specified padding constants

overhead is just 3 more hash calculations than the message needs alone any hash function can be used
eg. MD5, SHA-1, RIPEMD-160, Whirlpool

HMAC Overview

Using Symmetric Ciphers for MACs

can use any block cipher chaining mode and use final block as a MAC Data Authentication Algorithm (DAA) is a widely used MAC based on DES-CBC
using IV=0 and zero-pad of final block encrypt message using DES in CBC mode and send just the final block as the MAC
or the leftmost M bits (16M64) of final block

but final MAC is now too small for security

Data Authentication Algorithm

CMAC
previously saw the DAA (CBC-MAC) widely used in govt & industry but has message size limitation can overcome using 2 keys & padding thus forming the Cipher-based Message Authentication Code (CMAC) adopted by NIST SP800-38B

CMAC Overview

Authenticated Encryption
simultaneously protect confidentiality and authenticity of communications
often required but usually separate

approaches
Hash-then-encrypt: E(K, (M || H(M)) MAC-then-encrypt: E(K2, (M || MAC(K1, M)) Encrypt-then-MAC: (C=E(K2, M), T=MAC(K1, C) Encrypt-and-MAC: (C=E(K2, M), T=MAC(K1, M)

decryption /verification straightforward but security vulnerabilities with all these

Key Management and Distribution

topics of cryptographic key management / key distribution are complex
cryptographic, protocol, & management issues

symmetric schemes require both parties to share a common secret key public key schemes require parties to acquire valid public keys have concerns with doing both

Key Distribution
symmetric schemes require both parties to share a common secret key issue is how to securely distribute this key whilst protecting it from others frequent key changes can be desirable often secure system failure due to a break in the key distribution scheme

Key Distribution
given parties A and B have various key distribution alternatives:
1. A can select key and physically deliver to B 2. third party can select & deliver key to A & B 3. if A & B have communicated previously can use previous key to encrypt a new key 4. if A & B have secure communications with a third party C, C can relay key between A & B

Key Hierarchy
typically have a hierarchy of keys session key
temporary key used for encryption of data between users for one logical session then discarded

master key
used to encrypt session keys shared by user & key distribution center

Key Distribution Scenario

Key Distribution Issues

hierarchies of KDCs required for large networks, but must trust each other session key lifetimes should be limited for greater security use of automatic key distribution on behalf of users, but must trust system use of decentralized key distribution controlling key usage

Symmetric Key Distribution Using Public Keys

public key cryptosystems are inefficient
so almost never use for direct data encryption rather use to encrypt secret keys for distribution

Simple Secret Key Distribution

Merkle proposed this very simple scheme
allows secure communications no keys before/after exist

Man-in-the-Middle Attack
this very simple scheme is vulnerable to an active man-in-the-middle attack

Secret Key Distribution with Confidentiality and Authentication

Hybrid Key Distribution

retain use of private-key KDC shares secret master key with each user distributes session key using master key public-key used to distribute master keys
especially useful with widely distributed users

rationale
performance backward compatibility

Distribution of Public Keys

can be considered as using one of:
public announcement publicly available directory public-key authority public-key certificates

Public Announcement
users distribute public keys to recipients or broadcast to community at large
eg. append PGP keys to email messages or post to news groups or email list

major weakness is forgery

anyone can create a key claiming to be someone else and broadcast it until forgery is discovered can masquerade as claimed user

Publicly Available Directory

can obtain greater security by registering keys with a public directory directory must be trusted with properties:
contains {name,public-key} entries participants register securely with directory participants can replace key at any time directory is periodically published directory can be accessed electronically

still vulnerable to tampering or forgery

Public-Key Authority
improve security by tightening control over distribution of keys from directory has properties of directory and requires users to know public key for the directory then users interact with directory to obtain any desired public key securely
does require real-time access to directory when keys are needed may be vulnerable to tampering

Public-Key Authority

Public-Key Certificates
certificates allow key exchange without realtime access to public-key authority a certificate binds identity to public key
usually with other info such as period of validity, rights of use etc

with all contents signed by a trusted PublicKey or Certificate Authority (CA) can be verified by anyone who knows the public-key authorities public-key

Public-Key Certificates

X.509 Authentication Service

part of CCITT X.500 directory service standards
distributed servers maintaining user info database

defines framework for authentication services

directory may store public-key certificates with public key of user signed by certification authority

also defines authentication protocols uses public-key crypto & digital signatures
algorithms not standardised, but RSA recommended

X.509 certificates are widely used

have 3 versions

X.509 Certificates
issued by a Certification Authority (CA), containing:
version V (1, 2, or 3) serial number SN (unique within CA) identifying certificate signature algorithm identifier AI issuer X.500 name CA) period of validity TA (from - to dates) subject X.500 name A (name of owner) subject public-key info Ap (algorithm, parameters, key) issuer unique identifier (v2+) subject unique identifier (v2+) extension fields (v3) signature (of hash of all fields in certificate)

notation CA<<A>> denotes certificate for A signed by CA

X.509 Certificates

Obtaining a Certificate
any user with access to CA can get any certificate from it only the CA can modify a certificate because cannot be forged, certificates can be placed in a public directory

CA Hierarchy
if both users share a common CA then they are assumed to know its public key otherwise CA's must form a hierarchy use certificates linking members of hierarchy to validate other CA's
each CA has certificates for clients (forward) and parent (backward)

each client trusts parents certificates enable verification of any certificate from one CA by users of all other CAs in hierarchy

Certificate Revocation
certificates have a period of validity may need to revoke before expiry, eg:
1. user's private key is compromised 2. user is no longer certified by this CA 3. CA's certificate is compromised

CAs maintain list of revoked certificates

the Certificate Revocation List (CRL)

users should check certificates with CAs CRL

X.509 Version 3
has been recognised that additional information is needed in a certificate
email/URL, policy details, usage constraints

rather than explicitly naming new fields defined a general extension method extensions consist of:
extension identifier criticality indicator extension value

Certificate Extensions
key and policy information
convey info about subject & issuer keys, plus indicators of certificate policy

certificate subject and issuer attributes

support alternative names, in alternative formats for certificate subject and/or issuer

certificate path constraints

allow constraints on use of certificates by other CAs

Public Key Infrastructure

PKIX Management
functions:
registration initialization certification key pair recovery key pair update revocation request cross certification

protocols: CMP, CMC