Share via

3.2.4.3 R_KeyExchangePhase2 (Opnum 27)

  • Article

The client MUST call R_KeyExchangePhase2 after successful processing of R_KeyExchangePhase1 to complete the security session negotiation.

The client MUST perform the following steps:

  • Generate and store the client's session key.

  • Encrypt the client's session key with the server's key exchange public key.

  • Build an IIS_CRYPTO_BLOB structure with the BlobSignature field set to SESSION_KEY_BLOB_SIGNATURE to store the encrypted client's session key.

  • Compute the hash of the following three entities in this order:

    • The client's session key.

    • The server's session key.

    • The text value of HASH_TEXT_STRING_1, as specified in section 2.2.3.

  • Build an IIS_CRYPTO_BLOB structure with the BlobSignature field set to SESSION_BLOB_SIGNATURE to store the hash computed in the previous step.

  • Send IIS_CRYPTO_BLOBs built in the previous steps to the server.

  • Wait for the response from the server.

  • Retrieve the server's Hash IIS_CRYPTO_BLOB with the BlobSignature field set to HASH_BLOB_SIGNATURE sent by the server.

  • Build the hash for validation purposes.

  • Compute the hash of the client's session key.

  • Compute the hash of the text HASH_TEXT_STRING_2, as specified in section 2.2.3.

  • Compare hashes from the previous two steps. If they match, the server owns the server's key exchange private key and was able to decrypt the client's session key.

    If a hash validation fails, the receiver MUST reject the data and the method that is processing the encrypted data MUST fail. Error messages resulting from a hash validation failure are implementation-dependent.

  • Secure session negotiation is now complete. The client and server can now use secure session to encrypt/decrypt data of a sensitive nature marked by the METADATA_SECURE secure flag with calls to the R_GetData, R_EnumData, R_GetAllData, and R_SetData methods.