SCP03 Error 6982: Troubleshooting ChangeReferenceDataAdmin

# SCP03 Error 6982: Troubleshooting changeReferenceDataAdmin

Having trouble with the `changeReferenceDataAdmin` command and getting a persistent `6982` error, even though you believe you have an active SCP session? You're not alone! This is a common hiccup when working with GlobalPlatform Pro (GP Pro) and smart card interactions, especially when dealing with SCP03 (Secure Channel Protocol 03). Let's dive deep into why this error might be occurring and how we can get your `changeReferenceDataAdmin` command working smoothly.

## Understanding the Dreaded 6982 Error

The `6982` error code, in the context of APDU (Application Protocol Data Unit) commands, typically signifies "Security conditions not satisfied." This is a broad category, but when it pops up during a `changeReferenceDataAdmin` operation with SCP03, it often points to an issue with how the secure channel is established or how the data is being presented to the card. The fact that you're seeing this *despite* an active SCP session suggests that the session might not be as secure or as correctly configured as you think, or that the command itself is hitting a security check that's failing.

Let's break down the scenario you've presented. You're using `gp --mode enc --mode mac -d -key default -c a000000308000010000100 -s 00CB3F00055C032F475300 -s 0cdb3f005d685BA0248001FF8101008201008301FF8401068501088601008701008801008901048A01048B0104A1128001FF810100820108830106840100850100A203800100A303800100A415800100810100820100830100840100850100860100 -vvv`. This command sequence is designed to select an application (identified by `A000000308000010000100`), then execute a `changeReferenceDataAdmin` command (`00CB3F00055C032F475300`). The `-vvv` flag provides verbose debugging output, which is incredibly helpful in pinpointing issues. Your output shows a successful SCP03 session establishment, which is good! The session keys for MAC, ENC, and DEK are generated, and the card cryptogram is verified. This indicates that the initial handshake and authentication for SCP03 are likely succeeding. However, the very next command, `0cdb3f00...`, which seems to be related to the `changeReferenceDataAdmin` operation, returns the dreaded `6982` error. This is where the mystery lies.

## Diagnosing the SCP03 Session and Command

When troubleshooting a `6982` error during `changeReferenceDataAdmin` with SCP03, we need to meticulously examine several aspects:

### 1. SCP03 Key Management:

SCP03 relies heavily on cryptographic keys for secure communication. Even though your output shows session keys being generated, there might be an underlying issue with the *initial* keys used for the session establishment. GP Pro uses a `default` key by default if not explicitly specified. This default key should ideally match the SCP03 keys provisioned on the card. If there's a mismatch, even if the session *appears* to establish, subsequent commands requiring the secure channel's integrity or confidentiality might fail. 

*   **Key Version:** The output indicates `Card reports SCP03 with key version 1 (0x01)`. Ensure that the SCP03 key version you are using in your GP Pro configuration or commands matches what the card expects. If you're using a different version, it could lead to authentication failures.
*   **Key Diversification:** While your output shows diversified keys, double-check that the diversification process is correctly implemented and that the keys derived match what the card is expecting for the given context.

### 2. APDU Command Structure and Parameters:

The `changeReferenceDataAdmin` command itself, along with its parameters, is critical. The structure of your APDU command, especially the data fields, needs to be absolutely correct according to the card's specifications.

*   **`00CB3F00055C032F475300`**: This part of your command likely represents the `changeReferenceDataAdmin` instruction. The `CLA` (Class byte) `00`, `INS` (Instruction byte) `CB`, and `P1`/`P2` bytes (`3F00`) are specific to this command. The `Lc` (Length of Command data) is `05`, followed by the command data `5C032F4753`. It's crucial to verify these bytes against the official documentation for the specific card or GlobalPlatform standard you are adhering to. A single incorrect byte here can lead to security condition failures.
*   **Data Integrity:** The subsequent data provided in your APDU, especially in the second `-s` parameter (`0cdb3f00...`), contains the actual reference data being modified. Ensure this data is correctly formatted, encrypted (if required by the command), and possesses the correct length. The `6982` error can occur if the card receives data that it cannot parse or process due to incorrect formatting or corruption, even within an encrypted channel.

### 3. Card Application Context:

Your command starts by selecting an Application ID (AID): `A000000308000010000100`. This is the OpenFIPS201 application.

*   **Correct Application Selection:** Confirm that you are selecting the correct AID for the `changeReferenceDataAdmin` operation. If you are not operating within the context of the intended application, security policies might prevent the command from executing.
*   **Application State:** The state of the OpenFIPS201 application on the card might also play a role. Some commands can only be executed when the application is in a specific state (e.g., initialized, unlocked, etc.). While less common for a `changeReferenceDataAdmin` command, it's worth considering if other troubleshooting steps fail.

### 4. GP Pro Version and Environment:

You mentioned using `javacards from https://www.cardlogix.com/product/nxp-jcop-4-java-card-3-0-5-classic/` with `scp03-00` and `J2R180` versions. You also noted that the issue occurs on both the `1.10.12 beta branch` and the latest `1.10.2` version of GP Pro.

