[SOLVED] CS代考 FIT2093 INTRODUCTION TO CYBER SECURITY

Week 6 Lecture
Security Protocols
FIT2093 INTRODUCTION TO CYBER SECURITY
www.monash.edu

Copyright By PowCoder代写加微信 assignmentchef

Security Protocols
• Handshake
• Record ● IPsec
• AP headers
• ESP headers
● Bluetooth
• Secure Connections
Transport Layer (TCP)
Internet Layer (IP)

Securing the Transport Layer

Security for Communications
Security Protocols
○ 7 layers of communications
○ e.g. OSI model
● can do security at any layer
Transport Layer (TCP)
Internet Layer (IP)
Data Link (Ethernet)

Securing the Comms Channel: Protocols
○ ultimately:
■ wanttohave(virtual)securechannelbetweentwopoints ■ secureintermsof
• CONFidentiality • INTegrity
• AUTHentication

Securing the Comms Channel: Protocols
● howtoestablishsecurechannel?needsharedkeyK ● Q:whyneedsharedkeyK?
○ symmetric key crypto (SKC):
■ fastbutkeydistrproblem ○ public-keycrypto(PKC):
■ nokeydistrprobbutslow
○ usePKCfirstduringsetup,thendoSKCforbulkdata 1st stage 2nd stage

Securing the Comms Channel: Stages
Security Protocols
Tx Rx Tx Rx
Setup Secure Channel
1st stage 2nd stage

# Securing the Transport Layer
Security Protocols
● use SSL/TLS
● between Application layer & Transport layer
○ Applications need to interface to TLS ● SSL (Secure Sockets Layer):
○ by Netscape (de facto browser then)
● TLS (Transport Layer Security)
○ by Internet Engineering Taskforce
○ latest version: 1.3 (IETF RFC 8446, 2018)
transport layer
Internet Layer

# TLS v1.3
Security Protocols
● perfect forward secrecy (PFS) mandatory
● part of openSSL since TLS v1.3 (2018)
● MD5 (broken hash function) removed
● SHA-224 (member of SHA-2 family) removed
vs TLS v1.2 [2008]
● supportforAuthenticatedEncryptionAESmodes
○ GaloisCounterMode(GCM)
○ CounterwithCBC-MAC(CCM)
transport layer
Internet Layer

Perfect Forward Secrecy
Security Protocols
Günther [Eurorypt 1989] Diffie et al. [1992]
The right to retain security: “my security now, should remain secure in future, even if secrets compromised in future”
past now future
“If my security depends on the future, what’s the point of doing security now? ”

Perfect Forward Secrecy (PFS)
Security Protocols
past now future
● Recall: a and b are long-term private keys of Alice and Bob
● if b is compromised in the future, is Know still secure?

Perfect Forward Secrecy (PFS)
Security Protocols
past now future
● long-term private keys: a and b , used in computation of Kpast , Know , Kfuture ● compromiseofsinglelong-termprivatekeycompromisesallkeys
throughout time: Kpast , Know , Kfuture
● allsecuritylost,nooptionforrecoveryofsecurity

Perfect Forward Secrecy (PFS)
Security Protocols
past now future
● ephemeral private keys: apast , anow , afuture and bpast , bnow , bfuture , used in
compromise of at only compromises Kt for that period t so: not all is lost for security, still some remnant security
○ compromiseresilience/tolerance
computation of Kpast , Know , Kfuture
• use ephemeral keys for encryption key exchange, term keys for signing, why doesn’t compromise
• use long term key only for signing ephemeral keys
àcompromised long term key only affects future authentication (MITM attacks)
Q: With ephemeral encryption keys and long of long term key now affect past security?

Perfect Forward Secrecy (PFS)
Security Protocols
past now future
● known since 1989 but industry not worried
● U.S. NSA PRISM:
“ (encrypted) internet communications collected &
stored from internet companies … ”
● 2011: Google
● 2014: Microsoft, Facebook, Yahoo

Securing the Transport Layer: SSL/TLS
Security Protocols
● TWO Sub-protocols
○ for 1st stage
○ TLSHandshakeprotocol
■ use PKC: AUTH server & client
■ negotiate parameters
■ establish shared key K
• based on Diffie-Hellman

Securing the Transport Layer: SSL/TLS
Security Protocols
● TWO Sub-protocols
○ 2nd stage
○ TLS Record protocol
securely transport/encapsulate (like envelope) the data
• CONF: encryption
• INT: msg authentication (MAC)

SSL/TLS: Stages
Security Protocols
Tx Rx Tx Rx
Setup: Secure Channel:
Handshake Record

SSL/TLS: Handshake Protocol Security Protocols

SSL/TLS: Handshake Protocol Security Protocols
● Gist: solve the key distribution problem
1,2: nonces RA , RB for freshness
3: ensure public key integrity (digital certificates) vs key replacement
5: using PKC for key transport
Q: What kind of attacks are prevented using random nonces RA , RB?
Activity (2 mins)
1) Click the latest link in the Zoom chat
2) Add your question response to the Ed forum

#TLS HANDSHAKE: A CLOSER LOOK
Handshake Part 1 – Establishing Security Capabilities
ClientHello
– Supported cipher suites
– Random nonce RA
– Session ID
ServerHello
– Supported cipher suites
– Random nonce RB
– Session ID

#TLS HANDSHAKE: A CLOSER LOOK
Handshake Part 2 – Server Authentication and Key Exchange
The certificate contains server’s public key
ServerCertificate ServerHelloDone

#TLS HANDSHAKE: A CLOSER LOOK
Handshake Part 3 (if client authentication used) – Client Authentication and Key Exchange
ServerHelloDone
Client Certificate (Key exchange)
Client Certificate signed with client private key Change Cipher Spec
ClientFinished

#TLS HANDSHAKE: A CLOSER LOOK
Handshake Part 4 – Key Generation
Client will create pre-master secret and encrypt it by using the public key contained in the server’s certificate
ServerHelloDone
Client Certificate (Key exchange) Client Certificate
Send encrypted pre-master secret

#TLS HANDSHAKE: A CLOSER LOOK
Handshake Part 5 – Finish
Calculate master secret at both ends
Telling server that the cipher suite changes from asymmetric to symmetric now
Calculate master secret at both ends
Send encrypted pre-master secret
Change Cipher Suite ClientFinished Change Cipher Suite
ServerFinished
Start encrypted symmetric communication

Digital Signature in SSL/TLS
Security Protocols
● A certificate provides additional information for a public key:
○ Owner identity (e.g. URL) of the matching private key
○ Validity (expiration date and time)
○ Subject name
○ Issuer name
○ other parameters
○ digital signature by a trusted certification authority (CA)

Trust of Digital Signature in SSL/TLS
Security Protocols
A trusted certificate is digitally signed by a known CA
Browsers (Chrome, Firefox, IE, Safari, etc.) come pre-installed with a list of these CAs and their authentic public keys
Browsers can then verify certificates as coming from these CAs
Note: Do not trust ”self-signed” certificates! Anyone can “self-sign” a fake
certificate

CERTIFICATES ARE
USED IN BROWSERS
VERIFICATIONS OF CERTIFICATES AND DIGITAL SIGNATURES BY USING BOTH ASYMMETRIC AND SYMMETRIC CRYPTOGRAPHY

1. Google server obtains SSL certificate which is digitally signed by 3rd party called CA
2. CA’s public keys will be preinstalled inside the client’s PC
Certificate Authority
3. When you type a URL in the web browser e.g. www.google.com , a request will be sent from your browser to a Google web server for secure pages
www.google.com
** Note that SSL certificate is created by using CA’s private key
5. The green padlock verifies that the certificate indeed belongs to a www.google.com server
and has a valid CA signature by one of the preinstalled CA’s
Web Server www.google.com
www.google.com
4. Google server sends its public key with SSL certificate
Public Key
Private Key

7. However, the client would not want to send the secret key in plain text. Thus, it uses Google server’s public key to encrypt the secret key first.
8. When Google server receives the shared key encrypted by using its public key, it can decrypt it by using its private key.
Web Server www.google.com
Public Key Private Key
Symmetric Key
6. Verification done. Client will generate a secret shared (symmetric) key

Web Server www.google.com
Public Key
Private Key

