程序代写 ECS726: Security and Authentication

ECS726: Security and Authentication
Week6: Example Application of Cryptography: SSL/TLS protocol, Kerberos
Pasquale Malacaria EECS, QMUL

Learning Outcomes (this lecture)
􏰀 Understand: SSL/TLS and Kerberos protocols.
􏰀 Practice the arguments for establishing required security properties.

Learning Outcomes (of the book chapter)
􏰀 Familiarity with a range of applications of cryptography, identifying what we have learned:
◃ Internet security (SSL/TLS), Kerberos
◃ Wireless Local Area Networks (WEP, WPA)
◃ Mobile Telecommunication (GSM, UTMS, 3G/4G)
◃ Video Broadcasting (Subscription TV, pay-per-view)
◃ Electronic IDs, Secure Payment Cards (chip-and-pin)
◃ Anonymity and Anti-Censorship (Tor/I2P)
◃ Cryptocurrency (blockchain, timestamping, mining)
􏰀 Compare the different environment and security requirement constraints of these applications.
􏰀 Appreciating the effect of these constraints on the choice of cryptography and key management.

A Quick Review

Review: Cryptographic Primitives Alone
Table 1: Mapping of primitives used on their own to provide security services (Table 1.1 in the book).
Encr. Hash MAC Dig. Sig.
No Sometimes No Yes
D.O.A. N.R. E.A.
No No No No No No Yes Sometimes No Yes Yes No

Review: Cryptographic Primitives Combined
Table 2: Mapping of primitives that can be used to help provide security services. (Table 1.2 in the book).
Encr. Hash MAC Dig. Sig.
Yes Yes Yes Yes No Yes No Yes
D.O.A. N.R. E.A.
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

􏰀 Transport Layer Security (TLS) protocol is the main protocol behind Internet’s security (no big deal!)
􏰀 Also used for security email, instant messaging, VoIP (again, no big deal!)
􏰀 HTTPS: is just HTTP over TLS!
􏰀 FTPS: is just FTP over TLS!
􏰀 SMTP uses TLS for secure email delivery!

Port Description
889 FTP data over TLS/SSL (FTPS-DATA) 990 FTP control over TLS/SSL (FTPS)
992 telnet protocol over TLS/SSL (telnets) 25 SMTP
465/587 SMTP over TLS/SSL (SMTPS)
443 HTTP over TLS/SSL (HTTPS)
636 LDAP over TLS/SSL (SLDAP)

SSL/TLS: History
􏰀 First developed in the mid-1990s by Netscape Communications for use with their Navigator browser, and they called it Secure Sockets Layer (SSL).
◃ SSLv1 …………………………. broken at birth
◃ SSLv2 …………. many flaws, deprecated by IETF
◃ SSLv3 …….. now broken (POODLE + RC4 attacks)

SSL/TLS: History
􏰀 In 1999, the Internet Engineering Task Force (IETF), standardised an improved version of (which was no longer tied to any application layer browser or OS) and adopted the name TLS (Transport Layer Security).
◃ TLS 1.0 ………………………………….1999
◃ TLS 1.1 ………………………………….2006
◃ TLS 1.2 ………………………………….2008
◃ TLS 1.3 (significantly different) . . . . . 2018 (RFC8446)
Originally designed for secure e-commerce, now the de facto secure protocol of choice, used everywhere.

TLS requires a reliable underlying transport protocol, e.g., Transmission Control Protocol (TCP) in Internet, but is under the application layer. (Note: TLS does not require TCP, any reliable transport protocol would do.)
◃ In contrast, SSH (Secure Shell) protocol is at the application layer, and IPsec protocol is at the Internet Procol (IP) layer.
The (green) padlock sign in your browser shows that you are (properly) using HTTP over TLS, i.e., HTTPS.

TLS provides a secure channel between two entities (e.g. a client web browser and a web server) over a public channel. In particular, it can provide confidentiality, data integrity and origin authentication, and entity authentication.
◃ TLS is designed to work even in cases where there is no security association, i.e., where entities have never before shared any secret information or even agreed on the choice of algorithms, etc.
◃ How? Using public-key cryptography, and (public key) certificates (and cipher-suite negotiation).

TLS uses a wide range of cryptographic primitives:
• Public-key cryptography is used to enable symmetric key establishment.
• Digital signatures are used to sign certificates and facilitate entity authentication.
• Symmetric encryption is used to provide confidentiality.
• MACs are used to provide data origin authentication and facilitate entity authentication.
• Hash functions are used as components of MACs and digital signatures, and for key derivation.

