FAQ

Besidescontrollingdevicephysically,onlydevice’sownercanremotelycontrolthedeviceviaTracksolid PROapplication. There is an authentication mechanism in application to prevent unauthorized user to control device. All remote communications are protected using cryptographic methods to ensure only device’s owner has the permission forcontrolling. Only customers can control the device, manufacturer can manage the running status of the device and provide upgrades.

Not found yet.

After the device is powered on, there is a certain time threshold for binding, which may have the security risks brought by the long-term opening of Bluetooth broad casting and AP hot spots. The device will turn off Bluetooth broadcast or AP hotspot after a certain period (default is 5 minutes, determined by business). If using a publicly accessible network to connect the device with Jimi cloud, it needs to ensure that the network state is secure. OTA updates have a breakpoint continuation mechanism and the ability to roll back a previously available state. At unattended state, the IoT device

Communication protocols follow the principles of confidentiality, integrity and availability. There is an authentication mechanism for communication between device and APP, device and cloud, and cloud and APP. The session key is obtained through TLS1.2 handshake. TLS 1.2 is used for integrity verification during data transmission. And local data is stored in encryption, such as the account and password of AP is encrypted with Root Key, which is derived from the IMEI of the chip hardware. In general, Jimi uses strong secure cryptographic algorithms and secure protocol to protect all the traffic between device and cloud, device and application.

It does not add complexity to other devices, systems or environments. When the user uses the device, the device will only interact with the mobile APP and the cloud server without affecting other devices and systems. The function of the device itself is to improve the physical environment without complicating it.

1. The production firmware file is burned in the device, and no other configuration files need to be changed during use. 2. Only device’s owner have remote access to the device as there is relationship binding during initialization.

The debug interface has been closed, and unauthorized users cannot access it, and Wi-Fi and BLE interface can’t be access without authorization. 1.Physical protection: There isn’t any external interfaces on device that allows reading / writing firmware data or configuration data. 2.Network connection protection: There is authentication mechanisms sitting in both cloud, application and device to prevent any malicious/unauthenticated connections.

The device factory setting is a secure default configuration, the DVR performs predetermined functions according to the default configuration, and the attacker cannot access the device without authorization, the secure default configuration is defined by manufacturer.

The module has a log reporting mechanism, which only supports error log reporting at present. The crash log includes the connection fail info of the router or server, etc. The mechanism is not a real-time reporting. After login on the server, upload the crash log. And the log data can be viewed through the backend.

if different storages are used, please describe the authentication and authorization procedures respectively. Due to limited local storage capacity, the device does not store log information locally, but uploads it to cloud storage through an encrypted channel. In the cloud service, only the database management account has the authority to view log information. If the account is not authorized, access to the device log information is prohibited.