Email: The Electronic Postcard
Table of Contents 1.0Introduction……….page 3 2.0Internet Overview………...page 3,4 3.0Email vulnerabilities………...page 5-7 3.1Privacy………..page 5 3.2Authentication……….page 6 3.3Non-Repudiation……….page 6,7 4.0Implementing Security Features………page 6-12
4.1 Improving Security………..page 7 4.2 Secret key cryptography………..page 8 4.3 Message Digests………page 8 4.4 Digital Signatures………..page 9 4.5 Public key Cryptography………..page 9,10 4.6 Public Key Infrastructure……….page 11,12 5.0 Secure Email Systems………page 12-15 5.1 S/MIME………..page 12-14 5.11 Personal Distributors………...page 13 5.12 Public Distributors………...page 13 5.13 Other Distributors………page 13,14 5.2 PGP………...page 14,15 5.21 Certificate Distribution………page 14,15 6.0 Conclusion………page 15 7.0 Works Cited……….page 16 8.0 Glossary……….page 17,18
1.0 Introduction
Email is perhaps the most un-secure communication medium that
We use today. Sending an email message is analogous to sending a postcard through the mail. Anyone who comes into contact with it can read it. Many of the biggest problems with email today such as spam are directly related to the lack of security in email. Anyone can send an email message claiming to be someone else, and furthermore there isn’t the slightest guarantee that the message will be private. However, if other forms of communication can be made more secure, surely email could also be redesigned with authentication as well as privacy in mind.
2.0 Internet Overview
To understand why email is not secure we first need to cover how the internet deals with email. An email is handled much like most other information on the internet is handled. It is first broken into payloads and then bundled with information about its destination to form packets. The packets are then transmitted across the network to the router. Routers are computers or devices specifically designed for communication with other networks. A router is responsible for forwarding packets to the next location that is closer to its final destination. Because all networks are not directly connected to each other, any specific packet may encounter dozens of routers on its way to its destination. When a router receives its packet it first analyzes the destination information to determine where the next location it needs to be sent to reach its destination (naturally there is more to it than that, but we need not be concerned with next hop algorithms). The router then extracts the payload from the packet (keep in mind the payload is in plaintext) and inserts it into a new packet which contains the next hop in the destination information. This occurs until
the packet reaches its final destination. To illustrate this process imagine 2 computers, 2 networks and the internet located in between them.
Note: Email servers are required for email to be actually sent. However that detail is not necessarily important in this example and has been omitted.
We’ll call the computer sending the email computer A. The computer that is supposed to receive the email is computer Z. Computers A, and Z reside in networks A, Z
respectively with the internet located between them. First the email is broken up into packets and sent from computer A to the networks router. The router of network A then extracts the payload, figures out what the next hop is, constructs a new packet and
forwards it to that router. This occurs until the packet reaches the final router which sends the packet to Computer Z which reassembles all the packets into the email message.
3.0 Email vulnerabilities
3.1 Privacy
Due to the fact that numerous routers receive and forward the emails packets email is particularly vulnerable to the “Man in the middle attack”. This is when someone intercepts the information while in transit. This can easily by accomplished at any router that a packet encounters by simply saving a copy of the payload and reconstructing it as the rest of the packets pass through. Although not all of the packets will take the same route it is entirely possible that enough of them would be copied that most of the message would be reassembled into a readable form. The so called “man in the middle” has many options at his disposal. He can transmit the data so as to not arouse suspicion that the information has been intercepted. Or transmit modified data in place of the original data. Or not transmit the data at all. For example say Alice sends bob an email confirming their date Tuesday. Jealous room mate Leroy could intercept the information, and transmit a modified version to make it look as if Alice has cancelled their date.
Note: even when assuming that Alice, Bob, and Leroy are on the same network, many network implementations would still allow bob to intercept the email.
3.2 Authentication
As demonstrated above Email has severe privacy issues, but it also has even more severe authentication issues. Actually there is no authentication. In theory Email
addresses are composed of 2 parts. A name, followed by the domain it is sent from. For example if your email address is [email protected]. Most people would assume that the person who sent the email belongs to the network associated with engr.orst.edu. However sending email from any name and any domain is as simple as connecting to a
non-secure mail server via shell or command prompt and issuing a few commands. Even at our school it’s possible to spoof an email from any person, including staff.
3.3 Non - Repudiation
Of course spoof emails are generally traceable to anyone with technical prowess. Many email clients allow you to see the email headers. The email headers will generally tell you, all of the hops that the email encountered on its way to you. As well as the computer that sent it (via IP address), and the time it was sent. Still there are ways to circumvent this, and there is no guarantee that the computer it was sent from belongs to the person who sent the email. Security experts estimate that as much as 30 percent of all spam is relayed by compromised computers located in home offices and living rooms, but controlled from afar (PARANTHETICAL CITATION). Because of this it is virtually impossible to prove to a 3rd party that a particular person sent an email.
Note: The following are the headers from a spoof email I sent to myself from using the engineering mail server and Professor Koc’s email address.
Return-Path: <[email protected]>
Received: from gx21.CS.ORST.EDU (gx21.CS.ORST.EDU [128.193.32.71]) by engr.orst.edu (8.12.10/8.12.10) with SMTP id j260udoS008653 for [email protected]; Sat, 5 Mar 2005 16:57:53 -0800 (PST) Date: Sat, 5 Mar 2005 16:57:53 -0800 (PST)
From: [email protected]
Message-Id: <[email protected]>
Youre fired!
Note: “Youre fired!” Is the message I sent to myself.
Figure 3.3
From examining the information in the above header you can see that the computer that sent the email was gx21.CS.ORST.EDU. This computer is actually located in the Hovland computer lab. Normally there would be more “hop” entries after this but
because I sent this from a computer on the network to the network there is only one entry. By reading the headers you can have a clearer view of who sent you email. However, this information can not necessarily be used to verify that you know the person. For example if you think you know the IP address of the sender, then it is also possible that your adversary(The malicious hacker) does as well, and may be able to fake this information as well if he has sufficient skill.
4.0 Implementing Security Features
4.1 Improving Security
There are a host of possible security measures that can be used to provide security for email communication. These include Digital Signatures, secret key cryptography, Public key Infrastructure and Message Digests. However many of them have to be used in conjunction with each other to provide privacy, authenticity, and non - repudiation. 4.2 Secret Key Cryptography
Secret key cryptography is using cryptographic algorithms that require a hidden key. A key that only trusted parties can have. This key is required to both encrypt and decrypt any information you wish to send. The security of this paradigm depends on both the security of the algorithm itself and also on the actions of all those that have the secret key. This is a major drawback to secret key cryptography’s usefulness to securing email because you must either disclose the secret key to everyone you want to send secure email to, or you must maintain different secret keys for each person you wish to send secure email too. Unfortunately with secret key cryptography alone there is no way to guarantee authenticity.
4.3 Message Digest
A Message Digest uses a function that produces output that can not be used to find out the input. This function is also known as a one way transformation. These Message Digests are similar to a hash but with several key differences. It must be improbable to find 2 inputs that have the same output, and it must improbable to determine the input of the function from the output. This is useful because it means that if a message digest is included in an intercepted message. The message can not be modified undetected because the Digest produced from the modified message would not be same the same as the digest from the original message. This only works assuming that the digest is either encrypted via secret key encryption or used in conjunction with a digital signature. Other wise an adversary could simply modify the message and compute a new Message Digest to be included with the mail. Then any unsuspecting recipient would execute the Digest function on the message and would end up with the same digest and assume the message was unmodified.
Note: Refer to Example 4.5 4.4 Digital Signatures
A digital signature is a quantity that only be generated with knowledge of a private key (Private keys are covered in Section 1.24). However because it requires a different key for verification it allows both repudiation and authentication because there is only one person with the private key. Therefore if a message is signed with the digital signature the person who owns the private key must have sent the message because only that user is capable of generating that signature. Digital signatures are computed using the message contents as well. So if any of the data is modified after the digital signature is generated,
anyone who attempts to verify the digital signature will know that the message is not authentic. This helps protect against the man in the middle attack. Because generating Digital signatures can be slow it is common practice to digitally sign a Digest of the message.
Note: refer to Example 4.5
4.5 Public Key Cryptography Standard (PKCS)
Public key cryptography requires maintaining key values. The first of which is a public key, and the second of which is a private key. The private key is a key that only the creator can have. Otherwise security would be compromised. A private key is used to decrypt cipher text and to create digital signatures and generate public keys. A digital signature is created by applying the private key to an algorithm to create a number that can be verified with the public key, but can only be generated by the private key. This Digital signature can then be included with the message. A public key on the other hand is used to encrypt information and to verify to the digital signatures. Like secret key cryptography one public key must be maintained for each person you wish to send email to. However the secrecy of this key is not necessary because it cannot be used to decrypt information. Communication with public key cryptography would work like this.
Alice and bob wish to send secure messages to each other. First they both have to generate and distribute public keys to each other. This can be accomplished either in person or by PKI (See section 1.26), or some other secure means. However it would not be wise to send public keys on a non-secure medium, because there is no guarantee that the keys will not be intercepted by a man in the middle. First Bob encrypts a message using Alice’s public key. He then creates a Digest of the message and digitally signs it
with his private key and includes it with the message. When Alice receives the message she can verify that the message is actually from Bob by using bobs public key on the digitally signed message digest. She can then decrypt the message by using her own private key. Because no one can decrypt the message except Alice (unless she unwisely stored her private key) the communication is secure even if an adversary has Alice’s public key. The adversary could of course then send encrypted messages to Alice while claiming to be Bob. But with out Bob’s private key the adversary would not be capable of generating digital signatures and Alice would know the messages were not authentic. Unfortunately generating public keys is time consuming, and public key cryptography is considerably slower than secret key cryptography. Still it does improve privacy,
authenticity, as well as non-repudiation as the following example illustrates.
“Suppose bob sells widgets and Alice routinely buys them. Alice and Bob might agree that rather than place orders through the mail with signed purchase orders, Alice will send electronic mail messages to order widgets. To protect against someone forging orders and causing Bob to manufacture more widgets than Alice actually needs, Alice will include a message integrity code on her messages. This could be either a secret key based MAC or public key based signatures. But suppose sometimes after Alice places a big order, she’s changes her mind (the bottom fell out of the widget market). Since there’s a big penalty for canceling an order, she doesn’t fess up that she’s canceling, but instead denies that she ever placed the order. Bob sues. If Alice authenticated the message by computing a MAC addressed based on a key she shares with bob. If bob knows he didn’t create the message he knows it must have been Alice. But he can’t prove it to anyone! Since he knows the same secret key that Alice used to sign the order he could have forged the signature on the message himself and he cant prove to the judge that he didn’t! If it was a public key signature, he can show the signed message to the judge and the judge can verify that it was signed with Alice’s key. Alice can still claim of course that someone must have stolen and misused her key (it might even be true), but the contract between Alice and Bob could reasonably hold her responsible for damages caused by her inadequately protecting her key. Unlike secret key cryptography, where the keys are shared you can always tell who’s responsible for a signature generated with a private key” (kaufman 54).
4.6PKI (Public Key Infrastructure)
Public key infrastructure is one solution to the problem of distributing public keys. Generally for PKI to be considered secure it must have the following criteria met.
• Someway of certifying that public keys are valid • A way of managing these certifications
• Method of revoking certifications • Method of evaluating public keys
However the PKI must be trusted implicitly. If the Organization running it is not honest the illusion of security would be there, which is probably more dangerous than someone who is aware that they have no security.
A common structure for certifying public keys in a PKI is to issue certificates which contain a mapping between their name and the public key associated with it and a digital signature proving that the trusted party issued the certificate.
Figure 4.6
Notice in the above example that VeriSign issued Amazon the certificate. That means that VeriSign is the issuer. However it is possible that there is a chain of issuers. The beginning of this chain is called the trust anchor, because that is the organization responsible for issuing certificates to the organizations under it.
Of course each organization would have its own method for asserting the identity of each person or organization that it issues a certificate to. That is why it is important that the
Copyright VeriSign.com Figure 4.7
5.0 Secure Mail systems
5.1 S/MIME v2
S/MIME is one of the more interesting secure mail systems. It provides authentication, non-repudiation, and privacy via public key cryptography. The interesting aspect of S/MIME is that encrypted messages appear as regular emails with an attachment using the 3 character file extensions .p7m, or .p7s. Files using the extension .p7m are both encrypted and signed, while .p7s refers to a message that has merely been signed. Some mail programs are setup to automatically process the attachment, but users can open a third party application to decrypt and verify if necessary. Another interesting aspect is that S/MIME provides the ability digitally sign a plaintext message and then encrypt the signed message. This unorthodox strategy does provide extra privacy for the sender. Adversaries would be unable to find out the identity of the sender unless they had the correct public key. However if the user wishes it, it is possible to sign messages after encryption, or send signed “clear” messages. That is messages that aren’t encrypted. Of course the signed message digest would still require the public key to verify. S/MIME allows the ability to use either MD5 or Sha-1() for message digests, and provides support
for RSA encryption using key sizes from 512-1024 bits. Although 512 bit keys are considered by many to be non-secure. S/MIME has no specific PKI. Several certificate hierarchies have been developed, each with strengths and weaknesses.
Note: Sha-1 has been broken. This issue is dealt with in Version 3. 5.11 Personal certificate distribution
The most simple and least secure of which is requiring that anyone you wish to send a message to must first send you a signed message containing their certificates. The lack of security exists due to the fact that you cannot protect yourself from “the man in the middle attack”. That is someone could intercept the signed email and certificates and replace them with fraudulent ones. However, most people are primarily concerned with end to end privacy which this structure does provide assuming that no one intercepts that initial email. Once the key has been retrieved, email can then be securely transmitted. 5.12 Public certificate distributors
Many companies are now offering certificate services. Most notably VeriSign has several degrees of certificates. Each of which provides more and more security, but at greater cost. The first level of which is generally free.
Note: Refer to Figure 4.7 5.13 Other Certifiers
Of course it is entirely possible for any organization to provide there own certificate service. For example many companies probably choose this PKI. This does carry the additional risk that your company maintains both your private and public key, and can read any of your email they wish to. It is also entirely possible that people maintaining these keys could be corrupted. For example Employee Bob bribes Ted who manages the
PKI, to give him Alice’s private and public key. Now bob can spy on all messages sent to Alice, and assuming that he has the correct public key. He can also forge emails to others using her digital signature.
5.2 PGP
PGP is a popular PKCS system for both file transfer as well as secure email. Like S/MIME it requires that you encrypt messages and include them as a file attachment. A unique feature of PGP is that it lets you specify what you are encoding, whether it is text or binary information. It also allows you to choose whether the information will be sent by mail in which case encoding needs to take place in order for the information to be handled correctly by some mail servers. After encryption the result is then automatically zipped which results in a smaller file than what you initially started with.
Note: Encoding for transfer with mail servers typically increases the file size by about 30%.
Certificates in this system allow you to specify your own name. This can lead to a hassle because it is possible for you to have multiple certificates for the same name, but which have different keys. In this case you wouldn’t know which key to use to communicate with the person.
5.21 Certificate Distribution
PGP allows an unorthodox certificate distribution strategy. Like S/MIME people are allowed to manage their own keys but they are also allowed to certify certificates for other people. You choose whose certificates you trust, and you can also certify the identity of others. For example Bob trusts Alice, and they have already distributed certificates to each other. Ted now wants to communicate securely with Bob, but Bob
doesn’t know Ted very well. Because Bob trusts Alice, and Alice knows Ted she can certify that Ted is who he says he is. This forms a certificate chain. In this case the trust anchor is Alice. Now because of certificate chains it possible that you will end up with multiple chains that end with the same certificate name, but have different keys. It’s because of this feature that PGP suggests that you use personal information such as an email address when identifying your certificate. Once a chain incorporates someone that is untrustworthy the security of that certificate chain has been corrupted, and cannot be relied on. This system does create problems, but it is still very secure assuming you put a lot of thought into who you consider trustworthy, especially if your trust anchor is a public certifier such as VeriSign.
7.0 Conclusion
Before trying to decide on a security system you need to evaluate which security features are most important to you. If you merely want to protect yourself for eaves droppers any secret key cryptography solution would be perfectly acceptable. For those who want privacy, non-repudiation and authenticity a more complicated solution such as PGP or S/MIME would fulfill your security needs. When choosing between PGP and S/MIME it really comes down to whether you plan on sending files and other attachments securely, or just email. In that case PGP is probably the solution for you. Otherwise S/MIME will spare you the details of conflicting certificate chains. In the end security of any system is only as good as the people who use it. Those who use secure systems ineffectively (Not managing their keys well) will have no security, while people who act responsibly will have greater security.
Works Cited
Comer, Douglas E. Computer Networks, and Computers with Internet Applications Upper Saddle River: Pearson Prentice Hall, 2004.
Dusse et al. The Internet Engineering Task Force.
S/Mime Version 2 Message Specification. March 1998.
6 March. 2005. <http://www.ietf.org/rfc/rfc2311.txt>
Kangas, Erik. The Case for Secure Email. 2004. 4 March 2005. <http://luxsci.com/extranet/articles/email-security.html>
Kaufman Charlie, Radia Perlman, and Mike Speciner
Network Security: PRIVATE Communication in PUBLIC World Upper Saddle River: Prentice Hall, 2002.
United States. Federal Trade Commission. Who’s Spamming You? Could it Be You? January 2004. 4 March. 2005.
How to send email attachments using Perl/MIME::Lite.
Fraubrunnenstrass,Zauggenried. 3 March. 2005.
http://www.akadia.com/services/email_attachments_using_perl.htm
9.0 Glossary
AES- Advances Encryption Standard. A secret key encryption algorithm commonly used today.
Authentication – Accurate identification of who communication is taking place with. Certificate- A certificate is the mapping of a key to a name in the attempt to certify the identity of a computer or person for the sake of secure transactions.
Cipher text- Cipher text is encrypted information
Decryption: The inverse operation of encryption. A function that reverses enycryption. Digital Signatures- A digital signature is a large number that can only be generated by someone with a private key. The digital signature can be verified by anyone with a public key.
DSS- Digital signature standard
Encryption- A reversible function that utilizes and key to scramble data to an unrecognizable form.
Internet- A mass of interconnected networks
Key- A binary quantity used in conjunction with a cryptographic algorithm to generate cipher text from plaintext. A secure key must be longer than 512 bits.
Man in the Middle- A Man in the Middle is any person who intercepts information on its course towards its destination.
Message Digests- the result of using a one way transformation. Useful in proving that cipher text has not been modified or replaced.
MIME- A Format for messages that provides special headers. Allows multiple types of data to be sent as attachments.
Network- a series of computers connected to each other
Next hop- The next router a pack must encounter to reach its destination
Non-repudiation – Capable of being proven to a 3rd party that that communication was authenticated by a particular person.
Packet- A block of data generated when information I sent across a network or the internet. Contains a payload as well as information about its destination.
PGP- Pretty Good Privacy. A system for providing privacy, authentication, and non-repudiation for both files, and email.
PKI- Public key infrastructure. Refers to the manner in which certificates are issued in a public key cryptography system.
Plaintext- data that is not encrypted
Privacy – Only those who were intended to get the information are allowed to view it in plaintext.
Private Key- A key used in the PKCS used to decrypt information and generate digital signatures. This must be kept confidential.
Public Key- A key used in the PKCS to encrypt information, or verify a digital signature. Public Key Cryptography
Router- A computer of specifically designed device designed to forward packets to their next hop.
RSA- A type of public key encryption algorithm S/MIME- A type of secure mail system
Secret Key- A key that is used for encryption and decryption. Must be kept confidential. Secret Key Cryptography- The use of cryptographic algorithms with a secret key.
Sha-1- A Message Digest function. Broken in 2005 Sha -2- A Message Digest function. Successor to Sha-1 SMTP- An email transfer protocol