Cryptographic enforcement schemes using Diffie-Hellman

Question

If one wants to set up a decentralized cryptographic enforcement scheme in which the level of 'confidentiality' of information is marked by its position in a poset, why not use Diffie-Hellman to derive the key of a node from its immediate parents?

This is as opposed to the tree-based scheme described in this paper.

In more detail:

You have a poset $X$ from which you want to build a CES. You have a public one-way function $f$. The poset has a top element $r$ and a randomly generated key $k(r)$. Here is how you derive $k(x)$ for all $x \in X$: Let $u \in X$. We can assume one of only two possibilities (we can easily generalize to more than these):

• $u$ has one parent $x$. Then $k(u) = f(k(x))$.
• $u$ has two parents $x_1$ and $x_2$. Then choose a random DDH-hard cyclic group $G$ and a generator $g \in G$ and publish $(G, g, g^{k(x_1)}, g^{k(x_2)})$. $k(u) = g^{k(x_1)k(x_2)}$.

[edit]

When sending a message, a chain can be used to communicate its position in the poset. Let's say that if a node $u$ has one parent, its 'name' will be denoted $u$ (which will be random). Let's say if it has 2 parents, its name will be the $(G, g, g^{k(x_1)}, g^{k(x_2)})$. Then you publish the chain.

Answer 1

1) The meaning of a poset is that there may also be members $x,y \in X$, where neither $x \leqslant y$ nor $x \geqslant y$. Now consider such incomparable $x$ and $y$ with $parent(x)=parent(y)=w \in X$ and furthermore $u \in X, y=parent(u), x \nleqslant u, x \ngeqslant u$

Now $k(x)=f(k(w))=k(y)$. Then also $k(u)=f(f(k(w))=f(k(x))$, even though $x$ is not a predecessor of $u$. This is clearly a security violation in almost any information-flow control policy.

2) you would need an additional hash function to return the result of the DH exponentiation back to the key-domain.

3) It is not a good idea to change identities while changing keys

4) You will need information on the DAG structure to define the actual function used, which is considered inefficient in HKAS

5) In general, it is not a good idea to have node keys computed from parent keys, instead other secret values are used, to enable efficient key-updates

6) It is more efficient in change management and initial deployment to have anything depend only on one predecessor rather on multiple ones. Remember, the nodes are security levels, not users or computers.