2. The Goals of Security (Objectifs de la sécurité)

Beaucoup de personnes parlent de la sécurité comme s'il s'agissait d'une propriété monolithique unique d'un protocole ou d'un système ; à la réflexion, il est clair que ce n'est pas le cas. La sécurité est plutôt une série de propriétés liées mais quelque peu indépendantes. Toutes ces propriétés ne sont pas requises pour chaque application.

On peut diviser approximativement les objectifs de sécurité en ceux qui concernent la protection des communications (COMMUNICATION SECURITY, aussi appelée COMSEC) et ceux qui concernent la protection des systèmes (ADMINISTRATIVE SECURITY ou SYSTEM SECURITY). Comme les communications sont effectuées par des systèmes et que l'accès aux systèmes passe par des canaux de communication, ces objectifs s'emboîtent évidemment, mais peuvent aussi être fournis indépendamment.

2.1. Communication Security

Les auteurs divisent différemment les objectifs de la sécurité des communications. Le partitionnement que nous avons jugé le plus utile consiste à les répartir en trois grandes catégories : CONFIDENTIALITY, DATA INTEGRITY et PEER ENTITY AUTHENTICATION.

2.1.1. Confidentiality

Lorsque la plupart des gens pensent à la sécurité, ils pensent à la CONFIDENTIALITY. La confidentialité signifie que vos données sont tenues secrètes à l'égard d'auditeurs non intentionnels. Habituellement, ces auditeurs sont simplement des écouteurs clandestins. Lorsqu'un adversaire met sur écoute votre téléphone, cela pose un risque pour votre confidentialité.

Évidemment, si vous avez des secrets, vous vous souciez probablement que d'autres ne les découvrent pas. Ainsi, vous souhaitez au minimum maintenir la confidentialité. Lorsque les espions au cinéma vont dans la salle de bain et ouvrent toute l'eau pour contrer les micros cachés, la propriété qu'ils recherchent est la confidentialité.

2.1.2. Data Integrity

Le second objectif principal est la DATA INTEGRITY. L'idée de base est que nous voulons nous assurer que les données que nous recevons sont les mêmes que celles que l'expéditeur a envoyées. Dans les systèmes papier, une certaine intégrité des données vient automatiquement. Lorsque vous recevez une lettre écrite à l'encre, vous pouvez être assez certain qu'aucun mot n'a été retiré par un attaquant, car les traces d'encre sont difficiles à enlever du papier. Cependant, un attaquant aurait pu facilement ajouter des marques sur le papier et changer complètement le sens du message. De même, il est facile de raccourcir la page pour tronquer le message.

En revanche, dans le monde électronique, comme tous les bits se ressemblent, il est trivial de falsifier des messages en transit. Il suffit de retirer le message du fil, de copier les parties que l'on aime, d'ajouter les données voulues et de générer un nouveau message au choix, sans que le destinataire ne s'en aperçoive. C'est l'équivalent moral de l'attaquant qui prend une lettre que vous avez écrite, achète du papier neuf et recopie le message en le modifiant. C'est simplement beaucoup plus facile à faire électroniquement, car tous les bits se ressemblent.

2.1.3. Peer Entity authentication

La troisième propriété qui nous intéresse est la PEER ENTITY AUTHENTICATION. Nous entendons par là que nous savons que l'une des extrémités de la communication est celle que nous avions l'intention d'atteindre. Sans authentification de pair, il est très difficile d'assurer la confidentialité ou l'intégrité des données. Par exemple, si nous recevons un message d'Alice, la propriété d'intégrité des données ne nous sert pas à grand-chose si nous ne savons pas qu'il a en fait été envoyé par Alice et non par l'attaquant. De même, si nous voulons envoyer un message confidentiel à Bob, cela ne nous sert pas à grand-chose si nous envoyons en réalité un message confidentiel à l'attaquant.

Notez que l'authentification de pair peut être fournie de manière asymétrique. Lorsque vous appelez quelqu'un au téléphone, vous pouvez être assez certain d'avoir la bonne personne, ou du moins une personne qui se trouve réellement au numéro que vous avez composé. En revanche, s'ils n'ont pas l'identification de l'appelant, le destinataire d'un appel téléphonique ne sait pas qui l'appelle. Appeler quelqu'un au téléphone est un exemple d'authentification du destinataire, car vous savez qui est le destinataire de l'appel, mais ils ne savent rien sur l'émetteur.

Dans les situations de messagerie, on souhaite souvent utiliser l'authentification de pair pour établir l'identité de l'émetteur d'un certain message. Dans de tels contextes, cette propriété est appelée DATA ORIGIN AUTHENTICATION.

2.2. Non-Repudiation

Un système qui fournit l'authentification d'extrémité permet à une partie d'être certaine de l'identité de quelqu'un avec qui elle communique. Lorsque le système fournit l'intégrité des données, un récepteur peut être sûr à la fois de l'identité de l'émetteur et qu'il reçoit les données que cet émetteur entendait envoyer. Cependant, il ne peut pas nécessairement démontrer ce fait à un tiers. La capacité à faire cette démonstration s'appelle NON-REPUDIATION.

Il existe de nombreuses situations où la non-répudiation est souhaitable. Considérez la situation où deux parties ont signé un contrat dont une souhaite le rompre unilatéralement. Elle pourrait simplement prétendre ne l'avoir jamais signé en premier lieu. La non-répudiation l'empêche de le faire, protégeant ainsi la contrepartie.

Malheureusement, la non-répudiation peut être très difficile à réaliser en pratique et les approches naïves sont généralement inadéquates. La section 4.3 décrit certaines des difficultés, qui découlent en général du fait que les intérêts des deux parties ne sont pas alignés : une partie souhaite prouver ce que l'autre souhaite nier.

2.3. Systems Security

En général, la sécurité des systèmes concerne la protection des machines et des données. L'intention est que les machines ne soient utilisées que par des utilisateurs autorisés et aux fins que les propriétaires entendent. De plus, elles DOIVENT être disponibles à ces fins. Les attaquants ne DOIVENT pas pouvoir priver les utilisateurs légitimes de ressources.

2.3.1. Unauthorized Usage

La plupart des systèmes ne sont pas destinés à être entièrement accessibles au public. Ils sont plutôt destinés à n'être utilisés que par certaines personnes autorisées. Bien que de nombreux services Internet soient disponibles à tous les utilisateurs d'Internet, même ces serveurs offrent généralement un sous-ensemble plus large de services à des utilisateurs spécifiques. Par exemple, les serveurs Web servent souvent des données à tout utilisateur, mais restreignent la possibilité de modifier des pages à des utilisateurs spécifiques. De telles modifications par le grand public constitueraient une UNAUTHORIZED USAGE.

2.3.2. Inappropriate Usage

Être un utilisateur autorisé ne signifie pas que vous avez toute latitude sur le système. Comme indiqué ci-dessus, certaines activités sont réservées aux utilisateurs autorisés, certaines à des utilisateurs spécifiques, et certaines activités sont en général interdites à tous sauf aux administrateurs. De plus, même les activités généralement autorisées peuvent être interdites dans certains cas. Par exemple, les utilisateurs peuvent être autorisés à envoyer des courriels mais interdits d'envoyer des fichiers au-dessus d'une certaine taille, ou des fichiers contenant des virus. Ce sont des exemples d'INAPPROPRIATE USAGE.

2.3.3. Denial of Service

Rappelons que notre troisième objectif était que le système soit disponible pour les utilisateurs légitimes. Une grande variété d'attaques peut menacer une telle utilisation. De telles attaques sont collectivement appelées attaques par DENIAL OF SERVICE. Les attaques par déni de service sont souvent très faciles à monter et difficiles à arrêter. Beaucoup sont conçues pour consommer les ressources de la machine, rendant difficile ou impossible de servir les utilisateurs légitimes. D'autres attaques font planter la machine cible, refusant complètement le service aux utilisateurs.