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¶

mGuard uses Key-Policy ABE (KP-ABE) because:

• The producer supplies an attribute set for each stream’s data (e.g., ["device:dd40c", "sensor:accelerometer"]).
• The consumer holds a policy embedded in its DKEY (e.g., requester:researcher AND device:dd40c).
• Decryption succeeds only if the consumer's policy matches the producer's attribute list.

The producer attaches an attribute set to each encrypted item, and each DKEY encodes a policy.
This shifts policy management away from producers and simplifies code.

KP-ABE supports stream-specific semantics and flexible downstream authorization.

---

3. ABE Encryption of CK (Black Box Description)¶

When the producer encrypts one data chunk:

1. Producer calls:
2. Output:
3. a fresh symmetric CK
   
4. CK segments encrypted with KP-ABE (using AA public parameters)
   
5. Producer encrypts the data payload with CK.
   
6. Producer embeds the CK name inside the encrypted data.
   
7. Producer publishes:
8. CK segments
   
9. encrypted data segments

The consumer later:

• fetches CK segments,
• decrypts CK using its DKEY,
• decrypts the encrypted data.

The producer treats ABE internals as a complete black box.

---

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:
//CK//ENC-BY//seg=i
This scopes CKs to each stream.

Different streams produce CKs under different prefixes.

b) Naming encrypted data
//
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)¶

5.1 Producer Path¶

1. Per-stream CacheProducer initialization

   • loads stream cert
     
   • loads AA cert into trust config
     
   • fetches AA public parameters

2. Prepare data for encryption

   • data name suffix
     
   • attribute list
     
   • plaintext bytes

3. CK caching check

   • key = attributes-as-string
     
   • if CK exists in cache → reuse
     
   • else → generate new CK using kpContentKeyGen

4. CK generation on cache miss

   • ABE-encrypt CK using AA public parameters
     
   • name CK under stream identity
     
   • segment CK and store in cache

5. Data encryption

   • encrypt data with CK
     
   • embed CK name into ciphertext
     
   • segment encrypted data

6. Publishing

   • publish encrypted data segments
     
   • publish CK segments (for new CK)
     

---

5.2 Consumer Path¶

1. Fetch encrypted data segments.
   
2. Extract CK name from ciphertext.
   
3. Fetch CK segments.
   
4. Use DKEY to decrypt ABE-encrypted CK.
   
5. Use CK to decrypt the data.

All authorization is performed cryptographically using consumer DKEYs and producer-provided attributes.

---

6. ABE Key Issuance (DKEY Generation)¶

1. Consumer sends a request (identity TLV) to AA.
   
2. AA verifies consumer identity using trust schema.
   
3. AA constructs a DKEY containing a policy (e.g., "role:doctor AND device:dd40c").
   
4. AA segments and returns DKEY packets.
   
5. Consumer installs DKEY and uses it to decrypt CKs.

The AA never needs to be contacted again; DKEY is long-lived until revoked or replaced.

---

7. CK Granularity (Temporal Encryption Granularity)¶

CK granularity determines how often CKs rotate or are changed.

Common settings:¶

• Second-level CKs
  Maximum security; high CK overhead.
• Minute-level CKs
  Balanced performance vs granularity.
• Hour-level CKs
  Minimal overhead; coarse access control.

Granularity influences both performance and access separation.

---

8. Tradeoffs of CK Reuse¶

High CK Reuse (e.g., minute/hour)¶

Pros:

• fewer CK packets
  
• reduced overhead
  
• faster encoding and repo insertion

Cons:

• larger window where one CK decrypts many packets
  
• coarse-grained access control

---

Low CK Reuse (e.g., per second)¶

Pros:

• tight access control window
  
• limits impact of any single CK compromise
  
• better fine-grain policy enforcement
  

Cons:

• more CK segments to generate and publish
  
• more consumer fetches
  
• higher repo overhead

---

Summary¶

• NAC-ABE supplies per-packet cryptographic access control.
  
• mGuard uses KP-ABE for attribute-driven encryption.
  
• Stream certificates now define CK and data namespaces.
  
• AA certificate anchors ABE trust and supplies public parameters.
  
• CKs are cached per attribute set, generated on demand, and consumed by any valid DKEY holder.
  
• CK granularity and reuse directly impact performance and access control precision.

Why KP-ABE

Data encryption → CK encryption → CK decryption

ABE encryption of CK (black box)

ABE key issuance (DKEY)

CK granularity (second/minute/hour)

Tradeoffs of CK reuse level