关于PLC英文文献.doc

Security in OPERA Specification based PLC Systems
Guiomar Corral, Josep M. Selga, Agustín
Zaballos, David González-Tarragó
Enginyeria i Arquitectura La Salle-Universitat Ramon
Llull (URL)
Barcelona-Spain
{jmselga, guiomar, zaballos, dgonzalez}@salle.url.edu
Luis M. Torres
Design of Systems on Silicon (DS2) SA
Valencia, Spain
Berthold Haberler
Linz Strom Gmbh
Linz, Austria
Abstract— Power Line Communication (PLC) is a broadband telecommunication technology that enables the use of the existing electricity networks for high speed data transmission purposes. European project OPERA Open PLC European Research Alliance) is a project whose strategic objective is to push PLC technology in all the different and relevant aspects. Within this framework, security is an important aspect thatshould be taken into account and integrated into thespecifications from the very beginning. The project was scheduled in two phases with a duration of two years each. Phase1 produced a first PLC specification, including security.Phase2 produced an improved specification which was
submitted to the IEEE as the OPERA PLC proposal within thecontest organized by WG P1901. The paper presents the studies related to security in the PLC access technology made within this process that led to the second security specification of OPERA. Finally, an analysis of this specification isperformed.
Keywords- access technologies; PLC; communications network security; OPERA project.
I. INTRODUCTION
Power Line Communication (PLC) is a broadband telecommunication technology able to use the existing electricity networks for data transmission purposes, allowing any user connected to the power grid to benefit from Information Technology based services easily. The strategic objective of project OPERA (Open PLC European Research Alliance) [1] is to push PLC technology in all the different and relevant aspects (standardization, technology improvement, installation tools and processes, telecom services, dissemination,..) so as to allow the technology to become a competitive alternative to offer broadband access
service to all European citizens using the most ubiquitous infrastructure, the electrical grid, which covers not only the last mile but also in-building and in-home spaces.
Security has been sometimes neglected when defining standards. In fact, the initial specifications of many existing standards in related areas such as wireless [2] have been shown to have many vulnerabilities that have had to be fixed
in further specifications, not without trouble for the market. Unfortunately OPERA is not different. The specification produced in OPERA Phase1 [1][3] presented also several vulnerabilities that have been fixed in OPERA Phase2
specification [4]. The writing of this second specification by OPERA was inscribed in some way in the process created by the IEEE WG P1901 with the intention of producing an IEEE standard for PLC access and in-home networks. In fact, deliverable D27 [4] is the proposal submitted by OPERA to the IEEE within the mentioned process.
The presentation of the OPERA Phase2 specification and the related security analysis are the objectives of this paper.
The contents of the present paper is organized as follows. Section II introduces the security requirements to be complied by the specification; Section III succinctly describes the OPERA Phase1 specification; Section IV analyzes the level of compliance of this specification; Section V outlines the basic ideas for creating a new specification; Section VI contains a security analysis of the new specification and, finally, there is a conclusions section.
II. SECURITY REQUIREMENTS
The basic objectives of any security specification are to achieve confidentiality, integrity, mutual authentication and availability. These objectives can be threatened by a series of attacks.
Confidentiality is interpreted as the privacy of transactions between two nodes from all other nodes. It is made possible by the techniques of cryptography. The most relevant known attacks against confidentiality are [5]: brute force attack, dictionary attack, eavesdropping attack and precomputation
attack.
Data integrity refers to ensuring that data has not been altered during the transmission process. Malicious manipulation and forging of messages are different attacks against data integrity. It can be prevented by the use of Message Integrity Checks (MIC).
The function of admission control is to guarantee that network resources are only accessed by authorized devices which are who claim to be. Thus, it contains two aspects, one is authentication of the stations and the other is authorization to access the resources. Normally both functions are combined in a single access protocol. Different attacks against admission control are the following: identity
usurpation, replay attacks, man-in-the-middle attacks, hijack of MAC addresses, session hijacking, masquerading, malicious device and message interception.
Availability refers to the prevention from accessing and using the network by some unauthorized party. Attacks to availability are called Denial of Service (DoS) attacks. The security requirement demands that the specificationmust be robust against these attacks as well as to any other possible attack.
III. SUCCINCT DESCRIPTION OF OPERA PHASE 1 SECURITY SPECIFICATION
OPERA1 Specification [2][3] is aimed for PLC access networks and defines three types of devices, Head-End (HE), Repeaters (TDR, Time Division Repeaters) and Customer Premises Equipment (CPE). They typically form a multi-hop system like the one depicted in Figure 1.
Confidentiality in OPERA1 is achieved by the use of DES[6] and 3DES[7] encryption systems. The admission control process involves three messages: an Access Frame that invites nodes to join the network, a contention Access Reply Frame that is an answer to the Access Frame and arequest to join the network and, finally, an Access Protocol Packet that basically informs about the success or failure of the admission control process. It is, thus, a 3-wayhandshake.
The MAC layer is based on token passing controlled by the HE. The HE organizes and controls the downlink data frame for all data transmission from the HE to the CPEs. It also assigns the access duration for each CPE, which allows
the uplink transmissions from the CPEs to the HE [2][8].
The data frame structure used in the uplink and downlink transmissions is illustrated in Figure 2 [8]. Each frame begins with a “token announce” (TA). The TA is broadcasted in the clear over the network to inform the other stations about the upcoming transmission. The TA is followed by a number of bursts, each one addressing a specific CPE. Each burst consists of a burst header followed by several OPERA packets (basically similar to Ethernet packets). An interpacket header is inserted to separate two continuous packets or fragments of packets in a burst. The last symbol of the data frame carries a “Data Token” (DT).
IV. OPERA PHASE 1 SPECIFICATION SECURITY ANALYSIS
The most relevant vulnerabilities of OPERA Phase1 specification that have been detected are the following
Vulnerability 1: It uses DES [6] with a 56/64 bit key which has been reported to be breakable. It has even been phased out by FIPS (Federal Information Processing Standards). Brute force attacks as well as other attacks are feasible.
Vulnerability 2: Admission control is only based on MAC addresses. Since these addresses are necessarily sent in the clear over the PLC channel, they can be supplanted. Hijacking and identity usurpation are easy to deploy.

