How secure is clipper againt MITM?

[X Ryl]

Hi,

I wonder how clipper solve the issue of transmitting both algorithm
and data to the client browser as a secure operation ?

I mean, let's say
Alice want to speak to Server
Jack, an evil guy, intercept all communication between Alice and
Server.

How do you prevent Jack from intercepting Alice first packet to
Server, then making the connection between himself and the Server.
Whatever the Server answer, Jack send a same "look" webpage to Alice,
but with AJAX based keylogger to himself.
Whatever Alice inputs, Jack gets it almost simultaneously, and can
sent it to Server.
As soon as Alice has input her whole password, Jack can decrypt the
initial page, thus could send any action written in the initial
script, so Alice will never see she was hijacked.

This issue happens because Jack can temper the algorithm used to
decrypt the page. Unless there is a method to sign the script and to
make the browser check it before actually run anything, I can't
understand how secure the method is.

The only solution I could see to solve this issue is using a third
party to send the script, but still this is very dependent on the
trust you give to the third party.

[Giulio Cesare Solaroli]

Hello,

strictly speaking, using SSL for all communications between the
browser and the server fix all MITM class of problems.

But the tampering of the code is a real problem, and we consider it
the most serious thread to the security of "zero-knowledge web
applications".

At the moment we do not have a definitive answer, as a final solution
needs some support from the browser vendors themselves, and we do not
have the strength to push it on our own.

But we are taking some steps in order to alleviate this problem:
- http://groups.google.com/group/clipperz/browse_thread/thread/22c7cff41adf9b3a
- http://groups.google.com/group/clipperz/browse_thread/thread/345fede042104438
- http://www.clipperz.com/reviewing_the_code/checksums
- http://www.clipperz.com/learn_more/crypto_foundations (look at the comments)
- http://www.clipperz.com/users/marco/blog/2007/08/24/anatomy_zero_knowledge_web_application
(section 2: Hide nothing)

None of these are very user friendly, but at least the serve the
purpose of drawing some line to start understanding the exact
specification of the problem that needs to be tackled.

I hope this helps answering your concerns.

Best regards,

Giulio Cesare

[X Ryl]

Well,

  If you have SSL, I guess Clipperz's authentication is not so useful.

On Mon, Aug 4, 2008 at 9:03 AM, Giulio Cesare Solaroli <giulio...@gmail.com> wrote:

Hello,

strictly speaking, using SSL for all communications between the
browser and the server fix all MITM class of problems.

But the tampering of the code is a real problem, and we consider it
the most serious thread to the security of "zero-knowledge web
applications".

At the moment we do not have a definitive answer, as a final solution
needs some support from the browser vendors themselves, and we do not
have the strength to push it on our own.

I've been looking into this issue for a while now, and I might have a beginning of a secure answer.

First "solution", use Flash and ActionScript.

Flash player from version 9.115 provides SHA256 hashing directing in the player, meaning that the hashing method can't be forged (the hashed result, provided you really call the hashing method, will be good).
Better, the Flash player will only download a SWF file if the hash match

This means that if you can get an initial file that wasn't modified by an evil hacker, the next files will automatically be secured.
The initial file could be served on a shared webserver with SSL, or send in a PGP email, so it can't be modified. (SSL server will not have to handle authentication)

Second "solution", with only current javascript implementation and standard browser:

This one is a bit more technic, so please ask if I'm not clear enough:
1. The server serves a static HTML containing:
     a. A basic form and a page layout the user is expected to see
     b. Uncyphered JS code (containing hashing and decryption/encryption code like AES/RSA)
     c. Cyphered JS code (containing cyphered primitives) with the expected user key (there might be an issue here, see *1)
2. If there isn't any man in the middle (MITM), the client get the page as-is
     a. In the form, (s)he enters her/his username, and then her/his passphrase
     b. The username + passphrase is hashed and is used to uncypher the AES/RSA'ed JS code
     c. The JS code is executed, and a new input text box is displayed with an image on the left.
     d. In this text box, the user enter whatever text (s)he wants, the only important thing is the rythmn of the input that is monitored by the JS script (like 3 tap pause 2 tap pause etc...). The code here is the rythmn, not the data. The rythmn entered depends on the image of step c.
     e. Every tap, an small image is displayed with an increasing logic (like A then B then C, or 3, then 4, then 5), as expected by the user. Every authentication try send another image sequence, the only thing the user knows is that the displayed information must increase logically.
     f. The rythmn is then cyphered with other information (username + passphrase) and send back to the server for authentication

