---
title: 'MM-TCN-CMA: Caching-based Multicast Authentication'
url: https://www.emergentmind.com/topics/mm-tcn-cma
type: topic
---

# MM-TCN-CMA: Caching-based Multicast Authentication

Searching arXiv for the specified paper and closely related context.
arxiv_search.query({"search_query":"id:2308.04034 OR ti:\"Caching-based Multicast Message Authentication in Time-critical Industrial Control Systems\"","start":0,"max_results":5})
arxiv_search.query({"search_query":"ti:\"Caching-based Multicast Message Authentication in Time-critical Industrial Control Systems\"","start":0,"max_results":10})
The designation **MM-TCN-CMA** does not appear in the paper that defines the relevant mechanisms. The corresponding technical subject is the pair of schemes **Caching-based Message Authentication (CMA)** and **Caching-based Multicast Message Authentication (CMMA)**, introduced for immediate authentication of time-critical messages in industrial control systems (ICS), especially IEC 61850-based substation automation in smart grids. Their central idea is to precompute and cache authentication evidence for a set of likely future messages, so that after a message is issued the publisher performs no hashing, and after reception the subscribers avoid expensive public-key verification. The schemes are designed for communication models including unicast, multicast, and broadcast under message rates up to **4,000 messages per second** and end-to-end latency budgets of **1–2 ms** [2308.04034].

## 1. Problem setting and operational constraints

The paper targets ICS deployments in which authentication failures enable malicious data injection or command injection by illegitimate or compromised devices. The motivating environment is the **substation automation system** in smart grids using **IEC 61850** protocols, with particular attention to **GOOSE** and **SV** traffic. GOOSE is described as **event-driven, link-layer multicast**, whereas SV is **periodic, high-rate** traffic that can reach **4,000 msg/s**. Within this setting, certain protection and control commands must satisfy end-to-end deadlines of **1–2 ms** under **IEEE 1646** [2308.04034].

These constraints exclude straightforward deployment of standard public-key broadcast authentication. The reported evaluation gives **ECDSA verification ≈ 2500 µs on BeagleBoard-X15**, which is far above the budgets that govern the most time-critical paths. The paper also treats plain **TESLA/delayed key disclosure** as insufficient for the strictest loops: even a minimal one-interval delay at **4k msg/s** adds **≈250 µs**, and that delay is itself part of the critical path. This combination of high-rate traffic, multicast dissemination, and immediate-verification requirements motivates a design based exclusively on symmetric primitives and offline precomputation rather than post hoc signing or delayed authentication disclosure [2308.04034].

A further enabling condition is the partial predictability of ICS traffic. The paper states that IEC 61850 GOOSE PDUs contain many structured and predictable or slowly varying fields, including **IDs, confRev, ndsCom, test, datSet, goID, stNum/sqNum increments**, while **allData** often consists of binary status flags or bounded measurements such as frequency around **50 Hz**. This limited entropy is what makes it possible to enumerate likely future messages and precompute authenticators for them.

## 2. Threat model, trust assumptions, and design objectives

The adversary model assumes **remote attackers with network foothold**, for example via a compromised VPN or malware, who can inject or forge packets, attempt replays, and observe traffic. The same model excludes local reconfiguration of ICS devices and assumes that **BITW devices are non-addressable by remote attackers**. The schemes therefore focus on protecting message integrity, source legitimacy, and replay resistance in a constrained but realistic network threat model [2308.04034].

The trust model differs between the two schemes. **CMA** uses **pairwise symmetric keys** between the source and each destination. **CMMA** replaces per-destination MAC authentication with a **TESLA-style one-way key chain** to obtain source–destination asymmetry without computing a separate MAC for each receiver. CMMA therefore requires **loose time synchronization** and a **key disclosure delay** satisfying the condition that it is at least the **network delay + clock skew**. Replay protection additionally relies on application and protocol metadata, including **timestamps**, **sequence numbers**, and **timeAllowedtoLive**.

The design objectives are explicit. The paper aims to **achieve immediate verification with symmetric primitives**, and to **eliminate expensive cryptography both after message issuance and upon reception** by pushing work into a precomputation-and-caching stage. This suggests that the schemes are not merely lightweight MAC wrappers; they are organized around temporal decoupling of authentication work from message transmission time, with preauthenticated metadata serving as a stand-in for later cryptographic effort.

## 3. Core construction: cached authentication via hash trees