Vulnerability 3: There is no mutual authentication. There is no provision to authenticate masters. A malicious masterand man-in-the-middle attacks are possible.
Vulnerability 4: The OPERA1 proposal does not contain any security Message Integrity Check (MIC) that could preserve data against tampering.
Vulnerability 5: Channel Estimation MPDUs are never encrypted and include no MIC. Thus they can be manipulated to cause a DoS attack.
Vulnerability 6: Another possible data integrity attack is just to change the position of different blocks in the payload. This would be unnoticed due to the independent ciphering of each block. It is a permutation attack.
Vulnerability 7: It uses Diffie-Hellman algorithm without any protection against Man-in-the Middle attack. Although this may seem a big number of vulnerabilities of the OPERA Phase1 specification, the situation is common with other technologies, the most relevant of them being the early IEEE802.11 security specification [1].
V. OUTLINE FOR A NEW OPERA SECURITY SPECIFICATION
Upon the view of the previous vulnerabilities it was clear that a new specification was needed and that it should provide stronger encryption, stronger integrity and a new admission control method really securing authentication and authorization.

A- Stronger encryption.
It can be obtained by the use of AES [9] or 3DES [7] ciphering algorithms. Neither of both has been reported to be cracked until today. For the new security specification the option chosen has been AES. The reason is that upon a careful comparison with 3DES it was clear that under many scenarios AES is less costly than 3DES. Another fact is that AES is recommended by IEEE and that it is believed to be more robust than 3DES.
AES is a block cipher. To achieve confidentiality in messages of arbitrary length there are five options [10] called modes of operation. From these possible modes of operation the one chosen was the CTR mode because it can be performed in parallel (CFM and OFM modes do not allow this). Also it avoids some problems from the simpler ECB mode, it is well known and trusted (it has been used for more than 20 years) and does not raise Intellectual Property Rights (IPR) concerns as OCB does.
B- Stronger integrity.
From the variety of mechanisms generating a Message Integrity Check (MIC) the ones that support integrated confidentiality and integrity are specially interesting because they use one algorithm for both functions, thing that may
avoid hardware and software costs. So the decision was to use AES for both functions: confidentiality and MIC generation. The chosen method to perform integrated encryption and authentication was CCM (Counter with CBCMAC) as defined in RFC 3610 [11]. CCM combines CTR mode of encryption with the CBC-MAC mode of authentication. CCM has been used and studied for a long
time and has well-understood cryptographic properties. CCM uses the same encryption key for both processes but, in conjunction with other parameters, it leads to two separated keys.
The chosen values of the M and L parameters of CCM are:
M = 8; indicating that the MIC is 8 octets long.
L = 2; indicating that the length field is 2 octets.
The length of the MIC was chosen to be 64 bits since this is the minimum length recommended by [11]. Figure 3: Construction of an Encrypted Burst
The previous selections are coincident with those made in standard IEEE802.11i [12] for Wireless LANs. The main difference is that encryption and integrity are not applied over the same message. Encryption is performed over data bursts, which may contain several OPERA packets, while a MIC is generated for each OPERA packet (see Figure 3). The Burst header is authenticated but not encrypted. The OPERA packet header is authenticated and encrypted. This is done to improve efficiency in the very noisy environments typical to PLC channels. In case of error it is not necessary to retransmit the whole burst but only one packet. Another difference with [12] is that the OPERA specification does not support non robust options such as WEP or TKIP. This is possible because OPERA does not have to take into account IEEE802.11 legacy systems.
C-Admission control
With respect to admission control, the open possibilities were to define a specific protocol for OPERA or to use an existing standard. If such a standard existed it seems wiser the option to use it. Fortunately this standard exists and is
IEEE 802.1X [13], an IEEE standard for port-based Network Access Control in LAN, based on the EAP (Extensible Authentication Protocol) [14], that has been
adapted to be used in other environments such as wireless and which today is part of IEEE802.11i. Due to the adequacy and long time experience of this standard the decision was to make use of it in OPERA.
IEEE 802.1X defines three entities, Supplicant, Authenticator and Authentication Sever (AS) and allows foran authentication dialog after the two opening messages (EAP-Request and EAP-Response) and before the closing
message (EAP-Success or Failure). The three messages of the three-way handshake of OPERA Phase1 commented in Section III have similar functionality to the three EAP messages just mentioned. The approach taken in the new OPERA specification has been to keep the three messagesas defined in OPERA Phase1 for backwards compatibility.
The Authenticator is in charge of converting between

