On Improving Ethernet LAN Security - CiteSeerX

On Improving Ethernet LAN Security Rinat Khoussainov, Mikhail Bessonov, Pavel Gladychev, and Ahmed Patel Computer Networks and Distributed Systems Group Department of Computer Science, University College Dublin Belfield, Dublin 4, Ireland

ABSTRACT Despite many research and development efforts in the area of data communications security, importance of internal LAN security is still underestimated. This paper proposes a prospective solution for building of secure encrypted Ethernet LANs. The architecture presented allows for employment of the existing office network infrastructure, does not require changes to workstations’ software, and provides high level of protection. Keywords: LAN security, Ethernet, Architecture, Encryption, Public key cryptography. 1. INTRODUCTION Network security plays one of the key roles in the today’s overall security infrastructure [1]. Among other significant aspects of network security, protection of data in transfer gains additional importance due to the explosive growth of the network structure and ever broadening range of hardware and software technologies involved in communications. So far, designers of secure network systems have been mainly concerned with provision of protected communication over insecure Internet links leaving security issues within local area networks (LAN) out of the scope. Most efforts have been concentrated around either development of protected border network gateways, e.g., firewalls, encrypting routers, or design of application level protocols providing necessary security services, such as secure electronic mail, secure WWW connection (SSL), secure remote shell (SSH), etc. However, an insider can easily bypass border network protection of an organisation by simply

providing adversaries with a back-door access to the totally unprotected internal LAN. Besides, it may be required to restrict access to information being transferred via the local network to introduce various protection policies for sensitive data of separate users or organisational substructures. For example, accounts department may not want their financial data passed through the network to be read by employees from development divisions and/or vice versa. The use of specialised secure applications or protocols can resolve the problem, but it will need a significant effort on individual configuration and maintenance of the software and expensive qualified security personnel to ensure correctness of settings. Moreover, as this method requires individual approach to every single application on every computer in the network, there is always serious concern about possible misconfigurations or misuses made by ordinary users that can potentially lead to security leaks. An alternative way to guarantee confidentiality and integrity of data being passed via a local network is to apply security measures in the network interface devices connecting individual computers to the network. Thus, we prevent the physical possibility of sending unprotected data over the LAN. 2. BACKGROUND Virtually all of commercial and academic local area networks at the moment use the Ethernet technology for data exchange. Originated first by Xerox Corporation [2], it is now well standardised (e.g., by IEEE [4], ISO) and is supported by numerous hardware manufacturers. This situation is a natural result of obvious Ethernet advantages, such as cheap network equipment (i.e., network interface cards, repeaters, hubs, etc.), inexpensive network infrastructure (i.e., cabling system, interconnection devices, etc.), satisfactory performance (especially,

with use of modern high-speed technologies, like 100BASE-T [3]), and relative reliability. Unfortunately, the Ethernet has a number of disadvantages presenting a serious threat to the LAN security: 1. All stations in the local network share the same physical channel. This provides a passive attacker with excellent opportunities for eavesdropping as everything a computer sends over the network can be received simultaneously by all other stations connected to the same LAN. 2. No physical mechanisms are available to restrict time or duration of access to the shared network media. Thus, a single enemy connected to the network can easily disrupt functioning of the whole LAN even without breaking cable connections. 3. There are no ways in the Ethernet itself to authenticate message originator’s identity or to verify messages’ integrity. This allows an active attacker to generate counterfeit messages, to insert his own data into existing message streams, or to replay earlier eavesdropped packets. Possible consequences of these shortcomings comprise all kinds of security problems - from stealing of private information to unauthorised modification of important data. A traditional way to fight against the first problem and, to some extent, against the second one is to divide the Ethernet LAN into sub-segments using bridges. A bridge filters network traffic so that a packet addressed to a node within the same sub-segment does not cross the bridge. Therefore, an intruder can not listen to traffic between two stations in a different sub-segment. Still, communications within a sub-segment or across bridges are completely insecure. 3. REQUIREMENTS The common intention is to propose a solution that has all advantages of the Ethernet network mentioned above and, besides, satisfies to the following requirements to a secure LAN: •

Each node in the network can read only packets addressed to this node.

•

•

Each node in the network can verify the source of data, i.e., it must be able to acknowledge that the packet was indeed generated by the source node. Each packet addressed to a particular node may be accepted only once, i.e. the node must be able to detect an attempt of an attacker to send a valid packet, intercepted earlier, to the same node again.

Additionally, these requirements should be achieved without further complication of the existing network structure, i.e. they should not imply use of new complex protocols or implementation of specialised managing and/or monitoring devices. Moreover, ideally such a secure LAN should allow users to keep using their current applications without any changes and without employing the CPU, i.e., all improvements should be done below the physical interface with the network card. 4. RELATED WORK The research on network security started in the early 70s. The first encryption devices were used to protect network links between mainframes in the ARPANET. Examples comprise the PLI (Private Line Interface) encryptor developed in the early 70s by BBN (Bolt Beranek and Newman corp.), its successor, IPLI, updated to use TCP/IP, BCR developed by BBN together with Collins Radio, etc. However, those were mainly government-oriented proprietary products. They required use of certified COMSEC equipment, often were manually keyed, and saw very limited deployment. In the late 80s, IEEE started the SILS program to develop security protocols for LANs (IEEE 802.10 family [5]). It was oriented towards commercial, not just government, clients and thus had a model that allowed for selective encryption and/or integrity protection of packets. The NSA sponsored Secure Data Network System (SDNS) project [6] that brought together a variety of vendors that created the early SP3, KMP and MSP specifications. SP3 provided Network layer security services that included a tunnelling mode. SP3 is very similar to the IPSec working group ESP specification [7]. The Key Management Protocol (KMP) is similar to the

ISAKMP specification in concept, but used ASN.1 [8] for specifying the protocol formats.

provides security measures for communications between networks [12].

However, these standards were very generic and did not specify exact algorithms and methods used for encryption, key distribution and management. This led to various proprietary implementations that, sometimes, use only a limited set of security features provided by the protocols. For instance, the Security Association Identifier in IEEE 802.10 is often used solely for routing purposes (e.g., Cisco’s VLAN products).

Although these systems provide necessary protection for networked data between subsegments, they have a number of obvious disadvantages:

A number of commercial devices were proposed in late 80s – early 90s including NES from Motorola [9], DESNC from DEC, Xerox Encryption Units (XEU) from Xerox corp., Trusted Interface Unit (TIU) from Wang corp. Most of those products were either OSI layer 2 (Ethernet IEEE 802.3 [4]) or layer 3 (IP, IPX, etc. [2]) network encryption devices. However, these products did not gain a broad popularity. At present, almost all secure LAN products provide solutions for protection of selected LAN segments at the Network layer (IP, as a rule) by encrypting all network traffic going outside the LAN segment. This allows computers located in different LAN subsegments to communicate with each other over insecure inter-segment links that may possibly be Internet trunks. The encryption is made transparent to the end communicating stations so that they may treat two different LAN sub-segments as a single secure virtual LAN (VLAN). Examples of such systems include: • •

•

ED8000RL by Baltimore - Ethernet LAN encryptor using the RAMBUTAN II Chip from CESG [10]. MELWALL A3000 Encryption Adapter by Mitsubishi - This LAN encryption adapter provides encrypted communications when it is added to an existing router or server. It supports IP, IPX, is transparent to application and network components (excluding routers and firewalls). Keys and configuration are managed by a remote-key distributor [11]. KryptoGuard LAN by KryptoKom - The hardware system KryptoGuard LAN

•

•

•

They are expensive and bulky. A customer can not use such a device with every single PC in a LAN. Therefore, there are still possibilities for an intruder to violate LAN security within a selected sub-segment. These products need noticeable amounts of configuration that, when done incorrectly, can eliminate the effect achieved by securing hardware. Often, they have complicated centralised key management and require special management and client’s software. 5. CRYPTO-ETHERNET NIC

The proposed solution is a secure Ethernet network interface card. Such a device combines conventional Ethernet NIC functionality with an encryption engine on a single PC card. This card has the standard interface with a PC (e.g., Novell NE2000 compatible via PCI or ISA bus) and produces standard Ethernet frames on the output. Encryption is made absolutely transparent to user applications so that even network drivers need not distinguish whether a usual Ethernet NIC is used or a cryptoprotected one. The standard output interface with the channel media, e.g. 10BASE-2, 10BASE-T, or 100BASE-T, allows the crypto-Ethernet NIC to use the existing office network infrastructure including cabling system, hubs, switches, bridges, etc. These features provide seamless transition from the present insecure LAN to the highly protected encrypted Ethernet by simply replacing installed NICs only. The following list enumerates benefits of the cryptoEthernet NIC: •

As no unprotected data can physically be sent by a PC with the crypto-Ethernet NIC, the user need not worry about proper configuration of security features for every single installed program. Yet, he may be

•

• •

•

sure that nobody will read his packets passing through the network. A unique identifier in each network packet prevents an active attacker from duplicating frames. The mechanism of digital signatures [13] assures a receiving node that the authorised sender originated the packet. Since all encryption is done inside the NIC, no additional CPU resources are spent for security. The cards use decentralised key management. Therefore, no key distribution authority is required. This also increases reliability of the whole network. The use of public key cryptography [13] protects data from being read by anyone but the destination network node. Private keys are generated inside cards. Thus, the only way to get hold of the private key of a NIC is to tamper the hardware. Yet, this will open the key for one node only.

Data and key exchange Each board has a pair of private and public keys and it knows the public master key. Data are passed through the network in the standard Ethernet frames (e.g., IEEE 802.3). However, instead of pure data each frame contains the following fields: 1. Randomly generated session key K encrypted with the public key of the destination node. 2. MAC address of the destination node. 3. MAC address of the source node. 4. Packet ID including a sequence number of the source node. 5. User data. 6. Hash for fields 2-5 digitally signed with the private key of the source node. Fields 2-6 are encrypted with key K using an approved symmetrical key algorithm (e.g., GOST, Triple DES, IDEA, etc. [13]). Only the destination node can decrypt key K and, hence, the whole packet. The receiver can verify the sender’s signature to be sure that the source address is genuine. The packet ID consists of two parts. The first one is a random number generated by the originating NIC upon power up. The second part is the value of the

sequence counter in the NIC. This counter calculates the total number of packets sent by the NIC. Each card saves the ID of the last received packet from the particular destination. Therefore, a NIC can easily detect duplicated packets, as every subsequent packet from the same destination node must have a bigger sequence number with the same random part. Frames with improper IDs are dropped and the receiving NIC asks the sender for the actual current value of the packet ID. This allows for detection of the situation, when the sender’s packet ID changes after the “cold” restart (power off – power on). Consider the situation, when an attacker has intercepted a packet and wants to send it again to the same station. Then, he has to wait until either the sequence counter overflows or the random part of the ID matches the one in the intercepted packet. The probability of both events is miserable, if the ID is large enough (say, 4 bytes for the sequence number and 4 bytes for the random part). When a node wants to know the public key of another station or its current sequence number (the packet ID), it broadcasts the following request: 1. Destination MAC address. 2. Public key certificate for the source station signed with the private master key. 3. Packet ID including the sequence number of the source node. 4. Nonce (a sequence of randomly generated data). 5. Hash for fields 1-3 signed with the private key of the source node. In response, the targeted station broadcasts its public key and the current sequence number in the following form: 1. Public key certificate for the source station signed with the private master key. 2. Packet ID including the sequence number of the source node. 3. Nonce received from the requesting station. 4. Hash for fields 1-3 signed with the private key of the source node. The receiving station can always verify validity of the public key by verifying the master key signature. Nonce prevents an active attacker from replaying of public key certificates distributed earlier to falsify

the current packet ID of the responding NIC. To reduce the number of requests for public keys, each NIC has a cache of public keys and last received sequence numbers for different source nodes. Thus, it has to send request for a public key only when it is not in the cache. Key management The public and private master keys are kept in a strict secret inside a special key management unit – KMU. This device can communicate with NICs either through the network or via a bus connector. The KMU is used to change and certify public keys of other boards in the network. Here is how it looks when done via the network: 1. The KMU sends a request for changing keys to a selected NIC. 2. The NIC responds with a request to sign the new public key. 3. The KMU sends the new public key certificate to the NIC. 4. The KMU requests the public key of the selected NIC to check that the keys are changed. The KMU may repeat steps 1 and 4 several times in the case packets get lost. By analogy, the NIC may repeat step 2. The request to change keys has the following fields: 1. Randomly generated session key K encrypted with the current public key of the destination node. 2. Destination MAC address. 3. Source MAC address. 4. Randomly generated request number. 5. Hash of fields 2-3 digitally signed with the master private key. Fields 2-4 are symmetrically encrypted with the session key K. Upon receiving of such a request, the destination NIC generates new pair of public and private keys, saves the received request number, and sends the new public key to the KMU for certification in the following form: 1. Randomly generated session key encrypted with the public master key. 2. Destination MAC address. 3. Source MAC address.

K

4. 5. 6. 7.

Packet ID. Request number. New public key for the source node. Hash of fields 2-6 digitally signed with the old private key of the source node.

Fields 2-7 are symmetrically encrypted with key K. If all data (particularly, the request number and the signature of the responding NIC) is correct, the KMU responds with the new certificate for the board: 1. Randomly generated session key encrypted with the new public key of destination NIC. 2. Destination MAC address. 3. Source MAC address. 4. Request number. 5. Certificate for the new public key of destination node digitally signed with private master key. 6. Hash of fields 2-5 digitally signed with private master key.

K the

the the the

Fields 2-6 are symmetrically encrypted with key K. If all data (the request number and the KMU signatures) is correct, the destination NIC changes its public and private keys to the newly generated ones. Obviously, for the very first time a NIC has no public key signed by the KMU. Therefore, to make the KMU sure that it communicates with the selected card, but not with an enemy, the very first certificate has to be sent to the NIC via the bus connector (e.g., PCI). When communicating via the bus connector, the KMU need not check the signature of the NIC, as it trusts to the security manager, who connects the board to the KMU. After that, the NIC can be reprogrammed over the network. For general compatibility, some of standardised secure frame formats, such as IEEE 802.10 [5], may be used to pass the information fields discussed above. Hardware architecture The crypto-Ethernet NIC hardware is depicted in Figure 1. It has the following components:

•

•

• • •

•

•

Ethernet transceiver implements all standard data link layer processing including CSMA-CD transmit and receive operations, IEEE 802.3 Auto-Negotiation algorithm [4], and physical layer scrambling/descrambling (e.g., Manchester encoding or 100BASE-T TP-PMD). Encryption/decryption engine provides both public and symmetric key data encryption/decryption. It also routes control data (i.e. data from key exchange and key management packets) to/from the core logic module. Non-volatile RAM (flash) stores the board’s public and private keys and for the public master key. Transmit and receive FIFOs are used to buffer network data. Cache for public keys and sequence numbers (packet IDs) is used to encrypt data for other network nodes and to detect duplicated Ethernet packets. Interface with the network media includes components for interconnection between onboard chips and the physical media. Usually, external power transformers perform these functions. Bus interface, e.g., a PCI controller, provides interconnection with the PC bus. 100BASE-T

Ethernet transceiver

Key cache

Decryptor Encryptor

Tx FIFO

Core logic Rx FIFO

Bus controller

NVRAM

Possible ways for building the board may include productive combinations of existing Ethernet chipsets with high-performance FPGA-based encryptors and core logic. 6. PROSPECTIVE EXTENSIONS The following are possible further extensions to the crypto-Ethernet to provide even higher level of LAN security: •

•

