CurNext
Architecture de sécurité
Contrôles de niveau industriel sur la pile à cinq couches CurNext - des capteurs de terrain au cloud - conçus pour l'IoT industriel, l'OT bâtiment et les attentes européennes en matière de confidentialité.
Cette page résume comment CurNext conçoit la confidentialité, l'intégrité, l'authenticité, la disponibilité, la responsabilité et la vie privée. Ce n'est pas un runbook public, une page de statut ni un coffre de certificats.
Objectifs de sécurité
Confidentialité
La télémétrie et les identifiants ne sont pas lisibles en transit ou au repos sans autorisation.
Intégrité
Le micrologiciel, la configuration et les mesures sont protégés contre toute altération non détectée.
Authenticité
Chaque appareil et chaque service prouve son identité avant que la confiance ne soit accordée.
Disponibilité
Résilience aux pannes, aux rejeux et aux saturations, avec dégradation progressive lorsque c'est possible.
Responsabilité
Piste d'audit pour l'accès, le provisioning, l'OTA et les actions d'administration.
Vie privée
Traitement orienté RGPD des données personnelles et de chantier dans la couche cloud.
Normes auxquelles nous nous alignons
Les contrôles sont cartographiés sur des cadres industriels, IoT et européens largement utilisés. Lister une norme ici signifie un alignement de conception - pas que CurNext a terminé chaque certification tierce pour ce cadre.
| Standard | Scope | How we use it |
|---|---|---|
| IEC 62443 | Zones IoT industrielles / bâtiment | Modèle zones et conduits ; cibles de niveau de sécurité par couche |
| NIST SP 800-82 | ICS / OT bâtiment | Segmentation, surveillance, accès distant via WireGuard uniquement en bordure bâtiment |
| NIST SP 800-213 | Cybersécurité des appareils IoT | Identité appareil, mise à jour sécurisée et configuration |
| ENISA IoT / OT | Socle IoT UE | Crypto, mises à jour et surface d'attaque minimale |
| EU CRA | Cycle de vie sécurité produit | SBOM, divulgation des vulnérabilités, mises à jour signées |
| EU RED 3.3(d) | Cybersécurité des produits radio | Chemin radio et mise à jour sécurisés pour les nœuds terrain, CN-FG et CN-BC |
| ISO 27001 | SMSI organisationnel | Cible de conception pour le cloud et les opérations CurNext - non revendiqué comme certifié ici |
| GDPR | Données personnelles | Journalisation d'audit, contrôle d'accès, chemins d'effacement et d'export |
| OWASP IoT Top 10 | Pièges appareil et cloud | Traités par couche dans les contrôles terrain et cloud |
Cibles de niveau de sécurité IEC 62443
Les niveaux de sécurité cibles (SL-T) guident la conception produit. Ce sont des cibles d'ingénierie, pas des résultats d'évaluation tierce.
| Component | SL-T target | Rationale |
|---|---|---|
| Nœuds capteurs L1 | SL 2 (ambition SL 3) | Sans surveillance, longue durée de vie, accès physique possible |
| CN-FG (L2) | SL 2 | Passerelle terrain sur un chantier |
| CN-UPS (L3) | SL 1 | Alimentation uniquement - aucun traitement de données |
| CN-BC (L4) | SL 3 | Frontière de sécurité du bâtiment, chemin exposé à Internet |
| Cloud CurNext (L5) | SL 3 | Plateforme multi-locataires avec données clients |
Zones de sécurité et conduits
Des zones de style IEC 62443 séparent la radio terrain, le LAN d'étage, la bordure bâtiment et le cloud. L'alimentation n'a aucun conduit de données.
- 01
Zone Z1 - Capteurs terrain L1
Nœuds terrain (CN-CC, CN-WD et SKU associés). MAC LoRaWAN avec AES-128, élément sécurisé pour les clés, NFC pour l'installation. Pas de pile IP sur le nœud.
- 02
Zone Z2 - Étage (CN-FG)
La passerelle d'étage vérifie les trames, reste sur le VLAN local et n'a aucune interface exposée au cloud.
- 03
Zone Z3 - Alimentation (CN-UPS)
Alimente le matériel d'étage et de bordure bâtiment. Aucun conduit de données.
- 04
Zone Z4 - DMZ bâtiment (CN-BC)
Contrôleur bâtiment : client WireGuard, client MQTT, orchestrateur OTA. Chemin cellulaire sortant uniquement pour le tunnel et le trafic broker.
- 05
Zone Z5 - Cloud CurNext (L5)
Application, base de données et auth gérées, broker MQTT privé, IA et stockage objet derrière une protection en périphérie.
Conduit controls
| Conduit | Path | Controls |
|---|---|---|
| C1 | L1 ↔ CN-FG | AES-128 au niveau MAC LoRaWAN (chiffrement de charge utile + MIC), OTAA, clés appareil uniques dans l'élément sécurisé, compteurs de trames, rejet des rejeux |
| C2 | CN-FG ↔ CN-FG | Chaîne Ethernet en daisy-chain sur le VLAN d'étage uniquement ; aucune route Internet |
| C3 | CN-FG ↔ CN-BC | VLAN Ethernet ; le pare-feu bâtiment refuse aux passerelles d'étage un chemin vers Internet public |
| C4 | CN-BC ↔ L5 | WireGuard plus MQTT sur TLS 1.3 avec TLS mutuel ; broker hors Internet public |
| C5 | Installer ↔ L1 | Tap NFC uniquement avec preuve cryptographique ; provisionnement par scan QR désactivé ; les interfaces de debug usine ne restent pas ouvertes sur le terrain |
WireGuard scope
L1-L2
Pas de WireGuard
L3
Pas de WireGuard
L4 CN-BC
Client WireGuard - frontière de sécurité du bâtiment
L5 Cloud
Hub WireGuard - MQTT uniquement sur le maillage privé
Controls by layer
From field nodes to cloud - what each layer must enforce before trust moves upward.
L1
L1 - Capteurs terrain
Identité appareil unique, crypto de liaison radio LoRaWAN, démarrage sécurisé, OTA signé, conception anti-intrusion et détection de déplacement.
- - Clé racine unique par sonde dans un élément sécurisé - jamais partagée dans la flotte
- - Les étiquettes peuvent afficher le numéro de série public / DevEUI pour la logistique - jamais la clé racine
- - LoRaWAN Class A (EU868) : chiffrement de charge utile AES-128 et MIC via la pile MAC
- - Join OTAA uniquement ; compteurs de trames et rejet des rejeux à la passerelle d'étage
- - Démarrage sécurisé, micrologiciel signé, anti-retour arrière, debug de production verrouillé
- - Boîtier terrain et chemin de mesure anti-intrusion - toute interférence physique est détectable et signalée
- - Détection de déplacement lorsqu'un nœud quitte sa position d'installation assignée
- - Affectation terrain via liaison cryptographique NFC - affectation QR désactivée par défaut
L2
L2 - Passerelle d'étage CN-FG
Ancre de confiance pour la liaison radio. Valide le join, le MIC et les compteurs avant transfert.
- - Micrologiciel signé avec démarrage sécurisé et identité d'élément sécurisé
- - Aucune route Internet par défaut ; liaison montante uniquement vers CN-BC sur le VLAN d'étage
- - OTA uniquement depuis CN-BC
- - Événements de join et de vérification conservés pour téléversement d'audit
- - Ports de service restreints dans les images de production
L3
L3 - Alimentation CN-UPS
Chemin d'alimentation uniquement - aucun plan de données sur le VLAN de gestion.
- - Aucun IP ni API de gestion sur le VLAN de données
- - Pratiques de boîtier verrouillé à l'installation
- - L'indication de défaut reste locale - aucune fuite réseau depuis les défauts d'alimentation
L4
L4 - Contrôleur bâtiment CN-BC
Frontière de sécurité du bâtiment entre le LAN d'étage et le cloud.
- - WireGuard sortant depuis le bâtiment (compatible CGNAT)
- - MQTT sur TLS 1.3 avec certificats client par bâtiment
- - Pare-feu hôte en refus par défaut ; pas de SSH, MQTT ou API publics sur le cellulaire
- - Seul chemin OTA vers L1/L2 : vérifier le manifeste et l'image signés, déploiement progressif, rapporter le résultat
- - Tampon de télémétrie store-and-forward chiffré au repos ; purge après livraison réussie
L5
L5 - Cloud CurNext
Application et données multi-locataires avec entrée terrain privée.
- - Broker MQTT accessible uniquement sur le maillage privé - pas sur Internet public
- - Autorisation par bâtiment ; refus des jokers inter-locataires
- - Auth utilisateur avec jetons à courte durée ; MFA requis pour les rôles privilégiés
- - RBAC appliqué sur les routes API ; limites de débit et WAF en périphérie en production
- - Chiffrement en transit et au repos ; isolation des locataires sur les requêtes
- - Sauvegardes chiffrées avec exercices de restauration ; chemins d'audit, d'export et d'effacement RGPD
- - Secrets conservés dans un gestionnaire de secrets - pas dans le contrôle de source
OTA et chaîne d'approvisionnement logicielle
Aligné sur les attentes du Cyber Resilience Act de l'UE pour les mises à jour signées, le SBOM et la divulgation coordonnée.
- 01CA racine hors ligne
- 02CA de signature OTA
- 03Images / manifestes L1, CN-FG et CN-BC signés
- - Signatures de micrologiciel avec ECDSA P-256 (ou RSA plus fort si requis)
- - Le manifeste inclut la classe d'appareil, la version, la version minimale, le hash, la signature et l'époque de révocation
- - Matériel de signature compromis tourné via un chemin d'urgence
- - Partitions A/B sur les appareils terrain avec retour arrière en cas d'échec au démarrage
- - Déploiement progressif avant application à toute la flotte
- - SBOM par micrologiciel et version cloud ; surveillance continue des vulnérabilités
- - Mises à jour de sécurité critiques visées sous 14 jours ; élevées sous 30 jours
Factory
- - Le HSM d'usine injecte un matériel d'identité appareil unique dans l'élément sécurisé
- - Démarrage sécurisé activé avant expédition
- - Personnalisation NFC avec preuve cryptographique
- - Appareil enregistré comme fabriqué ; les clés ne sont jamais expédiées dans des tableurs ou des e-mails
Field install
- - Le tap NFC de l'installateur vérifie la liaison cryptographique
- - La liaison de surface exige une session d'app authentifiée et une permission d'affectation d'appareil
- - Le scan QR n'est pas fiable pour une affectation cryptographique
- - La mise en service du bâtiment émet le pair WireGuard et les identifiants client MQTT à l'installation
Cryptographie en un coup d'œil
| Use | Algorithm |
|---|---|
| Transport (cloud / MQTT) | TLS 1.3 |
| Tunnel bâtiment | WireGuard - Curve25519, ChaCha20-Poly1305 |
| Liaison radio (L1 ↔ CN-FG) | Chiffrement AES-128 MAC LoRaWAN + MIC |
| Signature micrologiciel | ECDSA P-256 |
| Tampon de télémétrie local | AES-256-GCM au repos en bordure bâtiment |
| Intégrité d'audit | SHA-256 |
Non utilisés : TLS 1.0/1.1, MD5, SHA-1 pour les signatures, ou clés de session radio statiques sans OTAA.
Comment nous vérifions
Les versions et les opérations annuelles suivent une barre de sécurité fixe avant usage entreprise.
- - Mise à jour du modèle de menaces par zone pour les versions matérielles
- - Listes de contrôle par couche pour L1, CN-FG, CN-BC et cloud
- - Analyse statique et scan des dépendances sans CVE critique ouverte à la publication
- - Artefact signé et SBOM joints à la version
- - Test de pénétration externe annuel et exercices de rotation de clés / restauration de sauvegarde
- - Préparation à la certification (évaluation IEC 62443, SMSI ISO 27001, dossier technique RED) suivie séparément - non revendiquée comme complète sur cette page
Divulgation et contact
Signalez les vulnérabilités à la boîte de sécurité CurNext. Pour le détail confidentialité et résidence, utilisez les politiques liées et la page des centres de données.
- - Divulgation coordonnée : [email protected]
- - Entité juridique : CurNext, Helsinki, Finlande
- - La politique de confidentialité couvre le traitement des données personnelles
- - La page Centres de données couvre la résidence d'hébergement UE (Allemagne / Francfort)
Les traductions sont fournies à titre indicatif. En cas d'accord signé, la version anglaise fait foi.