|
MINISTRY OF PUBLIC SECURITY OF VIETNAM |
SOCIALIST REPUBLIC OF VIETNAM |
|
No. 48/2026/TT-BCA |
Hanoi, May 12, 2026 |
NATIONAL TECHNICAL REGULATION FOR SURVEILLANCE CAMERA USING INTERNET PROTOCOL – BASELINE CYBERSECURITY REQUIREMENTS
Pursuant to the Law on Standards and technical Regulations No. 68/2006/QH11 amended by the Law No. 35/2018/QH14 and the Law No. 70/2025/QH15;
Pursuant to the Law on Cybersecurity No. 116/2025/QH15;
Pursuant to Decree No. 22/2026/ND-CP dated January 16, 2026 of the Government elaborating the Law on Standards and Technical Regulations;
Pursuant to Decree No. 02/2025/ND-CP dated February 18, 2025 of the Government on functions, tasks, powers, and organizational structures of the Ministry of Public Security amended by Decree No. 11/2025/ND-CP dated July 1, 2025 of the Government;
At request of Director of Department of Cybersecurity and Hi-tech Crimes;
The Minister of Public Security promulgates Circular on National Technical Regulation for Surveillance Camera using Internet Protocol – Baseline Cybersecurity Requirements.
Article 1. The National Technical Regulation for Surveillance Camera using Internet Protocol – Baseline Cybersecurity Requirements – QCVN 11:2026/BCA is attached hereto.
1. This Circular comes into force from July 01, 2026.
2. Circular No. 21/2024/TT-BTTTT dated December 31, 2024 of the Minister of Information and Communications on National Technical Regulation on Surveillance Camera using Internet Protocol – Baseline Cybersecurity Requirements (QCVN 135:2024/BTTTT) expires from the effective hereof.
3. Declaration of conformity to regulations for products and goods under QCVN 11:2026/BCA shall be adopted after the Ministry of Public Security promulgates List of products and goods with average and high risk levels under their management.
1. The Director of Department of Cybersecurity and Hi-tech Crimes has the responsibility to monitor, examine, and expedite the implementation of this Circular.
2. Department of Science, Strategy and History of Public Security has the responsibility to arrange popularization hereof for relevant agencies, organizations, and individuals and designate assessing bodies for conformity to this document as per the law.
3. Department of Science, Strategy and History of Public Security has the responsibility to periodically update, share list of organizations, individuals and surveillance cameras that have been successfully declared for conformity to Department of Cybersecurity and Hi-tech Crimes, and police forces of relevant entities and local governments for management as per the law.
4. Figureheads of entities affiliated to ministerial agencies, directors of police authorities of provinces and central-affiliated cities, and relevant agencies, organizations, and individuals are responsible for the implementation of this Circular.
Difficulties that arise during implementation of this Circular should be reported to the Ministry of Public Security (via Department of Cybersecurity and Hi-tech Crimes) for timely guidance./.
|
MINISTER General Luong Tam Quang |
NATIONAL TECHNICAL REGULATION FOR SURVEILLANCE CAMERA USING INTERNET PROTOCOL – BASELINE CYBERSECURITY REQUIREMENTS
Foreword
The QCVN 11:2026/BCA is compiled by the Department of Cybersecurity and Hi-tech Crimes, submitted by the Department of Science, Strategy and History of Public Security, inspected by the Ministry of Science and Technology, and promulgated by the Ministry of Public Security under Circular No. …/2026/TT-BCA dated ……… 2026.
Table of Contents
Foreword
1. GENERAL PROVISIONS
1.1. Scope
1.2. Regulated entities
1.3. Reference documents
1.4. Acronyms and abbreviations
1.5. Definitions
2. TECHNICAL PROVISIONS
2.1. Initialization of unique per device password
2.1.1. Requirement 2.1.1
2.1.2. Requirement 2.1.2
2.1.3. Requirement 2.1.3
2.1.4. Requirement 2.1.4
2.1.5. Requirement 2.1.5
2.2. Management of security vulnerabilities
2.2.1. Requirement 2.2.1
2.3. Management of update
2.3.1. Requirement 2.3.1
2.3.2. Requirement 2.3.2
2.3.3. Requirement 2.3.3
2.3.4. Requirement 2.3.4
2.3.5. Requirement 2.3.5
2.3.6. Requirement 2.3.6
2.3.7. Requirement 2.3.7
2.4. Storage of sensitive security parameter
2.4.1. Requirement 2.4.1
2.4.2. Requirement 2.4.2
2.4.3. Requirement 2.4.3
2.4.4. Requirement 2.4.4
2.5. Management of secured communication channels
2.5.1. Requirement 2.5.1
2.5.2. Requirement 2.5.2
2.5.3. Requirement 2.5.3
2.5.4. Requirement 2.5.4
2.6. Protection from attack via minimizing attack surfaces
2.6.1. Requirement 2.6.1
2.6.2. Requirement 2.6.2
2.6.3. Requirement 2.6.3
2.7. Protection of user data
2.7.1. Requirement 2.7.1
2.7.2. Requirement 2.7.2
2.8 Ability to restore normal operation after outage
2.8.1. Requirement 2.8.1
2.8.2. Requirement 2.8.2
2.8.3. Requirement 2.8.3
2.9. Erasure of data on surveillance camera
2.9.1. Requirement 2.9.1
2.10. Validation of input data
2.10.1. Requirement 2.10.1
2.11. Protection of data on surveillance camera.
2.11.1. Requirement 2.11.1
2.11.2. Requirement 2.11.2
2.11.3. Requirement 2.11.3
2.11.4. Requirement 2.11.4
2.11.5. Requirement 2.11.5
3. MEASUREMENT METHOD
3.1. Creation of unique per device password
3.1.1. Test group for requirement 2.1.1
3.1.2. Test group for requirement 2.1.2
3.1.3. Test group for requirement 2.1.3
3.1.4. Test group for requirement 2.1.4
3.1.5. Test group for requirement 2.1.5
3.2. Management of security vulnerabilities
3.2.1. Test group for requirement 2.2.1
3.3. Management of update
3.3.1. Test group for requirement 2.3.1
3.3.2. Test group for requirement 2.3.2
3.3.3. Test group for requirement 2.3.3
3.3.4. Test group for requirement 2.3.4
3.3.5. Test group for requirement 2.3.5
3.3.6. Test group for requirement 2.3.6
3.3.7. Test group for requirement 2.3.7
3.4. Storage of critical security parameter
3.4.1. Test group for requirement 2.4.1
3.4.2. Test group for requirement 2.4.2
3.4.3. Test group for requirement 2.4.3
3.4.4. Test group for requirement 2.4.4
3.5. Management of secured communication channels
3.5.1. Test group for requirement 2.5.1
3.5.2. Test group for requirement 2.5.2
3.5.3. Test group for requirement 2.5.3
3.5.4. Test group for requirement 2.5.4
3.6. Protection from attack via minimizing attack surfaces
3.6.1. Test group for requirement 2.6.1
3.6.2. Test group for requirement 2.6.2
3.6.3. Test group for requirement 2.6.3
3.7. Protection of user data
3.7.1. Test group for requirement 2.7.1
3.7.2. Test group for requirement 2.7.2
3.8. Ability to restore normal system operation after outage
3.8.1. Test group for requirement 2.8.1
3.8.2. Test group for requirement 2.8.2
3.8.3. Test group for requirement 2.8.3
3.9. Erasure of data on surveillance camera
3.9.1. Test group for requirement 2.9.1
3.10. Validation of input data
3.10.1. Test group for requirement 2.10.1
3.11. Protection of data on surveillance camera
3.11.1. Test group for requirement 2.11.1
3.11.2. Test group for requirement 2.11.2
3.11.3. Test group for requirement 2.11.3
3.11.4. Test group for requirement 2.11.4
3.11.5. Test group for requirement 2.11.5
4. REGULATIONS ON MANAGEMENT
Appendix A List of information for assessment
NATIONAL TECHNICAL REGULATION FOR SURVEILLANCE CAMERA USING INTERNET PROTOCOL – BASELINE CYBERSECURITY REQUIREMENTS
This Regulation prescribes baseline technical requirements for surveillance cameras using Internet protocol (hereinafter referred to as “camera devices”) manufactured and sold in Vietnamese market.
This Regulation applies to Vietnamese and foreign organizations, individuals in Vietnamese territory that are engaged in production and trade (including import) of camera devices regulated by this document.
ETSI EN 303 645 V2.1.1 (2020-06) “Cyber; Cybersecurity for Consumer Internet of Things: Baseline Requirements”.
ETSI TS 103 701 v1.11 (2021-08) “Cyber; Cybersecurity for Consumer Internet of Things: Conformance Assessment of Baseline Requirements”
1.4. Acronyms and abbreviations
| AES | Advanced Encryption Standard | Tiêu chuẩn mã hóa tiên tiến |
| API | Application Programming Interface | Giao diện lập trình ứng dụng |
| IP | Internet Protocol | Giao thức Internet |
| ISO | International Organization for Standardization | Tổ chức Tiêu chuẩn hóa Quốc tế |
| IXIT | Implementation eXtra Information for Testing | Thông tin triển khai bổ sung cho kiểm thử |
| ICS | Implementation Conformance Statement | Tuyên bố phù hợp triển khai |
| MAC | Media Access Control | Điều khiển truy cập môi trường |
The following definitions are used hereunder:
1.5.1. Associated services
Refer to digital services that, together with the camera device, provide additional expanded functionalities of the device.
Example 1: Associated services can include mobile applications, cloud computing/storage and third party Application Programming Interfaces (APIs).
Example 2: A device transmits telemetry data to a third-party service chosen by the device manufacturer. This service is an associated service.
1.5.2. Authentication mechanism
Refers to a method used to prove the authenticity of an entity.
1.5.3. Authentication value
Refers to individual value of an attribute used by an authentication mechanism.
Example: When the authentication mechanism is to request a password, the authentication value can be a character string. When the authentication mechanism is a biometric fingerprint recognition, the authentication value can be the index fingerprint of the left hand.
1.5.4. Best practice cryptography
Refers to cryptography that is suitable for the corresponding use case and has no indications of a feasible attack with current readily available techniques.
Example: The device manufacturer uses a communication protocol and cryptographic library provided with the IoT platform and where that library and protocol have been assessed against feasible attacks.
1.5.5. Support period
Refers to minimum length of time, expressed as a period or by an end-date, for which a manufacturer will provide security updates.
1.5.6. Device manufacturer
Refers to entity that creates an assembled final consumer IoT product, which is likely to contain the products and components of many other suppliers.
1.5.7. Factory default
Refers to state of the device after factory reset or after final production/assembly.
NOTE: This includes the physical device and software (including firmware) that is present on it after assembly.
1.5.8. Manufacturer
Refers to relevant economic operator in the supply chain (including the device manufacturer).
NOTE: Beyond the device manufacturer, such entities can also be: importers, distributors, integrators, component and platform providers, software providers, IT and telecommunications service providers, managed service providers and providers of associated services.
1.5.9. Sensing capability
Refers to functionality of camera device that collects data pertaining to surrounding environment such as: Image data; audio data; biometric data; location data, etc.
1.5.10. Hard-code
Refers to data input directly into source code of software.
1.5.11. Telemetry data
Refers to device data that help manufacturer identify issues or information relating to device use.
Example: A camera device reports software errors to manufacturer in order for the manufacturer to identify and rectify the errors.
1.5.12. Unique per device
Refers to value unique for each individual device of a given product class or type.
1.5.13. Debug
Refers to interaction and communication commands with camera devices in order to develop functions or find device errors.
1.5.14. Debug interface
Refers to physical interface used by the manufacturer to communicate with the device during development or to perform triage of issues with the device and that is not used as part of the consumer-facing functionality.
1.5.15. Logical interface
Refers to a network interface for communicating over the network via channels or ports.
1.5.16. Network interface
Refers to physical interface that can be used to access the functionality of consumer IoT via a network.
1.5.17. Physical interface
Refers to a physical port or air interface (such as radio, audio or optical) used to communicate with the device at the physical layer.
Example: Ethernet ports, serial interfaces such as USB; Wifi ports.
1.5.18. Initial password
Refers to a password created when user logs onto the device for the first time.
1.5.19. Default password
Refers to a password initialized by default when the device is manufactured.
1.5.20. Initialization
Refers to process that activates the network connectivity of the device for operation and optionally sets authentication features for a user or for network access.
1.5.21. Critical security parameter
Refers to security-related secret information whose disclosure or modification can compromise the security of a security module.
Example: Secret cryptographic keys, authentication values such as passwords, PINs, private components of certificates.
1.5.22. Public security parameter
Refers to security related public information whose modification can compromise the security of a security module.
Example: Public components of certificates.
1.5.23. Sensitive security parameter
Refers to critical security parameters and public security parameters.
1.5.24. Security module
Refers to a set of hardware, software, and/or firmware that implements security functions.
1.5.25. Security update
Refers to software update that addresses security vulnerabilities either discovered by or reported to the manufacturer.
1.5.26. Software service
Refers to a software component of a device that is used to support functionality.
Example: A runtime for the programming language used within the device software or a daemon that exposes an API used by the device software, e.g. a cryptographic module’s API.
1.5.27. Initialized state
Refers to state of the device after initialization.
1.5.28. Remotely accessible
Refers to device access from outside the local network.
1.5.29. Implementation Conformance statement
Refers to a statement made by manufacturer pertaining to possibilities implemented or supported by camera device.
1.5.30. Implementation Conformance Statement (ICS) pro forma
Refers to a document in form of a questionnaire used to develop Implementation Conformance statement for camera device.
1.5.31. Implementation eXtra Information for Testing
Refers to record which contains or references all of the information (in addition to that given in the ICS) related to the camera device and its assessment environment, which will enable the test laboratory to perform appropriate test activities.
1.5.32. Implementation eXtra Information for Testing (IXIT) pro forma
Refers to a document, in the form of a questionnaire, which when completed for a camera device becomes the IXIT.
1.5.33. Indication
Refers to a documented finding by the test laboratory used inside the assessment to assign a verdict.
1.5.34. Security guarantee
Refers to statement of the addressed security objectives.
NOTE: Under this document, security guarantees are used in an IXIT to describe the security objectives which are realized by an implementation or process.
1.5.35. Test group
Refers to named set of related test cases that describe how to assess the conformance of the DUT to a single provision as specified hereunder.
NOTE: The naming of test groups and their corresponding provisions coincide.
1.5.36. Test group objective
Refers to prose description of the common objective which the test purposes within a specific test group are designed to achieve.
1.5.37. Test purpose
Refers to prose description of a well-defined purpose of assessment, focusing on a single conformance requirement or a set of related conformance requirements.
1.5.38. Test scenario
Refers to a named set of related test groups that describe how to assess the conformance of the camera device to a corresponding set of provisions as specified hereunder.
1.5.39. External evidence
Refers to existing security certifications or third party evaluations of parts of the camera device which may be used partially as evidence for the conformance to reduce the effort of the assessment.
1.5.40. Test cases Conceptual
Refers to an assessment that determines level of conformance of IXI pro forma to requirements as specified hereunder.
1.5.41. Test cases functional
Refers to an assessment that determines level of conformance of implemented functions of camera device, including relationship between these functions and associated services and/or development, management procedures according to requirements as specified hereunder in service of proof of conformance in implementation.
1.5.42. Surveillance Camera using Internet Protocol
Refers to a camera device using internet protocol and is a digital camera, capable of connecting via internet protocol for monitoring and recording visuals.
2.1. Initialization of unique per device password
2.1.1. Requirement 2.1.1
Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user.
2.1.2. Requirement 2.1.2
Passwords of camera devices shall be pre-installed by manufacturers and generated with a mechanism that reduces the risk of automated attacks against a class or type of device.
2.1.3. Requirement 2.1.3
Authentication mechanisms used to authenticate users against a device shall use best practice cryptography, appropriate to the properties of the technology, risk and usage
2.1.4. Requirement 2.1.4
Camera device shall provide to the user or an administrator a simple mechanism to change the authentication value used
2.1.5. Requirement 2.1.5
Camera device shall have a mechanism available which makes brute-force attacks on authentication mechanisms via network interfaces impracticable.
2.2. Management of security vulnerabilities
2.2.1. Requirement 2.2.1
Manufacturer shall make a vulnerability disclosure policy publicly available. This policy shall include, at a minimum:
1) Contact information for the reporting of issues;
2) Information on timelines for:
2.1) Initial acknowledgement of receipt; and
2.2) Status updates until the resolution of the reported issues.
2.3.1. Requirement 2.3.1
Camera device shall have mechanism that notifies user when an update is available and assists update, installation of new software securely.
2.3.2. Requirement 2.3.2
Camera device shall have mechanism that allows user to update software.
2.3.3. Requirement 2.3.3
Camera device shall use best practice cryptography to facilitate secure update mechanisms.
2.3.4. Requirement 2.3.4
The manufacturer shall adopt policy and procedures for securely providing updates.
2.3.5. Requirement 2.3.5
Camera device shall verify the authenticity and integrity of each update via a trust relationship.
2.3.6. Requirement 2.3.6
The manufacturer shall publish, in an accessible way that is clear and transparent to the user, the defined support period.
2.3.7. Requirement 2.3.7
The model designation of the camera device shall be clearly recognizable, either by labeling on the camera device or via a physical interface.
2.4. Storage of critical security parameter
2.4.1. Requirement 2.4.1
Sensitive security parameters in persistent storage shall be stored securely by the device.
2.4.2. Requirement 2.4.2
Where a hard-coded unique per device identity is used in a device for security purposes, it shall be implemented in such a way that it resists tampering by means such as physical, electrical or software.
2.4.3. Requirement 2.4.3
Hard-coded critical security parameters in device software source code shall have protective measures and appropriate use purposes.
2.4.4. Requirement 2.4.4
Any critical security parameters used for integrity and authenticity checks of software updates and for protection of communication with associated services in device software shall be unique per device and shall be produced with a mechanism that reduces the risk of automated attacks against classes of devices.
2.5. Management of secured communication channels
2.5.1. Requirement 2.5.1
Camera device shall use best practice cryptography to communicate securely.
2.5.2. Requirement 2.5.2
Camera device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. Protocols that are an exception include ARP; DHCP; DNS; ICMP; and NTP.
Example: Security-relevant changes include permission management, configuration of network keys and password changes.
2.5.3. Requirement 2.5.3
Camera device shall protect the confidentiality of critical security parameters that are communicated via remotely accessible network interfaces.
2.5.4. Requirement 2.5.4
The manufacturer shall follow secure management processes for critical security parameters that relate to the device.
2.6. Protection from attack via minimizing attack surfaces
2.6.1. Requirement 2.6.1
All unused network and logical interfaces shall be disabled.
2.6.2. Requirement 2.6.2
In the initialized state, the network interfaces of the device shall minimize the unauthenticated disclosure of security-relevant information.
2.6.3. Requirement 2.6.3
Where a debug interface is physically accessible, it shall be disabled in software.
2.7.1. Requirement 2.7.1
The confidentiality of sensitive personal data communicated between the camera device and associated services shall be protected, with cryptography appropriate to the properties of the technology and usage.
2.7.2. Requirement 2.7.2
All external sensing capabilities of the camera device shall be documented in an accessible way that is clear and transparent for the user.
2.8. Ability to restore normal operation after outage
2.8.1. Requirement 2.8.1
Camera device shall have resilience mechanism taking into account the possibility of outages of data networks and power.
2.8.2. Requirement 2.8.2
Camera device should recover in the case of restoration of a loss of data networks and power.
2.8.3. Requirement 2.8.3
Camera device should connect to networks in an expected, operational and stable state and in an orderly fashion.
2.9. Erasure of data on surveillance camera
2.9.1. Requirement 2.9.1
User shall be provided with functionality such that user data can be erased from the camera device.
2.10. Validation of input data
2.10.1. Requirement 2.10.1
Camera device shall validate data input via user interfaces or transferred via Application Programming Interfaces (APIs) or between networks in services and devices.
2.11. Protection of data on surveillance camera
2.11.1. Requirement 2.11.1
Manufacturer shall provide consumers with clear and transparent information about purposes, how personal data is collected, processed and storage of personal data collected, processed by camera device, associated services, or third parties (if any).
2.11.2. Requirement 2.11.2
Camera device shall have function that verifies consent of user to allow camera device to collect and process personal data.
2.11.3. Requirement 2.11.3
Consumers who gave consent for the processing of their personal data shall have the capability to withdraw it at any time.
2.11.4. Requirement 2.11.4
If telemetry data is collected from consumer IoT devices and services, consumers shall be provided with information on what telemetry data is collected, how it is being used, by whom, and for what purposes.
2.11.5. Requirement 2.11.5
Camera device shall allow configuration for data storage in Vietnam.
3.1. Initialization of unique per device password
3.1.1. Test group for requirement 2.1.1
3.1.1.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.1.1 hereof
This test group applies to all status of camera device except for factory default.
3.1.1.2 Test case Conceptual
3.1.1.2.1. Test purposes
Assess conceptual conformance for verification mechanism based on password.
3.1.1.2.2. Test method
Test laboratory shall assess for all password-based user authentication mechanisms in IXIT 1-AuthMech where passwords are not defined by the user according to “Authentication Factor” and used in any state other than the factory default whether the “Password Generation Mechanism” ensures that passwords are unique per device.
3.1.1.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) Each password of a password-based authentication mechanism being used in any state other than the factory default, that is not defined by the user, is unique per device.
2) The verdict Fail is assigned if requirement above is not met.
3.1.1.3. Test case Functional
3.1.1.3.1. Test purpose
Assess conformance of the password-based authentication mechanisms concerning the completeness of the IXIT documentation (Section 1 under 3.1.1.3.2), the passwords defined by the user (Section 2 under 3.1.1.3.2) and the generation mechanisms (Section 3 under 3.1.1.3.2).
3.1.1.3.2. Test method
1) Test laboratory shall functionally assess whether password-based authentication mechanisms that are not documented in IXIT 1-AuthMech are available via a network interface on the camera device or described in the user manual.
2) For each password-based user authentication mechanism in IXIT 1-AuthMech, test laboratory shall functionally check whether the user is required to define all passwords that are user-defined according to “Authentication Factor” before being used.
3) Test laboratory shall functionally assess whether all passwords of the camera device, that are not defined by the user according to “Authentication Factor” in IXIT 1-AuthMech and used in any state other than the factory default, do not violate the description of the “Password Generation Mechanism”.
3.1.1.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) Every discovered password-based authentication mechanism is documented in the IXIT.
1.2) The user is required to define all passwords before being used, that are stated as defined by the user in the IXIT.
1.3) There is no indication that the generation of a not user-defined password of the camera device used in any state other than the factory default differs from the generation mechanism described in the IXIT.
2) Fail: If any of the requirements above is not met.
3.1.2. Test group for requirement 2.1.2
3.1.2.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.1.2 hereof
3.1.2.2 Test cases Conceptual
3.1.2.2.1. Test purposes
Conceptual assessment of the generation mechanisms of pre-installed passwords.
3.1.2.2.2. Test method
1) Assess for each authentication mechanism in IXIT 1-AuthMech using pre-installed passwords according to “Authentication Factor”, whether the generation mechanism in “Password Generation Mechanism” induces obvious regularities in the resulting passwords.
2) assess whether the generation mechanism induces common strings or other common patterns in the resulting passwords.
3) assess whether the generation mechanism induces passwords, that are related in an obvious way to public information.
4) assess whether the generation mechanism induces passwords, that are considered appropriate in terms of complexity.
3.1.2.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) No obvious regularities in pre-installed passwords are found;
1.2) No common strings or other common patterns in pre-installed passwords are found;
1.3) The generation mechanisms for pre-installed passwords do not induce passwords, that are related in an obvious way to public information;
1.4) The generation mechanisms for pre-installed passwords are considered appropriate in terms of complexity.
2) Fail: If any of the requirements above is not met.
3.1.2.3. Test case Functional
3.1.2.3.1. Test purposes
Functional assessment of the generation mechanisms of pre-installed passwords.
3.1.2.3.2. Test method
For each authentication mechanism in IXIT 1-AuthMech using pre-installed passwords according to “Authentication Factor”, the TL shall functionally assess whether the generation mechanism is plausibly implemented in accordance to the description in “Password Generation Mechanism”.
3.1.2.3.3. Assignment of verdict
1) A verdict Pass is assigned if: for each pre-installed password there is no indication, that its generation differs from the generation mechanism described in the IXIT.
2) The verdict Fail is assigned if the requirement above is not met.
3.1.3. Test group for requirement 2.1.3
3.1.3.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.1.3 hereof.
The objective of this test group is to assess whether the cryptographic methods are not known to be vulnerable to a feasible attack.
3.1.3.2 Test cases Conceptual
3.1.3.2.1. Test purposes
The purpose of this test case is the conceptual assessment of the cryptography used for the authentication mechanisms concerning the use of best practice cryptography (Sections 1, 2, 3 under 3.1, 3.2.2) and the vulnerability to a feasible attack (Section 4 under 3.1.3.2.2).
3.1.3.2.2. Test method
1) For each authentication mechanism in IXIT 1-AuthMech used to authenticate users against the camera device, the test laboratory shall assess whether the “Security Guarantees” are appropriate for the use case of user authentication, at least integrity and authenticity are required to be fulfilled.
2) For each authentication mechanism in IXIT 1-AuthMech used to authenticate users against the camera device, the test laboratory shall assess whether the mechanism according to “Description” is appropriate to achieve the “Security Guarantees”.
3) For each authentication mechanism in IXIT 1-AuthMech used to authenticate users against the camera device, the test laboratory shall assess whether the “Cryptographic Details” are considered as best practice cryptography for the use case of user authentication based on technical standards, technical regulations of relevant authorities or equivalent international standards. If “Cryptographic Details” are not included in a reference catalogue for the corresponding use case (e.g. novel cryptography), the supplier organization shall provide evidences, e.g. a risk analysis, to justify the cryptography is appropriate as best practice for the use case. In such case the test laboratory shall assess whether the evidence is appropriate and reliable for the use case.
4) For each authentication mechanism in IXIT 1-AuthMech used to authenticate users against the camera device, the test laboratory shall assess whether the “Cryptographic Details” are not known to be vulnerable to a feasible attack for the desired security property on the base of the “Security Guarantees” by reference to competent cryptanalytic reports.
3.1.3.2.3. Assignment of verdict
1) The verdict Pass is assigned if for all user authentication mechanisms:
1.1) The “Security Guarantees” are appropriate for the use case of user authentication;
1.2) The mechanism is appropriate to achieve the “Security Guarantees” with respect to the use case;
1.3) All used “Cryptographic Details” are considered as best practice for the use case;
1.4) All used “Cryptographic Details” are not known to be vulnerable to a feasible attack for the desired security property.
2) Fail: If any of the requirements above is not met.
3.1.3.3. Test case Functional
3.1.3.3.1. Test purposes
Functional assessment of the cryptography used for the authentication mechanisms.
3.1.3.3.2. Test method
For each authentication mechanism in IXIT 1-AuthMech used to authenticate users against the camera device, the test laboratory shall functionally assess whether the described “Cryptographic Details” are used by the camera device.
3.1.3.3.3. Assignment of verdict
1) The verdict Pass is assigned if: there is no indication that any used cryptographic setting differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.1.4. Test group for requirement 2.1.4
3.1.4.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.1.4 hereof.
3.1.4.2 Test cases Conceptual
3.1.4.2.1. Test purposes
Conceptual assessment of the mechanisms to change authentication values.
3.1.4.2.2. Test method
Test laboratory shall assess whether for every authentication mechanism in IXIT 1-AuthMech where “Description” indicates that the mechanism is used for user authentication, the resource of “Documentation of Change Mechanisms” in IXIT 2-UserInfo considers the mechanism and describes how to change the authentication value for the mechanism in a manner that is understandable for a user with limited technical knowledge.
3.1.4.2.3. Assignment of verdict
1) The verdict Pass is assigned if: for all user based authentication mechanisms the published resource describes how to change the authentication value with a simple mechanism.
2) The verdict Fail is assigned if the requirement above is not met.
3.1.4.3. Test case Functional
3.1.4.3.1. Test purposes
Functional assessment of the mechanisms to change authentication values.
3.1.4.3.2. Test method
1) Test laboratory shall perform a change of the authentication values for all user authentication mechanisms in IXIT 1-AuthMech as documented in the resource from “Documentation of Change Mechanisms” in IXIT 2-UserInfo.
2) Test laboratory shall functionally assess whether all changes of user authentication values are successful.
3.1.4.3.3. Assignment of verdict
1) The verdict Pass is assigned if: all mechanisms for the user to change authentication values for user authentication mechanisms work as described.
2) The verdict Fail is assigned if the requirement above is not met.
3.1.5. Test group for requirement 2.1.5
3.1.5.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.1.5 hereof.
3.1.5.2 Test cases Conceptual
3.1.5.2.1. Test purposes
Conceptual assessment of the mechanisms to make brute force attacks via network interfaces impracticable.
3.1.5.2.2. Test method
Test laboratory shall assess whether for each authentication mechanism in IXIT 1-AuthMech, where “Description” indicates that the mechanism is directly addressable via a network interface, the mechanism in “Brute Force Prevention” makes brute force attacks via network interfaces impracticable.
3.1.5.2.3. Assignment of verdict
1) The verdict Pass is assigned if: The documented mechanisms make brute force attacks via network interfaces impracticable.
2) The verdict Fail is assigned if the requirement above is not met.
3.1.5.3. Test case Functional
3.1.5.3.1. Test purposes
Functional assessment of the mechanisms to make brute force attacks via network interfaces impracticable concerning the completeness of the IXIT documentation (Section 1 under 3.1.5.3.2) and the corresponding mechanisms (Section 2 under 3.1.5.3.2).
3.1.5.3.2. Test method
1) Test laboratory shall functionally assess whether there exist further network-based authentication mechanisms, that are not listed in IXIT 1-AuthMech.
2) Test laboratory shall attempt to brute force every network-based authentication mechanisms described in IXIT 1-AuthMech.
3.1.5.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) ever discovered network-based authentication mechanism is documented in the IXIT 1-AuthMech.
1.2) For all authentication mechanism via network interfaces there is no indication that the implementation of brute force prevention differs from its IXIT documentation.
2) Fail: If any of the requirements above is not met.
3.2. Management of security vulnerabilities
3.2.1. Test group for requirement 2.2.1
3.2.1.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.2.1 hereof.
3.2.1.2 Test cases Conceptual
3.2.1.2.1. Test purposes
Conceptual assessment of the publication of the vulnerability disclosure policy.
3.2.1.2.2. Test method
Test laboratory shall assess whether access to the publication as described in “Publication of Vulnerability Disclosure Policy” in IXIT 2-UserInfo is possible without meeting criteria such as user account, i.e. whether anybody can access the documentation.
3.2.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if: the publication of the vulnerability disclosure policy is available for anybody.
2) The verdict Fail is assigned if the requirement above is not met.
3.2.1.3. Test case Functional
3.2.1.3.1. Test purposes
Functional assessment of the publication of the vulnerability disclosure policy.
3.2.1.3.2. Test method
1) Test laboratory shall functionally check whether the vulnerability disclosure policy is publicly accessible as described in “Publication of Vulnerability Disclosure Policy” in IXIT 2-UserInfo.
2) Test laboratory shall functionally check whether the policy contains:
2.1) Contact information;
2.2) Information on timelines regarding acknowledgement of receipt and status updates.
3.2.1.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.2) The vulnerability disclosure policy is publicly accessible;
1.3) The vulnerability disclosure policy contains contact information and information on timelines regarding acknowledgement of receipt and status updates.
2) Fail: If any of the requirements above is not met.
3.3.1. Test group for requirement 2.3.1
3.3.1.1. Test objective
Camera device is tested whether it satisfies requirement 2.3.1 hereof.
This test group examines that at least one mechanism for notifying the user about available updates and at least one update mechanism for the secure installation of software updates exists.
3.3.1.2 Test cases Conceptual
3.3.1.2.1. Test purposes
Conceptual assessment of the update installation mechanism concerning adequate measures to prevent an attacker misusing the update installation on the camera device.
3.3.1.2.2. Test method
For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the design of the update mechanism prevents misuse from an attacker according to the “Security Guarantees”, the corresponding “Description”, “Cryptographic Details” and “Initiation and Interaction”.
Example: A misuse can be the installation of an old software update to downgrade the security capabilities of the camera device or the injection of malware by manipulating a valid update.
3.3.1.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) One mechanism for notifying user about available updates is implemented.
1.2) One update mechanism of the DUT cannot be misused by an attacker.
2) The verdict Fail is assigned if the requirement above is not met.
3.3.1.3. Test case Functional
3.3.1.3.1. Test purposes
Functional assessment of the effectiveness of the update mechanism to avoid misuse.
3.3.1.3.2. Test method
1) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall devise functional attacks to misuse the update mechanism based on the “Description”.
2) Test laboratory shall attempt to misuse each update mechanism on the base of the devised adverse actions and assess whether the design of the mechanism (see “Description”, the “Cryptographic Details” and “Initiation and Interaction”) effectively prevents the misuse of software updates as described in the “Security Guarantees”.
3.3.1.3.3. Assignment of verdict
1) The verdict Pass is assigned if: there is no indication that a misuse of one update mechanism of the camera device is possible.
2) The verdict Fail is assigned if the requirement above is not met.
3.3.2. Test group for requirement 2.3.2
3.3.2.1. Test objectives
Camera device is tested whether its functionalities and technical properties satisfy requirement 2.3.2 hereof.
In terms of this test group, an update that is simple to apply will be automatically applied, or initiated using an associated service (such as a mobile application) or via a web interface on the device. However, this does not exclude alternative solutions
The focus of the provision is on triggering the update from the user perspective and verifying whether the user is provided with the ability to update all software components in a simple manner. This case is given if each software component is updatable with at least one simple update mechanism.
3.3.2.2 Test cases Conceptual
3.3.2.2.1. Test purposes
Conceptual assessment of the update mechanisms concerning simplicity for the user to apply an update.
3.3.2.2.2. Test method
1) For each software component in IXIT 6-SoftComp, the test laboratory shall assess whether at least one “Update Mechanism” is described, which is simple for the user to apply according to “Initiation and Interaction” in IXIT 7-UpdMech based on the following factors:
1.1) The software update is automatically applied without requiring any user interaction;
1.2) The software update is initiated via an associated service;
1.3) The software update is initiated via a web interface on the device;
1.4) The software update uses a comparable approach which is applicable for the user with limited technical knowledge.
3.3.2.3. Assignment of verdict
1) The verdict is Pass if: each software component is covered by at least one update mechanism, which is simple for the user to apply.
2) The verdict Fail is assigned if the requirement above is not met.
3.3.3. Test group for requirement 2.3.3
3.3.3.1. Test objectives
Camera device is tested whether it satisfies requirement 2.3.3 hereof.
The objective of this test group is to assess whether the cryptographic methods provide the security guarantees that are necessary for the secure update mechanisms and whether the cryptographic methods are not known to be vulnerable to a feasible attack.
3.3.3.2 Test cases Conceptual
3.3.3.2.1. Test purposes
Conceptual assessment of the cryptography used for the update mechanisms concerning the use of best practice cryptography (Sections 1, 2, 3 under 3.3.3.2.2) and the vulnerability to a feasible attack (Section 4 under 3.3.3.2.2).
3.3.3.2.2. Test method
1) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the “Security Guarantees” are appropriate for the use case of secure updates, at least integrity and authenticity are required to be fulfilled.
2) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the mechanism according to “Description” is appropriate to achieve the “Security Guarantees”.
3) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the “Cryptographic Details” are considered as best practice cryptography for the use case of secure updates based on technical standards, technical regulations of relevant authorities or equivalent international standards. If “Cryptographic Details” are not included in a reference catalogue for the corresponding use case (e.g. novel cryptography), the supplier organization shall provide evidences, e.g. a risk analysis, to justify the cryptography is appropriate as best practice for the use case. In such case the test laboratory shall assess whether the evidence is appropriate and reliable for the use case.
4) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the “Cryptographic Details” are not known to be vulnerable to a feasible attack for the desired security property on the base of the “Security Guarantees” by reference to competent cryptanalytic reports.
3.3.3.2.3. Assignment of verdict
1) The verdict Pass is assigned if for all update mechanisms:
1.1) The security guarantees are appropriate for the use case of secure updates;
1.2) The mechanism is appropriate to achieve the security guarantees with respect to the use case;
1.3) All used “Cryptographic Details” are considered as best practice for the use case;
1.4) All used “Cryptographic Details” are not known to be vulnerable to a feasible attack for the desired security property.
2) Fail: If any of the requirements above is not met.
3.3.4. Test group for requirement 2.3.4
3.3.4.1. Test objectives
Camera device is tested whether it satisfies requirement 2.3.4 hereof.
This test group focuses on the management procedures that are necessary for deploying security updates timely.
3.3.4.2 Test cases Conceptual
3.3.4.2.1. Test purposes
conceptual assessment of the manner in which security updates are deployed (Section 1 under 3.3.4.2.2) and the confirmation that the preconditions for the implementation are ensured (Section 2 under 3.3.4.2.2).
3.3.4.2.2. Test method
1) Test laboratory shall assess whether the “Description” and the “Time Frame” of each security update procedure in IXIT 8-UpdProc facilitate that security updates are deployed in a timely manner.
2) Test laboratory shall check whether “Confirmation of Update Procedures” in IXIT 4-Conf states a confirmation.
3.3.4.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) management procedure allows a timely deployment of security updates;
1.2) A confirmation for the implementation is given.
2) Fail: If any of the requirements above is not met.
3.3.5. Test group for requirement 2.3.5
3.3.5.1. Test objectives
Camera device is tested whether it satisfies requirement 2.3.5 hereof.
3.3.5.2. Conceptual and functional assessment
3.3.5.2.1. Test purposes
Conceptual assessment of the verification of software updates via a trust relationship concerning authenticity and integrity (Section 1 under 3.3.5.2.2) and the performing entity (Section 2 under 3.3.5.2.2), and the functional assessment of the completeness of the IXIT documentation.
3.3.5.2.2. Test method
1) Test laboratory shall apply designated test methods including:
1.1) For each update mechanism in IXIT 7-UpdMech, the test laboratory shall assess whether the authenticity of software updates is suitably verified according to “Security Guarantees” and the corresponding “Cryptographic Details”, including, in particular, the originality of the software update in regard to its source (manufacturer) and target (camera device) prior to the installation.
1.2) For each update mechanism in IXIT 7-UpdMech, the TL shall assess whether the integrity of software updates is suitably verified according to “Security Guarantees” and the corresponding “Cryptographic Details”.
2) For each network based update mechanism in IXIT 7-UpdMech, test laboratory shall assess whether the verification of integrity and authenticity relies on a valid trust relationship according to “Description” and “Security Guarantees”. A valid trust relationship includes:
2.1) Authenticated communication channels;
2.2) Presence on a network that requires the device to possess a critical security parameter or password to join;
2.3) Digital signature based verification of the update;
2.4) Confirmation by the user;
2.5) A comparable secure functionality.
3) Test laboratory shall functionally assess whether update mechanisms that are not documented in IXIT 7-UpdMech are available via a network interface on the camera device.
3.3.5.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) Each update mechanism is effective for the verification of authenticity of software updates;
1.2) Each update mechanism is effective for the verification of integrity of software updates;
1.3) The verification of authenticity and integrity of software updates is based on a valid trust relationship;
1.4) Every discovered network-based update mechanism is documented in the IXIT.
2) Fail: If any of the requirements above is not met.
3.3.6. Test group for requirement 2.3.6
3.3.6.1. Test objectives
Camera device is tested whether it satisfies requirement 2.3.6 hereof.
3.3.6.2 Test cases Conceptual
3.3.6.2.1. Test purposes
Conceptual assessment of the publication of the defined support period.
3.3.6.2.2. Test method
Test laboratory shall assess whether access to the “Publication of Support Period” in IXIT 2-UserInfo is understandable and comprehensible for a user with limited technical knowledge.
3.3.6.2.3. Assignment of verdict
1) The verdict Pass will be assigned if: the publication of software update support period is understandable and comprehensible for a user with limited technical knowledge.
2) The verdict Fail is assigned if the requirement above is not met.
3.3.6.3. Test case Functional
3.3.6.3.1. Test purposes
Functional assessment of the publication of the defined support period.
3.3.6.3.2. Test method
1) Test laboratory shall functionally check whether the user information on accessing the resource for publishing the defined support period according to “Publication of Support Period” in IXIT 2-UserInfo is provided as described.
2) Test laboratory shall functionally check whether the resource for publishing the defined support period according to “Publication of Support Period” in IXIT 2-UserInfo is accessible without restrictions (like e.g. a registration prior to the access).
3) Test laboratory shall functionally check whether the published support period according to “Publication of Support Period” in IXIT 2-UserInfo actually defines the support period with respect to the updateable software components as described in “Support Period” in IXIT 2-UserInfo.
3.3.6.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The access to the resource for publishing the defined support period to the user is provided as described in the IXIT;
1.2) The access to the resource for publishing the defined support period is unrestricted;
1.3) The defined support period is published.
2) Fail: If any of the requirements above is not met.
3.3.7. Test group for requirement 2.3.7
3.3.7.1. Test objectives
Camera device is tested whether it satisfies requirement 2.3.7 hereof.
3.3.7.2 Test cases Conceptual
3.3.7.2.1. Test purposes
Conceptual assessment of the model designation.
3.3.7.2.2. Test method
Test laboratory shall assess whether the model designation of the DUT can be obtained in a clearly recognizable way, either by labeling on the DUT or via a physical interface according to “Model Designation” in IXIT 2-UserInfo.
3.3.7.2.3. Assignment of verdict
1) The verdict Pass is assigned if: The model designation of the DUT can be obtained clearly recognizable by labeling on the DUT or via a physical interface.
2) The verdict Fail is assigned if the requirement above is not met.
3.3.7.3. Test case Functional
3.3.7.3.1. Test purposes
Functional assessment of the model designation.
3.3.7.3.2. Test method
1) Test laboratory shall functionally check whether the model designation of the camera device can be obtained applying the described way of recognition in “Model Designation” in IXIT 2-UserInfo.
2) Test laboratory shall functionally assess whether the obtained model designation is available in simple text and corresponds with the expected model designation described in “Model Designation” in IXIT 2-UserInfo.
3.3.7.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The model designation of the DUT can be extracted according to the described way of recognition;
1.2) The model designation is available in simple text;
1.3) The model designation is corresponding with the expected model designation according to the IXIT.
2) Fail: If any of the requirements above is not met.
3.4. Storage of critical security parameter
3.4.1. Test group for requirement 2.4.1
3.4.1.1. Test objectives
Camera device is tested whether it satisfies requirement 2.4.1 hereof.
This test group assesses whether critical security parameters are securely stored according to their type using the claimed protection schemes. However the assessment does not give assurance for the completeness of the documented critical security parameters apart from consistency with respect to other IXIT.
3.4.1.2 Test cases Conceptual
3.4.1.2.1. Test purposes
Conceptual assessment of the secure storage of critical security parameters concerning the security claims and the completeness of the IXIT documentation.
3.4.1.2.2. Test method
1) Test laboratory shall assess whether the declaration in “Type” of each critical security parameter provided in IXIT 10-SecParam is consistent with the “Description”.
2) Test laboratory shall assess whether the “Security Guarantees” of each critical security parameter provided in IXIT 10-SecParam matches at least the protection needs indicated by “Type”.
3) Test laboratory shall assess whether the “Protection Scheme” of each sensitive security parameter provided in IXIT 10-SecParam provides the claimed “Security Guarantees”.
Considering the usage of external evidences, test laboratory shall consider the following aspects in order to make judgements applicable to corresponding test group:
3.1) The scope of the evidence shall be appropriate to the corresponding test group objective;
3.2) The description of the test activities being part of the evidence shall meet each test purpose inside the corresponding test group;
3.3) The test depth respectively the evaluation assurance level of the evidence shall be appropriate to the corresponding level addressed by the test group.
4) Test laboratory shall assess the completeness of the sensitive security parameters in IXIT 10-SecParam by considering indications for critical security parameters in the provided information in all other IXITs.
3.4.1.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) For every critical security parameter the declaration is consistent with its description;
1.2) For every critical security parameter the claimed security guarantees match their minimal protection needs;
1.3) Every critical security parameter has a suitable protection mechanism for the claimed security guarantees;
1.4) There is no indication, that the listed critical security parameters are incomplete.
2) Fail: If any of the requirements above is not met.
3.4.1.3. Test case Functional
3.4.1.3.1. Test purposes
Functional assessment of the secure storage of sensitive security parameters.
3.4.1.3.2. Test method
1) Test laboratory shall functionally assess whether for all sensitive security parameters provided in IXIT 10-SecParam “Protection Scheme” is implemented according to the IXIT documentation.
3.4.1.3.3. Assignment of verdict
1) The verdict Pass is assigned if: For every critical security parameter there is no indication that the implementation of the corresponding protection scheme differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.4.2. Test group for requirement 2.4.2
3.4.2.1. Test objectives
Camera device is tested whether it satisfies requirement 2.4.2 hereof.
In this case hard-coded unique per device identity is an individual and static value, that represents the camera device and potential hard-coded information the value is derived from.
The test group addresses the identification of hard-coded device identities and whether adequate protection needs are identified. A functional evaluation for tamper proof storage by any means is not in focus of this test scenario.
3.4.2.2 Test cases Conceptual
3.4.2.2.1. Test purposes
Conceptual assessment of tamper-resistant storage of hard-coded identities.
3.4.2.2.2. Test method
1) Test laboratory shall check whether for each critical security parameter in IXIT 10-SecParam where the “Description” indicates that it is used as an hard-coded identity, a corresponding explicit statement is provided.
2) Test laboratory shall assess whether for each hard-coded identity as indicated in “Description” in IXIT 10-SecParam the corresponding “Security Guarantees” provide tamper-resistance.
3) Test laboratory shall assess whether the “Protection Scheme” of each hard-coded identity as indicated in “Description” in IXIT 10-SecParam provides the claimed “Security Guarantees” with respect to tamper-resistance.
3.4.2.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) There is no indication that any hard-coded identity is not documented as such;
1.2) For all hard-coded identities the security guarantee includes tamper-resistance;
1.3) Every hard-coded identity has a suitable protection mechanism for tamper-resistance.
2) Fail: If any of the requirements above is not met.
3.4.2.3. Test case Functional
3.4.2.3.1. Test purposes
Conceptual assessment of tamper-resistant storage of hard-coded identities.
3.4.2.3.2. Test method
Test laboratory shall functionally assess whether each hard-coded identity as indicated in “Description” in IXIT 10-SecParam the “Protection Scheme” with respect to tamper-resistance is implemented according to the IXIT documentation.
3.4.2.3.3. Assignment of verdict
1) The verdict Pass is assigned if: For every hard-coded identity, there is no indication that the implementation of any protection scheme with respect to tamper-resistance differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.4.3. Test group for requirement 2.4.3
3.4.3.1. Test objectives
Camera device is tested whether it satisfies requirement 2.4.3 hereof.
This test group assesses whether there is an indication for not documented hard-coded critical security parameters in device software source code in the provided provisioning mechanisms for critical security parameters.
3.4.3.2 Test cases Conceptual
3.4.3.2.1. Test purposes
Conceptual assessment of hard-coded critical security parameters.
3.4.3.2.2. Test method
1) Test laboratory shall check whether for all critical security parameters provided in IXIT 10-SecParam where “Provisioning Mechanism” indicates that it is hard coded in device software source code, the fact is reflected in “Description”.
2) Test laboratory shall assess whether for all critical security parameters in IXIT 10-SecParam, which are hard coded in device software source code according to “Description”, the corresponding “Provisioning Mechanism” ensures that it is not used during the operation of the camera device.
3.4.3.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) There is no indication that any critical security parameter hard-coded in device software source code is not documented as such;
1.2) For all critical security parameter hard-coded in device software source code, the “Provisioning Mechanism” ensures that it is not used during the operation of the camera device.
2) Fail: If any of the requirements above is not met.
3.4.3.3. Test case Functional
3.4.3.3.1. Test purposes
Functional assessment of hard-coded critical security parameters.
3.4.3.3.2. Test method
Test laboratory shall functionally assess whether for all critical security parameters hard-coded in device software source code documented in “Description” of IXIT 10-SecParam, the “Provisioning Mechanism” is indeed applied during the operation of the camera device.
3.4.3.3.3. Assignment of verdict
1) The verdict Pass is assigned if: For all critical security parameter hard-coded in device software source code there is no indication that the application of the provisioning mechanism differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.4.4. Test group for requirement 2.4.4
3.4.4.1. Test objectives
Camera device is tested whether it satisfies requirement 2.4.4 hereof.
This test group assesses by documentation whether all critical security parameter addressed by the underlying provision are identified and that their generation mechanisms meet the corresponding requirement.
3.4.4.2 Test cases Conceptual
3.4.4.2.1. Test purposes
Conceptual assessment of critical security parameters used for integrity and authenticity checks of software updates and for protection of communication with associated services concerning the generation mechanisms.
3.4.4.2.2. Test method
1) Test laboratory shall check whether all critical security parameter provided in IXIT 10-SecParam, where “Description” indicates that the critical security parameters are used for integrity and authenticity checks of software updates or for protection of communication with associated services are documented as such in “Generation Mechanism”.
2) Test laboratory shall assess for all critical security parameters provided in IXIT 10-SecParam, whether the “Generation Mechanism” ensures that the critical security parameter is unique per device and produced with a mechanism that reduces the risk of automated attacks against classes of devices.
3.4.4.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) All critical security parameter where the purpose in “Description” indicates that the critical security parameters are used for integrity and authenticity checks of software updates or for protection of communication with associated services are documented as such in “Generation Mechanism”;
1.2) For all critical security parameters the “Generation Mechanism” ensures that the critical security parameters are unique per device and produced with a mechanism that reduces the risk of automated attacks against classes of devices.
2) Fail: If any of the requirements above is not met.
3.5. Management of secured communication channels
3.5.1. Test group for requirement 2.5.1
3.5.1.1. Test objectives
Camera device is tested whether it satisfies requirement 2.5.1 hereof.
The objective of this test group is to assess, firstly, whether the cryptographic methods provide the security guarantees that are necessary for the use case of the communication and, secondly, whether the cryptographic methods are not known to be vulnerable to a feasible attack.
3.5.1.2 Test cases Conceptual
3.5.1.2.1. Test purposes
Conceptual assessment of the cryptography used for the communication mechanisms concerning the use of best practice cryptography and the vulnerability to a feasible attack.
3.5.1.2.2. Assessment methods
1) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the “Security Guarantees” are appropriate for the use case of the communication.
2) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the mechanism according to “Description” is appropriate to achieve the “Security Guarantees”.
3) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the “Cryptographic Details” are considered as best practice cryptography for the use case of secure communication based on a reference catalogue. If “Cryptographic Details” are not included in a reference catalogue for the corresponding use case (e.g. novel cryptography), supplier organization shall provide evidences, e.g. a risk analysis, to justify the cryptography is appropriate as best practice for the use case. In such case test laboratory shall assess whether the evidence is appropriate and reliable for the use case.
4) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the “Cryptographic Details” are not known to be vulnerable to a feasible attack for the desired security property on the base of the “Security Guarantees” by reference to competent cryptanalytic reports.
3.5.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if requirements below are met:
1.1) The security guarantees are appropriate for the use case of secure communication;
1.2) the mechanism is appropriate to achieve the security guarantees with respect to the use case;
1.3) All used cryptographic details are considered as best practice for the use case;
1.4) All used cryptographic details are not known to be vulnerable to a feasible attack for the desired security property.
2) Fail: If any of the requirements above is not met.
3.5.1.3. Test case Functional
3.5.1.3.1. Test purposes
Functional assessment of the cryptography used for the communication mechanisms.
3.5.1.3.2. Assessment methods
For each communication mechanism in IXIT 11-ComMech, test laboratory shall functionally assess whether the described “Cryptographic Details” are used by the camera device.
3.5.1.3.3. Assignment of verdict
1) The verdict Pass is assigned if: there is no indication that any used cryptographic setting differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.5.2. Test group for requirement 2.5.2
3.5.2.1. Test objectives
Camera device is tested whether it satisfies requirement 2.5.2 hereof.
3.5.2.2 Test cases Conceptual
3.5.2.2.1. Test purposes
Conceptual assessment for full description of information proving authentication of authenticating entities (humans and machine); Only allowing configuration and use of camera device upon successful authentication.
3.5.2.2.2. Test method
Apply all test methods for all all states of test camera with restriction to the functionalities that allow security-relevant changes according to “Allows Configuration” in IXIT 13-SoftServ. Network service protocols that are relied upon by camera device and where the manufacturer cannot guarantee what configuration will be required for camera device to operate are excluded.
1) For each device functionality in IXIT 13-SoftServ indicated as accessible via network interface in the initialized state according to “Description”, test laboratory shall check whether there is at least one “Authentication Mechanism” referenced.
2) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall assess whether the authentication mechanism described in IXIT 1-AuthMech allows to discriminate between multiple authentication subjects and can reject authentication attempts based on invalid identities and/or authentication factors.
3) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall assess whether the means protecting the authentication mechanism in “Cryptographic Details” in IXIT 1-AuthMech provide the “Security Guarantees” identified for the mechanism and are resistant to attempts at compromising the mechanism.
4) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall assess whether the authorization process described in “Description” in IXIT 1-AuthMech allows authenticated subjects with proper access rights to be granted access and denies authenticated subjects with inadequate access rights or unauthenticated subjects to be granted access.
3.5.2.2.3. Assignment of verdict
1) The verdict Pass is assigned if requirements below are met:
1.1) at least one authentication mechanism is referenced for every device functionality accessible via network interface in the initialized state;
1.2) every authentication mechanism allows to discriminate between multiple authentication subjects and to reject authentication attempts based on invalid identities and/or authentication factors;
1.3) the means used to protect an authentication mechanism provide the expected security guarantees and are resistant at attempts to compromise the mechanism;
1.4) Every authorization mechanism allows access to authenticated subjects with proper access rights;
1.5) Every authorization mechanism denies access to authenticated subjects with inadequate access rights and to unauthenticated subjects.
2) Fail: If any of the requirements above is not met.
3.5.2.3. Test case Functional
3.5.2.3.1. Test purposes
Functional assessment of device functionality allowing security-relevant changes via a network interface concerning the authentication and authorization and the completeness of the IXIT documentation.
3.5.2.3.2. Test method
1) Apply all test methods for all states of camera device with restriction to the functionalities that allow security-relevant changes according to “Allows Configuration” in IXIT 13-SoftServ. Network service protocols that are relied upon by camera device and where the manufacturer cannot guarantee what configuration will be required for camera device to operate are excluded.
1.1) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall functionally assess whether an unauthenticated subject and a subject with invalid identity or credentials and an authenticated subject without appropriate access rights cannot access the device functionality in the initialized state.
1.2) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall functionally assess whether an authenticated subject with appropriate access rights can access the device functionality in the initialized state.
1.3) For each “Authentication Mechanism” referenced in IXIT 13-SoftServ, test laboratory shall functionally assess whether the protection of the authentication mechanism conforms to the description in “Security Guarantees” and “Cryptographic Details” in IXIT 1-AuthMech.
2) Functionally assess whether communication mechanisms that are not documented in IXIT 11-ComMech are available via a network interface on camera device.
Example: Network scanning tools allow for discovery of network-based communication mechanisms.
3.5.2.3.3. Assignment of verdict
1) The verdict Pass is assigned if requirements below are met:
1.1) An unauthenticated subject, a subject with invalid identity or invalid credentials and an authenticated subject without appropriate access rights cannot access the functionality;
1.2) An authenticated subject with appropriate access rights can access the device functionality;
1.3) There is no indication that the mechanism to secure the authentication differs from its IXIT documentation;
1.4) Every discovered network-based communication mechanism is documented in the IXIT.
2) Fail: If any of the requirements above is not met.
3.5.3. Test group for requirement 2.5.3
3.5.3.1. Test objectives
Camera device is tested whether it satisfies requirement 2.5.3 hereof.
The use case in the underlying provision is concretised on the communication of critical security parameters via remotely accessible network interfaces, which requires at least the security guarantee of confidentiality.
The objective of this test group is to assess whether the cryptographic methods provide the security guarantees that are necessary for the use case of the communication of critical security parameters and whether the cryptographic methods are not known to be vulnerable to a feasible attack.
3.5.3.2 Test cases Conceptual
3.5.3.2.1. Test purposes
Conceptual assessment of the cryptography used for communicating critical security parameters via remotely accessible network interfaces.
3.5.3.2.2. Test method
1) For all “Communication Mechanisms”, that are remotely accessible according to their “Description” in IXIT 11-ComMech referenced in any critical security parameter in IXIT 10-SecParam, test laboratory shall apply all designated test methods with restriction, that at least the security guarantee of confidentiality is required to be fulfilled.
3.5.3.2.3. Assignment of verdict
1) The verdict Pass is assigned if for all communication mechanisms used for communicating critical security parameters via remotely accessible network interfaces:
1.1) The security guarantees are appropriate for the use case of secure communication;
1.2) The mechanism is appropriate to achieve the security guarantees with respect to the use case;
1.3) All used cryptographic details are considered as best practice for the use case;
1.4) All used cryptographic details are not known to be vulnerable to a feasible attack.
2) Fail: If any of the requirements above is not met.
3.5.3.3. Test case Functional
3.5.3.3.1. Test purposes
Functional assessment of the cryptography used for communicating critical security parameters via remotely accessible network interfaces.
3.5.3.3.2. Test method
For all “Communication Mechanisms”, that are remotely accessible according to their “Description” in IXIT 11-ComMech referenced in any critical security parameter in IXIT 10-SecParam, test laboratory shall apply all designated test method.
3.5.3.3.3. Assignment of verdict
1) The verdict Pass is assigned if: there is no indication that any used cryptographic setting differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.5.4. Test group for requirement 2.5.4
3.5.4.1. Test objectives
Camera device is tested whether it satisfies requirement 2.5.4 hereof.
3.5.4.2 Test cases Conceptual
3.5.4.2.1. Test purposes
Conceptual assessment of the secure management processes concerning the coverage of the parameter life cycles (Section 1 under 3.5.4.2.2) and the confirmation that the preconditions for the implementation are ensured (Section 2 under 3.5.4.2.2).
3.5.4.2.2. Test method
1) Test laboratory shall assess whether the secure management of critical security parameters covers the whole life cycle of a critical security parameter considering its:
1.1) Generation;
1.2) Provisioning;
1.3) Storage;
1.4) Updates;
1.5) Decommissioning, archival, and destruction;
1.6) processes to handle the expiration and compromise.
2) Test laboratory shall check whether “Confirmation of Secure Management” in IXIT 4-Conf states a confirmation.
3.5.4.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The secure management covers the whole life cycle of a critical security parameter according to its processes;
1.2) A confirmation for the implementation is given.
2) Fail: If any of the requirements above is not met.
3.6. Protection from attack via minimizing attack surfaces
3.6.1. Test group for requirement 2.6.1
3.6.1.1. Test objectives
Camera device is tested whether it satisfies requirement 2.6.1 hereof. In principle a logical interface can be accessible via a plurality of network interface: the manufacturer therefore ensures that all access paths to a logical interface are identified. The manufacturer disables those network and logical interfaces that are not required to provide the device functionality, depending on the interface purpose.
3.6.1.2 Test cases Conceptual
3.6.1.2.1. Test purposes
Conceptual assessment of the network and logical interfaces of camera device.
3.6.1.2.2. Test method
For each network and logical interface in IXIT 15-Intf that is described as enabled according to “Status”, camera device shall assess whether the purpose of the interface in “Description” provides a valid justification for being enabled.
3.6.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if for every network or logical interface that is marked as enabled in the IXIT documentation, there is a purpose that provides a valid justification for the interface to be enabled.
2) The verdict Fail is assigned if the requirement above is not met.
3.6.1.3. Test case Functional
3.6.1.3.1. Test purposes
Functional assessment of the network and logical interfaces of camera device (Section 1 under 3.6.1.3.2) and the completeness of the IXIT documentation (Section 2 under 3.6.1.3.2).
3.6.1.3.2. Test method
1) For each network and logical interface in IXIT 15-Intf, test laboratory shall functionally check whether the status of the interface matches the “Status” in the IXIT documentation.
2) Test laboratory shall functionally assess whether network or logical interfaces that are not documented in IXIT 15-Intf are available via a network interface on camera device.
3.6.1.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) Every documented network or logical interface that is marked as disabled in the IXIT documentation is found to be disabled or not accessible on camera device;
1.2) Every discovered network and logical interface is documented in the IXIT.
2) Fail: If any of the requirements above is not met.
3.6.2. Test group for requirement 2.6.2
3.6.2.1. Test objectives
Camera device is tested whether it satisfies requirement 2.6.2 hereof.
The principle of minimization applied to security-relevant information in unauthenticated context dictates that only such information that is necessary for device or service operations in unauthenticated context are disclosed. It is to be noted that the manufacturer might not be able to minimize disclosed information if requirements exist to conform to standardized protocols which, by design, disclose more information than necessary.
Example: MAC address in Ethernet, Bluetooth® and Wi-Fi®, ARP, DNS.
3.6.2.2 Test cases Conceptual
3.6.2.2.1. Test purposes
Conceptual assessment of the information disclosed by network interfaces without authentication in the initialized state.
3.6.2.2.2. Test method
1) For each network interface in IXIT 15-Intf, test laboratory shall assess whether the “Disclosed Information” disclosed by the interface without authentication in the initialized state and indicated as not security-relevant, is however security-relevant.
2) For each network interface in IXIT 15-Intf, test laboratory shall assess whether the “Disclosed Information” disclosed by the interface without authentication in the initialized state and indicated as security-relevant, is necessary for the operation of camera device.
3.6.2.2.3. Assignment of verdict
1) The verdict Pass is assigned if for every network interface:
1.2) Every security-relevant information disclosed by the interface without authentication in the initialized state is documented as such;
1.3) All security-relevant information disclosed by the interface without authentication in the initialized state is necessary for the operation of camera device.
2) Fail: If any of the requirements above is not met.
3.6.2.3. Test case Functional
3.6.2.3.1. Test purposes
Functional assessment of the information disclosed by the network interfaces without authentication in the initialized state.
3.6.2.3.2. Test method
For each network interface in IXIT 15-Intf, the TL shall functionally assess whether security-relevant information can be observed from the interface without authentication in the initialized state, that is not described in “Disclosed Information”.
3.6.2.3.3. Assignment of verdict
1) The verdict Pass is assigned if: for every network interface, only security-relevant information can be observed that is described in the IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.6.3. Test group for requirement 2.6.3
3.6.3.1. Test objectives
Camera device is tested whether it satisfies requirement 2.6.3 hereof.
In this test group, the debug interface might be permanently disabled in software or, if it is foreseen that it can be useful in specific cases of the device lifecycle, be under the control of a trusted software mechanism. Using specific tooling to physically access the interface is not in scope of the assessment.
3.6.3.2 Test cases Conceptual
3.6.3.2.1. Test purposes
Conceptual assessment of physically accessible debug interfaces of camera device.
3.6.3.2.2. Test method
1) For each physical interface in IXIT 15-Intf that is described as an accessible debug interface according to “Debug Interface”, test laboratory shall assess whether the protection means for the interface in “Protection” include a software mechanism to disable the interface.
2) For each physical interface in IXIT 15-Intf that is described as an accessible debug interface, that is not indicated as intermittently required according to “Description”, test laboratory shall check whether the interface is disabled permanently according to “Status”.
3) For each physical interface in IXIT 15-Intf that is described as an accessible debug interface, that is indicated as intermittently required according to “Description”, test laboratory shall check whether the interface is disabled by default according to “Status”.
3.6.3.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) For every accessible physical debug interface, there is a software mechanism described to disable the interface;
1.2) For every accessible physical debug interface that is not indicated as intermittently required, the interface is permanently disabled;
1.3) For every accessible physical debug interface that is indicated as intermittently required, the interface is disabled by default.
2) Fail: If any of the requirements above is not met.
3.6.3.3. Test case Functional
3.6.3.3.1. Test purposes
Functional assessment of physically accessible debug interfaces of camera device (Section 1 under 3.6.3.3.2) and the completeness of the IXIT documentation (Section 2 under 3.6.3.3.2).
3.6.3.3.2. Test method
1) For each accessible physical interface on the DUT indicated as “Debug Interface” in IXIT 15-Intf, test laboratory shall functionally check whether the interface is disabled.
2) For each accessible physical interface on camera device, test laboratory shall functionally assess whether the interface can be used for debugging purposes although it is not indicated as “Debug Interface” in IXIT 15-Intf.
3.6.3.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.2) Every accessible physical debug interface is disabled;
1.3) Every physical debug interface is indicated as such in the IXIT.
2) Fail: If any of the requirements above is not met.
3.7.1. Test group for requirement 2.7.1
3.7.1.1. Test group objective
Camera device is tested whether it satisfies requirement 2.7.1 hereof.
The use case in the underlying provision is concretised on the communication of sensitive personal data between the device and associated services, which requires at least confidentiality.
The objective of this test group is to assess, firstly, whether the cryptographic methods provide the security guarantees that are necessary for the use case of the communication of personal data and, secondly, whether the cryptographic methods are not known to be vulnerable to a feasible attack.
3.7.1.2 Test cases Conceptual
3.7.1.2.1. Test purposes
Conceptual assessment of the cryptography used for communicating sensitive personal data between the device and associated services.
3.7.1.2.2. Test method
For all “Communication Mechanisms” in IXIT 11-ComMech referenced in any sensitive personal data in IXIT 21-PersData according to “Sensitive”, where the communication partner is an associated service, test laboratory shall apply all test units as specified in 3.5.1.2 with restriction, that at least the security guarantee of confidentiality is required to be fulfilled.
3.7.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if for all communication mechanisms used for communicating sensitive personal data between the device and an associated service:
1.1) The security guarantees are appropriate for the use case of communicating sensitive personal data between the device and an associated service;
1.2) The mechanism is appropriate to achieve the security guarantees with respect to the use case;
1.3) All used cryptographic details are considered as best practice for the use case;
1.4) All used cryptographic details are not known to be vulnerable to a feasible attack.
2) Fail: If any of the requirements above is not met.
3.7.1.3. Test case Functional
3.7.1.3.1. Test purposes
Functional assessment of the cryptography used for communicating sensitive personal data between the device and associated services.
3.7.1.3.2. Test method
For all “Communication Mechanisms” in IXIT 11-ComMech referenced in any sensitive personal data in IXIT 21-PersData according to “Sensitive”, where the communication partner is an associated service, test laboratory shall apply all test units as specified in 3.5.1.3.
3.7.1.3.3. Assignment of verdict
1) The verdict Pass is assigned if there is no indication that any used cryptographic setting differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.7.2. Test group for requirement 2.7.2
3.7.2.1. Test group objective
Camera device is tested whether it satisfies requirement 2.7.2 hereof.
This test group aims at revealing any capabilities of a DUT to sense information about its surroundings, such as optic, acoustic, biometric or location sensors It is to be documented in a way that the user is knowledgeable about information that is obtained by test laboratory.
3.7.2.2. Test case Functional
3.7.2.2.1. Test purposes
Functional assessment of the documentation of external sensing capabilities (Sections 1, 2 under 3.7.2.2.2) and the completeness of the IXIT documentation (Section 3 under 3.7.2.2.2).
3.7.2.2.2. Test method
1) Test laboratory shall functionally check whether the documentation of external sensing capabilities is accessible as documented in “Documentation of Sensors” in IXIT 2-UserInfo.
2) Test laboratory shall functionally assess whether the documentation of external sensing capabilities as documented in “Documentation of Sensors” in IXIT 2-UserInfo is understandable for a user with limited technical knowledge.
3) Test laboratory shall functionally assess whether all obvious sensing capabilities of camera device are documented in IXIT 22-ExtSens.
3.7.2.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The documentation is accessible according to the IXIT;
1.2) The documentation is understandable for a user with limited technical knowledge;
1.3) Each obvious sensing capability of the DUT is documented for the user.
2) Fail: If any of the requirements above is not met.
3.8. Ability to restore normal system operation after outage
3.8.1. Test group for requirement 2.8.1
3.8.1.1. Test group objective
Camera device is tested whether it satisfies requirement 2.8.1 hereof.
3.8.1.2 Test cases Conceptual
3.8.1.2.1. Test purposes
Conceptual assessment of the resilience mechanisms concerning outages of network and power.
3.8.1.2.2. Test method
1) Test laboratory shall assess whether the combination of the resilience mechanisms in IXIT 23-ResMech are appropriate to protect against network connectivity and power outages according to the “Security Guarantees”.
2) For each resilience mechanism in IXIT 23-ResMech the TL shall assess whether the mechanism according to the “Description” is appropriate to achieve the “Security Guarantees”.
3.8.1.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The resilience mechanisms are appropriate to protect against network connectivity and power outages;
1.2) Every resilience mechanism is appropriate to achieve its security guarantees.
2) Fail: If any of the requirements above is not met.
3.8.1.3. Test case Functional
3.8.1.3.1. Test purposes
Functional assessment of the resilience mechanisms concerning outages of network and power.
3.8.1.3.2. Test method
1) Test laboratory shall interrupt camera device’s connection to the network and functionally assess whether the resilience mechanisms operate as described in IXIT 23-ResMech.
2) Test laboratory shall interrupt camera device’s power supply and functionally assess whether the resilience mechanisms operate as described in IXIT 23-ResMech.
3.8.1.3.3. Assignment of verdict
1) The verdict Pass is assigned if: there is no indication that the recovery of the resilience mechanisms during network connectivity and power outages differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.8.2. Test group for requirement 2.8.2
3.8.2.1. Test group objective
Camera device is tested whether it satisfies requirement 2.8.2 hereof.
3.8.2.2 Test cases Conceptual
3.8.2.21. Test purposes
Conceptual assessment of the resilience mechanisms concerning outages of network and power (Section 1 under 3.8.2.2.2) and the operation during network outages (Section 2 under 3.8.2.2.2) and restoration after power outages (Section 3 under 3.8.2.2.2).
3.8.2.2.2. Test method
1) Test laboratory shall apply all test units as specified in 3.8.1.1 for the resilience mechanisms in IXIT 23-ResMech.
2) Test laboratory shall assess whether the resilience mechanisms in IXIT 23-ResMech protecting against network connectivity outages according to “Type” are appropriate to ensure, that camera device remains operating and locally functional in the case of a loss of network connectivity.
3) Test laboratory shall assess whether the resilience mechanisms in IXIT 23-ResMech protecting against power outages according to “Type” are appropriate to ensure, that camera device resumes the connectivity and functionality after a loss of power in the same or improved state as before.
3.8.2.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The resilience mechanisms are appropriate to protect against network connectivity and power outages;
1.2) Every resilience mechanism is appropriate to achieve its security guarantees;
1.3) The resilience mechanisms are appropriate to ensure that camera device remains operating and locally functional in the case of a loss of network connectivity;
1.4) The resilience mechanisms are appropriate to ensure that camera device recovers cleanly after a loss of power.
2) Fail: If any of the requirements above is not met.
3.8.2.3. Test case Functional
3.8.2.3.1. Test purposes
Functional assessment of the resilience mechanisms concerning outages of network and power, the operation during network outages and restoration after power outages.
3.8.2.3.2. Test method
1) Test laboratory shall shall interrupt camera device’s connection to the network and functionally assess whether the resilience mechanisms operate as described in IXIT 23-ResMech and camera device remains operating and locally functional after the loss of network connectivity.
2) Test laboratory shall interrupt camera device’s power supply and functionally assess whether the resilience mechanisms operate as described in IXIT 23-ResMech and camera device resumes the connectivity and functionality after a loss of power in the same or improved state as before.
3.8.2.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) There is no indication that the operation of the resilience mechanisms during network connectivity or power outages differs from its IXIT documentation;
1.2) There is no indication that camera device does not remain operating and locally functional after the loss of network connectivity; and
1.3) There is no indication that camera device does not resume the connectivity and functionality after a loss of power in the same or improved state as before.
2) Fail: If any of the requirements above is not met.
3.8.3. Test group for requirement 2.8.3
3.8.3.1. Test group objective
Camera device is tested whether it satisfies requirement 2.8.3 hereof.
1) This test group considers the capabilities:
1.1) To perform a standardized connection establishment;
1.2) To protect against mass-reconnections.
3.8.3.2 Test cases Conceptual
3.8.3.2.1. Test purposes
Conceptual assessment of the resilience measures for the communication mechanisms.
3.8.3.2.2. Test method
1) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the “Resilience Measures” are appropriate to achieve a connection to a network in an orderly fashion taking the capability of the infrastructure into consideration.
2) For each communication mechanism in IXIT 11-ComMech, test laboratory shall assess whether the “Resilience Measures” are appropriate to support the operation of a stable network taking the capability of the infrastructure into consideration.
3.8.3.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) Every communication mechanism provides appropriate measures to achieve a connection to a network in an orderly fashion;
1.2) Every communication mechanism provides appropriate measures to support the operation of a stable network.
2) Fail: If any of the requirements above is not met.
3.8.3.3. Test case Functional
3.8.3.3.1. Test purposes
functional assessment of the resilience measures for the communication mechanisms.
3.8.3.3.2. Test method
Test laboratory shall functionally assess whether the implemented “Resilience Measures” for each communication method in IXIT 11-ComMech are implemented as described, especially considering the protection against simultaneous mass-reconnections.
3.8.3.3.3. Assignment of verdict
1) The verdict Pass is assigned if there is no indication that the operation of any implemented resilience measure differs from its IXIT documentation.
2) The verdict Fail is assigned if the requirement above is not met.
3.9. Erasure of data on surveillance camera
3.9.1. Test group for requirement 2.9.1
3.9.1.1. Test group objective
Camera device is tested whether it satisfies requirement 2.9.1 hereof.
3.9.1.2 Test cases Conceptual
3.9.1.2.1. Test purposes
Conceptual assessment of the user data erasure functionalities of camera device.
3.9.1.2.2. Test method
1) Test laboratory shall assess whether at least one functionality is provided according to IXIT 25-DelFunc, which can be performed by the user according to “Description” and “Initiation and Interaction” to erase user data from the device according to “Target Type”.
2) Test laboratory shall assess whether each functionality in IXIT 25-DelFunc is adequate to erase the targeted user data from the device.
3) Test laboratory shall assess whether the functionalities to erase user data in IXIT 25-DelFunc cover personal data, user configuration and user-related cryptographic material.
3.9.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if no user data is stored on the device or all requirements below are met:
1.1) At least one simple functionality to erase user data from the device is provided to the user;
1.2) The described functionality is adequate to erase the targeted user data from the device;
1.3) Personal data, user configuration and cryptographic material is covered by the functionalities to erase user data from the device.
2) Fail: If any of the requirements above is not met.
3.9.1.3. Test case Functional
3.9.1.3.1. Test purposes
Conceptual assessment of the user data erasure functionalities of camera device.
3.9.1.3.2. Test method
1) Test laboratory shall create typical user data on camera device with regard to the usage of the device.
2) Test laboratory shall perform each functionality to erase user data from the device according to “Target Type” in IXIT 25-DelFunc and functionally assess whether the “Initiation and Interaction” is consistent with the IXIT.
3) Test laboratory shall perform each functionality to erase user data from the device according to “Target Type” in IXIT 25-DelFunc and functionally assess whether the corresponding user data still exists after completing the operation.
3.9.1.3.3. Assignment of verdict
1) The verdict pass is assigned if for any functionality to erase user data from the device:
1.1) The initiation and interaction of the user is consistent with the IXIT;
1.2) There is no indication that the corresponding user data is not erased successfully.
2) Fail: If any of the requirements above is not met.
3.10. Validation of input data
3.10.1. Test group for requirement 2.10.1
3.10.1.1. Test group objective
Camera device is tested whether it satisfies requirement 2.10.1 hereof.
Input data validation ensures that the receiving end can process the data without causing unexpected behaviour. This entails verifying that the provided data is of the correct type (allowed data format and data structures), of allowed value, and of allowed cardinalities and ordering.
3.10.1.2 Test cases Conceptual
3.10.1.2.1. Test purposes
Conceptual assessment of the data input validation methods of camera device.
3.10.1.2.2. Test method
1) Test laboratory shall assess whether the combination of data input validation methods in IXIT 29-InpVal covers all sources for data input including:
1.1) The user interfaces, which enable data input from the user in IXIT 27-UserIntf;
1.2) The application programming interfaces (APIs), which enable data input from external sources in IXIT 28-ExtAPI;
1.3) The network communications, which enable data input according to the corresponding remotely accessible communication methods in IXIT 11-ComMech.
2) For each data input validation method in IXIT 29-InpVal, test laboratory shall assess whether it is effective for validating the corresponding data input.
3.10.1.2.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) the data input validation methods cover data input via user interfaces, transmitted via APIs and between networks in services and devices;
1.2) Every described data input validation method is effective for validating the corresponding data input.
2) Fail: If any of the requirements above is not met.
3.10.1.3. Test case Functional
3.10.1.3.1. Test purposes
Functional assessment of the data input validation methods of camera device (Section 1 under 3.10.1.3.2) and the completeness of the IXIT documentation (Sections 2, 3 under 3.10.1.3.2).
3.10.1.3.2. Test method
1) Test laboratory shall functionally assess whether each data input validation method in IXIT 29-InpVal prevents the processing of unexpected data input.
2) Test laboratory shall functionally assess whether all user interfaces of camera device are described in IXIT 27-UserIntf according to the documentation for the user, e.g. user manual.
3) Test laboratory shall functionally assess whether all remotely accessible APIs of camera device are described in IXIT 28-ExtAPI.
3.10.1.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) There is no indication that any data input validation does not protect against the processing of unexpected data input;
1.2) Every discovered user interface is documented in the IXIT;
1.3) Every discovered remotely accessible API is documented in the IXIT.
2) Fail: If any of the requirements above is not met.
3.11. Protection of data on surveillance camera
3.11.1. Test group for requirement 2.11.1
3.11.1.1. Test group objective
Camera device is tested whether it satisfies requirement 2.11.1 hereof.
3.11.1.2 Test cases Conceptual
3.11.1.2.1. Test purposes
Conceptual assessment of the user information about the processing of personal data.
3.11.1.2.2. Test method
Test laboratory shall assess whether the “Documentation of Personal Data” in IXIT 2-UserInfo is suitable for the consumer to obtain the information about processing personal data.
3.11.1.2.3. Assignment of verdict
1) The verdict Pass is assigned if the information about processing personal data is suitably provided to the consumer.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.1.3. Test case Functional
3.11.1.3.1. Test purposes
Functional assessment of the user information about the processing of personal data.
3.11.1.3.2. Test method
1) Test laboratory shall functionally assess whether the provided information about processing personal data (obtained information) is consistent to the description in “Documentation of Personal Data” in IXIT 2-UserInfo.
2) Test laboratory shall functionally assess whether the obtained information about processing personal data accessing the “Documentation of Personal Data” in IXIT 2-UserInfo match their description in “Processing Activities” in IXIT 21-PersData.
3) Test laboratory shall functionally assess whether the obtained information describes what personal data is processed.
4) Test laboratory shall functionally assess whether the obtained information describe how personal data is being used, by whom, and for what purposes.
3.11.1.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The information about processing personal data can be obtained as described;
1.2) The obtained information about processing personal data match their description;
1.3) The personal data being processed is clearly and transparently described;
1.4) It is clearly and transparently described how personal data is being used, by whom, and for what purposes.
2) Fail: If any of the requirements above is not met.
3.11.2. Test group for requirement 2.11.2
3.11.2.1. Test group objective
Camera device is tested whether it satisfies requirement 2.11.2 hereof.
According to this Regulation, obtaining consent “in a valid way” normally involves giving consumers a free, obvious and explicit opt-in choice of whether their personal data is used for a specified purpose.
3.11.2.2 Test cases Conceptual
3.11.2.2.1. Test purposes
Conceptual assessment of the consumers’ consent for the processing of personal data.
3.11.2.2.2. Test method
1) For each personal data in IXIT 21-PersData that is processed on the basis of consumers’ consent according to “Obtaining Consent”, test laboratory shall assess whether the opt-in choice:
1.1) Is given freely;
1.2) Is given obviously;
1.3) Is given explicitly.
3.11.2.2.3. Assignment of verdict
1) The verdict Pass is assigned if for each category of personal data that is processed on the basis of consumers’ consent:
1.1) It is described how to express consent (opt-in choice) to the processing of personal data for specific purposes;
1.2) The opt-in choice is given freely, obviously and explicitly.
2) Fail: If any of the requirements above is not met.
3.11.2.3. Test case Functional
3.11.2.3.1. Test purposes
Functional assessment of the consumers’ consent for the processing of personal data.
3.11.2.3.2. Test method
For each personal data in IXIT 21-PersData that is processed on the basis of consumers’ consent according to “Obtaining Consent”, test laboratory shall functionally assess whether consumers’ consent to processing personal data is obtained as described in the IXIT.
3.11.2.3.3. Assignment of verdict
1) The verdict Pass is assigned if for each category of personal data that is processed on the basis of consumers’ consent the way of obtaining consumers’ consent matches the description.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.3. Test group for requirement 2.11.3
3.11.3.1. Test group objective
Camera device is tested whether it satisfies requirement 2.11.3 hereof.
According to this Regulation, withdrawing consent at any time normally involves configuring IoT device and service functionality appropriately.
3.11.3.2 Test cases Conceptual
3.11.3.2.1. Test purposes
Conceptual assessment of withdrawing consumers’ consent for the processing of personal data.
3.11.3.2.2. Test method
For each personal data in IXIT 21-PersData that is processed on the basis of consumers’ consent according to “Obtaining Consent”, test laboratory shall assess whether the information on “Withdrawing Consent” describes how to withdraw consent to the processing of personal data at any time by configuring IoT device and service functionality appropriately.
3.11.3.2.3. Assignment of verdict
1) The verdict Pass is assigned if for each category of personal data that is processed on the basis of consumers’ consent: it is described how to withdraw consent to the processing of personal data at any time.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.3.3. Test case Functional
3.11.3.3.1. Test purposes
Functional assessment of withdrawing consumers’ consent for the processing of personal data.
3.11.3.3.2. Test method
For each personal data in IXIT 21-PersData that is processed on the basis of consumers’ consent according to “Obtaining Consent”, test laboratory shall functionally assess whether consumers’ consent to processing personal data can be withdrawn as described in “Withdrawing Consent”.
3.11.3.3.3. Assignment of verdict
1) The verdict Pass is assigned if for each category of personal data that is processed on the basis of consumers’ consent: the way of withdrawing consumers’ consent matches the description.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.4. Test group for requirement 2.11.4
3.11.4.1. Test group objective
Camera device is tested whether it satisfies requirement 2.11.4 hereof.
3.11.4.2 Test cases Conceptual
3.11.4.2.1. Test purposes
Conceptual assessment of the user information about the processing of telemetry data.
3.11.4.2.2. Test method
Test laboratory shall shall assess whether the “Documentation of Telemetry Data” in IXIT 2-UserInfo is suitable for the consumer to obtain the information about processing telemetry data.
3.11.4.2.3. Assignment of verdict
1) The verdict Pass is assigned if the information about processing telemetry data is suitably provided to the consumer.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.4.3. Test case Functional
3.11.4.3.1. Test purposes
Functional assessment of user the information about the processing of telemetry data.
3.11.4.3.2. Test method
1) Test laboratory shall functionally assess whether the provided information about processing telemetry data (obtained information) is consistent with the description in “Documentation of Telemetry Data” in IXIT 2-UserInfo.
2) Test laboratory shall functionally assess whether the obtained information about processing telemetry data accessing the “Documentation of Telemetry Data” in IXIT 2-UserInfo match their “Purpose” described in IXIT 24-TelData.
3) Test laboratory shall functionally check whether the obtained information describes what telemetry data is collected.
4) Test laboratory shall functionally check whether the obtained information describes how telemetry data is being used, by whom, and for what purposes.
3.11.4.3.3. Assignment of verdict
1) Pass: The verdict Pass is assigned if:
1.1) The information about processing telemetry data can be obtained as described;
1.2) The obtained information about processing telemetry data match their description;
1.3) The telemetry data being collected is described;
1.4) It is completely described how telemetry data is being used, by whom, and for what purposes.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.5. Test group for requirement 2.11.5
3.11.5.1. Test group objective
Camera device is tested whether it satisfies requirement 2.11.5 hereof.
3.11.5.2 Test cases Conceptual
3.11.5.2.1. Test purposes
Conceptual assessment of functionalities of camera device for configuration that allows camera device and associated services to archive data in Vietnam.
3.11.5.2.2. Test method
For each description in IXIT 11-ComMech and IXIT 28-ExtAPI, test laboratory shall assess whether camera device allows configuration and connection between camera device and associated services for data archival in Vietnam.
3.11.5.2.3. Assignment of verdict
1) The verdict Pass is assigned if there is no indication that camera device lack functionalities that allow configuration and enable camera device to connect to associated services for data archival in Vietnam.
2) The verdict Fail is assigned if the requirement above is not met.
3.11.5.3. Test case Functional
3.11.5.3.1. Test purposes
Functional assessment of functionalities of camera device for configuration that allows camera device and associated services to archive data in Vietnam.
3.11.5.3.2. Test method
1) Test laboratory shall assess to prove that camera device is connected to associated services that allow configuration and enable camera device and associated services to archive data in Vietnam.
2) Test laboratory shall assess in order to prove associated services for data archive in Vietnam.
3.11.5.3.3. Assignment of verdict
1) The verdict Pass is assigned if there is indication that camera device that uses configuration functionalities to enable camera device to connect to associated services for data archival in Vietnam is connected to servers in Vietnam.
2) The verdict Fail is assigned if the requirement above is not met.
4.1. Camera device with moderate and high risk level regulated by Section 1.1 must be subject to declaration of conformity in accordance with this Regulation and bear conformity mark (CR Mark).
4.2. Declaration of conformity
4.2.1. Declaration of conformity for camera device with moderate risk level regulated by this Regulation is based on self-assessment results of organizations and individuals on the basis of test results of designated testing bodies as per the law or conformity assessment results of recognized international, regional, foreign organizations as per the law.
4.2.2. Declaration of conformity for camera device with high risk level and regulated by this Regulation is based on conformity assessment results of designated certifying bodies as per the law.
4.2.3. Certification of conformity
Certification of conformity shall be implemented via method 5 or method 7 under legislative documents on declaration of conformity. Tests in service of conformity certification shall be conducted by designated testing bodies as per the law. The scope of tests conducted by testing bodies shall satisfy requirements under this Technical Regulation.
4.2.4. Use of conformity mark
Mark of conformity shall conform to regulations on declaration of conformity.
5. RESPONSIBILITIES OF MANUFACTURERS, ORGANIZATIONS, INDIVIDUALS
5.1. Manufacturers, organizations, and individuals shall ensure that camera device satisfies requirements under Section 2 and shall implement Section 4 hereof.
5.2. Manufacturers, organizations, and individuals have the responsibility to provide proof pertaining to conformity of products to this Regulation at request or upon being inspected as per the law for goods in market circulation.
5.3. Conformity assessing bodies, for the purpose of testing and certifying products’ conformity to this Regulation, have the responsibility to exercise Section 3 hereof.
List of entries for assessment
Schedule of IXIT entries
|
Provision |
IXIT entries |
|
2.1.1 |
IXIT 1-AuthMech: ID, Description, Authentication Factor, Password Generation Mechanism |
|
2.1.2 |
IXIT 1-AuthMech: ID, Description, Authentication Factor, Password Generation Mechanism |
|
2.1.3 |
IXIT 1-AuthMech: ID, Description, Security Guarantees, Cryptographic Details |
|
2.1.4 |
IXIT 1-AuthMech: ID, Description
IXIT 2-Userlnfo: Documentation of Change Mechanisms |
|
2.1.5 |
IXIT 1-AuthMech: ID, Description, Brute Force Prevention |
|
2.2.1 |
IXIT 2-Userlnfo: Publication of Vulnerability Disclosure Policy |
|
2.3.1 |
IXIT 7-UpdMech: ID, Description, Security Guarantees, Cryptographic Details, Initiation and Interaction |
|
2.3.2 |
IXIT 6-SoftComp: ID, Description, Update Mechanism
IXIT 7-UpdMech: ID, Description, Initiation and Interaction |
|
2.3.3 |
IXIT 7-UpdMech: ID, Description, Security Guarantees, Cryptographic Details |
|
2.3.4 |
IXIT 4-Conf: Confirmation of Update Procedures
IXIT 8-UpdProc: ID, Description, Time Frame |
|
2.3.5 |
IXIT 7-UpdMech: ID, Description, Security Guarantees, Cryptographic Details |
|
2.3.6 |
IXIT 2-Userlnfo: Support Period, Publication of Support Period |
|
2.3.7 |
IXIT 2-Userlnfo: Model Designation |
|
2.4.1 |
IXIT 10-SecParam: ID, Description, Type, Security Guarantees, Protection Scheme |
|
2.4.2 |
IXIT 10-SecParam: ID, Description, Type, Security Guarantees, Protection Scheme |
|
2.4.3 |
IXIT 10-SecParam: ID, Description, Type, Provisioning Mechanism |
|
2.4.4 |
IXIT 10-SecParam: ID, Description, Type, Generation Mechanism |
|
2.5.1 |
IXIT 11AuthMech: ID, Description, Security Guarantees, Cryptographic Details |
|
2.5.2 |
IXIT 1-AuthMech: ID, Description, Security Guarantees, Cryptographic Details
IXIT 13-SoftServ: ID, Description, Allows Configuration, Authentication Mechanism |
|
2.5.3 |
IXIT 10-SecParam: ID, Description, Type, Communication Mechanisms
IXIT 11-ComMech: ID, Description, Security Guarantees, Cryptographic Details |
|
2.5.4 |
IXIT 4-Conf: Confirmation of Secure Management
IXIT 14-SecMgmt: ID, Description |
|
2.6.1 |
IXIT 15-lntf: ID, Description, Type, Status |
|
2.6.2 |
IXIT 15-lntf: ID, Description, Type, Disclosed Information |
|
2.6.3 |
IXIT 15-lntf: ID, Description, Type, Status, Debug Interface, Protection |
|
2.7.1 |
IXIT 11-ComMech: ID, Description, Security Guarantees, Cryptographic Details
IXIT 21-PersData: ID, Description, Processing Activities, Communication Mechanisms, Sensitive |
|
2.7.2 |
IXIT 2-Userlnfo: Documentation of Sensors
IXIT 22AuthMech: ID, Description |
|
2.8.1 |
IXIT 23-ResMech: ID, Description, Security Guarantees |
|
2.8.2 |
IXIT 23-ResMech: ID, Description, Type, Security Guarantees |
|
2.8.3 |
IXIT 11-ComMech: ID, Description, Resilience Measures |
|
2.9.1 |
IXIT 25-DelFunc: ID, Description, Target Type, Initiation and Interaction |
|
2.10.1 |
IXIT 11-ComMech: ID, Description
IXIT 27-Userlntf: ID, Description IXIT 28-ExtAPI: ID, Description IXIT 29-lnpVal: ID, Description |
|
2.11.1 |
IXIT 2-Userlnfo: Documentation of Personal Data
IXIT 21-PersData: ID, Description, Processing Activities |
|
2.11.2 |
IXIT 21-PersData: ID, Description, Obtaining Consent |
|
2.11.3 |
IXIT 21-PersData: ID, Description, Obtaining Consent, Withdrawing Consent |
|
2.11.4 |
IXIT 2-Userlnfo: Documentation of Telemetry Data
IXIT 24-TelData: ID, Description, Purpose |
|
2.11.5 |
IXIT 11-ComMech: ID, Description
IXIT 28-ExtAPI: ID, Description |
1) IXIT 1-AuthMech: Authentication Mechanism
Complete IXIT lists all authentication mechanism of camera device. This pro forma contains the following entries and is typically filled out in form of a table.
1.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“AuthMech-1”) or labeling scheme (“AuthMech-PswdWebIf”).
1.2) Description: Brief description of the authentication mechanism and its corresponding authorization process. It is indicated additionally whether the mechanism is used for user or machine-to-machine authentication and whether it is directly addressable from a network interface.
1.3) Authentication factor: The type of attribute used for authentication. For passwords it is indicated additionally whether the password is set by the user and used in the initialized state.
Example: Password (set by user), password (pre-installed), biometric fingerprint.
1.4) Password Generation Mechanism: If the authentication factor is a password, which is not set by the user: Description of the mechanism to generate the password. It is indicated additionally whether the password is unique per device and whether it is pre-installed.
1.5) Security Guarantees: Description of the realized security objectives and the threats the mechanism is protected against.
Example: The mechanisms attests that the authenticated entity is in possession of a valid password. The confidentiality and integrity protection of the password during transfer is also guaranteed within the session.
1.6) Cryptographic Details: Description of the cryptographic methods (protocols, operations, primitives, modes and key-sizes) used to secure the authentication mechanism considering key management, and to facilitate the described “Security Guarantees”.
Example: Authentication is performed via http authentication framework (IETF RFC 7235 [i.8]). Integrity and confidentiality of the password transfer to the DUT is realized with the TLS cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.
1.7) Brute Force Prevention: If the authentication mechanism is directly addressable from a network interface: Description of the method to prevent an attacker from brute forcing credentials via network interfaces.
Example: A time delay of 5 seconds after an unsuccessful login before a new login can follow.
2) IXIT 2-UserInfo: User Information
The complete IXIT lists documentations, publications and information provided to users. The pro forma contains the following entries, which are independent from each other, and is typically filled out in form of a list.
2.1) Documentation of Change Mechanisms: Description of the way the mechanisms to change the authentication values are documented for the user, including all information to access the documentation.
NOTE: Possible ways of documentation are the website of the manufacturer and the corresponding URL, the user manual or built-in help.
2.2) Documentation of Sensors: Description of the way the information about external sensing capabilities is documented for the user, including all information to access the documentation.
NOTE: Possible ways of documentation are the website of the manufacturer and the corresponding URL, the user manual or built-in help.
2.3) Documentation of Personal Data: Description of the way the information about processing personal data is documented for the user, including all information to access the documentation.
NOTE: Possible ways of documentation are the website of the manufacturer and the corresponding URL, the user manual or built-in help.
2.4) Documentation of Telemetry Data: Description of the way the information about collecting telemetry data is documented for the user, including all information to access the documentation.
NOTE: Possible ways of documentation are the website of the manufacturer and the corresponding URL, the user manual or built-in help.
2.5) Model Designation: Model designation of camera device and a brief description of how the user can recognize the model designation of camera device.
NOTE: API call for or labeling sticker on the DUT are options to inform the user about the model designation.
2.6) Support Period: Time during which the product or service is maintained by the manufacturer, e.g. in terms of updates.
2.7) Publication of Support Period: Description of the way the defined “Support Period” is published and documented to the user, including all information to access the publication.
NOTE: Possible way of publication is the website of the manufacturer and the corresponding URL.
2.8) Publication of Vulnerability Disclosure Policy: Description of the way the vulnerability disclosure policy is published, including all information to access the publication.
NOTE: Possible way of publication is the website of the manufacturer and the corresponding URL.
3) IXIT 4-Conf: Confirmations
The complete IXIT lists confirmations for the establishment of processes. The pro forma contains the following entries, which are independent from each other, and is typically filled out in form of a list.
3.1) Confirmation of Update Procedures (Yes/No): Confirmation that for every update procedure described in IXIT 8-UpdProc the required infrastructure is in place and operators are briefed in order to achieve the targeted “Time Frame”.
3.2) Confirmation of Secure Management (Yes/No): Confirmation that the secure management processes described in IXIT 14-SecMgmt are established.
4) IXIT 6-SoftComp: Software Components
The complete IXIT lists all software components of the DUT. The pro forma contains the following entries and is typically filled out in form of a table.
NOTE: The used level of detail concerning the division of camera device software into software components serves for the fact that test laboratory can identify which components are updatable and which are not.
4.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme. EXAMPLE: Sequential numbering (“SoftComp-1”) or labeling scheme (“SoftComp-Firmw”).
4.2) Description: Brief description of the software component.
NOTE: BIOS, firmware and boot loader are possible software components of camera device.
4.3) Update Mechanism: Reference to update mechanisms in IXIT 7-UpdMech that are used for updating the software component. An empty list of update mechanisms indicates the absence of updates for the software component and in this case a justification is provided.
5) IXIT 7-UpdMech: Update Mechanisms
The complete IXIT lists all update mechanisms of camera device. The pro forma contains the following entries and is typically filled out in form of a table.
5.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“UpdMech-1”) or labeling scheme (“UpdMech-Firmw”).
5.2) Description: Brief description of the update mechanism including its major characteristics. It is indicated additionally whether the delivery of an update is network-based.
NOTE: Depending on the complexity it may be useful to divide the description into the steps in which the update is performed.
5.3) Security Guarantees: Description of the realized security objectives and the threats the mechanism is protected against. For authenticity and integrity is indicated additionally whether the security guarantee is given by camera device itself.
Example: The mechanism validates the integrity and authenticity before the installation of an update on camera device itself.
5.4) Cryptographic Details: Description of the cryptographic methods (protocols, operations, primitives, modes and key-sizes) used to secure the update mechanism considering key management, and to facilitate the described “Security Guarantees”.
Example: Authenticity and integrity of a software update is realized by a signed firmware package based on IETF RFC 3852 [5]. For the signature SHA-256 with RSA 2048 and PSS padding is used. The signing of the firmware package is performed with the private key of the manufacturer. The public key for the update validation is integrated during the manufacturing process of camera device.
5.5) Initiation and Interaction: Brief description of the procedure how an update is initiated and a brief description of the user interaction, which is necessary to initiate and apply an update.
6) IXIT 8-UpdProc: Update Procedures
The complete IXIT lists procedures of the manufacturer for the management of security updates. The pro forma contains the following entries and is typically filled out in form of a table.
6.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme. Example: Sequential numbering (“UpdProc-1”) or labeling scheme (“UpdProc-SecUpd”).
6.1) Description: Brief description of the procedure for deploying security updates including all entities and responsibilities.
6.1) Time Frame: Targeted time frame for completing the procedure.
7) IXIT 10-SecParam: Security Parameters
The complete IXIT lists all sensitive (public and critical) security parameters that are persistently stored on camera device during intended usage. The pro forma contains the following entries and is typically filled out in form of a table.
7.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“SecParam-1”) or labeling scheme (“SecParam-Pswd”).
7.2) Description: Brief description of the security parameter, including its purpose. It is indicated additionally whether the parameter is a hard-coded unique per device identity used in a device for security purposes (hard-coded identity) and/or hard-coded in device software source code.
7.3) Type: Indication whether the security parameter is public or critical.
NOTE: Public and critical security parameters are defined in this Regulation.
7.4) Security Guarantees: Description of the realized baseline security objectives and threats the security parameter is protected against during persistent storage.
7.5) Protection Scheme: Description of the measures that are applied to achieve the Security Guarantees. This includes the principals and roles through which access to the parameter is possible, including the privileges associated to each role.
7.6) Provisioning Mechanism: If the “Type” indicates that the parameter is critical: Description of the mechanism through which the parameter is assigned its value for the operation of camera device.
7.7) Communication Mechanisms: Reference to communication mechanisms in IXIT 11-ComMech that are used for communicating the parameter and an indication whether the communication is done via remotely accessible interfaces.
7.8) Generation Mechanism: If the “Type” indicates that the parameter is critical and used for integrity and authenticity checks of software updates or for protection of communication with associated services: Description of the mechanism used to generate the values of the parameter and it is indicated additionally that the parameter is used for integrity and authenticity checks of software updates or for protection of communication with associated services.
Example: References to a standard random number generator and applicable design documents.
8) IXIT 11-ComMech: Communication Mechanisms
The complete IXIT lists all communication mechanisms of camera device. The pro forma contains the following entries and is typically filled out in form of a table.
8.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“ComMech-1”) or labeling scheme (“ComMech-IP”).
8.2) Description: Brief description of the communication mechanism, including its purpose and a description of the used protocol. For standardized protocols a reference is sufficient. It is indicated additionally whether the mechanism is remotely accessible.
NOTE: A possible communication mechanism is the use of Bluetooth®, WiFi® or NFC for a local connection between a mobile application and camera device.
8.3) Security Guarantees: Description of the realized security objectives and the threats the mechanism is protected against.
NOTE: The most common security guarantees to be considered include authentication of peers, authentication of origin, integrity protection, confidentiality protection, and anti-replay.
8.2) Cryptographic Details: Description of the cryptographic methods (protocols, operations, primitives, modes and key-sizes) used to secure the communication mechanism considering key management, and to facilitate the described “Security Guarantees”.
NOTE: Cryptographic Details contain information such as: the protocol Z-Wave® with Security 2 Command Class v1 is used for the communication. The transferred data is authenticated encrypted with AES-128 CCM to facilitate confidentiality and integrity. The key exchange is based on an out-of-band mechanism.
8.3) Resilience Measures: Description of the measures to ensure that the connection establishment is performed in an orderly fashion including an expected, operational and stable state to achieve a stable connection.
NOTE: Resilience measures consider the sequence of the used protocol, the capability of the infrastructure, reset and initialization of the protocol and problems caused by mass reconnections.
9) IXIT 13-SoftServ: Software Services
The complete IXIT lists all software services of the DUT. The pro forma contains the following entries and is typically filled out in form of a table.
9.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“SoftServ-1”) or labeling scheme (“SoftServ-WebServ”).
9.2) Description: Brief description of the service, including its purpose. It is indicated additionally whether the service is accessible via network interface and whether this is the case in the initialized state.
NOTE: A SSH daemon not started by default (disabled), because it was used only for development purposes, is such a service.
9.3) Allows Configuration (Yes/No): If the service is accessible via network interface: Indication whether the service allows security-relevant changes in configuration and if so, a brief description of the possible configuration.
9.4) Authentication Mechanism: If the service is accessible via network interface: Reference to authentication mechanisms in IXIT 1-AuthMech that are used for authentication prior the use of the service.
10) IXIT 14-SecMgmt: Secure Management Processes
The complete IXIT lists all secure management processes for critical security parameters implemented by the SO for camera device. The pro forma contains the following entries and is typically filled out in form of a table.
10.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“SecMgmt-1”) or labeling scheme (“SecMgmt-Passwd”).
10.2) Brief description of the secure management process regarding the whole life cycle for critical security parameters. If an existing standard is used, a reference to the corresponding standard is provided.
NOTE: The life cycle of a critical security parameters typically considers generation, provisioning, storage, updates, decommissioning, archival, destruction, processes to handle the expiration and compromise of the parameter.
11) IXIT 15-intf: Interfaces
The complete IXIT lists all network, physical and logical interfaces of camera device. The pro forma contains the following entries and is typically filled out in form of a table.
11.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“Intf-1”) or labeling scheme (“Intf-LanPort”).
11.2) Description: Brief description of the interface, including its purpose. For physical interfaces, it is described additionally whether the interface is always required, never required or required only in specific cases (e.g. intermittently usage), which are briefly described then.
11.3) Type: Indication whether the interface is network, physical (includes also air interfaces), logical or several types.
11.4) Status: Indication whether the interface is enabled or disabled in the initialized state. For enabled interfaces a justification is given.
11.5) Disclosed Information: If the interface is a network interface: Description of the information disclosed without authentication in the initialized state and the reason for the disclosure. It is indicated additionally whether the information is security-relevant.
NOTE: Disclosed information can be used by an attacker to identify a vulnerable device, e.g. software version.
11.6) Debug Interface: If the interface is a physical interface: Indication whether the interface can be used as debug interface.
Protection: If the interface is a physical interface: Description of the protection methods necessary to limit exposure of the interface.
12) IXIT 21-PersData: Personal Data
The complete IXIT lists all personal data processed by camera device. The pro forma contains the following entries and is typically filled out in form of a table.
12.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“PersData-1”) or labeling scheme (“PersData-PayInfo”).
12.2) Description: Brief description of the category of personal data processed by camera device.
Example: Log data on the usage of camera device, payment information, timestamped location data, audio input stream or biometric data. Categories of personal data need to be described at a level of detail that provides a general understanding of what kind of data is being processed. This includes a general understanding of the level of sensitivity of personal data aligned with well-known terminology.
12.3) Processing Activities: Description of how the personal data is being processed, including all involved parties. It is described additionally for what purposes the processing is done.
NOTE: Permanent storage of personal data, also as backup, is a processing activity.
12.4) Communication Mechanisms: Reference to communication mechanisms in IXIT 11-ComMech that are used for communicating the personal data and an indication whether the communication partner is an associated service (Yes/No). An empty list of communication mechanisms indicates that the personal data is not transmitted.
12.5) Sensitive (Yes/No): Indication whether the personal data is sensitive according to the definition in the provision 2.7-1 of this Regulation.
12.6) Obtaining Consent: If the personal data is processed on the basis of consumer’s consent: Description of how the consent for the processing is obtained from the consumer.
12.7) Withdrawing Consent: If the personal data is processed on the basis of consumer’s consent: Description of how the consumer can withdraw the consent for processing the personal data.
13) IXIT 22-ExtSens: External Sensors
The complete IXIT lists all external sensing capabilities of camera device. The pro forma contains the following entries and is typically filled out in form of a table.
13.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“ExtSens-1″) or labeling scheme (“ExtSens-Cam”).
13.2) Description: Brief description of the sensing capability.
14) IXIT 23-ResMech: Resilience Mechanisms
The complete IXIT lists all resilience mechanisms for network connectivity and power outages of camera device. The pro forma contains the following entries and is typically filled in the form of a table.
14.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“ResMech-1”) or labeling scheme (“ResMech-Power”).
14.2) Description: Description of the mechanism that contributes to the DUT’s resilience to network and/or power outages.
14.3) Type: Indication whether the resilience mechanism addresses network connectivity or power outages or both.
14.4) Security Guarantees: Description of the realised security objectives and the threats the mechanism protects against.
Example: The mechanism protects camera device’s data integrity in case of a power outage.
15) IXIT 24-TelData: Telemetry Data
The complete IXIT lists all telemetry data collected by camera device. The pro forma contains the following entries and is typically filled out in form of a table.
15.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“TelData-1”) or labeling scheme (“TelData-CrashLog”).
15.2) Description: Brief description of the telemetry data being collected and provided to the manufacturer by camera device.
15.3) Purpose: Brief description for what purpose the data is collected.
16) IXIT 25-DelFunc: Deletion Functionalities
The complete IXIT lists all deletion functionalities for data of the user. The pro forma contains the following entries and is typically filled out in form of a table.
16.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“DelFunc-1”) or labeling scheme (“DelFunc-CloudServ”).
16.2) Description: Brief description of the functionality used to delete data of the user. If the “Target Type” indicates, that an associated service is addressed: The concerning associated service which is covered by the functionality is indicated additionally.
NOTE: Camera device’s settings could provide a functionality to remove personal data from a cloud server.
16.3) Target Type: Indicates whether the functionality addresses user data on the device or personal data on associated services or both.
16.4) Initiation and Interaction: Brief description of the user interaction, which is necessary to initiate and apply the deletion functionality.
17) IXIT 27-Userlntf: User Interfaces
The complete IXIT lists all user interfaces of camera device, which enable input from the user. The pro forma contains the following entries and is typically filled out in form of a table.
17.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“UserIntM”) or labeling scheme (“UserIntf-Config”).
17.2) Description: Brief description of the user interface enabling data input from the user. It is indicated additionally how the interface can be accessed by the user.
18) IXIT 28-ExtAPI: External APIs
The complete IXIT lists all APIs of camera device, which enables data input from external sources. The pro forma contains the following entries and is typically filled out in form of a table.
18.1) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
Example: Sequential numbering (“ExtAPI-1”) or labeling scheme (“ExtAPI-SOAP-Cloud”).
18.2) Description: Description of the API enabling data input from external sources of camera device.
NOTE: External APIs are typically used for machine-to-machine communication.
19) IXIT 29-lnpVal: Data Input Validation
The complete IXIT lists all data input validation methods of the DUT. The pro forma contains the following entries and is typically filled out in form of a table.
19.2) ID: Unique per IXIT identifier, that may be assigned using a sequential numbering scheme or some other labeling scheme.
19.3) Description: Description of the method for validating the data input via user interfaces, or transferred via APIs and between networks in services and devices including the handling of unexpected data. It is indicated additionally which of the sources for data input are addressed by the method.
Reference
[1] ISO/IEC 29147: “Information technology – Security techniques – Vulnerability Disclosure”.
[2] NIST Special Publication 800-63B: “Digital Identity Guidelines – Authentication and Lifecycle Management”.
[3] ETSI TR 103 621 (VO.1.6) (2021-06): “CYBER; Guide to Cyber Security for Consumer Internet of Things”.
[4] IETF RFC 7235: “Hypertext Transfer Protocol (HTTP/1.1): Authentication”.
[5] IETF RFC 3852: “Cryptographic Message Syntax (CMS)”.
[6] ISO/IEC 15408: “Information security, cybersecurity and privacy protection – Evaluation criteria for IT security”.
