web
You’re offline. This is a read only version of the page.
close
Support Portal

Secure LiDAR sensor configuration with HTTPS

This article explains the importance of using HTTPS for secure sensor configuration. It shows how encryption, authentication and certificate management.
Related Products
picoScan100
multiScan100

Table of Contents

HTTPS, short for Hypertext Transfer Protocol Secure, is a secure extension of the traditional HTTP protocol. It uses encryption through TLS (Transport Layer Security) to encrypt communication between devices. This encryption ensures that sensitive information, such as configuration settings sent to sensors, cannot be intercepted or altered by unauthorized parties. Beyond encryption, HTTPS also authenticates the device, guaranteeing that users connect to the legitimate device.

For many sensors, it is not the measurement data transfers that require encryption, but specifically the access to the device’s configuration. Securing this configuration access via HTTPS is crucial because it protects login credentials, network parameters, and other sensitive settings from being exposed or manipulated. Without HTTPS, attackers might intercept or alter configurations like alarm thresholds or network settings, potentially compromising the sensor or the system it supports.

HTTPS and CRA

In the context of the European Cyber Resilience Act (CRA), the use of HTTPS is even more significant. The CRA, which applies to all products with digital components sold in the EU market, imposes mandatory cybersecurity requirements to ensure products are secure throughout their lifecycle. One fundamental CRA requirement is securing communication channels, such as those used to configure sensors, against cyber threats. HTTPS is a core measure to meet these requirements, providing confidentiality, integrity, and authenticity in device configuration communication.

Moreover, HTTPS helps manufacturers comply with CRA demands for security by design and secure by default principles. It reduces attack surfaces on connected devices, enables safe management practices, and builds trust in products by protecting against unauthorized access or tampering. As the CRA governs product cybersecurity rigorously, using HTTPS for sensor configuration is both a technical necessity and a regulatory imperative to ensure product security and compliance in today’s digital ecosystem.

Certificates and keys

Certificates and keys in HTTPS serve essential functions for secure communication:

  • Certificates are digital documents issued by trusted Certificate Authorities (CAs). They contain the public key along with information that verifies the servers (e.g. sensor) identity. This allows clients (e.g., browsers or sensor management systems) to authenticate and trust the server they connect to, ensuring they communicate with the intended device.
  • Public and Private Keys work as a cryptographic pair. The public key, included in a certificate, is used by clients to encrypt data sent to the server. The private key, securely kept on the server, decrypts this data. This system ensures that even if data is intercepted during transmission, it cannot be decrypted without the private key.

The following image shows the relationship between certificate/key and client/server.

Together, certificates and keys enable encryption, authentication, an integrity of the data exchanged between client and server over HTTPS, protecting sensitive information such as configuration settings from being intercepted or tampered with by unauthorized parties.

Please note that creating and managing certificates and keys require specialized knowledge and expertise. Typically, certificate issuance and management are handled by IT infrastructure operators or dedicated security teams to ensure proper configuration and security compliance

Device specific information

A range of sensor specific information is required for certificate generation and HTTPS communication:

picoScan100 and multiScan100 family

Functions included:

Port:  

Certificate standard:

Certificate format:

Minimum key requirements:

 

 

 

Max. chain length:

Highly recommended chain length:

Configuration (no measurement data)

443

X.509

PEM (allowed extensions are .crt, .pem, .cer, and .key)

RSA>3072 bits,
ECDSA > 250 bits,
Edward Curve 25519
or Curve 448

root -> int1 -> int2 -> leaf

root -> int1 -> leaf

Certificate hierarchy

 

Level

Description

Example

Root Certificate   

Trust anchor, self-signed by the Certificate Authority (CA)

root

Intermediate Certificate(s)

Bridge trust from between Root to leaf certificates

int1

Leaf Certificate

End-entity certificate issued for the website or server

leaf

 

Keywords:
cybersecurity, http, https, tls, cra,key security, certificate, sensor, LiDAR, pcioScan, picoScan100, picoScan120, picoScan150, multiScan,, multiScan100,