Registration of Digital Certificate Equipment in Brazil

In order to guarantee security for confidential information online, a cryptographic key equipment can be used for the exchange of encrypted data during transactions.

In this article we will explain the process to register a cryptographic key equipment according to requirements by ICP-Brasil.

Overview

Digital certificates have multiple purposes for insuring users in an online environment such as for e-commerce, legal processes or administrative matters, and since 2002 financial institutions use them in Brazil for internet banking services. In practice, it works as a virtual identity card, providing secure and reliable identification of either a person or organization.

Digital certificates and cryptographic key equipment are regulated by ICP-Brasil, the Brazilian Public Key Infrastructure. ICP-Brasil works as a hierarchy chain of authorities that provide regulation, directives and issuance of certificates, composed by a Root Certificate Authority, a Certificate Authority, a Registry Authority and a Time Certificate Authority.

The certification model adopted in Brazil is a single root certification, which is developed by ITI, the Brazilian Institute of Information Technology, working as a Root Certificate Authority, or root CA. ITI is the first authority in the ICP-Brasil chain, with the purpose to certificate other players in the chain, homologate devices and equipment, supervise and audit processes.

The main information contained in a digital certification is the entitled public key, name, email address, certificate validation period, the name of the Certificate Authority that issued the certificate, serial number and digital signature of the CA. Any person or organization can order a digital certificate, even a foreigner that does not possess a CPF, although they cannot obtain an e-CPF certificate in this case.

Cryptographic equipment homologation

The formal process for cryptographic equipment homologation started back in 2008 with the publishing of RAC, the Compliance Evaluation Requirement, by Inmetro, or the National Institute of Metrology, Standardization and Industrial Quality. ICP-Brasil migrated later from a proprietary model to Inmetro’s, which is internationally recognized.

In order to acquire a valid homologation from ICP-Brasil for any equipment, first the product must be submitted to an OCP, or a Product Certificate Organism, accredited by Inmetro. The equipment which must follow this procedure are:

• Smart cards
• Readers
• Tokens
• HSMs

The first OCP, and currently the only one available for these kind of devices, is NCC Certificações. The company has operated in this market since 2003 and provides certification for all types of cryptographic key equipment. After getting the proper certification the product must be submitted to ITI for homologation.

After the product is properly homologated by ITI, the Certificate Authority will issue, when requested, a digital certificate regarding each pair of cryptographic key equipment linked to an entitled. Later the Registry Authorities will identify and register the entitled user and forward the certificate requests to an AC, if this is the case.

Requirements for equipment homologation

ICP-Brasil has published several manuals known as MCT, or Manual de Condutas Técnicas, that list specific documentation for equipment, requirements and demands that will be tested by the institute in order to provide the homologation.

Products are tested on two different homologation levels: one based in the functional and documentation evaluation, while the other is based on the analysis of the complete and detailed specification, including its software.

Any cryptographic equipment that does not possess a specific listed MCT manual available on ITI’s website do not need to follow the same compliance requirements and deadlines and procedures of SBAC. For these specific cases, the homologation process starts at LEA, or the Auditory and Testing Laboratory, and are later submitted to ITI for homologation as soon as the Laudo de Conformidade, or the Compliance Report, is published.

The documentation needed to homologate the equipment is usually the same for all of them, adjusting specific information according to each equipment:

• Physical components corresponding to the equipment itself that will be sent for testing
• Technical documentation regarding all devices submitted to the process, containing information such as source code, hardware, firmware and software details, security module specifications and properties, protocols and other specific functionalities. This can be submitted in printed or electronic format, noting that if printed, two identical copies of each document are required
• Executable software components

Smart Cards

Smart cards are cryptographic ICP cards with integrated circuits, carrying the ability to generate, store and process asymmetric cryptographic keys and digital certificates to use in an ICP-Brasil infrastructure.

Smart cards must comply with the following requirements that will be considered during the testing in the homologation process:

• Control of access through PIN and PUK codes and the effectiveness of these codes

• Finite state model represented by a state transition diagram and/or a state transition table, regarding the operation of the cryptographic module
• Assurance of physical security quality of the device components
• Protection of cryptographic keys against reading, modification and unauthorized usage and substitution
• Presence of obligatory cryptographic algorithms, providing assurance against unauthorized access of the PIN code
• Verification of the adequate operation of cache and temporary storage of PIN codes and its overwriting

The smart cards must assure the interoperability through the standardization of:

• Cryptographic module
• Structure of APDU message
• Support for minimum set of commands according to ISO/IEC standards
• Application management requirements on cryptographic modules
• Dimension of electrical interface on cryptographic cards
• Specifications for electrical interface according to ISO/IEC standards

Readers

A smart card reader is a hardware installed in a PC that uses a serial-type physical connector or USB, operating as an interface for the interaction between a smart card and an application.

Readers must comply with the following requirements:

• Interoperability and compatibility between reader and smart cards, regarding specifications for electrical interface; insertion and removal of smart cards; electrical properties; data transfer and transmission protocols according to ISO/IEC standard
• Support for data communication between smart card readers to PCs and the adequate functioning of the reader, driver, interface module and its functionality
• Security recommendations such as insulated numeric and alphanumeric keyboard, biometric device and display

The interface module must comply with the following specifications:

• Operational features such as the ability to create multiple logical connections, in case the module support multiple readers
• Inclusion of functionalities as specified by PC/SC standards
• Ability to display notifications according to smart card usage, such as when it is inserted or removed from the reader and the status of the connected smart card, according to the PC/SC standards
• Support for data transferring protocols as specified by ISO/IEC standards and compliance to PC/SC standards

Readers can include additional features, such as allowing for the activation and deactivation of a smart card through a service provider command, that was not listed above, as long as it does not interfere with other functionalities.

Tokens

Cryptographic tokens are the hardware installed in a PC using a USB connector, generating and storing cryptographic keys and digital certificates to use in an ICP-Brasil infrastructure.

Tokens must comply with the following requirements:

• Minimum security requirements according to the North-American FIPS 140-2 standard, including specifications for cryptographic modules; access profiles, services and authentication; finite state model; physical security; operational environment; cryptographic key management and auto testing
• Support for the obligatory cryptographic algorithms for data encryption, entity authentication and Hash result, according to NIST FIPS PUB standards
• Adequate functioning for PIN and PUK codes regarding their blockage and change, storage and effectiveness
• Documentation that includes detailed information of hardware, software and firmware
• Assure interoperability with cryptographic modules and tokens connected to PCs, according to ISO/IEC and PS/SC standards
• Support for the interface module to create multiple logical connections, in case it supports multiple tokens, and to send information regarding token functionalities following a service provider command
• Inclusion of technical documentation regarding hardware and software

Tokens can include optional features as long as they do not interfere with device functionality. The cryptographic module must comply with specifications that include:

• Support management functionalities through control applications or tools
• Compatibility for API such as Microsoft CryptoAPI or PKCS#11, and support for management commands to be issued through these APIs. Including the import and export of cryptographic keys
• Support for digital certificate data storage of at least 16 Kbytes

Hardware Security Modules

Hardware Security Modules, or HSM, are a server or resistant and secure cryptographic auxiliary printboard that provides functionalities with the ability to generate and store cryptographic keys to use in an ICP-Brasil infrastructure.

HSM must comply with the following requirements:

• Include detailed documentation on cryptographic modules specification regarding the hardware, software and firmware, with in-depth descriptions of components and security features
• Implement obligatory algorithms for functions such as data cryptography, entity authentication with public key cryptography and cryptographic summary of data, or Hash
• Include interfaces for a cryptographic module, such as ports for data input and output, command issuing and status output
• Allow the operator access through the authentication of multiple types of authorized profiles
• Include finite state modules with detailed information regarding operational status, input and output events, error and user status, which must be part of the documentation
• Deployment of physical security features to prevent unauthorized access or violation and display clear signs of such activities if they take place
• Specify the category of operational system used by the cryptographic module, and include documentation, in cases where it was already homologated by a Brazilian or international entity
• Allow for cryptographic key management functions, which includes random number generation and cryptographic key generation, regarding its functionality, components and critical security parameters employed in the module
• Allow the attribution of cryptographic keys through a manual or automatic process
• Support for import and export of keys from the cryptographic module. The methods must be detailed in documentation
• Support for cryptographic key storage inside the cryptographic module, with no possibility of access from unauthorized operators
• Protection from external electromagnetic disturbance and without producing interference in the surrounding areas, according to EMI/EMC regulation
• Allow for auto testing in the cryptographic module as soon as it is turned on, including power testing and conditional testing, which is applied during specific events
• Ensure the module functionality in accordance to its specifications, as detailed in the documentation for proper operation of the device
• Ensure protection from threats, including those caused by the operator itself, and detailed in the technical documentation which measures are applied to assure its safety
• Allow for the management of hardware functions in the cryptographic modules, that include backup, retrieval, import, visualization of keys and storage of access logs and operations
• Support interoperability with APIs such as Microsoft CryptoAPI, PKCS#11, Java Cryptographic Extension and OpenSSL

Other equipment

Any equipment that is not covered by a specific manual must comply with the requirements listed below during the homologation process. First they must be submitted to LEA for pre-evaluation of homologation viability.

In this case, you must comply with the following requirements:

• Support the security requirements listed in the FIPS 140-2 standard, according to each specific case and the complementary requirements generalized by main MCTs
• Follow the interoperability requirements established, derived and complementary to the ISO/IEC 7816, ISO/IEC 14443 and PC/SC version 1.0 standards
• Provide the requirements for management, functionality and documentation listed in the existing manuals, as seen in the previous listing