Enabling Oblivious Access Control via Function Encryption

Question

Abstract

With Functional Encryption, would access control between two parties be possible without revealing the entirety of one party's policy to the other? E.g. such that a server would be incapable of discerning anything more about a client's policy (aside from weather the client's requested action is permissible via single Boolean output), and vice versa for the client when checking that the server is first allowed to receive the action request before transmitting it.

Problem Statement

A distributed set on nodes (subjects) within a computation graph communicate peer-to-peer (P2P), exchanging messages, services, etc (objects) via an common API. Subjects exchange identities to authenticate each other with some common source of trust, e.g. a Certificate Authority (CA), thereafter establishing a forward secured channel, e.g. via Transport Layer Security (TLS). Through this channel, the two participants should conduct a form of trust negotiation with respect to validating the other participant is authorized to receive or request a given object respectively.

Ideally, in the interest of preventing any information about the computation graph from being leaked, one may wish that policy definitions be obfuscated from the public. For a large dynamic P2P systems, it is perhaps best participants store only their own provisioned policy, as opposed to all policies for whom they are expected to interact with. To be fully decentralized as well, no connection to a third party broker at run time for access arbitration should be used.

Given these requirements, middle ware standards such as DDS Security from OMG fallow a familiar pattern above where participants exchange signed permission documents that prescribe the policy to enforce upon the owner. In essence, a participant's entire hand of cards is revealed to all recipients. To introspect the topology of the inner data bus and its resources, a malicious actor needs only to annex a single identity in order to connect and aggregate policy documents.

I was thinking this relates to Oblivious Transfer (OT), but instead where the verifier gets exactly one policy decision result without without knowing anything about the rest of the policy that was not pertinent to the inquiry.

Related

• What are the current limitations (and capabilities) of Functional Encryption used for access control?
• What paradigm does ABE, KP-ABE and CP-ABE fall into
• Certificate based Access Control for Pub Sub messaging

Side Note & Motivation

I'd like to create a Mandatory Access Control (MAC) plug in for robotic and Industrial IoT (IIoT) middle wares. I've written one before that leverages regular expressions in clear text extensions within a subject's identity certificate. OMG's DDS Security default plugin does this better by decoupling identity and permission documents for handshaking. However, I think we could do even better than its v1.0 plugin by not sharing entire participant policies. Of course one could just provision the permission document into multiple minimalistic documents for each use niche use case, but my thoughts were that perhaps functional encryption could help avoid such quantized bookkeeping.

Answer 1

Potential Solution?

Using Functional encryption, a trusted authority with a master secret key ($msk$) and public key ($pk$) would generate a "functional decryption" key ($sk$) from a participant's policy ($k$). Each participants would be provided the $pk$ and relative $sk$, where $sk$ is bound to the participant's public identity via a signed document.

For a client and server session between two participants, the client would first use $pk$ to encrypt its own intended API request ($x$) to generate the ciphertext ($c$). After securely connecting and receiving the server signed document, the client would verify the server's ownership of $sk$. Next the client would check the server is authorized to receive the API by using the server's $sk$ to calculate a policy function of the request $c$ encrypts. If the function returns True, then the server is authorized to receive the API request, otherwise False is returned. If True, the client then transmits $x$ and its own $sk$ document for the server to verify similarly, checking the client is authorized to send the API request before fulfillment.

Extension?

To prevent recipients of a participant's $sk$ from probing what additional API permissions where provisioned within, e.g. by brute force enumeration of API requests, perhaps either the encryption or decryption algorithms could altered require a third argument ($sk'$). While also generated from $k$, $sk'$ is instead kept secret to the owner, while additionally remaining a non-substitutable argument for (public) $sk$ and vice versa. The result being that a return of True could only occur if the policies in $sk$ and $sk'$ coincide such that the permissions for the intended client and server for the API request $x$ are all permissible, otherwise False is returned.

This would prevent a malicious actor from gaining any more knowledge about the permissions of other participant's, aside from what could already be inferred from authorized exchanges using the identity and $sk'$ from the participant it has already compromised. Perhaps a another approach could necessitate some sub key or token from the other participant that would authorize the policy "background" check upon the received $sk$ for only the permission relevant for the API in question. However this would require the client to divulge the API request to the server to receive such a token before even vetting the server, itself a circumvention of access control that would perhaps negate the advanage.

In lieu of three argument function encryption algorithms unfeasible, perhaps a similar effect could be achieved by necessitating a cascaded calculating of function upon $c$ and then $c'$ using $sk$ and $sk'$ once in either of the two stages? E.g.

$$ (pk,msk) \leftarrow Setup(1^{\lambda}) \\ sk \leftarrow Keygen(msk, k) \\ {sk}' \leftarrow Keygen(msk, {k}') \\ c \leftarrow Enc(pk,x) \\ {c}' \leftarrow Dec({sk}',c) \\ F(({k}',k),x) \leftarrow Dec({sk}',{c}') $$