The core mechanism is to precompute authentication “evidence” over a candidate set of future messages by building an authenticated binary hash tree. Each candidate message is assigned to a leaf, and only the **root** is directly authenticated. The **tree nodes** are retained as private metadata at the source. When the actual message is later known, the publisher transmits the message together with a short proof consisting of the **sibling path** and the **leaf nonce**, allowing the receiver to recompute the root and compare it to the root authenticated earlier [2308.04034].

Two tree variants are used. A **Merkle Hash Tree (MHT)** is used when candidates are equally likely. A **Huffman Hash Tree (HHT)** is constructed from urgency or likelihood weights \( p_i \), so that more likely or more time-critical messages are placed closer to the root. Leaves take the form \( H(\text{message} \parallel \text{nonce}) \) with a fresh **256-bit nonce** per leaf, and internal nodes are \( H(\text{left} \parallel \text{right}) \). The root for interval \( i \) is denoted \( \text{root}_i \).

The procedures given in the paper define the two protocols precisely.

For **CMA**, the protocol is:

1. **Initialize(\(\lambda\)) \(\to \{K\}\)**: establish pairwise keys \( K = \{sk_1, \ldots, sk_N\} \); repeat every \( L \) messages.  
2. **Prioritize(preferences, system\_data) \(\to \{M_i, P_i\}\)**: compute the candidate set \( M_i = \{m_{i,1}, \ldots, m_{i,2^k}\} \) and normalized weights \( P_i = \{p_{i,1}, \ldots, p_{i,2^k}\} \), with \( \sum_j p_{i,j} = 1 \).  
3. **TreeConstruction(\(M_i, P_i, K, ts_i\)) \(\to \{tree_i, root_i, S_i\}\)**: build an HHT or MHT, compute \( root_i \), and for each destination \( n \) compute  
   \[
   s_{i,n} = \mathrm{HMAC}(sk_n, ts_i, root_i).
   \]
   The source shares \( (root_i, s_{i,n}) \) with destination \( n \) before the actual message is known.  
