Attention is currently required from: laforge.
4 comments:
Patchset:
Thanks for your review input.
File aram/src/main/java/fr/bmartel/aram/AccessRuleMaster.java:
Patch Set #2, Line 106: ISOException.throwIt(ISO7816.SW_SECURITY_STATUS_NOT_SATISFIED);
why is this exception not raised in the INSTALL FOR PERSO case? The only condition for raising it is […]
This is part of the scheme. As far as I understand INSTALL FOR PERSONALIZATION can only be issued from a secure channel with the ISD.
The process() method is executed when APDUs are sent to the application when it is selected. Here we have no authentication but we can set this.aram_lock_status to true, which will make processCmdStoreData() inaccessible for normal users.
In processData() we do not have this blocking logic because this method is only accessible from a secure channel from the ISD.
This is at least how I understood the world. Please correct me if I am wrong. If there is a way to call processData() without beeing authenticated, then my Idea will not work of course.
Patch Set #2, Line 304: this.aram_lock_status = true;
mixing tab (new) and space (old) indentation
Done
Patch Set #2, Line 307: this.aram_lock_status = false;
where is the check that this command is only issued via the INSTALL FOR PERSO ?
This method is called from processData() and process(). As far as I know processData only runs when INSTALL FOR PERSONALIZATION is executed. So from that perspective we should be fine. When the method is called from process() this.aram_lock_status is checked first, so the executions barred when this.aram_lock_status is true (see line 105). I think this should be sufficient.
To view, visit change 39615. To unsubscribe, or for help writing mail filters, visit settings.