Source string Source string

220/10000 · 220
English Actions
There are situations where symmetric authentication is required. In this case, each user must perform some computation with his/her private key. A possible exchange is the following. Alice sends her certificate to Bob. Bob replies with a nonce, :math:`R1`, and provides his certificate. Alice encrypts :math:`R1` with her private key and generates a nonce, :math:`R2`. Bob verifies Alice's computation and encrypts :math:`R2` with his private key. Alice verifies the computation and both have been authenticated.
The protocol described above works, but it takes a long time for Bob to authenticate Alice and for Alice to authenticate Bob. A faster authentication could be the following.
Alice sends her random nonce, :math:`R2`. Bob signs :math:`R2` and sends his nonce : :math:`R1`. Alice signs :math:`R1` and both are authenticated.
Now consider that Mallory wants to be authenticated as Alice. The above protocol has a subtle flaw that could be exploited by Mallory. This flaw can be exploited if Alice and Bob can act as both client and server. Knowing this, Mallory could operate as follows. Mallory starts an authentication with Bob faking himself as Alice. He sends a first message to Bob including Alice's identity.
In this exchange, Bob authenticates himself by signing the :math:`RA` nonce that was sent by Mallory. Now, to authenticate as Alice, Mallory needs to compute the signature of nonce :math:`RB` with Alice's private key. Mallory does not know Alice's key, but he could exploit the protocol to force Alice to perform the required computation. For this, Mallory can start an authentication to Alice as shown below.
In this example, Mallory has forced Alice to compute :math:`E_p(Alice_{priv},RB)` which is the information required to finalize the first exchange and be authenticated as Alice. This illustrates a common problem with authentication schemes when the same information can be used for different purposes. The problem comes from the fact that Alice agrees to compute her signature on a nonce chosen by Bob (and relayed by Mallory). This problem occurs if the nonce is a simple integer without any structure. If the nonce includes some structure such as some information about Alice and Bob's identities or even a single bit indicating whether the nonce was chosen by a user acting as a client (i.e. starting the authentication) or as a server, then the protocol is not vulnerable anymore.
To cope with some of the above mentioned problems, public-key cryptography is usually combined with certificates. A `certificate` is a data structure that includes a signature from a trusted third party. A simple explanation of the utilization of certificates is to consider that Alice and Bob both know Ted. Ted is trusted by these two users and both have stored Ted's public key : :math:`Ted_{pub}`. Since they both know Ted's key, he can issue certificates. A certificate is mainly a cryptographic link between the identity of a user and his/her public key. Such a certificate can be computed in different ways. A simple solution is for Ted to generate a file that contains the following information for each certified user :
his/her identity
his/her public key
a hash of the entire file signed with Ted's private key
Then, knowing Ted's public key, anyone can verify the validity of a certificate. When a user sends his/her public key, he/she must also attach the certificate to prove the link between his/her identity and the public key. In practice, certificates are more complex than this. Certificates will often be used to authenticate the server and sometimes to authenticate the client.
A possible protocol could then be the following. Alice sends :math:`Cert(Alice_{pub},Ted)`. Bob replies with a random nonce.
Until now, we have only discussed the authentication problem. This is an important but not sufficient step to have a secure communication between two users through an insecure network. To securely exchange information, Alice and Bob need to both :
mutually authenticate each other
agree on a way to encrypt the messages that they will exchange
Let us first explore how this could be realized by using public-key cryptography. We assume that Alice and Bob have both a public-private key pair and the corresponding certificates signed by a trusted third party : Ted.
A possible protocol would be the following. Alice sends :math:`Cert(Alice_{pub},Ted)`. This certificate provides Alice's identity and her public key. Bob replies with the certificate containing his own public key : :math:`Cert(Bob_{pub},Ted)`. At this point, they both know the other public key and could use it to send encrypted messages. Alice would send :math:`E_p(Bob_{pub},M1)` and Bob would send :math:`E_p(Alice_{pub},M2)`. In practice, using public key encryption techniques to encrypt a large number of messages is inefficient because these cryptosystems require a large number of computations. It is more efficient to use secret key cryptosystems for most of the data and only use a public key cryptosystem to encrypt the random secret keys that will be used by the secret key encryption scheme.
Key exchange
When users want to communicate securely through a network, they need to exchange information such as the keys that will be used by an encryption algorithm even in the presence of an eavesdropper. The most widely used algorithm that allows two users to safely exchange an integer in the presence of an eavesdropper is the one proposed by Diffie and Hellman [DH1976]_. It operates with (large) integers. Two of them are public, the modulus, p, which is prime and the base, g, which must be a primitive root of p. The communicating users select a random integer, :math:`a` for Alice and :math:`b` for Bob. The exchange starts as :
Alice selects a random integer, :math:`a` and sends :math:`A=g^{a} \mod p` to Bob
Bob selects a random integer, :math:`b` and sends :math:`B=g^{b} \mod p` to Alice
From her knowledge of :math:`a` and :math:`B`, Alice can compute :math:`Secret=B^{a} \mod p= (g^{b} \mod p) ^{a} \mod p=g^{a \times b} \mod p`
From is knowledge of :math:`b` and :math:`A`, Bob can compute :math:`Secret=A^{b} \mod p=(g^{a} \mod p) ^{b} \mod p=g^{a \times b} \mod p`
The security of this protocol relies on the difficulty of computing discrete logarithms, i.e. from the knowledge of :math:`A` (resp. :math:`B`), it is very difficult to extract :math:`\log(A)=\log(g^{a} \mod p)=a` (resp. :math:`\log(B)=\log(g^{b} \mod p)=b`).
An example of the utilization of the Diffie-Hellman key exchange is shown below. Before starting the exchange, Alice and Bob agree on a modulus (:math:`p=23`) and a base (:math:`g=5`). These two numbers are public. They are typically part of the standard that defines the protocol that uses the key exchange.
Alice chooses a secret integer : :math:`a=8` and sends :math:`A= g^{a} \mod p= 5^{8} \mod 23=16` to Bob
Bob chooses a secret integer : :math:`b=13` and sends :math:`B= g^{b} \mod p=5^{13} \mod 23=21` to Alice
Alice computes :math:`S_{A}=B^{a} \mod p= 21^{8} \mod 23=3`
Bob computes :math:`S_{B}=A^{b} \mod p= 16^{13} \mod 23=3`
Alice and Bob have agreed on the secret information :math:`3` without having sent it explicitly through the network. If the integers used are large enough and have good properties, then even Eve who can capture all the messages sent by Alice and Bob cannot recover the secret key that they have exchanged. There is no formal proof of the security of the algorithm, but mathematicians have tried to solve similar problems with integers during centuries without finding an efficient algorithm. As long as the integers that are used are random and large enough, the only possible attack for Eve is to test all possible integers that could have been chosen by Alice and Bob. This is computationally very expensive. This algorithm is widely used in security protocols to agree on a secret key.
Unfortunately, the Diffie-Hellman key exchange alone cannot cope with man-in-the middle attacks. Consider Mallory who sits in the middle between Alice and Bob and can easily capture and modify their messages. The modulus and the base are public. They are thus known by Mallory as well. He could then operate as follows :

Loading…

No matching activity found.
Browse all component changes

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only
Source string location
../../principles/security.rst:893
String age
3 years ago
Source string age
3 years ago
Translation file
locale/pot/principles/security.pot, string 77