Comment vérifier si crypté message S/MIME est également signé, sans le décrypter
Quelle est la manière la plus simple (en termes de ressources de calcul) pour dire si un s/mime message électronique est signé avec l'attaché de signature lorsque ce message est crypté?
Si un message est signé, c'est facile. C'est un peu comme:
pour les attachés de signature
Content-Type: application/x-pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Ou:
pour signature détachée
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; boundary="----=_NextPart_000_00D2_01CD5850.61030BF0"
dans ses en-têtes.
Mais quand un message est crypté, vous ne pouvez pas dire si c'est aussi signé parce que le header Content-Type est le même pour les deux cas (juste chiffré et chiffré ou signé):
Content-Type: application/x-pkcs7-mime;
smime-type=enveloped-data;
boundary="----=_NextPart_000_000D_01CDC82B.98454D80";
name="smime.p7m"
Signifie que j'ai pour déchiffrer le message, juste pour dire, si c'est aussi signé? Pour l'instant, il semble que je ne peux même pas dire si mon message est signé avant que je le décrypter (parce que la signature est dans les données chiffrées). Ou, peut-être, S/MIME chiffré et signé de données a toujours un modèle qui pourrait me permettre de distinguer entre/crypté crypté et signé/non signé de données sans déchiffrement (qui peut même être possible si je n'ai pas le certificat pour le décryptage)?
Je ne le pense pas. Certains clients de messagerie juste travailler de cette façon.
Si un message est crypté après il a été signé, le seul moyen de savoir c'est signé pour le décrypter en premier. Voir mon répondre pour savoir pourquoi c'est une mauvaise idée.
Merci pour votre commentaire, je vais le prendre en compte si jamais je viens à besoin pour chiffrer ou signer des e-mails. Cependant, je ne suis pas la mise en œuvre d'un système de sécurisation. J'ai juste besoin d'afficher signé et crypté e-mails dans mon client mail. Je viens donc de traiter avec ce que les autres expéditeurs livrer à moi.
OriginalL'auteur Alex | 2012-11-22
Vous devez vous connecter pour publier un commentaire.
S/MIME est flexible, vous pouvez signer et/ou chiffrer dans n'importe quelle combinaison que vous voulez. Les clients de messagerie, cependant, généralement, tous se comportent de la même manière: 2010 Outlook, Apple Mail, Thunderbird 17 de le signer et ensuite chiffrer. Les résultats de ces 3 sont presque identiques. Ils comprennent ces 3 titres dans les en-têtes de message:
Ils chiffrer et base64 encode l'ensemble du corps du message.
Pour répondre à vos questions:
Le seul moyen est de le décrypter.
Oui.
OriginalL'auteur james.garriss
Si l'objectif est de s'assurer que:
alors la séquence est à signe, chiffrer, puis nouveau signe. Sinon, vous ne pouvez pas faire confiance de toute façon. Voici pourquoi.
Signé et Crypté Message: l'expéditeur premiers signes du message, puis la crypte.
Ici, le destinataire peut déchiffrer le message, puis re-chiffrer avec la signature intacte et l'envoyer à un tiers (avec les en-têtes falsifiés). Que le tiers ne crois que l'auteur de l'original envoyé le message directement à lui, quand il a été effectivement transmis par le destinataire d'origine.
Chiffré et Signé du Message: l'expéditeur chiffre le message, puis des signes.
Tout attaquant peut supprimer la signature, de la remplacer par la sienne, et de revendiquer la paternité du message sans connaître son contenu.
Chiffré, Signé et Crypté Message: l'expéditeur chiffre et signe, le message, la crypte à nouveau.
Ici, l'intérieur de cryptage assure seul le destinataire peut lire le message. La signature signifie que l'auteur est au courant du contenu et l'intention pour le destinataire. L'extérieur de chiffrement empêche un attaquant de savoir ou d'altération du message.
Dans ce cas, le destinataire ne connais pas le message est signé jusqu'à ce que après c'est déchiffré.
Chiffrement d'un message deux fois plus
Pire, crypter puis-signe est connu à être vulnérables à l'attaque.
Signé, Crypté et Signé du Message: l'expéditeur signe et crypte le message, puis des signes de nouveau.
Ici, l'intérieur de la signature signifie que l'auteur est au courant du contenu. Le chiffrement assure seul le destinataire peut déchiffrer. Et à l'extérieur de la signature signifie que l'auteur a voulu le message pour le destinataire.
Si un attaquant tente de revendiquer la propriété par la suppression de l'extérieur de la signature et de la remplacer avec son propre, puis les (remplacé) extérieure de la signature ne correspond pas à l'intérieure de la signature.
Si le destinataire déchiffre et transmet le message à un tiers, il doit quitter le plus intime de la signature intacte ou la remplacer par la sienne. Dans les deux cas, l'auteur d'origine est déchargé de la responsabilité pour le message.
Conclusion
En dépit de courant (cassé), vous pouvez vérifier l'expéditeur d'un message seulement si elle a été signée lors de l'étape finale. Donc, ne vous inquiétez pas au sujet d'un message qui a été signé le premier et puis chiffré, parce que vous ne pouvez pas faire confiance, que le présumé signataire envoyé le message pour vous.
Par exemple, imaginez que vous receviez un signé et crypté message de la Présidente, de vous inviter à dîner à la Maison Blanche. Le Président n'a, en fait, d'écrire ce message, mais en fait il l'a envoyé à quelqu'un qui a décidé de jouer une blague sur vous.
Tout d'abord, merci d'avoir pris le temps (et d'avoir la courtoisie) pour expliquer votre downvote. L'une des leçons que vous apprenez de l'expérience, comme j'ai l'habitude de dire mon Soutien technique, est de ne pas se concentrer sur le fait de donner au client ce qu'il veut; au lieu de cela, donnez-lui ce qu'il besoins. En expliquant pourquoi il est trompeur de faire confiance à la signature sur un message qui a été chiffré après il a été signé, j'ai répondu à la question sous-jacente. L'OP demandé: "comment puis-je...?" La bonne réponse est: "ne le faites pas, et voici pourquoi."
Il y a beaucoup de mal avec le régime, mais elle protège contre de nombreuses attaques. Cela dépend du cas d'utilisation. E. g. si vous venez d'accepter les messages de certaines entités, vous n'avez pas de soins si quelqu'un prétend que c'est son message.
-1 Cette condescendance non-réponse est trop bien notées. Il a de bonnes infos, il devrait être un post de blog. D'ailleurs. Conformément à l'OP commentaire, il n'est pas utile pour leur tâche immédiate. Je compatis pleinement avec le désir d'expliquer La bonne Façon De Faire les Choses pour tous les stupides programmeurs. (Et parfois, c'est que je suis stupide programmeur.) Mais quand un mécanicien vous demande de remettre une clé et vous, au lieu de leur dire à longueur de pourquoi ils travaillent sur le mauvais moteur, c'est juste les déchets de leur temps et essaie de leur patience.
OriginalL'auteur Adam Liss
Normalement, le message est d'abord chiffré, signé donc il doit en effet être facile à voir à l'ASN.1 codé DER CMS enveloppe. Voir le publique de la CMS RFC pour plus d'informations.
Vous pouvez le faire sur le chiffrement après la signature de la création de la signature de l'enveloppe serait pleinement dans le chiffrement de l'enveloppe. Je ne pense pas qu'il y est de toute façon de vérifier si le message est susceptible d'être signé, à moins que cette information est communiquée "hors bande".
Merci pour la réponse. Je soupçonne la même chose, je voulais juste confirmation de la part d'autres experts.
OriginalL'auteur Maarten Bodewes