Skip to content

Appunti - Network Security I

Communication scenario

We consider a large set of subjects communicating among themselves. Each subject has a name in the form of a string. A message is a sequence of bytes associated with the subject that constructed the sequence. The association may be encoded in the message either explicitly or implicitly. We say that a sequence of bytes contains a subject to mean that it contains the name of that subject.

In practical scenarios, a subject may be an organization, an individual, a computer and so on. Messages may be frames, packets, byte streams, application messages, emails, files and so on. The communication channel may be a network, a file system, a person carrying a memory pen and so on. A subject name may be an Ethernet address, an IP address, a DNS name, an email address, a username, a fiscal code, an X509 tuple and so on.

The nature of subjects, of the communication channel, of messages and the format of names are irrelevant and depend on the specific application.

Subjects may be distributed worldwide and may belong to many different organizations. We assume that the set of subjects is “very large”; the composition of this set may vary dynamically and is not known to any entity.

Security properties

We aim at obtaining one or more of the security properties described below, despite the presence of an adversary (an attacker) that actively attempts to deny these properties. The actions that can be executed by the adversary (threat model) are described in a later section.

  • Secrecy (also called Confidentiality). A message can be understood only by its intended recipient.
  • Integrity. Let m be a message constructed at time t1 and used at time t2. Any difference between the content of m at t1 and its content at t2 is detected.
  • Authentication. Let m be a message carrying an explicit or implicit indication that has been constructed by subject S. If the subject that constructed m is not S, this discrepancy is detected.

Additional security properties

Other security properties very important in practice are the following.

  • Non repudiation. Let m be a message constructed by subject S. Assume that S claims to not have constructed m, or to have constructed m with a different content. Any subject can detect that the claim is false.
  • Timestamp. Integrity, augmented with the ability for any subject to determine that m indeed existed at any specified instant t1.
  • Availability. When two subjects need to communicate they are indeed able to communicate.

Non-repudiation and timestamp are essential properties for any commercial and/or legally binding operation. Availability is an essential property in any scenario.

These properties are not considered in this course.

Threat model

Whenever one has to reason about security properties, it is always necessary to specify the assumed threat model, i.e., the set of actions that the attacker can execute.

We consider a threat model that we call network attacker. A network attacker is a subject with the ability to observe, modify, discard any message at any time instant. The network attacker is also able to construct a sequence of bytes and transmit it as a message at any time instant.

How a subject may acquire the ability to operate as a network attacker is irrelevant.

It is simple to realize that none of the protocols analyzed so far in this course provide any security property with this threat model.

  • Secrecy (the attacker may observe any message);
  • Integrity (the attacker may modify any message and the modification will be undetected by the recipient);
  • Authentication (the attacker may forge a message and associate it with any subject; the attacker may modify a message that carries an explicit association with a subject and replace that subject with any subject).

Note that the above considerations apply to protocols at all levels: network, internetwork, application

Unless specified otherwise, in the following we will use the term attacker as a synonym for network attacker.

Practical considerations on the scenario

There is a myriad of different protocols and applications that use cryptographic techniques for obtaining security properties.

Some of those protocols and applications are: HTTPS, TLS, SSH (a protocol for remote login and remote network access), digital signatures on executable files, legally binding digital signatures on documents, DKIM (a protocol for detecting falsified sender email addresses), “Posta Elettronica Certificata”, Kerberos (a protocol used in enterprise networks based on Windows), NTLM (a protocol used in networks based on Windows), DNSSEC (a protocol for digitally signing DNS records), IPSEC, VPN, WPA Personal (the protocol for secure wi-fi communication used in our homes and in all public locations in which all devices connect with the same password), WPA Enterprise (the protocol for secure wi-fi communication used in enterprise networks including eduroam), Windows Update, Android PlayStore, WhatsApp, WhatsApp Web, chip-and-pin bancomat cards, SIM authentication in cellular phone networks, disk encryption, PGP, and so on, and so on.

We will analyze in detail only HTTPS and TLS. The fundamental concepts that we describe for these protocols apply to all the other cases.

Practical considerations on the threat model (I)

A network attacker may operate only on the communication channel. The endpoints are thus assumed to be outside of the reach of the attacker.

In practical scenarios this assumption is often not verified (for example when a node has a malware or an attacker knows a password). In those cases, the protocols and mechanisms described here will not provide the desired security properties. For example, if the attacker can read information on the communicating endpoints, then the attacker can obtain keys of private key cryptography and private keys of public key cryptography: it is simple to realize from the discussions below that in those cases secrecy and authentication will not be provided (the attacker can decrypt messages and construct messages whose authorship will be attributed to the subject from which the private key has been stolen).

The fact that, in practice, attackers may operate on the endpoints is a huge practical problem that will not be considered in this course.

Practical considerations on the threat model (II)

In practical scenarios, a network attacker could have a subset of the abilities assumed here.

  • It could perform a subset of actions (for example only observe and not modify or discard).
  • It could operate on a subset of messages (for example only those between specific subjects, or only in one direction, or only those of a specific application protocol).
  • It could operate only at some time instants or time intervals.

On the other hand, subjects do not know whether a network attacker is present and what he can do. Furthermore, the presence of a network attacker is detected, if at all, after a long time.

It is easy to realize, thus, that secrecy, integrity and authentication guarantees can only be obtained by assuming that a network attacker with full capabilities is indeed present.

Insecure communication channel

Let C denote a communication channel where an attacker may be present. We aim at obtaining security properties on C by using cryptographic techniques.

Consider two subjects A and B that can communicate only through C.

Suppose A and B want to agree on a key K-AB for private key cryptography. There is no way for them to agree on a key without making that key potentially known to the attacker (C does not provide secrecy). Once the attacker knows K-AB, no security property can be obtained based on that K-AB.

Suppose B has a private-public key pair for public key cryptography and wants to “send its public key” to A (i.e., to send the association < B , KPUB-B >). There is no way to make sure that A receives the real association <B , KPUB-B> rather than a false association <B, KPUB-Attacker> (C does not provide integrity).

Once the attacker has convinced A that KPUB-Attacker is the public key of B, the attacker can:

  • Sign documents that A will validate as having been signed by B;
  • Decrypt messages that A will believe can be decrypted only by B;

In summary, obtaining security properties by communicating only on a channel that does not have these properties already is impossible, even by using cryptographic techniques.

Key exchange channel

We assume the existence of an additional communication channel CS with the following properties:

  • CS provides guarantees of secrecy, integrity, authentication.
  • CS may be used only for secure communication of keys.

Intuitively, CS is a channel that is secure but very costly. Thus, CS cannot be a replacement for C (of course, if subjects could exchange messages on CS then there would be no need of adding security guarantees to C: subjects would use CS).

The nature of CS is irrelevant and need not be the same for all pairs of subjects. In practical scenarios, CS could be a face to face meeting, a diplomatic courier or other forms of secure by definition channel.

Practical considerations on the key exchange channel

An implementation of the key exchange channel CS cannot provide secrecy, integrity, authentication with absolute and provable certainty against every possible threat model.

For example, CS could be implemented with a face to face meeting in which one of the two parties delivers to the other party a memory pen containing a key. An attacker that is capable of reading the content of the memory pen (either through a malware, or through a malware on some device of the company that fabricated the pen and so on) would be able to read that key thereby violating secrecy of CS.

CS must be implemented so that attacks are very costly for a broad and "pessimistic" range of threat models, i.e., even for very powerful attackers. However, it is impossible to prove that CS indeed provides the required security properties. One can only obtain a high degree of confidence on the fact that CS provides those properties even in the presence of attacks. The notion of degree of confidence cannot be quantified and is intrinsically different from a mathematical proof.

Once an implementation of CS is used in practice, CS is assumed to provide the required security properties: it provides secrecy, integrity and authentication by hypothesis.

Secure communication over an insecure channel

Let C and CS denote the communication channels described above. We aim at obtaining security properties on C by means of cryptographic techniques and keys exchanged on CS.

The protocols for key exchange and secure communication described below are strong oversimplifications of what needs to be done in real protocols. The corresponding issues are not considered in this course.

Private key cryptography