both formats. The process has been represented in Figure 4. The Authenticator translates messages B and D into the corresponding Radius over EAP messages and
decapsulates/encapsulates messages C, those belonging to the authentication protocol of choice.
A much major difference is that the Authenticator in IEEE802.11i is the Access Point while in OPERA can be the HE but also a Repeater.
This creates the difference that in OPERA the communication between the Authenticator, when it is a Repeater, and the Authentication Server (Which can be located at the HE or beyond it) is also transmitted over the PLC channel. This fact implies the need to send the messages encrypted, protected with a MIC, with the same rules as in the dialog between Supplicant and Authenticator, and encapsulated into OPERA packets.
Another difference is that the Supplicant can be a CPE or Repeater. So, a Repeater can be first a Supplicant and later Authenticator. A smaller difference is that the Access Protocol Packet may convey not only success or failure information but also indication of a failed dialog. The authentication dialog allowed by IEEE802.1X/EAP allows for the use of both shared secrets and certificates. This solves the problem of OPERA1 Phase1 of authenticating only on a MAC address basis.
The new specification of OPERA is quite similar to the IEEE 802.11i and it complies with the RSNA (Robust Secure Network Association) defined in it. Nevertheless, the multihop nature of PLC, as shown in Figure 1, is a major
difference with respect to wireless. In fact IEEE802.11i does not take into account the possible existence of repeaters.
What the OPERA specification does, is to apply recursively the dialog between Supplicant and Authenticator.
A node is first Supplicant and, once admitted into the network, may become Authenticator for another Supplicant. This creates a chain of trust among d