Скачать книгу

      We concentrate on the Diffie–Hellman key‐exchange. The Elliptic Curve key‐exchange discussed in Chapter 6 is very similar, the main difference being that it uses a different group.

      Basically, the intruder Eve impersonates B to A and A to B. We use the notation of Section 3.7. Eve chooses an exponent x, and intercepts both g Superscript a Baseline left-parenthesis mod p right-parenthesis from A to B and g Superscript b Baseline left-parenthesis mod p right-parenthesis from B to A. The procedures is as follows:

      1 Eve intercepts from A to B and sends to A.

      2 Eve computes , i.e. .

      3 A computes . Thus, Eve and A have a common secret key .

      4 Eve intercepts from B to A and sends to B. Then Eve and B establish a common secret key . .

      When A sends a message to B encrypted with upper E Subscript bold upper A then Eve intercepts it, decrypts it with upper E Subscript bold upper A, encrypts it with upper E Subscript bold upper B and sends it to B. B decrypts it with upper E Subscript bold upper B.

      A and B have no idea that Eve is in possession of their secret. To avoid the attack, A and B need a procedure that authenticates A(B) to B(A). One way of achieving this is by using digital signatures.

      

      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.

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

      

      Pretty Good Privacy (or PGP) is a computer program which provides cryptographic privacy and authentication. It is a patented technology created by Phil Zimmerman and owned by the PGP Corporation. PGP may encrypt any type

Скачать книгу