At the ICS-CSR conference, researchers from the technology institute of Karlsruhe (Elbez et al.), published the results of their research on the authentication of GOOSE messages.  The aim of the study was to assess the compatibility of certain message authentication mechanisms with the protocol’s time constraints. 

By default, the GOOSE protocol, which is specified in standard IEC 61850, is used without any security mechanism. Standard IEC 62351 give best practices and recommends the use of different security strategies for the protocols in standard IEC 61850. In the case of GOOSE, the aim is to add a CRC and an APDU signature (Application Protocol Data Unit, the message content without headers) via RSASSA-SSP (RSA-Probabilistic Signature Scheme based on Signature Scheme with Appendix, see below). Nevertheless, the same standard specifies that use of this signature is not recommended for applications that require 3 ms response times. Due to this recommendation (and this protocol’s current state of security maturity), for the time being, most equipment manufacturers do not propose a signature mechanism for GOOSE messages. 

FIGURE 1: Block diagram of the RSASSA-PSS signature process. Credits: Farooq et al. 

To better understand the RSASSA-SSP signature mechanism, we recommend the research paper published last March by Farooq et al. , devoted to the implementation of this mechanism for GOOSE messages. As its name suggests, RSASSA-PSS is a signature mechanism based on RSA. It mitigates some of the weaknesses of the basic RSA encryption by adding padding and a random element to the initial GOOSE message. Figure 1 illustrates the process for the computing the signature of a GOOSE message: 

  • As a reminder, only the message APDU is signed 
  • This APDU undergoes several operations, shown in Figure 2. In particular they add a random value in the field called Salt and compute the hash which will be used to verify the integrity of the message 
  • This encoding is converted into an integer 
  • The RSA signature is computed from this integer and then added to the message in the field provided for this purpose 

FIGURE 2: APDU encoding steps. Credits: Hussain et al. 

The problem with this signature mechanism is the time required for encryption and decryption. This extra cost has to remain reasonable enough to allow real-time applications with strong time constraints (less than 3 m) to continue to operate. Unfortunately, few studies have examined this impact. 

As far as we know, the two studies we have mentioned are the only two that have implemented RSASSA-PSS for GOOSE messages and measured the time cost. Other studies have implemented a more conventional RSA mechanism. We note that, in general, the hardware used in these studies is not necessarily representative of the hardware used in electric substations. In addition, most of the studies concentrate on the use of 1024 bit keys, even though the use of 2048 bit keys was recommended by the NIST since 2013. The results show that it takes more than 4 ms to compute a signature with RSASSA-PSS. Therefore, this mechanism cannot currently be used for applications with strong time constraints. 

In their paper, Elbez et al. also explore the use of HMAC-256 to replace RSASSA-PSS. The results of the experiment show that use of this algorithm has much less impact from a time point of view. Indeed, computation of the signature requires roughly ten microseconds. 

The authors discuss the possibility of introducing this signature method in the next version of standard IEC 62351. However, it should not be overlooked that this mechanism is based on symmetrical encryption (not asymmetrical like RSASSA-PSS) which raises other issues, particularly the management of encryption keys.