mGuard

# NAC-ABE

### NAC-ABE in mGuard

NAC-ABE implements name-based access control using two layers:

1. **Symmetric encryption of data** using Content Key (CK).  

2. **ABE encryption of CK** using AA-issued public parameters and consumer policies.

Data is encrypted with a CK, and the CK itself is encrypted under ABE so that only authorized consumers holding a matching Decryption Key (DKEY) can recover it.

The Attribute Authority (AA) publishes public parameters and issues DKEYs, while NAC-ABE producers generate CKs and encrypted data using these parameters.

This removes the need for any online authorization server during data fetch and enables cryptographically enforced access control at the packet level.

---

### Why KP-ABE

mGuard adopts KP-ABE because it removes all producer-side dependency on access-control decisions.

In KP-ABE:

- The producer attaches a vector attribute to each CK.

- The consumer’s DKEY contains the policy created by the AA.

- Decryption succeeds when the policy prefix matches the CK attribute.

- The producer never needs to know who will access the data or what policy applies.

This makes KP-ABE ideal for mGuard because:

- Access rights can change without re-encrypting any CKs or data.

- New users can be added simply by issuing new DKEYs.

- Producers remain lightweight and stateless regarding authorization.

KP-ABE gives mGuard flexible, prefix-based authorization that works entirely at the consumer, eliminating the re-encryption burden of CP-ABE.

CP-ABE → policy in ciphertext → requires re-encrypting CKs when access changes → old NAC-ABE

KP-ABE → attributes in ciphertext, policy in DKEY → no re-encryption → current Implementation

---

### Certificates

NAC-ABE uses two distinct certificates, each serving a different purpose in the trust and encryption pipeline.

#### Stream Certificate

The stream certificate defines the namespace and identity under which CKs and encrypted data are published. NAC-ABE derives CK names from this certificate:

``` c

/<stream-identity>/CK/<random>/ENC-BY/<attributes>/seg=i

```

Encrypted data packets are also named under the same identity prefix. This ensures that each stream's data and CKs are isolated and validated using the stream's trust chain.

All CK and encrypted data packets are signed according to the stream’s identity chain.

#### Attribute Authority (AA) Certificate

The AA certificate anchors the ABE trust domain. It is used to validate:

- Public Parameters (PUBPARAMS)

- AA KEY packets

- Any ABE-related metadata

- The AA certificate ensures that only authenticated parameters are used for CK generation and that consumers can trust the DKEYs they receive.

---

###  ABE Encryption of CK

![](nac-abe end-to-end.png)

---

---

### Content Key (CK)

A CK is the symmetric key used to encrypt data. CK rotation frequency determines access-control precision. A user can only decrypt data encrypted with CKs they are authorized for.

#### CK Granularity

- **Second-level:** maximum precision, very high overhead

- **Minute-level:** balanced precision vs cost

- **Hour-level:** minimal overhead, coarse control

Granularity determines access-control precision and system cost.

**CK vs Access-Control Granularity**

CK granularity must be **equal to or finer than** the access-control granularity.

| Access Control ↓ / CK → | second | minute | hour |

|--------------------------|--------|--------|------|

| second                   | ✔️     | ❌     | ❌   |

| minute                   | ✔️     | ✔️     | ❌   |

| hour                     | ✔️     | ✔️     | ✔️   |

Rule: CK granularity cannot be coarser than the authorization window.

**CK Reuse Tradeoffs**

**High reuse (minute/hour):** fewer CK packets, low cost; coarse control.

**Low reuse (second):** fine-grain control; many CKs, high overhead.

**Implementation Note**

Most encryption overhead is CK generation, not data encryption; finer CK granularity increases load.

---

### End-to-End Flow