2

I have a TLS Record containing HTTPs application data.

I extracted the encrypted plain text with mac from the application data, then, when I decrypted the extracted data using AES CBC mode, I am expecting that It will return something like this:

POST /ImeiTracki
ng?msg=010908391
1841060249765020
A984108000001540
F7F9D00DFBF00001
7000160005100000
0000800060200020
7022502080300010
30A0E07918184026
284F8FFFFFFFFFFF
0000000000083083
A758909259672050
B00 HTTP/1.1..HO
ST: h..X-Admin-P
rotocol: globalp
latform-remote-a
dmin/1.0..
....

but instead, it returned:

³Y%þ&É?eĺìr8%
ng?msg=010908391
1841060249765020
A984108000001540
F7F9D00DFBF00001
7000160005100000
0000800060200020
7022502080300010
30A0E07918184026
284F8FFFFFFFFFFF
0000000000083083
A758909259672050
B00 HTTP/1.1..HO
ST: h..X-Admin-P
rotocol: globalp
latform-remote-a
dmin/1.0..
....

The only weird thing here is the first line (³Y%þ&É?eĺìr8%), it should be POST /ImeiTracki. The lines after the first line are all okay.

My input to the aes decryptor:

  1. encrypted text = encrypted text + mac
  2. key
  3. iv

I also tried other https messages from the same session and same result was observed - the first line is unreadable and the latter is okay.

I also tried to use an online aes decryptor and still- same result was observed.

I would like to have a result just like my expectation.

Any ideas on why is the first line unreadable?

  • 1
    Since only the first block is garbage, I would say the IV is wrong. – Stefano Sanfilippo Feb 26 '15 at 12:21
3

In CBC mode the IV is applied after the decryption algorithm with the key is applied to the ciphertext. Which means that if your key is correct, but your IV is wrong then the first block will come out garbled. The rest of the decryption will happen correctly since the each IV afterwards is the previous ciphertext (hence the name Cipher Block Chaining).

Here's a picture of the CBC decryption operation from the Wiki page:

enter image description here

Somehow you are incorrectly calculating the IV.

  • 1
    In particular for TLSv1.0 (and SSLv3) the IV for each record is the last block of the previous record, except the first record (which the OP's POST request likely is) uses an initial IV derived from the master secret during the handshake, along with the encryption and HMAC keys. For TLSv1.1 and 1.2 each record has an explicit random IV. This was to fix the Moeller attack that later evolved into BEAST. – dave_thompson_085 Feb 26 '15 at 19:49
  • @raz The IV key I used was derived from the master key with this formula:link The prf I used was from bouncy castle.for the case above, the record I used contains the first application data from client. So, I used the derived client_write_iv. I am referencing another tool that successfully decypts an https message in TLS PSK. The 6 keys I produced were same with tool's.I thought it was okay.if my iv is wrong, where could i have gone wrong? for the case above, the version is TLS 1.0 – piero Feb 27 '15 at 6:34
  • @piero Without seeing the code it's hard to say what's going wrong. But the IV is either calculated incorrectly, or the value you're using isn't what you think. For example, maybe you copied one less byte than you thought. – RoraΖ Feb 27 '15 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.