Questions: Attribute-Based Encryption

Question 1

CP-ABE (ciphertext-policy) and KP-ABE (key-policy) place the access policy in different locations. When is each appropriate?

Model answer: In CP-ABE, the encryptor chooses the access policy (embedded in the ciphertext), and the authority issues keys reflecting users' attributes. This is natural when the data owner decides who should access the data — like a document encrypted with 'Department=HR AND Level>=Manager'. In KP-ABE, the authority embeds policies in keys, and ciphertexts are tagged with attributes. This suits scenarios where the authority controls access decisions — like a pay-per-view system where the broadcaster tags content with attributes and the authority issues keys with viewing policies.

The distinction is about who controls access. CP-ABE gives control to the data owner (encrypt under any policy you like). KP-ABE gives control to the key authority (keys determine what each user can decrypt). Most cloud storage and data sharing scenarios use CP-ABE because data owners want to specify their own access policies.

Question 2

ABE enables access control without trusting the storage server. Why is this stronger than traditional server-enforced access control?

• A. ABE uses stronger encryption algorithms than server-side access control
• B. With server-enforced access control, a compromised or malicious server can bypass policies and read all data. With ABE, the data is encrypted under the policy — even a fully compromised server sees only ciphertext. Only users with attributes satisfying the policy can decrypt, regardless of the server's behavior. The access control is cryptographic, not administrative
• C. ABE policies are more expressive than traditional access control lists
• D. Server-enforced access control is vulnerable to timing attacks

Answer: (B)

This is ABE's fundamental value proposition. Traditional cloud access control means the cloud provider promises to enforce your policies — but they have the plaintext data and could be hacked, coerced, or malicious. ABE encrypts the data itself under the policy. The cloud stores ciphertext; decryption is impossible without the right attributes. This is 'zero-trust' access control: you don't trust the storage provider, the network, or any infrastructure — only the correctness of the cryptography and the key authority.

Question 3

Collusion resistance is a critical security property of ABE. What attack does it prevent?

• A. Multiple users combining their network access to perform a DDoS attack
• B. Two users, neither of whose attributes individually satisfy an access policy, pooling their attributes to decrypt. For example, if the policy is 'Department=Engineering AND Clearance=Secret', a user with only Department=Engineering and a user with only Clearance=Secret should not be able to combine their keys to decrypt
• C. A single user creating multiple accounts to receive more attributes
• D. The key authority colluding with users to forge attributes

Answer: (B)

Collusion resistance is achieved by binding each user's key to a unique random value during key generation. Keys from different users are algebraically incompatible — you cannot mix components from different users' keys because the random values don't match. This ensures that even if all users in the system pool their keys, they can only decrypt what each individual could decrypt alone. Without collusion resistance, ABE would be trivially breakable: any set of users covering all attributes in a policy could collaborate to decrypt.

Question 4

ABE over lattices (rather than bilinear pairings) provides post-quantum security but with significantly larger parameters.

• T. True
• F. False

Answer: True

Pairing-based ABE relies on bilinear maps on elliptic curves, which are broken by quantum computers (Shor's algorithm computes pairings' underlying discrete logarithms). Lattice-based ABE constructions exist (based on LWE) and provide quantum resistance, but with larger keys and ciphertexts — lattice-based ABE ciphertext and key sizes scale with the complexity of the access policy, sometimes by orders of magnitude compared to pairing-based schemes. This is an active research area; practical lattice-based ABE remains challenging.

Question 5

A hospital encrypts patient records under the policy '(Doctor AND SameWard) OR Administrator'. No central server needs to check credentials at access time. What happens when a doctor transfers to a different ward?

Model answer: The doctor's old key (with attributes including the previous ward) still satisfies the policy for records from that ward. ABE does not automatically revoke access — once a key is issued, it works until the system parameters change. Revocation in ABE requires additional mechanisms: time-based attributes (keys expire and must be refreshed), online mediators (a semi-trusted server that assists decryption and can deny assistance to revoked users), or re-encryption of the data under updated policies. Revocation remains one of ABE's most challenging practical problems.

This is analogous to the revocation problem in PKI but harder because ABE keys are attribute-based, not identity-based. You can't simply revoke 'Dr. Smith' — you need to revoke the combination of attributes that no longer applies. Proxy re-encryption and attribute refreshing schemes address this but add complexity and overhead.