STQC Certification

The industry is abuzz with debates over the mandatory ER Certification by STQC for CCTV cameras. This blog aims to clear the air by analyzing the relevant gazette notifications, compliance timelines, and the critical need for secure, nationally compliant cameras.

Understanding the Gazette Notification and Public Procurement Order (PPO)

On March 6, 2024, the government introduced an amendment to the Public Procurement Order (PPO). This amendment mandates that all CCTV camera brands in India must obtain Essential Requirements (ER) certification from the Standardization Testing and Quality Certification (STQC) Directorate.

The amendment provided a compliance period of three months, with the rule becoming effective from June 6, 2024. From this date onwards, any Made-in-India CCTV cameras procured for government projects must strictly adhere to the STQC-certified ER standards.

By complying with these requirements, organizations can ensure their surveillance systems meet the highest levels of security and performance, aligning with national standards.

Background

IoT System Certification Scheme (IoTSCS) is operated by STQC Directorate, Ministry of Electronics and Information Technology (MeitY), Govt. of India. Under supervision of CB, the Testing Laboratories perform Testing of CCTV Cameras against the Essential Requirements mentioned in Gadget Notification dated 6 Match, 2024 issued by MeitY

Purpose

The purpose of this document is to define the methodology to verify the compliance of claims made by CCTV developer/manufacturer with respect to Essential Requirements mentioned in Gadget Notification dated 6 Match, 2024 issued by MeitY.

Objective

The key objective is that the CCTV Cameras shall comply with the requirements as specified in the Essential Requirements mentioned in Gadget Notification dated 6 Match, 2024 issued by MeitY.

CCTV developer/manufacturer vendor may implement TEE on Single chip (i.e. Micro Controller, Micro Chip, Secure Processor, Secure Chip etc.) or set of chips on single PCB.

Procedure

The certification of the CCTV Cameras:

The CCTV Developer/Manufacturer shall identify the entities in its supply chain for design manufacturing, quality assurance and supply of chips through an entity relationship diagram highlighting the role and relationship and details of various critical entities. The number of entities could be different for different technical architectures and business models. In some cases, these entities are different specialist contractors or expert agencies and in other cases, a single agency may perform all the operations. Broadly, these specialist contractors cover different entities of the life cycle stages of concept, design & development, production, utilization, support, retirement.

The security controls exercise by CCTV Developer/Manufacturer should be as per Essential Requirements – Technical specification. Detail artefacts, demonstrating compliance, declarations etc. shall be submitted to STQC in the form of Technical Construction File (TCF).

Steps for CCTV Cameras Certification Proces

CCTV Developer/Manufacturer to study Gadget Notification dated 6 Match, 2024 issued by MeitY to meets the requirements of Essential Requirements (Annexure A).
CCTV Developer/Manufacturer should prepare a detailed technical solution architecture demonstrating capability of CCTV Camera with Essential Requirements mentioned in Gadget Notification dated 6 Match, 2024 issued by MeitY.
Certification Body will evaluate document submitted and if found prima facie worthy of the proposed TCF, may schedule detailed technical review with presentation and discussion to explain architecture and its merit.
The CCTV Developer/Manufacturer should prepare themselves by developing secure-boot code, secure-update support, crypto library, test cases and required artifacts as defined in the Annexure A. Ensure to follow a secure engineering process to create the CCTV Camera.
CCTV Developer/Manufacturer shall prepare device design guidelines/instructions and provide necessary tools to be used by the device provider and this list should be part of TCF. (like tool to load device Firmware, IDE, guidelines to use Tamper protection etc).
CCTV Developer/Manufacturer applies to STQC for CCTV certification by submitting application and technical construction file (TCF). The contents of technical construction file should at least consists of
a) The artifacts defined in the Essential Requirements
b) Artifacts to be used for test cases for verification and validation purpose. (Engineering board, demo board etc)
CB may allocate the application number under the scheme and same will be communicated to Test Laboratory.
a) Based on application number, CCTV Developer/Manufacturer shall contact Test Laboratory for proposal, SRF, submission of charges and test samples.
b) Test laboratory shall evaluate the CCTV Cameras based on TCF submitted, Vendor shall provide necessary support as and when required by Test Laboratory.
c) CCTV Developer/Manufacturer should demonstrate testing and validation as defined under the demonstration section of the Essential Requirements.
d) Laboratory will submit the final test report including TCF review report to CB
e) Laboratory will also submit final TCF (if any change) for the TCF submitted by CCTV Developer/Manufacturer as per Essential Requirements.
The Certification body will appoint Assessor for this evaluation. They will be continuously associated with this evaluation on behalf of Certification body to oversee the evaluation including witness testing, review of observation report and preparation of Test Report etc.