SSL/TLS: cipher-suite
The two entities agree on the cipher-suite, example: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
◃ TLS the protocol;
◃ ECDHE the key exchange algorithm;
◃ ECDSA the digital signature algorithm (for verifying the certificates);
◃ AES_256_CBC the bulk (symmetric key) encryption algorithm;
◃ SHA384 indicates the hash in HMAC algorithm.

SSL/TLS: handshake and record
TLS consists of two parts:
􏰀 Handshake Protocol: performs all the tasks requiring agreement between the two entities before they set up the secure TLS channel. In particular:
◃ agree on the cipher suite to be used;
◃ establish entity authentication; and
◃ establish the keys needed to secure the channel.
􏰀 Record Protocol: This protocol implements the secure channel, involving:
◃ formatting the data (breaking it up into blocks, etc);
◃ computing MACs on the data; and
◃ encrypting the data.

SSL/TLS: Handshake Protocol Description
Client Request Server Response
Pre-master secret transfer Client finished Server finished

TLS: illustration

SSL/TLS: Handshake Protocol Description
Client Request (ClientHello): This message from the client initiates the communication session. It includes:
◃ a session ID, (a unique identifier for the session – if the client wants to reuse some parameters from an older session);
◃ a pseudorandom number rC , used for freshness;
◃ a list of cipher suites that the client supports. e.g.:
– TLS_RSA_WITH_AES_256_CBC_SHA256,
– TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, – …
The list is in order of preference of the client.

SSL/TLS: Handshake Protocol Description
Server Response: with some initialisation data:
◃ the session ID;
◃ a pseudorandom number rS, which is the server’s
freshness contribution to the protocol;
◃ the particular cipher suite chosen from the list offered
by the client, which includes a specification of the
method to establish shared keys;
◃ a copy of the server’s public-key certificate, including
details of any certificate chain required to verify it;
◃ if the server has chosen Ephemeral DH to establish
shared keys, then it also generates a fresh set of parameters for it and sends the public values
alongside a digital signature on them. 17

SSL/TLS: Handshake Protocol Description
◃ The client now checks that the server’s public-key certificate is valid. This will involve checking the validity of all the public-key certificates in the chain, as well as checking any relevant CRLs.
◃ If the Ephemeral DH protocol is being used, then the client also verifies the digital signature on the DH parameters.

SSL/TLS: Handshake Protocol Description
Pre-master Secret Transfer: The client and server now need to agree on a shared pre-master secret KP , which will be used to derive the keys used to secure the session. The most popular techniques are:
1. if RSA has been selected for key establishment, then the client pseudorandomly generates KP , encrypts it using the server’s public key and sends to the server;
2. if Ephemeral DH has been selected for key establishment, then the client generates a fresh temporary DH key pair and sends the public value to the server, after which both client and server compute the shared DH secret KP .

SSL/TLS: Handshake Protocol Description
The client and server are both now in a position to derive the keys required to secure the TLS session:
◃ First, they use a key derivation function that takes KP as key and also rC and rS as inputs, to compute the master secret KM .
◃ The client and server both then use KM to derive keys to be used for MAC and encryption.
◃ From this point on, all exchanged messages are cryptographically protected.

SSL/TLS: Handshake Protocol Description
Client Finished: The client computes a MAC (typically based on HMAC) on the hash of all the messages sent thus far. Then encrypts it and sends it to the server.
Server Finished: The server checks the MAC received from the client. The server then computes a MAC on the hash of all the messages sent thus far. This MAC is then encrypted and sent to the client.
◃ Finally, the client checks the MAC received from the server.

TLS: Handshake Protocol Analysis
􏰀 Agreement of cryptographic algorithms. This is achieved at the end of the second protocol message (when the server informs the client which cipher suite has been selected from the list provided by the client).

TLS: Handshake Protocol Analysis
􏰀 Entity authentication of the server. assuming the protocol run has been successful, we argue:
1. The entity who sent the Server Finished message must know the master secret KM , since the final check was correct and relied on knowledge of KM .
2. Any entity who knows KM must also know the pre-mastersecretKP,sinceKM isderivedfromKP.

