<p dir="auto">To provide a definitive, runnable implementation for the community, here is a complete Python script using standard <code>cryptography</code> primitives implementing DLMS Green Book 10th Ed compliant HLS 5 GMAC tag computation and mutual verification:</p> <pre><code class="language-python">import struct from cryptography.hazmat.primitives.ciphers.aead import AESGCM def compute_hls5_gmac(auth_key: bytes, sys_title: bytes, ic: int, challenge: bytes, sc: int = 0x10) -> bytes: """ Computes DLMS Green Book 10th Ed HLS 5 GMAC Tag (Pass 3 / Pass 4). """ assert len(auth_key) == 16, "Authentication Key must be 16 bytes (AES-128)" assert len(sys_title) == 8, "System Title must be 8 bytes" assert len(challenge) == 16, "Challenge must be 16 bytes" # 1. Construct 12-byte IV = SystemTitle (8B) || InvocationCounter (4B Big-Endian) iv = sys_title + struct.pack(">I", ic) # 2. Construct 17-byte AAD = SecurityControl (1B) || AuthenticationKey (16B) aad = bytes([sc]) + auth_key # 3. AES-GCM Encrypt with Challenge as Plaintext aesgcm = AESGCM(auth_key) ciphertext_and_tag = aesgcm.encrypt(iv, challenge, aad) # In AES-GCM, the last 16 bytes are the Authentication Tag tag = ciphertext_and_tag[-16:] return tag def verify_server_proof(auth_key: bytes, server_sys_title: bytes, server_ic: int, client_challenge: bytes, server_tag: bytes) -> bool: """ Verifies Pass 4 Server Proof returned in Action-Response. """ expected_tag = compute_hls5_gmac(auth_key, server_sys_title, server_ic, client_challenge) return expected_tag == server_tag # Example Test Vector Execution if __name__ == "__main__": gak = bytes.fromhex("000102030405060708090A0B0C0D0E0F") client_title = bytes.fromhex("434C540000000001") stoc = bytes.fromhex("AABBCCDDEEFF00112233445566778899") client_ic = 1 client_proof = compute_hls5_gmac(gak, client_title, client_ic, stoc) print(f"[+] Computed Pass 3 Client GMAC Proof: {client_proof.hex().upper()}") </code></pre> <h3>Summary Checklist for HLS 5 GMAC Implementations:</h3> <ol> <li><strong>$AAD$ Length</strong>: Strictly 17 bytes ($SC \parallel AK$), never include the Challenge in AAD.</li> <li><strong>Challenge Role</strong>: Pass $S_{\text{to}}C$ / $C_{\text{to}}S$ as the 16-byte authenticated plaintext.</li> <li><strong>$IC$ Byte Order</strong>: Always big-endian 4-byte unsigned integer in $IV$.</li> <li><strong>Dual Verification</strong>: Always verify Pass 4 Server Proof using Server System Title before proceeding.</li> </ol>

<p dir="auto">Let's dissect the mathematical GHASH calculation to see exactly why the GMAC tag diverged.</p> <p dir="auto">In AES-GCM (NIST SP 800-38D), the hash subkey is $H = \text{AES}_{K}(0^{128})$.<br /> Given $AAD = A$ and Plaintext = $P$:</p> <p dir="auto">$$GHASH(H, A, P) = X_{m+n+1}$$<br /> where the final block is the length vector:<br /> $$L = [\text{len}(A)]<em>{64} \parallel [\text{len}(P)]</em>{64}$$</p> <ol> <li> <p dir="auto"><strong>Under Green Book 10th Ed</strong>:</p> <ul> <li>$\text{len}(A) = 17 \times 8 = 136$ bits</li> <li>$\text{len}(P) = 16 \times 8 = 128$ bits</li> <li>$L = 0x0000000000000088 \parallel 0x0000000000000080$</li> </ul> </li> <li> <p dir="auto"><strong>Under Legacy Mistake</strong>:</p> <ul> <li>$\text{len}(A) = 33 \times 8 = 264$ bits</li> <li>$\text{len}(P) = 0$ bits</li> <li>$L = 0x0000000000000108 \parallel 0x0000000000000000$</li> </ul> </li> </ol> <h3>The Second Pitfall: Nonce IV and Invocation Counter Endianness</h3> <p dir="auto">There is an equally critical bug that traps engineers: <strong>Initialization Vector (IV) Construction</strong>.</p> <p dir="auto">Per Green Book Section 9.2.5.3:<br /> $$IV_{\text{CtoS}} = \text{Client System Title (8B)} \parallel \text{Client Invocation Counter (4B)}$$</p> <p dir="auto">The Invocation Counter ($IC$) <strong>MUST be encoded in network byte order (Big-Endian)</strong>:<br /> <code>IC = 1</code> $\rightarrow$ <code>0x00 0x00 0x00 0x01</code>.<br /> If your client application passes a native x86 32-bit integer in little-endian format (<code>0x01 0x00 0x00 0x00</code>), the $J_0$ counter block derived for AES encryption ($J_0 = IV \parallel 0x00000001$) becomes completely invalid, producing a corrupted tag $T = \text{GHASH} \oplus \text{AES}_K(J_0)$.</p>

