Why is validating the integrity of the plaintext necessary in addition to validating the integrity of the cipher text?

Question

Reading the iOS Security Guide's description of the iMessage encryption protocol I'm trying to figure out why they included a mechanism for verifying the integrity of the plaintext as well as verifying the integrity of the final cipher text (emphasis added).

For each receiving device, the sending device generates a random 88-bit value and uses it as an HMAC-SHA256 key to construct a 40-bit value derived from the sender and receiver public key and the plaintext. The concatenation of the 88-bit and 40-bit values makes a 128-bit key, which encrypts the message with it using AES in CTR mode. The 40-bit value is used by the receiver side to verify the integrity of the decrypted plaintext. This per-message AES key is encrypted using RSA-OAEP to the public key of the receiving device. The combination of the encrypted message text and the encrypted message key is then hashed with SHA-1, and the hash is signed with ECDSA using the sending device’s private signing key.

What does this additional signature component add to the authenticity of the message?

Answer 1

What does this additional signature component add to the authenticity of the message?

Actually I think you got it reverse here. The ECDSA signature was there first. It turned out it wasn't sufficient. This is (part of) the content of the paper "Dancing on the Lip of the Volcano" (PDF).

The idea is that an attacker like Apple can just strip the signature and replace it with a "trusted one" (as they provide the public key directory service) where they actually control the signing key. After the authentication was defeated this way the paper describes a way to send malicious ciphertexts to the recipient to slowly learn the message.

The "fix" you see here, is that they've now part of the AES-CTR key depends on the public keys of the sender and recipient. Of course these are different when the attacker strips the signature and generates a new one and then the recipient should notice the integrity check failing.

Also note that the actually sane way to fix this issue would have been to use sign-then-encrypt with authenticated encryption rather than signing AES-CTR ciphertext...

Though one has to admit, that this "fix" somewhat solves the problem assuming they really couldn't change any of the previous message format given that this simply a bit of (undetectable) structure into the previously fully-random AES key.