Skip to content

Appunti - Network Security II

Public key cryptography with certification authorities

We augment the considered scenario with three assumptions, described in the next sections. The resulting scenario models all the practical applications of public key cryptography. In this augmented scenario:

  • Any subject may securely send “its public key” to any other subject by communicating only on C (not on CS).
  • Any two subjects may securely choose a key for private key cryptography by communicating only on C (not on CS).

In other words, any two subjects may thus establish a secure channel on C by only communicating on C itself, that is, by communicating only on the channel that they do not trust.

The two requirements that made the previous procedure impractical are no longer required:

  • A secure channel CS should exist between all pairs of subjects.
  • The time required for completing the key exchange on CS should be sufficiently short.

Intuitively, communication on CS is required only “at the beginning” and with a small set of subjects (the certification authorities). Having executed this costly-but-secure interaction once, there is no need to communicate on CS again and all communications may occur on C.

Certificates and certification authorities

A certification authority is a subject that attests (certifies) the public key of other subjects.

We assume that each subject interacts with a certification authority for proving that it is associated with a specified name A (i.e., that it has the right to impersonate subject A) and a specified public key KPUB-A. The details of this procedure are irrelevant and depend on the specific certification authority.

If the proof satisfies the certification authority, then the certification authority constructs a file and signs this file with its own private key. This file is called a certificate and contains an indication of the certification authority that constructed the file, that is, of the issuer of the certificate. We denote certificates as < Subject, KPUB, Issuer > (the signature is implicitly present), meaning that the certificate contains the association between the specified subject and specified public key, the association has been verified by the specified issuer and the issuer has signed the certificate with its own private key.

Note that certificates contain public information and thus need not be confidential or secret. Any subject can have a copy of the certificate of any other subject. Clearly, for any certificate, there will be only one subject whose private key is the companion of the public key in the certificate.

There are a few different standards for the format of certificates. The most important one is X.509. In this standard, subjects and issuers are described by means of a set of named strings: common name, organizational unit, organization, country and others. The rules for actually choosing these values are part of the protocol specification.

For practical reasons, a certificate has an expiration date chosen and signed by the issuer. The certificate cannot be used after that date, i.e., no software will accept to use an expired certificate.

For practical reasons, it may be necessary to revoke a certificate, i.e., the certification authority that issued a certain certificate might declare that certificate no longer valid even before its expiration date. The issues related to certificate revocation are very complex and not discussed in this course-

KeySet and TrustSet

We assume that each subject obtains on CS the association <Subject-i, KPUB-i> for a small set of certification authorities. We call the set of these associations KeySet of the subject.

Let S be a subject whose KeySet contains < CA-X, KPUB-X >. S may verify signatures made by CA-X, thus S may verify authenticity and integrity of certificates issued by S. These properties are guaranteed even for certificates that S receive on C, i.e., on the insecure channel..

Authenticity and integrity of a signed sequence of bytes do not imply that the sequence of bytes represents a true proposition or a real fact. In particular, “authenticity” does not mean “the signed content is true”: it means that the content has been signed with the private key companion of the public key used in verification.

A certification authority could thus sign a false association between a subject and a public key. It follows that a certificate may contain a false association between a subject and a public key, even though the signature on the certificate is verified.

We assume that each subject has a small set of subjects representing certification authorities that are trusted by that subject. A certificate issued by a trusted certification authority is assumed to contain real associations.

In summary, we augment the considered scenario by assuming that each subject:

  1. Has a certificate for its public key.
  2. Obtains on CS the public keys of certification authorities (KeySet).
  3. Chooses a set of trusted certification authorities (TrustSet).

The resulting scenario models all the practical applications of public key cryptography.

The actual implementation of KeySet and TrustSet depends on the software that uses public key cryptography. In many cases, such sets are part of the operating system and every software uses those sets. In some cases a software could use its own KeySet and TrustSet, managed independently of those of the operating system. In practice, KeySet and TrustSet exist with terminology and structure different from the one used in this document.

PersonalSet

A subject with a private-public key pair needs to store this information.

The public key is always associated with the name of that subject, in a certificate issued by a certification authority. While the certificate may be read by any subject, the private key obviously must be readable only by the subject associated with that private key. In many implementation a private key is associated with a password: the private key can be used only by proving knowledge of the corresponding password.

