Security in transit -

Security in transit

Editor's note: This article, third in a series of articles on the basics of electronic security, looks at security in transit. The author explains how to assess the “chain” that links the various parts of a network message path and how to ensure that data is secure. The first two articles in this series are
Part 1: What does security really mean? and Part 2: Tampering with easy targets .

There is one way to absolutely, positively guarantee that someone will receive a message intact, unadulterated, authenticated, and observed by no unauthorized party. Just copy the message to a physical medium, lock it in a sturdy briefcase, handcuff the briefcase to your own wrist, and board a plane. Best of luck at the security gate.

When you arrive at your destination, remove the briefcase from your wrist, unlock it, and present the message to your intended recipient. You can be assured that nobody else has seen it. Your recipient can be assured that the message is authentic. While you are there, find a comfortable meeting room and discuss the contents of the message, the weather, Italian restaurants—whatever you like. You have a little time before your flight home.

Use any other method for transmitting a message, and your message is at risk. Someone may intercept it and discover its contents. Or intercept your message and substitute it with one of their own. Or, intercept your message and block its transmission.

These three threats—disclosure of a secret message, alteration in transit, or blocking its transmission entirely—are the primary threats to any secure system. Protecting against these threats form what is known as the “CIA Triad.”[1] The term has nothing to do with the U.S. Central Intelligence Agency. Instead, the letters stand for Confidentiality, Integrity, and Availability. Any secure messaging system must protect confidentiality, provide integrity, and always be available when needed.

The problem is this: any time you employ a medium to transmit your message, you lose control, however temporarily, of that message. Write a letter, send an email, make a phone call. As soon as the message leaves you, you have relinquished control of it. We understand in theory that someone might intervene to take our message, but do we really care?

We now know that many of our electronic messages are at risk of routine, low-level snooping. And it is not just governments that do this. Businesses are archiving email messages, and some are routinely scanning inbound and outbound email to ensure that corporate secrets remain secret. Even if it is surprising, none of this is necessarily a nefarious thing.

But the time will come when each of us has news that we want to keep private. It is then and there that we care strongly about security. But in fact, the time to think about security is before you need it.

This article is the third part in a series on electronic security. In Part 1 we discussed the basic definition of security, when physical locks are less important than logical and virtual “fences.” In Part 2 we dissected the meaning and processes of tampering.

In this article we do not look at the specific cryptographic algorithms involved in electronic security. We assume, until proven wrong, that properly implemented instances of (for example) AES for encryption and ECDSA for signatures are sufficiently robust to deter essentially all potential opponents.

Instead, here we examine security in transit; we assess the “chain” that links the various parts of a secure message path.

Understanding the networking model
Before we delve into system security, we need to understand the network itself.

In the early 1980s, standards organizations created what became known as the Open Systems Interconnection Reference Model (the “OSI Model”)[2]. In this model, data networks were seen as a collection of seven layers, ranging from the physical layer of wires and radio signals at the bottom to the user application at the top. The concepts embodied in the model have proven extremely useful and help us understand what is happening at any point in the journey that a message takes from sender to recipient.

To simplify the discussion, we can condense the seven layers into just four, ranked from bottom to top[3]:

  • The physical and data link layer. This layer is how a network-connected device talks and listens over the physical medium. For example, in a digital radio system this layer would control when the station can transmit; what transmit power, frequencies, and modulation schemes may be used; what packet structure must be used; and how to address other stations that can be directly contacted.
  • The network layer. This layer is concerned with how one system talks to another system on the network. Systems on the network may not all be the same; some are connected by wireless links, some by wired Ethernet, and others by modems or other, older technology. These distinctions do not matter to the network layer. The network layer provides a consistent addressing scheme that gives every system running on it a unique network address. The most widely used network layer protocol today is the Internet Protocol (IP).
  • The transport layer. This layer is the first to ‘understand’ the concept of a connection. The network layer just sends and receives packets. The data link layer takes the data and transmits it over the physical medium without any analysis. But the transport layer is the first to ‘make sense’ of the set of packets, and arrange them as though they belong to a group. The most widely used transport layer protocol today is the Transmission Control Protocol, or TCP, and it provides the concept of a ‘connection.’ Thus, the software asks TCP to make a connection to a port on a remote machine. (The web, for example, operates on TCP port 80.) Its companion protocol, the User Datagram Protocol (UDP) is similar, but simply passes packets individually through to the higher layers without regard to an established connection. UDP is termed connectionless for that reason.
  • The application layer. This protocol layer is the workhorse that accomplishes the task intended by the user. If the user requests a webpage, it is transmitted over the Hypertext Transport Protocol (HTTP). If the user sends an email, it may be carried over the Simple Mail Transfer Protocol (SMTP). Everything that one might wish to do on the network is mediated by an application layer protocol.

When, for example, a user requests a webpage, the request makes its way over the network until, finally, it lands on the router connected, probably by an Ethernet cable, to the web server. The Ethernet card receives the packet and unwraps the first layer (the data link layer), thereby terminating that layer. The Ethernet interface passes the data contained therein to the computer. Network software running on the computer unpacks the IP header and extracts the destination address (“Yes, it is for me!”) and the source address (“Oh, so that computer is calling!”) and determines the transport protocol (“It is TCP.”). The software terminates the network layer and passes the payload to the transport layer.

The transport layer verifies that the packet is transmitted in the proper sequence and that it is bound for a port which some software task has claimed. If the requested port is port 80, the packet is destined for the web server task. The code running the transport layer removes the transport information, terminating the transport layer, and passes what is (most likely) HTTP data to the web server.

So now you know the network model…in an abbreviated way. The important thing here is that, from end to end, only the application layer remains intact. The message may originate on a cell phone with a wireless physical/link layer. It may pass through message handlers that terminate and reestablish the network and transport layers; and finally, it may terminate the message on a desktop computer with a wired connection. While each segment of the journey may (or may not) be encrypted, at the borders between segments, unless you take specific action, your message can be read by anyone with access to those segment breaks.

Figure 1. The application information may pass through many different transport, network, link, and physical layers before reaching its destination.

“But I thought the network was safe!”
Figure 1 shows how application data (i.e., the blue pipe) proceeds from the originator of the message to the receiver, even though different physical media, different types of networks, and different transport mechanisms carry the message. Each concentric cylinder represents a network protocol. Where each cylinder begins and ends represents the points at which one protocol layer is established and another terminated.

Now, assume that you are using a Wi-Fi connection to send a message. You are not concerned about security, because the Wi-Fi connection is secure. You are using WPA2 encryption, so no one can snoop on your message. How far does that security actually extend?

The answer is, not very far (Figure 2 ). Because WPA2 is part of the link layer protocol, as soon as the packets are received at the wireless access point, the encryption envelope is terminated. Hopefully, the other network elements will, in turn, encrypt the network traffic. But when dealing with security, we cannot depend on hope.

Figure 2. WPA2 protection over Wi-Fi extends only to the end of the first link layer.

Well, what about the Secure Sockets Layer, or Transport Layer Security (SSL/TLS)? Most of us have seen the little lock in the browser window when we are doing sensitive work, like online banking. We have been trained to interpret this lock icon as secure; it means that the transaction is secure and the information encrypted so that nobody can access the information except the intended recipient. So, how far does that security extend?

Continue to page two >>

Transport layer security only survives as long as the original transport layer is in place (Figure 3 ). If the message is handed off to another transport layer, security has to be reestablished…but may not be.


Figure3. Transport layer security lasts until the transport layer isterminated—usually at the server. The rest of the message path may beunprotected.

In most cases, if you are dealingwith a first-party website, the transport layer security is enough. Thisis because there is only one transport layer from your computer,tablet, or cell phone to the web server that manages the transaction;the information always stays in the security envelope from start tofinish. But in the case of email, that security envelope goes from yourcomputer only to the SMTP server receiving your outbound email message,and no further. From that point on, your email can be read by anyone whocan access the servers along the way.

These examples are notintended to create fear, but they do serve as a warning: once a messageleaves the safety of its security envelope, it is vulnerable to partieswhose privacy and security concerns may not align with yours.Fortunately, there are other ways to ensure the security and privacy of amessage.

Extending the envelope
For better or worse,we still think in old patterns. For example, the Save icon in mostprograms still bears an image of a floppy disk, even though most of ushave not used one of those for 20 years. Old ways of thinking are hardto break.

In times past when we received a letter, we knew thatthe sender had sealed the envelope and that we were the first to see themessage. (Oh, yes, the envelope might have been steamed open andresealed, but that was a lot of trouble. And besides, who would want todo that to me or you on a bulk basis?) But as we have seen, moderndigital envelopes do not persist very far in the message chain. Tointercept a digital message, no steam is required. The opponent needonly capture the message after the encryption envelope has been removedat some stage during the lifespan of the message.

The solution tothis vulnerability is conceptually simple, although challenging inpractice: extend the envelope. If you apply the encryption at theapplication layer then it survives the setup and teardown of all lowerlayers. In brief, it looks like the illustration in Figure 4 .

Figure 4. Application layer security extends from the message source all the way to the destination.

Ifyou present the transport layer with already encrypted data, it doesnot matter how it treats the data, as long as it faithfully transfersthe data to the endpoint. It can apply—and probably will apply—a TLSenvelope to the already encrypted data, and that is fine. Thatencryption layer will terminate when the transport layer terminates.Wi-Fi encryption will survive only until the Wi-Fi signal is terminatedat the access point—but the application layer will still be encrypted.

But how?
Ifyou are a designer creating a new messaging system, the lesson isclear. Unless there is just one transport pipe between the originatorand receiver of a message, you must not rely just on the SSL/TLSlibraries and subsystems to secure your users’ messages. Consider, forexample, a store-and-forward message system. It establishes a transportpipe when a user sends a message and a second transport pipe when theintended recipient retrieves a message. This message transfer is notcompletely secure even if SSL/TLS is used on both the sending andreceiving links.

But suppose that you are not a designer? What ifyou want to provide better security for messages that you or yourcompany sends?

Begin with one fundamental truth: if you aredealing with a first-party website, they define the security parameters,and you most certainly do not. The obvious first-party web operationsover which we might predictably have security concerns are social media,but they are not the only ones. Banks, credit card companies, and anyfirm which has day-to-day contact with users also get to set the rulesabout security. The good news is that since the entire transaction takesplace over a single transport-layer pipe, the transport layer securityis generally good enough for these parties. The bad news is that thedata you access comes from a back-end database, and there is absolutelyno transparency about the security of those back-end links.

Butthere are areas where we can take control of our own security. For theremainder of this article, we will look at one in particular: emailsecurity.

End-to-end security of email
To performend-to-end encryption of email messages, you need an encryptioncertificate from a certificate authority. Some certificate authoritiesprovide a certificate valid for one year free for personal use;longer-term certificates or certificates intended for business use areavailable on a paid basis. There are two types of certificates: class 1certificates only guarantee that the email address used to obtain thecertificate is the originator of the email message; class 2 certificatesactually guarantee the identity of the sender and require moreextensive background checks by the certificate authority.

Onceyou obtain a certificate, you must install it in your email client. Thisis a nontrivial operation best handled by an IT professional. It can,however, be done by an individual willing to read and follow directionsand perform the requisite follow-up testing.

Once installed, thecertificate directs the email client to transmit a signature attachmentwith each email. Properly configured email clients receiving a messagewith a signature attachment can verify the message sender by followingthe certificate’s ‘chain of trust.’ The signature asserts, “This messagewas signed by (for example) Alice, and here is her certificate.” Thecertificate asserts, “This is Alice’s certificate, and this certificateis signed by (once again, for example) Bob’s certificate authority, whovouches for it.” Bob’s certificate authority also has a certificatesigned by a higher level certificate authority, and so forth, until aroot certificate known to the receiving email client is reached.

Atthe end, the reasoning embodied in the chain of trust works like this:“I know Doug, and Doug says he knows Cindy, and Cindy knows Bob, and Bobknows Alice, so I can trust that this message came from Alice.” In thisway, Alice can prove that she, and only she, could have sent themessage since she is the only one who possesses the signing key forwhich the chain of trust vouches. The signature also proves that themessage has not been corrupted in transit. In addition, the signatureblock will include the sender’s public encryption key, so that thereturn message can be automatically encrypted.

After you—andthose with whom you correspond—have installed certificates, the mailclient will automatically encrypt and sign messages between you and yourassociates. This encryption has both benefits and disadvantages. Thebenefits are obvious: your message is secure and probably comes fromyou; your message cannot be scanned for keywords as it passes throughcommercial email providers; consequently, your message cannot be usedfor future advertising or demographic analysis.

But there is adisadvantage to this encryption: the message cannot be scanned fordangerous attachments or viruses. Corporate firewalls are uselessagainst harmful content that may be present in encrypted messages. You,as the sender or receiver of the message, must be particularly vigilantabout opening attachments within encrypted messages.

Iam not the first to observe that transmitting sensitive informationover public data networks is like writing your most personal secrets onpostcards. Probably nobody will take the time to read a postcard as itmoves through the postal system, but what if they do? And in a worldwhere everyone writes their most personal secrets on postcards, what canwe say about someone who wants an envelope? Is that person a spy? Acriminal? Maybe worse?

Right now, people who rely on SSL/TLS andother electronic transport security mechanisms for end-to-end emailsecurity are just like someone who writes secrets on postcards and theninsists that the mail trucks be armored. The journey from your home tothe local post office is absolutely secure, but the real security riskis when the postcards are unloaded off the armored truck. And what aboutthe odd, occasional message that actually uses an envelope? We’ll setthat aside for ‘special processing….’

Today, we rarely usepostcards. Even the most mundane messages are placed in envelopes. Inthe real world, end-to-end security of postal mail is the default; inthe digital world, end-to-end security of email messages is theexception, difficult to set up and perhaps even makes the user of suchtechnology a suspect.

We designers should consider end-to-endsecurity as a base function and not as an ancillary feature of oursystems – all systems and not just email. And for everyone else, perhapsit is time to invest in a box of envelopes.

Part 1: What does security really mean?

Part 2: Tampering with easy targets

1. For more background on the CAI Triad, see Perrin, Chad, The CIA Triad , TechRepublic, June 30, 2008. Also background on CIA Triad and general security under Information Security at Wikipedia.

2. General information on the OSI Model .

3. We are not discussing everything about each layer. For a more detailed presentation on the Microsoft website, see The OSI Model's Seven Layers Defined and Functions Explained .

Ben Smith joined the firmware engineering team at Maxim Integrated in 2003. Since then, Ben has designed hardware and software systemsthat made their way into the company’s products. Currently, Ben isengaged in product development for Maxim’s Smart Grid group. He is theholder of eight U.S. patents and has a BSEE degree from MissouriUniversity of Science and Technology.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.