Transcript Secure Communications Protocols

Secure Communications
Protocols
Dr. Ron Rymon
Efi Arazi School of Computer Science
IDC, Herzliya. 2010/11
Pre-requisite: Basic Cryptography, Identity Authentication
Overview
 IP Layer Security
 Web communications security
 Wireless security
IP Layer Security
IPSec
Main Source: Stallings
Network (IP) Layer
Application
Presentation
Session
Transport
Network (IP)
Data Link
Physical
OSI 7 layers
IP Security
 IPSec is not a single protocol, but rather a framework, and
set of algorithms that provide IP layer security services
– Authentication
– Confidentiality
– Key Management
 Implemented between transport and IP layers
– All packets going out are encrypted
– All packets coming in are authenticated and decrypted
– Can be implemented in routers, and also in client software
 Benefits
– Transparent to applications: good for security-ignorant apps
– Routers can authenticate requests and other routers
Typical Scenarios
IPSec Architecture
 Authentication Header (AH)
– only authentication service
 Encapsulating Security
Payload (ESP)
– Packet Encryption
– Packet Authentication
(optional)
 Domain Of Interpretation
(DOI)
– Specific parameters for
encryption and
authentication algorithms
 Key Management
IPSec Services
ESP with
AH
ESP
authentication
Access Control
√
√
√
Message Integrity
√
√
Data origin authentication
√
√
Reject replayed packets
√
√
√
Confidentiality
√
√
Limited traffic flow
confidentiality
√
√
Security Association (SA)
 One SA for each one-way communication, specifying
– Security Parameters Index (SPI) identifies the SA in the SA DB
– IP Destination
– Security Protocol Identifiers (which of AH or ESP shall be used)
 Security Policy Database (SPD) specifies SA selectors
– Maps outbound packets to specific SAs, e.g. app-specific fields
 SA Database stores all SA entries
–
–
–
–
–
AH info: authentication algorithm, keys, key lifetime,…
ESP info: encryption and authentication algorithms, keys, IVs,…
Running sequence number, used to prevent packet replays
SA lifetime
IPSec protocol mode: Tunnel, Transport
Authentication Header (AH)
 Authentication of data and source
– Prevent modifications of payload while in transit
– Prevent IP spoofing
– AH contains Integrity Check Value (ICV)
• Calculated HMAC over payload and all transit-immutable
values, concatenated with shared key (possibly truncated to fit)
• IPSec requires support of at least SHA-1 and MD5
 Countering replay attacks
– Goal: prevent capture and replay of packets
– For every SA, source generates up to 232 sequence
numbers, then starts a new SA with a new seed
– Receiver authenticates using a sliding window (w=64)
AH Packet Format
Which SA?
Anti-Replay
Integrity
Check Value
(ICV)
Encapsulating Security Payload
(ESP)
 Adds (symmetric) encryption of the payload
– Encryption Algorithms: DES (must), and also 3DES, RC5, IDEA,
3IDEA, CAST, Blowfish. In 2003, added AES
– CBC mode
– Plaintext payload is replaced with ciphertext by source and is
routed as new payload
 Optionally provides authentication
– HMAC with SHA-1 or MD5 (96 bits only)
 Anti-replay sequence number

Note: ESP supports authentication because SA cannot use both ESP and AH
ESP Packet Format
Which SA?
Anti-Replay
Integrity
Check Value
(ICV)
Transport and Tunnel Modes
 Transport Mode
– Protects upper layers
– IP Payload is encrypted / authenticated
 Tunnel Mode
– Protects all layers
– New packet created at network boundary, with original packet as
its payload, and the entire inner packet is encrypted / authenticated
– Can be applied to both AH and ESP
router
San Francisco
router
internet
New York
Tunneling Example (AH)
 Before AH
 AH Transport Mode
 AH Tunnel Mode
SA Bundles and Tunneling
 SA bundles allow a sequence of
SAs to be applied to same packet,
or within a tunnel
– Transport adjacency
• Transport ESP SA (w/o authentication)
followed by Transport AH SA
(covering also ESP fields)
– Iterated Tunneling
Key Management
 IPSec assumes availability of symmetric keys
 Option 1: Manual configuration
– Primarily for link communication
 Option 2: Internet Key Exchange (IKE) automated on-
demand creation of keys
– ISAKMP – default SA and key management protocol
• Does not mandate a specific key exchange protocol
• Implements at least Oakley, but can also use RSA for instance
– Oakley – default key determination protocol, based on a hardened
Diffie-Hellman protocol
Oakley
 A refinement of Diffie-Hellman
 DH weaknesses
– Clogging attack: attacker forces Alice to exponentiate endlessly
– Man-in-the-middle attack: attacker impersonates Alice to Bob and
impersonates Bob to Alice
 Oakley hardening (IKEv2)
– Precedes the DH phase with exchange of a pseudorandom number
(“cookie”) which is specific to each party (based on IPs of parties)
– This number is first acknowledged as belonging to other party, and only
then DH is performed. Hence attacker can only clog with acknowledge
requests
– Authenticates DH exchange to prevent impersonation
– Use nonces against replay attacks
 Options:
– Choice of “groups” (modulo) for DH exchange
– Choice of authentication method: digital signature, or encryption
Hardened Oakley
ISAKMP
 Protocol to establish, negotiate, modify, and delete SAs
 ISAKMP messages:
–
–
–
–
–
–
–
–
–
–
–
–
Security Association – establish new SA (initial parameters)
Proposal – indicates the protocol to be used (ESP or AH)
Transform – the algorithms to be used, e.g., 3DES, HMAC-SHA-1
Key Exchange – which key exchange protocol, e.g., Oakley, RSA
Identification – the identity of the peers, e.g., IP address, User ID
Certificate – certificates of the peers
Certificate Request
Hash – data generated by the hash function
Signature – data generated by digital signature function
Nonce – the current nonce
Notification - messages
Delete – revoke an SA
IPSEC and IKE in OSI Model
Virtual Private Networks (VPN)
VPN Implementations
 IPSec tunneling or transport encryption
 Simple encryption for systems that are not IPSec enabled
– Symmetric encryption using a physically-delivered shared key
– Public-key encryption, e.g., using RSA or PGP
– SSL implementations
 Most implementations include
– Authentication, Authorization, and Accounting (3A) servers
– Firewalls/ QoS servers
 Actual implementation
–
–
–
–
Desktop client for remote users
VPN concentrator (hardware)
Part of firewalls/routers
Win2K on top of Active Directory
VPN Concentrator
Other Implementations
 MultiProtocol Label Switching (MPLS)
– Label packets so that they go through a preferred routing (Label
Switched Paths – LSP). Labels are added to packet.
– Implemented between data layer and IP layer
– Sometimes viewed as IP implementation of ATM-like network
– Serves primarily for QoS reasons, but also reduces security risks
 MPLS VPN
Anonymized Networks
 Use VPN idea to anonymize sender/receiver
 Client downloads network map, and selects path
 “Onion” routers know only prior/subsequent nodes
– Prevents traffic analysis
– Offered by EFF to dissidents and journalist tippers
Web Access Security
Secure Socket Layer (SSL)
Transport Layer Security (TLS)
Main Source: Stallings
Web Security Considerations
 In principle, Web access is simply client-server
– Protocols such as Kerberos apply…
 Unrealistic to require every web application to implement own security
– Suggesting use of IPSec…
 But IPSec requires deployment on both ends (client included)
 Special characteristics of Web servers
– “out there” accessible to anyone
– connected to corporate databases - dangerous if subverted
– applicative software developed quickly and often security-ignorant
 Special characteristics of Web users
– often not security knowledgeable
– often not subject to corporate or other rules
– cannot be counted on to fulfill their part in a security protocol
Web Security Threats -the usual…
 Integrity
– Modification of data on servers (“data-at-rest”)
– Modification of messages (“data-in-motion”)
 Confidentiality
–
–
–
–
Theft of data from server, or from client
Eavesdropping on communication
Info on network configuration
Info on network traffic
 Interruption
– Denial of Service
 Authentication
– Impersonation of legitimate users
– Data forgery on server (or client)
Web Applications Vulnerabilities
 Explosion in the use of web applications
– Custom applications
– Wikis, portals, bulleting boards
 Web apps vulnerabilities account for half of all
SANS vulnerabilities
–
–
–
–
Malware
Buffer overflows
SQL Injections
Cross-site scripts
Alternative Security Facilities for
Web Communications
 Network layer, e.g., IPSec
 Application layer, e.g.
– SET on top of HTTP
– PGP and S/MIME on top of SMTP
 SSL/TLS protocols
– As a protocol above TCP in transport
and session layers
– As part of application software: browser
on client side and web server (SSL was
developed by Netscape)
Secure Socket Layer (SSL)
 Developed by Netscape as part of their browser
– SSLv3 was subjected to public review
– Transport Layer Security (TLS) designed as successor to SSLv3
 SSL is a session-based protocol, and each session may
consist of multiple connections
 SSL consists of two layers
