mGuard

# NAC-ABE Design

### What NAC-ABE Provides

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 mGuard Uses KP-ABE

A KP-ABE policy defines which identities can receive a Decryption Key (DKEY) and which data attributes that DKEY authorizes them to decrypt. Each policy includes:

- A **policy-id** , which uniquely identifies the policy.

- A list of **requester-names** , representing the NDN identities that will receive the DKEY generated from this policy.

- One or more **attribute-filters** , typically expressed as namespace prefixes. These prefixes determine which encrypted Content Keys (CKs) the resulting DKEY can decrypt.

Policies are evaluated using exact prefix matching. If the attribute attached by the producer during CK generation starts with a prefix listed in an allow-filter, a DKEY created from that policy will successfully decrypt the CK.

No role-based or device-level semantics are required; access control is driven entirely by namespace prefixes embedded within attributes.

The producer never evaluates policies and never needs access to DKEYs. All authorization takes place on the consumer side using the policy embedded in the DKEY.

---

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

#### 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 (Black Box Description)

---

## 4. Certificates in NAC-ABE (Updated mGuard Behavior)

### 4.1 Stream Identity Certificate

The stream’s certificate is used by NAC-ABE for:

**a) Naming CKs**  

Updated mGuard naming:

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

This scopes CKs to each stream.  

Different streams produce CKs under different prefixes.

**b) Naming encrypted data**

/<stream-identity>/<data-suffix>

This maintains per-stream isolation.

**c) Signing and trust schema validation**

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

---

### 4.2 AA Certificate

The AA certificate is used as the **trusted root of ABE**.

It enables the producer and consumer to:

1. Validate AA **Public Parameters (PUBPARAMS)**.

2. Validate AA **KEY** packets.

3. Determine **ABE type** from PUBPARAMS (KP-ABE vs CP-ABE).

4. Run `kpContentKeyGen()` (needs verified public params).

The AA certificate defines the mathematical ABE domain; the stream certificate defines the namespace and signing authority for CK and data packets.

---

## 5. End-to-End Flow (Producer → Repo → Consumer)

---

### Content Key (CK)

A CK is the symmetric key used to encrypt data.

CK rotation frequency determines **how precisely access control can be enforced**.

A user can only decrypt data encrypted with CKs they are authorized to received.

### 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 rotation 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.

![](att-authority.png)

![](nac-abe-pro-con.png)