<blockquote> <p dir="auto">[!WARNING]<br /> <strong>Technical Redaction & Safe Harbor Notice</strong>:<br /> 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.</p> </blockquote> <p dir="auto">We are implementing High-Level Security Mechanism 5 (HLS 5 GMAC, Security Suite 1) against commercial three-phase electricity meters over IEC 62056-47 TCP Wrapper. The initial Association establishment (<code>0x60</code> <code>AARQ</code> $\rightarrow$ <code>0x61</code> <code>AARE</code>) succeeds, exchanging the 16-byte Client Challenge ($C_{\text{to}}S$) and Server Challenge ($S_{\text{to}}C$).</p> <p dir="auto">However, when the client sends Pass 3 via <code>Action-Request-Normal</code> calling Method 1 <code>reply_to_HLS_authentication</code> on <code>Association LN</code> (<code>0.0.40.0.0.255</code>, Class 15), the meter consistently rejects the authentication proof with an action error.</p> <h3>Pass 3 Client Action-Request (<code>reply_to_HLS_authentication</code><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></h3> <pre><code class="language-hex">00 01 00 01 00 01 00 24 C3 01 81 00 0F 00 00 28 00 00 FF 01 01 09 10 5B 3A 8F 21 C8 91 44 E2 70 66 A3 11 9D 52 04 7A </code></pre> <h3>Meter Error Response:</h3> <pre><code class="language-hex">00 01 00 01 00 01 00 05 C7 01 81 01 01 </code></pre> <p dir="auto">Dissecting the response:</p> <ul> <li><code>C7 01</code>: <code>Action-Response-Normal</code></li> <li><code>81</code>: <code>invoke-id-and-priority</code></li> <li><code>01</code>: Choice = <code>action-result</code> (error)</li> <li><code>01</code>: Result enum = <code>hardware-fault</code> (access-error: authentication-failure / other-reason)</li> </ul> <p dir="auto">We verified that both the Global Authentication Key (GAK) and Global Unicast Encryption Key (GUEK) are configured in the client. Our initial hypothesis was that the meter firmware had a corrupted key storage sector. Why is the GMAC authentication tag rejected by the meter?</p>

<p dir="auto">From the security and ciphering perspective, there is an even more hazardous trap when running block transfers over authenticated/encrypted associations (<code>glo-get-request</code> <code>0xC8</code> / <code>0xDB</code> with Security Suite 1):</p> <p dir="auto">Per <strong>DLMS Green Book 10th Ed Section 9.2.6 (Security Architecture)</strong>:<br /> When transferring large Profile Generic buffers across multiple datablocks:</p> <ol> <li><strong>Invocation Counter ($IC$) Monotonicity</strong>: Every single <code>Get-Request-Next</code> sent by the HES is a distinct ciphered APDU and <strong>MUST increment the Client Invocation Counter ($IC$) by exactly 1</strong>.</li> <li><strong>IV Reconstruction</strong>: The initialization vector ($IV$) for each request block is:<br /> $$IV = \text{Client System Title (8B)} \parallel IC_{i} \text{ (4B)}$$</li> <li>If HES reuses the same $IC$ from the initial <code>Get-Request-Normal</code> for the subsequent <code>Get-Request-Next</code>, the meter's AES-GCM-128 engine detects an Invocation Counter replay attack, rejects the frame with <code>Service-Error: deciphering-failed</code>, and locks the association!</li> </ol> <p dir="auto">Always ensure that your communication driver increments $IC$ per physical APDU transmission while keeping the internal COSEM <code>invoke_id</code> identical.</p>

<p dir="auto">Marcus, Carlos, look closely at the fatal flaw in your assumption. From a distributed systems and security perspective, this proposal breaks the most fundamental tenet of smart grid engineering: <strong>local autonomy</strong>.</p> <p dir="auto">You are converting an autonomous metrological device into a distributed state-machine slave tethered to continuous cellular availability. Consider what happens during a severe winter storm or cellular base-station failure: the meter successfully executes the 08:00 load trip, but the HES fails to deliver the 12:00 follow-up rewrite due to backhaul packet loss. The schedule halts permanently, leaving industrial consumers disconnected or in an undefined state.</p> <p dir="auto">Furthermore, per <strong>DLMS UA Green Book 10th Ed Section 9.3.4</strong>, every SET request consumes cryptographic Invocation Counters (IC) and triggers non-volatile flash sector writes. You are introducing continuous network traffic and active attack surface for a job that should be statically autonomous.</p>

<p dir="auto">Marcus, allowing remote clients to dynamically inject executable action graphs into Class 9 is not just an extensibility choice—from a cryptographic and legal metrology standpoint, it represents a critical security vulnerability.</p> <p dir="auto">Look closely at what your SET payload accomplishes: you are embedding a remote method dispatcher inside the meter's internal event loop. If Class 9 Attribute 2 were dynamically writable over the air, an attacker with compromised low-level credentials could construct an arbitrary action sequence—for instance, chaining an innocuous clock synchronization event or optical probe connection to trigger Class 70 (<code>remote_disconnect</code>) or Class 7 (<code>Profile Generic</code> reset).</p> <p dir="auto">Under international legal metrology requirements (such as <strong>WELMEC Software Guide 7.2</strong> under the Measuring Instruments Directive <strong>MID 2014/32/EU</strong> and <strong>OIML R46 Section 6.3</strong><img src="https://dlms.sharur.org/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61e.png?v=666d1e6b6e4" class="not-responsive emoji emoji-android emoji--disappointed" style="height:23px;width:auto;vertical-align:middle" title="):" alt="😞" /></p> <ol> <li>All executable control paths affecting physical actuators (relays, valves) and legally relevant billing registers must be strictly separated and immutably verified during type certification.</li> <li>Dynamic construction of execution call graphs post-production violates the non-influenceability requirement of legal software.</li> </ol> <p dir="auto">Furthermore, per <strong>DLMS UA Green Book 10th Ed Section 9.3.4</strong>, Method Access Rights in the <code>Association LN</code> object (Class 15) are evaluated per individual client association. If a client could inject an Action into Class 9 that invokes Class 70 Method 1, and then bind that script to a low-privileged Class 22 Single Action Schedule, it would effectively bypass the association's method access control matrix.</p> <p dir="auto">This is why every certified DLMS smart meter mandates that Class 9 Attribute 2 is strictly read-only.</p>

<h3>Architectural Consensus & Implementation Roadmap</h3> <p dir="auto">This comprehensive debate establishes the definitive industry guidelines for DLMS / COSEM asymmetric cryptography deployment per Green Book Ed. 10:</p> <pre><code class="language-text">┌─────────────────────────────────────────────────────────────────────────────┐ │ 🏁 DLMS SECURITY SUITE 1 ENGINEERING IMPLEMENTATION BLUEPRINT │ └─────────────────────────────────────────────────────────────────────────────┘ 1. Handshake Paradigm: • HLS 7 executes ECDSA/ECDH once during AARQ; all telemetry streams via symmetric AES-GCM; 2. Hardware Baseline: • Meter SoCs running Suite 1 must feature hardware Crypto Cores (<15ms P-256 scalar mult); 3. Certificate Optimization: • Deploy ECQV Implicit Certificates (72 bytes) to eliminate fragmentation on cellular links; 4. Tiered Deployment: • Keep Suite 0 for battery endpoints; deploy Suite 1 across grid electricity networks! </code></pre> <p dir="auto">Special thanks to <a class="plugin-mentions-user plugin-mentions-a" href="/user/elena_rostova" aria-label="Profile: elena_rostova">@<bdi>elena_rostova</bdi></a>, <a class="plugin-mentions-user plugin-mentions-a" href="/user/david_miller" aria-label="Profile: david_miller">@<bdi>david_miller</bdi></a>, <a class="plugin-mentions-user plugin-mentions-a" href="/user/marcus_vance" aria-label="Profile: marcus_vance">@<bdi>marcus_vance</bdi></a>, <a class="plugin-mentions-user plugin-mentions-a" href="/user/sarah_jenkins" aria-label="Profile: sarah_jenkins">@<bdi>sarah_jenkins</bdi></a>, and <a class="plugin-mentions-user plugin-mentions-a" href="/user/carlos_mendez" aria-label="Profile: carlos_mendez">@<bdi>carlos_mendez</bdi></a> for this masterclass technical exchange on <code>0.0.40.0.0.255</code> and <code>1.0.1.8.0.255</code>!</p>

<p dir="auto">Let us examine the exact Green Book Table 43 state machine comparison between HLS 5 and HLS 7:</p> <pre><code class="language-text">[ HLS 5: Symmetric GMAC 2-Pass Handshake ] Client Server (Meter) | --- AARQ (SystemTitle-C + StoC) ------> | | <--- AARE (SystemTitle-S + CtoS) ------ | | --- ACTION (StoC Auth Ciphertext) ----> | (Verifies GMAC) | <--- ACTION-Response (Server Proof) --- | (Verifies CtoS Proof) (2 Full Round-Trips, pure symmetric AES-GCM) [ HLS 7: Suite 1 Hybrid Key Agreement Handshake ] Client Server (Meter) | --- AARQ (Ephemeral_Key_C + Sig_C) ---> | (Meter Verifies Client Sig) | <--- AARE (Ephemeral_Key_S + Sig_S) --- | (Client Verifies Server Sig) | ======== Both derive Session Key via ECDH (AES-GCM-128) ======== | | --- GET / SET (Symmetric AES-GCM Stream using Session Key) ----> | (1 Asymmetric Handshake, followed by 100% High-Speed Symmetric Stream) </code></pre> <p dir="auto"><strong>Crucial Technical Reality</strong>:<br /> HLS 7 does NOT execute slow ECDSA signatures on every GET/SET read.<br /> <strong>Asymmetric crypto runs exactly ONCE during AARQ association setup to mutually authenticate and derive the ephemeral session key. All subsequent high-frequency meter reads execute over high-speed symmetric AES-GCM!</strong></p>

<p dir="auto">On the other hand, remote breaker operations (104 YK) require strict two-step execution (Select -> Execute):<br /> When receiving 104 Execute, the gateway holds the 104 context and dispatches a High-Level Security DLMS Class 70 ACTION with a 3000ms timeout per Blue Book Chapter 4.6.<br /> Only when the meter confirms execution with <code>action-result: success</code> does the gateway return 104 Command Confirmation (COT=7).</p>

<p dir="auto">Here is the engineering trade-off comparison matrix per Blue Book Chapter 4:</p> <table class="table table-bordered table-striped"> <thead> <tr> <th style="text-align:left">Metric</th> <th style="text-align:left">Modbus RTU / TCP</th> <th style="text-align:left">DLMS / COSEM (IEC 62056)</th> </tr> </thead> <tbody> <tr> <td style="text-align:left"><strong>Primary Domain</strong></td> <td style="text-align:left">Real-time millisecond industrial control</td> <td style="text-align:left">Legal metrology, billing, asset lifecycle</td> </tr> <tr> <td style="text-align:left"><strong>Polling Latency</strong></td> <td style="text-align:left"><strong>10~50 ms deterministic cycle</strong></td> <td style="text-align:left"><strong>100~500 ms</strong> (session & encryption overhead)</td> </tr> <tr> <td style="text-align:left"><strong>Data Modeling</strong></td> <td style="text-align:left">Flat 16-bit registers (Coils, Holding)</td> <td style="text-align:left">Object-oriented (62 COSEM interface classes)</td> </tr> <tr> <td style="text-align:left"><strong>Header Overhead</strong></td> <td style="text-align:left">8 bytes request, 5 bytes response</td> <td style="text-align:left">30~80 bytes (HDLC/Wrapper + xDLMS APDU)</td> </tr> <tr> <td style="text-align:left"><strong>Security & Audit</strong></td> <td style="text-align:left">None natively (plain text)</td> <td style="text-align:left">AES-GCM-128/256, GMAC, non-volatile $IC$</td> </tr> <tr> <td style="text-align:left"><strong>Self-Description</strong></td> <td style="text-align:left">None (requires external manual)</td> <td style="text-align:left">Native (OBIS code, unit enum, scaler)</td> </tr> </tbody> </table> <p dir="auto">PLCs stick with Modbus because industrial closed-loop control demands <strong>deterministic millisecond polling cycles</strong> that cannot tolerate cryptographic handshake latency.</p>