Using Ethernet protocols requires the proper encryption schemes.

In Part 1, we looked at some do’s and don’ts on encryption. In Part 2, we introduced the concept of message authentication to increase the protection offered in our security system. In many applications, the encryption and authentication of messages is sufficient to protect the valuable data. However, as attackers get more sophisticated, it’s necessary to add more features to the security. I always think of it as adding layers of security, like the skins of an onion. If a malicious agent overcomes one of the protective layers, then he is confronted by another. Here, I’ll discuss how Ethernet systems can have additional features added to an embedded IP core.

Ethernet transmission has grown to dominate communications because it’s both efficient and extendable to high-speed transmissions. An extension to Ethernet has been specified that adds a whole new raft of security measures under the IEEE 802.1AE specification, which features an integrated security system that encrypts and authenticates messages as well as detecting and defeating a range of attacks on the network. The spec is known as the Media Access Control Security standard, or more commonly, MACsec.

MACsec provides three basic security capabilities above and beyond the AES-GCM encryption on which it is based. First, MACsec adds key management with the concept of secure channels allowing different keys to be used for different communications links. Second, MACsec provides replay protection, preventing an attacker from compromising the system by capturing a valid packet and sending it again. Third, as well as blocking attacks with encryption, it provides statistics gathering to allow an attack to be detected and higher level measures to be taken to respond to it, e.g., investigating its source.

A MACsec IP core is a complex hardware design for embedding into an FPGA that works at Layer 2. The MACsec scheme is based on network nodes that form a set of trusted entities called Security Entities (SecY). Each SecY is allocated a unique secure channel for transmitting packets. Up to four security associations (SA) can be linked with that channel, each of which has a key. So every node uses a different key, which means that only nodes that are provided with that key by the System Administrator can decrypt packets sent by that node.

MACsec decrypts and verifies each packet when it leaves an Ethernet LAN. Therefore, a packet crossing a bridge between two LANs would be decrypted as it left the first and encrypted again as it entered the second, so the system is termed a hop-by-hop scheme. This means that all packets can be authenticated. Authentication is achieved by appending data to the end of the message in a field called Integrity Check Value (ICV). This works with the encryption key to authenticate the frame, including the header and MACsec tag, to assure that not even the frame’s source or destination address could be manipulated.

The decrypted message (sometimes called plaintext) is now available inside the machine for further optional processing by upper layer software. This might be deep packet inspection to identify if the packet included malware or viruses. The plaintext packets can also be fed into a traffic manager that regulates the outflow of data or decides which packets to drop if there’s an overload situation. Bear in mind that adding the Security Tag (SecTag) and ICV to the packet means that the link’s maximum capacity is reduced. When the system is ready to forward the packet, it’ll be re-encrypted, but this time using the secure channel of the local machines transmit SecY.

In addition, the SecY collects and records a range of statistics at the packet level. This allows the systems administrator to see how many packets were rejected by MACsec for a number of different reasons. For example, they may be rejected because they failed integrity checks due to an invalid decryption key or used the wrong key. This can help to identify and defeat attempted Denial of Service (DoS) attacks on the network. Each packet is also numbered, and if packets arrive that have already been processed, this replay might indicate what’s called a man-in-the-middle attack. Again, the MACsec statistics can record and flag an attempted replay event.

The IP core uses the Secure Channel Identifier (SCI) in the MACsec packet’s SecTag header to retrieve the appropriate key before decrypting the message. Some IP cores support multiple virtual SecYs that enable one Ethernet MAC to have multiple MACsec SecYs associated with it for applications like multi-access LANs. So the equipment can look like multiple sources of messages (each with a unique encryption key) to the system. This facilitates partitioning a system into logical domains so that, for example, accountancy data isn’t available to factory staff, and engineering designs are only available to authorized people.

MACsec was originally envisioned to support metropolitan area networks, but it’s now also finding use in a range of applications such as data centers and the cloud, which increases the overall demand for an embedded FPGA-based solution.

The reason that engineers choose to use Layer 2 connectivity is to achieve high speed with minimal latency and overhead data in the packet. A hop-by-hop design also facilitates packet inspection in a firewall at the organizational boundary where an end-to-end encryption system like IPsec would pass encrypted data through the firewall and shield it from inspection. A MACsec core includes an AES-GCM crypto engine and additional logic to perform the protocol processing, key look-up, statistics collation, and storage functions. Core speeds can easily reach 10 Gigabit Ethernet and will scale up as Ethernet speeds increase. Another important consideration is that FPGAs are dramatically more power efficient than using a software solution to perform algorithms like cryptographic functions.

In Part 4, I’ll discuss how an embedded IP core can accelerate a commonly used Layer 3 technology called IPsec.

Paul Dillien has worked with Algotronix Ltd. covering sales and marketing for the past six years. He previously worked in the FPGA industry, and is the author of The FPGA Market report. Paul is a Chartered Engineer and has worked in strategic and tactical marketing roles for leading U.S. and UK semiconductor companies and has specializations in competitive analysis and negotiation.