Channel.selectNext() & openChannel with partial AID has potential conflict with GPAC enforcement
GoogleCodeExporter opened this issue · comments
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
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
[deleted comment]
[deleted comment]
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
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
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
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