Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le canal homologue permet un large éventail de types d’applications distribuées qui dépendent de la messagerie multipartie. Certains exemples incluent la distribution de contenu à l’échelle Internet, où une source approuvée distribue du contenu (comme les médias ou les mises à jour logicielles), un groupe d’amis échangent de la musique et des photos, ou une équipe de collègues modifient un document en collaboration. Chacun de ces scénarios nécessite un modèle de sécurité unique. Le modèle de sécurité du canal homologue est conçu pour répondre à ces scénarios et fournit un modèle de sécurité robuste adapté aux besoins des divers modèles d'identité, d'authentification et d'autorisation.
Scénarios de sécurité
Un scénario de distribution de contenu nécessite que chaque destinataire de contenu identifie la source de contenu. En raison de la nature distribuée du scénario, il n’est pas toujours possible de connaître et de faire confiance aux intermédiaires qui traitent ou interceptent les messages. Pour atténuer efficacement la menace qu’un intermédiaire non approuvé peut falsifier les messages, les applications peuvent sécuriser le message à l’expéditeur afin que toutes les tentatives de falsification soient facilement détectées. Dans ce cas, en fonction de la confidentialité du contenu, le chiffrement peut être nécessaire.
Les scénarios de collaboration tels que la collaboration de documents de groupe nécessitent souvent que chaque membre participant à la session soit identifié individuellement et authentifié. Cela signifie qu’un mécanisme permettant de définir des groupes d’utilisateurs et de s’authentifier auprès de ces groupes est nécessaire pour disposer d’une session sécurisée. De plus, les applications peuvent nécessiter le suivi de chaque message par authentification au niveau du message. Dans ces types d’applications, les performances peuvent être sacrifiées pour un schéma de sécurité plus fort.
Une session de communication entre un groupe d’utilisateurs occasionnels peut nécessiter des modèles de sécurité informels, comme la connaissance d’un secret commun au sein du groupe. Pour ces types d’applications, avoir un modèle de sécurité pratique pour établir et configurer est plus important que d’avoir la forme d’authentification la plus forte ou de fournir des mesures de non-répudiation. Pour ces scénarios, un mécanisme d’authentification basé sur un mot de passe permet de sécuriser la couche de communication tout en autorisant l’authentification des messages. La sécurité par mot de passe est le paramètre par défaut pour le canal pair-à-pair.
Types de jetons
Le canal homologue reconnaît un seul type de jeton pour les certificats d'identification X.509 puissants qui fournissent un modèle d'identité performant basé sur le type d'authentification et d'autorisation qui peut être implémenté. La confidentialité et l’intégrité sont facilement fournies à l’aide de certificats. Toutefois, les certificats X.509 peuvent être difficiles à utiliser et à déployer.
Peer Channel prend également en charge les applications simples avec des mots de passe. Les applications peuvent choisir de configurer des groupes homologues rapides et simples en fonction d’un mot de passe fourni. Dans ce cas, un propriétaire de groupe décide et communique le mot de passe aux membres. Chaque membre doit se connecter à l’aide de ce mot de passe avant de pouvoir rejoindre la session. Les mots de passe ne peuvent être utilisés que pour autoriser l’entrée à la session ; ils ne peuvent pas être utilisés pour effectuer l’authentification des messages. Cela est dû au fait qu’un jeton symétrique qu’un groupe d’homologues partage est difficile et inapproprié à utiliser pour l’authentification source.
Modèle de sécurité
Le canal entre pairs permet de sécuriser les liens entre pairs. Cela signifie qu’un message ne circule jamais sur un lien non sécurisé (du point de vue de l’application). En interne, chaque lien (un canal de transport entre deux homologues) est sécurisé à l’aide du protocole TLS (Transport Layer Security). Cela signifie que lorsqu’un expéditeur compose et envoie un message, il est envoyé via un transport sécurisé à chacun de ses homologues immédiats, qui accèdent au message, puis envoient le message à leurs homologues immédiats via des connexions sécurisées. Cette sécurité fonctionne uniquement au niveau du transport et est indépendante des modèles de sécurité des messages.
Peer Channel offre également un moyen de sécuriser les messages indépendamment de la sécurité du transport utilisée. Dans ce modèle, le message est sécurisé à la source à l’aide du jeton de sécurité de la source, bien que seuls les certificats X.509 soient actuellement pris en charge. Le message sécurisé est ensuite transmis sur le réseau homologue. Chaque homologue de réception peut vérifier l’authenticité de la source. Notez que le message est sécurisé afin que les intermédiaires ne puissent pas les falsifier.
Pour obtenir la confidentialité, les applications peuvent utiliser la sécurité du transport avec des schémas d’appartenance de groupe forts pour empêcher l’accès non autorisé au message.
Le canal homologue ne requiert pas de modèle d'identité spécifique tant que l'application choisit l'un des types de jetons pris en charge. Les applications possèdent complètement le cycle de vie de ces identités et décisions d’authentification.