authenticity, confidentiality & integrity - general questions

Question

I am pretty new when it comes to information security. And before I move on with more specific things I wanted to ask if I understood the three main parts of IPsec correctly: authenticity, confidentiality & integrity.

My focus here lays on VPN connections and the general term of the three topics. I am going to write down what I - so far - understood and hope that you can help me by correcting wrong statements.

Maybe some facts to the background of this question. I was setting up an IPsec tunnel for test purposes and want do declare if I understood all parts correctly. So the general purpose of an IPsec (site to end / remote access) tunnel is, that e.g. a home office user is able to connect to a company network and therefore access resources that are located within this. The main focus of IPsec is to provide the three purposes of authenticity, confidentiality & integrity. But what does this mean?

Integrity: Integrity is used to make sure that nobody in between site A and B (for example) changed some parts of the shared information. Therefore a hash is calculated and added to a packet. This can be achieved by using hashing algorithms like MD5, SHA(1,2) and so on. To really make sure that no one is even able to modify the hash HMACs are used. This stands for hashed message authentication code. The main difference between a hash and a hmac is that in addition to the value that should be hashed (checksum calculated) a secret passphrase that is common to both sites is added to the calculation process. E.g. [Value that should be hashed] + [secret passhrase] -> Hashed value of this "two" inputs. Here comes my first question: Can this be compared with a "salt"? Or what exactly is the difference between a HMAC and a Hash + Salt? And what is Pepper, if a Hash + Salt equals a HMAC?

Confidentiality: Confidentiality is used to make sure that nobody in between site A and B is able to read what data or information is sent between the to sites. To achieve this encryption algorithms are used. There are two kinds of encryption algorithms, symmetric and also asymmetric ones. Symmetric algorithms allow encryption and decryption with the same key. With asymmetric algorithms you have to kinds of keys: a public one and also a private one. The public key is often available to the public while the private key is just available for "yourself" (if the mentioned keypair is yours). Everything that you encrypt with the public key can only be decrypted with the private one and vice versa. When it comes to confidentiality you often just use symmetric algorithms like DES, 3DES (both outdated) or AES. Asymmetric encryption is used to transfer a symmetric key and also to make sure that the other site is really who it seems to be (when it comes to SSL/TLS).

Authenticity: And this last sentence of the confidentiality part leads directly to the authenticity part. Authenticity is used to make sure that you really communicate with the partner you want to. To achieve these different kinds of techniques can be used, e.g. Pre-shared keys that are configured on both sites, Elliptic Curves or RSA as public/private key algorithms.

This is the part where I think that I misunderstood lots of aspects. Because I am not sure, where the exact difference between authenticity and confidentiality lays, as both seem to focus on de/encryption (except if you are using a PSK for authenticity). And I know that Diffie Hellman is used when it comes to an IPsec tunnel. As far as I know the Diffie Hellman algorithm is not an encryption algorithm, but it is used to transfer a symmetric encryption/decryption key over an unsecured network (like the internet). So is DH part of authenticity, because (e.g.) only site A and B are able to calculate and transfer a symmetric key? But how does this prove that e.g. site B is really site B and not an attacker?

Is it correct that I can compare the RSA or EC process with SSL/TLS with the exception that SSL/TLS adds digital certificates with digital signatures (HMACs) in addition?

Answer 1

The difference between authenticity and integrity is this:

Suppose party A and B are talking to each other. Authenticity would mean that messages received by A are actually sent by B. Integrity means that on the route from B to A, the message has not changed in between.

In general, authenticity would imply integrity but integrity wouldn't imply authenticity. For example, the message may retain its integrity but it could have been sent by C instead of B.

So is DH part of authenticity, because (e.g.) only site A and B are able to caluclate and transfer a symmetric key? But how does this prove that e.g. site B is really site B and not an attacker?

DH is not part of the authentication process. In SSL/TLS you use the certificates of both parties for authentication. After you have authenticated the parties, you share a secret key for your symmetric encryption. This keys are exchanged using DH key exchange.

Keep in mind that authentication is different from authenticity. Authentication is establishing that you are talking to B while authenticity is establishing that the message actually came from B.

And a last question of mine is, is it correct that I can compare the RSA or EC process with SSL/TLS with the exception that SSL/TLS adds digital certificates with digital signatures (HMACs) in addition?

I am not sure what exactly do you mean here. RSA or eliptic curve are algorithms that are used for asymmetric encryption. SSL/TLS is a communication layer.

Answer 2

Looks like there are good answers here, but let me elaborate on the difference of availability versus authentication in the CIA triad. What the "A" stands for changes with context.

Authentication is used if we talk about hardware-based embedded security. When we discuss the crypto primitive functions of a secure element or a full TPM, the "A" stands for "authentication".

Availability is a cybersecurity/information-security(IS) construct. "Available" systems aim to remain available to users at all times, preventing or mitigating service disruptions due to power outages (power backup), hardware failures (redundancy), system upgrades and denial of service attacks.

Embedded security offers information to cybersecurity, which then decides how to act on that information, but any impact on availability from embedded security is, at very best, indirect. Therefore, talking about availability when discussing hardware-based functions, like IPsec, is incorrect.

Answer 3

I am not sure, where the exact difference between authenticity and confidentiality lays

You can sign some plaintext, put on your website, and you have authenticity, but not confidentiality. Your signature attests that you signed that text (authenticity), but everyone can read it (no confidentiality).

On the other hand, you can encript something with my public key, send it to me, and nobody but me can read the data (confidentiality), but I cannot know who sent me the data or if someone intercepted the message, and sent another one in its place (no authenticity).

So is DH part of authenticity, because (e.g.) only site A and B are able to calculate and transfer a symmetric key?

DH is not about authenticity, but about sharing a key over an insecure network.

But how does this prove that e.g. site B is really site B and not an attacker?

This proof is outside of the connection, it's on the hands of the CA, the Certificate Authority. The CA is the one who signed Site B certificate and attests that you are reading Site B certificate. Every CA is bound by rules preventing them from creating a certificate for Site B and giving it to Site C. From time to time a CA breaks this rules, and end up being evicted from the market (DigiNotar, for example).

Is it correct that I can compare the RSA or EC process with SSL/TLS with the exception that SSL/TLS adds digital certificates with digital signatures (HMACs) in addition?

No, it's incorrect. SSL/TLS can use RSA and EC to encrypt data, but not only RSA or EC. You can configure SSL to use Rot-13 or 1-byte XOR as encryption algorithm, nothing on the protocol stops you from doing that, even if that would be a very, very poor choice.