We denote by PersonalSet the set containing the private-public key pair of a subject. The content of this set must be carefully protected from fraudulent accesses. The actual implementation of the PersonalSet depends on the software that uses public key crytpography. In practice, this set appears with terminology and structure different from the one used in this document (much like KeySet and TrustSet). The corresponding storage may be a file stored in the device or in a smartcard.

Note that the PersonalSet cannot be kept always offline: the private key must be accessible to the software that needs to sign documents or to decrypt messages encrypted with the matching public key.

In most cases, the PersonalSet is empty: most users need not sign documents; most users need not authenticate with public key cryptography. Of course, web servers available on https must have a non-empty PersonalSet.

In some cases a PersonalSet could contain multiple key pairs. This occurs when a device may impersonate multiple subjects or when a subject may use multiple key pairs (in practice, a key that can be used for signing documents cannot be used for authentication with public key cryptography; the reasons are not part of this course).

Sending public keys on an untrusted channel: Solved!

In the augmented scenario, any subject may send “its public key” to any other subject by communicating only on C (not on CS!). The key distribution problem is thus solved in a practical way.

The procedure is as follows. Let A be the sending subject. Let B the receiving subject and let KeySet-B, Trust-Set-B denote the corresponding KeySet and TrustSet.

  1. A sends “its certificate” to B: < S=A, KPUB=KPUB-A, I=CA-A>
  2. B verifies that it can use the certificate:
    1. CA-A belongs to TrustSet-B.
    2. CA-A belongs to KeySet-B
  3. B validates the certificate:
    1. verifies the signature on the received certificate with the public key of the issuer, obtained in KeySet-B (i.e., by using < CA-A, KPUB-CA-A>).
    2. verifies that the certificate has not expired.

If all the checks succeed, then B knows that the public key of A is the one in the received certificate.

If any of the checks fails, then B cannot use the received certificate and thus does not know the public key of A (step 2-a: B does not assume that the association encoded by the certificate is real; step 2-b: B cannot verify the signature on the certificate; step 3-a: the certificate has no authentication and integrity guarantees).

Necessary condition for using a certificate, thus, is that the issuer of the certificate belongs to both the KeySet and TrustSet of the subject willing to use that certificate.

Securing the insecure channel: Solved!

Two subjects A and B may obtain secrecy, integrity, authentication on C easily, by exchanging their certificates on C (as discussed below).

Any two subjects may thus establish a secure channel on C by only communicating on C itself, that is, by communicating only on the channel that they do not trust. All that is needed is a communication on CS “only at the beginning” and only for initializing the respective KeySet and TrustSet (in practice, this communication on CS corresponds to installing an operating system from a trusted source).

The resulting procedure is as follows:

  1. Exchange the respective certificates on C
  2. Choose a key K-AB on C by means of public key cryptography
  3. Communicate on C using K-AB, i.e., send each message m as EK_AB(m),MACK-AB(m)

An attacker could attempt to impersonate A as follows (the reasoning for the attempt of impersonating B is identical):

  1. Send the real certificate of A. In this case the attacker cannot decrypt the key that B will choose and send encrypted with the public key of A (step 2).
  2. Modify the certificate of A by replacing KPUB-A with the attacker’s public key. In this case when B will verify the signature on the certificate, the verification will fail because there is no integrity.
  3. Forge a certificate that associates A with the attacker’s public key. In this case when B will verify the signature on the certificate, either the verification will fail because there is no authenticity (if the attacker forges a certificate whose issuer is in the KeySet of B) or the certificate cannot be verified (if the issuer is not in the KeySet of B).

An attacker could attempt other attacks (for example on CS, or on the content of KeySets and TrustSets) but those attacks are based on a different threat model, that is, they require abilities different from those assumed here. The three attacks outlined above summarize all the attacks that can be done by a network attacker.

TLS (Transport Layer Security)

Security guarantees and implementation

TLS provides secrecy, integrity and server authentication on top of TCP connections.

These guarantees are obtained with the procedures based on public key cryptography with certification authorities. The key difference with the description in the previous sections is that in the default TLS configuration:

  • The server has a private-public key pair and authenticates with public key cryptography.
  • Clients need not have any private-public key pair and do not authenticate.

