Читать книгу Cryptography, Information Theory, and Error-Correction - Aiden A. Bruen - Страница 80

TLS is used to protect data during communication via the Internet. Prior to TLS, the Secure Socket Layer (SSL) protocol was used for secure Internet transactions. The SSL protocol was developed by the Netscape corporation in the 1990s. It evolved into the TLS protocol [MC19,Res18,RNGC19], with the original TLS version 1.0 essentially being SSL version 3.1 [NIS20]. TLS is designed to provide authentication, confidentiality, and data integrity protection between two communicating entities. It is widely used to secure communications in online transactions, including financial transactions, such as online banking and online purchases, and healthcare transactions, such as viewing online medical records [MC19].

Most people will have encountered TLS on a regular basis while making purchases online, logging into accounts, such as social media accounts over the Internet. When doing these via a web browser (such as Google Chrome, Safari, Firefox, Microsoft Edge), these types of applications use HTTPS (Hyper‐Text Transfer Protocol – Secure), which can use TLS. Note that HTTP should never be used to access websites when sensitive or valuable information is involved, such as login names and passwords, bank information. So before entering or accessing any sensitive or valuable information into a website via web browser, always be sure that the URL you are accessing has https: before it (e.g. https://www.amazon.com ) as opposed to http: .

As mentioned, TLS is designed to provide authentication, confidentiality, and data integrity protection between two communicating entities. It uses an encrypted channel for communication between a client and a server (with the “client” often being one's web browser). This protects e‐mail messages, for example, from man‐in‐the‐middle attacks during message transmission. (See Section 7.4 for a discussion of Man‐in‐the‐Middle attacks.)

TLS uses a combination of symmetric encryption (such as AES from Chapter 5) and asymmetric encryption (such as RSA from this chapter). Asymmetric cryptography is generally slower and is used for authentication and distributing a shared secret. Symmetric encryption is quicker but needs a shared secret which the asymmetric algorithm provides. The symmetric encryption is used for the actual encrypted transaction.

Before a secure TLS transaction occurs, the server (eBay, Amazon, PayPal, etc.) must generate a public key/private key pair, and then get this pair signed by an authority. This signed information is called the certificate. The person (or organization) that signs the certificate knows as the certificate authority (CA). Anyone may sign a certificate, but every machine maintains a list of trusted CAs, and if the server's certificate is not signed, a warning is usually produced.

The signing process is merely the CA using its private key to encrypt some known data. The client may then use the CA's public key to decrypt this data and compare it to the known value. If they match, then it must have been the CA who actually signed the certificate.

There are three subprotocols to the TLS protocol: the handshake protocol, the change cipher spec protocol, and the alert protocol. The handshake protocol is used to negotiate the session parameters. The change cipher spec protocol is used to change the cryptographic parameters of a session. The alert protocol notifies the client or server of any error conditions.

The handshake protocol consists of a series of messages between the client and server to negotiate the cryptographic algorithms that will be used so as to provide confidentiality, message integrity, authentication, and replay protection. Symmetric keys and other session parameters are established. There are three phases to the handshake protocol:

1 Key exchange.The client sends a ClientHello message to the server. This message contains a random nonce, it notes which versions of TLS it supports, and it indicates which cryptographic protocols it can use.The server responds with a ServerHello message noting the version of TLS that will be used, and which cryptographic protocols will be used.The client and server exchange messages to determine shared keys and other cryptographic parameters.

2 Server parameters.In this (encrypted) phase, the client and server negotiate the other handshake parameters, including whether the client will be authenticated.

3 Authentication.In this (encrypted) phase, the server is authenticated. The client can be optionally authenticated as well.

As part of the establishment of keys during the TLS handshake protocol, a premaster secret, a master secret and the session keys are derived. The premaster secret depends on the key exchange method that is agreed upon by the client and server, and the version of TLS that is being used. The premaster secret together with values contained in the ClientHello and ServerHello messages are used in a pseudorandom function to compute the master secret. Session keys are derived from the master secret. These session keys are used to provide a secure channel for the client and server to communicate with each other. For further details, see [MC19] and [Res18].

When the client and server share the same secret key (in this case, the session keys), they may use a fast symmetric algorithm to communicate. When the two parties are finished communicating, then the session keys are forgotten, and would have to be regenerated for further transactions.