A Novel Solution for End-to-End Integrity Protection in Signed PGP Mail [chapter]

Lijun Liao, Jörg Schwenk
2008 Lecture Notes in Computer Science  
PGP mail has been widely used to provide the end-to-end authentication, integrity and non-repudiation. However it has the significant drawback that the email header is unauthentic. DKIM protects specified header fields, but only between the sending server and the receiver. These lead to possible impersonation attacks and profiling of the email communication, and encourage spam and phishing activities. In this paper we propose an approach to extend PGP mail to support endto-end integrity of
more » ... email, namely the whole content and selected header fields. This approach is fully compatible with PGP mail. Under some reasonable assumption our approach can help to reduce spam efficiently. End-to-End Security Mechanisms: PGP mail [1,2] is one of the most widely propagated mechanisms to provide authentication, message integrity, non-repudiation of origin, and data confidentiality. The email sender signs the message body using his private key. The receiver verifies the signature with the corresponding public key after receiving signed message. However, in PGP mail, only the body of the email message is protected. Most header fields, such as To, Date, and Subject, are remain unprotected, and the From and Sender are only secure if the receiver checks that the address in the From or Sender of a mail message matches the Internet mail address in the signer ID of the signer's certificate. The most email clients 1 do not check it. Fig. 1 shows that the Thunderbird (with PGP plug-in Enigmail [3]) cannot detect the modification of any email header fields 2 . In the following we analyze some approaches that provide sender authentication or the authentication of some email header fields: S/MIME 3.1, Sender ID, SPF, DKIM, and LES. They are designed to use X.509 based techniques. With light modification, they can be deployed with PGP based techniques, e.g. using PGP certificate instead of X.509 certificate, and using web of trust instead of public key infrastructure (PKI). To send a signed email in S/MIME 3.1, one prepares an email m 1 as usual. A new email m 2 is then created with the same header field as m1, a media block with m1 as its content is then added to m 2 . Now a signature is added to m 2 to protect the content of m 2 , namely the media block with m 1 . In this case, the content and header of m 1 are both protected by the signature. However, this approach is associated with the following disadvantages:
doi:10.1007/978-3-540-88625-9_2 fatcat:g4b5xoxodbgyrioismmrtybfjq