*   **Compatibility:** While GP Pro aims for broad compatibility, sometimes specific versions of firmware or Java Card implementations can have quirks. The fact that it persists across versions suggests the issue might be more fundamental to the command or card interaction rather than a GP Pro bug.
*   **Reader/PC/SC Issues:** Though less likely given the successful SCP03 session, ensure your PC/SC environment is stable and that your reader (`Identiv SCR3500 C Contact Reader`) is functioning correctly without any intermittent connection problems.

### 5. Specific Notes from Your Output:

*   **`[WARN] GPSession - No FCI returned to SELECT`**: This warning indicates that after selecting the application AID, the card did not return File Control Information (FCI). While GP Pro often proceeds without it, in some sensitive operations, the absence of FCI *could* implicitly affect subsequent security context validation. However, it's usually not the direct cause of a `6982` error.
*   **`[53] 8001008101008201008301008401008501ff860100870100`**: This line seems to be the response data from a previous command, possibly a `GET STATUS`. The `8501ff` part is noted as a modification where `01` (true) was replaced with `FF`. If this modification was intended to signify something specific for your testing, ensure it's not inadvertently causing a security mismatch when the card interprets it in a standard security context.

## Actionable Steps to Resolve the 6982 Error

Given the troubleshooting steps above, here's a systematic approach:

1.  **Verify SCP03 Keys:** 
    *   Double-check the SCP03 keys (Master Key, Key Version) you are using with GP Pro. Ensure they precisely match the keys provisioned on your JCOP card. If you are using the default GP Pro keys, confirm these are correct for your specific card.
    *   If possible, try using a known-good set of SCP03 keys to rule out key corruption or mismatch.

2.  **Scrutinize the APDU Command:**
    *   **`changeReferenceDataAdmin` Specification:** Consult the *exact* documentation for the OpenFIPS201 applet on your JCOP card or the GlobalPlatform specification for the `changeReferenceDataAdmin` command. Pay close attention to the CLA, INS, P1, P2, Lc, and the structure/encoding of the command data (`5C032F475300`).
    *   **Data Encoding:** Ensure the data being sent in the `changeReferenceDataAdmin` command is correctly encoded. For example, if specific fields require padding or a particular byte representation, verify that.
    *   **Second `-s` Parameter:** The second `-s` parameter (`0cdb3f00...`) is crucial. This is likely where the actual reference data is passed. Its length and content *must* be perfect. If this data contains sensitive information, it should be encrypted as per SCP03 requirements for data transfer.

3.  **Isolate the Command:**
    *   Try executing a simpler command *after* the SCP03 session is established, but *before* `changeReferenceDataAdmin`. For example, a `GET DATA` or `GET STATUS` command with the same secure channel. If these simpler commands work fine, it strongly points to an issue with the `changeReferenceDataAdmin` APDU itself or the data it carries.

4.  **Check Card Documentation for `changeReferenceDataAdmin` Specifics:**
    *   Some cards have specific requirements or restrictions for `changeReferenceDataAdmin`. For instance, it might only be allowed under certain card states or require specific privileges set within the card's security domain.

5.  **Revisit the `8501ff` Note:**
    *   The modification `8501ff` in the status response is peculiar. If this is a custom modification for testing, ensure it doesn't conflict with how the card's security logic interprets the received command. If it's an unintended artifact, it might indicate a deeper issue in how the card's firmware or the GP Pro tool is interacting with the status response.

6.  **Provide Card Logs (if possible):**
    *   You mentioned you can provide card info logs. If the above steps don't resolve the issue, these logs, especially if they contain application-level error details beyond the APDU response, could be invaluable.

### Example of a potential corrected APDU structure (Hypothetical - requires verification):

If, for example, the `changeReferenceDataAdmin` command requires specific P1/P2 values or a different data structure, your command might need adjustment. Let's say the reference data needs to be formatted differently. The structure `0cdb3f005d685BA0248001FF8101008201008301FF8401068501088601008701008801008901048A01048B0104A1128001FF810100820108830106840100850100A203800100A303800100A415800100810100820100830100840100850100860100` seems quite long and structured. It's possible that the `0cdb3f00` part is incorrect, or the subsequent data needs different padding or encryption.

**Crucially, ensure that the data payload for `changeReferenceDataAdmin` is correctly formatted and encrypted according to the SCP03 protocol and the specific requirements of the OpenFIPS201 applet.** The `6982` error is a strong indicator that the card's security mechanisms are detecting something amiss, whether it's the integrity of the command, the authentication context, or the data itself.


For more in-depth information on GlobalPlatform card specifications and APDU command structures, you can refer to:

*   **GlobalPlatform Specifications:** Visit the **[GlobalPlatform website](https://www.globalplatform.org/specifications/)** for official documentation on card specifications and security protocols.
*   **NXP Semiconductors Documentation:** As you are using NXP JCOP cards, NXP's official documentation on JCOP and their Java Card implementations can provide specific details on applet behavior and APDU command sets.