7.3.7. Signing Signature Values

7.3.7. Signing Signature Values

When applying the req parameter (Section 2.4) or multiple signatures (Section 4.3) to a message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value. While it would seem that this practice would transitively cover the components under the original signature in a verifiable fashion, the attacks described in [JACKSON2019] can be used to impersonate a signature output value on an unrelated message.

In this example, Alice intends to send a signed request to Bob, and Bob wants to provide a signed response to Alice that includes a cryptographic proof that Bob is responding to Alice's incoming message. Mallory wants to intercept this traffic and replace Alice's message with her own, without Alice being aware that the interception has taken place.

1. Alice creates a message Req_A and applies a signature Sig_A using her private key Key_A_Sign.

2. Alice believes she is sending Req_A to Bob.

3. Mallory intercepts Req_A and reads the value Sig_A from this message.

4. Mallory generates a different message Req_M to send to Bob instead.

5. Mallory crafts a signing key Key_M_Sign such that she can create a valid signature Sig_M over her request Req_M using this key, but the byte value of Sig_M exactly equals that of Sig_A.

6. Mallory sends Req_M with Sig_M to Bob.

7. Bob validates Sig_M against Mallory's verification key Key_M_Verify. At no time does Bob think that he's responding to Alice.

8. Bob responds with response message Res_B to Req_M and creates signature Sig_B over this message using his key Key_B_Sign. Bob includes the value of Sig_M under Sig_B's covered components but does not include anything else from the request message.

9. Mallory receives the response Res_B from Bob, including the signature Sig_B value. Mallory replays this response to Alice.

10. Alice reads Res_B from Mallory and verifies Sig_B using Bob's verification key Key_B_Verify. Alice includes the bytes of her original signature Sig_A in the signature base, and the signature verifies.

11. Alice is led to believe that Bob has responded to her message and believes she has cryptographic proof of this happening, but in fact Bob responded to Mallory's malicious request and Alice is none the wiser.

To mitigate this, Bob can sign more portions of the request message than just the Signature field, in order to more fully differentiate Alice's message from Mallory's. Applications using this feature, particularly for non-repudiation purposes, can stipulate that any components required in the original signature also be covered separately in the second signature. For signed messages, requiring coverage of the corresponding Signature-Input field of the first signature ensures that unique items such as nonces and timestamps are also covered sufficiently by the second signature.