Add key change implementation

[masomel]

This requires merging @marisbest2's code in the internal CONIKS repo to this repo.

[marisbest2]

Do I need to do anything for this?

[masomel]

I don't think so. You said your merge-mrochlin branch is ready for merging into master, right?

[marisbest2]

I think so.

Michael Rochlin

On Wed, Mar 16, 2016 at 9:09 PM, Marcela [email protected] wrote:

I don't think so. You said your merge-mrochlin branch is ready for merging
into master, right?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

[masomel]

@marisbest2 Could you please clarify: Why does your implementation change the change key after each ULN change? If I'm reading it correctly, the change key change is never itself authenticated (even in the signed key change case). I couldn't find an explanation in your report.

[marisbest2]

I think that you're referring to KeyChange.java. Assuming that's the case,
the function signature is just confusing. The DSAPublicKey passed as
changeKey is the new change key. The old change key was stored in the ULN.
The entire message, which should include the part that sets the new change
key, is verified on line 78.

If that's not what you're referring to, let me know.

Michael Rochlin

On Thu, May 19, 2016 at 1:43 PM, Marcela Melara [email protected]
wrote:

@marisbest2 https://github.com/marisbest2 Could you please clarify: Why
does your implementation change the change key after each ULN change? If
I'm reading it correctly, the change key change is never itself
authenticated (even in the signed key change case). I couldn't find an
explanation in your report.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

[masomel]

I did see that, though that isn't what I was referring to (I suppose it's related). I was referring to your code in the test client, specifically why you generate a new key pair for the change key every time you change the blob or the key change policy. This new change key pair is never authenticated, so even if the user doesn't allow unsigned key/ULN changes, the server can still insert a spurious blob by replacing the public change key in the ULN.

[marisbest2]

Updating the changekey by the client every time was just a proof of concept
that seemed natural. I think it should prevent replay attacks in which an
adversary could copy a message and signature, and if the user didn't update
the change key that could be replayed?

If the user requires only signed key changes, then I think the server would
have to post a change of key message using the previous key. The changekey
is included in the ULN record that is part of the merkle tree and so if the
server modifies the ULN's changeKey, the hash should change and the proof
should fail. A change of key should be no different than a change of Blob
in this regard.

I may be overlooking something, but I think that's right.

Michael Rochlin

On Thu, May 19, 2016 at 3:18 PM, Marcela Melara [email protected]
wrote:

I did see that, though that isn't what I was referring to (I suppose it's
related). I was referring to your code in the test client, specifically why
you generate a new key pair for the change key every time you change the
blob or the key change policy. This new change key pair is never
authenticated, so even if the user doesn't allow unsigned key/ULN changes,
the server can still insert a spurious blob by replacing the public change
key in the ULN.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

[masomel]

I see. I'm not sure what a malicious server could gain from replaying an old key-change-message+signature, but I might be missing something there.

I think you're right, if a user requires signed key changes and if the server tries to update the user's blob using a different previous change key, the signature verification on the change of key message should fail. But I'm concerned with the fact that not signing the new change key opens a window for a malicious server to equivocate about the change key, which then allows it to insert spurious blobs in the future. So for example, if the Alice's change key was ck1, her new blob is blob2 and the new change key is ck2, the malicious server can equivocate presenting ck2' + sign_ck1(blob2) to Bob, and then subsequently send Bob ck3 + sign_ck2'(blob3). Whereas, if Alice's client includes the change key: ck2 + sign_ck1(blob2+ck2), Bob's client can immediately reject ck2' + sign_ck1(blob2+ck2) because the change keys don't match and ck2' wasn't authorized by Alice's client.

It's true that Bob's client will eventually detect the equivocation even if the new change key isn't signed by Alice's client since the change key is included in the ULN. So maybe not signing the new change key doesn't make things worse since we already allow unsigned blob changes? But I do think that signing the new change key protects users who require signed key changes from such an equivocation attack.

[marisbest2]

I agree on the replay attack, and I think we had discussed it and said
"better safe than sorry"

