Who wrote an email? More precise: Who wrote the contents of the email?
+This is what cryptographic signatures should help you with. +It is called preserving the integrity and authenticity of an email contents. +The software must therefor help to spot if somebody sends +an email trying to trick the receiver into believing it was from somebody else.
+Researchers from Münster and Bochum have published an +applied research article [1] today. +In it they discuss a number of ways of how to 'spoof' +an email signature, trying to bypath the email client's checks. +Considered were a number of clients that implement the widely distributed +cryptographic standards OpenPGP and S/MIME. +The researchers found many smaller and larger problems. As it is good custom +they have reported the findings and suggested improvements to the implementors +in a process they call coordinated disclosure. This is why you may +only hear about it now, though most software has already been updated.
+Gpg4win and its crypto engine GnuPG had been affected. +Version 3.1.4 of Gpg4win released in October 2018 had the necessary fixes.
+This happens on a regular basis with software products. +But what can we learn about it?
+Obviously it is good to have independent applied research about email +cryptography that comes from a usability perspective. Progress is made +possible by competing implementations and thus open standards. +We can look at the less obvious lessons from two main perspectives:
+User perspective
+Following general practices of safely operating your computing equipment +has made you secure against the problems, because you use well maintained +software products, which you update. For example Gpg4win by default +will have notified you about the availability of a new version in October.
+However two points stand out:
+- What about my communication partners? +
- Why are so many clients affected? +
Be adequately cautious
+Signing emails cryptographically makes sense, because this way +the receiver will be given one more means to check that it was you.
+In general it impossible to fully control what the software and people +at the other end will do. +(Here the discussion could branch off into pros and cons of an open standard +with many implementation versus a single proprietary vendor solution. +Though being interesting to ponder, a small change of a problem +`on the other end` will remain.)
+So when receiving a message from someone: The more important it is +and the more sensitive, the more cautious you should be. +This is what humans do in other settings as well.
+Depending on the importance:
+- Check the available details for a signature. +
- Judge the context of the information (like writing style or situation the + communication partners are in). Is it plausible to be from this person in + this situation? +
- Seek conformation via additional communication channels. Like a phone call. +
To support users to be adequately cautious, the display of just two states +like 'unverified' and 'verified' is not enough. Email clients should offer ways +to display different status levels of a signature and allow to look at details. +Gpg4win is being developed into this direction and already displays +several states for a signature.
+Research is hard to summarize
+The summary of the research article shows that the majority of tested clients +had one or more issues. And the root case is that it is hard to make +digital signature usable, as the researcher conclude.
+In order to reason this, they took a variety of technical approaches +- called 'attacks' - to see if they find technical problems. +The combination of 14 attacks with about 40 email client- and +plugin-configurations means a lot of work. +Findings and countermeasures also had to be documented +and reported properly to the development teams. +Thus the work is done within a longer time period and if a component +is fixed quickly (like for example one important GnuPG fix), +this will not be reflected in the summary. +This is fine from the perspective of research because it helps to support +the conclusion that in addition to good cryptographic foundations, +also sound suggestions for implementing the user facing side has to be made.
+Needed are good recommendation how applications should behave +regarding email signatures. This is a lot of work and will take time. +For once it has to work with the user interfaces of different applications. +And secondly it is harder than specifying algorithms or protocols, +because it depends on how users perceive the interfaces.
+The reported findings and suggestions have already made email +signatures safer in many aspects, and not easily reflected in +a research summary. +In the long run: Coming up with good interface recommendations +will lead to an even more robust ecosystem of applications.
+Developers perspective
+Take a look at the proposed development improvements mentioned in +the article, it is a reminder about a number of pitfalls to avoid. +In Addition:
+When connecting your application safely to the crypto engine +GnuPG use GPGME, the official application programming interface (API). +GPGME has the code for parsing and state holding that is necessary to deal +with the response codes of the GnuPG command line executable. +Since more than a decade GPGME is preferred over calling a GnuPG executable +yourself. The article is a hint towards why: Applications using GPGME +were safe from the CVE-2018-12020 defect and the class of problems +from matching regular expressions and state confusion.
+Again it is shown that allowing HTML/CSS styling in emails add to the technical +problems of keeping our clients secure. So even if users demand it strongly, +it is not a good choice when security is an issue at all. At least the +default should be off. Maybe it would help to come up with a simpler markup +language which offers a very limited set of styling methods for email contents +that can be kept under control from a security point of view.
+Since 2016 there are notable approaches towards a better trust model +for OpenPGP based cryptography. GnuPG itself hold information where a +public key came from and how often it was used in communication. And the +Web Key Directory (WKD) allows for a standard way to get a public key +associated with an email address. Please consider this for your +applications.
+Technical Details for Gpg4win
+GpgOL the Outlook add-in coming with Gpg4win. +When displaying a signed email, it was possible to trick +GpgOL to show a wrong sending email-address of a valid signature.
+Also it was possible to use HTML in an email - if activated - to fake +a verification for inattentive users.
+Both problems have been resolved with Gpg4win version 3.1.4, +released 2018-10-17.
+ID attack on GpgOL
+In GpgOL before Gpg4win-3.1.4 it was possible to abuse a display issue +of Outlook to show a valid signature which did not match the visible +sender address. This was possible for both S/MIME and OpenPGP +and bypasses the check that matches a sender address against the +data in the certificate (aka 'public key' in OpenPGP lingo) in the UI. +To work the attacker has to control a key that is already trusted.
+Clicking on the GpgOL status icon brings up details of a signature. +A user doing this could still detect the attack. +The improved GpgOL additionally shows the user ID used to validate a signature +in the trusted sender category, close to the mail body.
+The issue is documented with example screenshots in the tracker [2].
+HTML display attacks on GpgOL
+The article describes that GpgOL should partially be affected +if an attacker added HTML elements in the mail, +that trick the user into believing the would they come from GpgOL +and thus faking the display of a signature status.
+GpgOL has multiple countermeasures against this:
+- The signature state is displayed as a large icon in the + Outlook menu. This icon provides an overall indication + and details of the signature as a tooltip (see screenshot below). + Full information about the used certificate can be obtained by + clicking the status icon. +
- GpgOL additionally uses categories located visually closer to the email + contents. Categories are displayed as part of the header + and not of the body so they cannot be completely faked. + Faked categories in the body would scroll and be part + of a different display area. +
- GpgOL does not use HTML elements in the mail body to display any + signature status. +
While a quick glance on the category may not be enough to recognize +a fake signature, a closer look on the category and the status icon will be.
+
GPG Output spoofing and Gpg4win
+All parts of Gpg4win use the official GnuPG Programming API (GPGME) and +as such are not affected by GnuPG output parsing problems. GPGME +handles all parsing of GnuPG output itself and provides a C API +to access it.
+MIME attacks and GpgOL
+GpgOL uses a MIME parser that avoids displaying +complicated MIME structure and was not affected by this class of attacks.
+CMS attacks and GpgOL
+GpgOL is not affected by the CMS attack classes as it +replaces the content of a mail with the data that was +actually used for verification. Certificate validation +is correctly handled by GpgSM.
+Timeline and references
+- 2018-06-08 GnuPG-Team notified by an implementor about CVE-2018-12020. +
- 2018-06-08 Fix for CVE-2018-12020 released and announced. +
- 2018-06-13 Publication of blog entry for CVE-2018-12020. +
- 2018-09-25 Researchers notified Gpg4win-Team about + "Display Name shown as Signer (I2)" defect. +
- 2018-10-17 Fixed version of Gpg4win released. +
- 2019-03-13 Preliminary access to article via the German BSI. +
- 2019-04-30 Publication of research article. +
[1] 'Johnny you are fired' – Spoofing OpenPGP and S/MIME Signatures in Emails, Müller et. al. 2019 +
[2] T4183.
+Authors
+2019-04-30 +Bernhard Reiter and Andre Heinecke for the teams of Gpg4win and GnuPG
+ + + +CC-BY-SA 4.0