This document provides an overview of analyzing the SSL/TLS protocol using formal methods. It begins with background on SSL/TLS, including its history, uses, and basic design. It then outlines the steps that would be taken to formally analyze SSL/TLS, including creating an abstract model of the protocol in the Murphi verification tool. The document walks through modeling key aspects of the SSL/TLS handshake protocol at an abstract level, such as generating nonces and establishing a shared secret. The goal is to demonstrate the process that would be followed if SSL/TLS were being formally analyzed as a student project.
- The final exam for the cryptography course will take place on June 9 from 9:30-11:18 AM. It will cover materials after RSA but students still need to know RSA. The exam allows open books and notes and calculators.
- The course covered symmetric encryption algorithms like AES and DES, public key encryption like RSA, hash functions like SHA-1, message authentication codes, digital signatures, entity authentication, and key agreement protocols.
- SSL (now called TLS) provides a secure and reliable connection over TCP. It uses the SSL/TLS handshake protocol to authenticate parties and establish encryption keys to protect data sent over the TCP connection.
- The document discusses SSL (Secure Sockets Layer), which is a standard security technology for establishing an encrypted link between a web server and browser. It provides key details on SSL including its architecture, protocols (SSL Record and Handshake), certificates, encryption, and history/development. SSL uses public/private keys to encrypt data during transmission and provides authentication and security for web applications.
SSL and TLS provide end-to-end security for applications using TCP. They operate at the transport layer and provide services like data encryption, message integrity, and client/server authentication. The key components are the handshake protocol for negotiating encryption parameters and exchanging keys, the record protocol for fragmenting and encrypting application data, and alert and change cipher spec protocols for signaling errors and key changes. Common algorithms include RSA and Diffie-Hellman for key exchange, RC4, 3DES and AES for encryption, and MD5 or SHA for hashing. Sessions define a connection's cryptographic settings while connections are the actual data streams.
Introduction to the design principles behind SSL. This was a relatively basic talk since the audience was a networking class with no previous security experience. Talk given to Cal Poly networking class on November 29, 2007.
Nate Lawson presents an overview of the TLS/SSL protocol design. He discusses the security goals of privacy, integrity, and authentication. He explains how these goals are achieved using cryptography primitives like symmetric encryption, public key encryption, certificates, message authentication codes, and secure PRNGs. He walks through the TLS handshake protocol in detail and discusses various attacks against SSL/TLS like side channel attacks, similarly-named certificate attacks, and data injection via renegotiation attacks.
TLS/SSL - Study of Secured CommunicationsNitin Ramesh
TLS/SSL - The mechanism enabling to have secured communications between 2 points over network is more important than ever. Here we deep dive into the basics and its relevance in today's world.
- The final exam for the cryptography course will take place on June 9 from 9:30-11:18 AM. It will cover materials after RSA but students still need to know RSA. The exam allows open books and notes and calculators.
- The course covered symmetric encryption algorithms like AES and DES, public key encryption like RSA, hash functions like SHA-1, message authentication codes, digital signatures, entity authentication, and key agreement protocols.
- SSL (now called TLS) provides a secure and reliable connection over TCP. It uses the SSL/TLS handshake protocol to authenticate parties and establish encryption keys to protect data sent over the TCP connection.
- The document discusses SSL (Secure Sockets Layer), which is a standard security technology for establishing an encrypted link between a web server and browser. It provides key details on SSL including its architecture, protocols (SSL Record and Handshake), certificates, encryption, and history/development. SSL uses public/private keys to encrypt data during transmission and provides authentication and security for web applications.
SSL and TLS provide end-to-end security for applications using TCP. They operate at the transport layer and provide services like data encryption, message integrity, and client/server authentication. The key components are the handshake protocol for negotiating encryption parameters and exchanging keys, the record protocol for fragmenting and encrypting application data, and alert and change cipher spec protocols for signaling errors and key changes. Common algorithms include RSA and Diffie-Hellman for key exchange, RC4, 3DES and AES for encryption, and MD5 or SHA for hashing. Sessions define a connection's cryptographic settings while connections are the actual data streams.
Introduction to the design principles behind SSL. This was a relatively basic talk since the audience was a networking class with no previous security experience. Talk given to Cal Poly networking class on November 29, 2007.
Nate Lawson presents an overview of the TLS/SSL protocol design. He discusses the security goals of privacy, integrity, and authentication. He explains how these goals are achieved using cryptography primitives like symmetric encryption, public key encryption, certificates, message authentication codes, and secure PRNGs. He walks through the TLS handshake protocol in detail and discusses various attacks against SSL/TLS like side channel attacks, similarly-named certificate attacks, and data injection via renegotiation attacks.
TLS/SSL - Study of Secured CommunicationsNitin Ramesh
TLS/SSL - The mechanism enabling to have secured communications between 2 points over network is more important than ever. Here we deep dive into the basics and its relevance in today's world.
Sync IT is a decentralized file transfer solution that uses peer-to-peer networking and encryption to securely transfer files between clients. It leverages industry standard cryptographic techniques like AES-128 encryption and utilizes a custom transport protocol to optimize transfers over local and wide area networks. The system can be deployed entirely within a private infrastructure and includes a browser-based management interface to schedule and monitor transfers between client nodes.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate servers securely. It was first developed by Netscape in 1994 to provide server authentication, encryption of messages, and message integrity. SSL establishes an encrypted connection between a client and server through a handshake process that verifies servers, negotiates encryption, and generates symmetric keys to encrypt subsequent communication. It has become the standard security technology for web servers and browsers to protect online transactions and sensitive data transmission over the internet.
The document provides an overview of the Secure Sockets Layer (SSL) protocol. It discusses SSL's goals of providing confidentiality, integrity, and authentication for network communications. It describes the SSL handshake process, where the client and server authenticate each other and negotiate encryption parameters before transmitting application data. It also discusses SSL applications like securing web traffic and online payments. The document concludes that SSL is vital for web security and ensures user confidentiality and integrity.
SSL provides authentication and confidentiality for web communications. It operates at the transport layer, encrypting data between the application and transport layers. The SSL handshake protocol establishes a secure connection in 4 phases: establishing capabilities, server authentication and key exchange, client authentication and key exchange, and finishing. The record protocol then encrypts and integrity checks data sent over the secure connection, while the alert protocol closes the connection if an error is detected.
This document discusses web security and encryption protocols. It provides an overview of Secure Sockets Layer (SSL) and Transport Layer Security (TLS), including their architecture, protocols, and differences. It also summarizes HTTPS, how it uses SSL/TLS to secure HTTP connections, and the processes for connection initiation and closure. Secure Electronic Transactions (SET) and digital signatures are introduced as standards for securing online payments and linking messages.
Transport Layer Security - Mrinal WadhwaMrinal Wadhwa
The document summarizes the evolution of the Transport Layer Security (TLS) protocol from versions 1.0 to 1.2. It describes the key components of TLS including the record protocol for fragmenting and transmitting encrypted data, handshake protocol for authentication and key exchange, and cipher suites for encryption algorithms. The TLS protocol provides secure communication over the internet by preventing eavesdropping, tampering, and forgery of messages between client and server applications.
The document summarizes the evolution of the Transport Layer Security (TLS) protocol from versions 1.0 to 1.2. It describes the key components of TLS including the record protocol for fragmenting and transmitting encrypted data, handshake protocol for authentication and key exchange, and cipher suites for encryption and message authentication. The TLS protocol provides secure communication over the internet by preventing eavesdropping, tampering, and forgery of messages between client and server applications.
This document summarizes a talk given by Chris Conlon from wolfSSL on September 15, 2017 in Tokyo, Japan about TLS 1.3. It provides background on Chris Conlon and his role at wolfSSL, an overview of wolfSSL's products and services including their lightweight SSL/TLS library. It also discusses the history and components of the SSL/TLS protocol, common vulnerabilities, and the goals of the new TLS 1.3 specification.
SSL and TLS provide secure communication over the internet using encryption. SSL uses public key encryption to establish a secure connection and exchange keys to encrypt data sent between a client and server. It defines sessions which allow parameters like encryption algorithms to be shared for multiple connections. TLS is an updated version of SSL that uses similar record and handshake protocols. SET is an open standard that uses digital certificates and dual signatures to securely conduct credit card transactions over the internet between cardholders, merchants, issuers and payment gateways.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate server and client identities securely. It uses public key encryption to generate a shared secret and establish an encrypted connection. The SSL handshake process verifies the server's identity and allows the client and server to agree on encryption algorithms before exchanging data. This helps prevent man-in-the-middle attacks by authenticating servers and encrypting the connection.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate server and client identities securely. It uses public key encryption to generate a shared secret and establish an encrypted connection. The SSL handshake process verifies the server's identity and allows the client and server to agree on encryption algorithms before exchanging data. This helps prevent man-in-the-middle attacks by authenticating servers and encrypting the connection.
SSL is a protocol that allows clients and servers to securely communicate over the internet. It uses public/private key encryption to authenticate servers and optionally authenticate clients. SSL establishes an encrypted connection using a handshake protocol to negotiate encryption parameters and exchange secret keys to encrypt the session. Popular open-source implementations of SSL include OpenSSL and Apache-SSL.
SSL is an acronym for Secure Sockets Layer. It is a protocol used for authenticating and encrypting web traffic. For web traffic to be authenticated means that your browser is able to verify the identity of the remote server.
SSL is a protocol that allows clients and servers to securely communicate over the internet. It uses public/private key encryption to authenticate servers and optionally authenticate clients. SSL establishes an encrypted connection using a handshake protocol to negotiate encryption parameters and exchange keys to encrypt subsequent communications. Popular open-source SSL implementations include OpenSSL and Apache-SSL.
This document discusses web security and Secure Sockets Layer (SSL) / Transport Layer Security (TLS). It defines key web security terminology like hackers, viruses, worms, and Trojans. It then explains what SSL/TLS is, how it provides security for web communications through encryption, message authentication codes, and authentication. The document outlines the SSL/TLS architecture, components, sessions and connections. It also discusses how SSL/TLS has been widely implemented in applications like HTTPS to secure internet traffic.
This document discusses web security and Secure Sockets Layer (SSL) / Transport Layer Security (TLS). It defines key web security terminology like hackers, viruses, worms, and Trojans. It then explains what SSL/TLS is, how it provides security for web communications through encryption, message authentication codes, and authentication. The document outlines the SSL/TLS architecture, components, sessions and connections. It also discusses how SSL/TLS has been widely implemented in applications like HTTPS to secure internet traffic.
This document discusses the course "Network Security" taught by Dr. Shivashankar at RRIT. The course aims to help students understand network security services, transport layer security using SSL and TLS, security concerns regarding the internet protocol, intruders and firewalls. It provides an overview of web security threats and approaches like IPsec and SSL. The document also describes the SSL/TLS handshake protocol and record protocol, cipher suites, and alert codes.
Sync IT is a decentralized file transfer solution that uses peer-to-peer networking and encryption to securely transfer files between clients. It leverages industry standard cryptographic techniques like AES-128 encryption and utilizes a custom transport protocol to optimize transfers over local and wide area networks. The system can be deployed entirely within a private infrastructure and includes a browser-based management interface to schedule and monitor transfers between client nodes.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate servers securely. It was first developed by Netscape in 1994 to provide server authentication, encryption of messages, and message integrity. SSL establishes an encrypted connection between a client and server through a handshake process that verifies servers, negotiates encryption, and generates symmetric keys to encrypt subsequent communication. It has become the standard security technology for web servers and browsers to protect online transactions and sensitive data transmission over the internet.
The document provides an overview of the Secure Sockets Layer (SSL) protocol. It discusses SSL's goals of providing confidentiality, integrity, and authentication for network communications. It describes the SSL handshake process, where the client and server authenticate each other and negotiate encryption parameters before transmitting application data. It also discusses SSL applications like securing web traffic and online payments. The document concludes that SSL is vital for web security and ensures user confidentiality and integrity.
SSL provides authentication and confidentiality for web communications. It operates at the transport layer, encrypting data between the application and transport layers. The SSL handshake protocol establishes a secure connection in 4 phases: establishing capabilities, server authentication and key exchange, client authentication and key exchange, and finishing. The record protocol then encrypts and integrity checks data sent over the secure connection, while the alert protocol closes the connection if an error is detected.
This document discusses web security and encryption protocols. It provides an overview of Secure Sockets Layer (SSL) and Transport Layer Security (TLS), including their architecture, protocols, and differences. It also summarizes HTTPS, how it uses SSL/TLS to secure HTTP connections, and the processes for connection initiation and closure. Secure Electronic Transactions (SET) and digital signatures are introduced as standards for securing online payments and linking messages.
Transport Layer Security - Mrinal WadhwaMrinal Wadhwa
The document summarizes the evolution of the Transport Layer Security (TLS) protocol from versions 1.0 to 1.2. It describes the key components of TLS including the record protocol for fragmenting and transmitting encrypted data, handshake protocol for authentication and key exchange, and cipher suites for encryption algorithms. The TLS protocol provides secure communication over the internet by preventing eavesdropping, tampering, and forgery of messages between client and server applications.
The document summarizes the evolution of the Transport Layer Security (TLS) protocol from versions 1.0 to 1.2. It describes the key components of TLS including the record protocol for fragmenting and transmitting encrypted data, handshake protocol for authentication and key exchange, and cipher suites for encryption and message authentication. The TLS protocol provides secure communication over the internet by preventing eavesdropping, tampering, and forgery of messages between client and server applications.
This document summarizes a talk given by Chris Conlon from wolfSSL on September 15, 2017 in Tokyo, Japan about TLS 1.3. It provides background on Chris Conlon and his role at wolfSSL, an overview of wolfSSL's products and services including their lightweight SSL/TLS library. It also discusses the history and components of the SSL/TLS protocol, common vulnerabilities, and the goals of the new TLS 1.3 specification.
SSL and TLS provide secure communication over the internet using encryption. SSL uses public key encryption to establish a secure connection and exchange keys to encrypt data sent between a client and server. It defines sessions which allow parameters like encryption algorithms to be shared for multiple connections. TLS is an updated version of SSL that uses similar record and handshake protocols. SET is an open standard that uses digital certificates and dual signatures to securely conduct credit card transactions over the internet between cardholders, merchants, issuers and payment gateways.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate server and client identities securely. It uses public key encryption to generate a shared secret and establish an encrypted connection. The SSL handshake process verifies the server's identity and allows the client and server to agree on encryption algorithms before exchanging data. This helps prevent man-in-the-middle attacks by authenticating servers and encrypting the connection.
SSL is a secure protocol that runs above TCP/IP and allows users to encrypt data and authenticate server and client identities securely. It uses public key encryption to generate a shared secret and establish an encrypted connection. The SSL handshake process verifies the server's identity and allows the client and server to agree on encryption algorithms before exchanging data. This helps prevent man-in-the-middle attacks by authenticating servers and encrypting the connection.
SSL is a protocol that allows clients and servers to securely communicate over the internet. It uses public/private key encryption to authenticate servers and optionally authenticate clients. SSL establishes an encrypted connection using a handshake protocol to negotiate encryption parameters and exchange secret keys to encrypt the session. Popular open-source implementations of SSL include OpenSSL and Apache-SSL.
SSL is an acronym for Secure Sockets Layer. It is a protocol used for authenticating and encrypting web traffic. For web traffic to be authenticated means that your browser is able to verify the identity of the remote server.
SSL is a protocol that allows clients and servers to securely communicate over the internet. It uses public/private key encryption to authenticate servers and optionally authenticate clients. SSL establishes an encrypted connection using a handshake protocol to negotiate encryption parameters and exchange keys to encrypt subsequent communications. Popular open-source SSL implementations include OpenSSL and Apache-SSL.
This document discusses web security and Secure Sockets Layer (SSL) / Transport Layer Security (TLS). It defines key web security terminology like hackers, viruses, worms, and Trojans. It then explains what SSL/TLS is, how it provides security for web communications through encryption, message authentication codes, and authentication. The document outlines the SSL/TLS architecture, components, sessions and connections. It also discusses how SSL/TLS has been widely implemented in applications like HTTPS to secure internet traffic.
This document discusses web security and Secure Sockets Layer (SSL) / Transport Layer Security (TLS). It defines key web security terminology like hackers, viruses, worms, and Trojans. It then explains what SSL/TLS is, how it provides security for web communications through encryption, message authentication codes, and authentication. The document outlines the SSL/TLS architecture, components, sessions and connections. It also discusses how SSL/TLS has been widely implemented in applications like HTTPS to secure internet traffic.
This document discusses the course "Network Security" taught by Dr. Shivashankar at RRIT. The course aims to help students understand network security services, transport layer security using SSL and TLS, security concerns regarding the internet protocol, intruders and firewalls. It provides an overview of web security threats and approaches like IPsec and SSL. The document also describes the SSL/TLS handshake protocol and record protocol, cipher suites, and alert codes.
Similar a 03-SSL (1).ppt03-SSL (1).ppt03-SSL (1).ppt03-SSL (1).ppt03-SSL (1).ppt03-SSL (1).ppt (20)
CHAPTER 1 SEMESTER V COMMUNICATION TECHNIQUES FOR CHILDREN.pdfSachin Sharma
Here are some key objectives of communication with children:
Build Trust and Security:
Establish a safe and supportive environment where children feel comfortable expressing themselves.
Encourage Expression:
Enable children to articulate their thoughts, feelings, and experiences.
Promote Emotional Understanding:
Help children identify and understand their own emotions and the emotions of others.
Enhance Listening Skills:
Develop children’s ability to listen attentively and respond appropriately.
Foster Positive Relationships:
Strengthen the bond between children and caregivers, peers, and other adults.
Support Learning and Development:
Aid cognitive and language development through engaging and meaningful conversations.
Teach Social Skills:
Encourage polite, respectful, and empathetic interactions with others.
Resolve Conflicts:
Provide tools and guidance for children to handle disagreements constructively.
Encourage Independence:
Support children in making decisions and solving problems on their own.
Provide Reassurance and Comfort:
Offer comfort and understanding during times of distress or uncertainty.
Reinforce Positive Behavior:
Acknowledge and encourage positive actions and behaviors.
Guide and Educate:
Offer clear instructions and explanations to help children understand expectations and learn new concepts.
By focusing on these objectives, communication with children can be both effective and nurturing, supporting their overall growth and well-being.
This particular slides consist of- what is Pneumothorax,what are it's causes and it's effect on body, risk factors, symptoms,complications, diagnosis and role of physiotherapy in it.
This slide is very helpful for physiotherapy students and also for other medical and healthcare students.
Here is a summary of Pneumothorax:
Pneumothorax, also known as a collapsed lung, is a condition that occurs when air leaks into the space between the lung and chest wall. This air buildup puts pressure on the lung, preventing it from expanding fully when you breathe. A pneumothorax can cause a complete or partial collapse of the lung.
As Mumbai's premier kidney transplant and donation center, L H Hiranandani Hospital Powai is not just a medical facility; it's a beacon of hope where cutting-edge science meets compassionate care, transforming lives and redefining the standards of kidney health in India.
End-tidal carbon dioxide (ETCO2) is the level of carbon dioxide that is released at the end of an exhaled breath. ETCO2 levels reflect the adequacy with which carbon dioxide (CO2) is carried in the blood back to the lungs and exhaled.
Non-invasive methods for ETCO2 measurement include capnometry and capnography. Capnometry provides a numerical value for ETCO2. In contrast, capnography delivers a more comprehensive measurement that is displayed in both graphical (waveform) and numerical form.
Sidestream devices can monitor both intubated and non-intubated patients, while mainstream devices are most often limited to intubated patients.
English Drug and Alcohol Commissioners June 2024.pptxMatSouthwell1
Presentation made by Mat Southwell to the Harm Reduction Working Group of the English Drug and Alcohol Commissioners. Discuss stimulants, OAMT, NSP coverage and community-led approach to DCRs. Focussing on active drug user perspectives and interests
At Malayali Kerala Spa Ajman, Full Service includes individualized care for every client. We specifically design each massage session for the individual needs of the client. Our therapists are always willing to adjust the treatments based on the client's instruction and feedback. This guarantees that every client receives the treatment they expect.
By offering a variety of massage services, our Ajman Spa Massage Center can tackle physical, mental, and emotional illnesses. In addition, efficient identification of specific health conditions and designing treatment plans accordingly can significantly enhance the quality of massaging.
At Malayali Kerala Spa Ajman, we firmly believe that everyone should have the option to experience top-quality massage services regularly. To achieve that goal we offer cheap massage services in Ajman.
If you are interested in experiencing transformative massage treatment at Malayali Kerala Spa Ajman, you can use our Ajman Massage Center WhatsApp Number to schedule your next massage session.
Contact @ +971 529818279
Visit @ https://malayalikeralaspaajman.com/
The facial nerve, also known as cranial nerve VII, is one of the 12 cranial nerves originating from the brain. It's a mixed nerve, meaning it contains both sensory and motor fibres, and it plays a crucial role in controlling various facial muscles, as well as conveying sensory information from the taste buds on the anterior two-thirds of the tongue.
NURSING MANAGEMENT OF PATIENT WITH EMPHYSEMA .PPTblessyjannu21
Prepared by Prof. BLESSY THOMAS, VICE PRINCIPAL, FNCON, SPN.
Emphysema is a disease condition of respiratory system.
Emphysema is an abnormal permanent enlargement of the air spaces distal to terminal bronchioles, accompanied by destruction of their walls and without obvious fibrosis.
Emphysema of lung is defined as hyper inflation of the lung ais spaces due to obstruction of non respiratory bronchioles as due to loss of elasticity of alveoli.
It is a type of chronic obstructive
pulmonary disease.
It is a progressive disease of lungs.
Emotional and Behavioural Problems in Children - Counselling and Family Thera...PsychoTech Services
A proprietary approach developed by bringing together the best of learning theories from Psychology, design principles from the world of visualization, and pedagogical methods from over a decade of training experience, that enables you to: Learn better, faster!
Digital Health in India_Health Informatics Trained Manpower _DrDevTaneja_15.0...DrDevTaneja1
Digital India will need a big trained army of Health Informatics educated & trained manpower in India.
Presently, generalist IT manpower does most of the work in the healthcare industry in India. Academic Health Informatics education is not readily available at school & health university level or IT education institutions in India.
We look into the evolution of health informatics and its applications in the healthcare industry.
HIMMS TIGER resources are available to assist Health Informatics education.
Indian Health universities, IT Education institutions, and the healthcare industry must proactively collaborate to start health informatics courses on a big scale. An advocacy push from various stakeholders is also needed for this goal.
Health informatics has huge employment potential and provides a big business opportunity for the healthcare industry. A big pool of trained health informatics manpower can lead to product & service innovations on a global scale in India.
2. Course organization (subject to revision)
January
• Two written homeworks: first due next Thursday (9 days)
• Lectures on case studies (protocols and tools)
• Choose your project: we’ll start giving examples Thursday
February
• Project presentation #1: describe your system (5-10 min)
• Lectures on additional approaches
• Project presentation #2: describe security properties
March
• Project presentation #3: results of study
Grading: 20% homework, 30% project presentations, 50% project results and final presentation
3. Overview
Introduction to the SSL / TLS protocol
• Widely deployed, “real-world” security protocol
Protocol analysis case study
• Start with the RFC describing the protocol
• Create an abstract model and code it up in Murj
• Specify security properties
• Run Murj to check whether security properties are
satisfied
This lecture is a compressed version of what you
would do if SSL were your project!
4. What is SSL / TLS?
Transport Layer Security protocol, ver 1.0
• De facto standard for Internet security
• “The primary goal of the TLS protocol is to provide
privacy and data integrity between two communicating
applications”
• In practice, used to protect information transmitted
between browsers and Web servers
Based on Secure Sockets Layers protocol, ver 3.0
• Same protocol design, different algorithms
Deployed in nearly every web browser
6. History of the Protocol
SSL 1.0
• Internal Netscape design, early 1994?
• Lost in the mists of time
SSL 2.0
• Published by Netscape, November 1994
• Several problems (next slide)
SSL 3.0
• Designed by Netscape and Paul Kocher, November 1996
TLS 1.0
• Internet standard based on SSL 3.0, January 1999
• Not interoperable with SSL 3.0
7. SSL 2.0 Vulnerabilities
Short key length
• In export-weakened modes, SSL 2.0 unnecessarily weakens the
authentication keys to 40 bits.
Weak MAC construction
Message integrity vulnerability
• SSL 2.0 feeds padding bytes into the MAC in block cipher
modes, but leaves the padding-length unauthenticated, may
allow active attackers to delete bytes from the end of messages
Ciphersuite rollback attack
• An active attacker may edits the list of ciphersuite preferences
in the hello messages to invisibly force both endpoints to use a
weaker form of encryption
• “Least common denominator" security under active attack
8. Let’s get going with SSL/TLS …
Intruder
Model
Analysis
Tool
Formal
Protocol
Informal
Protocol
Description
Find error
RFC
(request for
comments)
9. Request for Comments
Network protocols are defined in an RFC
TLS version 1.0 is described in RFC 2246
Intended to be a self-contained definition of the
protocol
• Describes the protocol in sufficient detail for readers
who will be implementing it and those who will be
doing protocol analysis (that’s you!)
• Mixture of informal prose and pseudo-code
Read some RFCs to get a flavor of what protocols
look like when they emerge from the committee
11. From RFC to Murj Model
Intruder
Model
Analysis
Tool
Formal
Protocol
Informal
Protocol
Description
Find error
Murj code
RFC
12. TLS Basics
TLS consists of two protocols
Handshake protocol
• Use public-key cryptography to establish a shared
secret key between the client and the server
Record protocol
• Use the secret key established in the handshake
protocol to protect communication between the client
and the server
We will focus on the handshake protocol
13. TLS Handshake Protocol
Two parties: client and server
Negotiate version of the protocol and the set of
cryptographic algorithms to be used
• Interoperability between different implementations of
the protocol
Authenticate client and server (optional)
• Use digital certificates to learn each other’s public keys
and verify each other’s identity
Use public keys to establish a shared secret
15. Encryption scheme
• functions to encrypt, decrypt data
• key generation algorithm
Secret key vs. public key
• Public key: publishing key does not reveal key-1
• Secret key: more efficient, generally key = key-1
Hash function, MAC
• Map input to short hash; ideally, no collisions
• MAC (keyed hash) used for message integrity
Signature scheme
• Functions to sign data, verify signature
Recall: Basic Cryptographic Concepts
16. Use of cryptography
C
Version, Crypto choice, nonce
Version, Choice, nonce,
signed certificate
containing server’s
public key Ks
S
Secret key K
encrypted with
server’s key Ks
hash of sequence of messages
hash of sequence of messages
switch to negotiated cipher
17. SSL/TLS Cryptography Summary
Public-key encryption
• Key chosen secretly (handshake protocol)
• Key material sent encrypted with public key
Symmetric encryption
• Shared (secret) key encryption of data packets
Signature-based authentication
• Client can check signed server certificate
• And vice-versa, in principal
Hash for integrity
• Client, server check hash of sequence of messages
• MAC used in data packets (record protocol)
18. Public-Key Infrastructure
Certificate
Authority Ka, Ka-1
Client Server
Known public signature verification key Ka
Sign(Ka-1, Ks)
Certificate
Sign(Ka-1, Ks)
Ks
Server certificate can be verified by any client that has CA verification key Ka
Certificate authority is “off line”
Ka
19. Another general idea in SSL
Client, server communicate
Compare hash of all messages
• Compute hash(hi,hello,howareyou?) locally
• Exchange hash values under encryption
Abort if intervention detected
Client Server
Hi
Hello
How are you?
20. SSL/TLS in more detail …
ClientHello C S C, VerC, SuiteC, NC
ServerHello S C VerS, SuiteS, NS, signCA{ S, KS }
ClientVerify C S signCA{ C, VC }
{ VerC, SecretC }
signC { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) }
-------- Change to negotiated cipher --------------------------------------------------------------------
ServerFinished S C { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + S + Master(NC, NS, SecretC) + Pad1))
}
ClientFinished C S { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1))
}
KS
Master(NC, NS, SecretC)
Master(NC, NS, SecretC)
21. Abbreviated Handshake
The handshake protocol may be executed in an
abbreviated form to resume a previously
established session
• No authentication, key material not exchanged
• Session resumed from an old state
For complete analysis, have to model both full
and abbreviated handshake protocol
• This is a common situation: many protocols have
several branches, subprotocols for error handling, etc.
22. Rational Reconstruction
Begin with simple, intuitive protocol
• Ignore client authentication
• Ignore verification messages at the end of the
handshake protocol
• Model only essential parts of messages (e.g., ignore
padding)
Execute the model checker and find a bug
Add a piece of TLS to fix the bug and repeat
• Better understand the design of the protocol
23. Protocol Step by Step: ClientHello
C
ClientHello
S
Client announces (in plaintext):
• Protocol version she is running
• Cryptographic algorithms she supports
24. struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites;
CompressionMethod compression_methods;
} ClientHello
ClientHello (RFC)
Highest version of the protocol
supported by the client
Session id (if the client wants to
resume an old session)
Cryptographic algorithms
supported by the client (e.g.,
RSA or Diffie-Hellman)
25. ClientHello (Murj)
ruleset i: ClientId do
ruleset j: ServerId do
rule "Client sends ClientHello to server (new session)"
cli[i].state = M_SLEEP &
cli[i].resumeSession = false
==>
var
outM: Message; -- outgoing message
begin
outM.source := i;
outM.dest := j;
outM.session := 0;
outM.mType := M_CLIENT_HELLO;
outM.version := cli[i].version;
outM.suite := cli[i].suite;
outM.random := freshNonce();
multisetadd (outM, cliNet);
cli[i].state := M_SERVER_HELLO;
end; end; end;
26. ServerHello
C
C, Versionc, suitec, Nc
ServerHello
S
Server responds (in plaintext) with:
• Highest protocol version both client &
server support
• Strongest cryptographic suite selected
from those offered by the client
29. “Abstract” Cryptography
We will use abstract data types to model
cryptographic operations
• Assumes that cryptography is perfect
• No details of the actual cryptographic schemes
• Ignores bit length of keys, random numbers, etc.
Simple notation for encryption, signatures, hashes
• {M}k is message M encrypted with key k
• sigk(M) is message M digitally signed with key k
• hash(M) for the result of hashing message M with a
cryptographically strong hash function
31. struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
ClientKeyExchange (RFC)
Let’s model this as {Secretc}Ks
32. “Core” SSL
C
Versions, suites, Ns,
sigca(S,Ks),
“ServerHelloDone”
S
C, Versionc, suitec, Nc
{Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
33. Participants as Finite-State Machines
M_SLEEP
ClientHello
Murj rules define a finite-state machine for each protocol participant
Client state
M_SERVER_HELLO
M_SERVER_KEY
M_SEND_KEY
M_CLIENT_HELLO
Server state
M_SEND_KEY
M_CLIENT_KEY
M_DONE
ServerHello
ServerKeyExchange
ClientKeyExchange
35. Intruder Can Intercept
Store a message from the network in the data
structure modeling intruder’s “knowledge”
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
…
alias known: int[i].messages do
if multisetcount(m: known,
msgEqual(known[m], msg)) = 0 then
multisetadd(msg, known);
end;
end;
end;
36. Intruder Can Decrypt if Knows Key
If the key is stored in the data structure modeling
intruder’s “knowledge”, then read message
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
…
if msg.mType = M_CLIENT_KEY_EXCHANGE then
if keyEqual(msg.encKey, int[i].publicKey.key) then
alias sKeys: int[i].secretKeys do
if multisetcount(s: sKeys,
keyEqual(sKeys[s], msg.secretKey)) = 0 then
multisetadd(msg.secretKey, sKeys);
end;
end;
end;
37. Intruder Can Create New Messages
Assemble pieces stored in the intruder’s
“knowledge” to form a message of the right format
ruleset i: IntruderId do
ruleset d: ClientId do
ruleset s: ValidSessionId do
choose n: int[i].nonces do
ruleset version: Versions do
rule "Intruder generates fake ServerHello"
cli[d].state = M_SERVER_HELLO
==>
var
outM: Message; -- outgoing message
begin
outM.source := i; outM.dest := d; outM.session := s;
outM.mType := M_SERVER_HELLO;
outM.version := version;
outM.random := int[i].nonces[n];
multisetadd (outM, cliNet);
end; end; end; end;
38. Intruder Model and Cryptography
There is no actual cryptography in our model
• Messages are marked as “encrypted” or “signed”, and
the intruder rules respect these markers
Our assumption that cryptography is perfect is
reflected in the absence of certain intruder rules
• There is no rule for creating a digital signature with a
key that is not known to the intruder
• There is no rule for reading the contents of a message
which is marked as “encrypted” with a certain key,
when this key is not known to the intruder
• There is no rule for reading the contents of a “hashed”
message
40. Secrecy
Intruder should not be able to learn the secret
generated by the client
ruleset i: ClientId do
ruleset j: IntruderId do
rule "Intruder has learned a client's secret"
cli[i].state = M_DONE &
multisetcount(s: int[j].secretKeys,
keyEqual(int[j].secretKeys[s], cli[i].secretKey)) > 0
==>
begin
error "Intruder has learned a client's secret"
end;
end;
end;
41. Shared Secret Consistency
After the protocol has finished, client and server
should agree on their shared secret
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server's shared secret is not the same as its client's"
ismember(ser[i].clients[s].client, ClientId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
!keyEqual(cli[ser[i].clients[s].client].secretKey,
ser[i].clients[s].secretKey)
==>
begin
error "S's secret is not the same as C's"
end;
end;
end;
42. Version and Crypto Suite Consistency
Client and server should be running the highest
version of the protocol they both support
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server has not learned the client's version or suite correctly"
!ismember(ser[i].clients[s].client, IntruderId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
(ser[i].clients[s].clientVersion != MaxVersion |
ser[i].clients[s].clientSuite.text != 0)
==>
begin
error "Server has not learned the client's version or suite correctly"
end;
end;
end;
43. Finite-State Verification
...
...
Murj rules for protocol
participants and the intruder
define a nondeterministic state
transition graph
Murj will exhaustively
enumerate all graph nodes
Murj will verify whether
specified security conditions
hold in every reachable node
If not, the path to the violating
node will describe the attack
Correctness
condition violated
44. When Does Murj Find a Violation?
Bad abstraction
• Removed too much detail from the protocol when
constructing the abstract model
• Add the piece that fixes the bug and repeat
• This is part of the rational reconstruction process
Genuine attack
• Yay! Hooray!
• Attacks found by formal analysis are usually quite
strong: independent of specific cryptographic
schemes, OS implementation, etc.
• Test an implementation of the protocol, if available
45. “Basic” SSL 3.0
C
Versions=3.0, suites
sigca(S,Ks),
“ServerHelloDone”
S
C, Versionc=3.0, suitec
{Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
46. Version Consistency Fails!
C
Versions=2.0, suites
sigca(S,Ks),
“ServerHelloDone”
S
C, Versionc=2.0, suitec
{Secretc}Ks
C and S end up communicating using SSL 2.0
(weaker earlier version of the protocol)
Server is fooled into thinking he
is communicating with a client
who supports only SSL 2.0
47. struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
A Case of Bad Abstraction
Model this as {Versionc, Secretc}Ks
This piece matters! Need to add it to the model.
48. Better “basic” SSL
C
Versions=3.0, suites
sigca(S,Ks),
“ServerHelloDone”
S
C, Versionc=3.0, suitec
{Versionc,Secretc}Ks
switch to key derived
from secretc
If the protocol is correct, C and S share
some secret key material secretc at this point
switch to key derived
from secretc
Prevents version
rollback attack
Add rule to check that received version
is equal to version in ClientHello
49. Summary of Incremental Protocols
A = Basic protocol
B = A + version consistency check
D = B + certificates for both public keys
– Authentication for client + Authentication for server
E = D + verification (Finished) messages
– Prevention of version and crypto suite attacks
F = E + nonces
– Prevention of replay attacks
G = “Correct” subset of SSL
– Additional crypto considerations (black art) give SSL 3.0
50. VerC, SteC
VerS, SteS, KI
{ SecretC }
C S
KS
Attack on Protocol B
Intruder in the middle
• Replaces server key by intruder’s key
• Intercepts secret from client
• Simulates client to server, server to client
I
VerC, SteC
VerS, SteS, KS
{ SecretC }
KI
51. Solution: Certificate Authority
Defeats previous attack
• But client is not authenticated to the server ...
VersionC, SuiteC
VersionS, SuiteS, signCA{ S, KS }
{ SecretC }
C S
KS
52. Replay Attacks
Network eavesdropper can record messages
If protocol is deterministic, then
• Eavesdropper can replay client messages to server, OR
• Eavesdropper can replay server message to client
This is a problem
• In each session, each party should be guaranteed that the other
is a live participant in the session
Solution
• Each run of each protocol should contain at least one new value
generated by each party, included in messages, and checked
before session is considered done
53. “Core” SSL Handshake with server auth (only)
C
Versions, suites, Ns
sigca(S,Ks),
“ServerHelloDone”
S
C, Versionc, suitec , Nc
{Versionc,Secretc}Ks
Hash of sequence of messages
Hash of sequence of messages
switch to negotiated cipher
Server public key in
certificate signed by CA
Nonces to avoid replay
Hash messages to confirm
consistent views
54. Anomaly (Protocol F)
C S
… SuiteC …
… SuiteS …
…
Switch to negotiated cipher
Finished Finished
data data
55. Anomaly (Protocol F)
C S
… SuiteC …
… SuiteS …
…
Switch to negotiated cipher
Finished Finished
data data
X X
57. Version Rollback Attack
C S
SessionId, VerC= 2.0, NC, ...
Finished Finished
data data
VerS= 2.0, NS, ...
X
X
{ NS } SecretKey { NC } SecretKey
SSL 2.0 Finished messages do not include version numbers or cryptosuites
58. Basic Pattern for Doing Your Project
Read and understand protocol specification
• Typically an RFC or a research paper
• We’ll put a few on the website: take a look!
Choose a tool
• Murj by default, but we’ll describe many other tools
• Play with Murj now to get some experience
(installing, running simple models, etc.)
Start with a simple (possibly flawed) model
• Rational reconstruction is a good way to go
Give careful thought to security conditions
59. Background Reading on SSL 3.0
Optional, for deeper understanding of SSL / TLS
D. Wagner and B. Schneier. “Analysis of the SSL 3.0 protocol.”
USENIX Electronic Commerce ’96.
• Nice study of an early proposal for SSL 3.0
J.C. Mitchell, V. Shmatikov, U. Stern. “Finite-State Analysis of SSL
3.0”. USENIX Security ’98.
• Murj analysis of SSL 3.0 (similar to this lecture)
• Actual Murj model available
D. Bleichenbacher. “Chosen Ciphertext Attacks against Protocols
Based on RSA Encryption Standard PKCS #1”. CRYPTO ’98.
• Cryptography is not perfect: this paper breaks SSL 3.0 by directly
attacking underlying implementation of RSA