4. **Prove(\(m_{i,t}, tree_i\)) \(\to \{proof_i\}\)**: collect the proof path and leaf nonce; no hashing is required.  
5. **Pre-Verify(\(sk_n, s_{i,n}, root_i\)) \(\to \text{accept/reject}\)**: the destination verifies \( s_{i,n} \) and stores \( root_i \) for the interval indicated by **timeAllowedtoLive**.  
6. **Verify(\(m'_{i,t}, proof_i, root_i\)) \(\to \text{accept/reject}\)**: the destination recomputes the path to the root and accepts if it matches the stored root.

For **CMMA**, pairwise MACs are replaced by a TESLA-style authenticated key chain:

1. **Initialize(\(C'_L\)) \(\to \{C_0, \ldots, C_L, proof(C_0)\}\)**: generate the chain \( C_{i-1} = H(C_i) \), \( i = 1..L \), with random \( C_L \), and derive MAC keys \( C'_i = H'(C_i) \).  
2. **Prioritize(preferences, system\_data)**: as above.  
3. **TreeConstruction(\(M_i, P_i, C_i, ts_i\)) \(\to \{tree_i, root_i, s_i\}\)**: compute the root and authenticate it with  
   \[
   s_i = \mathrm{HMAC}(H'(C_i), ts_i, root_i).
   \]
4. **Prove(\(m_{i,t}, tree_i\)) \(\to \{proof_i, C_i\}\)**: send the message and proof immediately, while disclosing \( C_i \) only in a later interval \( d + i \).  
5. **Verify(\(C_i, C_{i-1}, s_i, m_{i,t}, proof_i\)) \(\to \text{accept/reject}\)**: validate the key chain, recompute the root from the proof, and verify \( s_i \).

The architectural difference between the two schemes is summarized below.

| Scheme | Root authentication | Receiver scope |
|---|---|---|
| CMA | \( s_{i,n} = \mathrm{HMAC}(sk_n, ts_i, root_i) \) | Per destination |
| CMMA | \( s_i = \mathrm{HMAC}(H'(C_i), ts_i, root_i) \) | Shared by all receivers |
| Common mechanism | HHT/MHT proof over cached candidates | Immediate proof-based verification |

This organization allows **zero hashes after message issuance** at the source. The destination still hashes along the proof path, but avoids public-key verification entirely.

## 4. Urgency profiles, expected verification cost, and communication overhead

A distinctive feature of the construction is its use of an **urgency profile** or **likelihood profile**. For interval \( i \), the candidate set is \( M_i = \{m_{i,1}, \ldots, m_{i,2^k}\} \), and the weights are \( P_i = \{p_{i,1}, \ldots, p_{i,2^k}\} \) with \( \sum_j p_{i,j} = 1 \). The HHT uses these weights so that likely or urgent messages appear closer to the root and therefore require shorter proofs [2308.04034].

The paper expresses the resulting verification work in secure-hash equivalents. For **CMA with HHT**, the total per-message verification cost is approximately \( D_{i,j} + 3 \), where \( D_{i,j} \) is the depth of leaf \( j \). For **CMMA with HHT**, TESLA-related processing adds two further hashes, yielding approximately \( D_{i,j} + 5 \). The expected costs are:
\[
E[T_i] = \sum_{j=1}^{2^k} p_{i,j}\,(D_{i,j}+3)
\]
for CMA, and
\[
E[T_i] = \sum_{j=1}^{2^k} p_{i,j}\,(D_{i,j}+5)
\]
for CMMA. By the use of Huffman construction, the expected depth \( E[D] \) is minimized for the given distribution.

Communication overhead is likewise expressed in **hash values** per message, with **32 bytes per hash** under SHA-256. For CMA with MHT, the proof contributes **\(k+1\)** hash values and the authenticated root contributes one further hash-equivalent, giving **\(N \cdot (k+2)\)** hash values in total across \(N\) destinations. For CMA with HHT, the per-destination total becomes **\(N \cdot (D+2)\)**. For CMMA, which does not replicate root authentication per subscriber, the totals are **\((k+3)\)** hash values for MHT and **\((D+3)\)** for HHT, both shared across all receivers.

The paper’s analysis of likelihood distributions reports that **four distributions** were evaluated, including one with **\(p_1 = 0.9\)** and the remaining mass distributed uniformly. Under such skew, **CMMA with HHT significantly outperforms MHT**, with the paper linking this to IEC 61850 traffic patterns in which **“no state change” messages dominate**. A plausible implication is that the benefit of the scheme is maximized precisely in those operational regimes where nominal steady-state traffic vastly outweighs exceptional-state traffic.

## 5. Security properties, complexity, and state requirements

The schemes use **SHA-256** as the hash function, **HMAC-SHA-256** as the MAC, and a PRF **\(H'\)** derived from SHA-256 for TESLA key derivation. Each leaf includes a fresh **256-bit nonce**. The optional public-key baseline used for comparison is **ECDSA P-256**, with a **128-bit security target** [2308.04034].

Replay protection and freshness are tied to both protocol fields and cache lifetime. The authenticated root is bound to **\(ts_i\)**, destinations retain root state only for **timeAllowedtoLive**, GOOSE sequence information through **sqNum/stNum** aids replay detection, and proofs are indexed by interval and timestamp. The security sketch given in the paper reduces forgery resistance to standard assumptions: in CMA, an adversary that forges a valid proof for a new message under the same root must either recover nonces, violating preimage resistance, or find a collision on the path from leaf to root, violating collision resistance; in CMMA, security additionally depends on the **one-wayness of the TESLA key chain** and MAC unforgeability. With **256-bit nonces** and **SHA-256**, the forging probability is stated to be negligible, specifically **\(\le 2^{-128}\)** at the targeted security level.

The complexity formulas make the asymmetry between source and destination explicit. Using \(N\) for the number of subscribers, \(k\) for the number of unpredictable binary fields, \(R_1\) for message arrival rate, \(R_2 = 1/\text{timeAllowedtoLive}\), and \(D\) for the realized leaf depth, the source-side secure-hash rates are:
\[
(2N + 2^{k+1} - 1)\cdot R_2
\]
for CMA, and
\[
(3 + 2^{k+1})\cdot R_2
\]
for CMMA. Destination-side rates are:
\[
(k+3)\cdot R_1
\]
for CMA with MHT,
\[
(D+3)\cdot R_1
\]
for CMA with HHT,
\[
(k+5)\cdot R_1
\]
for CMMA with MHT, and
\[
(D+5)\cdot R_1
\]
for CMMA with HHT.

Memory use is dominated by the cached tree. The source stores **\(2^{k+1}-1\)** hashes and **\(2^k\)** nonces. Under SHA-256, each occupies **32 bytes**, yielding
\[
M_{\text{tree}} \approx (2^{k+1}-1)\cdot 32 + (2^k \cdot 32)\ \text{bytes}.
\]
CMA also stores per-destination MAC state of **\(N \cdot 32\)** bytes per interval, whereas CMMA stores a single **32-byte** MAC \(s_i\). Destinations store the root and root authenticator until expiry, and CMMA receivers additionally maintain the latest TESLA keys and disclosure schedule. This suggests that CMMA is primarily a scaling improvement in receiver multiplicity rather than a change to proof structure itself.

## 6. Empirical evaluation, robustness, and relation to alternatives

The evaluation uses a **BeagleBoard-X15** with a **single active core**, with trees resident in RAM, and reports averages over **500 runs**. With **32 prioritized messages**, **CMA and CMMA precompute trees in ≈ 210–250 µs**. The paper states that **CMMA precomputation is ~23 µs faster than tree’d ECDSA across subscriber/message counts** because it uses only symmetric hashing, while ECDSA incurs substantial signing and verification costs. The reported precomputation rate is sufficient to support **IEC 61850 SV throughput (4000 msg/s)** when the true message lies in the prioritized set [2308.04034].

At verification time, the baseline **HMAC per-message verification** costs **≈ 4 µs**. For HHT-based CMA and CMMA, best-case latency occurs when the most likely message is placed at **depth 1**. In that case, **CMA ≈ 2 hashes → ~4 µs**, and **CMMA** requires **~6 hashes → ~12 µs** because of the added TESLA check, key derivation, and HMAC verification. The paper states that MHT performs worse on average than HHT because MHT ignores likelihood. By contrast, **ECDSA verification ≈ 2500 µs**, which the paper treats as impractical for **≤2 ms** deadlines. The resulting verification latencies, in **microseconds** rather than milliseconds, leave substantial headroom for transport and application processing.

The paper also addresses robustness and operational edge cases. If the actual message is absent from the current prioritized set, the system can **fall back to computing a standard MAC on the fly** in the unicast case, or **defer to the next interval’s prioritized set** in the multicast case, incurring delay comparable to a non-precomputed baseline. In CMMA, if **\(C_{i-1}\)** is lost, a receiver can validate **\(C_i\)** by repeated hashing until it matches a previously stored key, providing resilience to packet loss. Out-of-order proofs are handled by indexing them with **interval \(i\)** and **\(ts_i\)**, and expired proofs are rejected after **timeAllowedtoLive**. The paper further notes that **BITW deployment** is compatible with legacy devices and requires **no application payload changes other than appending proof and root MAC**.

Relative to alternative schemes, the paper contrasts CMA and CMMA with **RSA/ECDSA**, **TESLA/delayed key disclosure**, **polynomial authentication codes**, **OTS/WOTS variants**, and **signature amortization**. Public-key signatures provide non-repudiation but exceed the required timing envelope. Plain TESLA is efficient but imposes disclosure delay on the message-authentication path. Polynomial and one-time-signature approaches are described as having large keys, large signatures, or state-management burdens, while signature amortization still depends on expensive public-key operations and may be sensitive to loss, jitter, or immediate-verification requirements. The paper’s counterposition is that CMA and CMMA exploit the **low entropy and predictability of ICS messages** to collapse many potential authenticators into a single authenticated root per interval, with **CMMA** specifically eliminating per-destination MAC computation for multicast and broadcast. A common misconception is that TESLA alone already solves broadcast authentication for these environments; the reported **≈250 µs** disclosure delay at **4k msg/s** is presented as evidence that delayed disclosure is still too costly for the tightest protection loops, whereas CMMA shifts authentication of the prioritization outcome ahead of message transmission.

In deployment terms, the paper recommends identifying predictable fields in **GOOSE/SV allData and header**, building candidate sets per **timeAllowedtoLive**, choosing **HHT** when message distributions are skewed, using **256-bit nonces** and **256-bit HMAC-SHA-256**, setting TESLA chain length \(L\) to cover the disclosure schedule, and ensuring \( d \ge \) **max network delay + clock skew**. CMA is described as suitable for **unicast or small multicast groups** where pairwise MACs are acceptable, while CMMA is the scalable variant for **multicast/broadcast groups with time synchronization**.

Source: https://www.emergentmind.com/topics/mm-tcn-cma