The image on step c. and step e. are semantically linked (for example, if the image in c is a book, then step e picture will be letters, and so on...)

3. If there is a MITM (let's call him Joe), he can:
    a. Refuse to send the JS code at all, and instead send an Ajax based keylogger. On his server, however, he will have to execute the real JS code based on user input, in order to be invisible from the authentication server.
        In that case, the previous sequence will execute correctly up to step d.
        Because Ajax requires sending data, and the script will then display a picture for this tap, the Ajax code must
        1) send the intercepted key
        2) receive the image (which should be big enough)

        This means that the timing information between each tap will be destroyed (as long as the image downloading takes longer than the duration between each tap).
        The final rythmn on Joe's server will be garbage, so the authentication will fail on the real server => disclosed data: username + passphrase
        Please note that the initial image sequence being randomized and cyphered into the cyphered JS code, Joe couldn't guess the image sequence, hence can't pre-send it.

    b. Send the both initial JS code, but with additional code to add his keylogger
        In that case, the initial JS code can detect the bad hash for the page, or if Joe is clever and modified the hash code to accept the forged JS code, the sequence will execute correctly up to step c.
        When the cyphered JS code is decoded (it can be decoded only if the username + passphrase is correct), and evaluated, the AJAX code is nullified (by simply overwriting the XMLHTTPRequest function, it's really simple). Joe can't get the other data. => disclosed data: username + passphrase


   c. Send the initial uncyphered JS code, with its keylogger, but not the cyphered JS code
       In that case, same remark as above, we will think Joe is clever and modified the hashing code to accept his modified file.
       When the username and the passphrase is entered, Joe's server will decrypt the cyphered JS code.
       His server will then have to sent back the DOM manipulation the JS code is doing while filtering the Ajax nullifier code (which could be multiple time redundant).
       Let's say his server is very very good (after all, a human will be lost here as if the answer is not "almost" instantaneous, the user will notice that the input text box is not displayed, and abort the authentication), and could filter the code and send it back to the user.
       Then the user will still enter his/her tap sequence, each tap being send to the Joe's server => bad rythmn (see first case)
       Or, the server send the JS code for the tap sequence (but the server must be really, really clever for separate the chaff from the seeds, and removing the Ajax nullifier code from this JS code). This code is big (as it contains all the pictures for the sequence), so the downloading will take a bit of time => the user will notice that either the picture or the input text box isn't displayed instantaneously => (s)he will abort the sequence (let's say the sequence is 16 pictures of 125kb each, the download will take 2 second for a 10Mbits/s link).
       If the tapped sequence is used as a cyphering key for the picture, then the server can't pre-send the pictures => abort due to bad rythmn.
       => disclosed data: username + passphrase 

   d. Joe knows the login process (after all, he can be legitimate user too), and prepare a predetermined picture sequence
       In that case, Joe could send a JS code that act almost like the authentication server code, but with keylogger and time monitorer.
       (The JS will record the keys the user typed, send them by Ajax to his server, and when the username + pass phrase match and can uncypher the code, the JS code will display the input text box and the predetermined picture). Joe will get a rythmn, but sadly a bad one.
       This will fails for the rythmn as the picture on the left of the text box will not match the one expected by the authentication server. The image being generated randomly, and on-the-fly by the server, Joe can't deduce the expected rythmn => disclosed data: username + passphrase
       Joe could try to decrypt the picture from the cyphered JS code, and send it by Ajax to the user, but then he will have to also decrypt all the sequence pictures, as they are linked with the initial picture, => bad rythmn (see case above)

So to conclude, this authentication scheme could work because:
   1) It is based on a physical information that can't be modified => Ajax can only be detected by the time it takes to send & receive the data.
      In the information sent between each tap is big enough (125kb for 1sec transit time, if the server uploads at 1Mbit/s), then the user or the script will see it.
   2) It's a three step authentication, with the last step being choosen by the server, so can't be modified by an attacker.
   3) It's fun for the user to tap a rythmn as a passcode, the rythmn being the really "lock", so it doesn't look too hacky for a casual user.
   4) The implementation on Joe server is very very hard to get right, and the server could decide to obfuscate the JS code to make Joe's life harder
   5) Doesn't need SSL, nor any third party to transfer trust with.
   6) The internet bandwidth for the user or Joe's server is not huge (less than 10Mbits/s). This is exactly the same kind of limitations than CPU processing power for the key length. We will need to increase the transfered image size which bigger bandwidth existence.