As for the signature, i think the entire message, including the new change
key, is signed using change key. So the client should already do what you
say it should do. (I think). The message is the bytearray of the protobuf
message as sent/received minus the signature.

On Tuesday, May 24, 2016, Marcela Melara [email protected] wrote:

I see. I'm not sure what a malicious server could gain from replaying an
old key-change-message+signature, but I might be missing something there.

I think you're right, if a user requires signed key changes and if the
server tries to update the user's blob using a different previous change
key, the signature verification on the change of key message should fail.
But I'm concerned with the fact that not signing the new change key opens a
window for a malicious server to equivocate about the change key, which
then allows it to insert spurious blobs in the future. So for example, if
the Alice's change key was ck1, her new blob is blob2 and the new change
key is ck2, the malicious server can equivocate presenting ck2' +
sign_ck1(blob2) to Bob, and then subsequently send Bob ck3 +
sign_ck2'(blob3). Whereas, if Alice's client includes the change key: ck2 +
sign_ck1(blob2+ck2), Bob's client can immediately reject ck2' +
sign_ck1(blob2+ck2) because the change keys don't match and ck2' wasn't
authorized by Alice's client.

It's true that Bob's client will eventually detect the equivocation even
if the new change key isn't signed by Alice's client since the change key
is included in the ULN. So maybe not signing the new change key doesn't
make things worse since we already allow unsigned blob changes? But I do
think that signing the new change key protects users who require signed key
changes from such an equivocation attack.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

Michael Rochlin

[marisbest2]

Or at least it should be. If it's not then that's a bug, not a design
oversight.

On Tuesday, May 24, 2016, Michael Rochlin [email protected] wrote:

I agree on the replay attack, and I think we had discussed it and said
"better safe than sorry"

As for the signature, i think the entire message, including the new change
key, is signed using change key. So the client should already do what you
say it should do. (I think). The message is the bytearray of the protobuf
message as sent/received minus the signature.

On Tuesday, May 24, 2016, Marcela Melara <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

I see. I'm not sure what a malicious server could gain from replaying an
old key-change-message+signature, but I might be missing something there.

I think you're right, if a user requires signed key changes and if the
server tries to update the user's blob using a different previous change
key, the signature verification on the change of key message should fail.
But I'm concerned with the fact that not signing the new change key opens a
window for a malicious server to equivocate about the change key, which
then allows it to insert spurious blobs in the future. So for example, if
the Alice's change key was ck1, her new blob is blob2 and the new change
key is ck2, the malicious server can equivocate presenting ck2' +
sign_ck1(blob2) to Bob, and then subsequently send Bob ck3 +
sign_ck2'(blob3). Whereas, if Alice's client includes the change key: ck2 +
sign_ck1(blob2+ck2), Bob's client can immediately reject ck2' +
sign_ck1(blob2+ck2) because the change keys don't match and ck2' wasn't
authorized by Alice's client.

It's true that Bob's client will eventually detect the equivocation even
if the new change key isn't signed by Alice's client since the change key
is included in the ULN. So maybe not signing the new change key doesn't
make things worse since we already allow unsigned blob changes? But I do
think that signing the new change key protects users who require signed key
changes from such an equivocation attack.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

Michael Rochlin

Michael Rochlin

[masomel]

You're absolutely right, the client does sign the entire message including the change key. I was confused on what the message it was signing was -- I didn't realize the ULNChangeReq contains the entire ULN contents. Thanks for clarifying, and so sorry for not paying more attention from the start.

[marisbest2]

Its ok. It took me a while to figure that out, and it should probably be
better documented.

Michael Rochlin

On Tue, May 24, 2016 at 10:58 PM, Marcela Melara [email protected]
wrote:

You're absolutely right, the client does sign the entire message. I was
confused on what the message it was signing was -- I didn't realize the
ULNChangeReq contains the entire ULN contents. Thanks for clarifying, and
so sorry for not paying more attention from the start.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#2 (comment)

[masomel]

Started with #7 and finished with #23.