Je suis assez nouveau en matière de sécurité de l'information. Et avant de passer à des choses plus spécifiques, je voulais demander si j'avais bien compris les trois principales parties d'IPsec: authenticité, confidentialité et intégrité.
Je me concentre ici sur les connexions VPN et le terme général des trois sujets. Je vais écrire ce que j'ai - jusqu'à présent - compris et j'espère que vous pourrez m'aider en corrigeant les fausses déclarations.
Peut-être quelques faits à l'arrière-plan de cette question. Je mettais en place un tunnel IPsec à des fins de test et je veux déclarer si j'ai bien compris toutes les parties. Donc, l'objectif général d'un tunnel IPsec (site à la fin/accès à distance) est, par exemple un utilisateur de bureau à domicile est en mesure de se connecter à un réseau d'entreprise et donc d'accéder aux ressources qui s'y trouvent. L'objectif principal d'IPsec est de fournir les trois objectifs d'authenticité, de confidentialité et d'intégrité. mais qu'est ce que ça veut dire?
Intégrité: L'intégrité est utilisée pour s'assurer que personne entre les sites A et B (par exemple) n'a modifié certaines parties des informations partagées. Par conséquent, un hachage est calculé et ajouté à un paquet. Cela peut être réalisé en utilisant des algorithmes de hachage comme MD5, SHA (1,2) et ainsi de suite. Pour vraiment vous assurer que personne ne peut même modifier les HMAC de hachage sont utilisés. Cela signifie code d'authentification de message haché. La principale différence entre un hachage et un hmac est qu'en plus de la valeur qui doit être hachée (somme de contrôle calculée), une phrase secrète commune aux deux sites est ajoutée au processus de calcul. Par exemple. [Valeur devant être hachée] + [phrase secrète] -> Valeur hachée de ces "deux" entrées. Voici ma première question: cela peut-il être comparé à un "sel"? Ou quelle est exactement la différence entre un HMAC et un Hash + Salt? Et qu'est-ce que le poivre, si un Hash + Salt est égal à un HMAC?
Confidentialité: La confidentialité est utilisée pour s'assurer que personne entre les sites A et B ne peut lire quelles données ou informations sont envoyées entre les sites. Pour ce faire, des algorithmes de chiffrement sont utilisés. Il existe deux types d'algorithmes de chiffrement, symétriques et asymétriques. Les algorithmes symétriques permettent le chiffrement et le déchiffrement avec la même clé. Avec des algorithmes asymétriques, vous devez utiliser différents types de clés: publiques et privées. La clé publique est souvent accessible au public tandis que la clé privée est uniquement disponible pour "vous-même" (si la paire de clés mentionnée est la vôtre). Tout ce que vous cryptez avec la clé publique ne peut être décrypté qu'avec la clé privée et vice versa. En matière de confidentialité, vous utilisez souvent des algorithmes symétriques comme DES, 3DES (tous deux obsolètes) ou AES. Le cryptage asymétrique est utilisé pour transférer une clé symétrique et également pour s'assurer que l'autre site est vraiment ce qu'il semble être (en ce qui concerne SSL/TLS).
Authenticité: Et cette dernière phrase de la partie confidentialité mène directement à la partie authenticité. L'authenticité est utilisée pour vous assurer que vous communiquez vraiment avec le partenaire que vous souhaitez. Pour atteindre ces différents types de techniques peuvent être utilisées, par ex. Clés pré-partagées configurées sur les deux sites , courbes elliptiques ou RSA en tant qu'algorithmes de clé publique/privée.
C'est la partie où je pense que j'ai mal compris beaucoup d'aspects. Parce que je ne suis pas sûr, où réside exactement différence entre authenticité et confidentialité, car les deux semblent se concentrer sur le dé/cryptage (sauf si vous utilisez un PSK pour l'authenticité). Et je sais que Diffie Hellman est utilisé lorsqu'il s'agit d'un tunnel IPsec. Pour autant que je sache, l'algorithme Diffie Hellman n'est pas un algorithme de chiffrement, mais il est utilisé pour transférer une clé de chiffrement/déchiffrement symétrique sur un réseau non sécurisé (comme Internet). DH fait-il donc partie de l'authenticité, car (par exemple) seuls les sites A et B sont capables de calculer et de transférer une clé symétrique? Mais comment cela prouve-t-il que par exemple le site B est vraiment le site B et non un attaquant?
Est-il exact que je peux comparer le processus RSA ou EC avec SSL/TLS à l'exception que SSL/TLS ajoute des certificats numériques avec signatures numériques (HMAC) en plus?
La différence entre l'authenticité et l'intégrité est la suivante:
Supposons que les parties A et B se parlent. L'authenticité signifierait que les messages reçus par A sont réellement envoyés par B. L'intégrité signifie que sur la route de B à A, le message n'a pas changé entre les deux.
En général, l'authenticité impliquerait l'intégrité mais l'intégrité n'impliquerait pas l'authenticité. Par exemple, le message peut conserver son intégrité mais il aurait pu être envoyé par C au lieu de B.
DH fait-il donc partie de l'authenticité, car (par exemple) seuls les sites A et B sont capables de calucléer et de transférer une clé symétrique? Mais comment cela prouve-t-il que par exemple le site B est vraiment le site B et non un attaquant?
DH ne fait pas partie du processus d'authentification. Dans SSL/TLS, vous utilisez les certificats des deux parties pour l'authentification. Après avoir authentifié les parties, vous partagez une clé secrète pour votre cryptage symétrique. Ces clés sont échangées à l'aide de l'échange de clés DH.
Gardez à l'esprit que l'authentification est différente de l'authenticité. L'authentification établit que vous parlez à B tandis que l'authenticité établit que le message provient réellement de B.
Et une dernière question à moi est, est-il exact que je peux comparer le processus RSA ou EC avec SSL/TLS à l'exception que SSL/TLS ajoute des certificats numériques avec signatures numériques (HMAC) en plus?
Je ne sais pas exactement ce que tu veux dire ici. RSA ou courbe éliptique sont des algorithmes utilisés pour le chiffrement asymétrique. SSL/TLS est une couche de communication.
Il semble qu'il y ait de bonnes réponses ici, mais permettez-moi d'expliquer la différence de disponibilité par rapport à l'authentification dans la triade CIA. Ce que le "A" signifie change avec le contexte.
L'authentification est utilisée si nous parlons de sécurité intégrée basée sur le matériel. Lorsque nous discutons des fonctions crypto-primitives d'un élément sécurisé ou d'un TPM complet, le "A" signifie "authentification".
La disponibilité est une construction de cybersécurité/sécurité de l'information (SI). Les systèmes "disponibles" visent à rester à la disposition des utilisateurs à tout moment, en prévenant ou en atténuant les interruptions de service dues aux pannes de courant (alimentation de secours), aux pannes matérielles (redondance), aux mises à niveau du système et aux attaques par déni de service.
La sécurité intégrée offre des informations à la cybersécurité, qui décide ensuite comment agir sur ces informations, mais tout impact sur la disponibilité de la sécurité intégrée est, au mieux, indirect. Par conséquent, parler de disponibilité lorsque vous discutez des fonctions basées sur le matériel, comme IPsec, est incorrect.
Je ne sais pas où réside la différence exacte entre authenticité et confidentialité
Vous pouvez signer du texte en clair, mettre sur votre site Web, et vous avez l'authenticité, mais pas la confidentialité. Votre signature atteste que vous avez signé ce texte (authenticité), mais tout le monde peut le lire (pas de confidentialité).
D'un autre côté, vous pouvez inscrire quelque chose avec ma clé publique, l'envoyer à moi et personne d'autre que moi ne peut lire les données (confidentialité), mais je ne peux pas savoir qui m'a envoyé les données ou si quelqu'un a intercepté le message et envoyé un autre un à sa place (pas d'authenticité).
DH fait-il donc partie de l'authenticité, car (par exemple) seuls les sites A et B sont capables de calculer et de transférer une clé symétrique?
DH n'est pas une question d'authenticité, mais de partage d'une clé sur un réseau non sécurisé.
Mais comment cela prouve-t-il que par exemple le site B est vraiment le site B et non un attaquant?
Cette preuve est en dehors de la connexion, elle est entre les mains de l'AC, l'autorité de certification. L'AC est celle qui a signé le certificat du site B et atteste que vous lisez le certificat du site B. Chaque autorité de certification est liée par des règles les empêchant de créer un certificat pour le site B et de le donner au site C. De temps en temps, une autorité de certification enfreint ces règles et finit par être expulsée du marché ( DigiNotar , par exemple).
Est-il exact que je peux comparer le processus RSA ou EC avec SSL/TLS à l'exception que SSL/TLS ajoute des certificats numériques avec signatures numériques (HMAC) en plus?
Non, c'est incorrect. SSL/TLS peut utiliser RSA et EC pour crypter les données, mais pas seulement RSA ou EC. Vous pouvez configurer SSL pour utiliser Rot-13 ou 1 octet XOR comme algorithme de chiffrement, rien sur le protocole ne vous empêche de le faire, même si ce serait un choix très, très mauvais.