A short update of the project status: we have managed to tackle the MITM problem by splitting the MS/keyblock generation process between the auditor and the auditee, as it turns out, the RFC 2246 TLS standard effectively allows the splitting in the definition of the MS generation function:
PRF(secret, label, seed) = P_MD5(S2, label + seed) XOR P_SHA-1(S1, label + seed),
where S1 and S2 are the first and second half of the 48 bytes PMS, respectively.
The basic procedure is a modification from that posted by dansmith:
https://bitcointalk.org/index.php?topic=173220.msg4998488#msg4998488.
1. The auditee connects to the bank's server and starts a TLS handshake.
2. The auditee gives the auditor the bank's public key, client_random and server_random.
3. Both auditee and auditor independently generate 24 bytes of random data, called S1 and S2 respectively per the definition of the RFC2246 standard.
4. Both parties then cooperate to generate the encrypted PMS with the bank's public key, using the homomorphic property of RSA encryption:
RSA(2^(k_p)*P+2^(k_1)*S1+1)*RSA(2^(k_2)*S2+1) mod n=RSA(2^(k_p+k_2)*P*S2 + 2^(k_p)*P+2^(k_1+k_2)*S1*S2+2^(k_1)*S1+2^(k_2)*S2+1),
where P is a factor used in construction of the PKCS RSA padding. As can be seen from the result of the above equation, the cleartext PMS that is to be used by the bank can be splitted clearly into parts which can be generated separately by an auditor/auditee, as long as k_1 > k_2+k_s, where k_s is the number of digits of S2.
5. The auditee calculates P_SHA-1(S1, label+seed), generating 48 bytes - H_1 = H_11||H_12, where H_11 and H_12 are of equal length of 24 bytes.
6. The auditor calculates P_MD5(S2, label+seed), generating 48 bytes - H_2 = H_21||H_22, where H_21 and H_22 are of equal length of 24 bytes.
7. The auditor gives to the auditee H_21.
8. The auditee gives to the auditor H_12.
9. The auditee constructs M_1 = H_21 XOR H_11 (the first half of the master secret).
10. The auditor constructs M_2 = H_12 XOR H_22 (the second half of the master secret).
11. The auditee now calculates X=P_SHA-1(M_1, label+seed).
12. The auditor now calculates Y=P_MD5(M_2, label+seed).
13.The auditor and auditee share those bytes of each of X,Y which allow the other party (using XOR again) to generate the required secret data: for the auditor, the server mac secret, and for the auditee, the client and server encryption keys. During the whole process, neither the auditor nor the aduitee has access to the full PMS/MS/keyblock, which prevents both the MITM attack from being carried out, and the forgery on auditee's part. The finished handshake message can be generated similarly as it uses the same PRF function.
Known problems:
Padding the secret is a bit tricky, as it needs to meet certain specified format, however we are already able to generate valid PMS at a high probability(about 90% of the time).
The entropies of both S1 and S2 are a bit too small, with that of S2 being as small as 10 bytes, however any brute-force attack can only be conducted in real-time as the PMS will not be reused, so even 2^80 possibilities pose a formidable challenge to any known potential attacker.
The above procedure will only work for TLS 1.0/1.1, as the TLS 1.2 changes the PRF to use a single SHA-256 function, yet given the slow pace of IT infrastructure upgrade it would take many years before the TLS 1.0/1.1 are phased out.
Implementation:
All of the modifications are already implemented, live trials have been conducted successfully as well, right now dansmith is working on polishing the NSS patch.
As always, questions are welcomed, especially attacks against the security.
Show Posts
