CNTR

Counter

Management →
Introduced in Rel-8

CNTR is a management parameter for UICC applications that represents a counter value used to track and limit the number of times a specific operation or event can occur, ensuring security and operational integrity.

Category
Management
Introduced
Rel-8
Where
Testing
Specifications
1 specs
CNTR Description Purpose Related Detected Changes Specifications

Description

CNTR, or Counter, is a fundamental data object defined within the 3GPP technical specification TS 31.213, which specifies the UICC application programming interface (API) for Java Card™. It is a persistent, integer-valued variable stored in the non-volatile memory of the UICC (or SIM/USIM card). The primary architectural role of a CNTR is to serve as a stateful, monotonic counter that can be incremented, decremented, or reset by authorized applications, typically under the control of a security domain. It operates within the Java Card Runtime Environment (JCRE), where it is accessed via standardized methods provided by the `javacard.framework.Util` class or similar application-specific interfaces defined by the card issuer.

How a CNTR works is intrinsically linked to the security and lifecycle management of UICC applications. When an application needs to enforce a limit—for instance, the number of failed Personal Identification Number (PIN) verification attempts before the PIN is blocked—it will read the current value of a designated CNTR. Upon each failed attempt, the application logic instructs the JCRE to increment the counter. The application then compares the updated CNTR value against a predefined threshold stored in the card's file system (e.g., in the EF_UST file). If the threshold is reached, the application triggers a security action, such as locking the PIN or disabling a service. The counter's value is maintained across card power cycles due to its storage in non-volatile memory, ensuring persistent state tracking.

Key components involved with CNTR management include the UICC's file system (for storing the counter's value and its associated threshold), the Java Card applet implementing the business logic, and the security framework that controls access permissions. Counters are often associated with specific elementary files (EFs) defined in the card's structure. For example, the counter for PIN try attempts is directly managed by the card's operating system in conjunction with the PIN reference data. The role of CNTR in the network is indirect but critical; it is a foundational element for subscriber authentication security, service provisioning control, and fraud prevention at the very edge of the network—the user's secure hardware token. Its reliable operation underpins trust in mechanisms like PIN blocking, which protects against unauthorized SIM use.

Purpose & Motivation

The CNTR concept exists to provide a standardized, reliable mechanism for stateful event counting within the constrained, secure environment of a UICC. Before standardized APIs, application developers had to implement custom counter mechanisms, leading to fragmentation, potential security vulnerabilities, and increased testing complexity for network operators and card vendors. The formal definition of CNTR within TS 31.213 solves the problem of how to persistently track occurrences (like security failures or usage milestones) in a way that is interoperable across different card manufacturers and Java Card platform implementations.

Historically, as UICCs evolved from simple authentication modules to platforms for multiple applications (like payment, identity, and transportation), the need for robust application state management grew. A counter is a primitive but essential building block for implementing security policies (e.g., limiting retries) and business logic (e.g., tracking loyalty points or data session counts). Its creation was motivated by the requirement to move beyond hard-coded, OS-specific solutions to a portable, Java Card-standardized approach. This allows network operators to develop and deploy secure applets with predictable behavior, knowing that the counter's integrity and persistence are managed by the underlying, certified Java Card platform.

The limitations it addresses include the lack of a guaranteed persistent storage API for application state in early smart card systems and the risk of counter manipulation if not properly secured. By defining CNTR operations within the secure context of a Java Card applet and the card's security domains, 3GPP ensured that these critical values are tamper-resistant and can only be modified by authorized entities, thereby enhancing the overall security posture of the mobile network's subscriber identity module.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-18.

Rel-18 1 change

In Release 18, the primary introduction for the CNTR function was the addition of test cases and corrections for the coverage of the `GBAUCipher` class from the `uicc.usim.gba_u` package. This involved defining specific test procedures that require the USIM Application Dedicated File (ADF) to contain the `EF AC_GBAUAPI` file as detailed in the specification's annex. The enhancements ensure proper validation of the USIM's API for the Generic Bootstrapping Architecture (GBA) functionality within the defined test framework.

  • Test cases and sources correction related to coverage of GBAUCipher class from uicc.usim.gba_u TS 31.213CR0053

Explore further

Broader topics and technologies where CNTR plays a role.

Defining Specifications

3GPP specifications that define or reference CNTR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 31.213 vi30 Test specification for (U)SIM Rel-18