As the discussion of internet security rages, you may have noticed that much of the conversation focuses on TLS (aka Transport Layer Security) vs. so-called end-to-end encryption in the application layer.

What the heck does it mean, and what difference does it make? We’ll cover this quickly because our focus will be on yet other layers of security. And the best way to set all this up is by reference to the standard network stack. The app-vs-TLS debate focuses on where the security should happen.

TLS happens on the transport layer, layer 4, as a supplement to TCP. If you use UDP, then there’s an analogous DTLS protocol – still at layer 4. App-level encryption, on the other hand, means that, as a system builder, you take ownership of security as an intrinsic part of the application. Yeah, that’s more work, which is why it’s easier (and, presumably, cheaper) to rely on the built-in, ready-to-go TLS service at layer 4.

The benefit of rolling your own is that you can do what you want – stronger or weaker than TLS. If the government mandates a back-door into common protocols like TLS, then that backdoor won’t help with your own app-level security. So, in theory, your data is more secure – if you do it right. If someone hacks any of the lower-level security protocols, they’ll get to the payload – but the payload itself will be encrypted, so it doesn’t do anyone (including the government) any good.

All of the prior discussions we’ve had on security – especially with respect to keys and other artifacts – revolve around TLS. I’ve generally been aware of this thing called “IPsec” for a long time, but it hasn’t come up in any discussions I’ve been aware of, so it’s merely floated around the back of my brain like some creepy lurker.

I was shaken awake, however, in a Linley Processor Conference presentation by Inside Secure that discussed yet another protocol: MACsec (IEEE 802.1AE). It was a completely new one for me (finding the limits of your knowledge is one of the fun things about this job). That forced my reconsideration of the role of IPsec and stimulated the question, do you need to run all of these at the same time?

The honest answer is that you could be running all of these, but it’s not likely to be within your awareness in the way that TLS is, since TLS can be invoked by the application. These other ones aren’t. But let’s dig into each – IPsec and MACsec – first to see what they are and then to see where they’re used.

Layer 3 Security

IPsec, as the name suggests, works with the IP protocol in a manner analogous to how TLS works with TCP. There are a number of ways it can work, depending on whether your goal is to ensure message authenticity or to protect the payload from prying eyes.

At its simplest, IPsec adds an authentication header that, more or less, gives a hash of the contents. When receiving a packet, that hash can be recalculated and compared to the transmitted hash to see if the contents were altered in transit.

The protocol is selective about what it includes in the hash, however, since, as the packet travels through the network, some fields (next hop, time-to-live, etc.) may change. So those fields are excluded from the hash.

You can go further and encrypt the payload, but, here again, there are fields that it won’t encrypt (or else the packet couldn’t get through the network). If you really want to protect the entire original packet, including all fields, then you can use “tunnel mode.” In that situation, the entire packet is encrypted and wrapped into a new IP packet; it’s the headers of that external IP packet that facilitate navigation through the interwebs.

One of the critical aspects of any of these protocols is key management. We looked at that more extensively for TLS, which uses asymmetric keys to set up a session between two nodes. Critically, the two nodes can set that conversation up by themselves, without the need of a third server (although an authorization server might be involved). This process is based on the RSA algorithms, although ECC (and possibly, eventually, “algebraic eraser”?) let us do the same thing with less burdensome computing.

But IPsec doesn’t use asymmetric keys; it uses symmetric keys. We saw that TLS can also use a symmetric approach like AES for encrypting bulk contents, but those keys are exchanged as part of the asymmetric key exchange, so everything is protected. If you don’t start with that asymmetric exchange, then how can you get keys to where they’re needed?

The important thing about asymmetric approaches is that messages sent and received are encrypted with different keys. The key exchange provides the keys for encryption as public keys, while the keys for decryption remain private; that’s how the math works. But with IPsec, both sides use the same key. That key must, therefore, remain private. If it’s going to remain private, and, if you’re not doing this exchange under the protection of some higher-level key (in the way that TLS is), then how can you exchange keys without someone snooping them along the way?

