NAC-ABE Design » History » Revision 5
Revision 4 (Suravi Regmi, 11/24/2025 07:37 PM) → Revision 5/11 (Suravi Regmi, 11/24/2025 07:51 PM)
# 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. KP-ABE supports stream-specific semantics and flexible downstream authorization. In KP-ABE, the producer assigns an attribute string to each Content Key (CK). The consumer receives a DKEY that contains a policy, usually expressed as one or more namespace prefixes. Decryption succeeds when: - policy_prefix is a prefix of attribute_string This creates a simple, deterministic Matching Rule: - The producer attaches attributes to CKs. - The consumer holds a DKEY containing a prefix-based policy. - Authorization is validated locally through prefix comparison. - T he 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. ## 3. ABE Encryption of CK (Black Box Description) When the producer encrypts one data chunk: 1. Producer calls: 2. Output: - a fresh **symmetric CK** - CK segments encrypted with KP-ABE (using AA public parameters) 3. Producer encrypts the data payload with CK. 4. Producer embeds the **CK name** inside the encrypted data. 5. Producer publishes: - CK segments - 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: /<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 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 is the symmetric key used to 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. data with CK rotation frequency determines **how precisely access control can be enforced**. A user can only decrypt - embed CK name into ciphertext - segment encrypted data 6. **Publishing** - publish encrypted with CKs they are authorized to received. data segments - publish CK segments (for new CK) --- ### Content Key (CK) A 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 the symmetric key used performed cryptographically using consumer DKEYs and producer-provided attributes. --- ## 6. ABE Key Issuance (DKEY Generation) 1. Consumer sends a request (identity TLV) to encrypt data. 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 rotation frequency Granularity (Temporal Encryption Granularity) CK granularity determines access-control precision. A user can only decrypt data encrypted with how often CKs they rotate or are authorized for. changed. ### CK Granularity Common settings: - **Second-level:** maximum precision, very **Second-level CKs** Maximum security; high overhead CK overhead. - **Minute-level:** balanced precision **Minute-level CKs** Balanced performance vs cost granularity. - **Hour-level:** minimal overhead, **Hour-level CKs** Minimal overhead; coarse control access control. Granularity determines access-control precision influences both performance and system cost. access separation. --- ## 8. Tradeoffs of CK Reuse ### High CK vs Access-Control Granularity Reuse (e.g., minute/hour) **Pros:** - fewer CK granularity must be **equal to or finer than** the access-control granularity. packets - reduced overhead - faster encoding and repo insertion | Access Control ↓ / **Cons:** - larger window where one CK → | second | minute | hour | |--------------------------|--------|--------|------| | second | ✔️ | ❌ | ❌ | | minute | ✔️ | ✔️ | ❌ | | hour | ✔️ | ✔️ | ✔️ | decrypts many packets - coarse-grained access control Rule: CK rotation cannot be coarser than the authorization window. --- ### Low CK Reuse Tradeoffs (e.g., per second) **High reuse (minute/hour):** fewer **Pros:** - tight access control window - limits impact of any single CK packets, low cost; coarse control. **Low reuse (second):** compromise - better fine-grain control; many CKs, high overhead. policy enforcement **Cons:** - more CK segments to generate and publish - more consumer fetches - higher repo overhead ### Implementation Note --- ## Summary Most encryption overhead is - NAC-ABE supplies per-packet cryptographic access control. - mGuard uses **KP-ABE** for attribute-driven encryption. - **Stream certificates** now define CK generation, not and data encryption; finer 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 increases load. 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  