This implementation doesn't work if:
   1) The browser on which the user runs is compromised (with an external keylogger for example), but hey, even SSL couldn't solve this issue too.
   2) Joe server doesn't even try to intercept the authentication, but, later on intercept the cookie (so the cookie on the server must include many information to prevent this)

Let me know if you see any hole in this algorithm.
Cheers,
Cyril
 

[Giulio Cesare Solaroli]

Hello Cyril,

On Tue, Aug 5, 2008 at 9:45 AM, X Ryl <boite.p...@gmail.com> wrote:
> Well,
>
> If you have SSL, I guess Clipperz's authentication is not so useful.

Mhhh. SSL does not provide any option to identify which user is trying
to access the Clipperz data; it "simply" protect the communication
channel between the Clipperz's server and the user's browser.

The authentication protocol allows us to identify who is trying to
access the data and verify that he owns the right credentials to do
so.

Anyway ... see my comments below.

> On Mon, Aug 4, 2008 at 9:03 AM, Giulio Cesare Solaroli
> <giulio...@gmail.com> wrote:
>>
>> Hello,
>>
>> strictly speaking, using SSL for all communications between the
>> browser and the server fix all MITM class of problems.
>>
>> But the tampering of the code is a real problem, and we consider it
>> the most serious thread to the security of "zero-knowledge web
>> applications".
>>
>> At the moment we do not have a definitive answer, as a final solution
>> needs some support from the browser vendors themselves, and we do not
>> have the strength to push it on our own.
>
> I've been looking into this issue for a while now, and I might have a
> beginning of a secure answer.
>
> First "solution", use Flash and ActionScript.
>

> [...]

>
> This means that if you can get an initial file that wasn't modified by an
> evil hacker, the next files will automatically be secured.

The whole Clipperz application is served as a single include all file
(HTML + JS + CSS + images are all included in the index.html file); so
if we can solve the "initial file" problem, we are already done.

> The initial file could be served on a shared webserver with SSL, or send in
> a PGP email, so it can't be modified. (SSL server will not have to handle
> authentication)

Given how browser security works, if you want to access the Clipperz
application with Javascript, you need to serve it from Clipperz
servers. So your suggestions do not provide much benefit, as far as I
can see.

> Second "solution", with only current javascript implementation and standard
> browser:
>
> This one is a bit more technic, so please ask if I'm not clear enough:

[Disclaimer: I have read your suggestion not very carefully, so feel
free to correct me if I got something wrong]

> 1. The server serves a static HTML containing:
> a. A basic form and a page layout the user is expected to see
> b. Uncyphered JS code (containing hashing and decryption/encryption
> code like AES/RSA)
> c. Cyphered JS code (containing cyphered primitives) with the expected
> user key (there might be an issue here, see *1)

> [...]

However you want to pack your data/algorithm etc... if you are going
to serve some crypto algorithm via web, you immediately fall back to
the first point where you need to verify that the algorithms are
legitimate and have not been compromised.

Anything that relies upon the outcome of an untrusted algorithm is
basically not trustable.

> Let me know if you see any hole in this algorithm.

If you believe that your suggestion is immune from this observation, I
will try to dig deeper into the details, because I have obviously
missed something.

Best regards,

Giulio Cesare

[X Ryl]

On Tue, Aug 5, 2008 at 11:44 AM, Giulio Cesare Solaroli <giulio...@gmail.com> wrote:

Hello Cyril,

On Tue, Aug 5, 2008 at 9:45 AM, X Ryl <boite.p...@gmail.com> wrote:
> Well,
>
>   If you have SSL, I guess Clipperz's authentication is not so useful.

Mhhh. SSL does not provide any option to identify which user is trying
to access the Clipperz data; it "simply" protect the communication
channel between the Clipperz's server and the user's browser.

The authentication protocol allows us to identify who is trying to
access the data and verify that he owns the right credentials to do
so.

Anyway ... see my comments below.

I meant that if you have SSL, you shouldn't need to worry about JS corruption, and SSL warranty data integrity and encryption.
This also means that HTTPS server-based authentication (without JS) is perfect in that case, Clipperz is useless for the authentication
(As a user, I prefer to authenticate on HTTPS based gmail server, than HTTP/HTML+JS based Clipperz).

> On Mon, Aug 4, 2008 at 9:03 AM, Giulio Cesare Solaroli
> <giulio...@gmail.com> wrote:
>>
>> Hello,
>>
>> strictly speaking, using SSL for all communications between the
>> browser and the server fix all MITM class of problems.
>>
>> But the tampering of the code is a real problem, and we consider it
>> the most serious thread to the security of "zero-knowledge web
>> applications".
>>
>> At the moment we do not have a definitive answer, as a final solution
>> needs some support from the browser vendors themselves, and we do not
>> have the strength to push it on our own.
>
> I've been looking into this issue for a while now, and I might have a
> beginning of a secure answer.
>
> First "solution", use Flash and ActionScript.
>

> [...]

>
> This means that if you can get an initial file that wasn't modified by an
> evil hacker, the next files will automatically be secured.

The whole Clipperz application is served as a single include all file
(HTML + JS + CSS + images are all included in the index.html file); so
if we can solve the "initial file" problem, we are already done.

What I meant, is download the first file by a secure meaning (HTTPS/sSL), no authentication needed, we just need to ensure data integrity.
Then save the first file on your hard drive (it's done automaticcally by the browser in the Flash cache)

Then, you never need to download it again, and you NEVER need SSL nor HTTPS for the authentication phase, as you can warranty (thanks to the hash algorithm in the flash file)
the integrity of the authentication flash based application.
It's a little bit like the browser extension example you've shown in the links below, but cross-broswer, cross-platform (as long as Flash is supported).
And like for the browser extension, where you must ensure the extension wasn't hacked, you have to make sure the initial Flash file isn't modified.

> The initial file could be served on a shared webserver with SSL, or send in
> a PGP email, so it can't be modified. (SSL server will not have to handle
> authentication)

Given how browser security works, if you want to access the Clipperz
application with Javascript, you need to serve it from Clipperz
servers. So your suggestions do not provide much benefit, as far as I
can see.

You didn't get the point,ssee above.

> Second "solution", with only current javascript implementation and standard
> browser:
>
> This one is a bit more technic, so please ask if I'm not clear enough:

[Disclaimer: I have read your suggestion not very carefully, so feel
free to correct me if I got something wrong]

> 1. The server serves a static HTML containing:
>      a. A basic form and a page layout the user is expected to see
>      b. Uncyphered JS code (containing hashing and decryption/encryption
> code like AES/RSA)
>      c. Cyphered JS code (containing cyphered primitives) with the expected
> user key (there might be an issue here, see *1)

> [...]

However you want to pack your data/algorithm etc... if you are going
to serve some crypto algorithm via web, you immediately fall back to
the first point where you need to verify that the algorithms are
legitimate and have not been compromised.

Anything that relies upon the outcome of an untrusted algorithm is
basically not trustable.

This is hopefully wrong. Do you know the egnima with the 2 guards and 2 doors where one of them is telling lies ? It's the same case as the byzantine problem.

The algorithm I'm describing here gives physical clues when it's not working as expected (it was modified), and those evidences are displayed to the user so (s)he can stop the authentication process.
Whatever the output of the algorithm (a part of the algorithm is on the user logic, this couldn't be hacked I hope, and another part is on a physical process measurement, that couldn't be hacked either), either the authentication proceed entirely, either it fails without the user being able to continue the authentication meaning hack-in-process.

What I've done, is making sure that it fails only when there is a modification in the expected logic.
Please try to read the process carefully, I explain why, if the crypto algorithm are modified the authentication will fail later on.

I know that a hash verification in the browser would be the real solution to this problem, but, we don't have it now, and it's unlikely to be added later on (at least not in HTTP/1.2 or part of HTML5).

> Let me know if you see any hole in this algorithm.

If you believe that your suggestion is immune from this observation, I
will try to dig deeper into the details, because I have obviously
missed something.

I provide a fallback for MITM, to abort the authentication. However, the session stuff still need cyphering stuff I haven't solved.

Best regards,

Giulio Cesare

[Giulio Cesare Solaroli]

Hello Cyril,

I will take a closer look at this whole tread to understand better
your suggestions, as there is still something I am definitely missing.

Thank your very much for the attention.

Best regards,

Giulio Cesare

[X Ryl]

Hi all,

   Well, after some discussion with Giulio, and a lot of personal brainstorming (and trying to write a proof of concept), the algorithm I've explained before wasn't so easy for the user.
If you look closely to the case 3.d, you'll see that it's user responsibility to accept / deny the proposed pictures. Say differently, it's user role to decypher the message.

Mathematically, I've moved the "cyphering" algorithm I couldn't secure enough in JS to the user. And, sadly, the user are not that good at computing.

So, I've come to another idea, and this time, I hope I'm close to perfect secrecy.
Here the (updated) algorithm:
  * Like before, the first page contains:

1. A username text input
2. A password text input, but character by character, with some character replaced by "stars" (not required) 
1. For example, let's say the password is "password", then the password text input could be "..**..*.", meaning you only have to type "pawod"
2. "Star" position are randomly choosen by the server, so no same password is either send twice.
   
3. A submit button
4. Some cyphered JS with a key derived from (username & partial password & salt) (BTW, the number of user must be limited)
5. The decryption code in JS.
6. (Optional) A timer saying time left before this authentication expires (likely 1mn)
   

  When the user enter his/her credentials, the cyphered JS is decyphered, and the cyphered code is executed.
This code add the following inputs:

1. A picture box (containing a picture from the list of picture the user has choosen in the registration step) chosen randomly by server
   
2. A text input
3. Another picture containing a text "warped", à la captcha (some very difficult to read for a computer, but easy for a human) chosen randomly by server
   

The picture (1.) tell the user what rythmn (s)he has to produce, and the other picture (3.) tell which key to start sequence with.
Then the user type his sequence with the right rythmn (doesn't need to be too complex).
Every time the user enter a new character, the picture (3.) changes, realtime, to the next char to be typed.
If it doesn't change quickly, the user must abort the authentication (probably hack in progress).

Concerning the security concern: (compared to previous algorithm)

1. Replay attack is very difficult as the password changes every time the page is requested (if the password is 8 character long and 3 characters are "star", then the probability to get the same sequence is 1/56 and the server could limit the authentication tries period to increasing periods of time)
2. MITM by keylogging is very difficult
1. If done since the beginning, then the user will notice that the text input & pictures don't appears instantaneously (as the keylogguer will have to send the user & partial password, decypher the JS code, and send the resulting "big" picture back to the user, and this takes times) => (s)he will abort
2. If "foreseen" / precomputed (not decyphering take place, a precomputed step 2 is displayed), then the picture (1.) will unlikely match what the user chose (probabilities are 3/64 if the user chose 3 pictures out of a set of 64) => abort
3. Even if the picture match the user's choice, the written sequence start (picture 3.) will not match the one from the server (probability (1/64)^(rythmn length) for standard keyboard), so the MITM won't get the right characters. This means that the MITM must:
1. Be a human to understand the captcha of the initial picture 3. sent by the server
   
2. Type the understood character in order to get the next picture in the sequence
3. And so on until the sequence expires (BTW, the sequence length is not the rythmn length, so the MITM will probably enter more/less character than expected).
   
4. However, the rythmn will be bad, as the MITM doesn't know the rythmn beforehand.
5. He can't get it from the hijacked user because the chosen sequence will not match the one of the server (the user will type the rythmn of the given sequence, which is not likely the one chosen by the server)
6. The MITM couldn't try to bruteforce the algorithm as the authentication is time monitored, and is rejected on the server if the duration is too high.
   
4. If the MITM can't inject his keylogguer/rythmn monitored in the JS cyphered code, as the key changes every time because the partial password changes.
   

 
Ok, concerning the setup of this algorithm, during registration (I consider registration taking place with SSL or another channel (GSM) to avoid MITM here) the user need to enter:

1. His(her) name
2. His(her) password (min 8 characters)
3. Choose 3 pictures out of a set of 64 (or more)
4. The server creates, let's say 3 random sequence (like "kghjuouhkj", "io qsa dr", " 45 op 54 op"). The sequence char can be mnemonic like "tooyu ta".
   
5. For each sequence the user is asked to type a rythmn (s)he wants, at least 3 times (to compute mean and deviation). The rythmn doesn't need to fit the sequence length (if not enough characters, the user can type whatever (s)he wants for the rythmn ending, and if too much characters in the sequence, well, no problem, it is ignored)
    

As you can see, this algorithm is "secure" with a probability of (1/56 (stars in password) * 3/64 (key picture) * (3/64)^(rythmn length) (chars in the sequence) = 8.6E-8) for a rythmn of only 3 taps (which is unlikely to be so short).
It's not so bad, provided that the server will refuse too many authentication per minute.

Regards,
Cyril

PS: The flash based solution (see previous email) will only work if Adobe create an authentication component (as Adobe components are digested and signed by private Adobe's key and are stored in Flash player cache (not browser cache), hence are never downloaded twice, see RSL). I've added a feature request on Adobe site for such component. Let's see how it goes.