Support SECBUFFER_READONLY_WITH_CHECKSUM in EncryptMessage and DecryptMessage

[jborean93]

In order to support RPC message encryption and signing, the EncryptMessage and DecryptMessage needs to support security buffers marked as SECBUFFER_READONLY_WITH_CHECKSUM. This flag indicates the bytes in that buffer are not part of the encrypted payload but are included in the header signature. For example here is what the SSPI calls look like by the RPC client there:

EncryptMessage(Context: 0x1E752D17F28, Qop: 0, Message: 0xC8EED8D878, SeqNo: 2)
        EncryptMessage Message(Version: 0, Buffers: 5)
                [0] Type: SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM (1), Length: 24, Data: 05000003100000004C014C0008000000D800000001000000
                [1] Type: SECBUFFER_DATA (1), Length: 224, Data: 6C000000000000006C000000000000000100048054000000600000000000000014000000020040000200000000002400030000000105000000000005150000001D9377F744357ACC8CD37BA9000200000000140002000000010100000000000100000000010100000000000512000000010100000000000512000000000000000000020000000000A84FC6BA90E87C91109083E7B0F859966901000010000000020000008AE3137102F4367102402800605978B94F52DF118B6D83DCDED720850100000033057171BABE37498319B5DBEF9CCC36010000000000000000000000
                [2] Type: SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM (1), Length: 8, Data: 0906080000000000
                [3] Type: SECBUFFER_TOKEN (2), Length: 76, Data: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
                [4] Type: SECBUFFER_PKG_PARAMS | SECBUFFER_READONLY (3), Length: 12, Data: 020000000000000000EBBFE8
EncryptMessage -> Res: 0x00000000
        EncryptMessage Message(Version: 0, Buffers: 5)
                [0] Type: SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM (1), Length: 24, Data: 05000003100000004C014C0008000000D800000001000000
                [1] Type: SECBUFFER_DATA (1), Length: 224, Data: E4280885A4D936180CAC4CEDDB5A8701CA0B44F46B6C1E900B1498D2A8037EEE93E43B383E99673484257C1BD430886FF39E40C111022177512539344790F582258B014BC93854C74E4B3CD23784DD48AC676D2C292D149654813B5E3B8BFB3FB6B527B1E5F2557A81226F0BCDF42E2E12C9D7ED190873B7F778F1CD590ABBEFB2A634C7921709A6EECBBD51EE71054D4003C8CD3270E21705E357EAC968C377DDD9BEC0055F9D0B9F3FDEC9FAEE5D672BF14AAC1483DD4291B8D46F1FABB03A66BDA17D0DFD9ABB17C582C1145B0B977552A9E264B64368597B6268FC9ED452
                [2] Type: SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM (1), Length: 8, Data: 0906080000000000
                [3] Type: SECBUFFER_TOKEN (2), Length: 76, Data: 050406FF0010001C000000006252ACAC5AC3E1A12D7A4AD7B214598D7251A6B4E7606469D7750EF2BD2FD0141780BAB5FAF227C592E6BCE338D184B4E198AC012B970ADE18632DF0A9D01228
                [4] Type: SECBUFFER_PKG_PARAMS | SECBUFFER_READONLY (3), Length: 12, Data: 020000000000000000EBBFE8

It uses 5 buffers

• [0] - SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM
  • Contains the RPC PDU header bytes which are integrity protected by the resulting signature
• [1] - SECBUFFER_DATA
  • Contains the RPC PDU body which are encrypted
• [2] - SECBUFFER_DATA | SECBUFFER_READONLY_WITH_CHECKSUM
  • Contains the RPC PDU security trailer bytes which are integrity protected by the resulting signature
• [3] - SECBUFFER_TOKEN
  • Buffer containing the resulting signature
• [4] - SECBUFFER_PKG_PARAMS | SECBUFFER_READONLY
  • Unsure but certainly not needed/included in the resulting header token

The corresponding DecryptMessage uses the same buffers and the input data for the buffers flagged with SECBUFFER_READONLY_WITH_CHECKSUM are used when verifying the input signature.

[jborean93]

When testing this a bit further it seems like support for just SECBUFFER_READONLY might also be missing. This would be required if using DCE encryption without signed header as well. The same SSPI buffers are used but instead of SECBUFFER_READONLY_WITH_CHECKSUM they are SECBUFFER_READONLY.