– SSL Record Protocol provides
basic security services, e.g. https
– Handshake protocol is used to
initiate sessions
– Alert protocol for peer messaging
 SSL session states:
– Security algorithms
– Compression methods
– Master keys
– Certificates
SSL Record Protocol
 Services: Confidentiality, Message Integrity
 Several encryption
algorithms are
permitted
 HMAC standard
 Header:
– Content type: SSL-specific, or application
(e.g. HTTP)
– SSL version
Handshake Protocol: Initial Negotiation
 Client suggests; Server




chooses
SSL version: lower version
will be used
Nonce: timestamp+random
Session ID: existing or new
Alternative CipherSpec suites,
in decreasing preference
–
–
–
–
–
Key exchange
Encryption algorithms
MAC algorithm
Parameters
AES added in 2008
 Compression methods
supported
Hello +
Cipher
Spec
Handshake Protocol: Authentication and
Key Exchange
 Server starts; client follows
 Server sends certificate
 Server sends key exchange
message
 Server may ask for client
certificate
 Client responds
Authentication
and
Key
Exchange
 State changed to pending
cipher_spec
 Handshake done
Finish
Finish
Cert and Key Exch Hello and Cipher Select
Example
Cookies
 Text files on client side (username@sitename)
– Web Server is allowed to store key/value pairs
– The browser resends cookie to Web Server
– Can be encrypted or not
– Used to implement state, e.g. Login credentials,
browsing history, allowed capabilities
 Simple implementation
– Capability, Expiration, HMAC(Cap+Exp)
Wireless LANs Security
802.11b/g/n
Main Sources: IEEE standards, SANS, and Berkeley Group
Wireless Networks
 Originally devised for mobile, and/or location-based services,
 HomeRF – 1.2Mbps (later increased to 10Mbps)
 Bluetooth – short range (10m), Personal Area Network, low voltage
 802.11 – IEEE Standard for wireless LANs
– Frequency hopping, using 2.4GHz unlicensed ISM frequency
 802.11b (WiFi) – Direct Sequencing Spread Spectrum (DSSS), and
increases bit rates to 11Mbps
– Achieves market sweet spot, in terms of cost, acceptance, interoperability
 802.11a – 5GHz frequency, 54Mbps, addresses some security concerns
 802.11g – provides 54Mbps at 2.4GHz and compatible with 802.11b
 802.11n – substantial increase in speed/range (MIMO technology)
 202.11i – security standard for wireless networks
Wired Equivalent Privacy (WEP)
 Wireless communication is point-to-multipoint
– Adversary can simply intercept packets, without having to intrude
or impersonate
 WEP security services:
– Confidentiality
– Integrity of messages
– No key management, and no robust authentication
 WEP mechanisms
– Challenge response (encryption ) to authenticate
– RC4 used to encrypt packets, based on a 40-bit key shared between
mobile unit and access point, concatenated with 24 bit IV (link
encryption)
– Integrity Check Vector (ICV) is appended to the packets, to ensure
that they were not modified
WEP Weaknesses (Summary)
 Same hand-configured 40-bit key is shared by all mobile
devices that connect to same access point
 Lack of key management services results in infrequent
change of above keys
 Attacks take advantage of small IV size
 Until 2003, WEP was only security standard in 802.11b
 And (if this is not enough)…most devices are shipped with
WEP turned OFF
RC4 (reminder)




Stream-cipher developed by RSA
Keystream is generated based on initial key
Keystream is XORed with the plaintext
RC4 with 40 bits is exportable…
Keystream
Generator
Ki
Pi
Ci
 Original Wi-Fi implementations have 64-bit RC4 key,
which is comprised of 40-bit WEP key + 24-bit IV
Passive Attacks on WEP’s Shortcomings
 A.k.a. “drive-by hacking” or “parking lot attacks”
 First, note that if two ciphertexts are encrypted with same
keystream, they can be XORed
– (A  K)  (B  K) = A  B
 Second, note that the keystream depends on key + IV
 The key is constant per access point, its just the IV
– Some implementations start at 0 and add 1 for each message; some
use randomized numbers
– IVs are quickly repeated
• At 11Mbps (old rate), IVs definitely repeated in 5 hours
• Birthday paradox: 50% chance for repeat after only 5000 packets;
99% for repeat in 10 minutes
 Once plaintext is recovered, can recover keystream
– (A  K)  A
– Following keystreams can also be computed
More Attacks on WEP’s Shortcomings
 WEP’s authentication is based on challenge-response
– The expected response is the encryption of the challenge
– But, since the challenge is sent in the clear, with both plaintext and
ciphertext, one can infer the keystream and fake her own response
 WEP’s ICV is based on Cyclical Redundancy Check
