blinding & BF IBE CA assisted credential system (Re: chaum's patent expiry?)
On Mon, May 10, 2004 at 03:03:56AM +0000, Jason Holt wrote:
[...] Actually, now that you mention Chaum, I'll have to look into blind signatures with the B&F IBE (issuing is just a scalar*point multiply on a curve).
I think you mean so that the CA/IBE server even though he learns pseudonyms private key, does not learn the linkage between true name and pseudonym. (At any time during a show protocol whether the private key issuing protocol is blinded or not the IBE server can compute the pseudonyms private key). Seems like an incremental improvement yes.
That could be a way to get CA anonymity for hidden credentials - just do vanilla cut and choose on blinded pseudonymous credential strings, then use a client/server protocol with perfect forward secrecy so he can't listen in.
Note PFS does not make end-2-end secure against an adversary who can compute the correspondents private keys, as vulnerable to MITM. Could say invulnerable to passive eavesdropper. However you might have an opening here for a new security model combining features of Hidden Credentials with a kind of MITM resistance via anonymity. What I mean is HC allows 2 parties to communicate, and they know who they are communicating with. The CA colluding MITM however we'll say does not apriori, so he has to brute force try all psuedonym, attribute combinations until he gets the right one. Well still not desirable security margin, but some extra difficulty for the MITM. Adam
On Mon, 10 May 2004, Adam Back wrote:
On Mon, May 10, 2004 at 03:03:56AM +0000, Jason Holt wrote:
[...] Actually, now that you mention Chaum, I'll have to look into blind signatures with the B&F IBE (issuing is just a scalar*point multiply on a curve).
I think you mean so that the CA/IBE server even though he learns pseudonyms private key, does not learn the linkage between true name and pseudonym. (At any time during a show protocol whether the private key issuing protocol is blinded or not the IBE server can compute the pseudonyms private key).
Well, he can always generate private keys for any pseudonym, just as in cash systems where the bank can always issue bank notes. Here's what I'm suggesting, where "b" is a blinding function and n1... are random nyms: Issuing: Alice FBI TTP b(n1,"agent")----> b(n2,"agent")----> b(n3,"agent")----> <---cut & choose: n1,n3 (n1,"agent")-----> (n3,"agent")-----> <---sig(b(n2,"agent")) (Alice unblinds and now has a credential for nym n2) So it's vanilla Chaum-style blinded credentials. The FBI signs Alice's agent cred without learning the nym. Alice can use the nym, and the server can ask the FBI the attributes (agent? chief? secretary?) of the person with the nym, but the FBI won't know. The FBI could eavesdrop on Alice's connection and generate whatever creds are necessary to read the resource Bob sends her, but that's why I was talking about building it in a protocol with PFS. But now that I think of it, PFS isn't really necessary at all for Alice&Bob to have a conversation where their policies are respected: Alice Bob (Alice generates random nonce na) HC_E(na, "Bob:agent", FBI)---> (Bob generates random nb) <---HC_E(nb, "Alice:member", NRA) Both generate session keys from Hash(na,nb). So, Alice wants to connect iff Bob's FBI, and Bob wants to talk iff Alice is in the NRA, where "Alice" and "Bob" are random pseudonyms. Thus they send their random nonces na and nb encrypted against those creds (HC_E is a hidden cred encrypt), then use those nonces for the session keys. The FBI can *always* impersonate an agent, because, well, they're the CA and they can make up pseudonymous agents all day long. But in this protocol, I believe they wouldn't be able to be a MITM and/or just eavesdrop on Alice&Bob. That's because Bob only wants to talk to NRA members, and the FBI can't impersonate that. Now, this is for an interactive session, rather than just sending a single request/response round like I discuss in the paper. But even then, policies are always respected. Just change "na" to "request" and "nb" to "response". Alice's policy is respected whether she talks to FBI-authorized-Bob or FBI-authorized-FBI, and the FBI doesn't get to read Bob's NRA-Alice-only repsonse. -J
But if I understand that is only half of the picture. The recipient's IBE CA will still be able to decrypt, tho the sender's IBE CA may not as he does not have ability to compute pseudonym private keys for the other IBE CA. If you make it PFS, then that changes to the recipient's IBE CA can get away with active MITM rather than passive eavesdropping. An aside is that PKI for Psuedonym's is an interesting question. The pseudonym can't exactly go and be certified by someone else as an introducer without revealing generally identifying things about the network of trust. But ignoring this presuming that the identities were not subject to MITM from day one, and could build up a kind of WoT despite lack of out-of-band way to check info to base WoT signatures on. It would still be interesting to defend the pseudonym against MITM colluding with IBE CA that at some point after the pseudonym has transferred keys without insertion of a MITM from. This problem of addressing the who goes first problem for pseudonymous communicants appears somewhat related to Public Key Steganography where there is a similar scenario and threat model. (Anderson and Petitcolas"On The Limits of Steganography" http://www.petitcolas.net/fabien/publications/jsac98-limsteg.pdf). They also cite a "Prisoners' problem" which might be something you could extend involving a warden who is eavesdropping and prisoners who will be penalized if he can detect and identify communicants. My earlier comment: | Btw one other positive side-effect of IBE is the server can't | impersonate by issuing another certificate in a pseudonyms name | because there is definitionally only one certificate. may not be that useful a distinction as the IBE CA server also gets your private key, so he doesn't _need_ to generate a certificate impersonating you as a conventional rogue CA would. But if we could make the binding from pseudonym to the pseudonym's non-IBE public key strictly first come first served, so that the IBE CA's attemt to claim his later released non-IBE public key is the correct one would be detectable. Either secure time-stamping, extending the psuedonym name to include fingerprint as self-authenticator would allow this. Adam On Mon, May 10, 2004 at 06:45:56PM +0000, Jason Holt wrote:
Well, he can always generate private keys for any pseudonym, just as in cash systems where the bank can always issue bank notes. Here's what I'm suggesting, where "b" is a blinding function and n1... are random nyms: [...] (Alice generates random nonce na) HC_E(na, "Bob:agent", FBI)--->
(Bob generates random nb) <---HC_E(nb, "Alice:member", NRA)
Both generate session keys from Hash(na,nb).
The FBI can *always* impersonate an agent, because, well, they're the CA and they can make up pseudonymous agents all day long. But in this protocol, I believe they wouldn't be able to be a MITM and/or just eavesdrop on Alice&Bob.
That's because Bob only wants to talk to NRA members, and the FBI can't impersonate that.
Now, this is for an interactive session, rather than just sending a single request/response round like I discuss in the paper. But even then, policies are always respected. Just change "na" to "request" and "nb" to "response". Alice's policy is respected whether she talks to FBI-authorized-Bob or FBI-authorized-FBI, and the FBI doesn't get to read Bob's NRA-Alice-only repsonse.
-J
participants (2)
-
Adam Back -
Jason Holt