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