MMS Security

Owned by Davood Sooran (Deactivated)
Aug 29, 2024
3 min read

Security in MMS vs XMPP:

When evaluating the security elements between XMPP and MMS within network communication, several key considerations come into play:

XMPP Security:

    • Features: Robust security provisions like TLS and SASL.

    • Functionality: Provides end-to-end encryption and secure communication channels.

    • Authentication: Offers user authentication for secure connections.

MMS Security:

    • Native Form: Lacks inherent encryption or authentication mechanisms.

    • Implementation: Additional security measures like TLS can be integrated for channel security.

In summary, both XMPP and MMS, fortified with TLS, offer secure communication channels. Selection depends on application specifics, network architecture, and security needs. XMPP suits dynamic and decentralized setups, while MMS, with additional configurations, can attain similar security levels.


MMS Security:

Substations engage with multiple networks, like remote monitoring systems, inter-substation connections, and third-party data networks, which pose significant security risks due to their susceptibility to malicious cyberattacks. These threats can emerge from within or outside the electronic security boundary. Internal threats within this boundary often stem from employee errors or disgruntled staff. Mistakes, such as inadvertently triggering generation or transmission assets, can directly impact the power system, although these errors may occur without any intent to cause harm. Conversely, external threats, like hackers and terrorists, exploit network vulnerabilities to gain unauthorized access to the computer assets within electric power systems, potentially resulting in severe disruptions to the power supply.

Securing IEC 61850-based communications stands as a primary objective, addressed through the technical specification IEC 62351. While IEC 62351 serves as a foundation for bolstering the security of 61850 communications, there are notable limitations and challenges that must be resolved for widespread acceptance and implementation.

IEC 62351 offers distinct methods for securing various communication types:

  • MMS: Security measures for MMS traffic are implemented at the application and transport levels. Peer authentication occurs at the application level, where authentication information, including an X.509 encoded certificate, timestamp, and digitally signed time value, is carried within the ACSE AARQ and AARE PDUs. On the transport level, IEC 62351 adopts TLS, specifying port 3782 for secure communications instead of the standard port 102. It also outlines a set of recommended and mandatory cipher suites, such as TLS_DH_DSS_WITH_AES_256_SHA and TLS_DH_RSA_WITH_AES_128_SHA, to be supported as a minimum.

  • GOOSE/Sampled Values: Security measures for real-time GOOSE/SV traffic primarily focus on message authentication. Authentication involves extending the GOOSE/SV PDUs with an authentication value generated by signing a SHA256 hash using RSA. Certificate exchange isn't part of the messages; instead, receiving nodes are required to have preinstalled X.509 encoded certificates for authentication purposes.

The primary objective of security measures within IEC 61850 is to ensure confidentiality, tamper detection, and message-level authentication for SCADA and telecontrol protocols operating over TCP/IP. While many information technology protocols allow for encryption algorithm renegotiation during connection establishment, telecontrol environments often sustain longer-lasting connections, necessitating special considerations. Specifically, only TLS 1.0 (or higher) is allowed, with symmetric keys being renegotiated based on time periods and maximum packet/byte thresholds. The configurable renegotiation values are an essential aspect covered under PIXIT (Protocol Implementation Extra Information for Testing).

Within IEC 61850, although TLS specifies the message authentication code as an option, it is mandatory for countering and detecting man-in-the-middle attacks. Compliance with the technical specification demands:

  • Support for Multiple Certificate Authorities (CA), wherein any entity's failure to provide its certificate terminates the connection. Bidirectional certificate exchange and validation can be based on CA or individual certificates.

  • Ability to Verify the Local Certificate Revocation List (CRL) at Configurable Intervals. Connection establishment using a revoked certificate results in termination, but inability to access the CRL doesn't terminate the connection.

Regarding MMS, security recommendations for the TCP T-Profile focus on TLS utilization and securing RFC1006, without specifying security recommendations for TCP, IP, or Ethernet directly. For TLS implementation, several aspects require consideration, including cipher renegotiation, certificate size, revocation, and recommended cipher suites.

Compliance necessitates support for minimum-maximum renegotiation criteria, termination of connections if certificates used are revoked, and support for key exchange algorithms with a minimum size of 1024 bits. RSA and Diffie-Hellman mechanisms must both be supported, with cipher suite support for TLS_DH_DSS_WITH_AES_256_SHA being the minimum requirement. Table below presents the recommended cipher suite combinations.