This section describes the runtime environment notes for the Symbian implementation.
The following system property is defined to indicate the names of the smartcard slots:
String |
Description |
|---|---|
|
The value returned is a comma-separated list of the smartcard slots that can be combined with the URI prefix apdu: to identify the specific smartcard slot. If the platform includes a (U)SIM card, it must be in slot 0. The logical slot names include the slot number and a descriptor indicating the type of the slot. For cold-swappable slots the letter ’C’ is appended to the slot number. For hot-swappable slots the letter ’H’ is appended to the slot number. An example of hot-swappable card is a memory card that can be inserted and removed while the phone is in operation. A typical configuration for a cold-swappable SIM would be:
|
The Security and Trust Services API security model implemented in Java Platform for Symbian is based on MIDP 2.1 Recommended Security Policy, MSA specification, security policy of the JTWI specification, and Appendix B, Security Permissions of The Security and Trust Services API for J2ME, Version 1.0 (JSR-177). The table below lists the access rights of MIDlets belonging to different MIDP access domains.
Category |
Manufacturer |
Operator |
Trusted third-party |
Untrusted |
|---|---|---|---|---|
Digital Signature Service |
Yes |
Yes |
Yes |
No |
Smart Card Communication |
Yes |
Yes |
Yes |
No |
The APDU functionality gives low-level access to smart cards. An Access Control File (ACF) located in the smart card file system defines which APDU commands are allowed for an application.
It is recommended that you locate the ACF files in the pkcs#15 or WIM application and use a relative path in the ACIF. If an absolute path is used in the ACIF, the ACF must be readable on all logical channels; otherwise, the terminal might not be able to access the ACF.
The Security and Trust Services API implementations
in Java Platform for Symbian allow users to accept MIDlet access rights
by using the function group Authentication. This function group is
defined in Appendix B of The Security and Trust Services API
for J2ME, Version 1.0 (JSR-177). It represents the permission
to the authenticate( byte[] byteArrayToAuthenticate, ...) method.
For Identified Third Party Protection Domain and
Unidentified Third Party Protection Domain MIDlets, the user settings
are defined according to the table below. In the Unidentified Third
Party Protection Domain, the Authentication group is not visible in
the device UI, as No is the only allowed setting.
Function |
Identified Third Party Protection Domain |
Unidentified Third Party Protection Domain |
|---|---|---|
Authentication |
Default setting: Session Allowed settings: Session, Blanket, Oneshot, No |
Default setting: No Allowed settings: No |
Explanations for the table values are as follows:
“Blanket” is valid for every invocation of an API by a MIDlet suite until it is uninstalled or the permission is changed by the user.
“Session” is valid from the invocation of a MIDlet suite until it terminates. “Session” mode MUST prompt the user on or before the first invocation of the API or function, which is protected. When the user re-invokes the MIDlet suite the prompt MUST be repeated.
“No” means that the MIDlet can’t access the protected function at all.
"Oneshot" means that the permission is asked every time the resource is needed.
The following table describes the security policy for the APDU API-related function group: