JavaCard中带Next Occurrence的SELECT指令未被小程序接收问题

Let me recap the key details of my setup and the issue I’m hitting to frame things clearly:

• My app holds RESET permission and is automatically selected right after the card resets.
• It has a granular logging system that accurately tracks every request sent to the card, and returns dynamic responses based on its current state.
• I’ve verified using card spy that all APDUs—even SELECT commands that don’t target my app or any other app on the card—are correctly forwarded to my app.
• The critical problem: SELECT commands with the Next Occurrence parameter never reach my app’s processing logic.

Possible Causes & Fixes to Try #

1. Card’s Internal Routing for Next Occurrence SELECTs

Many smart cards handle SELECT commands with Next Occurrence (typically P1=0x02 per ISO 7816-4) differently from standard SELECTs. Even if your app is the default after reset, the card’s core logic might skip routing these iterative SELECTs to your app, instead prioritizing a system-level application or iterating through installed apps directly.

• Action: Check your card’s applet development specs or documentation for details on how Next Occurrence SELECTs are routed. Look for configuration flags or applet registration settings that let your app intercept these commands.

2. APDU Handler Filtering Out Next Occurrence SELECTs

It’s possible your app’s APDU processing code is explicitly ignoring SELECT commands with the Next Occurrence parameter, and not logging this behavior. Your general logging captures other SELECTs, but a conditional check might be skipping these specific ones.

• Action: Dig into your applet’s process() method code. Look for checks on the P1 value of SELECT APDUs. For example, if you have code like this that only handles SELECT by name:

  if (apdu.getBuffer()[ISO7816.OFFSET_P1] != ISO7816.SELECT_BY_NAME) {
      return ISO7816.SW_INS_NOT_SUPPORTED; // No logging here!
  }
  

  Adjust it to include handling for P1=0x02 (Next Occurrence) and add logging for these cases to confirm they’re being received.

3. Card Spy’s View vs. Actual Card Routing

While card spy shows the APDU being sent to the card, it might not capture whether the card actually routes it to your app. There could be a disconnect between what the terminal sends and what your app receives.

• Action: Add a debug trigger in your app—like returning a custom status word (e.g., 0x9001) whenever any SELECT command is processed. Send a Next Occurrence SELECT and check if that custom status shows up in card spy. If not, the issue is definitely in the card’s routing layer, not your app.

4. Default Selection vs. Iterative Selection Context

Some cards maintain separate contexts for default app selection (post-reset) and iterative SELECT operations. When a Next Occurrence SELECT is sent, the card might switch to a system context that bypasses your default-selected app.

• Action: Check if your app can register as a global handler for all SELECT commands, or if there’s a way to override the card’s default routing behavior for iterative SELECTs via applet configuration.

内容的提问来源于stack exchange，提问作者diogocasado