TLS EXAMPLE: HOW ATTACKS ARE PREVENTED
EXAMPLE 1: MODIFICATION ATTEMPT BY USING REAL CERTIFICATE
But what if attacker imitated themselves as both legit server/receiver and client / sender?
4. The attacker then send the legit certificate to client as if attacker is the server
3. Then the server will send its certificate to attacker
1. When client requested for a webpage from server, the attacker intercept the message from the network and direct it to themselves so that the legit server will not receive the message
Web Server www.google.com
Public Key
ClientHello
2. Then the attacker itself act as the client and send a hello message to the legit server
Private Key
ServerHello FakeClientHello
FakeServerHello

TLS EXAMPLE: HOW ATTACKS ARE PREVENTED
EXAMPLE 1: MODIFICATION ATTEMPT BY USING REAL CERTIFICATE
Sounds like the attacker will succeed, right? However with TLS we are using RSA public key exchange upon symmetric key exchange, thus even the attacker intercepted the information, they have no way to access/decrypt it.
Now assume the public key exchange is done, the client is now going to send server the symmetric key that they are going to use for further connection.
1. Client encrypts the symmetric key generated by using the public key of web server which is available online
2. Attacker will have no idea what is the symmetric key since it does not have the legit server’s private key
ClientHello
And thus the attack failed.
Web Server www.google.com

TLS EXAMPLE: HOW ATTACKS ARE PREVENTED
EXAMPLE 2: MAN-IN-THE-MIDDLE ATTACK WITH FAKE CERTIFICATE
Now consider another scenario, what if attacker imitated themselves as both legit server/receiver and client / sender by using a fake certificate for google.com with attacker’s key?
2. Then the attacker itself act as the client and send the fake certificate to the client
3. Client will look up from the online public database for the public key of the certificate received to verify the certificate
ClientHello
1. When client requested for a webpage from server, the attacker intercept the message from the network and direct it to themselves so that the legit server will not receive the message
4. But obviously in this case, the certificate generated by attacker is not certified by authorised CA, thus the certificate will not be approved by the client
5. The website will then be labelled as not secure and again the attack failed

SSL/TLS: Record Protocol Security Protocols

SSL/TLS: Record Protocol
Security Protocols
○ after handshake, virtual secure channel between browser and server ○ all data will be secured i.e. authenticated encryption
○ authenticated encryption
■ integrityviamessageauthentication ■ confidentialityviaencryption

# SSL Stripping/Downgrade Attack
Security Protocols
1. User types into browser a URL address (eg. www.amazon.com)
2. Browser requests secure connection: https://www.amazon.com
3. MITM attacker intercepts request and answers with downgrade request 4. Browser sends a downgraded HTTP request: http://www.amazon.com
5. Attacker forwards request to real Amazon server as https://www.amazon.com – MITM attacker can see all plaintext in http msgs!
Q: How can servers and browsers defend against SSL Stripping downgrade attacks while still supporting http websites?

# Attacks on SSL/TLS
Security Protocols
● SSL Stripping: Attacker modifies web traffic to trick a client into accepting http (unencrypted) connection instead of https
○ Countermeasure: Server tells browser upon first visit to only accept HTTPS (not HTTP) for future requests to this domain
● BEAST (Browser Exploit Against SSL/TLS)/POODLE (Padding Oracle On Downgraded Legacy
Encryption): Attacker exploits bugs in encryption/MAC mode of operation algorithm/implementation in TLS v1.0 to extract information on secret key
○ Countermeasure: patches to TLS algorithms/implementations
● Compression Ratio Info-leak Made Easy (CRIME): TLS has a compress-then-encrypt mode; compressed data length not hidden by encryption, reveals information to attacker on secret web site cookies
○ Countermeasure: disable TLS compression, avoid if possible record layer compression 37

Securing the Network Layer

Securing your Comms Channel: VPN
Security Protocols
● VPN(VirtualPrivateNetwork) ○ encrypted channel / tunnel
● routespacketsbetweendifferentnetworks ● securechannelviaIPsec
Apps Layer
Transport Layer (TCP)
Internet (Network) Layer (IP)
Data Link (Ethernet)
Q: Why should VPN work between Transport and Network layers (rather than between App and Transport layer)?
Activity (2 mins)
1) Click the latest link in the Zoom chat
2) Add your question response to the Ed forum