Hiding information routes in the LAN – In order to prevent an eavesdropper from analysing existing information routes in the LAN, each packet can be sent with the broadcast Ethernet address. Only the destination node will be able to decrypt the frame properly, while an intruder will not be able to figure out the actual destination address from the encrypted packet. However, this will require periodical broadcasting of the current public key by each node in the network. Otherwise, a node could not distinguish between a packet addressed to another node and a packet addressed to this node but encrypted with an old public key. “Paranoia” – This combines the hiding of information routes with keeping the keys inside a smart card that is inserted directly into the NIC and using of tamper-resistant hardware. The owner detaches the smart card, when he leaves the office, so no one is able to send data via the LAN using somebody else’s name as the originator of data. However, this will require more complicated hardware on the Ethernet board. 7. CONCLUSIONS

Despite many research and development efforts in the area of data communications security, it appears that importance of LAN security is still underestimated. However, an unprotected office LAN may easily abandon often quite expensive attempts to protect the network only at the borders.

PCI

Figure 1: Hardware architecture

In this paper, we analysed the current situation with and existing architectures for LAN security and

proposed the prospective solution for building of secure encrypted Ethernet LANs. The architecture presented employs the existing office network infrastructure and does not require changes to user applications and even to the OS software (i.e., device drivers, etc.). It is absolutely transparent to the end user, reliable, and provides high level of protection.

8. REFERENCES [1]

[2] [3]

However, it is worth to mention here that there are a number of unresolved aspects in the system described that require further consideration: •

•

Support for a list of compromised public key certificates (certificate revocation list [14]): It would be undesirable to have a centralised list. A possible solution for this problem is to change the MAC address of the compromised board. However, it is unclear how long it will take to update the new MAC address at all upper levels of the application network stack. Besides, an attacker can impersonate the node at the network level using the old MAC, if the original PC is turned off or disconnected (i.e., simply by responding onto ARP requests for the IP of the disconnected PC). Implementation of crypto-Ethernet bridges, when we use the hiding of information routes: As a rule, Ethernet bridges improve performance of a LAN, as they protect network sub-segments from traffic belonging to other segments, thus, reducing the number of collisions. However, a conventional Ethernet bridge will not be effective in the case of the hiding of information routes, as all packets use the broadcast Ethernet address. Therefore, large encrypted LANs can experience serious performance problems.

These issues form directions for future work on improvement and enhancement of the cryptoEthernet. Certainly, authors are looking towards implementation of the whole system in hardware to obtain practical performance results for the device. This will also allow us to clarify the hardware structure and, possibly, to unveil other problems related with the proposed architecture.

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

Sead Muftic. “Security Mechanisms for Computer Networks”. Ellis Horwood Limited, 1989. A.S. Tanenbaum. “Computer Networks”. Third Edition. Prentice-Hall Inc., 1996. IEEE 802.3u-1995: “Local and Metropolitan Area Networks: Media Access Control (MAC) Parameters, Physical Layer, Medium Attachment Units and Repeater for 100Mb/s Operation”. IEEE Standard Press, 1995. IEEE 802.3-1985: “Local Area Networks: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) -(ETHERNET)”. IEEE Standard Press, 1985. IEEE 802.10-1998: “IEEE Standard for Interoperable LAN/MAN Security (SILS)”. IEEE Standard Press, 1998. D. Russell and G.T. Gangemi. “Computer Security Basics”. O’Reilly & Associates, Inc., 1991. S. Kent and R. Atkinson. “Security Architecture for the Internet Protocol”. RFC 2401. November 1998. D. Steedman. “Abstract Syntax Notation One (ASN.1). The Tutorial and Reference”. Technology Appraisals Ltd., 1993. “Motorola Network Encryption System (NES)”. Motorola, 1998. http://www.mot.com/GSS/SSTG/ISSPD/Netw ork/NES/index.html “ED8000RL LAN Encryptor”. Baltimore, 1999. http://www.baltimore.com/products/see_nets_ and_govt/mn_sec_nets_05.html “MELWALL network security systems”. Mitsubishi, 1996. http://www.mitsubishi.com/ghp_japan/misty/ 3300net.htm “KryptoGuard LAN”. KryptoKom, 1994. http://www.kryptokom.de/english/products/in dex.html B. Schneider. “Applied Cryptography: protocols, algorithms, and source code in C”. Second Edition. John Wiley and Sons, 1996. R. Oppliger. “Internet and Intranet Security”. Artech House, Inc., 1998.