In this chapter, a security protocol is proposed specifically for the advanced metering infrastructure (AMI) in the smart grid to address the security requirements. Although AMI does not cover all private networks in smart grid communications, security protocols for its comprehensive and complicated infrastructure can be extended to other private networks based on their different security requirements. The proposed security protocol will be illustrated in four parts, namely the initial authentication scheme, secure uplink transmission scheme, secure downlink transmission scheme, and domain secret update scheme.
The proposed security schemes in this chapter are based on several network security concepts: for example, security services, security mechanisms, etc. To make the illustration clearer, we first present some basic background about network security in this section.
Security services are provided in a system design to protect against possible security attacks. In a communication system, possible security services are described in Table 11.1
Table 11.1 Security services.
Security service | Description |
Access control | Control access from authorized users to resources. |
Authentication | Verify the identities of entities. |
Confidentiality | Ensure that information is accessible only to authorized entities. |
Data integrity | Maintain the accuracy and completeness of data. |
Non‐repudiation | Prove the data origin. |
Availability | Make information available to authorized entities when needed. |
For a given communication system, whether to apply a security service depends on system requirements. The system may be most secure if all security services are applied. However, due to limited computational resources, it is impractical to implement all services.
Security mechanisms are the tools to achieve security services in a communication system. Some major security mechanisms include encipherment, authentication, access control, digital signature, and data integrity.
Encipherment mechanisms mainly provide confidentiality. Encipherment algorithms include reversible and irreversible ones. Reversible encipherment algorithms are widely known as encryption algorithms, which are divided into symmetric and asymmetric ones.
Encipherment mechanisms are widely applied to achieve other security mechanisms.
Authentication mechanisms are applied to authentication services. Instead of specific algorithms, authentication mechanisms are mainly handshake protocols with messages created by other mechanisms using unique information provided by entities.
Access control mechanisms are applied to control access to services. Similar to authentication, many access control mechanisms use handshake protocols to determine and enforce the access rights of an entity depending on its authenticated identity.
Digital signature mechanisms are applied to non‐repudiation services and sometimes to data integrity. Most digital signature mechanisms are based on public‐key encryption algorithms, where the sender signs a message with the private key and the receiver verifies the signature with the sender's public key.
Data integrity mechanisms are applied to data integrity services. Irreversible encipherment algorithms are applied as data integrity mechanisms in most communication systems. For example, hash functions are data integrity mechanisms. In this chapter, a hash function is defined as . Note that a hash function has no key, so any entity has the ability to generate and verify a hash code with a given message.
Note that security mechanisms are not a one‐to‐one match with security services. A security service may be provided by multiple security mechanisms, and a security mechanism may be applied to multiple security services.
For simplicity, the notations of the keys used in the proposed security protocol of this section are listed in Table 11.2.
Table 11.2 Notations of the keys.
Keys for symmetric algorithms | |
Preshared secret key for node | |
Active secret key for node | |
Session key between and | |
Keys for asymmetric algorithms | |
Public key for node | |
Private key for node | |
Public key for the authentication server | |
Private key for the authentication server |
In this section, we present the initial authentication of the security scheme. The security scheme is proposed mainly for the wireless networks in the AMI. Security in the backbone network can be achieved using existing mechanisms and protocols controlled by utilities. Nodes in the wireless networks mainly include data aggregate points (DAPs) and smart meters.
Before joining the AMI, a DAP must be authenticated through the initialization process [167]. Assume that utilities have full control of their private networks; thus an authentication server (AS) is managed by utilities on their side. The initial authentication is based on a trusted AS. Generally speaking, if a node is closer to the AS, it will be authenticated before those that are farther away due to multihop networks. Therefore, before a smart meter joins the AMI, the gateway DAPs and normal DAPs are initialized by the AS. Note that gateway DAPs are initialized before normal DAPs since they have direct communication to the concentrator. For simplicity, gateway DAPs are not specified in the rest of the discussion.
DAPs are divided into two groups: one active and the other uninitialized. An active node is a node that has been authenticated by the AS to join the AMI communication system and is functioning normally. An uninitialized node can be one of the following four types:
The authentication process for uninitialized nodes is carried by existing active nodes and the AS. For example, as illustrated in Figure 11.1, DAP is uninitialized, while its neighboring DAPs , and are active. To join the AMI, initiates the authentication process by broadcasting a request to all of its active neighbors, which will relay the request to the AS through established secure links.
After the authentication process is performed by the AS, will receive reply messages from the AS through its active neighbors. The reply messages are different from each other, since they consist of authentication confirmation as well as information to establish secure links between and each of its active neighbors. In summary, the initial authentication process accomplishes the following three tasks:
After all DAPs have been initialized by the AS, a neighborhood‐area network is formed in the AMI. Smart meters will then be initialized through active DAPs. Unlike DAPs, smart meters do not have many neighbor nodes because of two reasons. First, smart meters have a limited transmission range. They are unlikely to have a direct connection with more than one DAP. Second, it is not a good idea to let smart meters communicate with each other, since their data contains much private information and smart meters are easier to access than DAPs.
An overview of the initialization process for a smart meter is shown in Figure 11.2. An uninitialized smart meter sends a request to an active DAP, and the DAP will relay the request to the AS through a secure communication link. Once the authentication process is approved by the AS, a reply is sent to the smart meter through the active DAP.
Without loss of generality, the authentication handshake protocol is presented according to the example given in Figure 11.1, where is the uninitialized node. One of its active neighbor is chosen to illustrate the detailed initialization process. The initialization processes through active neighbors and are similar.
In practice, the active neighboring node may not have a direct connection to the AS. Instead, there may be a secure link established between and the AS. Therefore, we focus on , , and the AS in the process. Note that other active nodes in the same secure link do not store useful information from the process. The initialization process achieves three mutual authentications.
Each legitimate node, whether uninitialized or active, has a preshared secret key (i.e. for node ) with the AS. Besides, an active secret key is assigned to each active node (e.g. key ) for node , mainly for uplink data traffic encryption. This active secret key is also used by the AS to verify if this node is active or not. Similar to , is known only to and the AS. In order to establish a secure connection from to the AS after the authentication process, an active secret key must be generated by the AS and assigned to during the initialization process. Note that does not carry before initialization process; only is known to . Moreover, although the active nodes relay messages from the AS to , the keys are not disclosed to those intermediate nodes.
The authentication handshake protocol is initiated from the uninitialized node . The entire process includes six handshakes among , , and the AS, as shown in Figure 11.3. The 6 messages exchanged during the process are described as follows:
After the six handshakes, is fully initialized, and it joins AMI communications through . The initial authentication processes through other active neighbors (i.e. and in this example) are similar. In particular, the AS sends back the same , , , and . Note that the preshared secret key is unique, depending on active neighbor identity . Nonetheless, in the final handshake, will send the same to its active neighboring node encrypted with , in this example. By doing so, shares the same public key to all of its active neighbors. Therefore, is able to join the uplink transmission through any of the active neighbors. In other words, both operating and backup secure communication channels are established through the initial authentication process.
The detailed process for smart meter initialization is the same as DAP initialization. The only difference is that, there is one process only because of the single active DAP a smart meter is connected to. The illustration is not repeated here.
The security of the proposed authentication process is described in terms of each security service, including confidentiality, data integrity, non‐repudiation, and availability. Note that the security services mentioned here are just those for the authentication process, not for the overall security protocol.
In the uplink transmission, data from each node is aggregated in a chain topology and is finally delivered to the service provider (assuming that the AS and the service provider share the same entity). As discussed before, data confidentiality and data integrity are critical requirements for metering data, since any mistakes may cause inefficient grid operation. Sender authentication or non‐repudiation may be considered in certain situations if there are enough computational resources. To achieve all these requirements, we propose the following security protocol for data aggregation in uplink transmission.
We first present the uplink encryption process for a single‐traffic transmission. The following description is based on the illustration shown in Figure 11.4. Suppose the single‐traffic transmission follows a path with nodes in the order of .
As the first one of the aggregation, mixes its raw data with as . It then encrypts the intermediate message with the active secret key as follows:
A hash value is generated as , where is a hashed message authentication code function that provides data integrity. The notation with is to distinguish the hash function from the one applied to the initialization process, since different hash functions can be used in authentication and uplink encryption. The hash value is attached to the cipher text as follows:
Finally, encrypts the entire message with as follows:
The next node first decrypts the incoming data with the session key as follows:
Then mixes its raw data with and generates cipher text as follows:
A hash value is generated as and attached to the cipher text. The message from is aggregated to the current message as follows:
Finally, encrypts the entire message with as follows:
Any intermediate node performs the same process as by replacing indexes with respectively. The final message reaching the AS (or utilities) from node is .
A node may receive multiple items of data traffic in the AMI communications network. In this case, the intermediate shall process all incoming traffic and generate a single item for the next node. The example shown in Figure 11.5 is used to illustrate the multiple‐traffic uplink encryption process. Suppose an intermediate node has two incoming items in traffic from nodes and respectively; chooses one of them randomly, for example, message from node . Node processes by following the single‐traffic uplink encryption as illustrated in the previous subsection and generates a cipher text as follows:
A hash value is generated based on the cipher text. The other message from node is decrypted at node to reveal . The disclosed is flagged such that and attached to the cipher text . The generated message at node is as follows:
The message sent from to the next node is computed as follows:
If there are more items in incoming traffic, they will be processed as at node .
Once the AS receives the aggregated data, it starts the decryption process of the data. For example, as shown in Figure 11.6, the AS first authenticates the incoming node, for example, node , by decrypting the receiving data with the preshared public key as follows:
and reveals , and . The AS then verifies the data integrity by computing the hash value . As shown in Figure 11.7, if the hash value matches the one disclosed from the decryption, then data integrity is validated. If a hash value cannot be validated, then the data integrity of that message is violated, and the message is discarded. Once data integrity is validated, the AS continue the data recovery process by decrypting as follows:
With already disclosed, from node can be recovered. After that, the AS continues the recovery process with . Note that the AS does not verify senders other than ; thus is processed using the same process used to process . To recover , the AS maintains synchronization of the initial vector .
If the message includes data from multiple incoming traffic streams, the AS extracts the messages between flags and and continues to recover the data by following the same process discussed before for . The AS may process multiple incoming messages in parallel, as they are not mixed together.
Confidentiality, data integrity, and non‐repudiation are the security services to be provided in the uplink transmission encryption protocol.
The downlink transmission involves control messages from the service provider to the nodes. Most of the control messages (e.g. price and tariff information) are for all the smart meters in the neighborhood. For those messages, confidentiality may not be as important as it is for the uplink transmission data. Nonetheless, data integrity is important. Message manipulation would alter demand response in the smart grid and in the end result in grid inefficiency. Moreover, non‐repudiation is critical for such control messages so that the customers can trust the sender. Some control messages are one‐to‐one, such as on‐off switch commands for participating customers' air conditioners. Confidentiality must be provided to those messages in addition to data integrity and non‐repudiation.
Encryption for a broadcast control message (e.g. ) is illustrated in Figure 11.8. A time stamp is appended to the message, and a hash value is generated as , where is a cryptographic hash function. The hash value is signed by the AS using its private key, such that , where is an encryption function using public key cryptography. The broadcast message to each node includes the original control message, time stamp, and the digital signature, such that,
At the receiver side, the original information (i.e. and ) is in clear text. The digital signature is decrypted using the public‐key of the AS by performing , where is a decryption function using public key cryptography. The decrypted information is the hash value. The receiver shall compute the hash value at its side and compare the result with the decrypted value to verify data integrity. If the hash value is valid, then non‐repudiation is also validated. If the integrity check is not passed, the receiver will request a retransmission from the AS through its secure uplink transmission tunnel. This rarely happens unless the message is not legitimate. Because each node will receive multiple copies of the control message from all of its active neighbors, if one of the messages is valid, then a retransmission will not be necessary.
Encryption for a one‐to‐one control message (e.g. ) is illustrated in Figure 11.9. The message is XORed to a time stamp and encrypted using the active key . A hash value of the encrypted data is generated and signed. Finally, the encrypted data, time stamp, and the digital signature are aggregated together as message such that
Unlike , is sent through all of its active neighbors of only, as illustrated in Figure 11.10. A few copies of the information would increase the reliability of transmissions.
Security services provided to broadcast messages and one‐to‐one messages in downlink transmissions are slightly different.
In order to keep the AMI secure in the long run, domain secrets need to be refreshed frequently, for example, daily or hourly depending on requirements.
For the AS, its public and private keys need to be refreshed. After the AS generates a new pair of public/private keys (i.e. /), it transmits the public key to all the active nodes using the encryption scheme for broadcasting, such that
The update of is for all the active nodes in the same time slot. In the mean time, separate control messages signed by and will be sent so that the downlink transmissions are not interrupted.
For an active node (e.g. ), its active secret key needs to be refreshed. To do so, the AS picks a new active secret key for , and sends it as one‐to‐one message to , such that
However, it is not necessary to refresh the active secret keys for all the nodes at the same time. The AS can do a batch at a time when the network is not heavily loaded, for example, after midnight. Moreover, as mentioned before, the session key (e.g. ) between two active nodes ( and ) needs to be refreshed more frequently. To do so, and simply run the sixth step from the initialization process again.
The preshared key of a node is not refreshed as frequently as the other keys since it is used much less frequently. Therefore, the preshared key can last longer before it wears out. However, it is reasonable to refresh the preshared key in some cases, for example, if a DAP is compromised and recovered, if a DAP is redeployed to another NAN, or if a house has been sold and thus its smart meter has a new owner. An on‐site firmware update will be recommended in this case. A customer can also request a firmware update and then load it to his/her smart meter. Automatic updates can also be achieved. For example, if DAP needs a preshared key update, the AS picks a new , and sends it to , such that
It is also reasonable to encrypt this message with if has been compromised. However, if both and are compromised, then a physical update will be inevitable.
In this chapter, we proposed a security protocol for the AMI in the smart grid. In order to meet various security requirements for asymmetric communication in the AMI, the proposed security protocol consists of initial authentication scheme, independent security schemes for uplink and downlink transmissions, and a domain secret update scheme. The security scheme for uplink transmissions provides confidentiality and data integrity to metering data and other monitoring data. The security scheme for downlink transmissions provides data integrity and non‐repudiation for controlling data and pricing/tariff information. Future work may be conducted to extend the proposed network security protocol so that cloud computing and various external information sources can be involved in the modern control of the smart grid.