4.1	File access conditions
Actions, e.g. read, update, on SIM data shall be controlled by access conditions, which shall be satisfied before the action can be performed.
Since a UICC may contain multiple (UMTS and non-UMTS) applications a flexible method  of controlling file access will be required. Two different solutions are considered in the following subclauses.
4.1.1	The EFCHV approach
Following a notion brought up in EN726-3 [6], for each file in a card there is a relevant CHV defined. CHVs are stored in an EFCHV, and the relevant CHV file is a son of the current DF, or, if this one is not existing, the relevant CHV file is the relevant CHV of the parent of the current DF applies.
This sounds a bit complex, but in fact is simple because given any file xyz, you look for an EFCHV at the same level. If there is none, you go one level up. If there is a CHV file at this level, it applies to xyz; if not, you go one further level up. If you end up at the master file without coming across any EFCHV, then no CHV applies to xyz.
Example:

Figure 1: File / CHV structure
Here, the CHV related to the upper CHV file applies to the MF, DFGSM and DFTelecom . In contrast, DFBanking is protected by its own CHV stored in the lower CHV file.
According to this approach, it is possible to group several applications in a card, each potentially with its own CHV protection. It is, however, not possible to combine access conditions to a file (e.g. CHV of party x or CHV of party y).
NOTE:	The solutions offered by ISO and other non-ETSI card standards on these questions should be considered, e.g. VISA, MULTOS.
With this method, CHVs are clearly application-related. Normally they are stored locally within the application DF, which bears the advantage that adding or deleting applications to a card is straightforward.

4.1.2	A general solution for flexible multiple CHVs
If multiple CHVs are being used within one card, this represents a multi-user environment. In particular, in the general case there is no mapping between applications and CHVs as in clause 4.1.1, but rather a CHV is related to a specific user. Consequently, in this case it is not sufficient to prompt for a CHV, but, as in multi-user computer systems, the user is prompted for username and password (i.e. CHV).
Clearly if there is no mapping between an application (i.e. a DF) and a specific CHV, then the GSM coding for the STATUS response is no more appropriate because the DF may be accessed by various CHVs and thus there is no clearly defined “number of false presentations remaining “ as in the GSM STATUS response.
In this scenario, each application DF would have a mandatory “CHV list” contained in it, with a list of pointers to the CHVs which are allowed to access the application. The CHVs itself would be stored together with some kind of username.

Figure 2: Example of multiple CHVs using the CHV list method
In this example, the card has three CHVs (A, B, C) in total; the application in DFX  can be accessed with either CHV-A or CHV-C, whereas the application in DFY  can be accessed with CHV-B. When the user selects an application, he is prompted for a username and the corresponding CHV which are both stored in the EFCHV. If the user successfully verifies a particular CHV, then all applications where this CHV is valid are accessible.