IPsec: Stages
Security Protocols
Tx Rx Tx Rx
Secure Channel:
Internet Key Exchange
(IKE) protocol (based on Diffie-Hellman)

IPsec: Methods
Security Protocols
● TwoIPSecMethods:
○ AH(AuthenticationHeader):
■ INT,AUTH,noCONF,anti-replay
○ ESP(EncapsulatingSecurityPayload): ■ INT,AUTH,CONF,
anti-replay
Source: http://jazier.blogspot.com.au/2015/08/ipsec-vpn-theory.html

IPsec: Two Methods (AH / ESP)
Security Protocols
Source: http://jazier.blogspot.com.au/2015/08/ipsec-vpn-theory.html

IPsec: Header
Security Protocols

IPsec: Header
Security Protocols
● extrafieldsforsecuritypurposes ○ securityparametersindex
■ pointtoentrycorrespondingtobrowser/server • incl info on shared key
○ sequencenumber
■ forfreshnessvsreplayattacks
○ MACoutputfield
Source: http://jazier.blogspot.com.au/2015/08/ipsec-vpn-theory.html

IPsec: Modes
Security Protocols
● TransportMode
○ IPpacketinsertedwithIPsecheader
● TunnelMode
○ originalpacketpreservedincloriginalheader,newheader
added/prepended
Source: http://jazier.blogspot.com.au/2015/08/ipsec-vpn-theory.html

Bluetooth:
Securing the
Personal Area Network (PAN)

# Securing the Personal Area Network (PAN)
Security Protocols
● Personal Area Network (PAN) ○ vsLAN/WAN/MAN
● network of personal devices around human’s personal space ○ e.g.mobilephone,earphone,tablet,
○ connectedviaBluetooth,ZigBee,IrDA

Personal Area Network Security: Bluetooth
Security Protocols
Bluetooth is a popular PAN technology
○ AppleAirPods
○ keyboards,mice,trackpads
○ fitnesswatches
○ helmetcameras
○ wearables:JacguardbyGooglewithLevi’s/Adidas https://youtube.com/watch?v=xwuSGTGYdO0 https://www.youtube.com/watch?v=qObSFfdfe7I

Security your PAN
Security Protocols
● much hype about internet of things (IoT), of everything (IoE)
● Q: What if your things got hijacked?
● Bluetooth standard
○ latestversion5.2[2020]
● Bluetooth security
○ LowEnergySecureConnections[v4.2] ○ usesECDH(ellipticcurveDiffie-Hellman) ○ supports4associationmodels

Security your PAN: Bluetooth
Security Protocols
Bluetooth security
○ LESecureConnections[v4.2]
○ supports4associationmodels ■ JustWorks
■ NumericComparison
■ PasskeyEntry
■ OutofBand
to pair two Bluetooth devices securely, i.e. establish a shared key, based on device I/O capabilities,
for subsequent secure data transfer between
paired Bluetooth devices

Security your PAN: Bluetooth
Security Protocols

Bluetooth’s Secure Connections Protocol
Security Protocols
Q: What kind of attack is prevented by passkey-based AUTH pairing?
Activity (2 mins)
1) Click the latest link in the Zoom chat
2) Add your question response to the Ed forum
Gist of Bluetooth’s Secure Connections [v4.2] ○ mainlyPhase2
■ legacy pairing (Secure Simple Pairing), or
■ Secure Connections
○ novelwayofAUTH
■ leverageonhumanchannelduringpairing,e.g.
• compare passkey on both devices
• see passkey on one, type into the other
• type same passkey into both
• which option, depends on device I/O capability
■ assumption
• harder for attacker to attack both the wireless channel and also control
the human owner

Further Reading
Security Protocols
● Chapters 9 & 22 of the textbook: Computer Security: Principles and Practice” by &,, 2015
● Optional:
○ IETF RFC5246: TLS 1.2 Protocol Specification: https://tools.ietf.org/html/rfc5246
○ IETF TLS 1.3 draft specification: https://tools.ietf.org/html/draft-ietf-tls-tls13-28
○ IETF RFC7457: Summarizing Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS): https://tools.ietf.org/html/rfc7457
○ Bluetooth Blog: https://bluetooth.com

程序代写 CS代考加微信: assignmentchef QQ: 1823890830 Email: [email protected]