MS Office encryption: keep making the old mistake

In one of the last articles I considered in details the process of the encryption evolution in different MS Office versions and concluded that it became better and better with every next version. However, as it is often happens in a updating of a software version, the new problems can appear unexpectadly, proving that the best is the enemy of the good.Lets consider the generalized process of password verification in MS Office, that has been invented in early MS Office versions and essentially had not been changed till now.

MS Office encryption

MS Office encryption

  • Step 1. The password and random salt are hashed one or multiple times, resulting in a bit string.
  • Step 2. The first several bit from this string are used for the key generation (from 40 up to 256 bit in different versions).
  • Step 3. One more random 128-bit string (Verifier) is encrypted using this key and the result (EncryptedVerifier) is stored in the Office file.
  • Step 4. The same Verifier is hashed once.
  • Step 5. The hash value is encrypted on the key obtained in step 2 and stored in the file as EncryptedVerifierHash.

Then, on developer’s intention, to verify the password it was necessary to generate the key, decrypt EncryptedVerifier, obtaining the initial Verifier, hash and encrypt it according to the steps 4, 5 and compare the result with EncryptedVerifierHash. When the MD5 was the hashing algorithm and RC4 was the encryption algorithm in Office XP, everything was running quite so. However in Office 2007 developers replaced MD5 with SHA1, and RC4 with AES.

It would seem everything became better: SHA1 is obviously more secure than MD5, and AES is the modern encryption standard. But,

  1. MD5 generates 128-bit hash, and SHA1 – 160-bit one. AES, however, uses blocks with 128 bits long.
  2. RC4 is the stream cipher, but AES is the block one.

The first led to the result that on step 5 VerifierHash has ceased to be a multiple of the AES block length, that is why it had to use two 128-bit blocks for its encryption. Without pausing to thing, extra 96 bits was filled with zeros. And that destroyed the whole estimated scheme of password verification. Indeed, now step 5 can be run in reverse order by decryption of EncryptedVerifierHash, and if the resulted last 96 bits are zeros, so the password is correct! There is no more necessity to take steps 3 and 4!

If the RC4 had remained as the encryption algorithm, so this trick wouldn’t have succeeded, as the internal key state was changing in it at each RC4 encryption round, and that is why we would have needed to make the encryption on the 3rd step in any case. But the replacement of RC4 with AES solved this problem.

Of course, that is not a severe vulnerability, and it doesn’t influence on password recovery speed because its main complexity is the Step 2, where 50.000 (Office 2007) or 10.000 (Office 2010) SHA1 transformations are executed. Interestingly that in Office 2010 the developers offered some new improvements, but ignored the described problem. It is amusing that the similar problem was in the old version of MS Office 97, when MS Word password verification could be speeded up using the same trick (it was not necessary to execute some steps suggested by Microsoft). That is why the password recovery of Word 97 occurs faster then Excel 97.

No Comments

No comments yet.

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.

WordPress Themes