TLS: Handshake Protocol Analysis
3. Any entity other than the client who knows KP must know the private key corresponding to the public-key certificate sent in the message Server Response, since:
◃ if RSA has been selected for key establishment, this private key is necessary to decrypt KP in the message Pre-master Secret Transfer;
◃ if Ephemeral DH has been selected for key establishment, then this private key was used to sign a verified digital signature on public DH parameters needed to compute KP .

TLS: Handshake Protocol Analysis
4. The only entity with the ability to use the private decryption key is the genuine server, since the public-key certificate provided by it in the message Server Response was checked and found to be valid.
5. The server is currently “alive” because KM is derived from fresh pseudorandom values (KP and rC ) generated by the client and thus cannot be an old value.

TLS: Handshake Protocol Analysis
􏰀 Key establishment. TLS establishes several keys, all of which are derived from the master secret KM , which is a value established during the Handshake Protocol. The master secret is derived from the pre-master secret KP , which is a value only the client and the server know.
Note that the Client Finished and Server Finished messages also provide assurance that none of the messages exchanged during the Handshake Protocol have been tampered with, which is particularly important since the opening messages of the protocol have no cryptographic protection.

TLS: Handshake Protocol Analysis
Question: Which one of the goals of AKE do we have?
◃ Mutual entity authentication
◃ Mutual data origin authentication
◃ Mutual key establishment
◃ Key confidentiality
◃ Key freshness
◃ Unbiased key control

TLS: Handshake Protocol w/ Client Authentication
◃ The simple Handshake Protocol does not provide mutual entity authentication, only entity authentication of the server.
◃ For some applications, this may be fine, e.g. client authentication is done at the application layer (using a password, token, etc.), or the server simply may not care! (e.g., when a user purchases goods from an online store, merchant may only care about getting paid at the end!)

TLS: Handshake Protocol w/ Client Authentication
Mutual authentication is achievable by adding an extra message from the client to the server after the message Pre-master Secret Transfer, as follows:
􏰀 Client Authentication Data: The client sends a copy of its public-key certificate to the server.
◃ The public key in this certificate is used as a verification key.
◃ The client hashes all the protocol messages so far and digitally signs the hash using the client’s signature key.

TLS: Handshake Protocol wi/ Client Authentication
Mutual authentication is achievable by adding an extra message from the client to the server after the message Pre-master Secret Transfer, as follows:
􏰀 Client Authentication Data: The client sends a copy of its public-key certificate to the server.
◃ The public key in this certificate is used as a verification key.
◃ The client hashes all the protocol messages so far and digitally signs the hash using the client’s signature key.

TLS: Handshake Protocol w/ Client Authentication
◃ The server then checks that the client’s public-key certificate (chain) is valid.
◃ The server also verifies the client’s digital signature at the end.

TLS: Analysis of Handshake w/ Client Auth.
Entity authentication assurance of the client follows:
1. The entity who sent the Client Authentication Data message must know the signature key corresponding to the public key in the client’s certificate (why?)
2. The only entity who knows the signature key is the genuine client (why?)
3. The client is currently “alive” (why?)

SSL/TLS: Record Protocol
The TLS’s Record Protocol is used to instantiate the secure channel after the Handshake Protocol has successfully completed.
􏰀 Before running the Record Protocol, both client and server derive the necessary cryptographic data:
◃ symmetric session keys for encryption;
◃ symmetric MAC keys for data integrity/origin
authentication (and by extension, entity
authentication);
◃ and any required IVs.

SSL/TLS: Record Protocol
◃ These are all generated using a key derivation function to compute a “key block”.
◃ This key derivation function uses KM as a key and takes as input, among other data, rC and rS.
◃ The key block is then “chopped up” to provide the necessary cryptographic data.

SSL/TLS: Record Protocol
In particular, the following four symmetric keys are extracted from the key block:
◃ KECS for symm. encryption from client to server; ◃ KESC for symm. encryption from server to client; ◃ KMCS for MACs from the client to the server; and ◃ KMSC for MACs from the server to the client.
Note: these keys are never explicitly exchanged! But how did we get them to be the same on both parties?

SSL/TLS: Record Protocol
For data sent from the client to the server, e.g., the process is:
1. Compute a MAC on the data (and various other inputs) using key KMCS;
2. append the MAC to the data and then pad, if necessary, to a multiple of the block length; and
3. encrypt the resulting message using key KECS.
4. Upon receipt of the protected message, the server
decrypts it using KECS and then verifies the recovered MAC using KMCS.
Recall: so TLS is using a MAC-then-Encrypt scheme. Question: what were the alternatives? their pros/cons?

