Signature électroniques, archives et droit
Par David Monniaux le lundi, avril 18 2011, 11:03 - Réseau - Lien permanent
Le tribunal administratif de Toulouse a rejeté un référé contre le CNRS, dans une affaire de marchés publics, au motif que le CNRS a pu valablement rejeter la soumission électronique de cette société car celle-ci avait signé électroniquement l'ensemble de l'archive Zip soumise et non chacun des fichiers individuellement.
De mon point de vue, pour des applications nécessitant une sécurité modérée (p.ex. pas des secrets militaires à conserver 50 ans), il n'y a pas de différence sensible de fiabilité entre signer avec un moyen de signature cryptographiquement sûr une collection de documents et signer chacun de ces documents. La seule différence technique appréciable est qu'en cas de signature d'une archive, il est impossible de vérifier individuellement l'authenticité de chaque fichier : il faut disposer de l'archive entière. Ceci peut être gênant dans certains contextes d'utilisation (p.ex. si pour des raisons de confidentialité, certains des documents ne doivent pas être adressés à certains services qui doivent pourtant vérifier l'authenticité de ceux qui les concernent).
Cette décision suscite une question amusante : celle des fichiers OpenDocument (les fameux .odt, .ods, etc. manipulés par OpenOffice ou LibreOffice, format normalisé par norme ISO). Ceux-ci sont des archives Zip (plus exactement, Jar) stockant dans des fichiers différents le texte du document, les styles, les images et autres objets inclus. Faut-il signer séparément chacun des fichiers ? :-)
PS Je ne vais pas blâmer les juristes : ils doivent débrouiller par rapport à la vie réelle un maquis de lois et réglements adoptés à d'autres époques, parfois pour répondre à des problèmes d'actualité, et sans grand souci de cohérence. Quand on voit ce que l'on fait avec les normes en informatique, et nos architectures matérielles et logicielles qui sont en grande partie conçues pour émuler les machines d'il y a 20, 30 voire 40 ans...
Commentaires
Le fait qu'on ne puisse pas déduire d'une signature sur l'archive une signature sur chaque fichier me semble déjà une raison suffisante pour reconnaître que ce sont deux choses différentes.
Par ailleurs, si je me souviens bien, une archive ZIP est un fichier assez malléable (on peut par exemple ajouter des séquences de bits arbitraires en fin de fichier sans modifier le contenu obtenu à la décompression, ou quelque chose comme ça). C'est un point qui n'a pas d'importance si on utilise des signatures réellement cryptographiquement sûres, mais dans le cas d'une signature disons sûre dans le modèle de l'oracle aléatoire mais instanciée avec une fonction de hachage un peu faible, ça peut poser des problèmes.
Par exemple, il doit être facile de fabriquer, à partir d'une archive ZIP, une autre archive dans laquelle on a modifié l'un des fichiers, et telle que les deux archives aient le même MD5, donc une signature avec MD5 sur une archive ZIP ne vaut pas grand-chose, alors que c'est plus dur de jouer à ce jeu avec des fichiers individuels moins malléables.
@mt-i: Est-ce différent du fait de pouvoir altérer un fichier texte sans changer son MD5 ? Si tu utilises de la cryptographie faible... tu as une faible fiabilité !
mt-i : Ça, ça montre juste que MD5 est cassé !
Oui, c'est différent d'un fichier texte. On ne sait pas modifier un mot dans un fichier texte pour obtenir un autre fichier texte avec le même MD5: il faut ajouter plein de garbage à la fin pour que ça collisionne (et il est fort peu probable qu'on tombe sur un fichier texte valide dans l'encodage dont on est parti, d'ailleurs).
Alors je suis d'accord que la faiblesse est au final celle de MD5, mais le même genre de faiblesses se trouve aussi dans les autres fonctions de la même famille: j'aurais plus confiance dans l'unicité du SHA-1 d'un fichier texte que d'une archive ZIP.
Tu veux dire que l'on pourrait insérer plein de cochonneries à la fin du Zip, dans un fichier supplémentaire d'archive, p.ex. ? D'accord, mais dans le Zip en question, on trouve des PDF... Je suis quasi sûr que dans un PDF, tu peux rajouter des zones de contenu arbitraire qui n'ont aucune conséquence d'affichage (p.ex. inclure une image bitmap tracée en blanc sur fond blanc ou similaire).
La morale de cette histoire, c'est que plus le format est compliqué et permet de mettre des informations en plus du bête contenu textuel affiché à l'utilisateur, plus on peut exploiter d'éventuelles collisions.
Pas dans un fichier supplémentaire d'archive, directement. Concrètement, `head -c 500 /dev/urandom | cat >> machin.zip` modifie le fichier machin.zip sans rien affecter de ce qui sera obtenu à la décompression. Il y a peu de formats de fichiers aussi coopératifs avec le cryptanalyste! Enfin il se peut que le PDF soit assez tripatouillable également, c'est vrai.
@Mt-i: Expérience sur deux fichiers PDF, l'un sortant de pdflatex, l'autre de Quark XPress : rajouter 500 octets de n'importe quoi ne change rien à l'affichage sous evince et Acrobat Reader, ajouter 500000 octets produit un avertissement d'evince sur la console (donc non lu par la plupart des utilisateurs bureautique) disant que la table xref est cassée et qu'il la reconstruit (il me semble qu'Acrobat affiche le même genre d'avertissement une fraction de seconde) !
Bref c'est totalement tripatouillable, si le seul problème est d'avoir le droit de rajouter n'importe quoi au bout.
Pour le naïf que je suis, à quoi est due une telle insensibilité du pdf ? Il y a de la redondance ? Un format rigide avec de la place pour de grands champs non indispensable ? Des données qui ne servent qu'à accélerer l'ouverture ? Pleins d'autres choses ? On peut les rajouter n'importe où ou bien seulement au début ou à la fin ? (n'importe où ça me ferait un peu mal quand même !)
@Pof: on ne peut rajouter des choses qu'à la fin. Pourquoi ? parce qu'il y a une ligne "fin de fichier". Tout ce qui est mis derrière ne compte pas. Le début du fichier contient le type, le prologue... toutes choses à ne surtout pas modifier.
Exellente ta ramarque sur les fichiers openoffice :)
Dans la même veine : Si je cite un bouquin, une ref technique qq ou une url dans mon document je doit signer tous les écrits de la terre entière depuis l'invention de l'écriture.
Ces procès sont de toutes fqcons idiots:
C'est au demandeur de s'assurer que son offre soit bien au bon format et acceptable.
Normalement (du moins dans l'industrie...) on recoit toujours un accusé de reception disant non seulement que la réponse soumise a été recue mais que sa forme est valide et que donc elle sera étudiée.
C'est à celui qui remet sa réponse à l'appel d'offre de s'arrurer qu'il pourra avoir un tel retour dans les temps.
Sinon bah on ne traite pas avec des entreprises trop procédurières...donc soit ils font un procès mais la prochaine fois on écrira l'appel d'offre de telle facon qu'ils sont pénalisés (c'est souvent facile à faire en restant parfaitement honnete).
Bref c'est un double fail pour cette entreprise : on ne se fache pas avec un gros client quand on est pas fichu de rendre sa réponse dans les temps pour être certain d'avoir le feedback et le temps de corriger le tir au cas où.
Autre chose fun : la signature de contrat se fait encore souvent par *fax*...oui oui...on attend un *fax*. C'est très rigolo. Par courier sur du beau papier 100g avec un beau tampon coloré je comprendrais encore (plus sur le plan émotif que juridique)...mais un fax... :)
@mt-i: Note que pour utiliser une faiblesse de MD5 de cette façon, il faut mettre du garbage dans le document modifié *et* dans le document original. Il faut que les deux documents existent au moment ou on calcule la signature, et dans un sens, les deux documents sont authentiques.
Le seul problème c'est quand la personne qui signe et la personne qui écrit le document ne sont pas les mêmes.
Et par ailleurs, ce genre de chose se détecte assez bien, puisqu'il suffit de regarder s'il y a du garbage...
de toutes facons, tous les algo de hash en usage de facon courante actuellement sont casses... pas forcement beaucoup, mais suffisamment pour qu'on essaie d'elaborer une nouvelle norme, histoire d'eviter les attaques qui vont plomber, a terme, aussi bien MD5 que SHA*.
Le chiendent, bien sur, c'est que les nouveaux algorithmes ne sont pas encore suffisamment testes par la communaute crypto. Juste assez pour dire qu'ils ne devraient pas avoir les defauts des anciens, mais peut-etre d'autre a la place...
Si je me souviens bien de ce que raconte Schneier a ce sujet, on sait encore moins faire des fonctions de digest mathematiquement raisonnables que des algo de chiffrement...
Pour rebondir sur tout ce qui a été dit :
En signature, le principe, c'est de signer ce que l'on voit (What you see is what you sign- WYSIWYS).
Ce n'est pas compatible avec un fichier zip (ou certain format pdf),
Ajouter 500 caractères à la fin d'un fichier va complètement invalider la signature de ce fichier ; la signature est effectuée sur les bits, si tu en rajoutes/modifies, la signature change...
Si vous signez un document avec une application 'maison', ca n'a aucune valeur. Il y a des conditions à respecter pour que la signature soit juridiquement exploitable.
Dernier point :
heu non les algo de hash ne sont pas tous cassés, et heureusement d'ailleurs ;) Par contre il est vrai qu'une nouvelle norme est en train d'être mise en place.
@WYSIWYS: L'histoire du garbage à la fin des fichiers est qu'apparemment, il est possible, étant donné a et b deux fichiers (PDF, ZIP etc.), de générer x et y tels que a.x (concaténation) et b.y ont même signature. Comme les lecteurs Zip ou PDF ne renâclent pas à ouvrir a.x (resp. b.y) comme s'ils ouvraient a (resp. b) ceci permet de générer deux documents différents de même signature.
Si, si, les algo de hash sont casses.
- on a trouve des faiblesses mathematiques dans tous les md5 et sha*: preuve d'existence d'un probleme.
- les publications existantes contiennent des attaques dans des cas tres particuliers.
d'une part, ca ne va pas aller en s'ameliorant, donc si je fabrique un programme utilisant du hash aujourd'hui, j'ai fort interet a permettre de remplacer simplement l'algo de hash par autre chose dans un avenir proche.
Les choses que personne ne sait:
- combien de temps ca va prendre pour finir d'analyser sha* et terminer de le casser officiellement.
- est-ce que quelqu'un est en avance la-dessus, et sait aujourd'hui casser du sha*.
Le point-cle pour moi, c'est qu'on sait que ces algo sont "mauvais" mathematiquement, il y a une structure algebrique exploitable derriere. Partant de la, ca ouvre beaucoup de doute quant a leur fiabilite...
@Xavier...
======ce commentaire est réalisée à titre personnel et n'engage en rien la société concernée par la jurisprudence en objet =======
si vous avez des retours de vos acheteurs avant la commission d'ouverture des plis merci de les dénoncer immédiatement à la Cour des Comptes et à la DAJ du Minefi...
Non ça ne sert à rien, hormis de se prémunir d'un éventuel ratage technique, de répondre 3 semaines avant, au contraire puisque vous ne pourrez plus ajuster votre proposition. La cible est de faire du juste à temps.
Oui le procès peut paraître excessif connaissant très bien (au second chef) le dossier je peux vous dire qu'en portant l'affaire au tribunal la société savait qu'elle se verrouillait le client en question, néanmoins cette proposition était peut être bonne et aurait dû à mon sens bénéficier de la part des achats d'un droit à apporter des compléments à l'offre après ouverture des plis ce qui est la bonne façon de faire en marché public (non encore une fois l'acheteur ne doit pas regarder votre offre avant la date officielle - par contre si l'erreur est de bonne foi, la personne publique peut, et le fait assez souvent, demander un complément). Si cette possibilité avait été offerte cette offre aurait peut être eu une sérieuse chance de gagner. Perdre des semaines de travail et plusieurs millions d'euros de chiffre d'affaire potentiel pour une question d'excès de zèle peut marquer douloureusement j'imagine.
Par ailleurs, si cette offre avait été déclarée recevable elle aurait eu une chance de gagner et la société concernée aurait pu gagner ce dernier marché chez ce client (accessoirement si ma mémoire est bonne un contrat cadre qui verrouillait toutes les autres prestations... le perdre revenait tout simplement au même que perdre la procédure en justice, donc il n'était pas déraisonnable de tenter cette chance)
Pour le bon format je ne suis pas sûr du nombre de RC, CCAP et CCTP que vous avez lu et écrit mais de mon côté travaillant régulièrement des deux côtés de la barrière je peux vous assurer que bon nombre sont idiots (surtout quand je ne travaille pas dessus^^) avec un paraphe à apposer par exemple numériquement sur chaque page de la proposition (comment ? je découpe ma proposition de 90 pages en 90 docs signés ? on m'objectera qu'on me demandait de parapher et lors du dépouillement je n'aurai aucune sympathie des évaluateurs, je peux vous le dire)
Pour ce qui est des critères contre les sociétés procédurières là aussi j'aime votre créativité vis à vis du code des marchés publics qui définit clairement les critères de choix des offres. Non ce n'est pas honnête d'indiquer de tels critères c'est même parfaitement illégal (les critères doivent être en lien avec l'objet du marché pour mémoire). Si les évaluateurs choisissent de biaiser le dépouillement par contre effectivement c'est faisable mais attention au référé... la personne responsable du contrat peut être engagée jusqu'au pénal.
Donc non ce n'est pas un double fail quoique vous en disiez... à aucun des titres il n'y a erreur de jugement de l'entreprise ni sur l'heure de dépôt ni sur le choix d'exercer un recours, la seule erreur fut technique.
En vous souhaitant d'heureuses consultations et de différer vos jugements quand vous ne détenez pas les tenants et aboutissants ...
très cordialement