Sort EMV applications by the priority indicator, not the AID

[arpitjain099]

EMVCard::GetCardTokenAID reads both the AID (tag 0x4F) and the Application Priority Indicator (tag 0x87), validates that the priority node exists and is exactly one byte, and then sorts on the wrong one:

aidNode         = TLVParser::TLV_Find(pseDirectoryNodes[i], EMV_AID_TAG);
aidPriorityNode = TLVParser::TLV_Find(pseDirectoryNodes[i], EMV_PRIORITY_TAG);
if (aidNode && aidNode->Value->size() > 0 && aidPriorityNode && aidPriorityNode->Value->size() == 1)
{
    supportedAIDs.push_back(*aidNode->Value.get());
    supportedAIDsPriorities.push_back(aidNode->Value->at(0));   // <- AID, not priority
}

The length check on aidPriorityNode only makes sense if byte 0 is about to be read, and it never is: grep -rn "aidPriorityNode" src/ returns exactly the three lines above, so the value is discarded everywhere in the tree. The key that gets pushed is the AID's first byte, which on essentially every EMV card is 0xA0, the registered application provider prefix. Every key collapses to the same value and the ordering degenerates.

Verification drives the unmodified src/Common/TLVParser.cpp, compiled standalone against a small shim for Platform/PlatformBase.h and Tcdefs.h, with the selection loop transcribed from EMVCard.cpp lines 280-305. Source identity confirmed by sha256 before building. The input is one PSE READ RECORD response holding two application templates, Visa at priority 0x02 and Mastercard at priority 0x01, so the card ranks Mastercard first:

application templates found: 2
  [shipped code: aidNode->Value->at(0)]
    sort keys used: 0xA0 0xA0
    SELECTED AID: A0000000031010
  [fixed: aidPriorityNode->Value->at(0)]
    sort keys used: 0x02 0x01
    SELECTED AID: A0000000041010
card's stated priority-1 application: A0000000041010

The sort keys used: 0xA0 0xA0 line is the whole finding. EMV Book 1 section 12.4 makes the priority indicator the field that orders candidate applications.

On severity, so it is not overread: this is a correctness and spec-conformance bug, not a security issue. A hostile card already supplies every certificate byte that becomes the keyfile, so controlling the ordering gains it nothing, and the wrong selection reaches only the user who inserted the card. What it costs is keyfile determinism on a multi-application card, which is the contract of the feature.

[idrassi]

Thanks for catching this. Indeed, the code reads from the wrong node. But I'm hesitant to merge the change as it stands because application selection affects the keyfile itself.

Selecting another application can change the certificates used to build the keyfile. Someone could then upgrade VeraCrypt and find that their existing volume won't open with the same card and password. The token path doesn't record the AID, so we don't currently have a way to preserve the previous choice.

There's a point in the description I'd like to clarify too. The existing sort is deterministic: it compares pairs, so the full AID breaks ties when the first byte is identical. It ignores the card's priority, but it doesn't produce an arbitrary selection.

The replacement also needs to account for how the priority byte is encoded. Zero means no priority is assigned, yet this change would sort it ahead of priority one. For contact cards, bit 8 carries a separate requirement for cardholder confirmation.

The Visa and Mastercard example misses the initial selection step. If the standard Mastercard AID is selectable, both versions choose it before reaching this block. I'd like to see a test through GetCardAID() that actually exercises the directory fallback.

I'm glad you brought this up, but we need to work out how to correct the priority handling while keeping existing keyfiles usable before changing the selection behavior.