Why does mixed-mode HLS 5 association fail with scope-of-access-violated when reading Class 70 or Class 8?

[carlos_mendez]

[!WARNING]
Technical Redaction & Safe Harbor Notice:
All communication captures, system titles, and cryptographic parameters in this thread have been sanitized and neutralized. Real utility meter identifiers, production encryption keys (GUEK/GAK/MK), SIM IMSIs, and proprietary network envelopes have been substituted with standard IEC 62056 synthetic test vectors. Do not post unredacted production captures or live cryptographic keys.

We are troubleshooting field communication access permissions under Management Client (Client SAP 0x0001, Logical Device 1) authenticated via High Level Security 5 (HLS 5 GMAC).

After HLS 5 mutual authentication is established (0x60 AARQ -> 0x61 AARE -> CtoS/StoC handshake accepted), our application reads instantaneous electrical registers (OBIS 1.0.32.7.0.255, Voltage L1, Class 3) using plain Get-Request-Normal (0xC0 0x01), and the meter responds with valid voltage data.

However, when we attempt to read Clock (Class 8, OBIS 0.0.1.0.0.255, Attribute 2 time) or operate Disconnect Control (Class 70, OBIS 0.0.96.3.10.255, Method 1 remote_disconnect) using plain APDUs, the meter persistently rejects the request with data-access-result: scope-of-access-violated (0xC4 0x01 C1 01 01)!

Here is the failing plain GET request for Class 8 Clock:

00 01 00 01 00 01 00 0D C0 01 C1 00 08 00 00 01 00 00 FF 02 00

And the meter response:

00 01 00 01 00 01 00 05 C4 01 C1 01 01

Why is an authenticated Management Client getting scope-of-access-violated on specific objects?

[sarah_jenkins]

Carlos, this is because Association Authentication Level and Object Attribute Access Rights are two decoupled security layers in DLMS/COSEM.

Per DLMS Blue Book Ed. 17 Section 4.5.3 (Association LN Class 15) and IEC 62056-62 Section 6.2.23:
The Association LN object (OBIS 0.0.40.0.0.255) contains Attribute 2 object_list, which defines an access descriptor table for every object accessible under that client SAP:

ObjectAccessDescriptor ::= Structure {
  class_id: Long-Unsigned,
  logical_name: Octet-String (6B),
  access_rights: Structure {
    attribute_access_modes: Array [
      { attribute_id: 2, access_mode: Enum }
    ],
    method_access_modes: Array [
      { method_id: 1, access_mode: Enum }
    ]
  }
}

Access Mode Enumeration (IEC 62056-62 Table 42):

• 0 = no_access
• 1 = read_only (Plaintext allowed)
• 2 = write_only
• 3 = read_and_write
• 4 = authenticated_read
• 5 = authenticated_and_encrypted_read

For energy registers (Class 3), the access mode is often set to 1 (read_only).
For Clock (Class and Disconnect Control (Class 70), the access mode is configured as 5 (authenticated_and_encrypted). When you transmit a plain 0xC0 0x01 APDU, the meter enforces rule 5 and rejects with scope-of-access-violated!

[alex_turner]

Sarah's analysis is exact. Look at the framing difference:

To access an object marked authenticated_and_encrypted, the request must be wrapped inside General-Glo-Ciphering (0xDB) with Security Control 0x30 (AES-GCM-128 authentication + encryption):

Here is the correct ciphered request for Class 8 Clock:

00 01 00 01 00 01 00 23 DB 08 53 48 41 00 00 00 00 01 30 00 00 00 02 88 1A 2B C0 44 99 EE 12 33 44 55 66 77 88 99 AA BB CC DD EE FF

When transmitted with 0xDB encryption, the meter's access controller validates that encryption security requirements are satisfied and returns the encrypted Clock value!

[david_miller]

This highlights a critical architectural rule in DLMS Green Book 10th Ed Section 9.2.5:
HLS 5 authentication creates an authenticated association, but does not dictate the ciphering mode of subsequent business PDUs.

A client can operate in:

1. Pure Plain Mode: HLS 5 handshake, all subsequent APDUs plaintext 0xC0/0xC1/0xC3;
2. Pure Ciphered Mode: HLS 5 handshake, all subsequent APDUs encrypted 0xDB;
3. Mixed Mode: Low-sensitivity telemetry plain, high-sensitivity control actions encrypted.

[elena_rostova]

From the firmware side, we configure Attribute 2 of Association LN specifically to prevent replay or sniffing of sensitive commands (such as relay disconnect or clock tampering).

Even if a malicious party establishes a low-level association, they cannot tamper with Class 70 or Class 8 without possessing the Global Unicast Key (GUEK) and monotonically valid $IC$.

[carlos_mendez]

That explains everything! We updated our client configuration to automatically wrap Class 8 and Class 70 in 0xDB ciphering, and both the clock read and the relay disconnect succeeded immediately!

[marcus_vance]

Best practice for HES design:
When initializing a communication session, HES should read Attribute 2 of 0.0.40.0.0.255 once to cache the meter's object access matrix, or default all management operations to Security.AUTHENTICATION_ENCRYPTION.

[alex_turner]

Here is the verified ciphered Get-Response for Class 8 Clock returned by the meter:

00 01 00 01 00 01 00 25 DB 08 53 48 41 00 00 00 00 01 30 00 00 00 03 44 19 82 77 1B C0 90 AA BB CC DD EE FF 00 11 22 33 44 55 66 77 88

Deciphering yields the 12-byte Date/Time octet string.

[sarah_jenkins]

Notice how this granular security model protects grid assets without imposing encryption overhead on high-frequency public meter reads.

[david_miller]

To synthesize for the community, here is the Python Gurux script demonstrating how to enforce encryption on sensitive objects:

from gurux_dlms.objects import GXDLMSClock, GXDLMSDisconnectControl
from gurux_dlms.enums import Security

def operate_secure_objects(client, reader):
    # Enforce Suite 1 Authentication + Encryption
    client.ciphering.security = Security.AUTHENTICATION_ENCRYPTION
    
    # 1. Read Protected Clock (Class 8)
    clock = GXDLMSClock("0.0.1.0.0.255")
    current_time = reader.read(clock, 2)
    print(f"[+] Current Protected Meter Time: {current_time}")
    
    # 2. Execute Protected Disconnect Control (Class 70)
    relay = GXDLMSDisconnectControl("0.0.96.3.10.255")
    reader.method(relay, 1, 0) # Method 1: remote_disconnect
    print("[+] Breaker successfully tripped via encrypted Action-Request.")

Summary Checklist:

1. Access Matrix: Verify Association LN object_list access modes (IEC 62056-62 Table 42).
2. Encrypted Access: Wrap Class 8 / Class 70 in 0xDB General-Glo-Ciphering.
3. Security Policy: Default HES management associations to Security.AUTHENTICATION_ENCRYPTION.