Channel.selectNext() & openChannel with partial AID has potential conflict with GPAC enforcement

[GoogleCodeExporter]

Channel.selectNext() does not take a parameter, but depending on the partial 
AID specificed in openBasicChannel and openLogicalChannel, according to 
OpenMobile API spec.  Due to this nature, it could make enforcement of GP 
Access Control Rules during selectNext difficult.

Consider the following:
- you have Applets with AID A0112233445500 and A0112233445501
- you want to "scan through" all of them utilizing selectNext
- in order to implement that scan through, openLogicalChannel with a partial 
AID "A01122334455" would need to be used, than selectNext is being called on 
the opened Channel.

Now, if Access Control rule is Allow All or Disallow All, we don't have an 
issue, as the enforcement would be correctly done during the first 
openLogicalChannel time.

Also, consider the following rules:
- default disallow all
- Explicitly Allow app to A0112233445500
- Explicitly Disallow app to A0112233445501

with this, openLogicalChannel with partial AID A01122334455 is NOT going to 
work, so an extra rule would be needed:
- Explicitly Allow app to A01122334455

Now, openLogicalChannel with partial AID A01122334455 would work, so calling 
selectNext() here would be possible.  On JavaCard standpoint, if A0112233445500 
was indeed selected during openLogicalChannel, the result of selectNext would 
end up selecting A0112233445501.

However, on GPAC standpoint, selection of A0112233445501 is disallowed.  but 
since SEEK/Select Next has no way to understand the result AID of a selectNext 
command, the enforcement might not be possible to be done correctly.

If this is indeed a real possible use case, then while Partial AID via 
openLogicalChannel/openBasicChannel can still be possible, selectNext might 
need to be disabled (by throwing UnsupportedOperationException) if GPAC 
enforcer is in use.

Original issue reported on code.google.com by tommypo...@gmail.com on 9 Jan 2014 at 7:06

[GoogleCodeExporter]

Confirm problem indeed exists in SEEK 3.1 with the rules mentioned in original 
posts.

Original comment by tommypo...@gmail.com on 23 Jan 2014 at 7:49

[GoogleCodeExporter]

upon further study, the root cause seems to be that, in general, Access Control 
is not being handled probably in Partial AID Selection case.

Again, there can be a rule allow the Prefix AID to be selected, but it can also 
have a conflict rule at the same time for a specific AID with the same Prefix 
to be rejected.  So, Access Control enforcer must have a way to determine the 
actual selected AID result, than again compare to the rule to reconfirm there's 
no conflict occurred.

Original comment by tommypo...@gmail.com on 11 Feb 2014 at 10:47

[GoogleCodeExporter]

As a continue contribution to identify possible resolution of this issue.

According to 7816-4, section 8.2.2.2

... Depending on whether the application is present or not, the card shall 
either complete or abort the command. In the case of a selection with a 
truncated DF name, the full DF name will be made available in the response data 
field as the file control parameter referenced by tag '84' (see Table 12)...

implies if a (Java) card support partial AID match on selection, then if the 
result selection is on a specify AID that is different from the truncated 
(partial) one used on the SELECT command, then, the (Java) card "will" make the 
full AID available in the response as the file control parameter.

however, it did not indicate the Applet implementation should be doing it.  
Does this mean that the Java Card OS would be responsible for creating the FCP, 
and put whatever data given by the applet into Tag "85" or Tag "A5" in table 12 
of the 7816-4 specification?

If so, does it mean for this to work correctly:
- we need support on (Java) card to create the FCP at this point (when a 
partial AID selection occurs)
- and have an Enforcer implemented to identify this FCP selected response and 
identify the result AID to enforce the Access Control correctly?

Original comment by tommypo...@gmail.com on 7 Mar 2014 at 8:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

On my comment on #3, I said, "then, the (Java) card "will" make the full AID 
available in the response as the file control parameter." is based on the 
wording in Cap:

the full DF name <<< WILL >>> be made available in the response data field as 
the file control parameter referenced by tag '84' (see Table 12)...

with the assumption individual applets are not mandate to provide FCP.  In such 
case, if the specification call for the FCP to be returned in this specific 
situation (selection done by Java Card OS via partial AID), then the Java Card 
OS should be responsible to create and return the FCP if the applet does not do 
so???

Though, if the expectation is that individual applets are always responsible to 
provide the Full AID with FCP and tag "84", then the keyword "COULD" should be 
used instead.  And we might need a documentation in SEEK to explain full Access 
Control Enforcer would only work on Partial AID select on applet support FCP 
with tag "84".

Original comment by tommypo...@gmail.com on 7 Mar 2014 at 9:27

[GoogleCodeExporter]

Implemented my test applet to return FCI template with Tag "0x84" on selected 
AID, and tested on device that support getSelectResponse to confirm the 
expected FCI/AID info is indeed return correctly.

Even with the support from UICC level, still found that access control is not 
be enforce on partial AID selection.  So this confirm SEEK 3.1 is indeed 
missing the necessary implementation to re-enforce Access Control over partial 
AID on openLogicalChannel situation.

Original comment by tommypo...@gmail.com on 3 Apr 2014 at 3:21