The corresponding procedure is as follows (this is a much oversimplified description of the real TLS protocol):

  1. Client opens a TCP connection with Server.
  2. Client sends the name of the Server.
  3. Server sends its certificate < S=ServerSubject, KPUB=KPUB-S, I=CA >.
  4. Client validates received certificate.
  5. Client verifies that received certificate is for the expected subject (the one specified at step 1).
  6. Client chooses a key K and sends EKPUB-S(K) to Server.
  7. Client and Server communicate using K, i.e., send each message m as EK(m),MACK(m)

In principle, any application protocol based on TCP can be used on TLS. After executing steps 1-5, client and server will interact as specified by the application protocol. This is what happens, for example, in HTTPS.

To understand the need for step 2 consider a scenario in which a given server has several names and hosts a websites for each such name. In this case the server must have a different keypair and certificate for each name. Without step 2, the server would not know which certificate to send at step 3.

To understand the need for step 5, consider the following example. At step 1 the client contacts the DNS for obtaining the IP address of “server.com”; the network attacker could falsify the DNS response, thus the client would open a TCP connection with the attacker. Suppose the network attacker has a valid certificate. This certificate will be for a subject different from "server.com" because the attacker does not have the right to use that name, thus (by hypothesis) no certification authority will issue a certificate for that subject name to the attacker. Without step 4, steps 2-6 would complete successfully, irrespective of the subject contained in the certificate of the Attacker: thus the Client would believe to be connected to “server.com” while in fact it is connected to the Attacker.

It is thus necessary to bind the Server identity as specified by the Client in step 1, to the server identity as contained in the certificate. In principle, the “subject” field of a certificate could be a DNS name. The certification authority would check that the subject requesting the certificate has the right to use that DNS name; and, clients would verify at step 5 that the subject in the received certificate matches the DNS name specified at step 1.

In practice, the “subject” field of a certificate is not a DNS name. A certificate contains a name called “Subject Alternative Name” whose value is a list of DNS names. These names are used as described in the previous paragraph (more details can be found in this blog post). In this course we may assume that the subject field of a certificate is a DNS name.

Understanding server authentication

Consider a website on server goodsite.com at address IP-good. Consider an attacker with a website on server badsite.com at address IP-bad. We explore the various options available to the attacker to impersonate goodsite.com, that is, to trick browsers that want to connect to goodsite.com to actually connect to the attacker’s website.

Case 1: The browser connects to http://goodsite.com.

  1. Browser sends DNS request for obtaining IP address of goodsite.com
  2. Attacker spoofs DNS response and responds with IP-bad.
  3. Browser connects to IP-bad, 80.
  4. TCP connection opens.
  5. Browser sends HTTP request to Attacker and Attacker responds.

The attack thus succeeds. The address bar on the browser will show http://goodsite.com but the content will be provided by the Attacker. This fact is not surprising because http does not provide server authentication.

Note that many websites are available both on http and on https; when a browser attempts to connect on http, the website responds with a redirection to https. The above attack succeeds irrespective of whether goodsite.com is available only on https or on both http and https.

Case 2: The browser connects to https://goodsite.com.

  1. Browser sends DNS request for obtaining IP address of goodsite.com
  2. Attacker spoofs DNS response and responds with IP-bad.
  3. Browser connects to IP-bad, 443.

