Fortuning Goods
Fortuning Goods
Fortuning Goods
Use of this document is subject to all of the terms and conditions of the Use Agreement located at
http://www.openmobilealliance.org/UseAgreement.html.
Unless this document is clearly designated as an approved specification, this document is a work in process, is not an
approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice.
You may use this document or any part of the document for internal or educational purposes only, provided you do not
modify, edit or take out of context the information in this document in any manner. Information contained in this document
may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior
written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided
that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials
and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products
or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.
Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely
manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification.
However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available
to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at
http://www.openmobilealliance.org/ipr.html. The Open Mobile Alliance has not conducted an independent IPR review of
this document and the information contained herein, and makes no representations or warranties regarding third party IPR,
including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you
must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in
the schedule to the Open Mobile Alliance Application Form.
THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT,
PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN
CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.
Contents
1. SCOPE ................................................................................................................................................................................5
2. REFERENCES ..................................................................................................................................................................6
2.1 NORMATIVE REFERENCES ..........................................................................................................................................6
2.2 INFORMATIVE REFERENCES .......................................................................................................................................6
3. TERMINOLOGY AND CONVENTIONS ......................................................................................................................7
3.1 CONVENTIONS .............................................................................................................................................................7
3.2 DEFINITIONS................................................................................................................................................................7
3.3 ABBREVIATIONS ..........................................................................................................................................................9
4. INTRODUCTION ...........................................................................................................................................................11
5. ARCHITECTURE...........................................................................................................................................................12
5.1 CONFIGURATION CONCEPT ......................................................................................................................................12
5.2 SUPPORT OF WAP PROVISIONING ON TELECOM SMART CARDS PLATFORMS.........................................................12
5.2.1 Generic Behaviour .............................................................................................................................................12
6. WAP PROVISIONING SMART CARD .......................................................................................................................14
6.1 OBJECT DIRECTORY FILE, EF (ODF)......................................................................................................................14
6.2 PROVISIONING DATA OBJECT DIRECTORY FILE, EF (DODF-PROV) .....................................................................14
7. WAP PROVISIONING DATA ON WIM ICC .............................................................................................................16
7.1 WAP PROVISIONING DATA ON WIM APPLICATION .................................................................................................16
7.1.1 Introduction........................................................................................................................................................16
7.1.2 Access to the WAP Provisioning file structure..................................................................................................16
7.1.3 File Overview ....................................................................................................................................................16
7.1.4 Access method ...................................................................................................................................................16
7.1.5 Access Conditions..............................................................................................................................................17
8. WAP PROVISIONING DATA ON WIM-LESS TELECOM SMART CARD .........................................................18
8.1 INTRODUCTION..........................................................................................................................................................18
8.2 WAP PROVISIONING DATA ON SIM OR UICC ACTIVATED IN 2G MODE ................................................................18
8.2.1 Access to the WAP Provisioning file structure..................................................................................................18
8.2.2 Files Overview...................................................................................................................................................18
8.2.3 Access Method...................................................................................................................................................19
8.2.4 Access Conditions..............................................................................................................................................19
8.3 WAP PROVISIONING DATA ON UICC ACTIVATED IN 3G MODE ..............................................................................19
8.3.1 Access to the WAP Provisioning file structure..................................................................................................19
8.3.2 Access Method...................................................................................................................................................20
8.3.3 Access Conditions..............................................................................................................................................20
9. FILES DESCRIPTION ...................................................................................................................................................21
9.1 EF ODF .....................................................................................................................................................................21
9.2 EF CDF .....................................................................................................................................................................21
9.3 EF DODF-PROV ........................................................................................................................................................22
9.4 EF BOOTSTRAP .........................................................................................................................................................22
9.5 EF CONFIG1 ..............................................................................................................................................................23
9.6 EF CONFIG2 ..............................................................................................................................................................24
9.7 EF TRUSTED CERTIFICATES.....................................................................................................................................24
10. REQUIREMENTS FOR THE ME ............................................................................................................................26
10.1 REQUIREMENTS ON THE WIM ON SMART CARD ......................................................................................................26
10.2 REQUIREMENTS ON THE SIM OR 2G UICC.............................................................................................................26
10.3 REQUIREMENTS ON THE 3G UICC...........................................................................................................................26
CHANGE HISTORY (INFORMATIVE) ..........................................................................................................................28
A.1 APPROVED VERSION HISTORY .................................................................................................................................28
A.2 DRAFT/CANDIDATE VERSION 1.2 HISTORY .............................................................................................................28
1. Scope
Open Mobile Alliance (OMA) Wireless Application Protocol (WAP) is a result of continuous work to define an industry-
wide specification for developing applications that operate over wireless communication networks. The Open Mobile
Alliance continues the work of the WAP Forum to define a set of specifications to be used by service applications. For
information on the WAP architecture, please refer to “Wireless Application Protocol Architecture Specification”
[WAPARCH].
This document defines the information format and the access methods of WAP provisioning data present on smart cards used
for wireless telecom applications. A particular case is when a WIM application is already present on such smart card type.
Provisioning WAP connectivity data on a smart card with SIM, USIM or WIM application will have advantages (i.e. pre-
provisioning of personalised data during manufacturing, portability, controlled access to sensitive data like login/passwords
etc.)
2. References
2.1 Normative References
[CREQ] “Specification of WAP Conformance Requirements”, WAP forum , WAP-221-CREQ,
URL:http://www.openmobilealliance.org/
[RFC2119] “Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. March 1997.
URL:http://www.ietf.org/rfc/rfc2119.txt
[ISO7816-4] ISO/IEC 7816-4 (1995): "Information technology - Identification cards - Integrated circuit(s)
cards with contacts - Part 4: Inter-industry commands for interchange".
[ISO7816-5] ISO/IEC 7816-5 (1994): "Identification cards - Integrated circuit(s) cards with contacts - Part 5:
Numbering system and registration procedure for application identifiers".
[PKCS#15] PKCS #15 v1.1: Cryptographic Token Information Syntax Standard”, RSA Laboratories, June 6,
2000. URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs-15v1_1.pdf
[PROVCONT] “Provisioning content specification 1.1”, Open Mobile Alliance ,
OMA-WAP-ProvCont-v1.1, URL: http://www.openmobilealliance.org/
[WIM] “Wireless Identity Module Specification”, Open Mobile Alliance ,
OMA-WAP-WIM-v1_1, URL: http://www.openmobilealliance.org/
[TS51 011] Specification of the Subscriber Identity Module – Mobile equipment (SIM-ME) interface. (ETSI
TS 51 011, R5), URL: http://www.3gpp.org
[TS102 221] Smart Cards; UICC-Terminal interface; Physical and logical characteristics (ETSI TS 102 221,
R4), URL: http://www.3gpp.org
All sections and appendixes, except “Scope” and “Introduction”, are normative, unless they are explicitly indicated to be
informative.
3.2 Definitions
Access conditions A set of security attributes associated with a file.
AID - Application A data element that identifies an application in a smart card. An application identifier may
Identifier. contain a registered application provider number in which case it is a unique identification for
the application. If it contains no application provider number, then this identification may be
ambiguous.
ALW - Always Access condition indicating a given function is always accessible.
AODF - The ([PKCS#15], section 6.8) contain directories of authentication objects (e.g. PINs) known to the
Authentication Object PKCS#15 application.
Directory Files
Application The implementation of a well-defined and related set of functions that perform useful work on
behalf of the user. It may consist of software and or hardware elements and associated user
interfaces.
Application Some of the information provisioned into the phone can relate to identity and applications
Information rather than to plain connectivity.
ASN.1 object Abstract
Syntax Notation A formal syntax for describing complex data objects.
object as defined in
[ISO8824-1].
ATR - Answer-to- Stream of data sent from the smart card to the reader in response to a RESET condition.
Reset
BER - Basic Encoding Rules for encoding an ASN.1 object into a byte sequence.
Rules
Binary Files Binary Files are equivalent to transparent files as described in [TS51 011].
Cardholder The person or entity presenting a smart card for uses.
Card Issuer The organization or entity that owns and provides a smart card product.
CDF - Certificate ([PKCS#15], section 6.6) contain directories of certificates known to the PKCS#15 application.
Directory Files
CHV - CardHolder Also called the PIN. Typically a 4 to 8 digit number entered by the cardholder to verify that the
Verification cardholder is authorized to use the card.
Command A message sent by the ME to the smart card that initiates an action and solicits a response from
the smart card.
Connectivity The information in connectivity provisioning relates to the parameters and means needed to
Information access WAP infrastructure. This includes network bearers, protocols, access point addresses, as
well as proxy addresses and Trusted Provisioning Server URL.
DER - Distinguished Rules for encoding ASN.1 objects in byte-sequences. A special case of BER.
Encoding Rules
DF - Dedicated File A file containing access conditions and, optionally, Elementary Files (EFs) or other Dedicated
Files (DFs).
DODF - The Data Files containing directories of data objects (not keys or certificates) ([PKCS#15], section 6.7)
Object Directory Files known to the PKCS#15 application.
DODF-wim The Data Object Directory Files contain directories of data objects (not keys or certificates)
([PKCS#15], section 6.7) used in WTLS and TLS, known to the PKCS#15 application.
DODF-prov The Data Object Directory Files contain directories of data objects (not keys or certificates)
([PKCS#15], section 6.7) used in WAP provisioning and known to the PKCS#15 application.
EF - Elementary File A set of data units or records that share the same identifier. It cannot be a parent of another file.
FCP File Control Parameter
File identifier A 2-byte binary value used to address a file on a smart card.
Function A function contains a command and a response pair.
ICC - Integrated Another name for a smart card.
Circuit Card
MF - Master File Mandatory unique dedicated file representing the root of the structure. The MF typically has
the file identifier 0x3F00.
NEV An access condition indicating a given function is never accessible.
ODF - The mandatory ([PKCS#15], section 6.2) consists of pointers to other EFs (PrKDFs, PuKDFs, CDFs, DODFs
Object Directory File and AODFs), each one containing a directory over PKCS#15 objects of a particular class (here
and below, a “directory” means a list of objects).
Path Concatenation of file identifiers without delimitation. The Path type is defined in [ISO7816-4]
sub-clause 5.1.2. If the path starts with the MF identifier (0x3F00), it is an absolute path;
otherwise it is a relative path. A relative path must start with the identifier of the current DF (or
with the identifier '0x3FFF').
PIN Personal Identification Number. See CHV.
PrKDF - The Private ([PKCS#15], section 6.3) contain directories of private keys known to the PKCS#15
Key Directory Files application.
PuKDF - The Public Files ([PKCS#15], section 6.4) contain directories of public keys known to the PKCS#15
Key Directory Files application.
Record A string of bytes within an EF handled as a single entity.
Record number The number, which identifies a record within an EF.
Smart card A device with an embedded microprocessor chip. A smart card is used for storing data and
performing typically security related (cryptographic) operations. In WAP context, a smart card
may be the SIM, the UICC or a smart card used in a secondary smart card reader of a WAP
phone.
Trusted Proxy The trusted (provisioning) proxy has a special position as it acts as a front end to a trusted
provisioning server. The trusted proxy is responsible to protect the end-user from malicious
configuration information.
TPS - Trusted A source of provisioning information that can be trusted by a Configuration Context. They are
Provisioning Server the only entities that are allowed to provision the device with static configurations. In some
cases, however, a single TPS is the only server allowed to configure the phone. Provisioning
related to a specific TPS is restricted to Configuration Contexts that are associated with this
TPS.
UICC - Universal ICC UICC is the ICC defined for the 3G standard [TS102 221].
WIM - Wireless A tamper-resistant device that is used in performing WTLS and application level security
Identity Module functions, and especially, to store and process information needed for user identification and
authentication.
2G UICC UICC activated in a 2G mode that has physical characteristics of UICC [TS102 221] but logical
characteristics of SIM [TS51 011]
3G UICC UICC activated in a 3G mode that has physical and logical characteristics of the UICC [TS102
221]
3.3 Abbreviations
2G Second generation network i.e. GSM
3G Third generation network i.e. UMTS
ADF Application Dedicated File
AID Application Identifier
ALW Always
AODF Authentication Object Directory File
ASN Abstract Syntax Notation
ATR Answer-to-Reset
CDF Certificate Directory File
CHV CardHolder Verification
DER Distinguished Encoding Rules
DF Dedicated File
DIR Directory File
DNS Domain Name Server
DO Data Object
DODF Data Object Directory File
EF Elementary File
ETSI European Telecommunication Standardization Institute
IC Integrated Circuit
ICC Integrated Circuit(s) Card
ID Identifier
ISO International Organization for Standardization
ME Mobile Equipment
MF Master File
MMS Multimedia Messaging Service
ODF Object Directory File
OID Object Identifier
PIN Personal Identification Number
PIN-G General Personal Identification Number according to [WIM]
SC Smart Card
SIM Subscriber Identity Module
TPS Trusted Provisioning Server
UICC Universal Integrated Circuit(s) Card
WAP Wireless Application Protocol
WIM Wireless Identity Module
WTLS Wireless Transport Layer Security
4. Introduction
The WAP provisioning framework specifies mechanisms to provision devices with connectivity and application information.
The purpose of this document is to specify the implementation of WAP provisioning data on the smart card present in mobile
phones - e.g. SIM smart card – allowing pre-configuration of the devices and/or application access parameters.
Very few end users in a mass-market environment will be able (or interested) to perform proper set up of the various
connectivity and/or application access information e.g. access point, proxy, local DNS server, MMS proxy/relay. The mobile
network operator is now able to pre-configure the subscriber identity smart card with appropriate information so that the end
user when inserting the smart card into the device could get direct web browsing or e-mail access.
WAP provisioning framework defines that each bearer network has unique provisioning mechanisms, i.e. network specific
procedures to initiate the phone or in the case of deploying the Multimedia Messaging (MMS) application it would be
necessary to configure the MMS access specific parameters.
Usage of the smart card to provision the device (compared to an other the air provisioning mechanism) has several
advantages for the end user and the mobile network operator point of view; immediate device bootstrapping i.e. no remote
connection required for the bootstraping procedure– protected access and storage of user applicative authentification
information i.e. login and passwords – portability of provisioning information from one device to another one etc.
Mobile network operator can leverage on its actual subscriber identity module smart card deployement and distribution
network to, in addition, provide WAP pre-provisioned smart cards to its customer.
5. Architecture
A generic "WAP file system" solution is defined. It provides a very flexible framework that can be used to tailor the set-up to
the needs of the carrier and the user. It can be used both for basic configurations and for generic storage of persistent
information.
The information stored in the files Bootstrap, Config1 and Config2 is of type application/vnd.wap.connectivity-wbxml.
The files required to enable WAP provisioning storage on the Smart Card are the following:
• Bootstrap File: used to store connectivity and application information that cannot be changed by the provisioning agent,
i.e. by the ME. The card issuer is the only one that can modify this file.
• Config1 File: used to store connectivity and application information that can be changed by the provisioning agent, i.e. by
the ME. Then, the user can modify connectivity parameters stored in this file in entering the correct enabled PIN (see
section 9.5).
• Config2 File: used to store connectivity and application information that can be changed by the provisioning agent, i.e. by
the ME. Then, the user can modify connectivity parameters stored in this file.
The use of multiple files enables the use of the Smart Card file access features to protect part of the configuration data from
change by the ME (browser).
The smart card MUST support at least one of provisioning files (Bootstrap, Config1, Config2).
Any provisioning file may contain information on how to connect to the TPS (Trusted Provisioning Server) as defined in
[PROVCONT].
This document aims at specifying WAP provisioning data to be hosted directly by such smart card platform type or by a
WIM application [WIM] present on it.
Other non-default provisioning data MAY be read from any location on the smart card. The reading of this information is
implementation dependent.
Trusted Certificates can be read in any order i.e. between the ones stored in the ME and the ones stored in the SC Trusted
Certificate EF.
• Application selection
• Cardholder verification
The [PKCS#15] specification defines a set of files. Within the PKCS#15 application, the starting point to access these files is
the Object Directory File (ODF). The EF(ODF) contains pointers to other directory files. These directory files contain
information on different types of objects (keys, certificates, authentication objects (PIN), data objects, etc).
EF(ODF) contains pointers to one or more Data Object Directory Files (DODF). Each DODF is regarded as the directory of
data objects known to the PKCS#15 application. For the purposes of WAP provisioning, EF(DODF-prov) contains pointers
the provisioning data objects, namely Bootstrap File, Config1 File and Config2 File.
The WAP provisioning data (provisioning files) are stored as PKCS#15 opaque data objects.
Informative note 1: If a path starts with 3F00, it is an absolute path (starting from root).
• Flags indicating whether the provisioning document is private (i.e., is protected with a PIN) and/or modifiable
(CommonObjectAttributes.flags). The card issuer decides whether or not a file is private (it does not need to
be if it does not contain any sensitive information)
• Object identifier indicating a WAP provisioning object and the type of the provisioning object
(CommonDataObjectAttributes.applicationOID)
The EF(DODF-prov) MUST contain the types of provisioning documents (indicated using object identifiers) to be used by
the ME. The following types are described in this specification:
• Bootstrap
• Config1
• Config2
If a type exists on the smart card but it is not in the EF(DODF-prov) then this type MUST NOT be used.
The ME MUST use the OID to distinguish the EF(DODF-prov) from any other EF(DODF).
The WAP provisioning data are located under the PKCS#15 directory allowing the card issuer to decide the identifiers and
the file locations. General data object attributes and associated pointers are located in the EF(DODF-prov). The EF(DODF-
prov) can be read but it MUST NOT be modifiable by the user.
This chapter deals with provisioning data only, for handling of trusted certificates refer to [WIM].
The WIM application file structure (PKCS#15) contains at least an Authentication Object Directory File (AODF), a
Certificate Directory File (CDF), and a Data Object Directory File (DODF).
For WAP provisioning an additional DODF MUST be supported, namely DODF-prov as described in Section 6.2
In that case, the WAP provisioning file structure has the same location as the WIM application file structure.
DF-PKCS#15
… EF-DODF
wim
EF-CDF EF-ODF EF-AODF
EF-DODF
Prov
The access of WAP provisioning files will be possible using WIM related data storage commands. This requires the WIM
application to be active (i.e. selected using direct selection method).
WIM commands used to access provisioning data will be formatted according to the WIM activation mode as defined in
[WIM].
In the case where one of the above mentioned flag is set, cardholder verification is required. The access rights for
provisioning files stored within a WIM smart card application are granted in verifying the PIN-G as defined in the WIM
specification [WIM] i.e. the DODF-prov “authId” references to the PIN-G entry in AODF
The ME will retrieve characteristics and location of the PIN-G from the AODF.
Access conditions for files are described in the chapter Error! Reference source not found. and the PIN reference format is
described in section PIN Reference Format.
The support of WAP smart card provisioning data will be indicated to the ME’s user agent, by the presence in the EF DIR of
a WAP provisioning application template as defined here after.
The EF DIR (ID ‘2F00’) MUST be located under the master file as defined in [ISO7816-5] specification.
The recommended format of EF(DIR) is a linear fixed record in order to be in line with [TS102 221].
EF (DIR) MUST contain the application template used for a PKCS#15 application as defined in [PKCS15]. Application
template MUST consist of Application identifier (tag 0x4F) and Path (tag 0x51) information.
The ME MUST read the EF(DIR) file indicating the presence of the WAP provisioning application template. The EF(ODF)
and EF(DODF-prov) MUST be used by the ME to determine which WAP provisioning files are available on the smart card.
The EF(ODF) and EF(CDF) MUST be used by the ME to determine which trusted certificates are available on the smart
card.
Trusted Certificates on the smart card are ‘read only’ and cannot be changed by the ME.
UICC smart card platforms can support two modes of activation: 2G and 3G.
UICC smart card platform activated in a 2G mode has the logical characteristics of the SIM smart card platform
[TS51 011]. In that case, smart card operation for accessing WAP provisioning data conform to the ones defined for the SIM
as specified in chapter 8.2
UICC smart card platform activated in a 3G mode has the physical en logical characteristics according to [TS102
221]. In that case, smart card operation for accessing WAP provisioning data are specified in chapter 8.3.
To select the PKCS15 application, the ME MUST evaluate the PKCS#15 application template present in the EF (DIR), then
the ME MUST use the indirect selection method as defined in [TS51 011] to select the application.
WAP provisioning files and trusted certificates will be located under the DF(PKCS#15).
MF ‘3F00’
EF ODF
EF DODF-prov
EF Config1
EF Config2
EF Bootstrap
EF CDF
Figure 2: File structure for WAP data on SIM smart card or 2G UICC
In the case where one of the above mentioned flag is set, cardholder verification is required. The ME implicitly knows that
the CHV1 must be verified as defined in [TS51 011].
Remark: in that case the DODF-prov “authId” is not significant since no AODF is present.
Access conditions for files are proposed in the chapter Error! Reference source not found..
- MUST evaluate the PKCS#15 application template – i.e. PKCS#15 AID - present in the EF (DIR),
- MUST open a logical channel using MANAGE CHANNEL command as specified in [TS102 221],
- MUST select the PKCS#15 ADF using the PKCS#15 AID as parameter of the SELECT command, using direct
application selection as defined in [TS102 221].
WAP provisioning files and trusted certificates will be located under the PKCS#15 ADF.
8.3.1.1.1 Files Overview
MF
‘3F00’
DF-Telecom EFDIR
‘7F10’ ‘2F00’
ADF
USIM EF ODF
EF DODF-prov
ADF
PKCS#15
EF Config1
EF Config2
EF Bootstrap
EF CDF
In the case where one of the above mentioned flag is set, cardholder verification is required. The ME must evaluate the PIN
references that must be verified as defined in [TS102 221] i.e. evaluate the FCP
Remark: in that case the DODF-prov “authId” reference is not significant since no AODF is present.
Access conditions for files are proposed in the chapter Error! Reference source not found..
9. Files Description
All files defined are binary files as defined in ISO7816-4 specification [ISO7816-4]. These files are read and updated using
commands related to the application they belong to either the smart card platform or the WIM application. See respective
access methods in sections 7.1.4, 8.2.3 and 8.3.2.
In this section, only files used for the provisioning are described. All other files of the WIM application are described in the
WIM specification [WIM].
The file size proposed hereafter is a recommended minimum size. Larger files can be created (or extended later) in order to
cope with possible extension of the provisioning file content.
9.1 EF ODF
The mandatory Object Directory File (ODF) ([PKCS#15], section 5.5.1) contains pointers to other EFs, each one containing a
directory of PKCS#15 objects of a particular class (e.g. DODF-prov).
The File ID is specified in [PKCS#15]. The card issuer decides the file size.
In the case of WIM ICC, the EF (ODF) contains, in addition to WIM parameters, pointers to the DODF-prov. The EF (ODF)
MUST be formatted as defined in the [WIM] specification.
Access Conditions:
READ ALW
UPDATE ADM
INVALIDATE ADM
REHABILITATE ADM
Description
9.2 EF CDF
An optional Certificate Directory File (CDF) ([PKCS#15], section 6.6) contains directories of certificates. A CDF pointed to
by a Trusted Certificates field in the ODF, contains references to trusted certificates.
Access Conditions:
READ ALW
Description
9.3 EF DODF-prov
This Data Object Directory File provisioning contains directories of provisioning data objects ([PKCS#15], section 6.7)
known to the PKCS#15 application.
The File ID is described in the EF (ODF). The file size depends on the number of provisioning objects stored in the smart
card. Thus, the card issuer decides the file size.
Access Conditions:
READ ALW
UPDATE ADM
INVALIDATE ADM
REHABILITATE ADM
Description
9.4 EF Bootstrap
Only the card issuer can modify EF Bootstrap
Access Conditions:
READ ALW
UPDATE ADM
INVALIDATE ADM
REHABILITATE ADM
Description
See [PROVCONT]
9.5 EF Config1
The user can modify EFConfig1
Access Conditions:
READ ALW
INVALIDATE ADM
REHABILITATE ADM
Description
See [PROVCONT]
9.6 EF Config2
The user can modify EFConfig2.
Access Conditions:
READ ALW
UPDATE ALW
INVALIDATE ADM
REHABILITATE ADM
Description
See [PROVCONT]
Access Conditions:
READ ALW
Description
See [WIM]
The ME MUST support the WAP provisioning data on WIM if the ME is a mobile phone supporting the WIM.
The ME MUST support the WAP provisioning data on WIM-less telecom smart card if the ME is mobile phone.
Informative note 4:
The ME can determine whether the smart card supports logical channels in checking historical bytes of the ATR, as indicated
in [WIM] and as specified in [ISO7816-4].
An example of content for each logical record EF (DIR), EF (ODF) and EF (DODF-prov) is described in the table of Error!
Reference source not found.) and implementation details are provided in Error! Reference source not found..
The ME MUST support the update binary command in order to allow the update of Config1 or/and Config2 files.
Prior to accessing protected files the ME MUST read the AODF to know PIN references required.
For reading of trusted certificates see [WIM].
- Read EF (DIR) to evaluate the WAP provisioning application template and find the file identifier (and path of the
PKCS#15 DF),
- Read ODF,
The ME MUST support the update binary command in order to allow the update of Config1 or/and Config2 files.
Value notation:
{
aid 'A000000063504B43532D3135'H,
label "PROVISIONING",
path '3F007F80'H,
}
The recommended value of the optional label field is “PROVISIONING” but this value and its coding (either UTF8 or
UCS2) can be changed in order to ensure interoperability with the EF(DIR) described in [TS102 221].
},
classAttributes {
applicationOID { joint-isu-itu-t(2) identified-organizations(23)
wap(43) provisioning(5) configuration_2(3)}
},
typeAttributes indirect : path : {
path '4433'H,
}
}
Informative note 5: file IDs are examples, card issuer defines them.
L is the length of ‘label’ field. It is required that the length is the same in each record. This way records have fixed length (L
+ 24hex).
1 30
1 L + 1B
1 30
1 L + 09
1 0C
1 L
L Label
2 03 02
2 07 80 – private
2 04 01
1 01 – authId 1
7 30 06 06 04 67 2B 05
1 01 – bootstrap
02 – config1
03 – config2
6 A1 06 30 04 04 02
2 file ID
Note that the ME can determine the label length by reading the 6th byte of the file. Then, it is easy to find offsets for
label
file ID
The provisioning documents are contained in files with file IDs 4431, 4432 and 4433.
30 12
0C 09 42 6F 6F 74 73 74 72 61 70 -- "Bootstrap"
03 02 07 80 -- private
04 01 01 –- authId 1
30 06
06 04 67 2B 05 01
A1 06
30 04
04 02 44 31 -- path '4431'
The second and third records are encoded in a similar way. Note that the outermost SEQUENCE is omitted.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning