- 0 Discussion
-
ce wiki
Accueil
|
Sommaire |
Aperçu
Modifier
Le projet FenrirMorphSign vise à fournir aux standards de signature existants des possibilités morph :"signer une fois, distribuer plusieurs versions". Ce modèle permet à n'importe quelle entité qui a déjà reçu un document signé auprès d'un Certificate Authority de pouvoir masquer des parties autorisées dans ce document, en utilisant la même signature originale sans aucune intervention du CA. Autrement dit, cette caractéristique "morph" permet à un distributeur de gérer des documents, tels que le masquage ou non de parties sensibles selon le contexte
Nous aimerions, cependant, mettre en application notre projet en ajoutant ces fonctionnalités avec un changement minimal des technologies existantes. La première version de l'api "Fenrir MorphSign" a été avec succès intégrée à l'implémentation de MONO du standard XMLDSig.
La caractéristique principale de notre approche est le "morph template". Il définit quelles parties du document pourraient être masquées. Ainsi, nous espérons permettre un accès facile à notre approche en soumettant le projet en ligne pour être adopté par la communauté libre.
Notre schéma de signature pourrait être enrichi de ce fait pour s'adapter à un grand type de documents, par exemple les certificats (X509 :avec la syntaxe d'ASN, SPKI avec l'X-Expression), images (bmp), films etc.....
IntroductionModifier
De nos jours, l’informatique a atteint une dimension planétaire et touche un large public amené à véhiculer et traiter un très grand nombre d’informations et de données. Ainsi, l'interaction entre un utilisateur et son environnement devient de plus en plus pervasive. En effet, les transactions commerciales et les publications (par exemple les virements bancaires, les factures, les livres, les journaux, etc.…) alors basées sur les documents papier migrent progressivement vers une version électronique principalement pour des raisons économiques et écologiques
La signature digitale est particulièrement importante dans ces types de transaction pour établir une certaine confiance dans l’interaction au sein d'une communauté virtuelle telle que l’Internet. En fait, elle peut être utilisée pour vérifier que l’authenticité et l’intégrité des données sont maintenues, c'est-à-dire que les données n’ont pas été modifiées depuis qu’elles ont été signées (s'assurer que le contenu original est intact). Cependant, dans certains cas, la modification des données n’est pas seulement permise mais désirée. L’on peut ainsi par souci de protection de sa vie privée vouloir cacher quelques informations sensibles d’un document préalablement signé. Le mécanisme de signature numérique tel que défini actuellement n’est pas approprié pour permettre la vérification de l’intégrité du document modifié. Nous utilisons le modèle Producteur-Distributeur-Consommateur (PDC) (voir le schéma ci-contre) pour illustrer l'inflexibilité et la faiblesse du mécanisme standard de signature.
Ajoutée par AkanniDans cet exemple le producteur est l'auteur du document. Le distributeur représente le rédacteur du document, il est mandaté par le producteur pour éditer et distribuer son document ou manuscrit. Le consommateur est le dernier acteur de la chaîne, il représente le lecteur qui acquiert et lit la distribution finale du document
.
Dans ce modèle le producteur signe son manuscrit pour montrer qu'il en est l'auteur. Puis le distributeur, tout comme "Springer", "ACM" ou "IEEE" s'occupe de fournir le document à la communauté en conservant la signature de l’auteur. Le distributeur veut fournir plusieurs versions du document original en les adaptant au contexte de la transaction (par exemple le prix) sans modifier signature originale de l’auteur. En conséquence le consommateur ou le lecteur peut choisir (ou acheter) des parties dont il a besoin du document et vérifier la signature de l'auteur même si le document n'est pas complet.
Notre travail vise alors à fournir au standard de signature existant (XMLDsig) la morph possibilité :"signer une fois, distribuer plusieurs". Ce modèle permet n'importe quelle entité qui a déjà acquis un document signé auprès d'une Autorité de Certification (CA) de pouvoir modifier certaines parties autorisées du document en gardant la signature originale intacte sans aucune intervention du CA. Pour cela, nous avons implémenté une API basée sur le standard XMLDsig; et pour permettre un accès facile à notre approche, nous l’avons soumis en ligne espérant qu’elle soit adoptée par la communauté libre et soit enrichie pour exécuter un grand type de documents.
Mécanisme de signature MorphModifier
L’objectif ici est de définir un modèle flexible de signature numérique. Elle est inspirée des standards de W3C :"XML Digital Signature"(XMLDSig). Cette signature est conçue pour une rentabilité distribuée.
Toutes les signatures standards emploient un algorithme de hachage pour obtenir la valeur résiduelle des données de document. Cette valeur est signée par une clef privée du producteur de document. En conséquence si le contenu est modifié, le résultat résiduel sera incorrect. Dans ce cas, le distributeur ne pourra pas adapter ses documents à certaines situations données en masquant ou en cachant d’information autorisée.
Il est alors défini dans ce modèle une méthode spécifique de signature utilisant des tags spécifiques ; le distributeur pourra contrôler et fait adapter le document selon une transaction spécifique (par exemple prix coût) (voir le schéma 1). Ainsi certaines parties autorisées du document pourront être librement masqué ou cacher par le distributeur sans solliciter l’intervention du producteur. De cette manière, le consommateur possédera un sous-document de l'original, qui contiendra seulement la partie nécessaire pour sa transaction.
Le certificat X316, conçu pour utiliser ce type de signature numérique, permettra alors à son détenteur de pouvoir masquer ou cacher certaines informations jugées non utiles à volonté pour une transaction donnée et ce, selon le contexte dans lequel il se trouve et sans intervention de l’autorité de certification qui le lui a délivré. (Voir fig. ci-contre)
Ceci étant, le défi est : Comment chaque distributeur peut-il adapter son document statique selon le contexte d’une transaction?
Pour résoudre ce problème, nous devons distinguer la partie dynamique de la partie statique.
- Les parties statiques : composées d’'informations obligatoires et non supprimables (ex : le titre du document, des auteurs…).Installation de ces données l'identité du document.
- Les parties dynamiques : représentent la partie démontable telle que les chapitres de document, les sections, etc.…
- Pour exécuter l'algorithme de signature de numérique morph, toutes les parties dynamiques dans le document doivent être définies.
Définition du Morph TemplateModifier
La Morph Template est définie pour faciliter et pour standardiser la Morph Signature. Ainsi l'objectif de cette spécification est de proposer un format pour le Morph Template qui réponde aux besoins suivants :
- Portabilité et indépendance à toute plateforme, car destiner à un large spectre de machine et de systèmes différents
- Le format doit aussi être extensible et généraliste
- Indépendance au format du fichier sur lequel on cherche à appliquer le template
Pour répondre à ces différents objectifs, le format proposé utilise le langage XML, principalement pour des raisons de portabilité et d'intégration avec les formats de signature XMLDSig. En effet, presque tous les supports multimédia sont formatés pour exprimer une structure régulière et un contenu sémantique. Quelques standards ont émergé comme : XML, HTML OpenDocument, OOXML, Mpeg7 etc.…Toutes ces normes sont conçues pour organiser des parties de document d'une façon bien formée. De la même manière, nous définissons le Morph Template pour exécuter le processus de signature morph pour une grande portée de formats de document.
Le morph template se compose de deux sections : le type du document et la section dynamique.
- Le type de document : La signature morph devra être calculée en tout type de documents (XML ou tout autre format). Cette section indique le type du document signé. Cette information est cruciale car elle définit comment le document sera parsé.
- Les attributs dynamiques : Cette section définit les parties dynamiques du document signé.
Par exemple, dans le format latex, "sous-section" et "subsubsection" sont considérés comme étant des parties dynamiques ; pour les documents XML, les parties dynamiques peuvent être les éléments < DP >.
La signature morph a comme entrées le document et le template correspondant. Elle analyse le template pour identifier les parties dynamiques.
Un Template se compose donc de deux parties distinctes. La première, délimitée par la balise <Header>, sert à spécifier les différents paramètres passés à l'algorithme. La seconde partie sert à définir les différentes parties dynamiques.
Scénario du Morph TemplateModifier
Il est défini une nouvelle méthode de signature permettant une adaptation contextuelle d’un document. Conformément au modèle PDC, la signature morph basée sur un template prédéfini est calculée comme suit:
- Signature du Producteur
- Adaptation du Distributeur
- Vérification du Consommateur.
- Signature du Producteur
Quand un document est soumis à une conférence, sa structure doit être formatée selon le template de la conférence.
De même, un Template peut être défini par le producteur ou par le distributeur pour formater le document. Ce template définit le type de section ou le type d'expression à hacher. Il choisit automatiquement la partie DP avant de produire de la signature morph.
Le producteur récupère le template de son distributeur. Ainsi le manuscrit peut être signé juste une fois avec la clef privée du producteur selon les conditions du distributeur.
- Adaptation du Distributeur
Le distributeur peut fournir différentes versions du manuscrit du producteur. Selon le template défini, il peut fournir quelques versions de document sans solliciter systématiquement le producteur pour signer chacune de ces versions.
- Vérification Du Consommateur.
Le consommateur peut vérifier la validité de n'importe quelle version du document fourni. En fait, la signature est la même pour toutes les versions excepté quelques parties résiduelles qui doivent être ajoutées à droite du document avant de vérifier la signature morph.
L'algorithme MorphSignatureModifier
Afin de calculer la signature morph, deux balises doivent être définies:
- Balise DPDigest : contient la valeur de hash correspondant aux parties dynamiques qui ont été définies dans le template.
- balise FloatPart : contient toutes les parties DPDigest et leurs positions dans le document original. Le champ ‘position’ est obligatoire pour reconstruire le morph Body afin de vérifier la signature.
Nous appliquons un nouvel algorithme pour produire un document morphable comme suit (voir figure ci-contre):
- transformer la source B en un Morph Body MB, en remplaçant toutes les parties dynamiques définies dans le template par leurs valeurs de hash correspondantes (DPDigest).
- appliquer une fonction de hachage au Morph Body MB pour obtenir un résidu D.
- le résidu D est chiffré (en utilisant la clef privée du signataire) pour obtenir la signature S du document.
- enfin, selon le contexte, les parties dynamiques peuvent être cachées ou non (remplacé par leur valeur de Hash) puis déplacées vers les parties flottantes de la signature.
La signature de morph fournit deux sortes de documents :
- Le document source Doc (B, S): Elle est produite par le producteur, et se compose de corps de source et de signature.
- Les Sous-documents SubDoc: Le distributeur peut créer quelques versions de son document. Il révèle simplement l'information correspondante liée à un contexte spécifique (c) et cache d’autres en calculant les valeurs correspondantes de DPDigest. Par souci de clarté, ces pièces calculées sont déplacées vers la partie flottante de la signature (voir figure 2, étape 4).
Pour vérifier l'authenticité de chaque document ou sous-document, les parties dynamiques restantes sont remplacées par leurs valeurs correspondantes de Hash avant de vérifier la signature.
Par ailleurs, chaque DP peut en contenir d’autres. De cette manière, le distributeur a la possibilité de cacher toutes les parties DP ou un ensemble de sous-parties à l'intérieur d’un DP. En conséquence avant de calculer le DP globale, le résidu de toutes les sous-DP doit être calculé récursivement.