This section describes the runtime environment notes for the S60 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 S60 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 S60 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: