Security & Payments

Computerized identification techniques

Password-based systems

Physical tokens

Biometrics 1 2

Location

Digital Signatures

Encryption algorithms

Secret Key Encryption

Sender and Receiver need to share a common secret key

Main problem:
- How participants safely exchange a common secret key
- For N participants, as many as N*N = N^2 keys are required

Common algorithms: DES (Data Encryption Standard), Triple DES, RC5
Currently under development: AES (Advanced Encryption Standard)

Public-key encryption

Sender and Receiver each have a pair of keys
a public and a private key each.
Public keys are public.
Private keys are kept secret by their owner.

To send an encrypted message:

sender encrypts with receiver's public key
receiver decrypts with receiver's private key
Nobody but the receiver can decrypt the message!

To send a signed message:

sender encrypts with sender's private key
receiver decrypts with sender's public key
Anybody can decrypt the message!
Only the particular sender could have sent the message!

Advantage:
- sender and receiver need not share a secret key.
- For N participants, only N key pairs are required.

Main problems:
Public-key encryption is 2-3 orders of magnitude slower than secret-key encryption. Hence public-key encryption is used to exchange secret keys. Secret-key encryption is then used for the data itself.

Authenticity problem: How does a user know that the public key that is thought to belong to Bob actually belongs to Bob? The certificate concept addresses this problem.

Common algorithms:
Rivest-Shamir-Adleman (Refs: 1 2 3 )
Elliptic Curve Cryptosystems (Refs: 1 2 3 4)

ECC keys smaller than RSA (1/6) for similar security
RSA 7x faster for encryption and verification
ECC 6.4x faster for decryption and signing
ECC has high setup cost
Little practical impact of the differences

Cryptographic Strengh

• Difficulty of key search
• Difficulty of inverting the encyption algorithm without knowing the key
• Lack of back doors, i.e. other ways by which an encrypted file can be decrypted without knowing the key.
• Ability to decrypt an entire message if you know how one portion of it decrypts (known plaintext attack).
• Properties of plaintext and knowledge of these properties by an attacker.

Cryptographic strength cannot be proven, but it may be disproven.

Attacks on symmetric encryption algorithms

• Key search (brute force) attacks
• Known plaintext attacks
• Chosen plaintext attacks
• Systems-based attacks (attack the system not the algorithm)

Attacks on public key encryption algorithms

• Factoring attacks
• Algorithmic attacks

Message digest or cryptographic hash or checksum

Objective: To protect message against tampering while in transit.

Property of the message digest:
Given a message and its corresponding message digest, it is computationally infeasible to find another message with the same message digest value.

Therefore if message is tampered with, comparison will fail.

Common algorithms: MD5, SHA, HMAC

Much faster than DES or RSA.

Services

1. Privacy in communication

2. Authentication: establish identity of participants

3. Message integrity: detect message sent by an imposter that claims to be the other participant.

What Cryptography Can't protect

• unencrypted documents
• against stolen encryption keys
• against denial-of-service attacks
• against the record of a message or the fact that a message was sent
• against a sabotaged encryption program
• against a traitor or a mistake

back to Overview

Using encryption: Protocols

Authentication protocols

a. Simple three-way handshake

Participants already share a common secret key.

Objectives:
- Client ensures talking to the true server and vice versa
- Client and server exchange another secret key just for this session

x,y: random numbers
SHK = CHK = server/client handshake key (a permanent shared secret key)
SK = session key (secret - for further exchanges in session)
E(x, CHK) = x encrypted with key CHK

SHK/CHK may be a transformed version of a password.

b. Trusted third party

Three parties A, B, and S.
A and B each share secret keys Ka and Kb with S (authentication server).
A and B know nothing about each other.

Objectives:
- To get A and B to trust each other's identity.
- To generate a secret key K for this session only

A, B: identifiers (names) of participants
T: timestamp (plays role of random number, too)
L: lifetime of session key K

c. Public key authentication

Objective: A wants to ensure that the available public key for B is correct.

Message Integrity protocols

a) Digital signature using RSA

Encrypt message with private key.

b) Keyed MD5

Sender S sends:

message + MD5(message + K) + E (K, privateS)

where K is a random number

Receiver:

- obtains K' by using publicS on E(K, privateS)
K' should be equal to K if message has not been tampered with.

- computes MD5 (message + K')

- compares result with the MD5 (message + K) sent.
They match only if K = K'.

c) MD5 with RSA signature

Sender sends:

msg = message + MD5(message) + E (MD5(message), privateS)

Receiver:

- decrypts MD5(message) using publicS on third part of msg.
- compares decrypted MD5(message) with second part of msg.

d) Public key distribution - informal

Public keys should still be safeguarded. Chains of trust.

A, B exchange public keys while in the same room
A, C exchange public keys at a later time when in the same room
A can sign C's public key and send it to B.
Now B has C's public key.
Chains of trust can be established this way.

Key-signing parties: Lots of A,B,Cs in a room with their laptops.

f) Public Key distribution -- Digital Certificates, Certification Authorities

Purpose:

To match identity of an individual A with his/her public key.

Content:

• Identity of A
• A's public key
• Digitally signed by the Certification Authority (CA) public key

Assumptions:

• CAs are established institutions (e.g. government, banks, credit card companies)
• Everybody knows the public keys of all CAs
• The CA has made a physical check of A before issuing A's digital certificate

e) Exchanging a secret key securely

Diffie-Hellman exchange protocol (Refs: 1 2)

f) Pretty Good Privacy (PGP)
PGP software PGP-based products

Purpose: Encryption and authentication for e-mail

Over time a user participates in key-signing parties and collects a set of certificates with varying degrees of trust (key ring).

Problem: A wants to send message to B and prove to B that it comes from A

• A encodes message body, or sends in the clear
• A creates cryptographic checksum, encrypts with A's private key
• B searches his key ring for A's public key
• If found, B calculates checksum from message
• also decrypts the encoded checksum with A's public key
• PGP also tells B the level of trust associated with A's public key.

back to Overview

Secure Transactions
(Transport Layer Security)

Protocol stack for secure Internet communications

• Payment protocols (SET, Cybercash, First Virtual,...)
• S-HTTP, HTTP, S/MIME, telnet, mail, news, ftp, ....
• Secure Sockets Layer
• TCP
• IP
• Data Link Layer (e.g. Ethernet)

Secure Sockets Layer(SSL),
Transport Layer Security(TLS), Wireless TLS (Refs: 1 2)

Widely used for internet transactions

Purchasing a book over the Internet:

• Shopper sends a hello message to Bookseller
• Bookseller responds with the bookseller's certificate
• Shopper checks bookseller's certificate via the CAs public key
• Shopper generates a secret session key (not bookseller)
• Shopper sends session key encrypted with bookseller's public key
• All subsequent communication uses the session key

Secure HTTP (Refs: 1 2)

• More options than SSL
• At the application layer
• Uses a "secure digital envelope", incl. nonrepudiation
• Never completely implemented
• Not to be confused with HTTPS, a different web protocol that runs on top of SSL.

Sender S, Recipient R
S generates a secret key SK
S sends:

E(message, SK) + E(SK, Public_R) + E( MD(message), Private_S)

Security support in IPv6

Extension headers for including

Security Parameters (encryption/authentication algorithm + key)
Authentication Data

Example of a packet before and after applying encryption & authentication

Before:

OrigIPHeader

TCPHeader

Data

After:

OrigIPHeader	ESPHeader	TCPHeader	Data	ESPTrailer
		encrypted	encrypted	encrypted
	authenticated	authenticated	authenticated	authenticated

ESP: encapsulated security payload

Virtual Private Networks

Tunneling: encapsulate a packet within a packet.
The inside packet can be

of the same protocol or of a different one.
encrypted and authenticated

IPSec (part of IPv6): an open standard for VPNs

Example of tunnel mode

NewIPHeader	ESPHeader	OrigIPHeader	TCPHeader	Data	ESPTrailer
		encrypted	encrypted	encrypted	encrypted
	authenticated	authenticated	authenticated	authenticated	authenticated

back to Overview

Secure Hosts in Networks

Firewalls: sit between the corporate network and the Internet and control packets

Internet --- Web Server --- Firewall --- Corporate network

Internet --- Firewall ---- Corporate network (incl. Web Server)

Internet ---

External Firewall --- Perimeter network (incl. Web Server) ---

Internal Firewall ---- Corporate Network.

Filter-based Firewalls

Packet filtering based on a set of rules at the TCP/IP level
(port no + IP address)

Proxy-Based Firewalls

Problem: company wants to make some of its server's pages publicly accessible, and restrict others to corporate users at remote sites.

Cannot express this as a filter at the TCP/IP level (policy depends on the URL in each HTTP request)

Solution:

• Put an HTTP proxy on the (filter-based) firewall.
• Remote user establishes an HTTP/TCP connection to proxy
• Proxy looks at the URL contained in the request message
• If requested page allowed, proxy establishes a second HTTP/TCP connection to server and forwards the request
• Proxy forwards response in reverse direction

Proxy allows application-specific filtering.

Discussion on Firewalls

Assumptions:

All parties on the corporate network are trusted

Firewall software is bug-free

Firewall is properly configured

Limitations

Slow communications down if very thorough

Misses attacks from insiders, viruses, new sophisticated attacks

Firewalls can be:

General purpose computers (stripped down to the bare essentials)

Special purpose devices (e.g. routers)

Denial-of-Service Attacks

An adversary tries to keep you from accessing information or resources you own.

Flooding of your machine with packets that may:

• cause it to spend all its cycles setting up bogus TCP connections
• fill up caches

Protection requires to:

• account for resources consumed by every user or connection
• detect when resources consumed exceed a limit
• then reclaim resources using as few additional resources as possible

Recent denial of service attacks

• Come from a large number of computers that have been broken into (attack is distributed)
• Packets carry false IP source addresses

Solution must be distributed over the network

• Routers must detect false addresses (slow down, need change in the protocol) and drop the packets
• Authenticated packets (slow down, privacy is reduced) allow easy tracing of the attacks (IPv6 required, PKI infrastructure in place)
• Improve security on all Internet hosts (so that break ins are harder)

References:
CERT Advisory on Denial-of-Service problems
Links to DDoS reviews and tools

back to Overview

Electronic Payments

Issues:

- security vs. fraud

- authenticity

- transaction cost (infrastructure, time needed and direct costs, cost of fraud)

- privacy, anonymity of user, traceability of payments

- acceptability, universality

- person-to-person transferability

- divisibility (granularity of payments)

- online verification of authenticity versus off line (cheaper)

- sharing risk among, user, bank, merchant

- taxation, money laundering, control over national monetary systems

(from J-C. Birget: Notes on Computer Security, Cryptography and Electronic Payments, Faculty of Computer Science, Dalhousie University, 1999).

Stored-account payment systems

Idea:
- credit-card transactions
- confidentiality of credit card number
- each transaction involves the bank and/or the e-payment organization

Cybercash

Parties:

Consumer PC
Merchant Server
Bank Payment Server
Merchant's Bank
Cardholder's Bank

Protocol

1. Merchant sends invoice to Consumer
   
   
2. Consumer approves purchase, selects credit card reg. with Cybercash
   Payment information encrypted with Cybercash's public key
   Transaction content digitally hashed (message digest) and signed
   
   
3. Merchant strips off order form
   Signs and forward encrypted payment information to CyberCash
   
   
4. Cybercash decrypts payment information with its private key
   Verifies consumer's signature
   Tests message integrity via message digest
   Cybercash forwards transaction amount to merchant's bank
   
   
5. Merchant's bank seeks authorization from customer's bank/credit card issuer
   
   
6. Customer's bank sends approval to merchant's bank.
   Merchant's bank sends information to merchant

Steps 1-4 over the Internet
Steps 5-6 over dedicated private networks

Secure Electronic Transaction (SET)

For credit card transactions
Industry-backed standard
Digital certificates for customer and merchant authentication

Dual Signature on the SET single purchase request

Customer message to merchant (encrypted with merchant's public key)	Customer message to bank (encrypted with bank's public key)
M1: Message digest	M2: Message digest
Dual customer signature M3, where	M3 = Digest (M1 + M2)

Stored-value payment systems

Counter-based:

• e-cash value stored in a counter of a hardware device
• transactions increment/decrement the counter
• hardware device must be tamper-proof
• does not involve the bank

Cryptographic coins:

• instances of specific denominations
• with serial number, digitally signed by the issuing bank
• must prevent multiple spending of the same "coin" (involves the bank)

Example:

DigiCash

Smart Cards

Hardware:

• CPU, RAM, ROM, cryptographic coprocessor

Contents:

• Personal data (SIN, Driver's licence, credit card, employee ID, etc.)
• The owner's private key
• Directory of others' public keys
• Personal digital certificate
• Stored value e-cash

For additional security requires a PIN.

Examples:

Mondex
Visa Cash

References

Overview of Cryptography
Firewall howto
JNDI
The java security model

back to Overview