Two subjects A and B could obtain secrecy, integrity, authentication on C as follows:

  1. Choose a key K-AB on CS
  2. Communicate on C using K-AB, i.e., send each message m as EK-AB(m),MACK-AB(m).

Procedures of this kind are impractical because of step 1:

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

Satisfying these fundamental requirements in a scenario characterized by a very large and geographically distributed set of subjects is virtually impossible.

Procedures of this kind were the norm before the Internet and now are only used in very specific settings, usually characterized by a small set of subjects.

The Kerberos protocol is based on private key cryptography, allows handling large sets of subjects and is widely used in practice (it is the basis of Windows enterprise networks). Kerberos is not structured as above and is not studied in this course.

Public key cryptography

We assume that each subject has a public-private key pair and that different subjects have different key pairs.

Two subjects A and B could obtain secrecy, integrity, authentication on C as follows:

  1. Exchange the respective associations on CS
  2. Choose a key K-AB on C by means of public key cryptography (italic font indicates an encryption with public key cryptography):
    1. A selects half-key K1 and sends E_KPUB-B(K1) to B
    2. B selects half-key K2 and sends E_KPUB-A(K2) to A
    3. Each party decrypts the received message with the respective private key (i.e., the one of the public-private key pair) and constructs K-AB as the concatenation of K1 and K2.
  3. Communicate on C using K-AB, i.e., send each message m as E_K-AB(m),MAC_K-AB(m).

Note that step 1 must be executed on CS although it involves the exchange of public data. The reason is because the exchanged information must have integrity and authentication guarantees. If this step was executed on C, then the attacker could convince subjects to use wrong associations between subjects and public keys (the attacker could send <A, KPUB-Attacker> to B or <B, KPUB-Attacker> to A). At steps 2 and 3, thus, the attacker could communicate with A by pretending to be B and/or the other way around.

At step 2, each party proves to the other the knowledge of a private key: A proves to B that it is able to decrypt E_KPUB-A(K2); B proves to A that it is able to decrypt E_KPUB-B(K1). Thus, this step ensures mutual authentication based on public key cryptography.

This procedure is impractical because of step 1, for the same reasons discussed above with respect to private key cryptography: CS should exist between any pair of subjects; communication on CS should be sufficiently fast.

Remark: TLS in its default configuration assumes that only one of the two subjects has a private-public keypair. Here we have assumed instead that both subjects have a keypair. TLS is discussed in a later section in this document. The scenario assumed in this section corresponds to TLS with mutual authentication, i.e., both the client and the server authenticate the respective identity with cryptographic means. This configuration of TLS is non default and used rarely.

Validating digital signatures

A document is a sequence of bytes. A signed document is a document associated with a signature (a sequence of bytes of fixed length) and with the name of the signing subject. In practice, these three pieces of information are usually represented as a single byte sequence, for example a file. The corresponding protocol is irrelevant.

Let A be a subject that receives a signed document < D, F, Signed by=B>, where F denotes the signature. A validates the digital signature as follows:

  1. Obtain the public key of the signing subject B from CS (i.e., the association < B, KPUB-B>)
  2. Validate the signature with < D, F, KPUB-B>

Note that A receives the signed document on the insecure channel C.

Note that step 1 must be executed on CS although it involves the exchange of public data. The reason is because the exchanged information must have integrity and authentication guarantees. If this step was executed on C, then the attacker could convince A to use the association . The attacker could thus sign documents that A will believe have been signed by B: the attacker will sign with KPRIV-Attacker and the signature validation at step 2 will succeed.

This procedure is impractical because of step 1, for the same reasons discussed above: CS should exist between any pair of subjects; communication on CS should be sufficiently fast.

Hhmmm...how to distribute keys?

We have a very large and dynamic set of subjects, distributed worldwide and that may belong to many different organizations.

If each pair of subjects (that need to communicate between themselves) had a private key then the problem of secure communication over an insecure channel would be solved. But we do not know how to distribute such a private key.

If each subject knew the public key of every other subject (with which it needs to communicate) then the problem of secure communication over an insecure channel would be solved. And, authentication and integrity verifiable by any subject and over "long" time periods (digital signature) would be feasible. But we do not know how to distribute such public keys.

In the next document we will see how an additional assumption on the scenario allows solving the above problems.