incorrect processing of paired-key osdp_CCRYPT

[rsgmodelworks]

When initiating a secure channel, osdp.net incorrectly accepts an osdp_CCRYPT response with a bad SCS header (SCBK-D set.)

[bytedreamer]

The osdp_CHLNG sent from OSDP.Net is a SCBK and the PD responds with SCKB-D?

[rsgmodelworks]

That is correct. This specific PD sends the wrong SCS header (the scbk-d version when it's a paired key secure channel) and osdp.net accepts it.

[bytedreamer]

@claude triage this

[github-actions]

Claude finished @bytedreamer's task in 5m 17s —— View job

---

Triaging Issue #193

Task: Analyze the issue about incorrect processing of paired-key osdp_CCRYPT

Checklist

• Read repository guidelines (CLAUDE.md)
• Understand the issue: OSDP.Net accepts osdp_CCRYPT with wrong SCS header
• Locate code handling osdp_CCRYPT responses
• Locate SCS header validation logic
• Review secure channel establishment code
• Understand SCBK vs SCBK-D differences
• Provide triage assessment

---

Triage Assessment

Issue Summary

OSDP.Net incorrectly accepts an osdp_CCRYPT response from a PD that contains the wrong Security Control Block (SCB) type. Specifically, when a paired key (SCBK) secure channel is being established, the PD responds with an SCB indicating SCBK-D (default key) instead, and OSDP.Net does not validate or reject this mismatch.

Technical Details

Background:

• In OSDP secure channel establishment, the third byte of the Security Control Block indicates whether the default key (0x00 for SCBK-D) or a paired/installed key (0x01 for SCBK) is being used
• When the ACU sends osdp_CHLNG with SCBK (0x01), the PD should respond with osdp_CCRYPT also indicating SCBK (0x01)
• If the PD responds with SCBK-D (0x00) when SCBK was requested, this is a protocol violation

Current Behavior:
The ACU code in OSDP.Net currently:

1. Sends osdp_CHLNG with the correct SCB type based on whether it's using the default key (SecurityInitialization.cs:36)
2. Receives osdp_CCRYPT and extracts the IsUsingDefaultKey flag from the incoming message
3. Does NOT validate that the PD's response matches the ACU's original request
4. Proceeds with secure channel establishment even when there's a mismatch

Affected Code Locations:

• src/OSDP.Net/Bus.cs:445-446 - Where ACU processes osdp_CCRYPT and calls InitializeSecureChannel
• src/OSDP.Net/DeviceProxy.cs:167-171 - The InitializeSecureChannel method that extracts payload but doesn't validate SCB
• src/OSDP.Net/Messages/SecureChannel/SecurityContext.cs:186-217 - The InitializeACU method that validates cryptogram but not the SCB type

Missing Validation:
There is no check to ensure that:

// Expected: ACU's IsDefaultKey should match PD's IsUsingDefaultKey from CCRYPT response
if (acu.IsDefaultKey != pdResponse.IsUsingDefaultKey) {
    // Reject the secure channel initialization
}

Severity Assessment

Severity: Medium-High

Impact:

• Security: Protocol compliance violation that could indicate a man-in-the-middle attack or a misconfigured/non-compliant PD
• Interoperability: May cause issues with PDs that incorrectly implement the OSDP specification
• Reliability: Could lead to secure channel establishment with mismatched key assumptions

Risk Factors:

• The issue only manifests with non-compliant PDs
• Could potentially mask configuration errors (PD configured with default key when it should use paired key)
• May allow secure channel establishment to proceed when it should fail

Recommended Fix

Approach:

1. Add validation in DeviceProxy.InitializeSecureChannel() or SecurityContext.InitializeACU() to compare the ACU's key type expectation with the PD's response
2. Throw an exception or return an error when there's a mismatch
3. Log a warning or error message indicating the protocol violation
4. Ensure the secure channel establishment fails and is not completed

Implementation Location:
The validation should be added in src/OSDP.Net/DeviceProxy.cs before calling MessageSecureChannel.InitializeACU(), or within SecurityContext.InitializeACU() itself. The DeviceProxy already has access to the IsDefaultKey property that indicates what the ACU sent.

Testing Considerations:

• Add unit tests to verify rejection of mismatched SCB types
• Test with both directions: SCBK-D requested but SCBK received, and vice versa
• Ensure proper error messaging for troubleshooting

Labels Recommendation

• bug - Incorrect behavior accepting invalid protocol responses
• security - Related to secure channel establishment
• protocol-compliance - OSDP specification compliance issue

Priority

Medium-High - This is a protocol compliance issue that could mask security or configuration problems, but only manifests with non-compliant devices.

---

[rsgmodelworks]

other than sounding like a cross between an R2D2 cosplay and a junior intern after being firedrilled, this assessement looks reasonable to me.