Certificate

Certification committee evaluates compliances in holistic way and integrates information from all channels stated above. Based on compliances along with Certification Committee recommendation, certificate of approval is issued to CCTV Developer/Manufacturer

The validity of the certificate will be issued for three years from date of issue subjected to surveillance audit

Annexure-A TCF requirements for CCTV Cameras

Technical Construction File (TCF) submitted by CCTV developer/manufacturer to IoTSCS Certification Body shall document:

Compliance/demonstration/validation to ALL applicable clauses as per Essential Requirements mentioned in Gadget Notification dated 6 Match, 2024 issued by MeitY.

To create confidence on CCTVs, Manufacture shall maintain Technical Construction File having following information. Vendor need a provide information pertaining to the entire requirements mentioned below.

General

S.no	Requirements from Vendor	Details need to be provided
1	General description of IoT Device, usage of IoT device and environment of use

Certificates

S.no	Requirements from Vendor	Details need to be provided
1	Certificate for ISO 9001 (Scope should cover IoT Device Development, Manufacturing and Service (Manufacturer).
2	Certificate for ISO 9001 (Scope should cover IoT Device Supply of IoT Device (Supplier/ Distributor) if applicable.
3	Certificate of Incorporation (Manufacturer).
4	Certificate of Incorporation (Supplier).
5	Manufacturer authorization to supplier to place devices in Indian Market if applicable.

Also Read: ISI Mark Certification

Securing a CCTV (Closed-Circuit Television) system is crucial to protect sensitive information and ensure the system operates effectively. Key areas of testing include exposed network services, device communication protocols, physical access to the device’s UART, JTAG, SWD, etc., the ability to extract memory and firmware, firmware update process security and storage and encryption of data. Here are brief requirements for the security of a CCTV system:

Physical Security - Use tamper-resistant camera enclosures and locking mechanisms to deter physical tampering
Access Control by Authentication, Role-Based Access Control (RBAC) and regularly review and update access permissions to reflect personnel changes.
Network Security by employing encryption of data transmission
Software Security by Regular Updates, Disable Unused Features and Strong Password Policies
Penetration Testing: Employ penetration testing to assess the system's resistance to cyberattacks and address vulnerabilities.

The validity of the “Certificate of Approval” will be issued for three years from date of issue. Essential Security Requirements

Sr. No.	Category	Testing Parameter	What to be tested	Documents Required
1.1	Hardware Level Security Parameter (supported by software)	Verify that application layer debugging interfaces such as USB, UART, and other serial variants are disabled or protected by a complex password.	1. Identify debugging interfaces through the Datasheet of the SoC being used. 2. Verify and validate the ports/interfaces enabled in production devices and access control mechanisms. 3. Testing in presence of OEM team. 4. Process audit of the manufacturing facility.	a. Datasheet of the SoC. b. Documentation of enabled ports/interfaces and access control mechanisms. c. Manufacturing/Provisioning process flow.
1.2	Hardware Level Security Parameter	Verify that cryptographic keys and certificates are unique to each individual device.	1. Identify all keys and certificates being used. 2. Verify through testing, code review, and process audit of the key lifecycle.	a. List of all keys and certificates. b. Key management lifecycle details.
1.3	Hardware Level Security Parameter	Verify that on-chip debugging interfaces such as JTAG or SWD are disabled or that available protection mechanisms are enabled and configured appropriately.	1. Identify debugging interfaces through Datasheet. 2. Validate ports/interfaces and access control mechanisms. 3. Test with OEM team. 4. Process audit of the manufacturing facility.	a. Datasheet of the SoC. b. Documentation on enabled ports/interfaces and access control. c. Manufacturing/Provisioning process flow.
1.4	Hardware Level Security Parameter	Verify that trusted execution is implemente d and enabled, if available on the device SoC or CPU.	1. Identifying whether TEE/SE/TPM is available or not in the device through the SoC datasheet and technical documentation submitted by the vendor. Further assessment is done on the basis of scenarios as applicable to device as defined below: CASE 1: TEE/SE/TPM is not available: No further assessment CASE 2: TEE/SE/TPM is available and enabled: Verification through codepreview that crypto functions are called through TEE/SE/TPM APIs. CASE 3: TEE/SE/TPM is available but not enabled by the vendor: Termed as nonconformance to the requirement. OEM is required to enable and implement the TEE/SE/TPM.	a. Datasheet of the SoC being used in the device. b. User manual/ Technical specifications of the device c. Code snippets of the TEE API call, wherever applicable.
1.5	Hardware Level Security Parameter	Verify that sensitive data, private keys and certificates are stored securely in a Secure Element, TPM, TEE (Trusted Execution Environme nt), or protected using strong cryptograp hy.	Identifying all the keys and certificates being used in the device eco-system, sensitive data and their storage mechanism(s); and verification through: 1. Testing, in presence of OEM team. 2. Code review 3. Process audit of the key life cycle process	Vendor shall submit the following: 1. List of all keys and certificates being used in the device ecosystem 2. List of all the sensitive data with their intended usage and secure storage mechanism(s) as implemented along with secure configurations to be enabled in the device. 3. Key management life cycle (purpose, generation, storage, destruction/zeroiz ation, validity, key changeover/rotatio n) private keys and certificates.
1.6	Hardware Level Security Parameter	Verify the presence of tamper resistance and/or tamper detection features	Testing, in presence of OEM team, to verify the measures implemented in the device to prevent software and hardware tampering.	Vendor shall submit the following: 1. Measures available in the device to prevent software tampering. 2. Measures available in the device to prevent hardware tampering
1.7	Hardware Level Security Parameter	Verify that any available Intellectual Property protection technologie s provided by the chip manufactur er are enabled.	Testing, in presence of OEM team, to verify the enabling of the Intellectual Property protection technologies provided by the chip manufacturer, if available.	Vendor shall submit the following: 1. Datasheet of the SoC 2. Documentation regarding the Intellectual Property protection technologies provided by the chip manufacturer which have been enabled. 3. In case, no Intellectual Property protection technologies are being provided by the chip manufacturer, then a declaration stating the same.
1.8	Hardware Level Security Parameter	Verify the device validates the boot image signature before loading.	Testing, in presence of OEM team, to verify the following: 1. Device boots up successfully with the documented secure boot process when a valid boot image is provided. 2. Device does not boot up when a tampered boot image (like with missing signature, invalid signature) is provided.	Vendor shall submit the following: 1. Datasheet of the SoC 2. Technical specifications of the device regarding secure boot (should consist of keys involved and their management life cycle* , signature validation process and any other secure mechanisms if implemented.)
1.9	Hardware Level Security Parameter	Verify usage of cryptograp hically secure pseudo random number generator on embedded device (e.g., using chip provided random number generators)	Verification of the documentation provided by the vendor regarding the random number generators being used in the device. Verification through code preview that random number generators or related libraries as applicable are being used in the device.	Vendor shall submit the documentation regarding the random generators (either hardware based or software based or both) being used in the device with their intended usage. In case, hardware based random number generators are being used, vendors shall submit the following: 1. Datasheet of the Soc 2. Technical specifications of the device regarding random generator In case, software based random number generators are being used, vendors shall provide the libraries being used for the same.
2.1	Software/Firmware	Verify that memory protection controls such as ASLR and DEP are enabled by the operating system, if applicable.	Testing in presence of OEM team using tools like DEP, EMET.	Vendor shall submit the declaration of the memory protection controls available and enabled in the device
2.2	Software/Firmware	Verify that the firmware apps protect data-in-transit using transport layer security.	1. Verify secure TLS version and strong encryption algorithms. 2. Validate server's TLS certificate. 3. Test vulnerabilities like weak cipher suites and padding oracle attacks.	Specifications and documentation on transport layer security configurations.
2.3	Software/Firmware	Verify that the firmware apps validate the digital signature of server connections.	1. Verify security features like strong cipher suites, TLS versions, and SSL pinning. 2. Validate certificates for chain validation and revocation checks.	Documentation on the security features of server connections and digital signatures.
2.4	Software/Firmware	Verify that any use of banned C functions is replaced with appropriate safe equivalent functions.	Secure code review using static analysis tools with OEM team participation.	Firmware binaries and internal code review reports.
2.5	Software/Firmware	Verify that each firmware maintains a software bill of materials cataloging third-party components, versioning, and published vulnerabilities.	1. Analyze third-party components for vulnerabilities using public databases. 2. Verify process for regular security updates.	a. Software bill of materials documentation. b. Policies for addressing vulnerabilities and issuing updates.
2.6	Software/Firmware	Verify that all code, including third-party binaries, libraries, and frameworks, are reviewed for hardcoded credentials (backdoors).	Secure code review using static analysis tools with OEM team participation.	Firmware binaries and internal code review reports.
2.7	Software/Firmware	Verify that the firmware apps pin the digital signature to a trusted server(s).	1. Verify security features like SSL pinning, strong cipher suites, and TLS validation. 2. Ensure proper certificate validation.	Use case documentation and security measures for digital signature validation.
2.8	Software/Firmware	Verify that security controls are in place to hinder firmware reverse engineering (e.g., removal of verbose debugging symbols).	Testing in presence of OEM team to verify anti-reverse-engineering measures.	Documentation on security controls implemented to prevent reverse engineering.
2.9	Software/Firmware	Verify that the firmware update process is not vulnerable to time-of-check vs time-of-use attacks.	Testing in presence of OEM team to ensure resistance to such attacks.	Documentation of measures implemented to prevent such attacks.
2.10	Software/Firmware	Verify that the device uses code signing and validates firmware upgrade files before installing.	1. Device updates successfully with valid packages. 2. Device rejects tampered or invalid packages.	Process for secure firmware upgrades, including key management lifecycle.
2.11	Software/Firmware	Verify that the device cannot be downgraded to old versions (anti-rollback) of valid firmware.	Testing in presence of OEM team to ensure anti-rollback mechanisms.	Process for achieving secure firmware upgrades with anti-rollback measures.
2.12	Software/Firmware	Verify that firmware can perform automatic firmware updates upon a predefined schedule.	Case 1: Automatic OTA updates available – Submit SOP for automatic updates. Case 2: Manual updates only – Submit SOP for manual updates.	Modes of updates (automatic/manual) and organizational policies for updates.
3.1	Secure Process Conformance	Verify that wireless communications are mutually authenticated.	Testing in presence of OEM team to verify mutual authentication processes.	Documentation of mutual authentication processes implemented.
3.2	Secure Process Conformance	Verify that wireless communications are sent over an encrypted channel.	Identify security mechanisms used in communication. Verify through testing, code review, and process audit.	Documentation on encryption mechanisms used in wireless communication.
3.3	Secure Process Conformance	Verify that trusted sources are being used for sourcing the components of the device.	Submit a Bill of Materials for critical hardware components related to security functions like SoC.	Bill of Materials for critical hardware components.
3.4	Secure Process Conformance	Supply chain risk identification, assessment, prioritization, and mitigation.	Submit supply chain risk planning and mitigation documents.	Supply chain risk documents, planning policies, and post-incident summaries.
3.5	Secure Process Conformance	Verify that no proprietary network protocols are being used in the device.	Submit documentation for all network protocols used. If proprietary, provide complete implementation details and source code.	Documentation on network protocols and source code (if proprietary).
4.1	Security Conformance at Product Development Stage	Provide design and architecture details till the PCBA and SoC level to aid in counterfeit mitigation and malware detection.	Submit design and architecture documents covering PCBA and SoC level details.	Design and architecture documents till PCBA and SoC level.
4.2	Security Conformance at Product Development Stage	Implement threat mitigation strategies for tainted and counterfeit products.	Submit process and method artifacts demonstrating threat mitigation strategies.	Threat mitigation strategies and supporting documentation.
4.3	Security Conformance at Product Development Stage	Deploy one or more up-to-date malware detection tools as part of the code acceptance and development process.	1. Submit a list of components requiring tracking as tainting/counterfeiting targets. 2. Demonstrate quality assurance processes, including scanning of finished products and components for malware.	a. Malware detection process documentation. b. Quality assurance process artifacts and tracking targets.
4.4	Security Conformance at Product Development Stage	Conduct supply chain risk identification, assessment, prioritization, and mitigation.	Submit supply chain risk planning, business continuity policies, and post-incident summary documents.	a. Supply chain risk/business continuity planning policies. b. Playbooks reflecting incident handling and mitigation. c. Post-incident summary documents.

WHY USE ABSOLUTE VERITAS (AV) FOR STQC CERTIFICATION?

If you require STQC Registration services, please contact Absolute Veritas.

Absolute Veritas is a prominent organisation from the private sector of India primarily dealing with the Inspection, Testing, Audits, Certification of products& consulting services to various industries in India and worldwide, ensuring compliance with regulatory standards and industry requirements. Offering a comprehensive range of services including product certification, testing, training, auditing, and compliance services, Absolute Veritas helps manufacturers and importers achieve higher production efficiency and quality standards.

Absolute Veritas (AV) will handle end to end pre-registration request, sample preparation, documentation, testing and application process for STQC Certification

For any questions regarding the most recent update on STQC registration licenses, please reach out to us via email at cs@absoluteveritas.com