<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>

<p dir="auto">The fundamental divergence lies in <strong>PLC memory address mapping vs Legal Metrology Object Contracts</strong>:</p> <ul> <li> <p dir="auto"><strong>Modbus (Process Control Philosophy)</strong>:<br /> A register like <code>40001</code> is purely raw bytes in PLC SRAM. The protocol does not know if it represents Celsius, Volts, or RPM. It relies entirely on external static Excel mapping sheets. There is zero security, zero timestamping, and zero non-repudiation.</p> </li> <li> <p dir="auto"><strong>DLMS / COSEM (Self-Describing Legal Metrology Philosophy)</strong>:<br /> Every metering value is an object instance per IEC 62056-62. A Class 3 Register (<code>1.0.1.8.0.255</code>) contains its value, signed scaler exponent, engineering unit enum (<code>30 = Wh</code>), and access permissions. Any standard client worldwide can discover and interpret the data without a manufacturer manual.</p> </li> </ul> <p dir="auto">When managing 20 million meters from 15 different vendors in a national smart grid, DLMS object standardization saves millions in integration costs.</p>

<p dir="auto">Instead of trying to memorize individual numbers, think of OBIS as a <strong>6-level semantic classification system</strong> per Blue Book Section 4.2:</p> <table class="table table-bordered table-striped"> <thead> <tr> <th style="text-align:left">Group</th> <th style="text-align:left">Standard Meaning</th> <th style="text-align:left">Intuitive Rule</th> <th style="text-align:left">Practical Examples</th> </tr> </thead> <tbody> <tr> <td style="text-align:left"><strong>A</strong></td> <td style="text-align:left">Medium / Abstract</td> <td style="text-align:left">What physical commodity?</td> <td style="text-align:left"><code>1</code> = Electricity, <code>7</code> = Gas, <code>8</code> = Water, <code>9</code> = Heat</td> </tr> <tr> <td style="text-align:left"><strong>B</strong></td> <td style="text-align:left">Channel</td> <td style="text-align:left">Which internal path?</td> <td style="text-align:left"><code>0</code> = No channel / Total, <code>1..64</code> = Sub-meter channels</td> </tr> <tr> <td style="text-align:left"><strong>C</strong></td> <td style="text-align:left">Physical Quantity</td> <td style="text-align:left">What physical parameter?</td> <td style="text-align:left"><code>1</code> = Active Energy (+A), <code>31/32/33</code> = Voltage (L1/L2/L3), <code>11/12/13</code> = Current</td> </tr> <tr> <td style="text-align:left"><strong>D</strong></td> <td style="text-align:left">Measurement Type</td> <td style="text-align:left">How is it measured/processed?</td> <td style="text-align:left"><code>8</code> = Cumulative Energy (integral), <code>7</code> = Instantaneous value, <code>4</code> = Max demand</td> </tr> <tr> <td style="text-align:left"><strong>E</strong></td> <td style="text-align:left">Tariff / Rate</td> <td style="text-align:left">Which pricing tier?</td> <td style="text-align:left"><code>0</code> = Total (all tariffs), <code>1</code> = T1, <code>2</code> = T2, <code>3</code> = T3</td> </tr> <tr> <td style="text-align:left"><strong>F</strong></td> <td style="text-align:left">Billing Period</td> <td style="text-align:left">Which historical snapshot?</td> <td style="text-align:left"><code>255</code> = Current real-time value, <code>0</code> = Previous billing period, <code>1</code> = 2 periods ago</td> </tr> </tbody> </table> <p dir="auto">For example:</p> <ul> <li><code>1.0.1.8.0.255</code> -> Electricity (<code>1</code>) -> Channel 0 (<code>0</code>) -> Active import (<code>1</code>) -> Cumulative energy (<code>8</code>) -> Total tariff (<code>0</code>) -> Current (<code>255</code>) = <strong>Total Active Import Energy (+A)</strong>.</li> <li><code>1.0.32.7.0.255</code> -> Electricity (<code>1</code>) -> Channel 0 (<code>0</code>) -> Phase B Voltage (<code>32</code>) -> Instantaneous (<code>7</code>) -> Real-time (<code>255</code>) = <strong>Phase B Instantaneous Voltage</strong>.</li> </ul>

<p dir="auto">Here is the verified A-XDR payload for Active Energy Import (<code>1.0.1.8.0.255</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="😞" /></p> <pre><code class="language-hex">00 01 00 01 00 01 00 12 C4 01 C1 00 02 02 06 01 31 2D 00 02 02 0F 00 16 1E </code></pre> <ul> <li><code>06 01 31 2D 00</code>: Double-Long-Unsigned <code>20,000,000 Wh</code> (20,000 kWh)</li> <li><code>0F 00</code>: Scaler <code>0</code> ($10^0$)</li> <li><code>16 1E</code>: Unit <code>30 [Wh]</code></li> </ul>

<p dir="auto">Elena's point regarding IEEE 754 precision is critical for utility MDMS architectures.</p> <h3>The Correct Datatype Standard:</h3> <p dir="auto">In all billing and data ingestion pipelines:</p> <ol> <li><strong>Never use <code>float</code> (32-bit)</strong> for energy quantities;</li> <li><strong>Use <code>Double</code> (float64: 53-bit mantissa $\implies 9 \times 10^{15}$ exact integers)</strong> or <strong>Fixed-Point Decimal (Python <code>decimal.Decimal</code>, Java <code>BigDecimal</code>)</strong>;</li> <li>Perform all aggregation using raw integer arithmetic before applying the scaler.</li> </ol>

<p dir="auto">Notice how the Public Client read solves the cold-start problem cleanly without exposing any secret keys!</p>

<p dir="auto">Marcus, this is the core security invariant of DLMS Security Suite 1: <strong>The Invocation Counter ($IC$) is persistent across connection lifetimes.</strong></p> <p dir="auto">Per <strong>DLMS Green Book 10th Ed Section 9.2.5.3 (Invocation Counter Management)</strong> and <strong>IEC 62056-53 Section 8.4.2</strong>:<br /> The 4-byte Invocation Counter ($IC$) is a strictly monotonic anti-replay sequence number.</p> <h3>The Meter's Non-Volatile Persistence:</h3> <p dir="auto">In the meter's security engine (Class 64 <code>Security Setup</code>), the meter stores the last verified Invocation Counter from Client SAP <code>0x0001</code> in <strong>non-volatile memory (EEPROM / Flash)</strong>:<br /> $$\text{Condition: } IC_{\text{rx}} > IC_{\text{persisted}}$$</p> <p dir="auto">If your HES worker thread restarts and resets $IC$ to <code>1</code> (or any value $\le IC_{\text{persisted}}$), the meter's AES-GCM decryption engine flags an active replay attack and drops the frame by design!</p>

<p dir="auto">Here is the verified ciphered <code>Get-Response</code> for Class 8 Clock returned by the meter:</p> <pre><code class="language-hex">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 </code></pre> <p dir="auto">Deciphering yields the 12-byte Date/Time octet string.</p>

<p dir="auto">Sarah's analysis is exact. Look at the framing difference:</p> <p dir="auto">To access an object marked <code>authenticated_and_encrypted</code>, the request must be wrapped inside <code>General-Glo-Ciphering</code> (<code>0xDB</code>) with Security Control <code>0x30</code> (AES-GCM-128 authentication + encryption):</p> <p dir="auto">Here is the correct ciphered request for Class 8 Clock:</p> <pre><code class="language-hex">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 </code></pre> <p dir="auto">When transmitted with <code>0xDB</code> encryption, the meter's access controller validates that encryption security requirements are satisfied and returns the encrypted Clock value!</p>

<p dir="auto">From the cryptographic standpoint, GBT introduces a critical security difference:</p> <p dir="auto">In <strong>Traditional DataBlock</strong>, each datablock is ciphered as an individual application chunk or ciphered at the outer APDU level.<br /> In <strong>GBT</strong>, the entire multi-block stream shares a single outer ciphering context or ciphers per GBT block with rolling Invocation Counters ($IC$).</p> <p dir="auto">If your HES does not parse GBT, it fails to extract the underlying plain <code>Get-Response-Normal</code> payload.</p>

<p dir="auto">Here is the verified ASN.1 DER signature format for ECDSA P-256 in Method 3:</p> <pre><code class="language-asn1">Signature ::= SEQUENCE { r INTEGER (32 bytes with leading 0x00 if MSB is set), s INTEGER (32 bytes with leading 0x00 if MSB is set) } </code></pre> <p dir="auto">Hex encoding:<br /> <code>30 45 02 21 00 [R_32B] 02 20 [S_32B]</code> (Total: 71 bytes).</p> <p dir="auto">When passed inside <code>Action-Request</code> for Method 3 (<code>0.0.44.0.0.255</code>), the meter's public key successfully validates the image digest.</p>