|
US$2459.00 ยท In stock
Delivery: <= 10 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 29271.3-2014: Identification cards -- Integrated circuit card programming interfaces -- Part 3: Application interface
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 29271.3-2014 | English | 2459 |
Add to Cart
|
10 days [Need to translate]
|
Identification cards -- Integrated circuit card programming interfaces -- Part 3: Application interface
| Valid |
GB/T 29271.3-2014
|
PDF similar to GB/T 29271.3-2014
Basic data | Standard ID | GB/T 29271.3-2014 (GB/T29271.3-2014) | | Description (Translated English) | Identification cards -- Integrated circuit card programming interfaces -- Part 3: Application interface | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L64 | | Classification of International Standard | 35.240 | | Word Count Estimation | 129,131 | | Date of Issue | 9/3/2014 | | Date of Implementation | 2/1/2015 | | Quoted Standard | GB/T 9387.1-1998; GB/T 29271.1-2012; GB/T 29271.2-2012; ISO/IEC 7816-11; IETF RFC 2141 | | Adopted Standard | ISO/IEC 24727-3-2008, MOD | | Regulation (derived from) | People's Republic of China Announcement of Newly Approved National Standards No. 21 of 2014 | | Issuing agency(ies) | General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China, Standardization Administration of the People's Republic of China | | Summary | This Standard specifies the client application service interface support services that operate in response to the operation request and a way to express. Independent of the programming language way of describing these services. This section is in the appl | GB/T 29271.3-2014: Identification cards -- Integrated circuit card programming interfaces -- Part 3: Application interface
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Identification cards -- Integrated circuit card programming interfaces -- Part 3: Application interface
ICS 35:240:15
L64
National Standards of People's Republic of China
identification card integrated circuit card programming interface
Part 3: Application Interface
(ISO /IEC 24727-3:2008, MOD)
Published on:2014-09-03
2015-02-01 Implementation
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China
Released by the Standardization Administration of China
directory
Preface III
Introduction IV
1 Scope 1
2 Normative references 1
3 Terms and Definitions 1
4 Abbreviations 3
5 Organizations for Interoperability3
5:1 Summary 3
5:2 Computational Model 3
5:3 Entity Relationships on Application Interfaces 4
5:4 Security Model 8
6 Card-side application service access 11
6:1 Overview 11
6:2 Initialize 11
6:3 Terminate 12
6:4 CardApplicationPath 13
7 Connecting Services 13
7:1 Overview 13
7:2 CardApplicationConnect 13
7:3 CardApplication Disconnect 14
7:4 CardApplicationStartSession 15
7:5 CardApplicationEndSession 16
8 Card-side application service 17
8:1 Overview 17
8:2 CardApplicationList 17
8:3 CardApplicationCreate 18
8:4 CardApplicationDelete 18
8:5 CardApplicationServiceList 19
8:6 CardApplicationServiceCreate 20
8:7 CardApplicationServiceLoad 21
8:8 CardApplicationServiceDelete 21
8:9 CardApplicationServiceDescribe 22
8:10 ExecuteAction 23
9 Naming Data Services 24
9:1 Overview 24
9:2 DataSetList 24
9:3 DataSetCreate 25
9:4 DataSetSelect 25
9:5 DataSetDelete 26
9:6 DSIList 27
9:7 DSICreate 28
9:8 DSIDelete 28
9:9 DSIWrite 29
9:10 DSIRead 30
10 Cryptographic Services 31
10:1 Overview 31
10:2 Encipher 31
10:3 Decipher 32
10:4 GetRandom 33
10:5 Hash 34
10:6 Sign 34
10:7 VerifySignature 35
10:8 VerifyCertificate 36
11 Differential Feature Services 37
11:1 Overview 37
11:2 DIDList 37
11:3 DIDCreate 38
11:4 DIDGet 39
11:5 DIDUpdate 40
11:6 DIDDelete 41
11:7 DIDAuthenticate 42
12 Certification Services 43
12:1 Overview 43
12:2 ACLList 43
12:3 ACLModify 44
Appendix A (Normative Appendix) Authentication Protocol 45
References 120
identification card integrated circuit card programming interface
Part 3: Application Interface
1 Scope
This part of GB/T 29271 defines the services supported by the client application service interface: These services respond to operation requests and operations
way to express: Describe these services in a programming language-independent manner:
This part is the application interface of the Open System Interconnection Reference Model defined in GB/T 9387:1-1998: it provides for customers
The high-level interface of the client application, the client application uses the information storage and processing operations of the card end application as the general card interface:
This section is not authorized to define concrete implementations of this interface:
2 Normative references
The following documents are essential for the application of this document: For dated references, only the dated version applies to this article
pieces: For undated references, the latest edition (including all amendments) applies to this document:
GB/T 9387:1-1998 Information Technology Open System Interconnection Basic Reference Model Part 1: Basic Model (idt
ISO /IEC 7498-1:1994)
GB/T 29271:1-2012 Identification Card Integrated Circuit Card Programming Interface Part 1: Architecture (ISO /IEC 24727-1:
2007, IDT)
GB/T 29271:2-2012 Identification Card Integrated Circuit Card Programming Interface Part 2: Universal Card Interface (ISO /IEC 24727-2:
2008, IDT)
ISO /IEC 7816-11 Identification cards - Integrated circuit cards - Part 11: Authentication by biometric methods
cards-Integratedcircuitcards-Part 11:Personalverificationthroughbiometricmethods)
IETFRFC2141 URN Syntax May:1997
3 Terms and Definitions
The terms and definitions defined in GB/T 29271:1-2012, GB/T 29271:2-2012 and the following apply to this document:
3:1
access control list accesscontrollist
A collection of access rules:
3:2
access permission accesspermission
The ability to grant permission to perform an operation:
3:3
access rule accessrule
The connection between the in-context operation of the card-side application and the security condition:
3:4
Action action
The operation of the card-side application required by the client application in the GB/T 29271:3 application interface:
3:5
alphacard-application
Management card-side application, specific to GB/T 29271, is responsible for discovering cards and applications and providing management services:
3:6
card-application-path
An ordered set of protocol endpoints that connect client applications to card-side applications in the network:
3:7
Card application service card-application-service
A collection of operations:
3:8
channel
A physical channel for transferring bit information between client applications and card-side applications:
3:9
client-application client-application
A software component that runs on a platform that uses data storage and computing services provided by the card-side application:
3:10
connection connection
Logical reference channel:
3:11
global differential-identity
Differential features identified in all card-side applications managed by the same alpha card-side application:
3:12
local differential-identity
Differential features that are recognized only in the card-side application for which they are defined:
3:13
parameter parameter
Information that is required to define or affect operation:
3:14
return code returncode
Information, including status, is returned as a result of the operation:
3:15
securitycondition
Boolean expression for the discriminative state of the difference feature:
3:16
session session
Connection when used for a specific security context:
3:17
object target
The entity manipulated by the operation of the card-side application service:
4 Abbreviations
The abbreviations given in GB/T 29271:1-2012, GB/T 29271:2-2012 and the following abbreviations apply to this document:
ACL: Access Control List (accesscontrollist)
AID: application identifier (applicationidentifier)
AR: access rule (accessrule)
DID: Differential-identity
DSI: data structure for interoperability
GCAL: generic card access layer (generic card access layer)
OID: object identifier (objectidentifier)
SAL: service access layer (serviceaccesslayer)
5 Organizations for Interoperability
5:1 Overview
The client application and the card-side application consist of two pair-level entities, which interact through well-defined transaction and communication mechanisms:
The GB/T 29271:3 application interface shall be the only interface through which the client application interacts with the card-end application:
This chapter defines the calculation model and permanent entity on the GB/T 29271:3 application interface, through which the client application and the card-side application communicate:
interaction: The security model manages the security mechanism and establishes a trusted interaction through the security mechanism:
5:2 Introduce the conceptual entities provided on the application interface of GB/T 29271:3, and describe their operational behaviors and relationships:
5:3 Describe in detail the entities provided by the GB/T 29271:3 application interface and the relationships between them:
5:4 Describe in detail the security model provided by the GB/T 29271:3 application interface:
5:2 Computational Model
5:2:1 The client application can identify the path to the card-side application: Using the card-side application path, the client application can initiate to the card-side application
Connection: The card-side application is the card-side application currently used for connection:
5:2:2 GB/T 29271:3 application interface is a card-side application service provided to client applications: Each card-side application service consists of an operation group
The operation can be requested by the client application and confirmed by the SAL return:
5:2:3 If the client application does not know the path of the card-side application, it can request the GB/T 29271:3 application interface to find the requested card
The path of the end application:
5:2:4 Card-side applications are uniquely identified by AID:
5:2:5 The Alpha card-side application provides the client application with the basis for the trusted management of the card-side application:
5:2:6 A client application can open multiple connections: The client application can open multiple connections to the same card-side application, and each connection is requested:
Refers to a different connection handle:
5:2:7 Using an open connection, the client application can initiate a session with the card-side application:
5:2:8 A client application can open multiple sessions: Only one session can be opened in a connection:
5:2:9 The current state refers to the current state of the connection defined by the current card-side application, the current data set, and the identified difference features:
Authentication state and session expressions on the connection:
5:2:10 Card-side application includes one or more card-side application services:
5:2:11 Specific card-side application services, named data services, provide access to zero or more data sets:
5:2:12 The dataset contains zero or more data structures for interoperability (DSI): The dataset provides the names it contains for DSI
Scope and access rules:
5:2:13 Each dataset can be accessed from the named data service according to the access rules of the management operation:
5:2:14 The data set selected in the current card application is called the current data set:
5:2:15 A single operation request of GB/T 29271:3 application interface can be converted into multiple general purpose card interfaces of GB/T 29271:2
ask:
5:2:16 The card-side application can support multiple operations, and the client application sends requests to it through the GB/T 29271:3 application interface:
5:2:17 An operation request shall result in an operation confirmation:
5:2:18 An access rule consists of the name of the operation and the security conditions: Security conditions are related to the operation of access rules:
5:2:19 An access control list is a collection of zero or more access rules: Access control lists are associated with each object:
5:2:20 If and only if the security condition related to the operation of the access rule in the object's access control list evaluates to TRUE, including
The operation inside the object can be executed successfully:
5:2:21 An authentication protocol is the process by which differential characteristics prove ownership of an identity:
5:2:22 Authentication is the successful completion of the authentication protocol: The distinguishing feature in this case is pass discrimination:
5:2:23 If the difference feature passes the identification, the identification status of the difference feature is a Boolean variable of "TRUE", otherwise it is "FALSE":
5:2:24 The client application can be detected by the card-side application through the discovery program (through various Lists,
Get, and Describe operations) to learn about information, status, or services:
5:2:25 Access rules appear in the GB/T 29271:3 application interface:
5:2:26 Generally speaking, the degree of interoperability between the card-side application and the client application depends on the card-side application in GB/T 29271:3 application interface:
The discoverable information given:
5:3 Entity Relationships on Application Interfaces
5:3:1 Overview
This section describes the accessible entities through the card-side application, namely the alpha card-side application and the card-side applications it manages: more directly involved
The entities of the security model are described in 5:4:
Figure 1 illustrates a client application example of a card-side application under GB/T 29271: GB/T 29271:3 application interface simplifies connection
and session mechanism, as shown in Figure 1:
Through the card-side application path, the client application connects to the specified card-side application: Through such a connection, client applications can take advantage of
GB/T 29271:3 application interface to access card-side application services: In addition to its inherent security features, sessions add a security context to the connection
It is used to protect the data flowing between the client application and the card-side application:
Figure 2 illustrates the entities defined in the computational model and the relationships established between these entities: The entity and relationship diagram to describe
Individual card-side application services: The object types available for the corresponding operation are displayed in the rounded box associated with each operation:
Card-side applications are collections of objects and services: A service is a collection of operations: An action is an action applied to an object: client application via
GB/T 29271:3 application interface to access card-side application operations and services:
5:3:2 Alpha Card Application
Alpha card-side applications are available in the application interface: It can exist in the IC card or be emulated by a SAL or GCAL implementation:
On any occasion, the connection of the client application to the alpha card end application acknowledges the availability of the card application list:
5:3:3 Access card-side application service
Client applications use the Initialize and CardApplicationPath entry points on the GB/T 29271:3 application interface to access the card
end application service: The client application uses the end entry point to terminate access to the card-side application service:
Before accessing the card-side application service, the client application should request the Initialize entry point on the GB/T 29271:3 application interface: exist
After Initialize is confirmed, the client application can open the connection and request operations for multiple card-side applications simultaneously or consecutively: when no longer needed
To use the card-side application service, the client application should request the end entry point:
5:3:4 Connection service interface
The card-side application service provides operations for establishing a connection between the client application and the card-side application: Once the connection is established, the session can
The connection function is to strengthen the security of the communication between the client application and the card-side application: Figure 3 illustrates the entity relationship of the connection service:
as shown in Table 1: For the generic card interface, differential characteristics can be transmitted as defined by ASN:1:
When the difference feature is generated, the DIDName data element shall be specified by the client application that generates the difference feature:
Authentication protocol data elements shall be designated as object identifiers (OIDs) and determine which operations the difference feature can be used for: only when
When the authentication protocol specified by this OID is defined for use as authentication as defined in Appendix A, for the difference feature, its successful completion sets the difference
The discriminant status of the feature is TRUE: DIDName SHOULD be associated with only one authentication protocol: The operation of cryptographic services can be exploited in
Information in the Marker data element, as defined in Appendix A:
NOTE: The authentication protocol represented by data element 2 is either used for authentication or other encryption services:
The Scope data element is implied: The difference features defined in the alpha card-side application are global in scope, so in the alpha
It is recognized within all card-side applications managed by the method card-side application: So the other differentiating features for the card-side application in which they are defined are
partial: The range of the corresponding identification status shall be consistent with the range of the difference feature:
The optional Qualifier data element may provide a description of the use of differential features: For example, it can reference external descriptions by OID:
The Marker data element is the information in the card-side application, or its index, which should be used to perform the authentication protocol data specified in the data element
authentication protocol:
Examples of tags include:
---PIN;
--- password;
--- symmetric key;
--- asymmetric key;
--- digital certificates;
--- biometric images or templates;
--- A pair of symmetric keys, for example, one for encryption and one for message authentication code (MAC) generation:
As evidenced by the last entry in the above list, the token may consist of multiple parts, such as multiple keys: This takes into account the complex
Authentication protocols, which may require the use of multiple keys in parallel or in series:
In card-side applications, Marker can often be implemented as a key, that is to say, the key index defined in ISO /IEC 7816-4
refer to: A differentiating feature and its signature may be associated with multiple key indices in some complex authentication protocols: key index possible
is coded as defined in the ISO /IEC 7816-4 security environment: Private key indexes can appear in several differentiating features:
Differential features are associated with markers through the association of DIDName to Marker and an authentication protocol: The mapping should be maintained as discovery
part of the information: The mapping allows client applications and card-side applications to identify, exchange and share differentially characterized information:
5:4:3 Authentication Protocol
The authentication protocol shall be the mechanism used by client applications to set the authentication state for the differentiating characteristics indicated by DIDName: authentication protocol in
Enumerated in Table 2 and described in Appendix A:
To set the discriminant status of the difference feature to TRUE, either use CardApplicationStartSession or use DIDAu-
The thenticate operation, the identification protocol of the difference feature shall be completed successfully:
The same operation is performed for successive requests for the same connection handle and named differential characteristics for completion of the authentication protocol defined in Appendix A:
consultation may be necessary: These represent a single level in a multilevel authentication protocol:
The local difference feature authentication state is valid for the connection handles specified during their authentication, when CardApplicationDisconnect
When an operation is requested by this connection handle or another connection handle, the local authentication state shall be set to FALSE, otherwise it shall be invalid: when connected to
When an alpha card-side application is used, the established global authentication state shall be available to all card-side applications managed by the alpha card-side application:
Connection is valid: The global authentication state remains valid until the connection handle used to establish the global authentication state is no longer connected or becomes invalid: Such as
If the difference feature is identified by the requested CardApplicationStartSession operation, the subsequent CardApplicationEndSession operation
The request shall set its authentication status to FALSE:
When a DIDAuthenticate or CardApplicationStartSession operation is requested, the authentication status of the differential feature shall be
This is set to FALSE, and is set to TRUE only when an operational approval is generated for the successful completion of the authentication protocol request:
The discriminant status of the difference feature shall be assigned FALSE, which is not recognized when its discriminant status is assigned:
5:4:4 Session keys
The protocol may include the generation of encryption keys used during the session:
The session key SHOULD be invalid when the CardApplicationDisconnect operation is requested or connected: Additionally, if via
The request CardApplicationStartSession operation protocol is completed, when the CardApplicationEndSession operation is requested,
The session key should be invalid:
5:4:5 Access Control List
An Access Control List (ACL) is a set of access rules (AR) that apply to objects: AR is associated with card-side application services with security conditions
operation: Identifying state safety conditions based on difference characteristics is a Boolean expression: Objects are datasets, differential features, or card-side applications:
The discriminative difference feature shall have its discriminant status set to TRUE: Otherwise, its authentication status should be FALSE: if safe
If the condition evaluates to TRUE, the associated operation is identified: If the security condition is assigned FALSE, the associated operation is not authenticated:
If AR is present in the current card-side application that is suitable for association with security conditions (for the current card-side
In the ACL of the object of the authentication state, whose value is TRUE), the operation that includes the object shall only be executed: if and only if requested
When including the object to which its ACL is associated, AR only applies to its operation request:
An ACL is part of the object to which it applies, not a distinct object itself: So when the operation of the authentication service appears in the AR
When, AR controls whether an operation can be performed on the ACL in which it exists: The AR that controls access to the ACL exists in the ACL
within itself:
By including the differential feature in the security condition, the authentication of the differential feature may become
Very necessary: If the difference feature is associated with the authentication protocol that generates the session key, its inclusion in the security condition may make it possible to establish
Safe perimeter becomes necessary:
6 Card-side application service access
6:1 Overview
This chapter defines the entry point on the GB/T 29271:3 application interface, through which the client application can locate the specified card-side application and
And establish a communication channel for the card-end application: A client application can connect to more than one card-side application:
6:2 Initialize
6:2:1 Purpose
This entry point initializes the GB/T 29271:3 layer, including connectivity to other components of the GB/T 29271 protocol stack: For the client should
Only after the entry point is successfully called, the card-side application service is available on the GB/T 29271:3 application interface:
The initialization state of GB/T 29271:3 application interface implementation (variables, possible values, resources, support for card-side application services) is not covered in this part:
within:
6:2:2 Entry points
OUT ReturnCode Initialize(
);
6:2:3 Parameters
without:
|