This section describes the runtime environment notes for the Series 40 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:
|
|
|
Version of the SATSA-APDU API supported by the device. |
|
|
Version of the SATSA-CRYPTO API supported by the device. |
|
|
Version of the SATSA-PKI API supported by the device. |
The 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.
In the Series 40 implementation, 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 following table describes the security policy for the API-related function group:
|
Function |
Identified 3rd Party domain |
Unidentified 3rd party domain |
Manufacturer domain |
Operator domain |
|---|---|---|---|---|
|
Smart Card Communication |
Default = Ask first time Other settings = Always allowed, Not allowed |
Default = Not Allowed Other settings = Not allowed |
Always allowed |
Always allowed |
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.