ITU - Telecommunication Standardization Sector
Temporary Document FF-xxxxx
STUDY GROUP 15
Original: English
Ft. Lauderdale, Florida 5 November – 8 November 2007
Question: XXX
SOURCE1: Intellon Corporation
TITLE: G.hn: Requirements for MAC data protection
________________________________________________________
ABSTRACT
The G.hn put a goal to design the system to provide security mechanisms, including protection of
data transmitted on the network, suitable for in-home networks.
1.
Introduction
In contrast to networks using dedicated wires (such as coax or twisted pair), networks using power
lines and wireless networks are open to eavesdropping and even injection of signals without direct
access to the network equipment. For businesses, and for many home users, it is necessary to
provide a level of security on par with a wired LAN – that is, only stations that the user wishes to be
connected to the network have meaningful access, and all stations in the network have direct access
to one another. Wireless security mechanisms attempting to do this not only have taken a beating
over the years for shortcomings in their design and implementation, but also are geared toward
variable-length data transmission units. Given that two-level framing is to be used for error control
performance, it is not necessary to use flow ciphers. Instead, a block cipher may be used to provide
for encryption and, with a suitable integrity check, message integrity. This paper proposes data
protection mechanisms suitable for in-home users.
Purva R. Rajkotia – Intellon Corp.
Tel:
+ 352 237-7416 x 120
E-mail: purva.rajkotia@intellon.com
Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the
Member States of the ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU
related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of the
ITU-T.
1. PB-based approach is very efficient and provides high level of security, provided that the
network key is rotated frequently enough.
2. Use of network-wide (Network Encryption Key ??) NEK allows for relay (for hidden nodes
and for power management).
1.1.
Stream Cipher Not Required for Efficiency
Stream ciphers have the advantage that they can easily accommodate any length of plaintext
without additional padding. This is desirable for protocols in which variable length data units may
be sent over the medium, including lengths that are not multiples of the cipher block length in use.
However, stream ciphers generally discard most output bits from each encryption operation that
generates a stream key, and so tend to be wasteful of computation. They also generally perform a
simple exclusive-or of the plaintext and the stream keys to form the ciphertext, rendering them
vulnerable to attacks that selectively alter bits in the ciphertext, and hence, the decoded plaintext.
This in turn require them to have stronger authentication codes on each transmission to protect
integrity and authenticity (for example, CRC is a linear code, and so changing the data bits and the
CRC bits in a way that duplicates a valid CRC codeword allows an altered message to appear to be
correct, even though the attacker may not know all the bits of the message).
Two-level framing uses fixed length FEC blocks as the basic unit of correct delivery [2], so the
FEC information length can be chosen to be a multiple of the cipher block length. Hence, no
additional padding is needed for block encryption. This allows use of computationally efficient
CBC mode, and also allows a simpler integrity check algorithm to be used.
1.2.
HMAC Not Required if CBC is Used
CCMP introduces 8 octets of message integrity check (MIC) in addition to the 4 octet frame check
sequence. In contrast, when cipher block chaining (CBC) is used, any change to a ciphertext block
will in essence randomize the corresponding decoded block. Since without the key it is not
possible to predict the way in which the bits of the decoded block will change, it is not possible to
determine how to change the integrity check value (ICV) either. Furthermore, the ICV itself is
decoded from a ciphertext block, so changing that ciphertext block in such a way to produce a
desired change in the ICV is not feasible. Hence, HMAC or other cryptographic integrity check is
not needed for assurance of integrity [1]. This saves not only additional overhead bytes, but also
the computation required to compute the MIC itself.
1.3.
Derivation of IV is Feasible if CBC is Used
In CBC, the IV’s primary function is to produce different ciphertext even when the same plaintext
is sent with the same key. This is very different from the IV’s function in stream ciphers, where the
IV is used to initialize the pseudorandom number generator that produces the stream keys. It is
absolutely necessary never to send data using the same IV and the same key when a stream cipher is
used, since this is tantamount to using the same one-time pad twice. For this reason, systems that
use stream ciphers must send the IV (or at least a fairly large portion of it) with each encrypted
transmission. This produces significant overhead when these transmission units are small (and is
no doubt the reason behind the choice of the insufficiently long IV in WEP). The CCMP
encryption header introduces 8 octets of overhead, of which the majority is IV. This is not needed
if CBC is used and the IV is derived from other changing elements already present in the
transmission.
1.4.
802.11 Encryption Mechanisms Not Needed nor Desired
Two-level framing makes a good marriage with CBC, and eliminates additional padding costs
usually present with block ciphers. Use of CBC in turn allows for high efficiency in both
computation (encryption and integrity check) and space. Nearly 12 octets of overhead are saved
compared to CCMP (the encryption key select is still needed, but this is a few bits amortized over
all the blocks transmitted in an MPDU). For data blocks of 512 bytes, this is about 2.3% overhead
that is saved. If the data blocks are shorter (which many are), then the savings are greater.
2. Data Protection Goals
In selecting the security mechanisms to use for an environment, it is imperative to know both the
goals and the threats so that the selection is properly informed. For the in-home network
environment, we have the usual security goals of confidentiality (no disclosure of data to
unauthorized recipients), integrity (the message that was received is the same as the message that
was sent), and authenticity (the message was sent by the station that claimed to send it). These are
modulated somewhat by weaker requirements on authenticity, and no requirements for nonrepudiation that are generally needed in enterprise environments. Likewise, the threat profile is
considerably lower for an in-home network than it is for an enterprise network. The value of the
assets that may be compromised is lower, and so unless the individual has a high risk for other
reasons (e.g., is a celebrity or has a job that engenders such risks), the resources of an attacker are
typically going to be moderate at most (i.e., we do not expect that a foreign government or
organized crime would spend the resources to attack an ordinary citizen).
Furthermore, the stations within an in-home network are generally equally trustworthy – there is no
need for mutual suspicion between the television and the DVD player, if they belong to the same
household. Hence, an accepted model for security for in-home networks is that of a wired LAN –
the stations in the same network can communicate freely and are trusted, while stations in another
network cannot communicate freely with or eavesdrop on the communications between stations in
the network [3].
2.1 Confidentiality
If the goal of confidentiality is set to be that all stations within the network can communicate with
each other, but outsiders cannot meaningfully eavesdrop on their communications, then a single
network-wide encryption key suffices for this purpose. Distribution of the Network Encryption Key
(NEK) must be done only to stations that belong to the network, and is the subject of a different
paper on authentication, so is not treated here.
Use of a common NEK does allow a station in the same network to decode communications
between other stations in the same network, but this is no different than stations on a wired LAN
can do (and in fact, due to channel adaptation, is actually harder to do than it is on a wired LAN).
This is acceptable within the goals and the threat model, assuming that the key distribution
mechanism is not compromised and that the key itself has not been compromised. The former is
the concern of the key management protocols, and is outside the scope of this paper. The latter can
be achieved by use of an appropriate encryption algorithm and use of randomly selected keys from a
sufficiently large key space.
The proposed algorithm is AES-128 in CBC mode, with the NEKs chosen randomly and rotated at
least once every hour and on network membership change.
2.2 Integrity
Message integrity is achieved through use of an integrity check value (ICV) computed over the
body of each MSDU or management message. The ICVs are part of each MAC frame, and the
MAC frames are concatenated to form the MAC Frame Stream, which is then segmented into
fixed-length segments that are in turn encrypted. Each encrypted segment forms the information
bits of an FEC block, which has its own small header and check sequence, which are unencrypted.
These FEC blocks are retransmitted as necessary until they are delivered correctly (that is, the check
sequence is correct). Apparently correct segments are then decrypted and reassembled (using
information in their header and the header of the MPDU in which they were sent). The ICV is then
checked for each MAC Frame that is extracted from the received MAC Frame Stream. This
produces low overhead for integrity, and has high probability of detecting any changes (malicious
or not) introduced in transmission.
As discussed in section 1 and asserted in [1], the use of large and computationally expensive MIC is
not needed in this environment when CBC is used for encryption. Derivation of the IV from the
MPDU and segment header information also limits the ways in which the IV can be maliciously
altered, further restricting an adversary.
2.3 Authenticity
Authenticity capabilities are limited, since the NEK is shared amongst all the stations in the
network. This is consistent with the goals, however, since the stations in the network (those that
have the NEK) are trusted. Any station that does not have the NEK can only attempt to replay
messages, but this also is limited by the way the IV is formed, even if the malicious sender could
use the same tone map. Replayed segments that have not been changed will not alter the
reconstructed MAC Frame Stream, since each segment has its reassembly information in its header,
and changing that will change the IV, hence the contents.
3. PHY Block (PB) -Based Encryption
This section outlines the proposed mechanism. It is designed to operate well with two-level
framing, to incur minimal overhead and to provide data security adequate for the in-home
environment [3]. Section 2.2 describes the segmentation mechanism. Each PB body is encrypted
independently each time it is (re)sent, using the NEK as the key for AES-128 in CBC mode.
3.1 NEK
All stations in the domain (or logical network) share the same network encryption key (NEK). This
permits easy direct communication (PM) as well as relayed communication (CM or UM). All
communication between these authenticated stations uses the NEK at the level of the PHY Block
(PB). The NEK is generated randomly, is only provided to authorized stations, and is changed at
least once every hour. It is also changed when the set of stations in the network changes.
3.2 IV
The IV is derived from portions of the PHY-frame header, the PHY Block header, and the position
of the PHY Block in the MPDU [4]. As discussed in Section 1.3, derivation of the IV for CBC is
not the problem that it might be for OFB or CTR, and this allows the explicit transmission of an IV
to be avoided, saving that overhead. As mentioned in 2.3, IV derivation also has some advantages
against replay attacks.
3.3 Integrity checks
Integrity of MAC Frames is checked by a CRC-32 appended to each MAC Frame. Combined with
AES-128 in CBC mode, this provides for integrity [1]. Note that, since the NEK is shared,
authenticity of messages is only at the level of the network, not at the individual station.
4. Comparison to CCMP
CCMP is a stream cipher, and so must have non-linear integrity check. This causes each message
encrypted with CCMP to have the encryption engine run once to generate the stream keys, and
again to produce the MIC. Furthermore, only a fraction of the encryption output is used for each
stream key, so there will typically be about 16 times as many encryptions to produce the stream
keys as there is in CBC to encrypt a 128-bit block.
CCMP also requires that 48 bits of IV be sent with each message, plus 16 more bits with the
encryption key select (EKS), etc. The proposed method uses 4 bits of EKS per MPDU.
Table 1. Comparison of CCMP and CBC/ICV in two-level framing
Enciphing
Computation per
128 bits
Integrity Check
CCMP
Requires 16 times 128-bit
encryptions plus 128 bits of XOR
CBC/ICV
Requires 128 bits of XOR plus one
128-bit encryption
Requires computing CBC over
Computes CRC over whole message
computation
IV overhead
Other overhead
Authentication
whole message
48 bits of IV sent with each
message
16 more bits of overhead for Key
Select and other CCMP fields, per
message
8 bytes+ 4bytes
IV derived from fields already there –
no overhead
4-bit key select per MPDU (which
may contain many messages)
5. Summary
This paper has discussed and compared competing mechanisms for data protection in in-home,
networks. The proposed approach provides security at the level required while maintaining
superior efficiency.
This paper is intended to be discussed at the G.hn session.
It is proposed to agree on the following items from the issues list
3.23.3
new
Should G.hn use CCMP to provide confidentiality & data
integrity?
That G.hn shall specify PHY-Block based data protection,
confidentiality, encryption and authentication technique as
described in this paper
No
YES
Also the paper suggests the technique to reconsider the goal upon old item number:
3.23.1
that G.hn should provide node authentication (if practical) and
encryption based on the CCMP procedures standardized in
IEEE 802.11i.
The paper proposes the following newer agreements
3.35
6. References
[1] M. Bellare and P. Rogaway, “Encode-then-encipher encryption: How to exploit nonces or
redundancy in plaintexts for efficient cryptography,” Advances in Cryptology - Asiacrypt 2000
Proceedings, Lecture Notes in Computer Science Vol. 1976, T. Okamoto ed, Springer-Verlag,
2000.
[2] Katar, Srinivas, Richard Newman, Haniph Latchman, and Larry Yonge, “Efficient MAC
Framing and ARQ for High-Speed PLC Systems”, ISPLC2005, Vancouver, Canada, April 2005,
pp. 27-31.
[3] Richard E. Newman, Larry Yonge, Sherman Gavette, and Ross Anderson, ``Protecting
Domestic Powerline Communications,'' Symposium on Usable Privacy and Security (SOUPS
2006), Pittsburgh, PA, July 12-14, 2006, pp. 122-132.
[4] Richard E. Newman, Larry Yonge, Sherman Gavette, and Ross Anderson, ``HomePlug AV
Security Mechanisms,'' IEEE ISPLC 2007, Pisa, Italy, March 26-28, 2007.