(CRC)
– When modifying content, it is easy to predict the bits that need to
be flipped in the CRC
– Eve can change destination IP address, and have the AP decrypt
the packet for her
 Table-based attack: Eve can construct a table of all
possible keystreams (224 x 1500 bytes = 24GB)
Improving 802.11b WEP Security
 First, don’t forget to turn WEP on
– 50% of sites don’t use any encryption
– Turn off SSID broadcast
– Do not boost signal
 Administrators should use end-to-end encryption
– Place access points outside the firewall and use VPN
– Use authentication protocols, e.g. RADIUS, to authenticate clients
 Most vendors have extended RC4 key size to 128 bits
– 104 bits (13 bytes) + IV of 24 bits (and some double that)
 WEP2
– WEP2 adds to IV space, and uses different and changing keys for
different stations
Wi-Fi Protected Access (WPA)
 New standard (part of 802.11i), approved 6/2004
 In Enterprise mode
– Key management services
– Central RADIUS authentication server (otherwise Pre-Shared Key)
 RC4 enhanced with
–
–
–
–
48-bit IV and smart IV sequencing algorithms
New Message Integrity Code (MIC)
Key based on initial exchange of random numbers
Ongoing generation of per-packet keys
 WPA2
– Replaces RC4 with AES
– CCMP = Counter-Mode Encryption + Cipher Block Chaining +
Message Authentication Code
– Requires new hardware
– Michael algorithm shuts off network for 1 min when detecting an
unauthorized message
Wireless Communication is
Fundamentally Weak
 The 802.11 protocol is fundamentally weak.
 “Using a wireless network for mission-
critical data is plain stupid. Using it for lifecritical data is criminally negligent”
Niels Ferguson, developer of the Michael algorithm.
Cellular Phone Security
Voice Security
WAP PKI
Malware
Main Sources: WAP Forum, Certicom
Cellular Communication Security
 Analog phones: easy-to-scan clear channel
– ESNs easily harvested and cloned
 Digital: call scrambling (FHMA, TDMA)
– Can encrypt, but rarely used (or use default keys)
 GSM was designed with cryptography
– SIM stores Identity and Key (encryption/authentication)
– Challenge-response (A3) and key generation (A8) algs
• Academic success breaking A3/A8 w/ chosen plaintext attack
– Encryption alg (A5)
• Also broken w/ access to SIM or over-the-air queries to phone
• Some countries use A5/2 algorithm that is further weakened
– Some attacks on base station
WAP
 Main risks
– Today: Eavesdropping, Impersonation, Interruption
– Soon: Malware, Intrusion…
 Needed security services
– Confidentiality, Authentication, Non-repudiation (m-commerce)
– Must work in computationally-challenged environment
WAP Security Mechanisms
Wireless Application Environment (WAE)
Wireless Session Protocol (WSP)
Wireless Transaction Procol (WTP)
Wireless Transport Layer Security (WTLS)
Wireless Datagram Protocol (WDP)
Wireless Data Network (e.g., GSM)
HTTP
TCP
SSL/TLS
UDP
WAP Security Standards
 WAP Identity Module (WIM)
– Tamper resistant chip on the handheld that stores key material, typically
implemented as a smart card
 WML Script Crypto API (WMLSCrypt)
– Library of security functions for WAP applications, e.g., key generation
and management, encryption, digital signature
– Elliptic Curve Cryptography (ECC) requires less key material and less
computation than traditional public-key encryption algorithms
 Wireless Transport Layer Security (WTLS)
– Based on SSL/TLS, optimized for wireless applications
– Provides authentication, encapsulation/encryption, integrity check
 WAP Public Key Infrastructure (WPKI)
– Optimized PKI management of keys and certificates
– Reduced size certificates
 WAP since replaced by GPRS, EDGE, UMTS
 Next generation: LTE, WiMax
Cellphone Malware
 Cellphones become most important computing platform
– Many more day-to-day tasks beyond telephone calls
– Hold identity and other valuable information
– P2P and soon NFC for store payment (late 2010)
 Use regular communication and computing paradigms
– Similar networking (WiFi, WiMax/LTE)
– Similar OSs (Windows, Symbian, iPhone)
– Similar apps
 Increasingly targeted
–
–
–
–
First worms (Cabir, Lasco) use bluetooth to infect neighbors (2004)
150 cellphone viruses detected (2/2006)
Web browsing opens many infection opportunities
IKEE.B virus attacks jailbroken iPhones (11/2009)
 Will likely use same security solutions