| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition |    
|
| C H A P T E R 6 |
|
Security and Access Control Mechanisms |
This chapter describes the following elements of security and access control:
A security policy designates the protected resources that can be accessed by individual applications or groups of applications. These protected resources may be security-sensitive system resources or application resources such as services provided by other applications.
On the Java Card Platform, a security policy may be implemented using two complementary techniques:
A permission-based security policy maps some of an application’s characteristics to a set of permissions granted to the application. These characteristics include the type of application model implemented by an application and may include other characteristics of an application’s code, such as its signer’s credentials.
Each application model supported by the Java Card Platform requires, permits or precludes access to various system resources, which may differ from one application model to the other. For example, the web application model supports multithreading and allows for an application to spawn new threads. However, in some environments, web applications may be denied permission to spawn new threads so other applications and the web container itself are not negatively impacted. Conversely, classic applet applications are typically not thread-safe and run in a environment that is single-threaded for backward compatibility reasons. Classic applet applications must not be permitted to spawn new threads.
The platform security policy MUST define this mapping of application models to sets of permissions granted to applications implementing these application models. The platform security policy MUST define for each of the three application models supported on the Java Card Platform the set of permissions that guarantees the consistency and integrity of the applications implementing each of these application models. The platform security policy MUST define each of these sets of granted permissions as a set of included permissions and a set of excluded permissions. The set of excluded permissions guarantees that no additional permissions can be granted that may violate the platform security policy. The platform security policy MAY be tuned for a specific environment, provided the consistency and integrity of each application model and of the platform itself is guaranteed. See Appendix A for the default set of permissions mapped to each of the application models.
In addition to permissions granted to an application based on its application model, other permissions MAY be granted in accordance with the operational environment in which the application is deployed. These permissions may be granted on a per-application basis or to applications sharing the same characteristics. Such permissions may include, for example, the permission to use another application’s service. The mapping from application characteristics to sets of permissions in accordance with the operational environment in which the application is deployed MAY be defined by what is referred to as the card management security policy.
Permission sets defined by the platform security policy and the card management policy constitute what is referred to as protection domains.
An application developer may express the logical security requirements of the application either declaratively through the definition of security constraints on certain resources (web resources only) or programmatically through the implementation of programmatic security checks within the code that manages the access to certain resources. These security constraints and programmatic security checks name the security roles permitted to access the protected resources.
A user or client security role is a logical grouping of users or client applications defined by the application developer or assembler. When the application is deployed, user and client roles MUST be mapped by a deployer (for example, the application provider) to actual user identities and client application identities or characteristics on the targeted platform. Such a mapping is referred to as an application security policy. An application security policy MUST be defined by an application deployer at deployment-time in the runtime descriptor of the application.
The overall security policy in effect for a particular application is the combination of the three security policies:
The effective authorization of a client application to use services provided by a server application results from the combination of the application client’s platform and card management security policies, and the server application’s application security policy. That is, the client application must be granted the permission to interact with the server application by its own platform and card management security policies, plus the client application must be granted an authorized role of the server application.
Permissions represent access to specific protected resources, such as security-sensitive system resources, or application resources, such as services provided by applications. Permissions are instances of subclasses of the java.security.Permission class. All permissions have a name or target name and may have an actions list. The format and interpretation of the name and actions list are specific to the permission classes.
Each permission concrete class MUST implement the implies abstract method of the Permission class to compare permissions. Permission p1 implies permission p2 means that if an application is granted permission p1, it is naturally granted permission p2. This comparison MUST take into account all the attributes of a permission, including its name or target name and, if defined, its actions list.
Permission objects are used to define the security policy. These permission objects are created when the platform security policy and the card management security policy are loaded and/or updated. Permission objects are also constructed whenever a permission to access a specific protected resource (the requested permission) must be checked against the permission granted by the security policies.
On the Java Card Platform, permission can be categorized into two types:
FIGURE 6-1 depicts the hierarchy of permission classes, the named permissions and the URI-named permissions as well as the two ways of defining new permissions.
FIGURE 6-1 Permission Class Hierarchy
A Named Permission (or Property-named Permission) contains a name designating the resource or collection of resources to protect. A named permission has no actions list; the named permission is either granted or not. The named permission classes are concrete subclasses of the java.security.BasicPermission class. They follow the hierarchical property naming convention of BasicPermission and allow for the use of name-prefix patterns (a property-like name with a trailing asterisk such as "crypto.*").
All named permission classes MUST be subclasses of the BasicPermission class. See Section 6.2.1.3, Definition of New Permissions.
The implies method of named permission classes MUST implement the following steps:
1. Check whether the compared permission instance passed as parameter is of the same class type as the comparing permission instance (both MUST be direct instances of the same class).
2. Check whether the compared permission name is implied by the name of the comparing permission.
The permission names comparison MUST take into account wildcards so that a trailing wildcard name component in the comparing permission’s name matches any trailing component of the compared permission name (including a wildcard).
TABLE 6-1 gives the list of named permission classes and their descriptions.
|
This class is for Java Card runtime environment permissions. It MUST protect the following functionality:
|
|
|
This class is for Java Card runtime permissions. It MUST protect the following functionality:
|
|
|
This class is intended for application- and library-defined named permissions. See Section 6.2.1.3, Definition of New Permissions. |
|
|
This class is for restartable task registry access permissions. It MUST protect the following functionality:
|
|
|
This class is for cryptographic service access permissions. It MUST protect the following functionality: |
|
|
This class is for card management permissions. It MUST protect the following functionality:
|
A URI-named Permission contains a URI target name designating a resource or collection of resources to protect and an optional actions list. The URI-named permission classes are concrete subclasses of the base javacardx.security.URIPermission class. They follow the URI naming convention of URIPermission to designate resources or collections of resources and allow for the use of a path-prefix URI patterns.
The target name represents the URI of a resource, such as an application, an SIO-based service, an event, a web resource, a file or any other type of resource. See Section 2.3, Unified Naming and Dedicated Application Namespaces.
The target name may be either:
For example, sio:///transit/pos/ticketbook designates the specific shareable interface object identified by the sio:///transit/pos/ticketbook URI; the sio:///transit/pos/* designates all the shareable interface objects identified by a URI starting with sio:///transit/pos/. The URI sio:///~/ticketbook designates the specific shareable interface object identified by the sio:///transit/pos/ticketbook URI when in the context of application ///transit/pos. The URI http://*.sun.com:*/* designates any resource on any host in the sun.com DNS domain accessible via the HTTP protocol on any port.
| Note - The root of the namespace designated by the path prefix URI pattern MUST NOT be itself included in the set of resources designated. |
The actions to be granted are passed to the constructor in a string containing a list of one or more comma-separated keywords (whitespaces surrounding commas are ignored). The possible action keywords are application or library-specific, but the semantic of each action keyword MUST NOT overlap, because an action MUST NOT imply another action[1].
The URI-named permission classes MUST implement the following requirements:
The implies method of URI-named permission classes MUST implement the following steps:
1. Check whether the compared permission instance passed as parameter is of the same class type as the comparing permission instance (both permissions MUST be direct instances of the same class).
2. Check whether the compared permission’s URI is implied by the URI of the comparing permission.
3. Check whether the compared permission actions list is implied by the actions list of the comparing permission.
The permission URIs comparison MUST take into account wildcards so that a trailing wildcard path component in the comparing permission’s URI path matches any trailing component of the compared permission URI (including a wildcard).
TABLE 6-2 gives the list of URI-named permission classes and their descriptions.
|
This class is for GCF connector permissions. It MUST protect the following functionalities:
See the API specification for javax.microedition.io and javacardx.io. |
|
|
This class is for firewall-enforced context permissions. It MUST protect the following functionalities:
|
|
|
This class is for event registry access permissions. It MUST protect the following functionalities:
See Section 7.4, Events. |
|
|
This class is for SIO-based service registry access permissions. It MUST protect the following functionalities: |
|
|
This class extends the Permission class and is the base class of all URI-named permission classes. It MUST be used as the base class for all permissions that use URIs (Uniform Resource Identifiers) as target names. See Section 6.2.1.3, Definition of New Permissions. |
New permissions may be defined either by defining new permission names for already defined permission classes or by defining new permission types extending existing permission base classes.
An application or library developer may define new named or URI-named permissions by defining new names, target name URIs and actions lists for NamedPermission and URIPermission objects.
The name attribute of the NamedPermission class is not constrained and allows any name to be used. The semantic of the names used depends on the context where they are defined and especially on the resources protected. Names of NamedPermission objects should uniquely designate the resources they protect. It is suggested that the names of NamedPermission objects be prefixed in accordance with the reverse domain name convention for package naming suggested by The Java Programming Language Specification. The prefixes javacard and javacardx are reserved by this specification.
The URI name and actions list attributes of the URIPermission class are not constrained and allow for any URI and URI scheme, and any actions list, to be used. The URI target name MUST uniquely designate the resource or collection of resources to protect. The semantic of the actions used SHOULD reflect permissible operations on these resources.
TABLE 6-3 lists the naming convention of application- and library-defined permissions a Java Card Platform MAY support.
New permission types MAY be defined by standards bodies when defining standard application or framework libraries for the Java Card Platform. These new permission classes MUST be subclasses of the BasicPermission or URIPermission classes. It is suggested that these permissions:
Additionally, these new permission classes MUST be immutable.
See Section 6.2.2, Protection Domains for the implications of defining new permission types on the protection domain.
A protection domain is a set of permissions granted to an application or group of applications. A protection domain is bound to a group context whose applications are granted the set of permissions. The set of permissions of the protection domain is determined according to the security policy that applies to the application or group of applications.
An application’s effective protection domain, or application protection domain for short, is the combination of:
Each application’s group context MUST be bound to one and only one protection domain, its application protection domain.
An application protection domain MUST be bound to a platform protection domain. The effective set of permissions granted by an application protection domain MUST account for the permissions granted as well as the permissions explicitly denied by the platform protection domain it is bound to, as per the procedure for checking permissions described in Section 6.2.4, Checking of Permissions.
An application protection domain MUST be updatable; that is, permissions may be added to or removed from the set of granted permissions during the lifetime of an application.
Updates to an application protection domain MUST NOT affect the protection domain of other applications in a different group context.
Updates to an application protection domain MUST NOT result in a set of permissions that violate the platform security policy that applies to that application (see also Section 6.2.4, Checking of Permissions):
An application protection domain MUST support being irreversibly locked to prevent further update of its permission set.
A protection domain MUST only allow for the following permission objects to be added to its permission set:
The use of JCREPermission MUST be restricted to the definition of platform protection domains, see Section 6.2.2.1, Platform Protection Domains.
Any attempt to add to an application protection domain instances of permission classes, other than the one listed above or indirect instances of the classes listed above, MUST result in a security exception being thrown. Any attempt to add to an application protection domain an instance of JCREPermission MUST result in a security exception being thrown.
An application protection domain may be assigned a name. Protection domain names are not constrained and may not be unique, but MUST be different from the names reserved for protection domains defined by the platform security policy, see Section 6.2.2.1, Platform Protection Domains. The name of a protection domain may be used by context switch permissions and role-based security for inter-application communications, see Section 6.2.5.2, Context-switch-triggered Security Checks and Section 6.5, On-card Client Application Authentication and Authorization.
A Java Card Platform implementation MAY internally create Java Card RE-owned copies[2] of the permission objects to be added to a protection domain and only add these copies to the protection domain. In such a case, subsequent management operations (add, remove, enumerate, check) MAY be performed on these Java Card RE-owned copies.
A Java Card Platform implementation MAY internally use any optimized representations to manage (add, remove, enumerate, check) permissions in a protection domain, but MUST manage permission sets as collections of permission objects (allowing duplicates) with respect to adding and removing permissions[3]. Add and remove operations on a collection of permission objects MUST be implemented in terms of the Permission.equals() method[4]. Especially, permissions MUST be removed with the same granularity in which they were added, regardless of the possible compositions of permissions of the same types. For example, if the two following permissions:
had been added to a protection domain, attempting to remove the permission ServiceRegistryPermission(“/transit/pos/ticketbook”,“register”) or ServiceRegistryPermission(“/transit/pos/ticketbook”,“lookup”) must not result in the protection domain’s set of permissions being changed because it does not actually contain any of the permission objects to be removed.
Access to the class or classes encapsulating the characteristics of protection domains MUST be protected by package access control builtin checks as described in Section 6.8.1, Built-in Checks and MUST be restricted to card management applications. Retrieving the protection domain of an application from its group context MUST be subject to access control: a security check MUST ensure that the permission javacardx.spi.cardmgmt.CardManagementPermission with the target name protectionDomain.get is granted.
The platform security policy defines for each of the three application models supported on the Java Card Platform, a platform protection domain, which is a set of permissions that guarantees the consistency and integrity of the applications implementing each of these application models. Each of these platform protection domains defines the minimum set of permissions granted to an application of the corresponding type. Additionally, the platform security policy defines a platform protection domain for the card management applications.
Each of these platform protection domains MUST be uniquely identified with a name.
Each of these platform protection domains MUST be defined with a set of included permissions and a set of excluded permissions.
The default platform protection domains defined below MAY be tuned for specific environments according to the following rules:
Platform protection domains MUST be locked to prevent any post-issuance update.
The default protection domain for web applications MUST be named “Web”. It MUST include the set of included permissions listed in Appendix A, TABLE A-1 and the set of excluded permissions listed in Appendix A, TABLE A-2.
The default protection domain for extended applet applications MUST be named “Extended”. It MUST include the set of included permissions listed in Appendix A, TABLE A-3 and the set of excluded permissions listed in Appendix A, TABLE A-4.
The default protection domain for classic applet applications MUST be named “Classic”. It MUST include the set of included permissions listed in Appendix A, TABLE A-5 and the set of excluded permissions listed in Appendix A, TABLE A-6.
The default protection domain for card management applications MUST be named “CardManagement”. It MUST include the set of included permissions listed in Appendix A, TABLE A-7 and the set of excluded permissions listed in Appendix A, TABLE A-8.
A group context is bound to one application protection domain. All the applications in that group context are granted the same set of permissions.
Prior to the first application being instantiated in a group context, the assignment of permissions to the application protection domain MUST proceed as follows:
1. The platform protection domain MUST be determined, based on the type of applications to be instantiated, and bound to the group context.
2. The application protection domain MUST be created with an optional name and bound to that platform protection domain.
3. The application protection domain MAY be assigned additional permissions as per the card management policy in effect.
4. The group context MUST be bound to the application protection domain.
Permissions MAY be added and removed from the set of permissions initially added as per the card management policy at any time, provided the application protection domain is not locked.
Checking if a permission is granted to an application by its application protection domain MUST follow the following steps:
1. Check if the permission is implied for all of its actions, if any are specified, by the set of permissions resulting from the union[5] of:
2. Check if the permission is not implied for any of its actions, if any are specified, by the set of excluded permissions defined by the platform protection domain.
When checking if a requested permission is implied by a set of permissions, the requested permission may not correspond to a single permission object in the permission set but may be implied by a composition of several permissions.
A URI-named permission object may not only include a URI target name but also a list of actions. When a permission set contains several permissions of the same type which protect the same resource either by directly designating the resource or by designating a namespace that encompasses the resource, the actions of all the permissions that protect the resource MUST be taken into account to determine the effective permission on that resource.
For example, if a permission set contains the two following permissions:
and the permission ServiceRegistryPermission( “/transit/pos/ticketbook”, “register,lookup”) is being checked, then the effective permission against which the checked permission must be compared is ServiceRegistryPermission(“/transit/pos/ticketbook”, “register, unregister,lookup”).
The security policy is enforced by two types of security checks:
Each of these two types of security checks implements the same principle for deciding whether to grant access to protected resources.
An access control decision MUST be made based on the group context of the immediate application requesting the access:
The protection domains of the other group contexts in the chain of calls MUST NOT be taken into account during an access control decision.
FIGURE 6-2 depicts the interaction between the different actors involved in a access control decision. Objects colors indicate common ownership of interacting objects. The colors of focus of control boxes[6] indicate the currently active contexts as the results of specific calls.
FIGURE 6-2 Access Control Decision Principle (Sequence Diagram)
When a thread calls a method of an object owned by a group context different from its active context, the Java Card virtual machine performs a context switch. During the context switching method invocation, the current active context is saved and the new context (group context or Java Card RE context) becomes the active context of the currently executing thread.
After the Java Card virtual machine has determined that a context switch must be performed, but prior to performing it, the Java Card virtual machine MUST perform one of two security checks depending on the new context:
This security check MUST ensure that the permissions in the applicable protection domain (as defined in Section 6.2.5.1, Access Control Decision Principle) imply the permission javacardx.spi.framework.JCREPermission with a name designating the class name of the temporary (respectively permanent) Java Card RE EPO or global array object according to the following format callTempJCREEPO.{class name} (respectively callPermJCREEPO.{class name}).
TABLE 2-3 gives the Classic set of permanent Java Card RE EPO classes that is designated by the permission javacardx.spi.framework.JCREPermission with the special name callPermJCREEPO.CLASSIC.
TABLE 2-4 gives the Classic set of temporary Java Card RE EPO classes that is designated by the permission javacardx.spi.framework.JCREPermission with the special name callTempJCREEPO.CLASSIC.
TABLE 2-5 gives the Extended set of permanent Java Card RE EPO classes that is designated by the permission javacardx.spi.framework.JCREPermission with the special name callPermJCREEPO.EXTENDED.
TABLE 2-7 gives the Classic set of global array objects that is designated by the permission javacardx.spi.framework.JCREPermission with the special name callTempJCREEPO.CLASSIC.
This security check MUST ensure that the permissions in the protection domain associated with the currently active context imply the permission javacardx.framework.ContextPermission with a target identifying the new group context and with the action switch.
The target identifying the new group context MUST designate one of the following:
No such security check MUST happen when switching to the Java Card RE context or switching from the Java Card RE context.
Security checks may be programmatically initiated by the Java Card RE, libraries, and also applications to protect access to sensitive resources or check by anticipation if access to protected resources would be granted.
To programmatically check if an application is granted the permission to access a specific protected resource prior to access, the resource, an instance of the corresponding permission class, MUST be constructed and the checkPermission method of the java.security.AccessController class MUST be invoked. The checkPermission method of the AccessController class MUST determine whether the access request indicated by the permission should be granted or denied, based on the protection domain associated with the group context of the application. The specified permission MUST be granted if the access controller determines that the permissions of the protection domain imply the requested permission.
The permissions required for access are specified for each protected resource or functionality by the associated API specification. These MUST be enforced by an implementation of the Java Card Platform.
Platform protection domains are not updatable post issuance. An implementation MAY implement checks for permissions granted by platform protection domains, such as for javacardx.spi.framework.JCREPermission, in any optimized way, including as built-in checks, as long as the result is semantically equivalent to that described in Section 6.2.4, Checking of Permissions.
Role-based security is used to restrict access to resources to only those users and client applications which have been granted a particular security role:
An application’s role-based security relies on the following:
A user or client security role is a logical grouping of users or clients defined by the application developer or assembler. When the application is deployed, roles MUST be mapped by a deployer (for example, the application provider) to user identities and client identities or client characteristics. If a role is not mapped, that role cannot be granted to any user or application client and, therefore, a resource exclusively protected by that role will not be accessible.
User role-based security may be used to control access both to SIO resources, such as SIO-based services and events, and to web resources:
A web application developer may use declarative security to express security constraints on certain resources of a web application. A security constraint designates:
Security constraints are declared in the deployment descriptor of web applications for constraints on web resources.
See Section 6.4.5.1, Container Checking of User Authorization for more details on how the web container determines whether a user is authorized to access a protected web resource.
Programmatic user role-based security consists of the following methods:
The JCSystem.isUserInRole method determines if an authenticated identity is in a specified security role as defined in the Java Card Platform-specific application descriptor for SIO and event resources. On a call to JCSystem.IsUserInRole, the following steps MUST be followed:
1. If the authentication is session-scoped, that is, if there is an authenticated identity associated with the current thread, check that the URI of the authenticator associated with that authenticated identity matches one of the authenticator URIs to which the role was mapped. See Section 6.3.1.3, Role to User Mapping for details on the matching rules.
2. Otherwise, if the authentication is global, that is, there is no authenticated identity associated with the current thread, or if the authentication is session-scoped but the URI of the authenticator associated with the authenticated identity does not match any of the authenticator URIs to which the role was mapped, check that one of the authenticator URI to which the role was mapped corresponds to a globally authenticated user.
The HttpServletRequest.isUserInRole method determines if an authenticated identity is in a specified security role as defined in the web application's deployment descriptor for web resources. On a call to HttpServletRequest.isUserInRole, the following steps MUST be followed:
1. If there is an authenticated identity associated with an incoming request, check that the URI of the authenticator associated with that authenticated identity matches one of the authenticator URIs to which the role was mapped.
2. Otherwise, if there is no authenticated identity associated with the incoming request, false is returned.
|
Caution - The HttpServletRequest.isUserInRole method applies to roles defined for web resources, while the JCSystem.isUserInRole method applies to roles defined for SIO and event resources. |
User security roles MUST be declared in the Java Card Platform-specific application descriptor and/or in the deployment descriptor of web applications. These roles MUST be mapped to authenticator URIs in the runtime descriptor of the application. See Section 6.4.1, Scheme-specific Authenticators for details on authenticator URIs.
The use of path prefix URIs is allowed under certain restrictions for designating a collection of session authenticator URIs. For example sio:///standard/auth/user/session/admin/* may be used to designate sio:///standard/auth/user/session/admin/admin1/password, sio:///standard/auth/user/session/admin/admin2/fingerprint and sio:///standard/auth/user/session/admin/admin3/iris-scan. Such path prefix authenticator URI patterns can only be used to designate authorized users where a user authorization can be checked by matching the path prefix URI pattern against the authenticator URI representing a user’s identity.
The platform MUST enforce programmatic security for the authenticated identity associated with the client of an SIO-based service or the consumer of an event based on the corresponding authenticator URI. The web container MUST enforce declarative and programmatic security for the authenticated identity associated with an incoming request based on the corresponding authenticator URI.
The following rule must be enforced by the Java Card RE:
The use of path-prefix URI pattern for global authenticator is not permitted. The platform MUST reject any application mapping security roles to a global authenticator path-prefix URI pattern.
The use of an authenticator path-prefix URI pattern is not permitted for security constraints on web resources defined in a web applications’s deployment descriptor. The platform MUST reject any web application mapping security roles defined for security constraints on web resources to authenticator path-prefix URI patterns.
If a user security role declared in the Java Card Platform-specific application descriptor or in the deployment descriptor of a web application is not mapped to any authenticator URI, no user can authenticate in that role and therefore access to resources protected by that role can not be authorized.
If a web application declares a user security role in its deployment descriptor but no login configuration or authentication method (login-config and login-config/auth-method elements), active authentication in that role by the container on behalf of that application will not be performed. Similarly, if the user security role is mapped to an authenticator URI with a <scheme> or <realm> path component that does not match the authentication method or realm name[8] (login-config/auth-method and login-config/realm-name elements) declared for that web application, active authentication in that role by the container on behalf of that application will not be performed. If the user security role is mapped to a global card holder identity, access to resources protected by that role may still be authorized regardless of the authentication scheme or realm name, provided the global card holder identity has already been authenticated either programmatically by the application or, by or on behalf of another application. This behavior is enforced by the algorithm described in Section 6.4.5.1, Container Checking of User Authorization.
See Chapter 8 for more details on how to map roles to users in the runtime descriptor of the application.
Client role-based security may be used to control access to SIO resources such as SIO-based services and events only. Client role-based security for SIO-based services and events may only be implemented using programmatic security[9].
Programmatic client role-based security consists of the isClientInRole method of the JCSystem class.
The JCSystem.isClientInRole method determines if an application client is in a specified security role. A call to this method MUST check that one of these conditions exist:
Client role-based security MUST not apply among applications within the same group context. If the client application (the caller of the SIO) is in the same group context as the server application isClientInRole MUST return true.
Client security roles MUST be declared in the Java Card Platform-specific application descriptor. These roles MUST be mapped in the runtime descriptor of the application to one of the following:
See Chapter 8 for more details on how to map roles to clients in the runtime descriptor of the application.
User authentication is the process by which a user proves his or her identity to the card. This authenticated identity is then used by the platform to perform authorization decisions for accessing protected resources such as web resources and SIO-based and event-based services.
Users can be categorized into two types:
To both these types of users may correspond different user identities on the card:
Additionally, applications can be categorized into two types:
See Section 6.4.6, Card Holder Authorization For Remotely Accessible Applications for how the container MUST distinguish between these two types of applications.
The scope of user authentication can be categorized into two types:
Card-holder-user authentication can be tracked globally (card-wide). Authorization to access resources protected by a globally authenticated card-holder-user identity is granted to all users. This may be viewed as the card holder opening the card for a certain usage, thereby allowing certain protected resources to be accessed by any users regardless of their actual identities.
Because several conversational sessions can be established simultaneously between on-card applications and web clients, web user authentication can also be tracked on a per-session basis. This prevents a user authenticated in a conversational session under one identity to gain unauthorized access to protected resources authorized to another, simultaneously authenticated, identity. Such a situation would, otherwise, arise if global authentication were used to authorize access from different web clients, even though different identities were used.
The Java Card RE implementation MUST support tracking the state of card-holder-user authentication globally (card-wide) and on a per-session basis (session-scoped), whereas the Java Card RE implementation MUST support tracking the state of other-users' authentication only on a per-session basis. In both cases, authentication is delegated to application-level authenticators for performing the actual authentication against a user's credentials according to a specific scheme (such as PIN-based, biometric, or password-based).
Additionally, an application may either manage (meaning initiate, check and reset) authentication of users directly, interacting directly with the user authentication facility, or may delegate authentication of users to the application container. Container-managed authentication is only supported by the web application container[10]. A web application may manage user authentication directly if the web application needs to manage authentication at a different granularity than the one provided by the web container.
Container-managed authentication of a card-holder-user MUST only be supported for applications identified in their Java Card Platform-specific application descriptor as locally accessible, see Section 6.4.6, Card Holder Authorization For Remotely Accessible Applications. Application-managed authentication of a card-holder-user is not subject to this restriction, but application developers and application providers must be aware of the potential risks.
The authentication facility relies on authenticators, a set of authentication services, to handle authentication according to different schemes. These authenticators MUST expose service interfaces which implement the javacardx.framework.Authenticator interface and which itself implements javacard.framework.Shareable interface. The corresponding SIOs MUST be registered in the SIO-based service registry under the standard SIO namespace. The authenticator SIO namespace is partitioned to discriminate between card-holder-users and other-users, and between global and session-scoped authentication. URIs in this namespace additionally distinguish both specific users being authenticated, as well as specific schemes used for authentication of these users. Authenticators may be registered and unregistered in and from the SIO-based service registry by any application having the required privileges, such as a card management application.
An authenticator URI MUST be one of three types:
sio:///standard/auth/holder/global/[<realm>/]<user>/<scheme>
sio:///standard/auth/holder/session/[<realm>/]<user>/<scheme>
sio:///standard/auth/user/session/[<realm>/]<user>/<scheme>
The <user>, <scheme> and <realm> path components of these URIs are place holders for specific user names, authentication schemes and authentication realm names respectively. The <realm> path components of these URIs may designate an arbitrary path.
For example, an authenticator URI for the global card-holder-user name owner, the authentication scheme pin and the realm name /transit/pos could be:
sio:///standard/auth/holder/global/transit/pos/owner/pin
Each authenticator URI represents a unique identity on the platform.
The uniqueness of user names (<user> path component of the authenticator URIs) across the different authenticator sub-namespaces is not enforced by the platform, meaning the same user name may be used for a global card-holder-user identity, a session card-holder-user identity, or even an other-user’s identity. It is recommended, though, that the user management policy enforces the uniqueness of user names between card-holder-user identities and all other-user identities.
Each authenticator MUST provide the following functionality:
For PIN-based authentication, the authenticator SIO and its URI MUST have the following properties:
For password-based authentication, the authenticator SIO and its URI MUST have the following properties:
For biometric authentication, the authenticator SIO and its URI MUST have the following properties:
Additional schemes MAY be defined as long as they do not use these reserved names.
Since authenticators are plain SIOs, registration and invocation of authenticators are subject to the same access control policies as plain SIOs. For example, authentication as a particular identity may only be granted to a specific application and, then, only if a card-holder-user has already been globally authenticated. Authentication of the admin user sio:///standard/auth/user/session/admin/password, for example, may only be authorized through the /admin web application if the owner card-holder-user sio:///standard/auth/holder/global/owner/pin is already authenticated.
For global authentication, the authenticator SIO instances returned by the SIO-based service registry for a particular URI MUST represent a single authentication state. The authenticator SIO may typically be implemented as a singleton.
Authenticators registered under the namespace sio:///standard/auth/holder/global/ MUST support global card-holder-user authentication.
Upon successful authentication using a global authenticator, the authenticated identity represented by the URI of the global authenticator MUST remain authenticated until explicitly reset or invalidated by a failed re-authentication attempt or until a platform reset.
In order to determine if a card-holder-user is globally authenticated, the corresponding authenticator MUST be located and the authentication status MUST be checked. For example, to determine if the card-holder-user owner identified by the URI sio:///standard/auth/holder/global/owner/pin is authenticated, the PIN authenticator must be located and its Authenticator.isValidated method must be invoked.
An application developer may determine if a card-holder-user is globally authenticated by directly implementing this procedure or may use the JCSystem.isUserInRole method to determine if an authenticated card-holder-user identity is in a specified security role as defined in the Java Card Platform-specific application descriptor. See Section 6.3.1.2, Programmatic User Role-based Security for more details.
For session-scoped authentication, the authenticator SIO instance returned by the SIO-based service registry for a particular URI MUST represent a different authentication state for each session. This is typically achieved by returning different instances at each call. While the authentication state they manage must be different, all authenticator instances representing the same identity SHOULD share a common try limit counter so that failed attempts may be counted globally.
Upon successful authentication using a session authenticator, the authenticated identity represented by the URI of the session authenticator MUST be associated with the current authentication session and bound to the current thread. The same authenticated identity MUST be bound to any subsequent request-dispatching thread when entering any web application within the scope of that same authentication session.
Session-scoped authentication MUST be supported for authenticators registered under the namespaces sio:///standard/auth/holder/session/ and sio:///standard/auth/user/session/.
Authenticators registered under the namespace sio:///standard/auth/holder/session/ MUST support session-scoped card-holder-user authentication.
Authenticators registered under the namespace sio:///standard/auth/user/session/ MUST support session-scoped authentication for other-users.
In order to determine if a user (a card-holder-user or an other-user) is authenticated for the current session, the corresponding session authenticator URI and the authenticator URI bound to the current thread MUST be compared. For example, to determine if the user admin identified by the URI sio:///standard/auth/user/session/admin/password is authenticated, this URI must be compared with the authenticator URI bound to the current thread.
An application developer may not have direct access to the authenticator URI bound to the current thread. An application developer may use the JCSystem.isUserInRole method to determine if the currently authenticated identity is in a specified security role as defined in the Java Card Platform-specific application descriptor. See Section 6.3.1.2, Programmatic User Role-based Security for more details.
The platform MUST allow an application to manage (validate, check and reset) user authentication by the application interacting directly with the user authentication facility.
Applications may locate authenticators in the SIO-based service registry using their URIs and may invoke the methods exposed by the authenticators to:
It is the responsibility of the application to properly demarcate the authentication session.
When attempting to access a protected web resource, a web application client can authenticate a user to the web application container using one of the following mechanisms:
The authentication mechanism to be used when accessing a protected web resource MUST be specified in the application's deployment descriptor (web application deployment descriptor). The platform MUST reject a web application which declares in its deployment descriptor an authentication method that is not supported.
These authentication mechanisms can be used for both global authentication of card-holder-users and session-scoped authentication of card-holder-users and other-users.
When a user attempts to access a protected web resource, the container MUST determine whether the user is authorized to access the resource by checking if any of the following conditions is true:
1. There is an authenticated identity associated with the current authentication session (a session authenticator URI) and that authenticated identity corresponds to one of the roles permitted to access the resource.
2. One of the roles permitted to access the resource corresponds to a globally authenticated identity (a global authenticator URI).
If the user is authorized, the requested web resource is activated and a reference to it is returned.
If the user is authenticated but not authorized, the request MUST be rejected as forbidden and a 403 status code MUST be returned.
If the user is not authenticated and if there is no login configuration or authentication method (login-config and login-config/auth-method elements) defined for the web application, the request MUST be rejected as forbidden and a 403 status code MUST be returned.
If the user is not authenticated and if there is a login configuration and authentication method (login-config and login-config/auth-method elements) defined for the web application, the container MUST attempt to authenticate the user as follows:
1. The container MUST query the user for his credentials (including his user name) through the requesting client according to the authentication scheme identified in the login-config/auth-method element of the web application deployment descriptor.
2. For the first[11] role permitted to access the resource (which is done in the order by which they are listed in the deployment descriptor) mapped to an authenticator whose URI’s <scheme> and <realm> path components match the values of the login-config/auth-method and login-config/realm-name elements[12], respectively, of the web application deployment descriptor, and whose URI’s <user> path component matches the user name provided by the user, the container MUST proceed as follows:
a. The container MUST locate the authenticator. If the container fails to locate the authenticator, the authentication MUST fail.
b. The container MUST attempt to authenticate the user with the provided credentials.
3. If none of the roles permitted to access the resource is mapped to an authenticator URIs matching the provided user name, the authentication MUST fail.
4. If authentication fails, therefore the user is not authorized, and the status code of the response is set to 401 (Unauthorized).
5. If authentication succeeds, the user is authorized and the requested resource is returned to the client.
This process is a refinement of the generic process described in the Java Servlet Specification for the Java Card Platform where the container first attempts to authenticate the user and then determines if the user’s authenticated identity is permitted to access the resource. For security reasons, the validation of the credentials provided by the user during authentication must only happen if the user’s claimed identity is known to be permitted to access the resource.
Some authentication schemes, such as the standard form-based authentication mechanism and the Java Card Platform authentication mechanism defined below, may use means other than setting the status code of the response to 401 (Unauthorized) for triggering authentication and/or handling authentication failure.
The getRemoteUser method of the HttpServletRequest interface returns the user name the client used for authentication. This value also corresponds to the <user> path component of the authenticator URI used for authentication. Note that if access to a protected resource is granted on the basis of some (other) globally authenticated card holder identity rather than on the actual authenticated identity of the user, the getRemoteUser method MUST still return the user name provided by the remote user if he already authenticated, or null if the remote user has not already been authenticated.
HTTP Basic, HTTP Digest and Form-based Authentications are all based on a username and password.
These three schemes MUST be mapped to either PIN-based or password-based authenticators. Typically, for card-holder-user authentication, these three schemes will be mapped to PIN-based authenticators, while for other-users they will be mapped to password-based authenticators. The platform MUST reject web applications for which these three schemes are not mapped to PIN-based or password-based authenticators.
When performing PIN-based authentication using one of these three schemes, the password value MUST be interpreted as the PIN, and the user name either explicitly queried or implicitly set[13] MUST be used to determine the URI of the authenticator.
When HTTP DIGEST authentication is being used, the web container MUST check the credentials of the user by calling the check method of the javacardx.servlet.http.HttpDigestAuthentication interface on the authenticator. If the authenticator does not implement the HttpDigestAuthentication interface the authentication MUST fail.
To facilitate the implementation by application and library developers of authenticators that support HTTP DIGEST authentication, instances of javacardx.biometry.OwnerBioTemplate created for the type BioBuilder.PASSWORD SHOULD implement the HttpDigestAuthentication interface.
In addition to the standard authentication schemes, the web application container MUST support the use of the Java Card Platform authentication mechanism for container-managed authentication. This mechanism is intended to be extensible and to support various authentication schemes such as biometric which have requirements beyond those of simple user name and password.
The Java Card Platform authentication mechanism MUST be identified in the auth-method element of web application deployment descriptors with names in the form JC-<scheme>, where the <scheme> name component must match the scheme path component of registered authenticator's URIs. For example, an auth-method element value of JC-fingerprint constrains the container to use fingerprint-based authenticators that must be registered with URIs ending in /fingerprint, for example, sio:///standard/auth/holder/global/transit/pos/owner/fingerprint.
The Java Card Platform authentication mechanism behaves similarly to the standard form-based authentication mechanism and reuses its deployment descriptor entries for login and error pages: form-login-page and form-error-page.
The login form MUST collect the user’s name and scheme-specific credential and MUST pass them as parameters of an HTTP request to the jc_security_check URL. This URL is relative to the base URL of the login form. The parameters for the user’s name and scheme-specific credential MUST be named jc_username and jc_<scheme> (for example, jc_pin, jc_password or jc_fingerprint), respectively. For a biometric authentication scheme, the jc_<scheme> parameter will contain the data of the candidate template. When the scheme-specific credentials are too large, are binary data or are text containing non-ASCII characters, the content type "multipart/form-data" may be used for the request. If implemented in HTML, the login form may contain fields for entering a user name and a scheme-specific credential. These fields must be named jc_username and jc_<scheme>, respectively. The action of the login form must be jc_security_check.
Note that a Java Card Platform authentication mechanism can also be used for PIN-based and password-based authentication, in which case the auth-method element of the web application deployment descriptor must be set to JC-pin and JC-password, respectively.
When a user attempts to access a protected web resource, the container checks the user’s authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned. If the user is not authenticated, the web application container MUST perform the following steps:
1. The login form associated with the security constraint is sent to the client and the URL path (and parameters) triggering the authentication is stored by the container.
2. The user is asked to fill out the form.
3. The client posts the form back to the server.
4. The container determines if there is an authorized role for accessing the resource that matches the user’s claimed identity and then attempts to authenticate the user using the information from the form and the configured scheme.
5. If there is no role matching the user’s claimed identity, or if authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200.
6. If the user is authorized, the client is redirected to the resource using the stored URL path and parameters.
The error page sent to a user that is not authenticated MUST contain information about the failure.
If the user is authenticated, the method getAuthType of the HttpServletRequest interface may be used to retrieve the name of the scheme used for authentication. The returned value MUST be the exact authentication scheme name as declared in the auth-method element of the web application deployment descriptor, for example, “JC-fingerprint”.
An example of configuration for PIN-based authentication of a web application is given in CODE EXAMPLE 6-1 and CODE EXAMPLE 6-2.
<form method=”POST” action=”jc_security_check”> <input type=”text” name=”jc_username” /> <input type=”password” name=”jc_pin” /> </form> |
An example of configuration for fingerprint authentication of a web application is given in CODE EXAMPLE 6-3 and CODE EXAMPLE 6-4.
Clients of web applications can be categorized into two types:
Access to locally accessible web applications (meaning applications that may be expected to interact with the card holder) MUST only be allowed from card holder-facing web clients. When using container-managed authentication, the web container MUST NOT proceed with a card-holder-user authentication through a web client that is not facing the card holder or considered otherwise trusted.
Access to remotely accessible applications (meaning, applications that are not expected to interact with the card holder but with other-users) requires card holder authorization when accessed from non-card holder-facing clients. Web applications requiring card holder authorization MUST include in their Java Card Platform-specific application descriptor a card-holder-authorization element and one or more role-name sub-elements designating role names mapped to card-holder-users, see card-holder-authorization Element in Chapter 8. Access to such a web application MUST only be granted if the card holder is already authenticated in one of the roles listed. This applies, in addition, to the authorization constraints on remote users that the web application's deployment descriptor may define for specific portions of the web application (web resources). If no role is listed, a web client MUST NOT be allowed access to any of the resources of the web application.
FIGURE 6-3 depicts the various interactions when accessing locally or remotely accessible web applications from a card holder-facing client. The numbering indicates typical interaction sequences.
FIGURE 6-3 Access from a Card Holder-Facing Client (Collaboration Diagram)
FIGURE 6-4 depicts the various interactions when accessing a remotely accessible web application from a non card holder-facing client. The numbering indicates typical interaction sequences.
FIGURE 6-4 Access from a Non Card Holder-Facing Client (Collaboration Diagram)
TABLE 6-5 summarizes when card holder authorization is required for granting access to a web application depending on the types of clients requesting the access and the types of applications being accessed.
The verification of whether the card holder is already authenticated in one of the roles listed for authorizing a remote access to an application MUST be done by locating the card-holder-user authenticators these roles are mapped to and invoking their Authenticator.isValidated method.
If none of the card-holder-users the roles listed are mapped to is already authenticated, the web container MUST NOT attempt to authenticate any of these card-holder-users through the requesting web client, and it MUST reject the request as forbidden. A 403 status code MUST be returned to the requesting web client.
For example, to allow access from remote web clients if the card holder is authenticated in the ADMIN role, the application's Java Card Platform-specific descriptor would contain:
<card-holder-authorization> <role-name>ADMIN</role-name> </card-holder-authorization>
The platform MUST allow for these role names (card holder authorization role names) to be mapped to either global or session-scoped card-holder-user authenticator URIs. The card holder authorization, if granted for an application, is granted for the duration of the HTTP session between the remote client and that application. Card holder authorization is granted on per HTTP session and per application basis. When during the same interaction session between the remote client and the card, the remote client access another web application that requires card holder authorization, the authorization MUST be checked for that new application.
The platform MUST reject web applications that require card holder authorization and that map a card holder authorization role name to an authenticator URI that is not in the card-holder-user authenticator namespace. Mapping of roles other than card-holder-authorization roles to card holder authenticators is allowed in remotely accessible application but active authentication in these roles using these card holder identities MUST only be allowed when accessed from trusted-card-holder-facing terminal.
TABLE 6-6 summarizes the role-to-user mapping that must be supported (or rejected by the platform) for both locally accessible applications and remotely accessible applications depending on the role (card holder authorization role or other role), the type of user identity to which that role is mapped.
When a user attempts to access a web application’s resource, the container MUST proceed as follows:
1. If the web client is a trusted card holder facing client, the container MUST proceed with the regular checking of user authorization as per the process described in Section 6.4.5.1, Container Checking of User Authorization.
2. If the web client is not a trusted card holder facing client, the container MUST proceed as follows:
a. If the session was already authorized by the card holder, the container MUST proceed with the regular checking of user authorization as per the process described in Section 6.4.5.1, Container Checking of User Authorization.
b. If the session was not already authorized by the card holder and if the application's Java Card Platform-specific descriptor contains a card-holder-authorization element with one or more role-name sub-elements designating role names, then for each of the card-holder-users these roles are mapped to, the container MUST proceed as follows:
i. The container MUST locate the card-holder-user authenticator. If the container fails to locate the authenticator, the card-holder-user MUST be skipped.
ii. If the card-holder-user is already authenticated as per a call to the authenticator’s Authenticator.isValidated method, the container MUST grant the access for the duration of the HTTP session with this web application and the container MUST proceed with the regular checking of user authorization as per the process described in Section 6.4.5.1, Container Checking of User Authorization.
iii. If none of the card-holder-users the roles are mapped to are already authenticated, then the request MUST be rejected as forbidden and a 403 status code MUST be returned.
c. If the application's Java Card Platform-specific descriptor does not contain a card-holder-authorization element or if it has no role-name sub-elements, then the request MUST be rejected as forbidden and a 403 status code MUST be returned.
Client application authentication is the process by which a client application proves its identity to a server application. This authenticated identity is then used by the server application to perform authorization decisions for accessing protected resources, such as SIO-based and event-based services it exposes.
A server application may initiate and check authentication of a client application programmatically by invoking the client role-based security API described in Section 6.3.2.1, Programmatic Client Role-based Security, and passing a client security role name that has been mapped to credential aliases, designating the credentials of authorized application clients.
Client application authentication is tracked on a per-server application basis. That is a client application may authenticate with several different server applications and the authentication of the client application with each of these server applications must be tracked independently.
The Java Card RE implementation MUST support tracking the state of client application authentication on a per-server application basis.
When a server application invokes the JCSystem.isClientInRole method with a role name argument that has been mapped to one or several credential aliases, and with the URI of the protected resource the client application is requesting access to, the Java Card RE MUST proceed as follows:
1. The CredentialManager instance applicable to the server application for the mode MODE_SIO_SERVER is retrieved, see Section 6.6.2, Retrieving Security Requirements and Credential Managers For Establishing Connections.
2. The CredentialManager instance applicable to the client application for the mode MODE_SIO_CLIENT is retrieved, see Section 6.6.2, Retrieving Security Requirements and Credential Managers For Establishing Connections.
3. The server’s CredentialManager instance getTrustedCredentials method is invoked with the list of credential aliases to which the client security role is mapped and with the URI of the protected resource the client application is requesting access to.
4. The client’s CredentialManager instance getCredentials method is invoked with the list of credential types requested by the server and with the URI of the protected resource the client application is requesting access to.
5. The server’s trusted client credentials and the client’s credentials are checked two-by-two, according to their respective pairing property[15], using a challenge-response authentication algorithm until a matching pair is found.
The Java Card RE MUST use a cryptographic challenge-response authentication algorithm with randomly generated challenges to authenticate the client application with the server application using the retrieved server application’s trusted client credentials and client application’s credentials.
This process MUST execute within the Java Card RE context and the ownership of the credential objects MUST be retained by their original owner at all times.
FIGURE 6-5 depicts the interaction between the different components and actors of on-card client application authentication. Objects colors indicate common ownership of interacting objects. The colors of focus of control boxes[16] indicate the currently active contexts as the results of specific calls.
FIGURE 6-5 On-card Client Application Authentication (Sequence Diagram)
The authentication status of a client application with a server application is valid for the duration of the authentication session. The duration of authentication session may be of one of the following types:
The type of the authentication session duration MUST be set in the runtime descriptor of the application, either globally for all of its client security roles or individually for each of its client security roles, see On-Card-Clients-Credential-Auth-Duration Attribute in Chapter 8. The choice of the type of the authentication session duration may depend on the sensitivity of the security role, as well as on whether a client application’s or server application’s credentials are managed dynamically (may be changed during their lifetime) or not.
On the Java Card Platform, applications may interact with on-card or off-card peers through the following secure communications:
The security characteristics of a secure communication depend on the type of connection:
The security requirements - meaning the required security characteristics - for a particular secure communication being established, by either an application or by the web container on behalf of a web application, MUST be retrieved from settings that MUST be either specific to that application or common to all applications in the same group context. Similarly, the management of the credentials and trust decisions required to establish the secure communication MUST be delegated to a credential manager that MUST be either specific to that application or common to all applications in the same group context.
Application developers may configure the security requirements for secure communication with peers. The security requirements for a secure communication may cover the followings:
Security requirements are encapsulated by an instance of the javacardx.security.CredentialManager.SecurityRequirements class.
Application developers may use a credential manager to manage the credentials used to establish secure communication with peers. A credential manager is used both for managing the key material which is used to authenticate with peers and for managing the trust material that is used when making trust decisions such as deciding whether credentials presented by a peer should be accepted. A credential manager addresses the following requirements:
A credential manager is encapsulated by an instance of the javacardx.security.CredentialManager class.
Credential managers and security requirements may be assigned as follows:
Setting and getting of credential managers by applications MUST be subject to access control. When the CredentialManager.setCredentialManager and CredentialManager.getCredentialManager methods are invoked, a security check MUST ensure that the permission javacardx.framework.JCRuntimePermission with the target name credentialManager.set and credentialManager.get, respectively, is granted.
Note that setting and getting of security requirements by applications is not subject to access control.
Retrieving the card manager-assigned credential manager and security requirements of an application from its group context MUST be protected by package access control builtin checks as described in Section 6.8.1, Built-in Checks and MUST be restricted to card management applications. Retrieving the card manager-assigned credential manager and security requirements of an application from its group context MUST additionally be subject to access control: a security check MUST ensure that the permission javacardx.spi.cardmgmt.CardManagementPermission with the target name credentialManager.get is granted.
The security requirements and the credential manager retrieved for establishing a secure communication MUST be the ones set for the corresponding type and mode of communication:
When a security requirements or credential manager instance has been set for a mode of communication by an application, it MUST be retrieved in priority to the instance set in the group context by the card manager application when establishing a secure communication in that mode for that application. That is the security requirements or credential manager set by the application overrides the security requirements or credential manager set by the card manager application:
If no applicable credential manager instance can be retrieved, the secure communication MUST fail.
If no applicable security requirements can be retrieved, the security requirements MUST default to false, meaning there is no specific requirement, unless the application is a web application and the mode of communication is CredentialManager.MODE_WEB_SERVER, in which case the security requirements MUST correspond to the requirement for client authentication and the overall requirements for content integrity and confidentiality of the web application as declared in its runtime descriptor and deployment descriptor, respectively. See Section 3.5.3, Retrieving a Web Application Instance’s Security Requirements and Credentials.
FIGURE 6-6 depicts the assignment of security requirements or credential manager instances by the card manager and application instances, and the order in which they are retrieved.
FIGURE 6-6 Security Requirements and Credential Manager Assignment and Lookup Order
The SecurityRequirements and CredentialManager class defines the following methods
See the API specification for a detailed description of these methods.
A Java Card Platform implementation MUST NOT cache credentials or trust decisions returned or performed by credential managers.
For secure network communications, the security requirements and credential manager instance MUST be retrieved for each SSL/TLS handshake. The same security requirements and credential manager instance MUST be used throughout a SSL/TLS communication session, such as when required for SSL/TLS re-handshake.
In the case of inter-application SIO-based communications, the credential manager instance MUST be retrieved for each on-card client authentication according to the authentication session duration, see Section 6.5.2, Authentication Session Duration.
The callers of the SecurityRequirements and CredentialManager methods, the SSL/TLS protocol handler or the Java Card RE itself, MUST invoke these methods with at least the following mandatory parameters:
TABLE 6-7 describes the endpoint URI formats that MUST be used in conjunction with the different modes of operation.
FIGURE 6-7 illustrates the invocation sequence of CredentialManager methods during a TLS Handshake with asymmetric, or public key, cryptography authentication. See RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 for details on the TLS Handshake Protocol.
FIGURE 6-7 Invocation of CredentialManager Methods During a TLS Handshake with Asymmetric, or Public Key, Cryptography Authentication
FIGURE 6-8 illustrates the invocation sequence of CredentialManager methods during a TLS Handshake with symmetric, or pre-shared secret key, cryptography authentication. See RFC 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) for details on the TLS Handshake Protocol.
FIGURE 6-8 Invocation of CredentialManager Methods During a TLS Handshake with Symmetric, or Pre-shared Secret Key, Cryptography Authentication
Code isolation ensures that code loaded from one application does not interfere with code of other applications. Code loaded in this manner cannot override or directly access code of other applications. This is implemented by defining and enforcing different class namespaces for each loaded application code.
On the Java Card Platform, code isolation MUST be implemented with a class loader delegation hierarchy, which enforces isolation of application code by default and allows for explicitly sharing code such as libraries and public interfaces between cooperating applications.
In order to enforce separate code isolation spaces (or class namespaces) for applications while still allowing them to communicate, the class loader delegation hierarchy MUST ensure the following:
Every class loader with the exception of the bootstrap class loader MUST have one and only one parent class loader. The class loader delegation hierarchy MUST be laid out as follows:
The class loader delegation hierarchy MAY be enhanced with application framework class loaders in order to load standard bodies-defined framework libraries:
FIGURE 6-9 Class Loader Delegation Hierarchy
The class loading on the Java Card Platform MUST address the following requirements:
To address these requirements, the class loading delegation MUST be implemented as follows:
1. When a loaded class references a class type and that reference must be resolved, the class loader of the loaded class MUST be requested to load the new class.
2. When the java.lang.Class.forName method is called to dynamically load a class, the class loader to be requested to load the class MUST be the defining class loader of the calling class.
3. When the java.util.ResourceBundle.getBundle method is called to dynamically load a subclass of ResourceBundle, the class loader to be requested to load the class MUST be the defining class loader of the calling class.
4. If a class loader is requested to load a class and, if the class has not already been loaded by that class loader, the class loader MUST first delegate to its parent class loader (unless it is the bootstrap class loader).
5. If a class cannot be loaded by its parent class loader, a class loader MUST attempt to locate the class file and define the class itself (convert it from its binary representation into an instance of java.lang.Class).
6. The same class MUST NOT be loaded more than once by the same class loader.
7. If a class cannot be loaded by a class loader a ClassNotFoundException MUST be thrown.
As a consequence, a class may be loaded by a class loader (its defining class loader) which may be different from the class loader (its initiating class loader) initially invoked to load the class. The defining class loader is either the initiating class loader or a parent of the initiating class loader. Since a class is uniquely identified by its name and its defining class loader, two classes are deemed the same (equals) if they have the same name and have the same defining class loader. Each class loader thereby defines a separate class namespace.
The Class instance internally created by the Virtual Machine to represent an array class MUST be assigned the defining class loader of its component type. If the array is an array of primitive types, the defining class loader of the array class MUST correspond to the bootstrap class loader.
The class loader delegation hierarchy MUST NOT be exposed to application developers, and especially, there MUST NOT be support for user-defined class loaders.
Class-path resources designate those resources that are packaged along with classes and that can be accessed using the getResourceAsStream method of the java.lang.Class class[17].
Lookup of class-path resources MUST be performed by class loaders in the class loader delegation hierarchy according to the same delegation principle as that of class loading with the only restriction that Java Card RE system resources MUST not be accessible to applications or libraries. The class-path resource lookup delegation MUST be implemented as follows:
1. When the getResourceAsStream method is invoked on a Class instance, the class loader of that class MUST first delegate to its parent class loader (unless the parent is the bootstrap classloader[18]).
2. If the named resource cannot be located by its parent class loader, a class loader MUST attempt to locate the resource itself among the resources it loaded. The extension library class loader or a group library class loader MUST look up a resource in the libraries it loaded in the exact same order as these libraries were loaded (meaning, starting from the first loaded library).
3. If a resource cannot be found by a class loader, null MUST be returned.
As a result, the “visibility” of class-path resources is identical to that of classes, as described in the preamble of Section 6.7.1, Class Loader Delegation Hierarchy, with the exception that Java Card RE system resources are not visible to libraries and applications.
The Java Card Platform provides different complementary mechanisms to control the definition and access to classes in packages.
To be allowed to define a new class in a package, all of the following MUST NOT fail:
The Java Card Platform MUST prevent loaded code, applications or libraries, from overriding or extending the set of the system classes provided in the following packages and sub-packages thereof:
A Java Card Platform implementation MUST ensure that application or library developers cannot override, modify, or add any classes to these protected system packages. An attempt by a class loader other than the bootstrap class loader to define a class in one of these protected system packages MUST result in a SecurityException being thrown.
The Java Card Platform MUST prevent an extended applet or web application’s code from overriding or extending the set of classes in packages initially defined by extension libraries. An attempt by a class loader other than the extension library class loader to define a class in a package initially defined by an extension library MUST result in a SecurityException being thrown.
The Java Card Platform MUST prevent a classic applet application’s code from overriding or extending the set of classes in packages initially defined by classic libraries. An attempt by a class loader other than the classic library class loader to define a class in a package initially defined by a classic library MUST result in a SecurityException being thrown.
The Java Card Platform MUST prevent loaded code, applications or libraries, other than resident libraries and card management applications from accessing (linking) directly with system classes provided in the following packages and sub-packages thereof:
The Java Card Platform MUST support the JAR file package sealing mechanism. A package sealed within a JAR file specifies that all classes defined in that package MUST originate from the same JAR file. Otherwise, a SecurityException MUST be thrown.
A package may be sealed according to the optional Sealed attribute in the JAR Manifest file, defined for that package or defined by default for all packages in the JAR file. After a class loader loads a class from a sealed JAR file, classes in the same package can only be loaded from that JAR file.
The use of the Class.forName method by application code to dynamically load classes MUST be restricted. Only the classes declared in the Java Card Platform-specific descriptor of an application MUST be allowed to be dynamically loaded by that application, see dynamically-loaded-classes Element in Chapter 8.
An application module class loader MUST implement the following security check: an attempt to dynamically load a class that is not declared in the Java Card Platform-specific descriptor of the application module loaded by that application module class loader MUST result in a SecurityException being thrown.
A group-library class loader MUST implement the following security check: an attempt to dynamically load a class that is not declared in the Java Card Platform-specific descriptor of any of the application modules loaded by one of its child application module class loader MUST result in a SecurityException being thrown.
This restriction MUST NOT apply to extension library code. The extension library class loader MUST allow for unrestricted use of the Class.forName method to dynamically load classes from other extension libraries or allowed system libraries.
This section describes the enhancements to the basic firewall-enforced context isolation mechanism on the Java Card Platform, Connected Edition:
Refer to Section 2.4, Context Isolation Basics for details on the basic firewall-enforced context isolation mechanism.
Before performing a context switch to another group context or to the Java Card RE context, the Java Card RE enforces security checks based on the protection domain of the currently active context, meaning the application requesting the context switch. See Section 6.2.5.2, Context-switch-triggered Security Checks.
An application URI defines the root of a dedicated namespace within which all its resources are named. All resources of an application are named relatively to that application’s URI, see Section 2.3.2, Dedicated Application Namespaces.
Additionally, each thread of control maintains distinct active context and active namespace references. See Section 2.7.2.2, Per-Thread Active Context and Active Namespace.
The Java Card Platform MUST enforce the separation of application namespaces as follows:
The basic firewall-enforced context isolation mechanism (see Section 2.4, Context Isolation Basics) is enhanced with the object ownership transfer mechanism. This mechanism allows an application to transfer the ownership of objects it owns to applications in other contexts. See Section 7.2, Object Ownership Transfer Mechanism for more details on the ownership transfer mechanism.
In order to facilitate application instance deletion and to prevent dependencies on simple objects referenced by static fields of shared classes from blocking the deletion of the application instance that owns these objects, instances of explicitly transferable object classes, namely arrays and String objects, MUST be owned by the group context of the application that created them, not by the application itself. That is, such objects are not bound to any owner context but solely to a group context. Similarly, when transferred using the transfer of ownership mechanism, these objects are owned by the group context of the targeted recipient. Note that implicitly transferable objects are not bound to any context (group contexts or Java Card RE context) and, therefore, do not interfere with application instance deletion.
When an explicitly transferable object is transferred from one owner context to another, the object is bound to the new owner context and any object created subsequently by the transferred objects MUST be bound to the same owner context as the transferred object’s.
Implicitly transferable objects are not bound to any context (group contexts or Java Card RE context). Any object created and returned by an implicitly transferable object as a result of a call from an object bound to an owner context MUST be bound to that same owner context. For example, a call to an interned String object’s substring method must return a String object bound to the owner context of the caller. The only exception is the String.intern method, which returns a canonical representation for the String object that is not bound to any context (group context or Java Card RE context). See Section 2.7.2.2, Per-Thread Active Context and Active Namespace.
An implicitly transferable object MUST NOT hold in its state any reference to objects it created as a result of a call from an object bound to an owner context as this will break the immutability principle of such objects and prevent safe sharing.
5 (Footnote) Checking of permissions must account for permissions spanning the platform protection domain’s set of included permissions and the set of permissions added to the application protection domain, as per the card management security policy in effect.
| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition | 5-30-09 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.