Journal authentification et certification de contenu de courriel ?

Posté par (page perso) . Licence CC by-sa
4
7
juin
2016

Question :
Attendu que :
- le nom de domaine de ma société enregistré par mon registrar .com est sensé corresponde à ma société (travail du registrar de vérifier il me semble),
- les courriels sortants de mon serveur SMTP sont signés avec DKIM (header ET body),
- la source (serveur SMTP) des courriels de ma société (vus de l'extérieur) est vérifiée par SPF et DMARC,
- les utilisateurs du serveur SMTP (submission) de ma société sont authentifiés et que le serveur ne permet pas l'usurpation d'adresses internes,
est ce que quelqu'un peut me confirmer que cela forme une chaîne d'authentification et de certification de l'émission d'un courriel (au sens le courriel n'a pas été modifié, et à bien été émis par telle personne de telle société) ? Auquel cas, qu'est ce qui manquerait pour avoir légalement la valeur de signature numérique ?

Par ailleurs, mettre un document en pièce jointe et coller le MD5SUM dans le courriel n'ajoute pas d'information pertinente. Assertion vrai ou fausse ?

Par avance merci aux spécialistes du chiffrement et de la législation qui passeront par la… :-)
Si vous voulez des détail sur les fonctionnalités de chaque protocole pour mieux juger, il suffit de demander.

  • # Tentative

    Posté par (page perso) . Évalué à 9.

    A priori:

    1. Dans la mesure ou les records nécessaires a SPF, DKIM et DMARC transitent via DNS, il faut aussi s'assurer qu'ils ont voyagé sans encombre, c'est-a-dire les signer de ton cote avec DNSSEC et être sur que le destinataire fait aussi du DNSSEC et les vérifie correctement (c'est-a-dire que si les records sont invalides, l'email doit être considéré comme invalide… ce qu'aucune application ne fait aujourd'hui)

    2. Effectivement, un MD5 ou meme un SHAx d'un document ne sert a rien, dans la mesure ou les pièces jointes font partie du body qui est signé par DKIM. Surtout que MD5 peut tranquillement être considéré comme cassé aujourd'hui.

    Après, au niveau légal, je ne peux pas me prononcer. Même pour la solution qui me parait la plus adaptée (S/MIME) je ne sais pas quelle est sa valeur légale.

  • # Éléments de réponse

    Posté par (page perso) . Évalué à 5.

    le nom de domaine de ma société enregistré par mon registrar .com est sensé corresponde à ma société (travail du registrar de vérifier il me semble)

    Non, c'est là une supposition farfelue. N'importe qui peut acheter nimportequoi.example, le nom de l'acheteur n'a pas du tout besoin de correspondre à quelque partie que ce soit du nom de domaine.

    Le nom indiqué dans le WHOIS est censé être le tien, mais il n'est pas vraiment utilisé en matière de courrier électronique.

    est ce que quelqu'un peut me confirmer que cela forme une chaîne d'authentification et de certification de l'émission d'un courriel (au sens le courriel n'a pas été modifié, et à bien été émis par telle personne de telle société) ?

    Ça donne des éléments de preuve que le message a bien été émis à partir d'un compte de courrier électronique donné dans ton organisation. Il manque au moins une authentification du DNS contre les possibles usurpations par ce moyen (un attaquant qui ferait en sorte que le destinataire d'un message, lorsqu'il va chercher la clef publique DKIM, récupère la sienne à la place de la votre), ce qui peut se faire avec DNSSEC.

    Concernant l'association avec les personnes disposant des comptes de courrier électronique, ce n'est pas possible sans ajouter au moins une sorte de répertoire sécurisé.

    À noter que, du point de vue du destinataire, tout cela dépend de la confiance en pas mal d'acteurs : le bureau d'enregistrement et le registre DNS, ton organisation et son système informatique, plus l'expéditeur lui-même (qui aurait pu laisser quelqu'un d'autre utiliser son compte). Ceci est à comparer avec une méthode de signature de bout en bout telle qu'OpenPGP, qui ne dépendra que de la confiance qu'on accorde à la chaîne de certification qui relie l'expéditeur et le destinataire (chaîne qui peut au besoin être réduite à ces deux seuls acteurs, s'ils ont l'occasion de se rencontrer directement).

    Par ailleurs, mettre un document en pièce jointe et coller le MD5SUM dans le courriel n'ajoute pas d'information pertinente. Assertion vrai ou fausse ?

    Un peu des deux ? C'est pertinent contre les erreurs de manipulations ou de transmissions (tiens, la somme de contrôle ne correspond pas, le fichier a dû être abîmé au passage, ou alors l'expéditeur s'est planté de fichier), pas contre les usurpations effectivement (un attaquant veillerait évidemment a mettre la somme de contrôle de son fichier).

    • [^] # Re: Éléments de réponse

      Posté par (page perso) . Évalué à 3.

      Auquel cas, qu'est ce qui manquerait pour avoir légalement la valeur de signature numérique ?

      Sans doute une signature associée à la personne qui a rédigé le message. Je doute qu'on puisse qualifier de signature numérique une chaîne de transmissions, si sécurisée qu'elle puisse être contre l'usurpation et la modification.

    • [^] # Re: Éléments de réponse

      Posté par (page perso) . Évalué à 1.

      Non, c'est là une supposition farfelue. N'importe qui peut acheter nimportequoi.example, le nom de l'acheteur n'a pas du tout besoin de correspondre à quelque partie que ce soit du nom de domaine.
      
      Le nom indiqué dans le WHOIS est censé être le tien, mais il n'est pas vraiment utilisé en matière de courrier électronique.
      

      OK, je n'était pas confiant sur ce point. Donc il faudrait un TLD avec authentification de la possession du domaine + DNSSEC

      Concernant l'association avec les personnes disposant des comptes de courrier électronique, ce n'est pas possible sans ajouter au moins une sorte de répertoire sécurisé.
      

      Tu en tends quoi par là ? Une table mysql avec mots de passes chiffrés ne suffirait pas ? Il faudrait un engagement de responsabilité sur la chaîne d'administration du serveur ?

      Ceci est à comparer avec une méthode de signature de bout en bout telle qu'OpenPGP, qui ne dépendra que de la confiance qu'on accorde à la chaîne de certification qui relie l'expéditeur et le destinataire (chaîne qui peut au besoin être réduite à ces deux seuls acteurs, s'ils ont l'occasion de se rencontrer directement).
      

      C'est sûr qu'une clef de main en main est plus sûre. Mais c'est difficile à réaliser techniquement dans beaucoup de cas. D’où les chaînes de certification et les blockchains.

      Merci pour ton analyse !

      • [^] # Re: Éléments de réponse

        Posté par (page perso) . Évalué à 3.

        Tu en tends quoi par là ? Une table mysql avec mots de passes chiffrés ne suffirait pas ? Il faudrait un engagement de responsabilité sur la chaîne d'administration du serveur ?

        Il faudrait surtout que ce soit public. Parce que sinon, en recevant un tel message, tout ce qu'on peut dire c'est : si personne n'a fait d'usurpation DNS, si personne n'a piraté le serveur de l'expéditeur, si celui-ci est bien configuré et utilisé, et si personne n'a piraté le compte de l'expéditeur, ce message vient bien de untel@example.com. Ça ne dit pas que ça provient de M. Truc Untel né le 1970-01-01T00:00Z à Paris 42e arrondissement : c'est associé à un compte, pas à une personne.

        • [^] # Re: Éléments de réponse

          Posté par (page perso) . Évalué à 1.

          Oui mais à la limite, que la personne ne soit pas authentifiée ce n'est pas grave. Ce qui importe c'est que ma société le soit. Mais dans tous les cas il y a d'autres problèmes, voir commentaires ci-dessous.

          • [^] # Re: Éléments de réponse

            Posté par (page perso) . Évalué à 4.

            Oui mais à la limite, que la personne ne soit pas authentifiée ce n'est pas grave. Ce qui importe c'est que ma société le soit.

            Dans ce cas ce n'est pas vraiment comparable à une signature, plutôt à un tampon en fait. Et pour le coup, DKIM répond très bien à ce besoin : si on doit pouvoir fournir une indication fiable, vérifiable a posteriori, que tel message provient bien de ton organisation, une signature DKIM fera très bien l'affaire.

            Ce n'est peut-être pas une preuve qui sera acceptée sans argumentation par un tribunal, mais avec une expertise qui va bien, ça devrait être tout à fait concluant.

      • [^] # Re: Éléments de réponse

        Posté par . Évalué à 1.

        C'est aussi pour ça qu'on peut passer par une autorité de confiance.

        Tu auras un certificat niveau 3 (la chambre de commerce en délivre http://www.chambersign.fr, mais également d'autres entités). Ça passe par une vérification physique de l'identité. C'est un certificat x509 si je ne m'abuse.

        Après je ne suis pas super spécialiste, mais j'imagine que si ton certificat DKIM est signé par ton certificat de niveau III ça fait une bonne chaîne de confiance. Pareil pour la signature d’une clé GPG avec le certificat x509 (le problème par contre c'est que sortant du mode de fonctionnement de OpenPGP, il faut faire les vérifications à la main).

        Je pense aussi que plus ta chaîne est courte plus c'est facile d'assurer sa validité.

        Dernier point, si tu veux aller plus loin, ton message pourrait inclure une chaîne issu d'un serveur d'horodatage (en gros un timestamp et la signature par ce serveur). J'avoue ne pas savoir qui fournit ce service (il y a des serveurs open-source, mais le problème ici c'est d'avoir un tiers neutre qui te rend ce service).

        Je suis pas sûr à 100% de ce que j'avance mais c'est une piste.

        • [^] # Re: Éléments de réponse

          Posté par (page perso) . Évalué à 4.

          Après je ne suis pas super spécialiste, mais j'imagine que si ton certificat DKIM est signé par […]

          Non. Il n'y a pas de certificat DKIM, seulement une paire de clefs. La clef publique est publiée comme enregistrement DNS, et si elle doit être certifiée — et elle devrait l'être — ce sera avec DNSSEC.

          Dernier point, si tu veux aller plus loin, ton message pourrait inclure une chaîne issu d'un serveur d'horodatage (en gros un timestamp et la signature par ce serveur). J'avoue ne pas savoir qui fournit ce service

          Il existe un moyen simple de se prémunir des antédatation — mais pas des postdatations — qui consiste à inclure un extrait des dernières nouvelles provenant de n'importe quel journal.

  • # Tentative :

    Posté par (page perso) . Évalué à 1.

    Auquel cas, qu'est ce qui manquerait pour avoir légalement la valeur de signature numérique ?

    Une signature numérique? Tu n'en parles jamais dans ton listing technique (qui s’intéresse au transport et pas au contenu)

    https://fr.wikipedia.org/wiki/Signature_num%C3%A9rique

    A mon avis, vu ta demande, le mieux n'est pas de demander de l'aide au pif comme ça mais de faire appel à un professionnel (que tu peux chercher ici) que tu payeras pour la prestation de conseil sur comment faire une signature numérique du point de vue légal. La sécurité n'est pas un truc simple et demandable "comment on fait et je vais faire" à moins de vouloir être troué dans l'année.

    Sinon journaux != forum.

    • [^] # Re: Tentative :

      Posté par (page perso) . Évalué à 1.

      J'ai une approche différente. Je connais l'existence des procédures standardisées de chiffrement. Mais cela implique des modifications sur les logiciels client. Je me pose la question de savoir si avec les protocoles d'authentification récents on arriverait à s'en passer tout en étant conforme à ce que demande la loi. Je pensait avoir trouvé un moyen mais ce n'est pas le cas…

      • [^] # Re: Tentative :

        Posté par (page perso) . Évalué à 2.

        Je connais l'existence des procédures standardisées de chiffrement. Mais cela implique des modifications sur les logiciels client.

        Ben non, justement; bien que nous autres amateurs du libre auront une préférence naturelle pour PGP et dérivés, il y a aussi S/MIME qui est déjà reconnu par la majorité des MUA commerciaux (même l'iPhone le fait!), et qui fournit plus de fonctionnalité que PGP.

        • [^] # Re: Tentative :

          Posté par (page perso) . Évalué à 3.

          FUD.

          Il y a au moins un contre-exemple majeur : S/MIME est basé sur X.509, dont la sécurité dépend de la fiabilité de l'ensemble des autorités de certification reconnues, or cette hypothèse a plusieurs fois été reconnue non vérifiée. Cela provient principalement d'une limitation précise de X.509, qui est l'impossibilité pour un certificat de porter plusieurs signatures d'autorités de certification, ce qui est précisément l'avantage majeur d'OpenPGP.

          • [^] # Re: Tentative :

            Posté par . Évalué à 2.

            Voilà mais là ça dépend aussi du but de la signature. Si c'est pour avoir une preuve légale, mieux vaut une autorité de certification (qui est la garante de la fiabilité, donc la faute retombe sur eux).

            Si l’objectif est plus interne, GPG est mieux, en effet car non centralisé (pas de SPOF)

            • [^] # Re: Tentative :

              Posté par (page perso) . Évalué à 2. Dernière modification le 08/06/16 à 15:41.

              Voilà mais là ça dépend aussi du but de la signature. Si c'est pour avoir une preuve légale, mieux vaut une autorité de certification (qui est la garante de la fiabilité, donc la faute retombe sur eux).

              Ça tombe bien, c'est faisable avec PGP, dont le modèle est un sur-ensemble de celui de X.509. En fait, n'importe qui peut être autorité de certification, techniquement parlant j'entends. Administrativement, c'est différent, mais toujours est-il qu'il est tout à fait possible pour des autorités de certification ayant pignon sur rue de signer des clefs PGP, en engageant leur responsabilité comme il se doit (et en faisant des vérifications merdiques, parce que ce sont des pros, et que les vérifications sérieuses, c'est un truc d'amateurs).

              • [^] # Re: Tentative :

                Posté par . Évalué à 3.

                Oui le problème est que malheureusement, que je sache, l'ANSSI ne fait pas la certification de GPG (ce que à mon avis elle devrait faire, au moins sur les versions stable).

            • [^] # Re: Tentative :

              Posté par (page perso) . Évalué à 3.

              qui est la garante de la fiabilité, donc la faute retombe sur eux

              Sûrement pas. Les autorités de certification prennent grand soin de se dégager de toute responsabilité.

              Elles fournissent le certificat, point. Elles ne sont responsables de rien de ce qui peut se passer ensuite, et aucune faute légale ne retombera sur elles.

              • [^] # Re: Tentative :

                Posté par (page perso) . Évalué à 1.

                Oui mais quand même, une autorité de vérification d'identité, via chaîne de certification, a quand même une certaine valeur pour prouver ton identité. Je sais que ce type de procédure est utilisée pour la remise des réponses à appel d'offre dématérialisées (ex : plate-forme megalis https://marches.megalisbretagne.org).
                Mais bon, on revient au même problème, chaque code définit ses critères en matière de signature numérique…

              • [^] # Re: Tentative :

                Posté par . Évalué à 0.

                Sûrement pas. Les autorités de certification prennent grand soin de se dégager de toute responsabilité.

                Elle ne peut tout de même pas dégager sa responsabilité si sa clé est corrompue et qu'elle n'a pas suivi les procédures, où si une fausse clé a été forgé en ton nom !

                De plus je pense que la loi fixe certaines responsabilités (par exemple la vérification d'identité pour un certificat de niveau 3)

                • [^] # Re: Tentative :

                  Posté par (page perso) . Évalué à 3.

                  Tu peux me citer une autorité de certification qui a arrêté de certifier quoi que ce soit après que sa clé a été utilisée de manière frauduleuse, même pas nécessairement par eux ?

                  Le seul exemple que j'ai en tête c'est que Chrome a arrêté de faire confiance au CNNIC par défaut. C'est pas beaucoup.

                  Un peu de visionnage: https://www.youtube.com/watch?v=pDmj_xe7EIQ

                  • [^] # Re: Tentative :

                    Posté par (page perso) . Évalué à 3.

                    Tu peux me citer une autorité de certification qui a arrêté de certifier quoi que ce soit après que sa clé a été utilisée de manière frauduleuse, même pas nécessairement par eux ?

                    Diginotar

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: Tentative :

                      Posté par (page perso) . Évalué à 2.

                      Ah ! Je savais bien que le monde n'était pas complètement pourri et qu'il y avait une certaine justice. Merci pour la référence.

    • [^] # Re: Tentative :

      Posté par (page perso) . Évalué à 1.

      RQ : tu as tout à fait raison sur journaux != forum, j'aurais dû poster ça dans le forum. Désolé.

  • # technique != légal

    Posté par . Évalué à 4.

    La "légalité" d'une signature ne dépend pas de la robustesse de ton procédé. J'veux dire même si tu proposes un truc béton techniquement, ta "signature" ne sera légale que si quelqu'un la déclare comme tel.

    La signature traditionnelle est universellement reconnue comme quelque chose qui peut nous lier légalement pourtant elle ne vaut rien du tout en terme de certification d'identité / garantie contre les usurpations.

  • # Ce qui manque - Ailleurs et en France

    Posté par . Évalué à 3.

    Auquel cas, qu'est ce qui manquerait pour avoir légalement la valeur de signature numérique ?

    Partout ailleurs, encore pas mal de choses

    • Tout d'abord une action consciente de l'utilisateur. Envoyer un e-mail n'est pas contractuellement engageant - donc même si tu peux prouver tout le trajet de ton e-mail de l’émetteur au destinataire, avec préservation de l'intégrité du message etc. Un e-mail n'est pas nécessairement engageant (ceci étant si vous faites un email, même non signé, dans lequel vous déclarez au client le livrer à une date précise, promis, juré - c'est opposable en tribunal). C'est valable aussi pour les courriers note bien, c'est pas pour rien qu'on demande d'écrire des trucs du genre "Je soussigné Machin TarteTruc certifie par la présente que …"

    Donc la première chose est de mettre en place un système qui fait que l'utilisateur se rend compte qu'il est en train de s'engager et que cet email aura la valeur d'un document signé. Généralement une action qui l'oblige à s'authentifier avant l'envoi.

    • Ensuite un repo fiable. Généralement un tiers de confiance - mais n'importe quel système qui garantit que l'e-mail n'a pas pu être forgé à posteriori peut faire l'affaire. Il y a trois façons de faire :

    • a) Un officier ministériel (Type huissier ou notaire en France) qui constate l'envoi du mail et consigne le contenu dans ses minutes (preuve très forte, mais peu pratique pour un usage quotidien)

    • b) Un tiers de confiance - c'est à dire un site qui va relayer vos e-mails en enregistrant un hash du contenu et la transaction de transmission de l'e-mail dans un coffre fort numérique. Le niveau de confiance accordée à la signature est proportionnel au niveau de confiance que l'on accorde au tiers. Les certifications de type ISO 2700X aident à estimer le niveau de confiance qu'un juge accordera.

    • c) Un log non altérable. Soit dans le monde physique, par exemple une rame de papier perforé (papier listing) pré-signé et tamponnée par un officier ministériel (encore lui)et qui garantit la cohérence et la continuité des envois mails (méthode populaire en Italie - notamment pour tout ce qui touche au fiscal). Soit dans le monde virtuel avec des systèmes de transactions non altérables - comme ce qu'on a pour les transactions bitcoins par exemple.

    Généralement quand tu as l'action utilisateur et le repo fiable - tu peux gentiment allez voir M. le juge et il va considérer ton document comme au moins aussi bon qu'un document signé. Et ce même en France.

    Par contre si tu veux pouvoir signer les e-mails de tiers (en d'autres termes tu veux créer un service de tiers de confiance et le vendre) - là en France ça devient inextricable ou presque.
    Si ton but est donc de pouvoir signer les e-mails de tes clients, prépare toi à cracher du sang. Surtout si tes clients sont avocats ou officiers ministériels eux-mêmes. J'ai joué à ce jeu en 2008 et même été certifié en 2009 - mais très honnêtement c'est un casse tête juridico-politico-administratif. En 2010 le RGS a commencé à s'en mêler officiellement et les règles ont commencé à changer plus vite que ce que j'ai pu suivre.

    Un bon point de départ est ici RGS qui te donne des liens vers les 300 ou quelques pages que tu dois lire pour commencer ton dossier.

  • # Totalement impossible

    Posté par (page perso) . Évalué à 7. Dernière modification le 07/06/16 à 18:28.

    DKIM, SPF & DMARC n’autorisent qu’une vérification a priori de la validité d’un mail. C’est impossible de s’en servir pour une vérification a posteriori (ie comme preuve future), sauf à conserver la preuve de la validité de la vérification de ces mécanismes lors de la réception.
    Ce qui sur le papier me semble encore plus impossible qu’une validation a priori certifiée. Il faudrait sauvegarder l’état du DNS (SPF, DKIM, DMARC, MX, IP…), des clefs DKIM utilisées, des IP de réception, du registre du personnel, du propriétaire du domaine… le tout de manière certifiée elle-aussi.

    On peut en effet très bien imaginer recevoir un mail légitime qui passe l’ensemble des validations à l’instant T, mais qui ne peut plus être vérifié à l’intant T+1 (changement de clef DKIM ou de SPF suite à refonte de l’infra informatique par exemple).
    Ou inversement un mail illégitime à l’instant T mais dont l’attaquant fera le nécessaire le jour où il aura besoin de s’assurer de la validité de cette preuve (usurpation DNS, etc).

    • [^] # Re: Totalement impossible

      Posté par . Évalué à 2. Dernière modification le 08/06/16 à 09:01.

      Je rajouterai que tout cela ne concerne que les serveurs de mail. Or le but est de valider le mail par les personnes le lisant et l'écrivant. Dans ce procédé, il n'y a déjà pas la relation de confiance entre le serveur SMTP sortant et la personne écrivant le mail. Le serveur sortant pouvant modifier le mail.

      Le seul moyen est de signer le mail avant l'envoi au SMTP sortant. Il faut donc utilisé GPG ou autre, ce partager les clefs de façon sûres et vérifier la signature à l'arrivé. Notez que de la même façon, la signature ne pourra être vérifiée que si la clé est encore valable. Si elle est révoquée, on peut encore vérifier la signature mais rien nous dit si le message a été modifié depuis. Pour cela, on peut contre-signer le mail dès l'arrivé, et re-contre-signer dès que l'on change sa clé personnelle et/ou faire faire cela par une personne tierce.

      Notez que l'on peut aussi contre-signé un mail qui ne l'était pas avant pour se prouver qu'il n'a pas été modifié depuis.

      Cela m'étonne même de ne pas encore avoir vu GPG dans les commentaires.

      SPF, DKIM, DMARC ne sont que des bricolages pour éviter le spam et l'éviter l'usurpation d'identité par un tier n'ayant pas accès au domaine.

      DNSSEC peut être utilisé pour diffusé sa clé public.

      • [^] # Re: Totalement impossible

        Posté par (page perso) . Évalué à 5.

        Cela m'étonne même de ne pas encore avoir vu GPG dans les commentaires.

        On m’a appelé ?

        Si le but est que la signature ait une valeur légale, je ne suis pas certain que GnuPG soit une bonne réponse malheureusement.

        La dernière fois que j’ai vérifié, en France (et probablement dans le reste de l’Union Européenne, parce que la loi française en la matière est une transposition d’une directive de l’UE), une signature électronique a un « haut niveau de reconnaissance juridique » (signifiant qu’elle a la même valeur qu’une signature manuscrite) si, entre autres :

        • elle est émise par un dispositif certifié conforme (comme ceux-ci) ;

        • le certificat du signataire est fourni par un prestataire lui-même certifié (comme ceux-ci).

        À ma connaissance, seule une version spécifique de GnuPG a jamais été formellement certifiée.

        A priori, une signature générée par toute autre version, et/ou avec une clef générée par soi-même indépendamment de toute autorité de certification (comme c’est généralement le cas des certificats OpenPGP, l’un des principes d’OpenPGP étant de ne pas avoir besoin absolument d’autorités de certification), ne saurait répondre à ces critères, et serait donc regardée comme une signature à « bas niveau de reconnaissance juridique », c’est-à-dire « ne pouvant prétendre à un niveau de reconnaissance équivalent à celui de la signature manuscrite ».

        (Tant il est vrai qu’une signature manuscrite est beaucoup plus sûre et difficile à forger qu’une signature RSA, c’est bien connu ⸮)

        Et je dis ça pour OpenPGP, mais une signature S/MIME émise par un produit non-certifié et/ou avec un certificat délivré par un prestataire non-certifié ne vaudra pas mieux.

        • [^] # Re: Totalement impossible

          Posté par . Évalué à 2.

          Si le but est que la signature ait une valeur légale, je ne suis pas certain que GnuPG soit une bonne réponse malheureusement.

          Malheureusement, la valeur légale d'une signature est difficile à avoir et comme tu le dis, une signature manuscrite à plus de valeur qu'une signature RSA. Il faut toutefois faire confiance à ces tiers ayant été certifié conforme et à l'organisme les certifiants. Les signatures personnelles permettent toutefois d'apporter une couche de sécurité pour soi et être sur que ça n'a pas été falsifé après coup et resigné à notre place.

          Le GPG ou autre ne donne la certification que pour ceux qui sont maitres des clefs utilisées.

      • [^] # Re: Totalement impossible

        Posté par (page perso) . Évalué à 2.

        Tiens, ça faisait longtemps que je n’avais pas chipoté.

        Notez que de la même façon, la signature ne pourra être vérifiée que si la clé est encore valable. Si elle est révoquée, on peut encore vérifier la signature mais rien nous dit si le message a été modifié depuis.

        Ça dépend de ce que dit le certificat de révocation.

        S’il comprend une « raison de révocation » (RFC 4880, §5.2.3.23) et que celle-ci indique que la clef a simplement été remplacée ou retirée du service, les signatures antérieures à la date de révocation sont toujours valables.

        Si la clef a été révoquée parce qu’elle a été compromise, ou si le certificat de révocation ne fournit pas de raison (et donc qu’on ne peut exclure que la raison soit par crainte que la clef ait été compromise), alors en effet toutes les signatures émises par cette clef sont suspectes (même celles antérieures à la date de révocation).

        • [^] # Re: Totalement impossible

          Posté par (page perso) . Évalué à 1.

          La question de la vérification à posteriori est vraiment compliquée… c'est vrai que seul un équivalent du SYN SYN/ACK ACK permet de le faire de manière fiable et autonome… l'autre solution est la plate-forme tierce, certifiée, avec du contenu en read only, qui fait la vérification à l'entrée (demandé dans certains codes pour les procédures dématérialisées d'après les commentaires).

  • # Technical Legal / Legal Design / National Security Agency as a start

    Posté par . Évalué à -10.

    Ton système est très sécurisé sur le plan des choix des types de certificats et te mécanismes de sécurités logiciels en place.

    En revanche le cadre juridique ne tient sans doute pas seulement du comte du fait que tu envois des messages.

    Pour les autorités il s'agit d'un système d'information international (ENIGMA).
    On ne te demande rien lorsque tu héberge un service chez toi et tu peu le déclarer au pres de la CNIL.

    Voici quelques points clés (brulants) qui me viennent à l'esprit si j'étais mandaté par l'état pour juger.

    woot

    Il fut un temp ou il était connu que la cryptographie était reservée à l'armée et interdite au grand publique, aujourd'hui crypté est accessible à tous et je me réjuis de voir fleurir de telles initiatives. Il faudrait poser la question à des services qui proposent des servuces d'hébergement de fichier cryptés altermondialistes car ils utilisent peut-être eux aussi des certificats et juissent d'un cadre légal.

    A prévoir en plus d'une formation sur la communication et des notions de droit et de design :
    http://www.quedestampons.com/cachet-a-cire-et-cachet-en-relief-pour-savon-poterie-archives-et-livres/263-cachet-a-cire-officiel-marianne.html

  • # MD5 signature considered harmful

    Posté par . Évalué à 3.

    mettre un document en pièce jointe et coller le MD5SUM dans le courriel n'ajoute pas d'information pertinente.

    Au risque d'enfoncer des portes ouvertes pour ceux qui suivent, le MD5 ne doit pas être utilisé comme outil de vérification d'intégrité vis à vis d'attaques volontaires, mais uniquement contre des modifications fortuites/involontaires.

    Il est aujourd'hui prouvé qu'il est techniquement possible de générer des collisions MD5 volontaires. Dans le cas où les données à transmettre peuvent être altérées sans qu'on voie trop que les traces de modifications se voient (par exemple en rajoutant des octets dans des métadata d'un PDF de façon à conserver le même MD5 malgré la modification du payload), c'est embêtant.

    • [^] # Re: MD5 signature considered harmful

      Posté par (page perso) . Évalué à -1.

      Cela confirme ce que je pensait. Tu peux confirmer que c'est également embêtant pour l'enregistrement des hachages des mots de passe (génération de collision) ? Auquel cas c'est également embêtant pour les systèmes actuels (services, apps - ex : enregistrement du MD5 du mot de passe en base de données pour faire l'authentification, si la base se fait récupérer par un attaquant, il peut générer des collisions).
      Je viens de regarder, le fichier shadow utilise par défaut du SHA-512 sous debien 8, cela me rassure.
      Sur le sujet, pour la pratique orientée WEB, voir : https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016

      • [^] # Re: MD5 signature considered harmful

        Posté par (page perso) . Évalué à 3.

        Tu peux confirmer que c'est également embêtant pour l'enregistrement des hachages des mots de passe (génération de collision) ?

        Attend : tu dis t’intéresser aux signatures etc, mais tu "pensais" seulement que MD5 est troué? Tu demandes vraiment une confirmation que c'est embêtant pour les pass?
        Franchement, tu devrais commencer par la base, et naviguer sur le web pour "picorer" un peu de culture de sécurité, avant de t'attaquer à la signature de mail (sujet bien plus complexe que sécuriser un mot de passe). Même moi qui m’intéresse de très loin à la sécurité est clairement au courant que MD5 est troué depuis des lustres tellement c'est dit partout.

        Auquel cas c'est également embêtant pour les systèmes actuels (services, apps - ex : enregistrement du MD5 du mot de passe en base de données pour faire l'authentification, si la base se fait récupérer par un attaquant, il peut générer des collisions).

        impossible : aucun système "actuel" utilise MD5 pour de l'authentification.

        https://en.wikipedia.org/wiki/MD5#Security

        Pour info, on a même enlevé SHA-1 de la liste des fonctions sûres.

        • [^] # Re: MD5 signature considered harmful

          Posté par (page perso) . Évalué à 0.

          Merci pour la leçon mais ce n'est pas la peine d'être condescendant pour autant…
          SHA1 j'étais au courant. MD5 j'en avais entendu parler mais je ne m’étais pas intéressé de près au sujet.
          Sois heureux si tu as le temps de tout apprendre et de faire ta veille sur tous les sujets. Ce n'est plus mon cas malheureusement.
          Pour information MD5 est encore utilisé par défaut dans postfixadmin par exemple. Cela n'a pas de gravité tant que la BDD ne sort pas du serveur. Un changement implique que tous les utilisateurs redonnent leur mot de passe… imagine pour un système avec plusieurs milliers d'utilisateurs. Mais c'est à faire.
          Idem pour les connexions POP/IMAP avec le CRAM/MD5 et DIGEST/MD5… alors ok on passe sur du SCRAM (https://tools.ietf.org/html/rfc6331). Dovecot : SCRAM-SHA-1 \o/ ! Dans mon cas je passe par du TLS donc c'est moins grave mais bon…
          Bref, merci d'avoir confirmé :-)

          • [^] # Re: MD5 signature considered harmful

            Posté par (page perso) . Évalué à 2.

            Cela n'a pas de gravité tant que la BDD ne sort pas du serveur.

            C’est ce devaient se dire les admins de tous les sites listés ici

            Effectivement, tant qu’on n’est pas attaqué, peu importe la façon de stocker les mots de passe, on pourrait même les stocker en clair que ça ne poserait aucun souci… tant que la BDD ne sort pas du serveur.

  • # Ca bouge au niveau de la loi ? Un décodeur juridique SVP ? :-)

    Posté par (page perso) . Évalué à 1.

    Je n'ai absolument pas le niveau de connaissance juridique pour apprécier cela, mais j'ai trouvé : https://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=496651A7C8DDD67CC38996A243559590.tpdila18v_1?cidTexte=JORFTEXT000032004939&idArticle=LEGIARTI000032006591&dateTexte=20160212

    (version du code civil à venir au 1er octobre 2016)
    "Ordonnance n° 2016-131 du 10 février 2016 portant réforme du droit des contrats, du régime général et de la preuve des obligations - Article 2 "
    voir : Sous-section 4 : Dispositions propres au contrat conclu par voie électronique

    Franchement je ne comprends pas le texte…
    Entre l'envoi des contrats, des éléments intermédiaires et l'exécution du contrat, on ne parle pas de signature.
    Il y a deux cas identifiés (cas des articles 1125 et 1126, et les autres cas) et je ne sais pas dans lequel placer la "signature" (ie accord contractuel prouvé)… de plus, des conditions sont fixées par décret en Conseil d'Etat : quelqu'un a connaissance de ces décrets ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.