[SOLVED] CS FIT2093 INTRODUCTION TO CYBER SECURITY

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

Copyright By Assignmentchef 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
Gunther [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, whats 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 doesnt compromise
use long term key only for signing ephemeral keys
acompromised 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 servers 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 servers 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. CAs public keys will be preinstalled inside the clients 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 CAs 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 CAs
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 servers 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 servers 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 attackers 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 humans 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:JacguardbyGooglewithLevis/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

Bluetooths 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 Bluetooths 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]