Signature numérique XML
La syntaxe et le traitement de signature XML (signature XML) est une spécification qui définit les règles de traitement et de syntaxe XML pour la signature et la vérification des signatures numériques de contenu numérique. La spécification a été développée conjointement par W3C (World Wide Web Consortium) et IETF (Internet Engineering Task Force).
La signature XML n'intègre pas de nouveaux algorithmes de chiffrement. WebSphere Application Server utilise la signature XML avec des algorithmes existants, tels que RSA, HMAC et SHA1. La signature XML définit un grand nombre de méthodes de description des informations clé et active la définition d'une nouvelle méthode.
- <person first="John" last="Smith"/>
- <person last="Smith" first="John"></person>
C14n est un processus permettant de placer sous forme canonique les informations XML. Sélectionnez un algorithme c14n car les informations placées sous forme canonique dépendent de cet algorithme. Un des algorithmes principaux c14n, Exclusive XML Canonicalization, place sous forme canonique le schéma de codage de caractères, l'ordre des attributs, les déclarations d'espace de nom, etc. L'algorithme ne canonise pas les espaces se trouvant hors des balises, les préfixes d'espace de nom ou la représentation du type de données.
Signature XML dans la spécification WSS-Core (Web Services Security-Core)
La spécification WSS-Core (Web Services Security-Core) définit une manière standard d'intégration d'une signature XML à des messages SOAP (Simple Object Access Protocol). Vous pouvez utiliser quasiment l'ensemble des fonctions de signature XML de WSS-Core sauf la signature enveloppée et la signature d'enveloppement. Toutefois, WSS-Core comporte certaines recommandations, telles que la canonisation exclusive de l'algorithme c14n et certains fonctions supplémentaires, telles SecurityTokenReference et KeyIdentifier. Le KeyIdentifier correspond à la valeur de la zone SubjectKeyIdentifier dans le certificat X.509. Pour plus d'informations sur l'élément KeyIdentifier, voir “Reference to a Subject Key Identifier” dans la documentation OASIS Web Services Security X.509 Certificate Token Profile documentation.
- Intégrité du message
- Un destinataire de message peut confirmer que les attaques ou les accidents n'ont pas modifié les éléments du message une fois que ces éléments ont été signés par une clé.
- Authentification
- Vous pouvez supposer qu'une signature valide est une preuve de possession. Un message avec un certificat numérique émis par une autorité de certification et une signature du message dont la validation effectuée par une clé publique dans le certificat a abouti, est preuve que le signataire possède la clé privée correspondante. Le destinataire peut authentifier le signataire en vérifiant la fiabilité du certificat.
Signature XML dans l'implémentation en cours
La signature XML est prise en charge dans la sécurité de Services Web. Toutefois, une API (Application Programming Interface (API) n'est pas disponible. L'implémentation en cours a des comportements définis dans le code et certains éléments de configuration définis par l'utilisateur. Pour configurer le client pour la signature numérique, voir Configuration du client pour la vérification des signatures numériques : Vérification des parties de message. Pour configurer le serveur pour la signature numérique, voir Configuration du serveur pour la vérification des signatures numériques des requêtes : Vérification des parties de message.
Remarques sur la sécurité :
Dans une attaque de réexécution, la personne à l'origine de l'attaque entre les lignes, reçoit un message signé et renvoie le message au destinataire. Dans ce cas, le destinataire reçoit deux fois le même message et peut traiter les deux messages si les signatures sont valides. Le traitement de ces deux messages peut provoquer des dommages au niveau du destinataire si le message constitue une demande de paiement. Si vous possédez l'horodatage de génération signé et l'heure d'expiration signée dans une réexécution de message, les attaques peuvent être réduites. Toutefois, il ne s'agit pas d'une solution complète. Un message doit comporter une valeur nonce afin d'empêcher ces attaques et le destinataire doit rejeter un message qui contient une valeur nonce traitée. L'implémentation en cours ne fournit pas de façon standard de générer et de vérifier des valeurs nonce dans les messages. Dans WebSphere Application Server, version 5.1, la valeur nonce est prise en charge dans les jetons nom d'utilisateur uniquement. Le profil de jeton nom d'utilisateur contient des scénarios de syntaxe de valeur nonce concrets pour les jetons nom d'utilisateur. Les applications gèrent des valeurs nonce (telles que des numéros de série) et elles doivent être signées.