Assessing Of The Substation Architecture Information Technology Essay
A typical substation architecture is shown in Figure 1. The substation network is connected to the outside wide area network via a secure gateway. Outside remote operators and control centers can use the abstract communication service interface (ACSI) to query and control devices in the substation. There is one or more substation buses connecting all the IEDs inside a substation. A substation bus is realized as a medium bandwidth Ethernet network, which carries all ACSI requests/responses and generic substation events messages (GSE, including GOOSE and GSSE). There is another kind of bus called process bus for communication inside each bay. A process bus connects the IEDs to the traditional dumb devices (merge units, etc.) and is realized as a high bandwidth Ethernet network. A substation usually has only one global substation bus but multiple process buses, one for each bay.
Figure 2 : ACSI Communication model
I 1.3. COMMUNICATION MODELS
GOOSE MESSAGES - follow PUBLISHER SUBSCRIBER MODEL - Transmission using MULTICAST APPLICATION ASSOCIATION
SERVICE FUNCTIONS - follow CLIENT SERVER MODEL - Transmission using TWO PARTY APPLICATION ASSOCIATION
SMV MESSAGES - follow PUBLISHER SUBSCRIBER MODEL - Transmission using MULTICAST APPLICATION ASSOCIATION
GOOSE:(Generic Object Oriented Substation Event)is used for fast transmission of substation events, such as commands, alarms, indications, as messages. A single GOOSE message sent by an IED can be received by several receivers. Examples:-Tripping of switchgear,providing position status of interlocking
SERVICE FUNCTIONS :
Services Operating on Data-
logical device model-
Get logicaldevice directory
logical node model-
Get logicalnode directory
Get alldata values
set data values
get data directory
get data definition
data set model-
get data set values
set data set values
create data set
delete data set
get dataset directory
Sampled Measured Values :
A method for transmitting sampled measurements from transducers such as CTs, VTs, and digital I/O.
SECURITY HUB ARCHITECTURE
Figure 4 : Security Hub Architecture
A security hub  is a network element whose purpose is to provide broad access to a distinguished collection of hosts while assuring latency requirements between these distinguished hosts. The concept is illustrated in the figure. The security hub (or "hub" for short) links two networks: a connected network such as the Internet or enterprise network and a control network such as the digital communication bus in a power station or vehicle. Hosts in the connected network are said to be external hosts (ehosts) whereas hosts in the control network are called internal hosts (ihosts). The security hub mediates communication with each ihost so that a packet from an ehost to any ihost must pass through the hub and a packet from any ihost to any other ihost must pass through the hub. The security hub provides a "hub-and-spokes" network architecture for the ihosts while also acting as a gateway between the ehosts and the ihosts. It provides a low bandwidth interface to the connected network and a low latency interface to the control network. The hub maintains IPsec-authenticated tunnels between itself and each of the ihosts and takes responsibility for checking the authenticity of the origin of any packet sent between ihosts. It routes packets from the connect network to the ihosts through these tunnels, but leaves their authentication to the ihosts, which use TLS to provide both authentication and encryption for these links. Each ihost is given a DNS name and a certificate with a private key bound to this name. These keys are managed by a key repository which is located in the connected network. The nodes use the Domain Name Server (DNS) to get IP addresses for routing, including routing within the control network. The hub provides multicast addresses and routing for use by the ihosts. An ihost can declare a new multicast address and other ihosts can subscribe to it. Finally, the hub keeps an inventory of the names of all of the ihosts attached to it in the control network and is able to provide this list to hosts authorized to receive it. The hub is also able to enforce basic partitioning of the ihosts by being configured so to allowing only some communication between the ihosts, thereby implementing an analog of a VLAN.
2. SECURITY HUB ARCHITECTURE SUPPORT FOR PUBLISHER SUBSCRIBE MODEL
If a SIED wants to be a PUBLISHER, it sends a message to SECURITY HUB. SECURITY HUB broadcasts this message to all SIEDS in the control network. Any SIED wishing to SUBSCRIBE sends a message to security hub. Security hub check its security association policies before setting up a PUBLISHER SUBSCRIBER relationship between them. SECURITY HUB contains a Database which keeps track of publisher subscriber relationships and various publisher subscriber systems active at a given time.
2.1 ROLE of SECURITY HUB as a KEY MANAGER and DISTRIBUTOR
Generates a group key for each publisher subscriber group and transmits it to each group member.
GROUP JOIN OPERATION-If any SIED wants to join an established group it receives the group key of group. GROUP LEAVE OPERATION-If any SIED wish to leave the group, a new group key is generated and unicasted to each group member .
Use of group keys will save cryptographic checksum calculations as packets meant for the same group members will just have to be duplicated.
PAIRWISE KEY SETUP -Generate pairwise session keys for members of the group. No. of keys to be generated , nC2 , n is no. of group members. Unicast set of keys to each group member. This way they are aware of other group members as well. Each group member receives 'n' keys in a unicast message (a group key and n-1 session keys corresponding to each group member)In case of a group leave, leaving member sends a message to security hub and security hub multicasts this information to the group, so group members can flush the session key established with this group member from their cache. I think it is a good idea to cache the keys in local cache of publisher-subscriber group members. It is OK to be a bit sloppy here (in terms of security) to save some time. As these SEIDs can be mutually interdependent for the period they are part of a publisher subscriber group, if one SEID gets compromised, others will be affected naturally as they are functionally dependent on each other.
Members which are a part of publisher subscriber system, can also be mutually dependent on each other for that period. So, there is a very high probability that they may issue some service commands to each other as well using client - server model. As member SIEDs can communicate directly via session keys established between them, we save some time again here.
Role of security hub* cuts down to key management to most extent and sort of decentralization is achieved with various publisher subscriber systems operating almost independently. Any communication between SIEDS (belonging to different publisher-subscriber systems or we can say belonging to different domains at that time) is achieved via SECURITY HUB as an intermediate node. This also helps in detecting suspicious behaviour and immediate security actions.
* Security hub may be replicated in the control network to enhance reliability, external connectivity and performance
Communication between members of a different domain is achieved via Hub and Spoke principles.
AN ON DEMAND GROUP GENERATION SCHEME-Implementation of a counter in a security hub which keep tracks of interactivity between SEIDs belonging to different domains. If the activity exceeds a certain set threshold level in some predecided time interval1 a group is established and keys can be distributed accordingly. If the group activity reaches below threshold level in some predecided time interval2 group dissolves.
Might be present in Substation SIEDs (This behaviour may be observed among different publisher subscriber groups and might be periodic in nature)
SUB DOMAIN GENERATION WITHIN A LARGE DOMAIN -
Effect on key distribution-
In case of a domain merge-
A new group key is generated for new group. Also, pairwise session keys are generated between members in domain1 and domain2 respectively. Suppose there are 'a' members in domain1 and 'b' members in domain2. So, total no. of session keys to be generated 'ab'. Each member in domain A receives b+1 keys ( 'b' pairwise session keys + 1 group key) and unicast message for domain B members contains a+1 keys ( 'a' pairwise session keys + 1 group key ). Total no. of unicasts a+b. In absence of dynamics- No. of keys to be generated a+bC2 pairwise session keys + a group key.
In case of a domain split-
It is not required to generate pairwise session keys among group members, as they already exist . Only new individual group keys need to be generated and invalid session keys need to be flushed from local cache of group members.
In case of a sub domain generation-
A new group key should be transmitted to each group member
In absence of dynamics - No. of keys to be generated nC2 pairwise session keys, where 'n' is no. of group members in a newly generated sub domain + a group key
4. KEY GRAPH FOR GROUP COMMUNICATION AMONG SUBSTATION SIEDS
Some key graphs  -
1)Reduction in no. of messages to distribute group key when a group leave operation is performed.
2)Enables sub-group communication via sub group keys.
1)Key graph generation, each time a group is created.
2)Number of keys to be changed when a group leave operation is performed.
Some fundamental questions/challenges which arise are Which key graph to use? A significant parameter on which choice of key graph might depend-Order of group. Is it feasible to make the nature of key graph dynamic?
Some Efficiency Measures to be considered
1)Network traffic (should be in a suitable range)
2)Network latency (should satisfy the requirements, try to achieve as minimal as possible)
3)Key management and distribution overheads (should be manageable)
5. POSSIBLE ATTACKS ON EXISTING SECURITY HUB ARCHITECTURE
Both of the attacks described here, exploit TLS protocol to launch a DOS attack.
1) TCP data injection -While TLS itself may be as secure as possible, the use of TCP without additional cross-layer functionality makes it almost impossible to protect TLS against Denial-of-Service (DoS) attacks on the TCP layer. For, TLS the injection of just any data denotes a DoS attack. TCP assembles IP packets into a data stream and hands this stream over to TLS. In the effort of suppressing duplicate packets it hands over a given range of bytes just once. If an attacker is able to inject an arbitrary amount of random bytes into the byte stream TCP hands over to TLS, the data integrity check of TLS will fail, and the data has to be dropped. This behavior combined with TCP's dropping of duplicate packets leads to the TLS layer needing data that the TCP layer believes to have already handed over, and therefore detects as duplicates. A TLS implementation needs to restart the complete TLS connection in such a case.
2)Forcing the TLS server to perform large number of illegitimate RSA decryptions-An attacker attempts to incapacitate a TLS server by initiating large no. of TLS handshake requests per second as the number of RSA decryptions the server can perform per second. A high end server can process upto 4000 RSA decryptions per second. If we assume that a partial TLS handshake takes 200 bytes, then 800 KB/s is sufficient to paralyze the server.
1)Adding authentication at the TCP layer -The major problem of TLS is TCP offers a reliable service and delivers data to the upper layer protocols just once because it is supposed to suppress duplicates. TCP's decision is based on the unsecured entries of the TCP header, or else it could find out that the received packet is a forgery. Even if TLS could figure out that a given data segment was injected, TCP would not pass TLS the original data since it seems to be duplicate. Solution is to add authentication at the TCP layer using TCP MD5 option. Authentication is achieved by combining advantages of TLS and TCP MD5 option. TLS allows to setup a secure connection to an unknown peer, (though peers, ehosts and ihosts may not be unknown in this scenario) but misses authentication of data below the TLS layer. The MD5 option adds the missing data authentication but cannot set up connections with unknown peers. Two approaches can be combined start TLS without protection first and use it to set up the MD5 option for the TLS connection as soon as possible.
So, the time during which an attack is possible is reduced to the first packets, namely the TCP three way handshake and the first phase of the TLS key exchange. After the TLS handshake phase, the attacker would not be able to successfully inject packets into the TCP. Therefore, the TLS connection is secure for the rest of its lifetime
Considering Network Address Translation-The original TCP MD5 option authenticates TCP's data and header, as well as the IP source address. If a NAT modifies the packet in transit the IP source address in the packet will be changed, and the receiver's integrity check with the TCP MD5 option will fail. But as sender is already authenticated as an entity using TLS mechanisms, authenticating the IP address is not a requirement.
2) Client puzzle solution -The idea of client puzzles is to slow down the attacker sufficiently that a denial of service is no longer possible. In order to prevent the denial-of-service attack against TLS, a new message is added after the Server Hello message and before the Server Done message. This message contains a cryptographic puzzle and is only sent when the server is under load. The server will then wait on a response message before continuing with the handshake protocol. The type of client puzzle used consists of inverting a hash function when given the hash digest and a certain portion of the pre-image. After the client has sent its client hello message, the server chooses a random a-bit value s and inputs it to a cryptographic hash function. It then includes the hash digest t = hash(s) along with the b first bits of s (where b < a) to the client in the server hello message. Using these b bits, the client solves the client puzzle via brute-force and finds a value s' that hashes to the desired t. With knowledge of the first b pre-image bits, the client only needs to attempt approximately 2 candidate values before finding a valid solution s' that satisfies t = hash(s'). The client then includes s' in its client key exchange message. Only if s' verifies - i.e, it is of correct length and its hash output is t - will the server proceed with the SSL handshake and decrypt the encrypted session key submitted by the client. The computational cost of a hash computation is almost negligible when compared to an RSA decryption (a hash is about 3 to 4 orders of magnitude faster to compute), so the addition of puzzle verification step adds a very minor server side overhead. The amount of work needed to be done by the client in order to solve the puzzle depends upon its computing resources and, more importantly, the number of unknown bits in the pre-image value sent by the server. The addition of client puzzles to the SSL handshake protocol has the advantage of making DoS attacks more elaborate to carry out. A single client machine is no longer ableto easily overload an SSL server by sending consecutive SSL initiation requests, as it would need to solve the appropriate client puzzles, thereby limiting the number of valid requests it could send per second.
3)CLIENT AIDED RSA -The main idea is to shift some computational burden from the ihosts to the ehosts. Specifically, clients should perform the bulk of the work in RSA decryption, thereby allowing the server to accept and process more incoming requests. Computation transfer-We begin by representing the server's private exponent as d = f1d1 + f2d2 + ... + fkdk (mod Ï†(n)), where the fi 's and di's are random vector elements of c and |n| bits, respectively. The following processes take place when a server wants to offload the computation xd (mod n) to a client:
Server sends vector D = (d1 , d2, ..., dk ) to client
Client computes vector Z = (z1, z2 , ..., zk), where zi =xdi (mod n),and sends it back to server.
3.Finally, server computes
âˆi=1 k zifi = âˆi=1 k xfidi = xd (mod n)
Note that, assuming that it is computationally difficult to "break" RSA, parameter selection should not introduce any attacks that compromise the security of the above computation by the server, namely xd (mod n). An attacker can attempt to exhaust all possible vector values fi thereby deriving d. Thus, a minimal requirement for c and k is that a brute force attack (which requires 2cÃ-k steps) should be as difficult as breaking underlying RSA. The client hello and server hello messages remain unchanged, although the server's certificate (which is sent as part of the server hello message) now includes the vector D = (d1, d2, ..., dk ). The client chooses a random value x, which is then used to derive the TLS session key, and uses the server's public exponent to encrypt it : y = xe (mod n). Next, the client uses D to construct a vector Z by computing the individual vector elements zi = ydi (mod n), for 1 â‰¤ i â‰¤ k. This vector is included in the client key exchange message. The server, upon receiving this message and derives yd = (xe)d = x (mod n).
Note: Chinese remainder theorem can be used to speed up RSA secret key exponentiations.
7. MODIFICATIONS TO EXISTING IEC 61850 PROTOCOL STACK
Existing IEC 61850 protocol stack -
A New Component added to protocol stack, to meet one to one communication need among SIEDS. -
7.1 How XML security will work in this scenario and suits the needs of the architecture?
As information between ihosts and ehosts is exchanged in XML format, security can be embedded in the document itself, eliminating the need of TLS.XML document being sent to the ihost is digitally signed by the respective ehost.ihost on receiving the document verifies the digital signature of ehost. Respective public keys of ehosts can be obtained easily in a secure manner by utilizing DNSSEC architecture .
Some possible benefits as compared to TLS-
Suppose, an XML document say a substation configuration file is to be transferred whose contents are filled by some specific ehosts i.e there are different authentication requirements for different sections of a document. On using TLS, each ehost will establish a separate TLS connection with the ihost in the control network and send the required information. On using XML security options, it can be easily accomplished by using digital signatures. Each ehost will sign its section in the document and this document will be propagated to the control network. On receiving the document, ihost can easily verify, individual signatures. Also, it will be possible to encrypt specific sections of document. SOAP accounts should be included in the soap messages to provide protection against XML rewriting attacks.
I would like to thank Dr. Carl Gunter and Jianqing Zhang for their immense guidance and support.
In this paper we explored group communication possibilities for SIEDs. We discussed security hub architecture support for publisher/subscriber model used for transmission of messages in substation network. We studied role of security hub in secure group communication, its role as Key Manger and Distributor. Group Dynamics among SIEDs were observed. Use of key graphs for secure group communication among substation SIEDs was also discussed. Finally, we discussed attacks on existing security hub architecture. Both of the attacks ,exploited TLS protocol to launch a DOS attack. Certain solutions to these attacks were discussed such as adding authentication at the TCP layer, client puzzle solution, client added RSA. We also suggested a modification to IEC 61850 protocol stack. In future we aim to explore behaviour of groups in a substation,design, experiments to observe factors such as group order, group dynamics, study
key graph issues for group communication in SIEDs and continue to refine security hub architecture.
If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please click on the link below to request removal: