Brands' private credentials

[Jason Holt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Mon, 10 May 2004, Adam Back wrote:
> 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?

Yep, that'd be a problem in that case.  In the most recent (unpublished)  
paper, I addressed that by using R as the key for a ciphertext+MAC on the
actual message.  So the server would have to find two R's that both satisfy
the MAC but produce different ciphertexts in order to learn anything from the
response.

In either case, though, you can't just trust that the server encrypted against
"patient OR doctor" unless you have both creds and can verify that they each
recover the secret.  They might be lying about the "doctor" part, and really
sending against "patient OR nonexistant", in which case your response reveals
that you're a patient.  That's why we recommend that your response (if any)
include the policy for the creds you used in decryption.  So if Alice is
responding to a message she decrypted with her "patient" cred, which she only
(implicitly) discloses to Medicare, and the response itself is only for AIDS
clinics, she should encrypt against "Medicare AND AIDS_clinic".

(And you're right, the AIDS example is not very compelling.  The slides give a
better one about FBI agents, but I'm still looking for other examples of
super-sensitive transactions where HCs would fit)


> 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

That's very slick.  I'll check it out.

> 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.

Hugo Krawczyk gave a great talk at Crypto about the going-first problem in
IPSec, which is where I got the phrase.  He has a nice compromise in letting
the user pick who goes first, but for some situations I think hidden
credentials really would hit the spot.


> 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).

Yeah, although I think most of them would require an on-line trusted server.  
But that just makes all sorts of things way too easy to be interesting. :)

						-J
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAn9/HnwLgjivV2NERAkBUAJwLhH7lZBtd/boI6Edn3JWA+eStDQCdEFZi
GI4rzGoiscp0Ze/+iKweu08=
=eX/X
-----END PGP SIGNATURE-----