A propos des signatures XML

Adobe AIR 1.5 et les versions ultérieures

Une signature XML est une signature numérique représentée en syntaxe XML. Les données d’une signature XML peuvent être utilisées pour garantir la non modification des informations signées depuis la signature. De plus, lorsqu’un certificat de signature a été publié par une autorité de certification approuvée, l’identité du signataire peut être vérifiée via l’infrastructure de clé publique.

Une signature XML peut être appliquée à n’importe quel type de données numériques (au format binaire ou XML). Des signatures XML sont généralement utilisées pour :

  • vérifier si des ressources externes ou téléchargées ont été modifiées ;

  • vérifier que des messages proviennent d’une source connue ;

  • valider les droits de licence d’une application ou les droits d’abonnement.

Syntaxe de signature XML prise en charge

AIR prend en charge les éléments suivants de la recommandation W3C portant sur la syntaxe et le traitement des signatures :

  • Tous les éléments de syntaxe de signature centraux (section 4 du document de la recommandation W3C uniquement), à l’exception de l’élément KeyInfo qui n’est pas entièrement pris en charge

  • L’élément KeyInfo ne doit contenir qu’un élément X509Data.

  • Un élément X509Data ne doit contenir qu’un élément X509Certificate.

  • La méthode digest SHA256

  • L’algorithme de signature RSA-SHA1 (PKCS1)

  • La méthode de canonisation « XML canonique sans commentaires » et l’algorithme de transformation

  • La transformation de la signature enveloppée

  • horodatage

Le document suivant présente une signature XML typique (la plupart des données cryptographiques ont été supprimées pour simplifier l’exemple) :

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
    <SignedInfo> 
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> 
        <Reference URI="URI_to_signed_data"> 
            <Transforms> 
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>            </Transforms> 
            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 
            <DigestValue>uoo...vY=</DigestValue> 
        </Reference> 
    </SignedInfo> 
    <SignatureValue>Ked...w==</SignatureValue> 
    <KeyInfo> 
        <X509Data> 
            <X509Certificate>i7d...w==</X509Certificate> 
        </X509Data> 
    </KeyInfo> 
</Signature>

Les éléments-clés d’une signature sont les suivants :

  • SignedInfo : contient les références aux données signées et les valeurs du digest calculé au moment de la signature. Les données signées elles-mêmes peuvent être incluses dans le même document que la signature XML ou peuvent être externes.

  • SignatureValue : contient un digest de l’élément SignedInfo chiffré avec la clé privée du signataire.

  • KeyInfo : contient le certificat de signature et tout certificat supplémentaire nécessaire pour établir la chaîne d’approbation. Notez que, bien que l’élément KeyInfo soit techniquement facultatif, AIR ne peut pas valider la signature s’il n’est pas inclus.

Il existe trois types généraux de signature XML :

  • Enveloppée : la signature est insérée dans les données XML signées.

  • Enveloppante : les données XML signées sont incluses dans un élément Object au sein de l’élément Signature.

  • Détachée : les données signées sont externes à la signature XML. Les données signées doivent être dans un fichier externe. Elles peuvent également être dans le même document XML que la signature, mais pas dans un élément parent ou enfant de l’élément Signature.

Pour référencer les données signées, les signatures XML utilisent des URI. Pour résoudre ces URI, les applications de signature et de validation doivent utiliser les mêmes conventions. Lorsque vous utilisez la classe XMLSignatureValidator, vous devez fournir une implémentation de l’interface IURIDereferencer. Cette implémentation est chargée de résoudre l’URI et de renvoyer les données signées sous forme d’objet ByteArray. Le digest de l’objet ByteArray renvoyé est calculé avec le même algorithme que celui qui a permis de calculer le digest de la signature.

Certificats et approbation

Un certificat est constitué d’une clé publique, d’informations d’identification et, éventuellement, d’un ou plusieurs certificats appartenant à l’autorité de certification émettrice.

Deux méthodes permettent d’établir la confiance d’un certificat. Vous pouvez établir la confiance en obtenant directement une copie du certificat auprès du signataire, par exemple sur un support physique, ou par l’intermédiaire d’une transmission numérique sécurisée, telle qu’une transaction SSL. Vous pouvez également vous appuyer sur une autorité de certification pour déterminer la fiabilité du certificat de signature.

Dans ce cas, le certificat de signature doit être publié par une autorité approuvée sur l’ordinateur sur lequel la signature est validée. La plupart des éditeurs de systèmes d’exploitation placent les certificats racine d’un certain nombre d’autorités de certification dans le magasin d’approbation du système. Les utilisateurs peuvent également ajouter et supprimer des certificats dans ce magasin.

Même si le certificat est publié par une autorité de certification approuvée, vous devez décider si le certificat appartient à une personne de confiance. Dans la plupart des cas, cette décision revient à l’utilisateur final. Par exemple, lors de l’installation d’une application AIR, le programme d’installation AIR affiche les informations d’identification du certificat de l’éditeur lorsqu’il invite l’utilisateur à indiquer s’il souhaite installer l’application. Dans d’autres cas, vous devrez peut-être comparer la clé publique ou d’autres informations de certificat à une liste de clés acceptables. (Cette liste doit être sécurisée, éventuellement par sa propre signature ou en étant stockée dans le magasin local chiffré d’AIR, de sorte que la liste elle-même ne puisse pas être altérée.)

Remarque : bien que vous puissiez choisir d’approuver le certificat de signature sans vérification indépendante (par exemple lorsque une signature est « auto-signée »), la vérification de la signature n’est pas suffisamment rassurante dans ce cas. Si vous ne connaissez pas l’auteur de la signature, la certitude que la signature n’a pas été modifiée n’a que peu de valeur. La signature peut être une contrefaçon signée.

Expiration et révocation des certificats

Tous les certificats arrivent à expiration à un moment donné. Les certificats peuvent également être révoqués par l’autorité de certification émettrice si, par exemple, la clé privée associée au certificat a été compromise ou volée. Si une signature est signée avec un certificat arrivé à expiration ou révoqué, elle est désignée comme non valide sauf si un horodatage a été inclus dans la signature. En présence d’un horodatage, la classe XMLSignatureValidator valide la signature si le certificat était valide au moment de la signature.

Un horodatage est un message numérique signé provenant d’un service d’horodatage qui certifie que les données ont été signées à une heure et une date spécifiques. Les horodatages sont publiés par des autorités d’horodatage et signés par le propre certificat de ces autorités. Le certificat de l’autorité d’horodatage intégré à l’horodatage doit être approuvé sur l’ordinateur en cours pour que cet horodatage soit considéré comme valide. L’objet XMLSignatureValidator ne fournit pas d’API pour désigner un autre certificat à utiliser pour valider l’horodatage.