[cifs-protocol] [EXTERNAL] [MS-OAPXBC] Incorrect session key instructions

[Sreekanth Nadendla]

William, David

Are you decrypting with the machine key (device transport key) ? Also have you been able to separate header, encryptedkey, iv, payload and authentication Tag from the response ? I want to see what was sent in these fields and ensure that the parsing scheme is valid.

If the Algorithm is dir instead of RSA-OAEP, is your implementation working ?


Regards,

Sreekanth Nadendla

Microsoft Windows Open Specifications


________________________________
From: William Brown <wbrown at suse.de>
Sent: Wednesday, January 24, 2024 7:45 PM
To: David Mulder <dmulder at samba.org>
Cc: Sreekanth Nadendla <srenaden at microsoft.com>; Interoperability Documentation Help <dochelp at microsoft.com>
Subject: Re: [EXTERNAL] [cifs-protocol] [MS-OAPXBC] Incorrect session key instructions

[You don't often get email from wbrown at suse.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

> On 25 Jan 2024, at 08:07, David Mulder <dmulder at samba.org> wrote:
>
>
> On 1/24/24 2:34 PM, Sreekanth Nadendla wrote:
>> Hello David, William,
>> You are correct i.e. the individual fields are sent after base64 encoding in the response.
>>
>> So, the following data needs to be Base64URL decoded first in order to decrypt
>>        1) iv, payload, tag ( used when decrypting using dir algorithm. )
>>
>>              2) encrypted Key parsed out from response (when decrypting using RSA-OAEP algorithm, device transport key, account info is used to decrypt)
>>
>> Have you been able to parse the response header and verify which algorithm is used ? "Direct use of a shared symmetric key as CEK" vs "RSAES using OAEP".
>>  It's value will be either  RSA-OAEP or dir in the header.
> Here's an example:
> Header:
> {"enc":"A256GCM","alg":"RSA-OAEP"}
> CEK field:
> EGzWVAJryfCZcHTBuh2GlgpsSJ07_uJYJzxHugaMcs0fRqPCuyJbmnPUF4RAIA52NuxIIvUX2IQZbkip81SbSyDQdZc9qrMTBGBij4X3vTq_lRX6AVu9qY_S8CmOp1Uj0fwwuJ0JZBB9gyaIVz55aSmh0EpJLD6sZaWoCQ_yW4zi2Zkh76Ejj6oXdg4N4EcuT_BE_BYa-k4C6rzEZOC56tFhLeajJiaQZjkS9sDFFCqD954yakiK6OITMQWCgrxWnouXBzIgXIeeLHfoBpV2FKjLgUW9j_W_PSj02awvzPxCCgxCoMttuH0gSg_nIBslqsRUOtV7Z6-R4PRQCvu7bBBMCatoGEDCIcSDOsxGXi4qWebJDDV8lwRJDnX6fj0XlWiaSw37
>
> Which if we decode with base64url, it's 294 bytes long (which can't be decrypted because it is too long).
> Here's a whole session_key_jwe we're getting back from MS:
> eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAifQ.EGzWVAJryfCZcHTBuh2GlgpsSJ07_uJYJzxHugaMcs0fRqPCuyJbmnPUF4RAIA52NuxIIvUX2IQZbkip81SbSyDQdZc9qrMTBGBij4X3vTq_lRX6AVu9qY_S8CmOp1Uj0fwwuJ0JZBB9gyaIVz55aSmh0EpJLD6sZaWoCQ_yW4zi2Zkh76Ejj6oXdg4N4EcuT_BE_BYa-k4C6rzEZOC56tFhLeajJiaQZjkS9sDFFCqD954yakiK6OITMQWCgrxWnouXBzIgXIeeLHfoBpV2FKjLgUW9j_W_PSj02awvzPxCCgxCoMttuH0gSg_nIBslqsRUOtV7Z6-R4PRQCvu7bBBMCatoGEDCIcSDOsxGXi4qWebJDDV8lwRJDnX6fj0XlWiaSw37.fGFa6aVfmf83em7B.EA.O8wTp91cEL3-bACPGhi3iA
>
> I'm consistently getting this sort of response, with a garbled CEK.
>
> I tried putting this JWE through Powershell, and attempted decrypting the CEK with `System.Security.Cryptography.RSAOAEPKeyExchangeDeformatter`. This fails with:
> MethodInvocationException: /home/dmulder/.local/share/powershell/Modules/AADInternals/0.9.2/PRT_Utils.ps1:754
> Line |
>  754 |  …             $CEK    = [System.Security.Cryptography.RSAOAEPKeyExchang …
>      | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      | Exception calling "DecryptKeyExchange" with "1" argument(s): "The length of the data to decrypt is not valid
>      | for the size of this key."
>

It is worth pointing out that this data being 294 bytes in length may indicate a buffer over-read or similar data leak. While it may not be a valid CEK, you may internally need to raise this with your security teams.

Generally there shouldn't be a case where you are yielding any extra data than the 256 bytes of signed CEK.


--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20240125/91359d08/attachment.htm>