Access Control mechanism on Smartcard 2.4.0 + GPAC
GoogleCodeExporter opened this issue · comments
According to GP Secure Element AC spec 1.0 (section 4.2), there are 2 ways for
the Enforcer to be implemented: 1. Pre-Cache Rules and Refresh Tag mechanism.
2. Instant Query mechanism, which means that the access control enforcer would
never query rules up front; instead, on each open logical channel action, the
Access Control enforcer retrieves the rules associated to the AID & the cert
hash from ARA applet to determine the permission.
Looking into the code of SC 2.4, it seems to me that the implementation does
not follow any of the two mechanisms that GP specified.
Here is a scenario that could cause an error to evaluate access control rules:
1. App-A opens a logical channel to AID-1. As a result, GPAC enforcer loads the
access control rules associated with AID-1.
2. App-B opens a logical channel to AID-2. As a result, GPAC enforcer loads the
access control rules associated with AID-2.
3. OTA adds an access control rule to AID-2. The value of Refresh tag is
changed accordingly.
4. App-A opens a logical channel to AID-1. As the value of Refresh Tag is
changed, GPAC enforcer re-loads the access control rules associated to AID-1.
The new value of Refresh Tag also replaces the current Refresh tag.
5. App-B opens a logical channel to AID-2. Due to the value of Refresh Tag is
unchanged, GPAC enforcer uses the cashed access control rules associated to
AID-2, which is out of date as the rules have been changed since step 3.
Original issue reported on code.google.com by danny.w....@gmail.com
on 8 Feb 2013 at 5:00
After another review of code, I've realized that I am mistaken on this bug
report. According to the code, the entire cached access control rules will be
reset when a different value of Refresh Tag is found. Thus, on the step 5,
App-B will retrieve those access control rules associated to AID-2 even though
the Refresh Tag is the same.
It's not a defect.
Original comment by danny.w....@gmail.com
on 11 Feb 2013 at 7:23
see #1
Original comment by schus...@gmail.com
on 18 Mar 2013 at 2:47
- Changed state: Invalid