An introduction to G.hn security

G.hn is the new standard developed by ITU for high-speed networking over existing home wires (power lines, phone lines and coaxial cables). One of the key elements in a communication standard is the security mechanism that ensures that data confidentiality is protected and that external users cannot get access to users’ data.

G.hn’s security architecture is composed of four major elements:

1. Data Encryption: a procedure to encrypt data with a secret key
2. Data Integrity: a procedure to ensure that messages are not altered after they have been transmitted
3. Authentication: a procedure to ensure that only authorized nodes/users can access encrypted data
4. Key distribution: a procedure to distribute secret keys to authenticated devices in the network

Data Encryption in G.hn

G.hn uses the well-known AES (Advanced Encryption Standard - NIST standard FIPS PUB 197) as the encryption procedure. G.hn uses AES keys with a length of 128 bits. AES-128 provides much stronger security than existing home networking technologies that use the DES encryption algorithm, which has a much shorter key length (56 bits), and is not currently considered secure. From Wikipedia’s entry on DES:

“DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small. […] In recent years, the cipher has been superseded by the Advanced Encryption Standard (AES).”

NIST, the US agency that developed both DES (FIPS PUB 46) and AES (FIPS PUB 197), withdrew the DES standard in May 2005, because “DES no longer provides the security that is needed to protect Federal government information.”

Unique point-to-point encryption keys

In many networking standards, all communications are encrypted with the same key. This has many security implications:

1. If a device is compromised by an attacker (ie, if the attacker gets access to its copy of the encryption key), then the attacker can eavesdrop all communications in the network, even between other nodes.
2. If a device is given temporary access to the network (for example, if a friend wants to get access to the internet from your home during a visit), then the “common encryption key” has to be shared. When the network owner wants to disable access to the network to that temporary device, he/she now has to change the encryption for all devices in the network.

G.hn solves this by having unique point-to-point keys: the encryption key used for communication between nodes Alice and Bob is different from the key used for communication between nodes Charlie and Dave. Charlie cannot eavesdrop the communication between Alice and Bob.

Key distribution in G.hn

Having unique encryption keys for each individual communication path would be very complex and difficult to maintain, unless we have a mechanism to distribute these keys efficiently to all devices in the network.

In G.hn, the mechanism for key distribution is based on ITU Recommendation X.1035 (Password-authenticated key exchange (PAK) protocol). X.1035 specifies a mechanism that can be used by two nodes to:

1. authenticate each other, that is, verify that both share a secret password, without actually transmitting the secret password on the wire
2. agree on a new randomly-generate encryption key, without actually transmitting the encryption key on the wire

X.1035 achieves this by using a password-authenticated Diffie-Hellman exchange.

Authentication in G.hn

The process followed by a node to authenticate itself with a G.hn domain is as follows:

1. The new node Alice joins the domain (this process is not authenticated and is thus not secure)
2. Node Alice starts a password-authenticated Diffie-Hellman exchange with the “Security Controller” (SC), as described in X.1035
3. Alice and the SC are now mutually authenticated (the node knows the SC is who it claims to be, and the SC knows node Alice is who it claims to be), and they both have agreed on a randomly-generated encryption key (known as NSC – Node to Security Controller Key) they can use for further communication.
4. Using the newly generated key, node Alice can ask the SC to generate a pair of keys for communication between node Alice and node Bob.
5. The SC will generate the random keys, and will transmit them to nodes Alice and Bob using each node’s unique NSC.
6. Nodes Alice and Bob can now start communication using the new keys. No other nodes in the network (except for the SC) can eavesdrop their conversation.

Ensuring message integrity in G.hn

Another important aspect of security is ensuring that messages transmitted between two nodes have not been modified by intermediate nodes, in what is called “man in the middle attack”.

G.hn ensures message integrity by adding a Message Integrity Code (MIC) to each data frame. The MIC can have a length of 4, 8 or 16 bytes, and its calculation requires having access to the AES-128 encryption key.

If a message is modified by an intruder during transmission, the MIC calculated by the receiver will be different from the MIC included in the message. This can be used by the receiver to detect that the message has been tampered with.

End-to-end encryption in G.hn

G.hn supports the concept of relays, in which one device can receive a message from one node and deliver it to another node further away in the same domain. Relaying provides extended range for large networks.

To ensure security in scenarios with relays, G.hn specifies end-to-end encryption, which means that if node Alice sends data to node Bob using node Mallory as an intermediate relay, the data is encrypted in such a way that Mallory cannot decrypt it. Also, because the data is accompanied by a MIC, Bob could detect if Mallory had attempted to modify the data.

The other alternative (not used by G.hn) would be hop-by-hop encryption, in which data is sent from Alice to Mallory, decrypted by Mallory, encrypted again by Mallory for delivery to Bob and then decrypted by Bob. In this hop-by-hop scenario, data is available in plain text while it's being relayed by Mallory, which makes the system susceptible to a Man-in-the-middle attack.

G.hn Single security scheme

Many standards define multiple encryption and key distribution schemes. In some cases, this is done to support legacy devices that use weaker encryption. In other cases, this is done because the group developing the standard could not agree on a single one, so multiple options had to included in the document. Having multiple security schemes is a big problem for implementers (because it increases development and verification time, and because it increases the probability of introducing security bugs in their implementations) and for consumers (because of interoperability problems caused when multiple devices don’t implement the same options).

G.hn specifies a single encryption scheme (AES-128) and a single authentication and key exchange scheme (X.1035), which reduces implementation complexity and will ensure interoperability for consumers.

Summary

G.hn ensures data confidentiality by using AES-128 encryption and a password-authenticated Diffie-Hellman key exchange as specified in Recommendation X.1035.

G.hn ensures message integrity by adding a MIC to each transmitted data frame, guaranteeing that messages cannot be modified during communication.

G.hn ensures security in large networks with relay nodes by using end-to-end security, as opposed to hop-by-hop security.

G.hn ensures interoperability by mandating a single encryption scheme (AES-128) and a single authentication and key exchange scheme (X.1035).