SSL/TLS: TLS 1.3
Motivations for TLS 1.3:
◃ Weaknesses. the discovery of a number of attacks on TLS, e.g. Renegotiation attack (2009), Downgrade attacks: FREAK and Logjam, Cross-protocol attacks:DROWN, BEAST attack, CRIME and BREACH attacks, POODLE, Sweet32, . . .
◃ Efficiency. The Handshake Protocol is somewhat inefficient, requiring two round trips between the client and server.

SSL/TLS: TLS 1.3
Main differences between TLS 1.3 and earlier versions:
◃ Perfect Forward Secrecy. (what is it?) This is achieved by removing support for key establishment based on RSA and mandating the use of DHE.
◃ Protocol. The handshake is made more efficient by only requiring one full round trip, and more of it is encrypted. Further, the messages in the new Handshake Protocol are protected by dedicated keys (the two Finished messages of were protected using the same keys as used in the Record Protocol).
◃ Authenticated encryption modes. Encryption “must” use an authenticated-encryption mode.

is an authentication protocol. The name comes from Greek mythology: is the ferocious three-headed guard dog of Hades (God of the dead).

is a protocol based on tickets.
• Kerberos allows agents communicating over a non-secure network to prove their identity to one another in a secure manner.
• Kerberos protocol messages are protected against eavesdropping and replay attacks.
• Kerberos uses symmetric-key cryptography, requires a trusted third party, and usually uses public-key cryptography…

• it was developed at Massachusetts Institute of Technology (MIT) in the 80s
• there are both free and commercial versions
• It relies on a trusted Key Distribution Center (KDC)
• as the KDC is trusted it doesn’t need public key cryptography

Kerberos: illustration

Kerberos: Client Authentication
Protocol steps: step 1 Client Authentication
• client sends a cleartext message of the user ID to the AS (Authentication Server) requesting services on behalf of the user.
• AS checks if client is in its database. If it is, AS generates the secret key by hashing the password of the user found at the database and sends back the following two messages (Message A, Message B) to the client:

Kerberos: Client Authentication
1. Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
2. Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client network address, ticket validity period, and the Client/TGS Session Key) encrypted using the secret key of the TGS
client receives A and B: if client is genuine he can decrypt A and obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS’s secret key.)

Kerberos: Client Service Authorization
Protocol steps: step 2 Client Service Authorization. When client needs a service:
• client sends the following messages to the TGS:
1. Message C: Composed of the message B (the
encrypted TGT using the TGS secret key) and the ID
of the requested service.
2. Message D: Authenticator (which is composed of the
client ID and the timestamp), encrypted using the Client/TGS Session Key.

Kerberos: Client Service Authorization
TGS receives C and D. It decrypts message B using the TGS secret key obtaining Client/TGS Session Key and the client ID (both are in the TGT). Client/TGS Session Key, the TGS decrypts message D (Authenticator) and compares the client IDs from messages B and D; if they match TGS sends the following two messages to the client:
1. Message E: Client-to-server ticket (which includes the client ID, client network address, validity period, and Client/Server Session Key) encrypted using the service’s secret key.
2. Message F: Client/Server Session Key encrypted
with the Client/TGS Session Key. 46

Kerberos: Client Service Request
Protocol steps: step 3 Client Service Request. Client can now use a service:
• when client receive E and F from TGS, he can authenticate itself to the Service Server (SS). He sends to SS:
1. Message E: From the previous step (the Client-to-server ticket, encrypted using service’s secret key).
2. Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.

Kerberos: Client Service Request
• SS decrypts the ticket (message E) with its own secret key and retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and compares client ID from messages E and G, if they match SS sends client the following
1. Message H: The timestamp found in client’s Authenticator encrypted using the Client/Server Session Key.
client decrypts the confirmation (message H) using the Client/Server Session Key and checks timestamp. If so, secure communication is established

Kerberos: illustration

Further protocols
SSl/TLS and Kerberos are only two among hundreds of protocols used everyday and relying on cryptography.
Chapter 12 (Cryptographic Applications) in the book “Everyday Cryptography” provides several other important examples

Further protocols

程序代写 CS代考加微信: powcoder QQ: 1823890830 Email: powcoder@163.com

Related Posts