TB SiteMapbreadcrumb separatorSCPbreadcrumb separatorActivity Reportsbreadcrumb separatorActivity Report 2014

SCP Activity Report 2014

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
Chairman: Klaus Vedder
Giesecke & Devrient GmbH

Responsible for the development and maintenance of a common Smart Card Platform for all mobile telecommunication systems, for the application-independent specifications, for the interface with terminal equipment and for smart card standards for general telecommunications, mCommerce and security applications

The main task of ETSI’s Smart Card Platform committee is to develop and maintain the Smart Card Platform specifications for mobile communication systems. The specifications produced by TC SCP may, however, also be used in other sectors. Because they are generic and application-agnostic, they can be used as specifications for a (secure) platform for any application designed to reside in a smart card or a secure element.

To date, TC SCP has produced well over 40 specifications for smart cards. For each topic addressed, its specifications define requirements, the technical solution and conformance testing for both the smart card and the terminal. It is TC SCP’s hallmark in the world of standards that it provides the industry with a hitherto unknown basis for the development and integration of applications. In this way, interoperability can be achieved between terminals and the applications implemented on this true multi-application platform (called the UICC).

The areas addressed by TC SCP range from the definition of all lower layers and interfaces of the Smart Card Platform itself and application functionality, including physical aspects. This covers administrative commands, Application Programming Interfaces, browsers, Internet connectivity, Machine-to-Machine (M2M) and interfaces for high speed and Near Field Communication (NFC), as well as remote management.

TC SCP also provides and maintains the application identity register for smart card applications on behalf of other committees including the Third Generation Partnership Project (3GPP™), 3GPP2, GlobalPlatform, the Open Mobile Alliance (OMA), oneM2M, various financial institutions and the WiMAX Forum.

The main topics handled by TC SCP in 2014 were the continuation of work on the embedded UICC (eUICC), support of multiple secure elements for mobile contactless communication over the NFC interface and optimisation of the access to the UICC over the terminal interface. 

In general terms, an embedded UICC is a “UICC which is not easily accessible or replaceable, is not intended to be removed or replaced in the terminal, and enables the secure changing of subscriptions”. The ‘embedded’ nature of a UICC relates not so much to its form factor (any of the UICC form factors in the form of a smart card may thus be embedded) but to its accessibility, or rather the lack thereof. It may be inconvenient, if not impossible, to exchange an embedded UICC for another one, and this imposes specific constraints on the administration of an eUICC, including the electrical personalisation of the UICC. The ability to change subscription-related data in the UICC without its physical removal and replacement in the end-device necessitates new methods for provisioning identity and access credentials both securely and remotely. 

After the publication of the first version of the requirement specification for the eUICC in 2013, TC SCP extended the specification considerably in 2014. One of its enhancements concerned the interoperability of profiles: eUICC profiles must use a common description format so that profiles generated by any entity can be understood and accordingly installed by any compliant eUICC. Proprietary extensions are possible in a profile but ignored by the eUICC if not supported. While the publication of the first version of the specification was achieved by consensus, some of the new topics proved contentious. A major step forward was the resolution of the management of credentials for the eUICC. After long discussions about the number of Profile Management Credentials (PMC) and therefore the number of actors potentially involved in the management of the eUICC, it was finally agreed by means of an electronic vote that there will be one PMC for the creation of the container and transport of Profiles, one for the enabling/disabling of Profiles and one for the deletion of those Profiles. Using an electronic ballot outside the actual meetings proved advantageous for both the committee and individual members by saving precious meeting time.

A key activity in 2015 will be the development of a policy control function and the related rules. In addition, TC SCP’s Technical working group (SCP TEC) will continue its work towards the specification of a technical solution to meet the identified requirements. Good progress was made in 2014, particularly on the definition of the common description format of the Profile.

In 2014, TC SCP tightened the requirements related to secure messaging between the UICC and a remote server to prevent a potential cryptographic attack on the algorithms and keys.

TC SCP’s specifications are widely used by the industry and certification bodies, and the provision of ongoing support as they are implemented is an important aspect of the committee’s work. The maintenance and technical improvement of its specifications, as well as the continuous updating of its test specifications to cover new features and functions, therefore form a significant part of the work of TC SCP. In 2014 TC SCP upgraded several existing test specifications to cover new releases of the respective core specifications and reviewed a large number of existing test descriptions to take into account experience gained in the field.

TC SCP continues to develop its test specifications and to provision several new ones. In 2014 the committee began work on a new specification which will provide tests for the remote management of the UICC based on any of the secured packet structures specified by TC SCP. This will be of particular interest to implementers/issuers of UICCs that are expected to have applications loaded, customised or deleted over the lifetime of the UICC – typically UICCs used as a secure element for mobile contactless communication or as an embedded UICC.

In late 2014 TC SCP completed its work on test environment integrity and test case execution with the publication of an ETSI Technical Report. This report defines how the test environment should be set up to execute test case implementations based on TC SCP’s test specifications in order to produce consistent test results.

Work was also completed on the requirements for new contactless features by adding use cases and requirements to answer interoperability issues between the UICC and other potential contactless execution environments. This will address problems encountered when applications are provided by different service providers using different environments. In order to increase interoperability and avoid proprietary implementations, there is a need to standardise the interaction between the NFC controller, the UICC and these other (secure) elements, particularly the routeing of data to a specific application (in any one of the secure elements) without user interaction. TC SCP therefore began work on the technical realisation of the requirements for the support of multiple contactless Host Controller Interface hosts, and collaborates with both the GlobalPlatform and the NFC Forum to achieve a harmonised approach.

The requirements for UICC access optimisation were completed and work began on their technical realisation. This will, in particular, look into file access and aspects related to processing and transferring files. These requirements will provide the basis for mechanisms to support a better user experience when the UICC is used as a platform for several applications, in particular for NFC applications. The committee expected to complete the work in 2015. 

TC SCP began work on mechanisms for monitoring the number of updates on UICC non-volatile memory. This is of particular interest for the management of M2M devices, which can last much longer than consumer devices. The integrity of the UICC memory over this period is essential for the proper functioning of the M2M device. 

Concern had been raised by 3GPP that some non-3GPP applications could make the UICC unresponsive for a duration incompatible with authentication timeouts, which could block the making of calls. TC SCP investigated the issue and found that the cause was mostly due to on-board generation of cryptographic elements. Such a process is so CPU-intensive that UICCs operating under the existing power supply constraints require an unusually long time to perform it. TC SCP, in co-ordination with 3GPP and 3GPP2, solved the problem by increasing the power available to the UICC and defining a maximum processing time for applications. As part of this work, TC SCP also enhanced the specification of the power supply conditions for the UICC to ensure that the latest technology used by silicon manufacturers can be used for UICCs.

In 2014 TC SCP closed Release 12 of the Smart Card specifications and began the definition of the requirements for Release 13 and their technical realisation. 

The work of TC SCP is based on input from both inside and outside ETSI, and the committee therefore continues to liaise with major external contributors such as GlobalPlatform, the GSM Association, 3GPP, 3GPP2, the NFC Forum, the OMA, the Global Certification Forum, oneM2M and the PCS Type Certification Review Board. 

A full list of all active and completed work and detailed information relating to them can be found on the committee’s ‘Work Item Monitoring’ page at: http://portal.etsi.org/scp.