-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CASESession] Factoring Out Sigma2 and Sigma3 Parsing Functions for Improved Testability #36941
base: master
Are you sure you want to change the base?
[CASESession] Factoring Out Sigma2 and Sigma3 Parsing Functions for Improved Testability #36941
Conversation
…sionParameters as an outparam and does not touch PairingSession class member mRemoteSessionParameters - a utility SetRemoteSessionParameters to be able to set PairingSession class member mRemoteSessionParameters
9351204
to
403d4ee
Compare
PR #36941: Size comparison from 2249628 to 403d4ee Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #36941: Size comparison from 2249628 to ea053d8 Increases above 0.2%:
Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
ea053d8
to
cc77e8c
Compare
PR #36941: Size comparison from 2249628 to cc77e8c Increases above 0.2%:
Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
df9a3e8
to
5c9281b
Compare
0fe56e3
to
1a6f27b
Compare
PR #36941: Size comparison from d5e9829 to 1a6f27b Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
1a6f27b
to
c4dfb95
Compare
|
||
if (data.keystore != nullptr) | ||
{ | ||
SuccessOrExit(err = helper->ScheduleWork()); | ||
ReturnErrorOnFailure(helper->ScheduleWork()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is async and will swithc context. It is certain that there is nothing here that will be out of scope later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not change the scope of any of the decoded elements, so it should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that assumes it was fine before... Do we run the unit tests with asan?
|
||
SuccessOrExit(err = ConstructTBSData(data.initiatorNOC, data.initiatorICAC, ByteSpan(mRemotePubKey, mRemotePubKey.Length()), | ||
ByteSpan(mEphemeralKey->Pubkey(), mEphemeralKey->Pubkey().Length()), | ||
data.msg_R3_Signed.Get(), data.msg_r3_signed_len)); | ||
data.msgR3Signed.Get(), data.msgR3SignedLen)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we passed a mutable span instead to the ConstructTBSData, then it may be clearer that it's a max length in msgR3SignedLen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean I should modify ConstructTBSData
to take a MutableByteSpan instead of a Pointer + length? that would require more changes in the other parts of the code, it might be better to do it as a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can do a follow-up.
@@ -2018,6 +2006,71 @@ CHIP_ERROR CASESession::HandleSigma3a(System::PacketBufferHandle && msg) | |||
return err; | |||
} | |||
|
|||
CHIP_ERROR CASESession::ParseSigma3(ContiguousBufferTLVReader & tlvReader, | |||
Platform::ScopedMemoryBufferWithSize<uint8_t> & msgR3Encrypted) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest passing a MutableByteSpan. The fact that we are mutating the payload to decrypt in place was never really stated, but it's actually what's happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it looks like even the alloc is done by this method on the provided msgR3Encrypted. Suggest calling it outMsgR3Encrypted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added comments to the method in the header file, as well as during instantiation of parameters passed to it
I made it like:
CHIP_ERROR CASESession::ParseSigma3(ContiguousBufferTLVReader & tlvReader,
Platform::ScopedMemoryBufferWithSize<uint8_t> & outMsgR3Encrypted,
MutableByteSpan & outMsgR3EncryptedPayload, ByteSpan & outMsgR3Mic)
4c0fd48
to
a68f2c0
Compare
PR #36941: Size comparison from 8a0fc4d to a68f2c0 Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
a68f2c0
to
386d4b9
Compare
386d4b9
to
f7b8166
Compare
PR #36941: Size comparison from 958c1cb to f7b8166 Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #36941: Size comparison from 17ad72e to 1f9cd96 Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
MutableByteSpan msgR2EncryptedPayload; | ||
ByteSpan msgR2Mic; | ||
SessionParameters responderSessionParams; | ||
uint16_t responderSessionId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spec calls this responderSessionID. Why the random casing difference? This applies to some other bits too (resumptionId here and in EncodeSigma2ResumeInputs, responderSessionId in EncodeSigma2ResumeInputs, resumptionId and responderSessionId in ParsedSigma2Resume).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, there seems to be dispute on how should we treat abbreviations with camelCase, treat them like a word or keep them all Capital?
} | ||
// Msg2 should only be added to MessageDigest after we construct SaltSigma2 that is used to derive S2K |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? We're not using SaltSigma2 here.... why does this ordering requirement exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because to construct SaltSigma2, we use the MessageDigest/TranscriptHash that only includes Msg1 and doesn't include Msg2 (this happens within CASESession::ConstructSaltSigma2
)
sr2k.KeyHandle(), kTBEData2_Nonce, kTBEDataNonceLength, msg_R2_Encrypted.Get())); | ||
if (parsedSigma2.responderSessionParamStructPresent) | ||
{ | ||
SetRemoteSessionParameters(parsedSigma2.responderSessionParams); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This used to be after successful decrypt, no? Why the ordering change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, is it an issue if we do it before a sucessful decrypt? there seems to be nothing in spec about it?
I wanted to group all the outer sigma-2-struct parts together
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will move this after signature validation, as it was done before
SuccessOrExit(err = decryptedDataTlvReader.Get(responderICAC)); | ||
SuccessOrExit(err = decryptedDataTlvReader.Next(TLV::kTLVType_ByteString, AsTlvContextTag(TBEDataTags::kSignature))); | ||
} | ||
std::copy(parsedSigma2TBEData.resumptionId.begin(), parsedSigma2TBEData.resumptionId.end(), mNewResumptionId.begin()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This used to be after signature validation, right? Why the ordering change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wanted to group the parts related to Sigma2TBEData together.
- Looking at the spec, this is done after signature validation, I will move it there.
- I will also move
SetPeerSessionId(responderSessionId);
to after signature validation, as it is like that in the spec (but wasn't the case in the code)
PR #36941: Size comparison from 17ad72e to 291a38f Increases above 0.2%:
Full report (71 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Overview:
This PR continues the CASESession refactoring efforts to improve testability and robustness, building on:
Key Changes:
1. Refactoring:
2. Hardening and Fixes:
TBSData2Signature
andTBSData3Signature
.EndOfContainer
TLV elements by ensuringExitContainer
is called after TLV-Reading containers TLV Reading of Containers often missed a call to ExitContainer #36959.Testing