from gurux_dlms.secure import GXSecure
from gurux_dlms.enums import Security, Authentication
from gurux_dlms.objects import GXDLMSAssociationLN

def verify_hls5_mutual_authentication(client, server_system_title, server_proof_bytes, ctos_challenge):
    # 1. Extract Server SC, Server IC, and Server GMAC Tag
    server_sc = server_proof_bytes[0]
    server_ic = int.from_bytes(server_proof_bytes[1:5], 'big')
    server_gmac_tag = server_proof_bytes[5:17] # 12 bytes
    
    # 2. Build Server IV: Server System Title (8B) || Server IC (4B)
    iv = server_system_title + server_proof_bytes[1:5]
    aad = bytes([server_sc])
    
    # 3. Calculate Expected Server Proof over original CtoS challenge using GAK
    expected_proof = GXSecure.secure(
        client.settings, client.ciphering, server_ic, ctos_challenge, server_system_title
    )
    
    assert server_proof_bytes == expected_proof, "Server Proof Mismatch! Mutual auth failed."
    print("[+] HLS 5 Mutual Authentication & Server Proof verified successfully!")

Summary Checklist for HLS 5 GMAC:

1. IV System Title Assignment: CtoS uses Client System Title; Server Proof verification uses Server System Title (Green Book Table 43).
2. Key Separation: Use Authentication Key (GAK), not Encryption Key (GUEK).
3. Data Payload: CtoS hashes StoC; Server Proof hashes CtoS.
4. Anti-Replay: Guarantee monotonic $IC$ incrementation before challenge generation.

1. AARQ with Client Challenge (CtoS

00 01 00 01 00 01 00 3C 60 3A A1 09 06 07 60 85 74 05 08 01 03 A6 0A 04 08 4D 4D 4D 00 00 00 00 01 8A 02 07 80 8B 07 60 85 74 05 08 02 05 AC 0A 80 08 43 74 6F 53 31 32 33 34 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 00

2. AARE with Server Challenge (StoC

00 01 00 01 00 01 00 3C 61 3A A1 09 06 07 60 85 74 05 08 01 03 A2 03 02 01 00 A3 05 A1 03 02 01 00 A6 0A 04 08 47 52 58 00 00 00 00 01 88 02 07 80 89 07 60 85 74 05 08 02 05 AA 0A 80 08 50 36 77 52 4A 32 31 46 BE 10 04 0E

3. CtoS Action Request (Method 1) & StoC Server Proof Action Response succeed cleanly.

When the meter receives Action-Request Method 1, it checks:
$$IC_{\text{CtoS}} > IC_{\text{last_stored}}$$
If the client retransmits CtoS with an old or duplicate $IC$, the meter returns Action-Response-With-Service-Error: hardware-fault (0xC7 0x01 C1 01). Always ensure the client increments its $IC$ before building CtoS!

$$\text{CtoS Tag} = \text{GMAC}{\text{GAK}}(\text{SystemTitle}{\text{Client}} \parallel IC_{\text{Client}}, \text{AAD}{\text{0x10}}, \text{StoC})$$
$$\text{StoC Tag (Server Proof)} = \text{GMAC}{\text{GAK}}(\text{SystemTitle}{\text{Server}} \parallel IC{\text{Server}}, \text{AAD}_{\text{0x10}}, \text{CtoS})$$

Notice the perfect criss-cross symmetry between Challenge Originator and System Title Holder per DLMS Green Book Section 9.2.5.3.

1. System Title Inversion: Our code was using client.ciphering.systemTitle to build the IV for both CtoS AND StoC verification, instead of using server.systemTitle (4752580000000001 / GRX00000001) for the Server Proof!
2. Challenge Inversion: We were hashing StoC against the server response, rather than our original CtoS challenge string.

Once we passed serverSystemTitle and clientChallenge into the AES-GCM GMAC validator, the computed tag matched 88 F0 1A 2B 3C 4D 99 11 22 33 44 55 with 0 bit errors!

Per DLMS Green Book 10th Ed Section 9.3.4 (Association LN Class 15), when HLS 5 is used, the calling-authentication-value in AARQ must use the charstring or bitstring choice with tag [0] (ACSE User Information = 14).

If the HES transmits the initial CtoS challenge in AARQ with an incorrect length (e.g. 8 bytes vs 16 bytes), the meter's internal RNG pads the challenge with zeros, causing the Server Proof calculation to diverge from the client's expectation.

Dissecting the meter's proof:

• 10: Server Security Control byte
• 00 00 00 01: Server Invocation Counter (0x00000001)
• 88 F0 1A 2B 3C 4D 99 11 22 33 44 55: 12-byte Server GMAC Tag

Per IEC 62056-53 Section 8.4.2 and DLMS Green Book Section 9.2.5.3.2, to verify this Server Proof, your client must execute:
$$\text{IV} = \text{ServerSystemTitle} (8\text{B}) \parallel \text{ServerIC} (0x00000001)$$
$$\text{AAD} = \text{0x10} \parallel \text{GAK}$$
$$\text{Data} = \text{Client Challenge (CtoS extracted from AARQ)}$$

If your client passed StoC instead of CtoS as the data payload during Server Proof verification, it fails immediately!

In DLMS Green Book Section 9.2.5.3, HLS 5 authentication strictly uses the Authentication Key (GAK) (e.g. D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF), NOT the Global Unicast Encryption Key (GUEK: 000102030405060708090A0B0C0D0E0F).

In your Action-Request hex:
10 00 00 00 01 1A 52 FE 7D D3 E7 27 48 97 3C 1E 28

• 10: Security Control (0x10 = Global Key, Authenticated Only, Security Suite 1)
• 00 00 00 01: Client Invocation Counter 1
• 1A 52 FE ...: 12-byte GMAC tag.

Notice that 1A 52 FE 7D D3 E7 27 48 97 3C 1E 28 exactly matches the official Green Book Table 43 test vector when StoC is 503677524A323146 and Client System Title is 4D4D4D0000000001! This proves your client computed CtoS correctly, meaning the meter accepted it and incremented its own Invocation Counter to 1 for the Server Proof.

Per DLMS Green Book 10th Ed Section 9.2.5.3 (High Level Security Mechanism 5) and Table 43 (HLS 5 Standard Test Vectors), HLS 5 uses AES-GCM-128 authentication in two asymmetric directions:

1. Client to Server Proof (CtoS):
   • Input challenge: StoC (generated by meter)
   • IV Construction: $\text{IV}_{\text{CtoS}} = \text{Client System Title (8B)} \parallel \text{Client Invocation Counter (4B)}$
   • AAD: $\text{Security Control (0x10)} \parallel \text{Authentication Key (GAK)}$
2. Server to Client Proof (StoC):
   • Input challenge: CtoS (generated by client in AARQ)
   • IV Construction: $\text{IV}_{\text{StoC}} = \text{Server System Title (8B)} \parallel \text{Server Invocation Counter (4B)}$

Look closely at how your HES client verifies the meter's response:
If your client code re-used the Client System Title (or client IV) instead of extracting the Server System Title from the AARE response (0x61), the AES-GCM GHASH polynomial state will calculate a completely different tag!