3.1.5.1 Verifying an Incoming Message
If a client or server requires verification of a signed message, it provides the message length, the buffer containing the message, and the key to verify the signature. The following steps describe how the signature MUST be verified:
The receiver MUST save the 16-byte signature from the Signature field in the SMB2 Header for use in step 5.
The receiver MUST zero out the 16-byte signature field in the SMB2 Header of the incoming message.
If Session.Connection.Dialect belongs to the SMB 3.x dialect family,
If Connection.Dialect is “3.1.1” and Connection.SigningAlgorithmId is not empty, the receiver MUST use Connection.SigningAlgorithmId to compute the signature. Nonce specified in [RFC4543] MUST follow the syntax specified in section 3.1.4.1.
Otherwise, the receiver MUST use AES-128-CMAC to compute the signature. The AES-128-CMAC is specified in [RFC4493].
A 16-byte hash MUST be computed over the entire message, beginning with the SMB2 Header from step 2, and using the key provided.If the message is part of a compounded chain, any padding at the end of the message MUST be used in the hash computation.
If Session.Connection.Dialect is "2.0.2" or "2.1", the receiver MUST compute a 32-byte hash by using HMAC-SHA256 over the entire message, beginning with the SMB2 Header from step 2, and using the key provided. The HMAC-SHA256 is specified in [FIPS180-4] and [RFC2104]. If the message is part of a compounded chain, any padding at the end of the message MUST be used in the hash computation.
If the first 16 bytes (the high-order portion) of the computed signature from step 3 or step 4 matches the saved signature from step 1, the message is signed correctly.
Determining when a client will verify a signature and the action taken on the result of verification is specified in section 3.2.5.1.3. Determining when a server will verify a signature and the action taken on the result of verification is specified in section 3.3.5.2.4.