HOME   Cart(1)   Quotation   About-Us Policy PDFs Standard-List
www.ChineseStandard.net Database: 189759 (19 Oct 2025)

GB/T 36094-2018 English PDF

US$794.00 ยท In stock
Delivery: <= 5 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 36094-2018: Information technology -- Biometrics -- Embedded BioAPI
Status: Valid
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusPDF
GB/T 36094-2018English794 Add to Cart 5 days [Need to translate] Information technology -- Biometrics -- Embedded BioAPI Valid GB/T 36094-2018

PDF similar to GB/T 36094-2018


Standard similar to GB/T 36094-2018

GB/T 37344   GB/T 37735   GB/T 36344   GB/T 45346   GB/T 17554.1   

Basic data

Standard ID GB/T 36094-2018 (GB/T36094-2018)
Description (Translated English) Information technology -- Biometrics -- Embedded BioAPI
Sector / Industry National Standard (Recommended)
Classification of Chinese Standard L70
Classification of International Standard 35.240.15
Word Count Estimation 42,468
Date of Issue 2018-03-15
Date of Implementation 2018-10-01
Issuing agency(ies) State Administration for Market Regulation, China National Standardization Administration

GB/T 36094-2018: Information technology -- Biometrics -- Embedded BioAPI

---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.
Information technology--Biometrics--Embedded BioAPI ICS 35.240.15 L70 National Standards of People's Republic of China Information Technology Biometrics Embedded BioAPI (ISO /IEC 29164.2011, IDT) Published on.2018-03-15 2018-10-01 implementation General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China China National Standardization Administration issued

Content

Foreword III Introduction IV 1 Scope 1 2 Compliance 1 3 Normative references 1 4 Terms and Definitions 2 5 Abbreviations 3 6 Embedded BioAPI Environment 3 6.1 Embedded BioAPI Operating Environment 3 6.2 Embedded BioAPI Security 5 7 Embedded BioAPI Common Architecture 5 8 frame structure 7 9 Embedded BioAPI Patron Format 9 10 Embedded BioAPI Security Block Format 9 10.1 Security Block Format Owner 9 10.2 Security Block Format Owner Identifier 9 10.3 Security Block Format Name 9 10.4 Security Block Format Identifier 9 10.5 ASN.1 Object Identifier in Secure Block Format 9 10.6 Scope of use 9 10.7 Version Identifier 9 10.8 CBEFF Version 9 10.9 Overview 10 10.10 Specification 10 11 Data Types, Formats and Encodings 10 11.1 Slave ID field [S] 10 11.2 Command Field [C] 10 11.3 Status/Error Field [E] 11 11.4 Biometric Recognition Modal Code 12 12 Command Definition 12 12.1 Management Command 13 12.2 Template Management Commands 16 12.3 Registration Order 17 12.4 Biometric Processing Command 19 Appendix A (Normative) Compliance Requirements 25 Appendix B (informative) Frame Implementation Example 27 Appendix C (informative) Example of command exchange in multiple scenarios 29

Foreword

This standard was drafted in accordance with the rules given in GB/T 1.1-2009. This standard uses the translation method equivalent to ISO /IEC 29164.2011 "Information Technology Biometrics Embedded BioAPI". The documents of our country that have a consistent correspondence with the international documents referenced in this standard are as follows. ---GB/T 26237 (all parts) Information technology biometric identification data exchange format [ISO /IEC 19794 (all section)]; --- GB/T 28826.2-2014 Information technology common biometric identification exchange format framework Part 2. Biometrics Do not register the operating procedures (ISO /IEC 19785-2.2006, NEQ) Please note that some of the contents of this document may involve patents. The issuing organization of this document is not responsible for identifying these patents. This standard is proposed and managed by the National Information Technology Standardization Technical Committee (SAC/TC28). This standard was drafted. Guangzhou Guangdian Express Financial Electronics Co., Ltd., Changchun Hongda Optoelectronics and Biometric Identification Technology Limited Company, Guangzhou Guangdian Zhuozhi Intelligent Technology Co., Ltd., Beijing Tiancheng Shengye Technology Co., Ltd., Guangzhou Guangdian Express Information Technology Co., Ltd. Zhejiang Ant Micro Finance Service Group Co., Ltd., China Electronics Technology Standardization Research Institute, Beijing Defiance Technology Co., Ltd., Ministry of Public Security Institute, Xiamen Digital Software Technology Co., Ltd., Guangdong Baring Technology Co., Ltd., Shenzhen Mingtu Innovation Technology Co., Ltd. The main drafters of this standard. Hu Jingyi, Luo Panfeng, Liang Tiancai, Wang Xin, Zhang Lie, Ke Wenhui, Lin Guanchen, Peng Cheng, Zhang Yong, Luo Hongwei, Liu Xudong, Zheng Zheng, Yang Bo, Zhang Xin, Gao Jian, Weng Zhan, Jiang Qiwei, Xu Jun, Jin Xiaofeng, Zheng Cheng, Qin Rizhen.

Introduction

There are many differences between embedded system environments and conventional computing environments. First, the embedded system is processing functions, memory (or storage) is empty Between, operating system support and resource support are more limited. Therefore, the practice of configuring more common interfaces for embedded systems may not Suitable. For embedded biometrics, recognition algorithms and sensors are often packaged into hardware or firmware modules. Second, embedded system designers do not care about the implementation of the system in biometrics when designing system software and firmware. Details, but prefer to implement some or all of the biometric features by integrating an external module. This standard does not apply to applications that integrate biometrics into software or firmware. Used in such applications BioAPI (GB/T 30267.1-2013) or its frameless version (see ISO /IEC 19784-1 with Amd. 2). The interfaces defined in this standard provide direct connection to such biometric modules. The interface definition takes into account the services provided by the interface. And the message format of the command sent to the biometric module and the expected message format of the response from these modules. This standard is intended to provide a common interface for all biometric systems that do not implement BioAPI (see GB/T 30267.1). Previously, due to the considerable range of processing power and memory space requirements of BioAPI, there were some different solutions. One of them is BioAPI is used directly without the BioAPI framework, which is one of the most expensive processing and memory components. This BioAPI version Called the frameless BioAPI. However, this solution works for several types of applications (such as biometrics installed in mobile devices with an operating system). Identifying applets and biometric services is a big help, but its requirements go beyond the capabilities of embedded systems. Therefore, this standard A new solution called Embedded BioAPI was proposed, which is completely different from the above-mentioned frameless BioAPI. Embedded BioAPI can be used for remote controls, garage openers, car ignitions, access control devices, memory cards, authentication tokens, and Holding weapons and so on. Compared to the more common application scenarios, the usability of a standard interface in these application environments is not outstanding, but it has The next two important advantages. ---When multiple devices or components on a manufacturer's product line (only devices or components with built-in data acquisition devices, such as remote control devices) Only when there is a difference in the built-in data acquisition device or biometric technology (for example, device A uses built-in fingerprint data) Acquisition device or algorithm, while device B uses a face recognition camera or function), the standard interface can help the manufacturer to a single generation The code library meets the needs of multi-device production. And because the single code library helps simplify configuration management, it can increase productivity; --- Help data acquisition equipment OEMs implement multi-device vendor support with a single OEM component or firmware (ie no data to consider What kind of equipment is built into the acquisition device). In this standard, a device suitable for deploying an embedded BioAPI is called an "embedded BioAPI subcomponent." Please note that other types of settings This standard can also be used, but for a better understanding of this standard, we will only describe it here around the embedded BioAPI. This standard The requirements for devices such as embedded BioAPI subcomponents are not specified, but the requirements for implementing the embedded BioAPI devices are specified. Information Technology Biometrics Embedded BioAPI

1 Scope

This standard provides a hardware biometric identification module designed for embedded systems that are integrated into memory space and limited computing power. Standard interface. This standard specifies a complete interface for such hardware-based biometric modules. This interface is called an embedded BioAPI. It is defined by the specification of the commands that these modules are to implement. The specification is divided into the following two layers. --- Underlying implementation, which defines a framework for the underlying implementation and the encoding of all commands and their corresponding response pairs. Make For a single-master/multi-slave half-duplex protocol, these messages can be implemented at any physical and link layer via any communication interface. This The definition of some communication interfaces is not covered by this standard; --- A header description of a C-based function for manufacturers who have the following ideas. Provide a C library as a whole An integrated software development kit for embedded systems. Regarding security, this standard defines two types of equipment. --- Class A equipment. This type of equipment does not implement any security mechanism due to lack of processing power; --- Class B equipment. This type of equipment implements a security mechanism to achieve confidentiality, integrity and/or authenticity and is recommended for use. This standard A minimum set of requirements for Class B equipment is defined, but the safety mechanisms of the equipment are outside the scope of this standard. The underlying implementation is not covered by the specification part of this standard, but is provided as an informative annex (see Appendix B). Although the safety mechanism is considered in this standard, they are not within the scope of this standard. Please refer to other relevant standards. Especially the key Management is also outside the scope of this standard and is expected to be addressed prior to the application of this standard. Specifications and requirements for embedded BioAPI sub-components or any device suitable for implementing embedded BioAPI are outside the scope of this standard.

2 Compliance

A biometric module that claims to comply with this standard shall cover all mandatory requirements of the normative requirements of this standard. As long as the standard is not modified Under the premise of the stated behavior, the biometric module conforming to this standard can provide additional functionality. See Appendix A for a more detailed list of compliance requirements.

3 Normative references

The following documents are indispensable for the application of this document. For dated references, only dated versions apply to this article. Pieces. For undated references, the latest edition (including all amendments) applies to this document. GB/T 28826.1-2012 Information technology - Common biometric identification exchange format framework Part 1. Data element specification (ISO /IEC 19785-1.2006, MOD) GB/T 30267.1-2013 Information technology biometric identification application programming interface Part 1. BioAPI specification (ISO /IEC 19784-1.2006, IDT) ISO /IEC 19784-1/Amd.3.2010 Information technology biometrics application programming interface Part 1. BioAPI Normative Amendment 3 supports the exchange of certificates and security claims and other security aspects (Informationtechnology-Biometric applicationprogramminginterface-Part 1.BioAPIspecification-Amendment3.Supportforinter- Changeofcertificatesandsecurityassertions,andothersecurityaspects) Information technology - Common biometric identification exchange format framework - Part 2. Biometric registration. Operational procedures (Informationtechnology-Commonbiometricexchangeformatsframework-Part 2. Pro- Ceduresfortheoperationofthebiometricregistrationauthority) ISO /IEC 19785-3.2007 Information technology - Common biometric identification exchange format framework - Part 3. Patron format Informationtechnology-Commonbiometricexchangeformatsframework-Part 3. Patronformat Specifications) ISO /IEC 19794 (all parts) Information Technology Biometrics Data Exchange Format (InformationTechnology- Biometricdatainterchangeformats) ISO /IEC 24761.2009 Information Technology Security Technology Biometric Data Authentication Context (Information technology-Securitytechniques-Authenticationcontextforbiometrics)

4 Terms and definitions

The following terms and definitions apply to this document. Note. The functions and data elements are not listed separately in this chapter, but are introduced one by one in the body of this standard. 4.1 Biometric module A hardware-based module for implementing some or all of the functionality associated with a biometric modality. These features include data mining Set, sample processing, comparison, storage, registration, or a combination of any of the foregoing functions. Note. The biometric module can also provide other functions, such as sending an activation signal for external services, but such features are outside the scope of this standard. 4.2 Biometric sample biometricsample Biometric information obtained directly from the sensor or processed further. Note. See original biometric samples, intermediate biometric samples and processed biometrics in GB/T 30267.1-2013. 4.3 Biometric template biometrictemplate A collection of biometric samples or biometric samples suitable for storage. It can be used as a reference for subsequent comparisons. 4.4 Embedded BioAPI subcomponent embeddedBioAPIsubcomponent Can be integrated into a complex system or subcomponent of a device by a system integrator. Note 1. Sub-components may be provided by third parties or equipment vendors. Note 2. This standard does not describe the requirements for devices such as embedded BioAPI sub-components, but it specifies the requirements for the equipment required to implement embedded BioAPI. 4.5 Embedded system embeddedsystem There are sometimes real-time computing limitations for dedicated computer systems designed to implement one or more dedicated functions. Note. Usually the system is built into a complete device, including hardware, firmware and mechanical components. In contrast, a general-purpose computer such as a personal computer can To perform a variety of different tasks through programming. 4.6 Frame frame A set of bytes that make up a command or response message in an inter-device communication. 4.7 General processing unit A unit in a digital system that controls some or all of the information processing, usually a microprocessor, microcontroller, or sub-microprocessor system. 4.8 Host host The processing unit of the embedded system is directly connected to the biometric module. 4.9 Main embedded BioAPI interface masterembeddedBioAPIinterface Send commands and accept embedded COMAPI subsets of responses. 4.10 Processed biometric sample processedbiometricsample Can be used as a biometric sample for comparison. 4.11 Session key sessionkey A key used for encryption or authentication, using a different key per session. Note. The session period can be defined as the time period between power on/off or the time period between device connection/disconnection. When a session is detected to violate the security mechanism When the session is considered to have expired. 4.12 SlaveembeddedBioAPIinterface from the embedded BioAPI interface A subset of embedded BioAPI that receives commands and sends responses. 4.13 Template template Biometric template. 4.14 Template storage capacity templatestoragecapacity The number of biometric template BIRs that can be stored in a biometric module.

5 Abbreviations

The following abbreviations apply to this document. BIR. Biometric Information Record (BiometricInformationRecord) OEM. Original Equipment Manufacturer (OriginalEquipmentManufacturer) PoS. Point of Service Terminal (PointofServiceterminal) RFU. Reserved for Future (ReservedforFutureUse) SDK. Software Development Kit (SoftwareDevelopersKit)

6 Embedded BioAPI environment

6.1 Embedded BioAPI runtime environment The embedded BioAPI provides a standard interface for biometric modules installed in embedded systems. Usually, the embedded system The system has a small memory space and low computational power, so that it cannot support BioAPI (GB/T 30267.1-2013) or its frameless version. (See ISO /IEC 19784-1/Amd.2). This means that the interface defined in this standard enables direct connection between the application and the biometric module without using an operating system solution. A solution or a high-level programming language. The definition of the interface takes into account the services provided by the interface and the commands received by the biometric module. The message format and the message format of the response sent. There are no details of the underlying implementation, see Appendix B and Appendix C for examples of such details. To better understand the application environment of the embedded BioAPI, an example is illustrated in FIG. Figure 1 represents a point of service (PoS) terminal Modules (such as terminals used in stores that accept credit card payments), in which two biometric modalities are integrated into a single form (for example, fingerprints and handwritten signatures). According to the design of the application, one of the biometric recognition modes can be selected according to the actual scene. Figure 1 Example of a biometric identification system based on embedded BioAPI subcomponents In order to implement such PoS terminals, manufacturers should integrate the required biometric algorithms and data acquisition devices into the system. because For embedded systems with limited processing capabilities, microcontrollers equipped with this terminal may not be able to support complex algorithms. To this end, the manufacturer chooses to live The feature technology vendor procures the hardware modules that have installed the required services. As shown in Figure 1. --- Solve the problem of handwritten signatures through a separate hardware module with built-in required services, only need to (through the data acquisition device) Providing the user's registered student for the original biometric sample (see ISO /IEC 19794-7) and (via the PoS processing unit) Feature template. --- Solve the fingerprint identification problem through two cascaded independent modules. One of the independent modules supports the required services and comparisons Yes, but need to interface with another module to get the data acquisition device interface; another independent module has a built-in data acquisition device and The final signal processing algorithm (see ISO /IEC 19794-2). The first independent module does not need to enter biometric samples, but To enter the biometric template that the user has registered, in order to be processed with the second independent module. The samples were compared. In the above example, the module should provide the required biometric services, such as. ---Fingerprint. collect fingerprints and compare them with user templates; ---Handwritten signature. Alignment. Provides the user's original biometric samples and their storage templates (these templates are stored in a database or personal device) In, for example, a smart card). Other systems and modules may require additional features such as services and commands (see Chapter 9). For example, they may need to have a template Storage function or registration function. Note that this standard only specifies API requirements for security, and does not specify any mandatory security algorithms or key exchange mechanisms. These security mechanisms have yet to be determined, such as the security mechanisms used for communication between user devices or between various vendor devices. Recommended by this standard Use standardized security mechanisms such as those defined in ISO /IEC JTC1SC27. The embedded BioAPI is derived from the full BioAPI, but is specially tailored for the embedded environment. With general BioAPI In contrast, the embedded BioAPI has the following features. a) No framework components are required, and there is no need to utilize the component registry (ie, between the application and the Biometric Service Provider (BSP) component Straight connection) b) includes a subset of full BioAPI functionality (eg, embedded BioAPI does not support one-to-many alignment or related primitives); c) minimize the state of the required processing; d) lack of a callback mechanism; e) unused data handles; f) does not support the Function Provider Interface (FPI); g) The option is reduced to a minimum. Embedded BioAPI maintains the neutrality of biometrics, providing biometric identification and verification through a common interface The basic functions required by the card. The data format (biometric identification data information record) should comply with GB/T 30267.1.2013 and Provisions of the relevant part of ISO /IEC 19794 (published). Embedded BioAPI components are typically software or firmware, both associated with a specific hardware data acquisition device. Embedded systems typically have the following limitations. a) memory and storage space limitations; b) processor size and processing speed limits; c) operating system support restrictions; d) support only a single data acquisition device that requires hardwired; e) Can only run independently (cannot connect to the network). 6.2 Embedded BioAPI Security This standard defines two devices. --- Class A equipment. This type of equipment is not used because it does not provide processing functions and is designed for convenience rather than safety. Any security mechanism; --- Class B devices. These devices employ relevant security mechanisms to ensure confidentiality, integrity, and ACBio instance generation. These ones The mechanism and its corresponding algorithm and key information are dependent on the target device and will be shared with the application before execution. If only encryption is supported, BIR BDB will be encrypted; if only integrity protection is supported, the integrity of SHB and BDB concatenation will be guaranteed; Encryption and integrity protection, prioritized encryption. Note. Class B equipment is highly recommended. The security requirements for Class B equipment are given below, but the specific security mechanisms used are beyond the scope of this standard. In class B devices, biometric data is exchanged using a security block (SecurityBlock) in BIR, as defined in Chapter 10. Therefore, biometric data is exchanged using security blocks in the BIR. The security mechanisms used in communication can be added through the underlying protocol, but This standard is not responsible for additional instructions. All Class B devices do not use any security mechanism, so all exchanged biometric information The use of the safety block in the BIR is not covered by ISO /IEC 19784-1/Amd.3 and GB/T 28826.1-2012.

