|
This SIM Access Profile defines the protocols and
procedures that shall be used to access a SIM card via a Bluetooth link.
The profile enables the usage model "Personalizing the Car and its
Devices" (see [5]) and similar usage models, which involve a
Bluetooth enabled SIM card holder and a cellular phone.
For example, with this profile, the user can
personalize his/her car-embedded phone with a SIM card in an external
device, which is connected via a Bluetooth wireless link. The external
device can either be a simple SIM card holder or a portable phone, which
is brought into the car.
For more details : Download the SIM Profile from the Bluetooth.org
website.
The figure below shows the protocols and entities
used in this profile.
Image reprinted from Bluetooth SIM Profile, Figure
2.1 , page 13
The Baseband, LMP and L2CAP are the OSI layer 1 and
2 Bluetooth protocols. RFCOMM is the Bluetooth serial port emulation
entity. SDP is the Bluetooth Service Discovery Protocol.
The following two roles are defined for this profile:
- The SIM Access Server has direct (galvanic) access to a
SIM. It acts as a SIM card reader, which assists the Client in accessing
and controlling the SIM via the Bluetooth link.
Client - The SIM Access Client is connected via a Bluetooth link
to the SIM Access Server. The Client accesses and controls the SIM inside
the Server via the Bluetooth link.
Typical examples of a Server are a simple SIM card
holder or a portable phone in the car environment. A typical example of a
Client is a car phone, which uses a SIM card in the Server for a
connection to the cellular network.
In general, the SIM Access Server functions as a SIM
reader for the SIM Access Client. The SIM Access Profile enables all
scenarios, that are also possible with wired SIM card readers.
Two scenarios are depicted here, as they serve as
building blocks for other scenarios. Both scenarios will be referenced
throughout the document.
- The Server contains a SIM, which is used by the Client: The
Client accesses the files and services of the SIM as if the SIM was
directly contained in the Client or connected via a cable.
- Proactive SIM in the Client and Additional SIM in the
Server:
The Client contains a proactive SIM for connecting to the cellular
network. Furthermore, the proactive SIM may request the Client to
control the additional SIM, which is located in the Server. For this
purpose the SIM Access Profile provides the necessary means to perform
all functions.
The SIM Access Profile describes the messages and
procedures for accessing a SIM card over a Bluetooth link. It is
especially designed for usage with GSM SIM cards and provides a transport
and remote control solution for GSM 11.11 and GSM 11.14 .
The SIM Access Server contains a SIM and is
responsible for establishing and maintaining the physical connection to
the SIM. The Server also acts a mediator for all messages (APDUs)
exchanged between the SIM Access Client and the SIM. Furthermore, if the
Client requests information from the Server about the SIM or about the
Server itself, the Server will respond by sending the requested data over
the Bluetooth link.
The Client is in most cases a phone, which has to
behave according to the relevant GSM specifications. This behaviour is
fully supported by the SIM Access Profile, by providing the necessary
framework.
The Server might also be a phone, which apart from
the SIM Access Profile functionality has the ability to use the SIM for
its own cellular network connection. According to the GSM specifications,
this is only allowed, if the Server is outside of a SIM Access Profile
connection.
In general, the Server may establish a SIM Access
Profile connection, even if there is no SIM in the Server. Similarly, the
Server may establish a connection, even if its SIM is powered off. In
order to handle these different situations, the Client shall be informed
about the status of the SIM during connection setup). The application of
the profile is limited to one Server, which establishes a SIM Access
Profile connection to one Client. Similarly, the Server shall only grant
the Client access to a single SIM in the context of this profile.
In order to ensure secure communication between
Client and Server, several security measures from the Bluetooth
specification are mandatory:
- Bonding
- Encryption
- Server initiated Authentication
- Link Keys: Only combination keys shall be used for SIM Access
Profile connections.
- Encryption key length: The encryption key deployed in
the system shall support the maximum length as given in the Bluetooth
specification.
- Passkey: The length of the passkey shall be 16 digits
(decimal) at least.
The table below shows the feature requirements made
by this profile.
Image reprinted from Bluetooth SIM Profile, Table 1
, page 18
This chapter describes the procedures for all
features listed in the previous chapter. Each procedure consists of one or
more messages that are exchanged between the SIM Access Client and Server.
In order to start the SIM Access Profile connection
and negotiate important parameters adherent to the connection, the
messages CONNECT_REQ, CONNECT_RESP, STATUS_IND, TRANSFER_ATR_REQ and
TRANSFER_ATR_RESP are used.
If the Client wants to release the SIM Access
Profile connection, it first shall terminate any existing GSM session
which involves the SIM in the Server. The Client can then send a
DISCONNECT_REQ message to the Server. The Server will answer with a
DISCONNECT_RESP message and the SIM Access Profile is successfully
released.
If the Server wants to release the SIM Access
Profile connection, it shall send the DISCONNECT_IND message to the
Client. Within this message the Server can indicate, if it wants to
release the SIM Access Profile connection immediately or gracefully.
For transferring an APDU between the Client and the
Server, the messages TRANSFER_APDU_ REQ and TRANSFER_APDU _RESP are used.
ADPU transfers are always initiated by the Client.
The Client may ask the Server to send the ATR from the SIM. The
TRANSFER_ATR_REQ message is used for this purpose. Following this request,
the Server sends the ATR to the Client in the payload of the
TRANSFER_ATR_RESP message.
If the Client wants the Server to power off the SIM, it
first shall terminate any existing GSM session which involves the SIM in
the Server. The Client can then send the POWER_SIM_OFF_REQ message to the
Server. Upon receiving this message, the Server powers off the SIM, i. e.
it removes the voltage from the card. Afterwards, the Server sends the
POWER_SIM_OFF_RESP message to the Client.
If a SIM is powered off, the Client may request the Server
to power it on again, i. e. to apply the supply voltage and clock signal
to the SIM. The POWER_SIM_ON_REQ message is used for this purpose.
If the Client wants the Server to reset the SIM, it
first shall terminate any existing GSM session, which involves the SIM in
the Server. The Client can then send the RESET_SIM_REQ message to the
Server.
Upon receiving this message, the Server resets the
SIM and eventually performs a PPS procedure. After this has been
completed, the Server sends the RESET_SIM_RESP message to the Client.
If the RESET_SIM_RESP message indicates that the SIM
was reset on successfully, the Client shall request the ATR of the SIM
with the TRANSFER_ATR_REQ message. The Server will then answer with the
TRANSFER_ATR_RESP message.
This procedure is deployed during the connection
setup phase or whenever a change in the physical connection between Server
and SIM occurs. The STATUS_IND message is used to inform the Client about
the status or the status change.
The Client may ask the Server to return the Card
Reader Status using the TRANSFER_CARD_READER_STATUS_REQ message. Following
this request, the Server sends the Client the Card Reader Status in the
TRANSFER_CARD_READER_STATUS_RESP message.
The Server sends an Error Response message
ERROR_RESP to the Client, whenever it has received a request message from
the Client, which was invalid or improperly formatted.
The state machine below shows the simplified state
machine underlying the SIM Access Profile. The three main states are
"Not connected", "Connection under negotiation" and
"Connected". Within the "Connected" state, several
sub-states exist.
Image reprinted from Bluetooth SIM Profile, Figure
4-12 , page 33
As it can be seen from the state machine, each
request message (e. g. TRANSFER_APDU_REQ) can in general only be followed
by the corresponding response message (TRANSFER_APDU_RESP). However, there
are two exceptions. The POWER_SIM_OFF_REQ and RESET_SIM_REQ can be sent in
nearly any state, in order to allow the Client to reactivate a not
accessible SIM card.
A Bluetooth link loss can be detected by the Server
or the Client. Whenever either device detects a Bluetooth link loss, the
SIM Access Profile connection is automatically terminated.
This section describes the coding and formats of the
messages and parameters of the SIM Access Profile. The SIM Access Profile
messages are transported on an RFCOMM link.
Message are formatted as shown below (length of each field is
given in bytes):
Image reprinted from Bluetooth SIM Profile, Figure
5.1 , page 35
The message header consists of three fields. The
field "MsgID" contains the message ID. The field "Number of
Parameters" gives the number of parameters in the payload of the
message. Two bytes are reserved for future use and shall be set to 0x0000
until otherwise specified in future revisions of the SIM Access Profile,
while the payload itself contains the parameters as listed below.
Image reprinted from Bluetooth SIM Profile, table 3
, page 36
See section 6 of the SIM Access Profile to see all
entries in the SDP database of the SIM Access Server. In the status column
it is indicated whether the presence of this field is mandatory or
optional.
This profile requires compliance with the Serial
Port Profile. For the purpose of reading the Serial Port Profile, the
SIM Access Client shall always be considered to be Device A (the
"initiator") and the SIM Access Server shall always be
considered to be Device B (the "acceptor").
- For the RFCOMM , L2CAP & LC layer, no additions to the
requirements as stated in the Serial Port Profile shall apply
- In addition to the LM Interoperability Requirements stated in the
Serial Port Profile, this profile mandates the use of link encryption.
- For the SDP layer, a number of service records are defined for the
headset and the audio gateway respectively. They can be found on page
211 of the Headset Profile
This profile requires compliance with the Generic
Access Profile , see section 8.1, 8.2 & 8.3 of the SIM profile to
see the support status for Modes, Security aspects & Idle Mode
procedures within the SIM Access Profile.
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