There are several alternatives available for managing IPsec keys. The most basic is Diffie-Hellman – a venerable approach. It also has a public/private character to key components, but different from RSA. The easiest way of describing it is through color mixing, as described in Wikipedia’s article on Diffie-Hellman.

To start with, the two sides will share a common artifact. Then they’ll each pick a private artifact to combine with the shared artifact. Call the shared piece S and the private pieces P1 and P2; these are then combined into C1 and C2. C1 and C2 are then exchanged. Now one side has received C2=S+P2. It combines it with P1 to get K1=C2+P1=S+P2+P1. The other side takes C1=S+P1 and combines with P2 to generate K2=C1+P2=S+P1+P2 – which is the same as K1. In other words, without sharing the private components, they both end up with the same key

I used “+” to indicate the combination, and, of course, it’s not strictly addition. But, critically, the operations used are commutative. That ensures that K1 ends up being the same as K2.

By Dav-FL-IN-AZ-id – Own work. Improved version of this file: http://commons.wikimedia.org/wiki/File:Diffie-Hellman_Key_Exchange.jpg, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=16969730

An alternative to this approach is to use the Internet Key Exchange (IKE) protocol, which leverages X.509 certificates – either “pre-shared” (meaning somehow manually put into the system) or distributed via DNS servers (as a trusted source). Ultimately, Diffie-Hellman is part of this process as well.

Then there’s yet another alternative, called Kerberized Internet Negotiation of Keys (KINK). This involves a third server that independently authenticates and sends keys to the two nodes that need to talk. And, just in case you haven’t had your fill of acronyms yet, it’s worth noting that all of these approaches operate under the overarching auspices of the Internet Security Association and Key Management Protocoal (ISAKMP).

Layer 2 Security

Securing layer 2 means securing the most common layer-2 protocol: Ethernet. And I’ve seen a couple of ways the scope of the protocol has been described, and these definitions rely on two components of a LAN: the hosts (i.e., the things we plug into the network) and the switches that deliver packets to their destinations.

I’ve seen some sources say that MACsec is only for host-facing traffic – that is, traffic between a switch and a host. Others speak of two (actually three) modes, depending on whether traffic is between switches or between a switch and a host. We’ll assume the latter for this discussion.

There’s also a separation between the control plane and the data plane. For those new to that notion, the data plane involves typical traffic trying to get from here to there. It has to be processed as fast as possible to keep up with the flood of packets (and the hardware processing the most common such packets is, in fact, referred to as the “fast path”).

The control plane, meanwhile, handles the less-common tasks required to manage the connection – key exchange being an example. Because it’s less common, it takes place (along with less-common data packet types) on the “slow path.” Often the fast path is executed by purpose-built hardware, while the slow path is handled by software.

MACsec protects the control and data planes with separate keys, with the control-plane key referred to as the CAK and the data-plane key as the SAK. There are three modes possible.

Static mode involves a “pre-shared” CAK. In other words, your IT guy walks around to all the switches and ensures that they have the same key. Given that this is a LAN protocol, this may actually be manageable, since all the switches will be relatively close to each other. There is then a protocol that lets the switches decide which amongst them will act as the key server; that switch then creates the SAKs that encrypt payload data. The SAKs are periodically renewed.

Dynamic mode is for switch-to-host (or –endpoint) connections. It involves a so-called AAA (for Authentication, Authorization, and Accounting) exchange with a main server via the RADIUS protocol. (Aren’t you glad there’s not a quiz at the end of this?).

The server independently sends CAKs to both ends of the link (which… I guess would mean that it has to go through the link to get to the other end of the link… unless there’s a completely separate network connection between the server and endpoint). The endpoint and switch then start their session by showing that their keys match. Then they can exchange SAKs.

The third mode is apparently not encouraged; it’s called “static SAK” mode. Your IT maven manually installs the same pair of passwords in each node on the network; on some agreed-upon schedule, the nodes switch between the passwords.

I have to say that, looking at the various MACsec documents, there is a bewildering number of keys involved to independently protect traffic between servers, switches, and hosts. You’ve got a KEK as key whose purpose is to protect the SAK as it’s sent from the key server. There’s yet another ICK that provides an integrity check on the SAK. Some keys serve only to generate other keys. And so on. I gave up trying to flesh it all out, because, for the most part, we don’t need the details, as we’ll see. But at least we get a flavor.

Which of These to Use?

So, as a system designer, are you totally freaking out about the possibility that you might have to work all this stuff into your systems? Heck, TLS gets enough push-back. Now all of these too?

Well, yes and no. Yes, they may be involved in the transport of your data, but, for the most part, you may not have to worry about the details. Here’s why, thanks to some conversation with Inside Secure.

IPsec was conceived largely for protecting data that’s going out onto a WAN. That means gateways. Packets leaving your building are protected by IPsec as they leave, with all the IPsec wrappings being removed as it enters some other building via its gateway.

So, even if you’ve protected your data via TLS or your own secret sauce, your traffic may undergo yet more security as it crosses the WAN. You have no control over that; that’s a matter for gateways to negotiate, and network edge nodes – like IoT devices – aren’t involved. If you’re designing an IoT edge node, that node will likely not see IPsec. If you’re designing an IoT gateway, on the other hand, then you should have it in the stack. Whether or not it’s there will not be visible to the application layer.

MACsec is for LANs. It’s implemented by IT folks, and, from your standpoint, it either happens or not according to whether the local IT department decided to secure the LAN. It happens only between switches or between switches and endpoints. To the extent of switch-to-switch traffic being protected, this is completely transparent to your application – your systems would have no knowledge of it. To the extent that it involves traffic to your edge node, then yes, that edge node would need to be able to participate in the protocol. The reality is that few LANs will require this. Further good news is that the calculations required aren’t too onerous.

So, why was it being presented at Linley? Because there’s one big exception: cars. The network within automobiles has historically been the CANbus. Critically, that bus protocol has no notion of security. There has been work on an updated CANbus, but, realistically, the industry seems to be leaving CAN behind entirely in favor of a simple version of Ethernet.

If the car runs Ethernet, we know that it needs to be secured, and so this would fall to the MACsec protocol. Fortunately, security IP companies like Inside Secure should be able to provide complete stacks that handle all of the transactions necessary to keep it working (with hardware elements typically being integrated by chip makers and software elements going to system makers). So, while it’s useful to have a feel for how it works, you shouldn’t have to become overly familiar with the details.

In general, your application is likely to need at least TLS. It’s not likely to need IPsec capability, but there’s a chance that it might need MACsec capability. But that latter would simply be to allow it to talk to a MACsec-enabled switch, which happens well below the level of your application. While your application would need to be able to talk to TLS, it wouldn’t talk to MACsec.

Within automobiles, MACsec is poised to secure the network (possibly as the highest level, although additional protections could be layered over it). Here again, though, it would be buried in the stack; the application code itself would not interact directly with MACsec.

In summary then:

• Any application-layer security would be created and implemented by you in your application, by definition.
• TLS will be the most common security for IoT devices, and it is invoked through the application.
• IPsec will not play a role in IoT edge nodes, only in devices that act like gateways.
• MACsec might play a role if a local LAN were to require it. This is, of course, impossible for you to control or predict (since each LAN is managed by a local IT group), so if you want to account for this possibility, then you’d need to include MACsec in the stack. The application layer wouldn’t specifically talk to the MACsec layer.
• For automotive Ethernet applications, network endpoints would need to implement MACsec. But, again, this would be transparent to the application.

More info:

Inside Secure MACsec

IPsec docs (via Wikipedia for enormous set of associated RFCs)

IEEE 802.1 standards (may require payment or registration)