afscm-nfc-applicatio..

Transcription

Mobile NFC Applications Validation Process
RELEASE 2.1
Date
21/12/2011
Reference
111221 - AFSCM PROC - LIVBL - EN - Application Validation Process - V2.1.doc
Copyright © AFSCM 2008-2011
AFSCM Validation Process V2.1
December 21, 2011
p1/29
AFSCM Confidential & Proprietary
Name
Company
Franck Chauvigné
Bouygues Telecom
Julian Alvero
Orange
Maryline Eznack
SFR
Evelyne Babel
NRJ mobile
Sébastien Gauthier
AFSCM
Document manager
Julian Alvero
Orange
Approval
Laurence Becq and Olivier Tessier
AFSCM
Translation on v1.2
Evelyne Babel
Monetech
Authors
Document management
Version
Date
Chapters
1.1
15/12/2009
All
14/05/2010
All
1.2
1.3
Modification
English translation
Operational process improvements with the proposition
of support/information and intermediate/pre-result
meetings.
Added precisions on some steps of the process.
Added a comment about Midlet Permissions.
Added a Security Acknowledgement template in the
appendixes.
Added precision on access conditions to the tests results
by the MNO and MVNO.
Added a chapter on Application Life Cycle management
process.
2.0
19/07/2011
Added information on the requirements and rules coming
from the EAL4+ level context (Common Criteria and
PPUSIM framework).
Wording : replacement of Midlet by Mobile Application
Modified Validation Process scheme : for EAL4+ sensitive
applications, it is recommended to apply the AFSCM
Validation step before any EAL4+ Certification step.
Introduced the Validation Authority and MDAP elements.
2.1
05/12/2011
Added android and RIM references, minor modifications
December 21, 2011
p2/29
TABLE OF CONTENTS ____________________________________________________________
1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
INTRODUCTION
Context .................................................................................................................................................. 5
Copyright license ................................................................................................................................... 6
Introduction to the Mobile NFC Applications Validation Process ......................................................... 7
Purpose.................................................................................................................................................. 7
References ............................................................................................................................................. 8
Acronyms and abbreviations ................................................................................................................. 8
AFSCM Definitions ................................................................................................................................. 8
2
2.1
2.2
2.3
2.4
2.5
2.6
5
ROLES AND RESPONSIBILITIES OF ACTORS
10
General context ................................................................................................................................... 10
AFSCM ................................................................................................................................................. 10
Mobile Network Operator (MNO) ....................................................................................................... 10
Service Provider (SP) ........................................................................................................................... 11
Security Validation Entities ................................................................................................................. 11
AFSCM validation committee .............................................................................................................. 11
3
PROCESS DIAGRAM OF THE VALIDATION OF NFC APPLICATIONS
12
4
PROCESS DETAILS AND MNO REQUIREMENTS
13
4.1 Management Rules ............................................................................................................................. 13
4.2 Development Rules ............................................................................................................................. 13
4.3 Functional Specification ...................................................................................................................... 14
4.4 Acknowledgment to Security Requirements....................................................................................... 14
4.5 Validation of Acknowledgment to Security Requirements ................................................................. 15
4.6 Application development phase ......................................................................................................... 15
4.7 Validation of the developments' compliancy ...................................................................................... 15
4.8 Validation of the application by the AFSCM Validation Committee ................................................... 16
4.9 Publication of validated applications .................................................................................................. 16
4.10Ultimate validation of the application by the MNO ............................................................................ 16
4.11Application Life Cycle management .................................................................................................... 16
5
MOBILE APPLICATION SIGNATURE
18
5.1 Java Mobile Application Permissions .................................................................................................. 18
5.2 Android and other non-Java Mobile Application Permissions ............................................................ 18
6
CARDLET SIGNATURE AND LOADING
19
6.1 Signature of Cardlets ........................................................................................................................... 19
6.2 Loading of cardlets .............................................................................................................................. 19
6.2.1
Pre loading of Cardlet in Factory ............................................................................................19
6.2.2
OTA Loading of the Application ..............................................................................................19
APPENDIX 1 PROCESS FOR REFERENCING OF THE VALIDATION ENTITIES
A1.1
21
Introduction ................................................................................................................................ 21
December 21, 2011
p3/29
A1.2
Process Description ..................................................................................................................... 21
A1.2.1
Request for Referencing......................................................................................................21
A1.2.2
Analysis of the request for referencing...............................................................................21
A1.2.3
Decision on the referencing ................................................................................................22
A1.2.4
Follow up of the referencing of the validation entity .........................................................22
A1.2.5
Withdrawal of the referencing ............................................................................................22
A1.3
Duties Related to the Referencing as Validation Entity .............................................................. 23
APPENDIX 2 ACKNOWLEDGMENT TO SECURITY REQUIREMENTS TEMPLATE (MODELE DE DECLARATION
SPECIFIQUE DE SECURITE)
A2.1
A2.2
A2.3
24
Livraison par l’éditeur ................................................................................................................. 24
Déclaration de sécurité ............................................................................................................... 25
Exemple de déclaration de sécurité ............................................................................................ 27
_____________________________________________________________________________
December 21, 2011
p4/29
1
INTRODUCTION
1.1
Context
The three French Mobile Network Operators Bouygues Telecom, Orange and SFR have founded in
April 2008 the AFSCM (Association Française du Sans Contact Mobile) to foster the development of
mobile contactless services.
The AFSCM’s objective is to present a one-stop window to professionals and organizations in the
mobile NFC eco-system:
- Deliver a consistent message to end users and enterprises about the benefits of mobile NFC
services,
- Develop and implement services that are promoted by both the Service Providers and the
MNOs,
- Facilitate the deployment of NFC services thanks to harmonized processes,
- Develop common specifications (Information Systems interfaces, NFC tags, handsets, etc.),
- Favour interoperability and homogeneity of equipments deployed.
The AFSCM industrializes the mobile NFC in order to:
- Progress from mono application to multi application by considering the existing initiatives
such as Pegasus for the payment and Ulysse for the transport,
- Progress from experimentations to mass deployment for 53 millions of potential end users.
To define a mutually beneficial mobile contactless eco-system, AFSCM has defined a label that will
indicate to end users the NFC services that are validated by the MNOs.
AFSCM constituency make possible for any company involved in the development of a sustainable
market for mobile contactless services to become member of the association: Service Providers,
handset manufacturers, smart card manufacturers, Mobile Network Operators, MVNOs...
December 21, 2011
p5/29
1.2
Copyright license
The text below is a personal, non-exclusive copyright license between you – the Licensee - and the
AFSCM founding members (*), regarding the AFSCM specifications, that must be included in any
copy of said specifications.
The licensee is authorized to copy, present or communicate the AFSCM specifications on any
media without having to pay any license fee under the condition that the following copyright
notice be included in any copy or any excerpt of the specifications
« Copyright © AFSCM 2008-2009 (Association Française du Sans Contact Mobile ;
http://www.afscm.org/). All rights reserved. Terms and conditions to copy, display and
communicate these Specifications available at http://www.afscm.org/conditions.html »
The licensee is NOT authorized to create or disclose modifications or abstracts of the specifications
or work derived from the specifications.
The specifications include detailed functional specifications, technical specifications, NFC handset
and NFC UICC implementation guidelines, application development guidelines (Mobile Application
and cardlet) and SP-MNO interconnection guidelines.
Separate patent licenses and additional material will be proposed to those wanting to implement
solutions compliant with the AFSCM specifications, under licensing conditions to be defined in
separate agreements. Information for procuring such patent licenses and additional documents
will be made available upon request by e-mail to: [email protected].
THE SPECIFICATIONS ARE SUPPLIED “AS IS” AND NEITHER THE AFSCM NOR ITS MEMBERS ARE
COMMITTED TO ANY WARRANTY, EXPLICIT OR IMPLICIT, REGARDING THE SPECIFICATIONS, IN
PARTICULAR NO WARRANTY IS GIVEN OF QUALITY, SUITABILITY TO ANY USE WHATSOEVER,
ABSENCE OF TITLE OR RIGHTS TO THE CONTENT OF THE SPECIFICATIONS, INSURANCE THAT THE
USE OF THE SPECIFICATIONS WILL NOT INFRINGE INTELLECTUAL PROPRETY RIGHTS OF A THIRD
PARTY SUCH AS PATENTS, TRADE MARKS, COPYRIGHTS. NEITHER THE AFSCM NOR ITS MEMBERS
SHALL BE HELD LIABLE FOR ANY DAMAGE INCURRED IN CONNECTION TO THE USE,
REPRESENTATION OR COMMUNICATION OF THE SPECIFICATIONS.
Neither the AFSCM name nor its trade marks shall not be used under any circumstances, such as to
communicate or advertise the specifications without the prior written agreement of the AFSCM.
No rights other than the rights described above are granted under this license and the rights
granted under this license cannot be construed as conferring, implicitly or explicitly, any rights
(through a licensing agreement or any other means) concerning AFSCM or AFSCM members
inventions, know-how or intellectual property, or any of their assets resulting from, based on or
required in the specifications.
This copyright license is subject to French law and shall be governed by and interpreted according
to French laws. The exclusive place of jurisdiction shall be the Paris Court of Appeal, regardless of
the number of claims or defendants.
(*) AFSCM founding members are Bouygues Telecom, Orange France / France Telecom, SFR.
December 21, 2011
p6/29
1.3
Introduction to the Mobile NFC Applications Validation Process
The AFSCM has elaborated a common process regarding the validation and acceptance criteria of
the embedded NFC applications.
The validation process applies to both Cardlet and Mobile Application hosted respectively in the
UICC and NFC handset.
This document also refers to the documents and reference guides published by the technical and
security committees.
This document is consistent with the requirements of the AFOM in the reference [R9] and can be
seen as the transposition of this validation scheme to the NFC context.
1.4
Purpose
The purposes of this document are the following:
- To define the steps that a Service Provider shall go through regarding the development and
validation of NFC applications so that he can deploy its NFC service in compliance with MNOs'
requirements.
- To gather the maximum of requirements and needs under AFSCM specifications, in order to
limit MNO specific requirements.
- To make it possible for the Service Providers to develop and deploy a single application
common to all the MNOsa
- To list the functional, technical and security requirements to be fulfilled in order to validate,
and deploy NFC applications.
- To define processes:
o "Multi-MNO" processes so that the Service Providers can develop and validate
applications in compliancy with the AFSCM rules based on the requirements of the
MNOs.
o Process for the referencing of the validation entities (selection and referencing).
o Description of the AFSCM proof of validation and provisioning of applications before they
can be loaded on handsets and UICC.
- Identify
o The actors involved and their roles,
o The related responsibilities,
o The interaction process (several iterations),
o The deliverables (referenced documents),
o The impacts regarding functionalities and organisation.
a
The technical features specific to NFC components (for instance on handsets) will be addressed in a
portability process that will be described later.
December 21, 2011
p7/29
1.5
References
AFSCM
[R1] Interface Specification between Telecom Operators and NFC Service Providers
[R2] Rules and recommendations for MIDlet design and development (also know as “Midlet
Application Development Guide)
[R3] Cardlet Development Guide
[R4] Guidelines for interconnection of Service Providers' and MNOs' Information Systems
[R5] Déclaration Spécifique de Sécurité (i.e Acknowledgement to Requirements)
[R6] NFC Android applications development guidelines
[R7] NFC applications development guidelines on RIM handsets
Payez Mobile (AEPM)
[R8] Book 0 - General Description v1.1
AFOM
[R9] Gestion des applications mobiles SIM - Exigences sécuritaires MNO
1.6
Acronyms and abbreviations
Please refer to the main document [R1].
1.7
AFSCM Definitions
Acknowledgment to
requirements
(also known as « Déclaration Spécifique de Sécurité »)
Declaration document the Service Provider has to provide. It lists
the used resources, the system accesses, used Java libraries, etc.
of the NFC application.
An example of this document for MIDP application can be found
in section A2.3 Exemple de déclaration de sécurité
AFSCM
Association Française du Sans Contact Mobile
AFSCM Validation Committee
Committee of experts coming from each MNO.
Functional specification
This document describes all the functionalities of a service. It
details which resources are used and how the application
accesses to these resources (API, JSR, methods …)
A specification is provided by the Service Provider for each
application.
Proof of validation
Technical way of proving that the application has been validated
and identifying the code.
PPUSIM
(U)SIM Java Card Platform Protection Profile defined by the FFT
(Fédération Française des Telecom).
Security Validation Entity
Entity in charge of validating that the security level in the
applications meets the security requirements.
For this purpose, the Security Validation Entity will use the
following documents:
December 21, 2011
p8/29
-
Application functional specification
Security policy
Application Development rules
Service Provider (SP)
Entity which provides a NFC service.
Its application shall go trough the different validation steps as
defined by the AFSCM in the current document.
UICC
Universal Integrated Circuit Card (usually known as SIM card).
In the context of the NFC deployment, the UICC is certified at an
EAL4+ level. This implies a number of specific development
constraints linked with the UICC platform. These requirements
are listed in the development guidelines [R3].
December 21, 2011
p9/29
2
ROLES AND RESPONSIBILITIES OF ACTORS
Several actors are involved in the process of NFC applications validation. The roles and
responsibilities described in this chapter are complementary to what has been for instance defined
by the Association Européenne du Paiement Mobile (AEPM) in [R8], chapter Players, Roles and
Responsibilities.
2.1
General context
-
2.2
The secure element for hosting the applications (Cardlet) is the UICC;
The MNO is the owner of the UICC;
The Service Provider is the owner of its application;
A Mobile Application loaded on a mobile handset (signed or not) with or without the approval
of the MNO engages the responsibility of the Service Provider that has developed it.
AFSCM
The roles of the AFSCM are the following:
- Define, publish and maintain the processes for the validation of NFC applications compliant to
the MNO requirements,
- Reference the Validation Entities that will apply the process defined in the current document,
- Analyse and pronounce acceptance of tests and validation reports that are common to all the
MNOs,
- Be the reference entity for the MNOs and the Service Providers,
- Publish the list of available NFC applications that can be deployed in production environment.
The AFSCM process aims to:
- Protect the MNO's assets,
- Protect the user's assets,
- Protect the Service Provider's assets,
- Respect the internal mechanisms of the UICC,
- Respect the principle of innocuousness of applications for each other (secure segmentation of
applications, access control and centralised management of applicative requests by UICC),
- Comply with the security requirements of common criteria for the applications that require a
high level of security (such as banking application).
Note: Document [R3] takes into consideration the different card vendors requirements.
2.3
Mobile Network Operator (MNO)
The roles of each MNO are the following:
- Provide the telecom infrastructure and access,
- Manage the UICCs,
- Ensure that each application loaded in its UICCs has been validated according to the AFSCM
validation process described in the current document.
- To ensure the validation of applications, the MDAP mechanism may be activated (depends on
the different MNO policies applied in the different countries or different UICC
Protection/Security Profiles). In this case, the MNO acts as Validation Authority for any
application loaded onto the UICC and applies the relevant MDAP signatures.
December 21, 2011
p10/29
2.4
Service Provider (SP)
The roles of a Service Provider are the following:
- Respect the NFC applications' validation process defined by the AFSCM (current document) for
both cardlets and Mobile Applications;
- Develop NFC applications taking into account the requirements and recommendations of the
AFSCM (management rules, development rules) [R2] [R3] [R6] [R7];
- Provide a Functional Specification and an Acknowledgement to Security Requirements for
each application and respect them;
- Submit each application (source code and bytecode) to a Validation Entity referenced by the
AFSCM;
- Provide applications that allow access to NFC services, free of charge or charged;
- Provide all the information necessary for the application provisioning (AID, version number …).
The Service Provider has the application management capabilities to operate its applications.
The Service Provider bears the validation costs of its applications.
2.5
Security Validation Entities
The roles of a Security Validation Entity are the following:
- Set up technical means, acknowledged by the AFSCM, in order to certify and identify an
application code that has been validated accordingly to the AFSCM requirements;
- Prove and commit on the compliance of the code with the functional specification and the
rules for management and development;
o the AFSCM development guides (see [R2], [R3], [R6] and [R7]) including the specific
requirements and recommendations coming from the EAL4+ UICC vendors;
o the Acknowledgement to Security Requirements
- Ensure that each application is innocuous for the other applications;
- Provide a validation report that presents a table with the level of risks identified, propose
recommendations for solving the problems, and provide an issues follow-up spreadsheet.
2.6
AFSCM validation committee
The roles of the AFSCM validation committee are the following:
- Validate the validation reports provided by the Security Validation Entities;
- Provide expertise support to MNOs on the applications (a MNO might want some clarifications
on some risks related to an application);
- Authorise and provision the applications that are validated;
- [Optional] advise the SP on the validation phases of his project by proposing early Validation
Kick-offs, Intermediate Validation Reviews before the end-results are issued, and security
specifications information;
- Analyse the request for referencing of the Validation Entities;
- Evaluate the requests for referencing and provide recommendations to the steering
committee;
- Reference the Validation Entities that are validated according to the process described in
Appendix 1;
- The access conditions to the confidential Validation Reports and related data by the MNO and
MVNO are detailed in the following document “Règlement Intérieur AFSCM”.
December 21, 2011
p11/29
3
PROCESS DIAGRAM OF THE VALIDATION OF NFC APPLICATIONS
The diagram below presents the role of each actor involved in the process of development and
validation of NFC applications.
Figure 1 - Process for development and validation of NFC applications
December 21, 2011
p12/29
4
PROCESS DETAILS AND MNO REQUIREMENTS
The MNOs define a reference guide of security requirements applicable to the applications hosted
in the UICC and in the mobile handsets. This reference guide defines a common basis, governed by
the mobile network operators working together in the security group of the AFOM.
The MNOs' requirements are presented in terms of management and development rules in
documents that are available to the Service Providers ([R2], [R3], [R6] and [R7]).
The Service Provider shall write the Functional Specification and Technical documentation of its
application. The Service Provider has to supply the Acknowledgement to Security Requirements
before the validation phase.
Notes on the scope of the requirements:
- Security related to MNO's activities:
Due to the fact that all the NFC applications will be in relation with the UICC and shared MNO
resources, every application shall pass the security validation. This applies to all applications,
be they non-sensitive applications or sensitive applications (EAL4+ certified applications).
- Security related to Service Provider's activities:
The security level of the NFC application is defined by the Service Provider depending on the
level targeted. The Service Provider may decide between two levels:
o Sensitive applications with an additional specific certification (EAL4+ certification or
equivalent), such as banking applications;
o Non-sensitive applications without additional specific certification.
- Sensitive NFC applications evaluated by other security certification schemes, such as EAL4 ,
CAST/EMVCO evaluations, should go through the AFSCM Validation first.
4.1
Management Rules
The management rules are specified in the guides published by the AFSCM [R2] Rules and
recommendations for MIDlet design and development, [R3] Cardlet Development Guide, [R6] NFC
Android applications development guidelines and [R7] NFC applications development guidelines on
RIM handsets.
These rules define the applications rights regarding the access to data, resources and functions,
and mention forbidden or restricted access (for instance: it is forbidden for the applications to
access to reading functions, or modify data or resources that are forbidden).
These rules also mention the security restrictions that are useful for the life cycle of the
applications hosted in the mobile handsets and/or in the UICCs.
4.2
Development Rules
The development requirements rules are specified in the guides published by the AFSCM [R2]
Rules and recommendations for MIDlet design and development, [R3] Cardlet Development Guide,
[R6] NFC Android applications development guidelines and [R7] NFC applications development
guidelines on RIM handsets. They define the rules to ensure the stable operating of the UICC and
its environment.
The rules refer to existing standards, procedures and requirements regarding the development of
applications in order to ensure:
- The interactions between applications (firewall);
December 21, 2011
p13/29
The interactions between applications and the UICC, the mobile handset and the telecom
network;
- The preservation of data, applications, services, resources and functions of the UICC or of the
mobile handset.
Some security rules might require the definition of additional development rules. The security
requirements are currently integrated in the development guides.
-
Notes on the scope of the requirements:
- Specific requirements for EAL4+ certified UICC platforms :
The EAL4+ certificate of certified UICC platforms may be conditioned to the fact that all the
embedded applications comply with some specific requirements and recommendations. These
specific requirements are issued during the EAL4+ certification process of the UICC platform.
The security validation will include the verification of these specific requirements and
recommendations for all applications in order to ensure that the global EAL4+ level is always
maintained.
- It has to be noted that these requirements may change from one UICC to the other; they can
likewise change regularly with the new UICC generations and lifecycles. The AFSCM will
regularly compile the evolutions.
4.3
Functional Specification
The functional specification of the application shall be fully detailed and supplied to the validation
entity.
The functional specification is compliant with the "management rules". It details the usage of data,
resources and functions as described in the "management rules". It includes a description of the
security measures implemented in order to protect the application data.
4.4
Acknowledgment to Security Requirements
The Service Provider, as owner of the application, shall provide an Acknowledgment to security
requirements that describes how the application accesses sensitive data, resources or functions
whether mentioned or not in the management rules and that lists all the functionalities used by
the application.
The Acknowledgment to security requirements describes how the application uses sensitive
data, resources or functions:
- Usage of data, resources or functions defined with "restricted access" in the management
rules:
o List of data, resources and functions used,
o Applicable processing,
o Purpose and scope of the processing.
- Usage of data, resources or functions not mentioned in the management rules, but that may
harm the assets of the MNO and/or the other Service Providers:
o List of data, resources and functions used,
o Applicable processing,
o Purpose and scope of the processing.
This acknowledgement is mandatory for each delivered version of the application.
The Service Provider should consider versioning this document in case some functionalities were
to be added later on.
December 21, 2011
p14/29
4.5
Validation of Acknowledgment to Security Requirements
The Acknowledgment to Security Requirements shall be controlled and approved by the AFSCM
Validation Committee. This group might request additional information on the applicable
processing and its consistency with the functional specification.
In case one MNO would release proprietary rules, complementary to the AFSCM rules, the Service
Provider should provide to this MNO a dedicated appendix to the Acknowledgment to Security
Requirements.
In order to start and facilitate the next validation milestones, a kick-off meeting shall be organised.
4.6
Application development phase
The development of the application shall strictly follow the management rules and development
rules (published by the AFSCM) on top of the Service Provider's functional specifications.
4.7
Validation of the developments' compliancy
The validation of the applications' compliancy is done by a recognized actor that has been
referenced by the AFSCM. A list of such recognized actor is available at http://www.afscm.org/.
The Service Provider mandates and shall contract with one or several validation entities.
The validation task consists in verifying the exact compliancy of the developed application and:
- The management rules,
- The development rules,
- The Functional specification:
o Absolutely no function shall be implemented if it is not described in the Functional
Specification;
o The only accesses to sensitive resources that can be implemented are the ones described
in the acknowledgment to security requirements.
The validation entity writes and provides a test report and certifies the compliancy of the tested
application with the reference documents.
The entity in charge of this security validation process is responsible for controlling the access of
the application to the resources of mobile handset and UICC and the data handled. It is also
responsible for providing recommendations depending on the sensitivity of the errors found.
The validation entity has a technical mean, approved by the AFSCM and by the Service Provider, in
order to certify and identify the application code that has been validated. This technical mean is
called the "proof of validation". It certifies that the application is validated and it identifies the
code that was tested.
The validation entity provides the following items:
- A test report related to security tests,
- The size of the application code,
- The version number of the application code,
- The hash value of the application code (preferred hashing: SHA-1).
[Note] When the NFC service uses both a Cardlet and a Mobile Application, the Service Provider
shall provide both applications to the validation entity.
[Note] The validation of Cardlet and Mobile Application can not be performed separately.
December 21, 2011
p15/29
4.8
Validation of the application by the AFSCM Validation Committee
Once the application is validated by the Validation Entity, it is presented to the AFSCM Validation
Committee for approval. This committee is in charge of analysing the reports provided by the
validation entities and deciding whether this application can be provided to the MNOs.
Once the application is approved by the AFSCM, its reference is added into the list of AFSCM
applications. Furthermore, the AFSCM validation committee writes a report with its
recommendations for the MNOs.
In case the validation fails, the application shall be corrected in order to meet the AFSCM's
requirements and shall go again through the entire validation process.
The delay between the moment the AFSCM Validation Committee receives a report and the
moment it gives its recommendations is usually a week and should not exceed 2 weeks.
4.9
Publication of validated applications
The applications approved by the AFSCM Validation Committee are published to all the relevant
actors.
The AFSCM is entitled to withdraw an application from the list published in case a problem is
encountered (such as security, functional, technical and/or organisational issue).
4.10 Ultimate validation of the application by the MNO
Each MNO might want to investigate the application in further details for instance to ensure that
its specific requirements are considered or to facilitate the portability of the applications to all the
targeted handsets.
Each MNO might proceed with an additional validation in order to ensure that all the requirements
are fully respected.
The ultimate validation is done by the MNO, which can decide whether to provision the application
on its OTA platform or to preload it in the UICCs and in the mobile handsets.
Refer to the chapter 6 Cardlet signature for the questions of MDAP and Validation Authority.
4.11 Application Life Cycle management
When an application needs to be modified or needs to evolve, the following rules apply:
Case 1: Cardlet changes
o Any Cardlet change has to be formally notified and has to go through a full AFSCM
Validation process.
Case 2: Mobile Application changes
o Any Mobile Application change has to be formally notified but may not need to go
through the full AFSCM Validation. A more flexible process can be allowed in case
of simple changes or corrections of the Mobile Application such as bug
corrections, GUI improvements, etc.
 In the case there is no validation required, the process is called a
“Declarative Validation Process”,
 In the case there is a simple and focused validation required, the process is
called a “Code Difference Verification”,
 In the case a full validation is required, the process is called a “AFSCM
validation”.
o The level and depth of the Mobile Application validation is decided by the
Validation Entity as the Validation Entity bears the responsibility of the application
compliancy against the AFSCM rules.
December 21, 2011
p16/29
The AFSCM validation committee may be consulted about this for informal
guidance.
In any case, all the earlier steps of the process apply, such as the supplying of:
The source code,
The Security Acknowledgment, especially in the Declarative Validation Case with a Security
Agreement signed by the Service Provider,
A follow-up spreadsheet for change tracking,
The hash codes of the applications,
Etc.
The Validation Entity must store the source codes and hash values in a secure manner, should an
audit be conducted later.
December 21, 2011
p17/29
5
MOBILE APPLICATION SIGNATURE
Mobile Applications are applications hosted in a mobile handset.
The signature of the Mobile Application ensures the authenticity of the application as well as its
integrity. The entity signing an application is committed by his signature.
In most cases, to achieve proper installation and use of the service, an application must be signed
to be trusted in the mobile environment. The SP is the owner of the service; the party applying the
signature on the application takes the responsibility for the security impacts associated with
malicious behaviours of the application. Maintaining a good level of security is important for the
user.
Validation of the mobile application through the AFSCM process is
- mandatory if the MNOs apply their signature and
- highly recommended if the Service provider applies its own signature.
Regarding Mobile Applications, each MNO decides whether or not to sign a Mobile Application
that is validated by the AFSCM and published via the validation process.
The signature of the Mobile Application ensures its authenticity and its integrity. The application is
signed only once it has been verified that the AFSCM requirements (and eventual MNO-specific
requirements) are fulfilled.
Once the application is signed, the Service Provider can publish it.
5.1
Java Mobile Application Permissions
Java Mobile Applications (MIDlets) can be stored in different memory zones of the terminal:
- Manufacturer
- MNO
- ITP (Identified Third Party)
- UTP (Unidentified Third Party)
Each zone benefits from a certain protection profile that is key for the application behaviour and
user experience.
NFC MIDlets must be loaded in the trusted MNO zone, unlike game MIDlets that can be stored in
the ITP or UTP zones (that is “unidentified public zones”), and must thus be signed by the MNO to
function properly. A MNO only applies its signature, and accepts a MIDlet in this zone after it has
properly been validated; this applies to both standalone and cardlet-linked MIDlets.
The adequate permission profile has to be defined and set before entering the validation phase.
Further technical details can be found in the reference [R2].
5.2
Android and other non-Java Mobile Application Permissions
Application signature details for Android mobile applications can be found in [R6] NFC Android
applications development guidelines.
Application signature details for mobile applications on RIM handsets can be found in [R7] NFC
applications development guidelines on RIM handsets.
December 21, 2011
p18/29
6
CARDLET SIGNATURE AND LOADING
In order to comply with the requirements of the EAL4+ certification of the UICC platforms, any
cardlet to be loaded in the UICC must go through the AFSCM validation process.
The Mandated DAP mechanism in place on EAL4+ UICC platforms ensures that only Cardlets that
have been signed by a Validation Authority can be loaded in the UICC.
To ensure this, the MNO acts as Validation Authority on its own UICCs and will only sign Cardlets
properly validated according to the present process. The security policies and procedures in
relation with this Validation Authority role are specific to the MNO, and are not described in this
document.
6.1
Signature of Cardlets
The Cardlets are JavaCard applications hosted in the UICC. Each Cardlet must be signed by the
MNO acting as a Validation Authority before it can be loaded in the UICCs.
There are two ways of loading the Cardlet in the UICCs:
- In factory, during UICC production,
- Or OTA once the UICC is issued.
6.2
Loading of cardlets
The Mandated DAP in the UICC ensures that only applications signed by the Validation Authority
can be loaded in the UICC.
This process is independent of the technical bearer used for loading (NFC, OTA, in factory). This
section gives more information about the loading operations using some of these bearers:
6.2.1
Pre loading of Cardlet in Factory
The MNO may decide to load an AFSCM application during UICC production. The MNO must
ensure that the application loaded by the UICC manufacturer (personalisation) is indeed the one
validated by the AFSCM (verification of the proof of validation).
The MNO ensures the security of the application (integrity and confidentiality) during its
provisioning to the smart card manufacturer and for the management of the application by the
smart card manufacturer (storage, access …).
6.2.2
OTA Loading of the Application
The process for OTA loading is under the responsibility of the Mobile Network Operator.
Nevertheless, the technical operation of loading can be delegated to another party.
December 21, 2011
p19/29
APPENDICES
December 21, 2011
p20/29
Appendix 1
PROCESS FOR REFERENCING OF THE VALIDATION ENTITIES
A1.1 Introduction
This appendix specifies the process by which Validation Entities can request to the AFSCM for
being referenced as AFSCM validation entity of NFC applications.
The validation entities will be responsible for the validation of NFC applications (Cardlets and
MIDlets), according to the specification commonly issued by the MNOs – that is the current
document.
The Validations Entities are mandated by the Service Providers willing to deploy a NFC services in
mobile handsets and UICCs.
As defined in the rules and requirements provided by the AFSCM and the MNOs, the validation
entity shall control the technical and security features of the NFC applications.
The AFSCM defines and publishes the conditions for referencing Validation Entities so that a
Validation Entity is authorised to validate NFC applications.
A1.2 Process Description
A1.2.1 Request for Referencing
The request for referencing shall be addressed to the AFSCM.
The following documents shall be provided together with the request:
- Copy of the KBIS to provide legal information,
- A technical offer in order to evaluate the professional skills and capabilities of the applicant
o General presentation of the company, including organisation charts that illustrate the
position of the validation entity within the company in case it is part of a larger company.
The organisation charts shall mention the different responsibilities;
o The experiences and national and international references for similar activities, with the
budget of these missions, name and contact details of the customer as well as date and
period the mission took place. The applicant shall justify in particular its competences for
validation tasks in the field of security for information technology.
- The existing authorisations and certifications of the company,
- Any other relevant information regarding the applicant.
A1.2.2 Analysis of the request for referencing
The AFSCM validation committee analyses the requests for referencing and is in charge of
validating the conformity of the request. The committee goes in further details in order to verify
the information related to the application, in particular:
- Company (organisation, viability, …),
- Equipment and organisation of premises,
- Organisation (business units, organisation charts, roles and responsibilities, security, quality,
technical, commercial),
- Competences and qualifications of employees (technical knowledge, methodology …),
- Commitment on confidentiality and non disclosure of sensitive information:
o From the organisational perspective,
o Regarding the employees (rules, contractual commitment),
o Clear separation of information sources (Service Providers, MNOs, …).
December 21, 2011
p21/29
Then the AFSCM validation committee verifies the existing certifications applicable to security and
industrial activity.
Level of requirements for the security validations
For the security validations, the requirements are related to usual competences expected by the
organizations in terms of information technology and telecommunication security. It is required
that the validation entity is certified NF 45011 or ISO 17025 by a certification organisation certified
by COFRAC and performs evaluations such as CC, ITSEC, EMV
The Validation Entity is responsible for presenting its references and accreditations so that the
AFSCM can evaluate them.
A1.2.3 Decision on the referencing
If the conclusions of the examination of the request are positive, and once the AFSCM steering
committee gives a favourable notice, the AFSCM notifies the validation entity that it is successfully
referenced by the AFSCM and adds the name of this validation entity to the appropriate list of
referenced Validation Entities
A1.2.4 Follow up of the referencing of the validation entity
The referencing is valid for a period of two years renewable exclusively upon presentation of a
new request.
The AFSCM continuously follows the activity of the validation entities and the evolution of the
scope of validation.
At any time, the AFSCM is entitled to ensure that the validation entity is still compliant with the
criteria and requirements that lead to the referencing.
A1.2.5 Withdrawal of the referencing
In case the validation entity does not comply anymore with the requirements and duties related to
the referencing, the AFSCM is entitled to suspend the referencing.
The AFSCM and the validation entity may agree on a schedule for the implementation of the
corrective measures necessary for retrieving the referencing. Once this period is over, if the
validation entity has not fully or successfully implemented the corrective measures, the AFSCM
may decide for the definitive withdrawal of the referencing.
The suspension or the withdrawal of the referencing leads to the removal of the validation entity
from the list published by the AFSCM.
The validation entity shall notify the AFSCM in case it stops its validation activity.
When the referencing of a validation entity is withdrawn, the applications previously validated by
the entity are still considered as valid. The applications earlier validated by this validation entity do
not need to go again through a validation process.
December 21, 2011
p22/29
A1.3 Duties Related to the Referencing as Validation Entity
The Validation Entity commits to respect and apply the processes related to the evaluation and the
certification defined by the AFSCM.
It commits respecting the referencing criteria, especially:
- It agrees to set up the validation process defined by the ASFCM in the current appendix,
- It commits to refuse any evaluation that would lead to a conflict of interest with a supplier
related to its evaluation activity. It commits to inform the AFSCM in case such situation
happens,
- It immediately informs the AFSCM about structural changes in the company, concerning the
organisation and the employees, and provides the documents that illustrate such changes.
- It ensures the security :
o Access control to its premises,
o Access control to the documents, equipments and/or tools used for the evaluations
related to this agreement,
- It authorizes the AFSCM members to control at any moment the progress of an evaluation, to
attend some evaluation tasks and to control that the referencing criteria are respected,
- It commits on the non disclosure to third parties of information related to its tools and
methods of evaluation,
- It shall restrict the usage of methods and validation tools provided by the AFSCM exclusively
to the evaluation tasks related to NFC. They shall absolutely NOT be transferred to any third
party.
- It shall propose validation schemes that take into account application’s life cycles (version
control, bug correction, upgrades and portability, etc) in a convenient and efficient manner to
fit in Service Providers development processes.
[Note] The AFSCM shall be informed about any activities, other than validation, that might be
done by the employees of the Validation Entity. The AFSCM shall ensure that these
activities are not incompatible with the validation activity.
December 21, 2011
p23/29
Appendix 2
ACKNOWLEDGMENT TO SECURITY REQUIREMENTS TEMPLATE
(MODÈLE DE DÉCLARATION SPÉCIFIQUE DE SÉCURITÉ)
NOTE : this section is in French. The English translation is not available yet.
A2.1 Livraison par l’éditeur
Afin d’optimiser le processus d’audit, une livraison doit contenir :
- La spécification fonctionnelle de son Application détaillant de manière exhaustive les
ressources utilisées par l’Application.
- Le code source doit être complet et ne doit pas être livré avec des librairies sans code source
correspondant
- Une déclaration de sécurité personnalisée avec les informations du projet.
- Le HMAC-SHA-1 du code source sous forme d’archive ZIP doit être renseigné dans la
déclaration de sécurité (pour votre information, l’application gratuite « hashmyfiles » offre ce
service)
- L’ensemble des classes utilisées doivent être présentes dans la fiche. Pour chaque classe, les
librairies utilisées (JSRs utilisés via le mot clé Java Import) doivent être renseignées dans la fiche
- Les appels directs de classes sans « imports » doivent être déclarés (ex :
javax.microedition.io.HttpConnection) et renseignés comme dans le précédent point.
- Le code de l’Application est documenté au format « Java Doc ».
- La déclaration de sécurité doit référencer l’ensemble des classes utilisées dans le projet dans
les catégories de fonctionnalités correspondantes
Lorsque les conditions de livraisons précédentes sont remplies et que tous les éléments de la
« Déclaration Spécifique de Sécurité » sont complétés par l’éditeur, cette déclaration est transmise
à l’AFSCM puis à chacun des MNOs qui se réservent le droit de demander des précisions sur les
traitements appliqués et leur cohérence avec la spécification fonctionnelle.
December 21, 2011
p24/29
A2.2 Déclaration de sécurité
L’audit de code est réalisé sur la base de la déclaration de sécurité et de la spécification
fonctionnelle.
Ce document sera complété par le fournisseur de l’application puis utilisé par les MNOs pour
auditer le code et signer l’application.
Voici des explications sur les informations attendues dans la déclaration de Sécurité :
-
-
-
Les informations d’en-têtes de document doivent impérativement être remplies :
nom éditeur,
date de déclaration,
nom de l’application,
version du code,
nom de l’archive,
taille de l’archive,
signature (HMAC-SHA-1) de l’archive (utiliser « hashmyfiles » par exemple).
Dans la colonne «Liste des classes utilisatrice » doivent apparaitre l’ensemble des classes du
projet. Les classes ayant des appels directs aux fonctionnalités offertes par les JSRs doivent
être remplies en premier.
Les classes utilisant des fonctionnalités non listées dans la déclaration de sécurité doivent être
ajoutées, en indiquant les dépendances utilisées si elles ne sont pas présentes(JSRs).
La dernière catégorie est réservée pour les classes plus « haut niveau » qui n’ont pas d’appels
directs aux ressources système.
La colonne justification de l’usage doit contenir la justification de l’usage des fonctionnalités
des dépendances utilisées, ainsi qu’un renvoi au besoin correspondant écrit dans la
spécification fonctionnelle. (Par exemple, dans le cas du SMS, il est nécessaire d’indiquer si il
s’agit d’un envoi ou d’une réception de message, ainsi que d’indiquer le besoin xxx
correspondant à cette usage. Cette information est de la même manière requise dans la
spécification fonctionnelle)
Au final, toutes les classes et dépendances recensées dans le projet devront apparaitre dans ce
document.
La déclaration de sécurité recense les fonctionnalités utilisées par l’application livrée.
Voici une liste non exhaustive des accès aux ressources qui peuvent être réalisées par les
applications:
accès aux données personnelles :
o Notes personnelles,
o Répertoire mobile,
o Calendrier,
o Fichiers locaux,
o Espace de Stockage Utilisateur.
accès à la messagerie :
o Envoi de SMS,
o Réception de SMS,
o Envoi de MMS,
o Réception de MMS,
o Envoi d’e-mails,
December 21, 2011
p25/29
o
Réception d’e-mails.
accès à la connectivité locale :
o Bluetooth,
o Wifi,
o Port Série,
o Sans Contact.
accès à la connectivité distante :
o http,
o Https.
accès à la carte SIM :
o Applications SIM.
accès aux fonctionnalités multimédia :
o Caméra-photo,
o Caméra-vidéo,
o GPS.
accès Applications :
o Réveil Application,
o Lancement Application.
autres ressources :
o Interrogation des capacités ou de la configuration du terminal.
December 21, 2011
p26/29
A2.3 Exemple de déclaration de sécurité
Cette section présente un exemple de la déclaration de sécurité demandée lors du processus de
validation des applications pour une midlet :
En-tête
Nom Editeur
Date Déclaration
Nom application
Version Code
softProviderName
01/01/209
mySoftware
9.9.9
Nom Archive
Taille Archive
HMAC-SHA-1 archive
mySoftwareProject.zip
253657 octets
d6aa97d33d459ea3670056e737c99a3d
Accès aux données personnelles
Fonctionnalité
Ressource manipulée
JSR
Listes Classes utilisatrices
justification de l'usage
Données PIM
Notes personnelles
JSR 75
Répertoire Mobile
JSR 75
Calendrier
Non utilisé
myContactReader.java
Lecture des infos des contacts
myContactCreator.java
Création d’un contact (besoin xxx)
JSR 75
myBirthdayReminder.java
Ajout d’un événement annuel dans
le calendrier (besoin yyy)
fichiers(sons,
images,...)
JSR 75
myPicModifier.java
Retouche de photos (besoin zzz)
Espace Stockage
Utilisa.
JSR 75
myContextSerializer.java
Sauvegarde du contexte de
l’application
Accès à la messagerie
Fonctionnalité
JSR
Messagerie
SMS
JSR 120 - 205
myWarner.java
MMS
JSR 120 - 205
Non utilisé
Emails
JSR 120 - 205
Non utilisé
Envoie un SMS d’avertissement
au numéro xx xx xx xx xx
(besoin aaa)
Accès à la connectivité locale
Fonctionnalité
JSR
Connectivité locale
December 21, 2011
p27/29
Espace de stockage
JSR 75
Non utilisé
Bluetooth
JSR 82
myFileSender.java
Wifi
JSR 118
Non utilisé
Port Série
Envoie un fichier image vers un
appareil à proximité (besoin
bbb)
Non utilisé
Sans Contact
JSR 257
Non utilisé
Accès a la connectivité distante
Fonctionnalité
JSR
Connectivité distante
HTTP
JSR 118
mySynchonizer.Java
HTTPS
JSR 118
Non utilisé
Se connecte sur l’ip du serveur
xxx.xxx.xx.x (serveur de
synchro) besoin ccc :
synchroniser le répertoire)
Accès aux fonctionnalités de téléphonie
Fonctionnalité
JSR
Téléphonie
Appel Vocal
JSR 118
myCaller.Java
Envoi d’un message vers
l’identifiant 06 06 xx xx xx
Accès à la carte Sim
Fonctionnalité
JSR
Accès Sim
Application SIM
JSR 177-257
myDataProcessor.java
Fait déchiffrer dès données par
l’applet SIM XXX (besoin eee :
les données sont chifrées par
l’application xxx de la carte
UICC)
Accès aux fonctionnalités multimédia
Fonctionnalité
JSR
Multimédia
Camera-Photo
JSR 135 234
myPhotoTaker.java
Camera-Video
JSR 135 234
Non utilisé
December 21, 2011
Prend une photo. Utilisé par la
classe XXX.java besoin fff
p28/29
GPS
JSR 178
Non utilisé
Accès Applications
Fonctionnalité
JSR
Application
Réveil application
JSR 118
myAppLauncher.java
Lancement application
JSR 211- 320
Utilisé par la classe XXX.java
quand événement XXX besoin
ggg
Autres classes
Fonctionnalité
JSR
Autres Classes
Catégorie XXX
Nouvelle Catégorie?
JSR xxx
myUnknownClass.java
Utilise le JSR xxx pour faire ….
Besoin hhh
none
myHighLevelClass.java
Utilise les classes xxx.java et
xxx.java pour effectuer les
traitements xxx. Besoin jjj
JSR?
END OF DOCUMENT
December 21, 2011
p29/29

afscm-nfc-applicatio..

Transcription

Documents pareils

Age validation in France Name of the list

A Step out of the Ivory Tower Experiences with Adapting a Test Case

The International Database on Longevity

EmoNets: Multimodal deep learning approaches for emotion

A quick look at some of the top birds currently on the Elimar online

Financial Institutions` Digital Future: Embracing the Inevitable

Concours d`accès au 1er cycle de l`institut - Alwadifa

Near Field Communication Research Lab Hagenberg