Professor Sanjay K. Jha
Securing Fixed and Wireless Networks Application and Transport Layer Security
School of Computer Science and Engineering, UNSW
Copyright By PowCoder代写 加微信 powcoder
Security at Internet Protocol Layers
• Security can be implemented at various layers
• Application Layer Security
– A quick glimpse at secure email (PGP)
• Secure Socket Layer (SSL) / Transport Layer Security (TLS)
– this week
• Network Layer Security
– IPSec next week
• Link Layer Security
– WLAN covered earlier, more on Enterprise later 2
Why Security at Application Layer?
• Application may want control of aspects of security
– E.g. End user authentication who purchases a product
• E-commerce sites can’t rely on security provided by various networks in between
– noendtoendintheInternet
• Application layer can decide new type/level of security without relying on lower layer changes
Application Layer Security -1
• Assume Alice and Bob want to use email
A. They decide to use a symmetric key encryption algorithm such as AES with a 256 bit key. Alice encrypts the message and sends it to Bob who can decrypt using the same shared key.
• What have they achieved?
o Message can only be decrypted by Alice and Bob achieving
confidentiality
o No message integrity and origin authentication. Additional measures required for integrity and origin authentication
o Requires secure key distribution
Network Security 11
m KS(.) KS(m )
KS(.) m KS
Alice – V1
Pre-negotiated symmetric key, KS
encrypts message with KS (for efficiency) sends KS(m) a
Application Layer Security-2
§ Assume Alice and Bob want to use email
B. Suppose Alice and Bob do not care about confidentiality but want assurance that messages will not be tampered with in transit. Alice calculates the message hash using SHA-3 algorithm and sends it to Bob. Bob can recalculate the hash and verify it matches
• What have they achieved?
o No confidentiality and origin authentication
o What about message integrity? An attacker can easily replace the genuine message with a forged one and a matching hash. Bob cannot detect the message alteration
o Additional measures still required for achieving message integrity Network Security 12
Alice – V2
v Alice wants to provide sender authentication message integrity SHA-3
H(.) H(m ) SHA-3
v Alice digitally signs message
v sends both message (in the clear)
Application Layer Security – 3
• Assume Alice and Bob want to use email
C. Alice calculates the message hash using SHA-3 algorithm and additionally uses a pre-negotiated symmetric key to encrypt the hash. Bob now decrypts this hash using the pre-negotiated symmetric key.
• What have they achieved?
o No confidentiality as message still sent in plain text
o What about message integrity? Bob can verify the integrity of the received message
o This also authenticates that the message was sent by someone who shares a key with Bob, in this instance Alice
o Does not provide non-repudiation
Network Security 13
Alice – V3
KS( ) H(.)
Application Layer Security – 4
D. Alice uses public key cryptography and calculates the message hash using SHA-3 algorithm and uses her private key to encrypt the hash (forming digital signature). Bob now decrypts this hash using the Alice’s public key
• What have they achieved?
o No confidentiality as message still sent in plain text
o This allows for an integrity check and authentication at the same time, as no one other than Alice knows her private key.
o Also achieves non-repudiation as well
o We avoided pre-negotiation or sharing of keys
• How does Bob get Alice’s public key and trust that Eve or Mallory are not using a forged public/private key to perform MiTM?
Network Security 14
Alice – V4
v Alice wants to provide sender authentication message integrity
m H( ) K-( ) KA(H(m)) KA(H(m))
+ Internet v Alice digitally signs message
H(m ) – compare
v sends both message (in the clear) and digital signature
Pretty Good Privacy (PGP)
• in 1991, prosecuted for violating US export laws, charges dropped in 1996
– Company PGP Inc formed, acquired by Network Associates … Symantec
• Used worldwide serves more than 1M pages per day to 166 countries
• PGP software (https://philzimmermann.com/EN/findpgp/) or
https://www.openpgp.org/
– Createspublic/privatekeyforuser(RSA)
– Privatekeypasswordprotected
– Digitallysignmessage:MD5orSHA
– Optionally encrypt as well: CAST, 3-DES, IDEA …
• PGP key certified by Web of Trust (more later)
PGP Alice-Bob
. – KA(H(m))
m H() KA()
Homework: Work out Bob side
Web of Trust
• The web of trust is an alternative to PKI where users can create a community of trusted parties by mutually signing certificates without needing a registrar
• Alice and Bob can sign each other’s certificates certifying their public keys. Other entities if they trust Alice, can use Bob’s certificate duly certified by Alice
• Similar to certificate Chain in PKI.
• Pretty Good Privacy (PGP) was one of the earliest email systems to propose the security approach using the web of trust for certificates
Network Security 16
Application Layer Security
• Various original application layer protocols lacked security features
Protocol Name
Functionality
Security Attacks
Simple Mail Transfer Protocol (SMTP) & Multipurpose Internet Mail Extensions (MIME)
Exchanging messages between mail servers, MIME for content formatting in SMTP
DoS, Impersonation
Domain Name System (DNS)
Translation between a host name and the corresponding IP address
MiTM, DNS cache poisoning, DNS exfiltration
Hyper Text Transfer Protocol (HTTP)
Interaction between web servers and web clients
Various forms of DoS
Network Time Protocol (NTP)
Synchronize devices to Coordinated Universal Time (UTC)
Replay, MiTM, Spoofing, DoS
Application Layer Security
Protocol Name
Security extension
SMTPS (RFC 3207 / 7817)
Uses security services from transport layer
S/MIME (RFC 5751)
Integrity check and certificates validation automatically performed by the respective mail agents
DNSSEC (RFC 4033-35)
Provides authenticity and data integrity by using public key cryptography
HTTPS (RFC 2818)
Uses security services from transport layer
Ntpd compliance with RFC 7384
Authentication, authorisation using cryptographic keys
Network Security 19
DNS Attacks
• Domain Name Service: translation between a host name and the corresponding IP address, maintained by a hierarchy of name servers.
• DoS Attack: A number of Denial of Service (DOS) attacks in recent years
• MiTM: attacker can impersonate a DNS server
– returnabogusaddress,diverttraffictoamaliciousserver,allowsinto collect user passwords or other credentials.
• Cache poisoning attack aka DNS spoofing:
– attackerstoplantbogusaddresses,thusdivertingauserrequestto malicious servers.
DNS Security
• IETF DNS Security Extensions (DNSSEC)
• Approach similar to PGP
– response signed by the private key of a DNS server.
– a requester can verify using the corresponding public key.
– a digital signature also provides the integrity of the response data, Confidentiality not an issue for DNS records
• Recent study : only 1% of domains use the DNSSEC
• Very few registrars support DNSSEC .
• Mechanism for communicating DNSSEC information has several security vulnerabilities.
• DDoS defence in not part of DNSSEC
– Intrusion Detection/Prevention System for DOS (later week)
Transport Layer Security
§ Security services at the transport layer could relieve each application from the burden of taking care of security itself
• This would also provide compatibility across platforms/vendors
§ Provide a shim layer between the application and the transport layers
in the form of Secure Socket Layer (SSL)
• API provided by SSL enable applications to bootstrap secure connections and send/receive data securely
§ IETF developed Transport Layer Security (TLS) taking ideas from SSL 3.0 protocol
• Current version is TLS 1.3 (standardised in 2018)
§ We will learn main ideas behind SSL/TLS – details in RFCs – also more in Lab
Network Security 20
Transport Layer Security
• Various attacks on Transport layer
Functionality
Counter measure
TCP SYN Flooding
Client sends SYN, Server replies with SYN/ACK, Client never replies back
TCP SYN Cookies [RFC 4987]
Connection Replay
Eve capture communication and repeat the sequence later on
TLS (and PMS generation algorithm) uses session specific nonce
Various attacks on SSL/TLS itself
SSL stripping, BEAST, Lucky thirteen attacks [RFC 7457]
[RFC 7366] Encrypt before MAC, Counter measures in latest version of TLS 1.3 [RFC 8446]
Network Security 25
SSL: Secure Sockets Layer
SSL in TCP/IP protocol stack
SSL and TCP/IP
Application
Application
normal application application with SSL
v SSL provides application programming interface (API) to applications
v C and Java SSL libraries/classes readily available
Toy SSL: a simple secure channel
• handshake:AliceandBobusetheircertificates, private keys to authenticate each other and exchange shared secret
• keyderivation:AliceandBobusesharedsecretto derive set of keys
• data transfer: data to be transferred is broken up into series of records
• connection closure: special messages to securely close connection
Toy: a simple handshake
MS: master secret
EMS: encrypted master secret
public key certificate
KB+(MS) = EMS
Toy: key derivation
• considered bad to use same key for more than one cryptographic operation
– use different keys for message authentication code (MAC) and encryption
• four keys:
– Kc = encryption key for data sent from client to server
– Mc = MAC key for data sent from client to server
– Ks = encryption key for data sent from server to client
– Ms = MAC key for data sent from server to client
• keys derived from key derivation function (KDF)
– takes master secret and (possibly) some additional random data and creates the keys
Toy: data records
• why not encrypt data in constant stream as we write it to TCP?
– where would we put the MAC? If at end of TCP connection, no message integrity until all data processed.
– e.g., with instant messaging, how can we do integrity check over all bytes sent before displaying?
• instead, break stream in series of records – each record carries a MAC
– receiver can act on each record as it arrives
• issue: in record, receiver needs to distinguish MAC from data
– want to use variable-length records
Toy: sequence numbers
• problem:attackercancaptureandreplayrecord or re-order records
• solution:putsequencenumberintoMAC: • MAC = MAC(Mx, sequence||data)
• note: no sequence number field
• problem:attackercouldreplayallrecordsin future
• solution:usenonce SSL/TLS
Toy: control information
• problem:truncationattack:
– attacker forges TCP connection close segment
– one or both sides thinks there is less data than there actually is.
• solution:recordtypes,withonetypeforclosure – type 0 for data; type 1 for closure
• MAC = MAC(Mx, sequence||type||data)
SSL Architecture
Real SSL: handshake (1)
1. server authentication
2. negotiation: agree on crypto algorithms
3. establish keys
4. client authentication (optional)
Real SSL: handshake (2)
1. client sends list of algorithms it supports, along with client nonce
2. server chooses algorithms from list; sends back: choice + certificate + server nonce
3. client verifies certificate, extracts server’s public key, generates pre_master_secret, encrypts with server’s public key, sends to server
4. client and server independently compute encryption and MAC keys from pre_master_secret and nonces
5. client sends a MAC of all the handshake messages
6. server sends a MAC of all the handshake messages
Real SSL: handshaking (3)
Why last two messages with MAC exchanged?
• clienttypicallyoffersrangeofalgorithms,some strong, some weak
• man-in-themiddlecoulddeletestrongeralgorithms from list
• last2stepspreventthis
– last two messages are encrypted
Real SSL: handshaking (4)
Why two random nonces?
• suppose Trudy sniffs all messages between Alice & Bob
• next day, Trudy sets up TCP connection with Bob, sends
exact same sequence of records
– Bob (Amazon) thinks Alice made two separate orders for the same thing
– solution: Bob sends different random nonce for each connection. This causes encryption keys to be different on the two days
– Trudy’s messages will fail Bob’s integrity check 34
Encrypted Traffic
Bob (Sender)
Start of TLS Handshake
Alice (Receiver)
TLS Protocol Exchange
TCP 3-way Handshake
Application Data
Figure No 2
Client Hello
Server Hello, Certificate Server Hello Done
ChangeCipherSpec Finished
ClientKeyExchange, ChangeCipherSpec Finished
TLS Protocol Handshake
§ After TCP connection establishment
• Bob sends a ClientHello message to Alice containing available
ciphers, hash functions and a large random number (nonce)
• Alice responds with a ServerHello message along with her choice of ciphers and hashes (e.g., AES for confidentiality, RSA for public key, SHA3 for Message Authentication Code (MAC), Deffie Hellman for key exchange), her public key certificate and a nonce.
• Bob checks validity of Alice’s certificate and initiates ClientKeyExchange message
• Bob sends a ChangeCipherSpec and a finished message to indicate that key generation and authentication are complete
• Alice also has the shared key now and responds with ChangeCipherSpec and finished message
• Bob decrypts message with symmetric key and checks integrity Network Security 22
TLS Protocol Key Derivation
§ A pseudorandom function produces a Master Secret (MS) using client nonce, server nonce and Pre-Master Secret (PMS)
§ Following four keys are derived using MS and additional parameters
• Client encryption key: Session key for data sent from Bob to Alice
• Server encryption key: Session key for data sent from Alice to Bob
• Client MAC key: session MAC key for data sent from Bob to Alice
• Server MAC key: Session MAC key for data sent from Alice to Bob
§ Separate ephemeral keys for encryption and Integrity in each direction provides perfect forward secrecy (avoids replay attacks)
Network Security 23
SSL/TLS record protocol
data fragment
record header
encrypted data and MAC
data fragment
record header
encrypted data and MAC
record header: content type; version; length MAC: includes sequence number, MAC key Mx
fragment: each SSL fragment 214 bytes (~16 Kbytes) 38
TLS Protocol Data Transfer
TLS defines a record format to keep track of the data being
0-byte 1 2 3 4
Content Type
Padding (block ciphers only)
o Data plus MAC are encrypted using the session encryption key and it is then passed on to TCP
Network Security 24
§ QUIC is a new transport protocol designed by Google for faster web-browsing using UDP instead of HTTP over TCP
• The protocol currently uses proprietary encryption and authentication
§ Although QUIC uses the standard HTTP ports, security devices such as Firewalls and IDS do not track this application layer protocol at present
§ Since the standardisation work is already in progress, it is likely to use TLS1.3 for secure transport
Network Security 26
SSL vs TLS
• The same record format as the SSL record format.
• TLSv1.3 defined in RFC 8446.
• Similar to SSLv3.
• Differences in the:
– versionnumber
– messageauthenticationcode
– pseudorandomfunction
– alertcodes
– ciphersuites
– clientcertificatetypes
– certificate_verifyandfinishedmessage – cryptographiccomputations
Acknowledgements
• Computer Networking A top-Down Approach: and , Chapter 8, (foils provided by Authors)
– Reference section 8.5
• Network Security Essentials: Stallings, 6, Foils provided by , Blekinge Institute of Technology, Sweden
– Reference Section 6.2 for SSL
– Optional read Section 6.3 for TLS
• See Cybok NETWORK SECURITYKNOWLEDGE AREA for references and research papers.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com