At this point there are the following possibilities:

  • Attacker does not have https site. The TCP connection will not open, because the Attacker web server is not listening on port 443.
  • Attacker has a valid certificate for badsite.com. TCP Connection opens, Attacker sends certificate, Browser detects that the certificate is not for goodsite.com and closes the connection.
  • Attacker has a copy of the certificate of goodsite.com (any subject may obtain a copy of this certificate, for example by connecting to the real https://goodsite.com). TCP Connection opens, Attacker sends certificate, Browser sends a private key encrypted with the public key in that certificate. Attacker cannot decrypt, thus communication will not proceed and the connection will close.
  • Attacker obtains a certificate for goodsite.com from a certification authority in the KeySet and TrustSet of the browser. This fact cannot occur by hypothesis.

Thus, if a browser follows an https URL then the browser is guaranteed that the web server is authentic. This means that:

The content shown by the browser is indeed provided by the web server whose DNS name appears in the browser address bar.

A big practical problem occurs because browsers often follow URLs received in email messages or found in other web pages. In these cases a browser may connect to an attacker-controlled website (https://badsite.com) whose appearance may be identical to that of another website (https://goodsite.com). In particular, the attacker-controlled website could replicate the login page of https://goodsite.com. Although the address bar of the browser will show https://badsite.com, users that forget to check the address bar or are not able to perform that check correctly will send their credentials for goodsite.com to badsite.com, i.e., to the attacker (phishing). Of course, the attacker could choose for its website an URL syntactically similar to the URL to attack.

Note that an attacker-controlled website (https://badsite.com) may have an appearance identical to that of another website (https://goodsite.com) despite both sites being on https. This fact does not violate the server authentication property described above. The reason is because https does not provide any guarantee on “which data” will be sent within the TCP connection by the web server.

TLS with mutual authentication

TLS with mutual authentication is not part of this course.

In the default TLS configuration, client authentication is not provided. Clients may authenticate with the mechanisms specified by the application-level protocol. For example, in HTTPS, they may authenticate with BASIC or FORM authentication and the corresponding network traffic will have the security guarantees provided by TLS.

Application-level authentication mechanisms involve the use of a client password. This fact introduces many practical problems because:

  • The client can be tricked to send the password to an Attacker (phishing);
  • The password of all the clients must be known to the server; an attacker could manage to steal all the passwords from the server.

A TLS server may be configured with mutual authentication. In this case clients must have a private-public key pair. When the server sends its certificate, it specifies that mutual authentication is required. The resulting procedure is as follows:

  1. Client opens a TCP connection with Server.
  2. Server sends its certificate < S=ServerSubject, KPUB=KPUB-S, I=CA > and requires mutual authentication.
  3. Client validates received certificate.
  4. Client verifies that received certificate is for the expected subject.
  5. Client chooses a key K and sends E_KPUB-S(K) to Server and sends its certificate< C = ClientSubject, KPUB=KPUB-C, I =CA-C>.
  6. Server validates received certificate.
  7. Server chooses a key K1 and sends E_KPUB-C(K1) to Client
  8. Client and Server communicate using K concatenated with K1

The client identity at the application protocol will be the subject in the client certificate and the application will consider the client as authenticated. The details for passing this information from TLS to the application are irrelevant.

Using TLS with mutual authentication removes the password problems completely, because the client secret (its private key) never leaves the client device:

  • The client cannot be tricked to send its private key to an Attacker (because the client never sends its private key);
  • The private key of clients is not known to the server, thus the Attacker cannot steal all those keys from the server.

In other words, a client authenticates to the server by demonstrating that it knows a secret. In the case of passwords, the server must know the secret and this fact leads to important practical problems. In the case of public key cryptography, the server need not know the secret thus the corresponding problems are eliminated. The reason why the server need not know the secret is this: the server constructs a problem that only the client can solve and such that the server can verify it has been solved (“decrypt this number: E_KPUB-C(K1)”)

The reason why TLS with mutual authentication is rarely used despite its advantages is because managing the credential lifecycle when credentials are key pairs is much more costly and more difficult than when credentials are passwords.

Practical considerations on public key cryptography

Certification authorities

It cannot be proved with absolute (mathematical) certainty that a certification authority only certifies real associations.

Certification authorities must use procedures that even in the presence of mistakes or attacks never end up in certifying false associations. However, it is impossible to prove that such events never occur. One can only obtain a high degree of confidence on the fact that a certification authority only certifies real associations.

Once a subject considers that a certification authority is trusted, the subject assumes that all certificates with a valid signature issued by that authority describe real associations.

Key pair generation

In principle, a subject could generate a private-public key pair and then interact with a certification authority to have a certificate for his/her public key.

In practice, key pairs are generated by certification authorities. A subject interacts with a certification authority not only for obtaining a certificate but also for obtaining a key pair. The certification authority thus provides every subject with a key pair and a certificate for the corresponding public key.

This fact is a practical necessity because subjects usually do not have the required technical skills. Of course, certification authority must be trusted to not retain a copy of the private keys that they distribute.

Self-signed certificates

A self-signed certificate is one in which subject and issuer are identical. The signature of a self-signed certificate is verified with the public key in the certificate.

Any subject may construct a self-signed certificate for any other subject and such that the signature on the certificate is valid. To this end, the subject only needs to:

  1. Generate a new public-private key pair.
  2. Construct a certificate associating the newly-created public key with any arbitrary subject (i.e., specifying an arbitrary value for the fields “subject” and “issuer” to be written in the certificate).
  3. Sign the certificate with the newly-created private key. The key point is that any subject can be specified at step 2. The signature on the certificate will be valid, as long as the certificate is not modified. This fact is not surprising because a byte sequence with a valid signature may or may not contain a true proposition.

A self-signed certificate, thus, does not provide any guarantee on whether it describes a real association. A valid signature on a self-signed certificate only provides authenticity and integrity, with authenticity meaning that the certificate was signed with the private key companion of the public key in the certificate. Authenticity does not mean that the content of the certificate contains a true proposition (i.e., a real association).

Let S be a subject that receives a self-signed certificate. In practice:

  • If the certificate was received on CS then the certificate is assumed to describe a real association.
  • If the certificate was received on C, then the software asks the subject how to proceed (or may be configured to take on the choices below automatically):
    1. Do not use the self-signed certificate.
    2. Use the self-signed certificate, only once.
    3. Use the self-signed certificate and store the certificate in the KeySet and TrustSet.

When receiving a self-signed certificate over an untrusted channel C, the subject should make a choice based on its degree of confidence that the received self-signed certificate indeed contains a real association. Of course, such a degree of confidence will be much lower than what typically obtained on CS.

KeySet and TrustSet: Actual content

The key exchange channel CS is an abstraction that models the transmission of public keys of certification authorities from each certification authority to devices. As observed above, it is impossible to mathematically prove that CS indeed provides the required security properties (i.e., that KeySet indeed contains the real public keys of certification authorities). One can only obtain a high degree of confidence that CS provides those properties even in the presence of attacks.

Elements of the KeySet and of the TrustSet are self-signed certificates. This fact is due to technical reasons that are irrelevant to our discussion.

KeySet and TrustSet are part of the operating system. Thus, CS includes the distribution, installation, configuration and maintenance of the operating system on the device. Furthermore, it is the operating system that specifies which certification authorities are trusted.

The content of KeySet and TrustSet must be carefully protected from fraudulent modification: an attacker could modify the public key of a certification authority in the KeySet as well as insert other (attacker-controlled) certification authorities in the TrustStore. Attacks on these sets may occur during fabrication, installation, configuration, usage of the device. Those attacks correspond to a threat model different from a network attacker, however.

The actual implementation of KeySet and TrustSet depend on the operating system. In practice, these sets appear with terminology and structure different from the one used in this document.

Key storage in practice

The actual implementation of KeySet, TrustSet, PersonalSet in practice is quite intricate. We provide this information only for completeness of discussion.

In Windows, KeySet and TrustSet appear as a single set; this set can be accessed from Control Panel, Internet Options, Content, Certificates, in the tab named “Trusted Root Certification Authorities” (“Autorità di Certificazione Radice Attendibile”). The PersonalSet can be accessed in the same way, in the tab named “Personal”.

In Java, KeySet and TrustSet can be kept separate. A Java program must be associated with a property called TrustStore whose value is the name of a file containing the TrustSet. This file must follow a Java-specific format called keystore. A Java program must be associated also with a property called KeyStore, whose value is the name of a keystore file containing the PersonalSet (if the PersonalSet is empty then the KeyStore property is never used).

Certificates received on C that have been validated can be stored in the device, so that the public key of the corresponding subject will be always available locally. In Windows, these certificates are stored in the tab named “Other users”; in Java, these certificates must be stored in the file specified as KeyStore.

In other words, in Java there is a set containing the public keys of trusted certification authorities (TrustStore) and a set containing the keypair(s) of the user and the public keys of other subjects (KeyStore). Certificates in the KeyStore must be signed by subjects in the TrustStore. PGP uses yet a different structure than either Windows or Java.