7 Common Architecture of Embedded BioAPI

The general architecture corresponding to the biometric module supporting embedded BioAPI consists of two components, which need to interact with each other. Provide biometric identification related functions. One of the components is a general purpose processing unit, also known as a host. This component is responsible for providing the top work of the whole machine. Yes, need to be with the embedded BioAPI subgroup responsible for completing some or all of the biometric operations (processing, storage, registration, and verification) The pieces (ie, the biometric identification module) are connected. The embedded BioAPI is designed to integrate embedded BioAPI subcomponents (embedded biometrics subcomponents) into the main Machine equipment. There are currently two integration methods. a) Independent embedded BioAPI sub-components (Class 1). refers to a single integrated biometric data acquisition device, memory and algorithm Embedded BioAPI subcomponents; b) Combined Embedded BioAPI Subcomponent (Class 2). refers to a single embedding that integrates at least one or more (not all) of the following features BioAPI subcomponent. 1) Biometric data acquisition device - used to sense and collect raw biometric data; 2) Biometric Memory - for onboard storage of template data; 3) Biometric algorithm - used to process and compare biometric data. The two integration methods are shown in Figure 2. Figure 2 Different ways to implement an OEM biometric module Class 1 (independent embedded device) modules are OEM fingerprint data acquisition devices or chip boards that are installed in remote control devices. The module mentions For complete biometric devices, including fingerprint data acquisition devices, processors, firmware (built-in biometric data processing and comparison calculations) Method) and onboard memory (up to 5 fingerprint templates can be stored). Class 2 (combined embedded device) module is the original CCD camera that supports facial image capture (ie biometric data acquisition) Prepare). The camera is built in a home access device and a biometric module having a face image comparison function. Such an application en...

Tips & Frequently Asked Questions:

Question 1: How long will the true-PDF of GB/T 36094-2018_English be delivered?

Answer: Upon your order, we will start to translate GB/T 36094-2018_English as soon as possible, and keep you informed of the progress. The lead time is typically 3 ~ 5 working days. The lengthier the document the longer the lead time.

Question 2: Can I share the purchased PDF of GB/T 36094-2018_English with my colleagues?

Answer: Yes. The purchased PDF of GB/T 36094-2018_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet.

Question 3: Does the price include tax/VAT?

Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countries

Question 4: Do you accept my currency other than USD?

Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.