SecurityControl 0x10 vs 0x30 — is authentication-only just a DLMS checksum?

[sarah_jenkins]

I am reviewing two protected DLMS captures and want to confirm the correct terminology.

Our older parser labels 0x10 as "checksum protection" and 0x30 as "encrypted protection".

That naming now looks wrong to me.

The simplified traces below are synthetic, but preserve the structure I am seeing.

Capture A — authentication protection

C8 xx
10
00 00 00 2A
C0 01 C1 00 01 00 00 01 00 00 FF 02 00
7D 91 2A 44 35 8E 10 A0 B1 C2 D3 E4

My current byte-level interpretation:

C8
└─ glo_GetRequest

10
└─ Security Control = authentication

00 00 00 2A
└─ Invocation Counter = 42

C0 01 C1 00 01 00 00 01 00 00 FF 02 00
└─ inner GET APDU remains visible in this example

7D 91 2A 44 35 8E 10 A0 B1 C2 D3 E4
└─ example authentication tag

If I flip one byte in the visible GET APDU, the receiver rejects the packet even though the APDU is not confidential.

Capture B — authentication + encryption

C8 xx
30
00 00 00 2B
7A 91 C4 08 2D A0 9F 6B 11 85 D2 31
4C 83 6E A2 6D 73 05 91 9A 20 31 7F
...

Interpretation:

C8
└─ glo_GetRequest

30
└─ Security Control = authentication + encryption

00 00 00 2B
└─ Invocation Counter = 43

7A 91 C4 08 ...
└─ protected payload; the original GET APDU is no longer
   directly readable from the wire

So should 0x10 be described as integrity/authenticity protection, rather than a checksum?

And is the practical difference:

0x10 → readable payload + cryptographic authentication
0x30 → encrypted payload + cryptographic authentication

?

[alex_turner]

That is the better terminology.

0x10 is not a normal checksum mode.

A CRC/FCS answers something like:

"Did these bits probably change during transmission?"

The authenticated DLMS protection answers a stronger question:

"Was this protected message produced by a party holding the
required cryptographic material, and was the protected data modified?"

So I would label the modes:

0x10 = Authentication / integrity protection
0x30 = Authentication + encryption

With 0x10, confidentiality is not the goal. A sniffer may still understand the inner APDU.

With 0x30, the receiver must first validate/decrypt the protected content before you can meaningfully parse the GET/SET/ACTION body.

[marcus_vance]

Also keep link-layer FCS and DLMS data protection separate.

For HDLC you can have:

HDLC FCS
+
DLMS security protection

at the same time.

They solve different problems.

The FCS is unkeyed transport error detection.

The DLMS authentication tag is keyed cryptographic protection.

And if you are using the DLMS Wrapper interface, there is no HDLC FCS around the Wrapper frame anyway, so calling 0x10 a "checksum" becomes even more confusing.

I would avoid this log message:

checksum verification failed

and use something explicit:

DLMS authentication tag verification failed

[elena_rostova]

For field debugging I normally parse protected APDUs in this order:

1. Protected APDU type
2. Security Control
3. Security Suite bits
4. Invocation Counter
5. Sender System Title / security context
6. Authentication and ciphering parameters
7. Verify authentication
8. Decrypt if encryption is enabled
9. Parse the inner xDLMS APDU

The order matters.

If the packet starts with:

30 00 00 00 2B ...
^^

and 0x30 is the Security Control, there is little value in searching the following ciphertext for:

OBIS
class-id
attribute-id
GET tag

until protection processing succeeds.

For 0x10, seeing a recognizable GET body does not mean the protection is optional. A single modified byte can still invalidate the authentication tag.

[david_miller]

One more thing: the invocation counter belongs in your security troubleshooting dashboard.

A lot of "wrong key" incidents are actually:

counter reused
counter lower than meter expects
counter read from the wrong security context
counter reset after restart

So when a protected packet fails, log at least:

securityControl
securitySuite
invocationCounter
systemTitle
direction
APDU type
verification result

Do not log live keys.

That usually tells you whether you have:

a DLMS parser problem
a replay/counter problem
a security-context problem
or an actual key mismatch

before you start changing cryptographic configuration.