Re: [TLS] User Defined Key Pair

["OMAR HASSAN (RIT Student)" <[e-mail]>]

Hi Uri,

May be I am still not able to clear my point regarding the man in the
middle attack.

When the user provides the credential information, he will not provide it
to the Facebook log in page, instead he will go to the menu bar in his
browser, and run the new plugin which has two tabs: one for log in; and the
other for enrollment, and in the plugin interface the user will provide his
credential information.

The key pair will be generated inside the browser's plugin, and only the
signed message, and the username will go to Facebook, no passwords will
leave the user's browser. When the server receive the username and the
signed message, it will send the session key encrypted with the user's
public key.

If  someone pretended to be Facebook, he will receive a public key and a
signed message. The attacker cannot use this information to log into
Facebook, because the signed message contains the current server's time
stamp, so it's valid only for a few seconds.

And even if the attacker sends the signed message and the username to the
server, and the server accepted them, the next step is that the server will
respond with the session key encrypted with the user's public key. How the
attacker will read the public key if he doesn't have the private key, the
private key that didn't leave the user's browser.


On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student)
<[e-mail]>wrote:

> Hi All
>
> >Stephan:
>
> >How you made sure that the user (client) is connected with the intended
> server?
> >Paras Shah:
>
> >That is exactly the question I had. How is Server Authentication done
> with this approach?
> >Rich:
>
> >I don’t see anything in your system that prevents this, either.  It seems
> that replacing your system with self-signed client >certificates would be
> equivalent.
>
> >Robert:
> >As the proposal has no server authentication, it is surely broken in that
> respect i.e. the client could be lured to any bogus >website masquerading
> as a legitimate one. How would the client know?
>
> I would explain How is Server Authentication done with a practical
> example. Let's name facebook as our website that we need to protect using
> that new protocol.
>
> When I go to facebook, I would receive a browser message telling me:
> "Please use the UDKP protected access (Tools->UDKP Protected Access)!"
> the user will go to the plugin interface, and provide the username,
> password, password confirmation, the plugin will create a file with random
> data stream in the user's usb, and then the user will click on the register
> button.
>
> At that point the plugin will create the key pair based on the random
> file, username, and password. The public key will go to the server with the
> username and a signed message, and the user will be redirected to the
> facebook registration page to complete his registration.
>
> Now the user profile is created on facebook and associated with the user
> public key.
>
> When the user tries to sign in later into facebook, and if he was deceived
> to sign in into a fake website, the user will go to the browser plugin
> interface, and provide the username, password, and select the file from his
> usb. At that point the user will be expecting to see his facebook timeline
> if he is really signing into the real facebook. Note that the user didn't
> provide the credential information to the website but to the browser plugin
> (Tools->UDKP Protected Access).
>
> In our case, the fake website will only receive the username, the public
> key, and the token (ServerHello.random ) signed with user private key, If
> the attacker delivered this message to the facebook server, the server will
> try to read and validate the token using the user public key. If it
> succeeds, it will respond with the session key premaster encrypted by the
> user public key. Because the user private key did not leave the browser,
> the attacker will not be able to read the session key and hence will not be
> able to monitor the traffic.
>
> So if the user was successfully able to see his timeline, he would be sure
> that he is communicating with the real facebook.
>
> >Robert:
> >Token = enc(ServerHello.random, PrivKey) : The concept of encrypting
> using a private key seems pointless. Don't you mean >signing?
>
> Yes Robert, I mean signing not encrypting. Actually someone told me before
> about that mistake in the previous version, but unfortunately I forgot to
> correct it in the new version. Hopefully in the next version it will be
> corrected. Thank You.
>
> >Juho Vähä-Herttua:
>
> >The whole security of the system seems to be dependant on the security of
> the "browser plugin" and its key generation and encryption algorithms
>
> I preferred to make the generation of the key pair as a black box, so we
> can focus our discussion on the idea itself, so the question is if we have
> a key generation function that can generate key pair securely based on the
> username, password, and the file selected, would the idea be a good one.
>
> >What if someone detects this enrollment and sends a new public key for
> the user before the user has time to fill all the fields? Sounds like a
> race condition to me.
>
> The key pair generation is done inside the browser plugin interface, not
> in the website page, so there is no race condition, the communication with
> the website will start after the creation of the key pair.
>
>
> >I don't see how this is different from generating a self signed client
> cert and verifying it with for example HMAC with username+password+question
> derived secret. If you already need a custom >browser
> >plugin to handle the login, you can put all your custom logic there and
> use standard TLS for the rest.
>
> You can look at the generated key pair as a client certificate, but I
> preferred to make it as a key pair, so this key pair could be generated
> based on different approaches: security question, file, smart card,
> hardware token.
>
> Additionally it's not only about custom sign in, it's also about
> eliminating the dependence on the CA, so the session key must be encrypted
> with the user public key not encrypted with a key that claims to be the
> server public key.
>
> >Rich:
>
> >It’s great that you are trying to improve things; don’t get discouraged,
> but this ain’t there yet.  And as a first step to replacing all of
> SSL/TLS?  Nope.
>
> I am not discouraged at all, but I am still insisting that the security of
> my traffic to facebook must be the responsibility of me and facebook only,
> and not anyone else. And I am doing my best to achieve that. The discussion
> is very useful to me, may be after this discussion we can come out with a
> new final solution to this issue.
>
>
> On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <[e-mail]> wrote:
>
>> **Ø  **Self signed certificate is very dangerous because the user will
>> not have a way to verify the identity of the certificate owner and he could
>> be a victim to a man in the middle attack.****
>>
>> ** **
>>
>> I don’t see anything in your system that prevents this, either.  It seems
>> that replacing your system with self-signed client certificates would be
>> equivalent.****
>>
>> ** **
>>
>> It’s great that you are trying to improve things; don’t get discouraged,
>> but this ain’t there yet.  And as a first step to replacing all of
>> SSL/TLS?  Nope.****
>>
>> ** **
>>
>>                 /r$****
>>
>> ** **
>>
>> --  ****
>>
>> Principal Security Engineer****
>>
>> Akamai Technology****
>>
>> Cambridge, MA****
>>
>> ** **
>>
>
>