Brands' private credentials

[Adam Back]

On Mon, May 10, 2004 at 02:42:04AM +0000, Jason Holt wrote:
> > However can't one achieve the same thing with encryption: eg an SSL
> > connection and conventional authentication?  
> 
> How would you use SSL to prove fulfillment without revealing how?
> You could get the CA to issue you a "patient or doctor" SSL cert,

Well SSL was just to convince you that you were talking to the right
server ("you have reached the AIDs db server").

After that I was presuming you use a signature to convince the server
that you are authorised.  Your comment however was that this would
necessarily leak to the server whether you were a doctor or an AIDs
patient.

However from what I understood from your paper so does your scheme,
from section 5.1:

P = (P1 or P2) is encoded HC_E(R,p) = {HC_E(R,P1),HC_E(R,P2)} 

With Hidden Credentials, the messages are in the other direction: the
server would send something encrypted for your pseudonym with P1 =
AIDs patient, and P2 = Doctor attributes.  However the server could
mark the encrypted values by encoding different challenge response
values in each of them, right?

(Think you would need something like Bert Jaap-Koops Binding
cryptography where you can verify externally to encryption that the
contained encrypted value is the same to prevent that; or some other
proof that they are the same.)


Another approach to hiding membership is one of the techniques
proposed for non-transferable signatures, where you use construct:

RSA-sig_A(x),RSA-sig_B(y) and verification is x xor y = hash(message).

Where the sender is proving he is one of A and B without revealing
which one.  (One of the values is an existential forgery, where you
choose a z value first, raise it to the power e, and claim z is a
signature on x= z^e mod n; then you use private key for B (or A) to
compute the real signature on the xor of that and the hash of the
message).  You can extend it to moer than two potential signers if
desired.

> > Outside of this, the usual approach to this is to authenticate the
> > server first, then authenticate the client so the client's privacy is
> > preserved.
> 
> If you can trust the server to do so.  Firstly, hidden credentials limit what
> the server learns, so you don't *have* to trust the server as much.  But
> secondly, they also solve the problem which shifts to the server when it goes
> first: 

OK so the fact that the server is the AIDs db server is itself secret.
Probably better example is dissident's server or something where there
is some incentive to keep the identity of the server secret.  So you
want bi-directional anonymity.  It's true that the usual protocols can
not provide both at once; SSL provides neither, the anonymous IP v2
protocol I designed at ZKS had client anonymity (don't reveal
pseudonym until authenticate server, and yet want to authenticate
channel with pseudonym).  This type of bi-directional anonymity pretty
much is going to need something like the attribute based encryption
model you're using.

However it would be nice/interesting if one could do that end-2-end
secure without needing to trust a CA server.

> My system lets folks:
> 
> * access resources without the server even knowing whether they fulfill the
> policy

this one is a feature auth based systems aren't likely to be able to
fullfil, you can say this because the server doesn't know if you're
able to decrypt or not

> So it's definitely in the realm of other privacy systems.  We could
> define a new term just to exclude my system from the others, but at
> this point I don't think naming confusion is any worse for my
> system; they all have lots of different nonorthogonal features.  

I think it would be fair to call it anonymity system, just that the
trust model includes a trusted server.  There are lots of things
possible with a trusted server, even with symmetric crypto (KDCs).

Adam