IoT Bezpečnosť: Sprievodca pre HW Inžinierov

Čo vám konkurencia o IoT bezpečnosti nepovie

Väčšina sprievodcov IoT bezpečnosťou sa zameriava na IT bezpečnosť aplikovanú na IoT — firewally, záplaty, riadenie prístupu, Zero Trust. To je nevyhnutné, ale pre priemyselné systémy nedostatočné.

Čo im uniká:

Čo pokrýva konkurencia ❌	Na čom skutočne záleží ✅
„Zmeňte predvolené heslá”	Hardware Root of Trust — heslá sa dajú extrahovať z flash pamäte; secure elementy nie
„Používajte šifrovanie”	Životný cyklus správy kľúčov — kde sa kľúče generujú, ukladajú, rotujú a revokujú?
„Udržujte softvér aktuálny”	Autentifikované aktualizácie firmvéru — ako zabránite škodlivej aktualizácii, ktorá vyradí 10 000 zariadení?
„Segmentujte sieť”	Ochrana proti fyzickej manipulácii — čo sa stane, keď má niekto fyzický prístup k zariadeniu?
„Spustite antivírus”	Pre embedded systémy neexistuje antivírus — bezpečnosť musí byť navrhnutá v hardvéri
„Monitorujte anomálie”	Kompromitované zariadenie môže klamať — iba hardvérová atestácia dokazuje integritu zariadenia

Tento sprievodca rieši IoT bezpečnosť od hardvéru nahor — z perspektívy, na ktorej záleží pri navrhovaní produktov, nie len pri ich nasadzovaní.

Skutočné náklady zlyhania

Zlyhania priemyselnej IoT bezpečnosti nie sú abstraktné — majú kvantifikovateľné dôsledky:

Incident	Dopad	Príčina
Triton/TRISIS (2017)	Pokus o výbuch v saudskej petrochemickej továrni	Malvér cieliaci na bezpečnostné systémy (SIS)
Colonial Pipeline (2021)	Výkupné $4,4M, prerušenie dodávok paliva v USA na 6 dní	Kompromitované VPN prihlasovacie údaje, žiadne MFA na OT prístupu
Kamery Verkada (2021)	150 000 kamier kompromitovaných (Tesla, nemocnice, väznice)	Napevno zakódované admin prihlasovacie údaje vo firmvéri
Oldsmar voda (2021)	Pokus o otrávenie pitnej vody (hydroxid sodný 100×)	Vzdialený prístup k SCADA bez autentifikácie
MOVEit (2023)	2 500+ organizácií napadnutých	Nezáplatované zariadenie na prenos súborov

Spoločný menovateľ: Každé veľké narušenie IIoT využilo buď chýbajúcu hardvérovú bezpečnosť, nezáplatovaný softvér, alebo nedostatočné riadenie prístupu. Bezpečnosť založená len na softvéri zlyhala v každom prípade.

Priemerné náklady priemyselného bezpečnostného incidentu: 4,7 milióna € (IBM Cost of a Data Breach 2025). Pri kritickej infraštruktúre to môže zahŕňať aj ohrozenie ľudského zdravia.

Architektúra bezpečnostného zásobníka

Zabezpečenie priemyselného IoT zariadenia vyžaduje obranu na každej vrstve:

┌────────────────────────────────────────────┐
│          CLOUD / BACKEND BEZPEČNOSŤ       │
│  API autentifikácia, správa certifikátov  │
│  Správa zariadení, audit logy             │
├────────────────────────────────────────────┤
│          APLIKAČNÁ BEZPEČNOSŤ             │
│  Validácia vstupov, bezpečné kódovanie    │
│  Šifrované úložisko, riadenie prístupu    │
├────────────────────────────────────────────┤
│          KOMUNIKAČNÁ BEZPEČNOSŤ           │
│  Obojstranný TLS, DTLS, šifrovaný MQTT   │
│  Certificate pinning, rotácia kľúčov      │
├────────────────────────────────────────────┤
│          BEZPEČNOSŤ FIRMVÉRU              │
│  Podpísané aktualizácie, rollback ochrana │
│  Bezpečný bootloader, podpisovanie kódu   │
├────────────────────────────────────────────┤
│          OS / RTOS BEZPEČNOSŤ             │
│  Ochrana pamäte, separácia privilégií     │
│  Secure storage API, watchdog             │
├────────────────────────────────────────────┤
│     ★ HARDVÉROVÁ BEZPEČNOSŤ (Základ) ★   │
│  Secure element / TPM, secure boot ROM    │
│  Hardvérový RNG, detekcia manipulácie     │
│  Fúzované kľúče, blokovanie debug portov  │
└────────────────────────────────────────────┘

Kľúčový princíp: Bezpečnosť prúdi smerom nahor. Ak je hardvérová vrstva kompromitovaná, každá vrstva nad ňou je kompromitovaná. Preto je hardvérová bezpečnosť základ, nie dodatok.

Best Practice 1: Hardware Root of Trust

Najkritickejšie rozhodnutie v návrhu IoT bezpečnosti je ustanovenie Hardware Root of Trust — nemennej, odolnej voči manipulácii, komponenty, ktorá slúži ako bezpečnostná kotva celého systému.

TPM vs Secure Element vs MCU-integrované: Čo použiť?

Vlastnosť	Diskrétny TPM	Secure Element	MCU-integrovaný (TrustZone/PSA)
Štandardy	TCG TPM 2.0 (ISO 11889)	CC EAL5+/EAL6+	PSA Certified (Level 1–3)
Ukladanie kľúčov	RSA/ECC kľúče, zapečatené úložisko	ECC/AES kľúče, X.509 certifikáty	Izolovaný bezpečný enkláv
Odolnosť voči manipulácii	Stredná (diskrétny čip)	Vysoká (navrhnuté pre fyzické útoky)	Nízka–Stredná (zdieľaný čip)
Cena	2–8 € za kus	0,50–3 € za kus	0 € (zabudované v MCU)
Krypto výkon	Stredný (I2C/SPI zbernica)	Stredný	Rýchly (na čipe)
Najlepšie pre	PC/serverové zariadenia, Linux	IoT zariadenia, smart karty	Cenovo citlivé MCU návrhy
Príklady čipov	Infineon SLB 9670, Microchip ATECC608B	NXP SE050, Infineon OPTIGA Trust M	STM32U5 (TrustZone), nRF5340

Kedy čo použiť

• Batériový IoT senzor → MCU-integrovaný TrustZone (najnižšia cena, akceptovateľné pre PSA Level 2)
• Priemyselný gateway → Diskrétny TPM 2.0 (TCG štandard, auditovateľný, podpora Linuxu)
• Platobný terminál alebo kritická infraštruktúra → Secure Element (CC EAL5+, najvyššia odolnosť)
• FPGA systém → Šifrovanie bitstreamu + externý secure element pre ukladanie kľúčov

Implementačný checklist

□ Unikátna identita zariadenia (X.509 certifikát na zariadenie, nie na sériu)
□ Privátny kľúč generovaný na čipe (nikdy neopúšťa secure element)
□ Hardvérový RNG pre generovanie kľúčov (nie softvérový PRNG)
□ Monotónny počítadlo pre ochranu proti rollbacku
□ Debug port (JTAG/SWD) deaktivovaný v produkčnom firmvéri
□ Fuse bity nastavené pre zabránenie čítaniu flash
□ GPIO detekcia manipulácie (voliteľné, pre vysoko bezpečné aplikácie)

Pre detailné implementačné vzory pozrite našu stránku Embedded Security & IoT.

Best Practice 2: Secure Boot reťazec

Secure boot reťazec zabezpečuje, že na zariadení beží iba autentifikovaný, nemanipulovaný kód, od zapnutia po aplikáciu:

 Zapnutie
    ↓
 1. Boot ROM (nemenný, v kremíku)
    → Overuje podpis bootloadera pomocou OTP fúzovaného verejného kľúča
    ↓
 2. Bootloader (prvý aktualizovateľný stupeň)
    → Overuje podpis obrazu firmvéru (ECDSA P-256 alebo Ed25519)
    → Kontroluje rollback počítadlo (zabraňuje downgrade útokom)
    ↓
 3. Firmvér / RTOS
    → Overuje integritu aplikácie
    → Inicializuje bezpečné úložisko
    ↓
 4. Aplikácia
    → Nadväzuje TLS spojenie s backendom
    → Začína normálnu prevádzku

Časté chyby Secure Bootu

Chyba	Dôsledok	Oprava
Ukladanie podpisového kľúča vedľa firmvéru	Útočník extrahuje kľúč, podpíše škodlivý firmvér	Kľúč iba v secure elemente, nikdy vo flash
Žiadna ochrana proti rollbacku	Útočník nahrá starý zraniteľný firmvér	Monotónne počítadlo v OTP fúzoch
Overovanie iba prvého stupňa	Neskoršie stupne môžu byť modifikované nedetekované	Reťazec dôvery — každý stupeň overuje nasledujúci
Debug port ponechaný otvorený v produkcii	JTAG/SWD obchádza celý boot reťazec	Fúzovať deaktiváciu JTAG pred nasadením
Používanie iba SHA-256 (bez podpisu)	Hash sa dá prepočítať pre modifikovaný firmvér	Používať overovanie podpisu ECDSA alebo Ed25519

FPGA-špecifický Secure Boot

FPGA majú unikátne požiadavky na secure boot, pretože celá hardvérová konfigurácia sa načítava pri zapnutí:

1. Šifrovanie bitstreamu — AES-256 šifrovanie konfiguračného súboru FPGA
2. Autentifikácia bitstreamu — overenie podpisu RSA/ECDSA pred načítaním
3. Ukladanie kľúčov — eFUSE alebo batériou zálohovaná RAM pre šifrovacie kľúče
4. Záložný režim — golden/recovery bitstream ak primárna autentifikácia zlyhá
5. Čiastočná rekonfigurácia — aktualizácia iba časti FPGA bez opätovného načítania všetkého

AMD/Xilinx a Intel/Altera FPGA natívne podporujú tieto funkcie. Naše FPGA Design služby zahŕňajú bezpečnostnú architektúru od začiatku každého projektu.

Best Practice 3: Šifrovaná komunikácia

Každá dátová cesta v IoT systéme musí byť šifrovaná a autentifikovaná:

Výber protokolu pre priemyselné IoT

Protokol	Bezpečnosť	Réžia	Najlepšie pre	Odporúčanie
MQTT + TLS 1.3	Silná	Stredná (TCP + TLS)	Cloud-pripojené zariadenia, telemetria	✅ Predvolená voľba pre IP zariadenia
MQTT-SN + DTLS	Silná	Nižšia (UDP-based)	Obmedzené zariadenia, stratové siete	✅ Vhodné pre LoRaWAN/NB-IoT
CoAP + DTLS	Silná	Nízka	RESTful obmedzené zariadenia	✅ Alternatíva k MQTT pre request/response
OPC UA	Silná (vstavaná)	Vysoká	Priemyselná automatizácia, SCADA	✅ Štandard pre výrobnú halu
Modbus TCP	❌ Žiadna natívne	Nízka	Legacy priemyselné	⚠️ Zabaliť do VPN alebo TLS tunelu
BLE	Stredná (AES-CCM)	Nízka	Senzory krátkeho dosahu	⚠️ Akceptovateľné pre nekritické dáta
LoRaWAN	AES-128 (vstavaná)	Veľmi nízka	LPWAN senzory	✅ Akceptovateľné pre dáta zo senzorov

Obojstranný TLS: Prečo nestačí iba serverový TLS

Štandardný HTTPS/TLS autentifikuje iba server. V IoT sa musí zariadenie tiež autentifikovať voči serveru (obojstranný TLS / mTLS):

Štandardný TLS:
  Zariadenie → „Dôverujem ti, server" (overuje certifikát servera)
  Server → „Neviem, kto si" (prijíma akéhokoľvek klienta)

Obojstranný TLS:
  Zariadenie → „Dôverujem ti, server" (overuje certifikát servera)
  Server → „Dokáž, že si skutočné zariadenie" (overuje certifikát zariadenia)
  Zariadenie → Predkladá X.509 certifikát zo secure elementu
  Server → Overené — spojenie nadviazané

Prečo záleží na mTLS: Bez autentifikácie zariadení môže útočník predstierať zariadenie, vkladať falošné dáta zo senzorov alebo exfiltrovať príkazy určené pre legitímne zariadenia.

Rotácia kľúčov a životný cyklus certifikátov

 Výroba → Zariadenie prevádzkované s počiatočným certifikátom
      ↓
 Nasadenie → Certifikát zaregistrovaný v IoT platforme
      ↓
 Prevádzka → Certifikáty rotované každých 1–2 roky
      ↓
 Vyradenie → Certifikát revokovaný, zariadenie vymazané

Kľúče by nikdy nemali byť zdieľané medzi zariadeniami. Každé zariadenie dostáva unikátny pár kľúčov vygenerovaný v jeho secure elemente počas výroby.

Best Practice 4: Bezpečné aktualizácie firmvéru (OTA)

Schopnosť aktualizovať nasadené zariadenia je bezpečnostnou požiadavkou aj bezpečnostným rizikom. Kompromitovaný mechanizmus aktualizácií dáva útočníkom root prístup k celej flotile zariadení.

Bezpečnostné požiadavky na OTA aktualizácie

Požiadavka	Účel	Implementácia
Podpisovanie kódu	Overenie autenticity aktualizácie	Podpis ECDSA-P256 alebo Ed25519
Šifrovanie	Zabránenie reverzného inžinierstva firmvéru	AES-256 šifrovanie balíka aktualizácie
Ochrana proti rollbacku	Zabránenie downgradu na zraniteľnú verziu	Monotónne počítadlo v OTP/secure elemente
Atomická aktualizácia	Zabránenie bricknutia pri prerušení	A/B partičná schéma alebo delta aktualizácie
Overenie verzie	Zaistenie správneho firmvéru pre správne zariadenie	Hardware ID + kontrola verzie pred aplikáciou
Audit trail	Sledovanie stavu aktualizácie celej flotily	Backend logovanie per-zariadenie

A/B architektúra aktualizácií

 Rozloženie Flash pamäte:
 ┌────────────────┐
 │   Bootloader   │  Overuje aktívnu partíciu
 ├────────────────┤
 │  Partícia A    │  ← Aktuálne bežiaca (v2.1)
 ├────────────────┤
 │  Partícia B    │  ← Nová aktualizácia zapísaná sem (v2.2)
 ├────────────────┤
 │  Bezpečný úl.  │  Kľúče, certifikáty, konfigurácia
 └────────────────┘

 Proces aktualizácie:
 1. Stiahnutie v2.2 do Partície B (kým beží v2.1)
 2. Overenie podpisu v2.2
 3. Kontrola rollback počítadla (v2.2 > v2.1 ✓)
 4. Označenie Partície B ako „čakajúca"
 5. Reštart → bootloader skúša Partíciu B
 6. Ak boot uspeje → označenie B ako „aktívna"
 7. Ak boot zlyhá → automatický rollback na Partíciu A

Toto nie je voliteľné — EU Cyber Resilience Act vyžaduje autentifikované aktualizácie firmvéru pre všetky pripojené produkty predávané v EÚ od roku 2027. Pozrite náš CRA Compliance Checklist.

Best Practice 5: Segmentácia siete a Zero Trust

Purdue Model pre priemyselné siete

Priemyselné siete by mali nasledovať vrstvovú segmentáciu:

 Level 5: Enterprise    │ ERP, email, internet
 ───── DMZ ─────────────┤ Firewall + IDS
 Level 4: Business      │ MES, historian, reporting
 ───── DMZ ─────────────┤ Priemyselný firewall
 Level 3: Operations    │ HMI, SCADA, inžiniering
 ────────────────────────┤ Managed switch + ACL
 Level 2: Control       │ PLC, DCS, RTU
 ────────────────────────┤ Fyzická izolácia
 Level 1: Field         │ Senzory, aktuátory, pohony
 Level 0: Process       │ Fyzické zariadenia

Zero Trust pre OT — Praktická implementácia

Zero Trust v priemyselných prostrediach neznamená „autentifikujte všetko pomocou MFA” — niektoré zariadenia nemajú ani obrazovku. Praktický Zero Trust pre OT znamená:

1. Mikrosegmentácia siete — každé zariadenie alebo skupina v samostatnej VLAN
2. Identita zariadenia — autentifikácia založená na X.509 certifikátoch (nie heslách)
3. Minimálne oprávnenia — zariadenia môžu komunikovať iba so svojím kontrolérom, nie navzájom
4. Šifrovaná east-west komunikácia — medzi-zariadenová komunikácia šifrovaná aj v rámci OT siete
5. Kontinuálny monitoring — detekcia anomálií na dopravných vzorcoch (nie inšpekcia payloadu, ktorá narúša real-time)
6. Žiadna implicitná dôvera — zariadenie autentifikované pred 5 minútami sa musí znova autentifikovať, ak sa zmení jeho správanie

Best Practice 6: Fyzická bezpečnosť (Zabudnutá vrstva)

Väčšina sprievodcov IoT bezpečnosťou končí pri sieti. Ale priemyselné zariadenia sú nasadené na fyzicky prístupných miestach — výrobné haly, technické skrine, vonkajšie inštalácie.

Povrch fyzického útoku

Vektor útoku	Riziko	Mitigácia
Debug porty (JTAG/SWD)	Kompletná extrakcia firmvéru, dump kľúčov	Fúzová deaktivácia, pokrytie epoxidom v produkcii
Čítanie flash	Reverzné inžinierstvo firmvéru	Flash read protection bity + šifrovaný firmvér
Sniffovanie zbernice (I2C/SPI na secure element)	Extrakcia kľúčov počas prevádzky	Šifrovaná komunikácia zbernice alebo on-die integrácia
Postranný kanál (analýza napájania, EM vyžarovanie)	Extrakcia kľúčov z krypto operácií	Konštantno-časové krypto, hardvérové protiopatrenia
Fault injection (voltage glitching, laser)	Obídenie secure boot, preskočenie autentifikácie	Redundantné kontroly, glitch detektory, SE s FI ochranou
Výmena zariadenia	Podstrčenie kompromitovaného zariadenia	Atestácia zariadení + fleet management

Bezpečnostné opatrenia na úrovni PCB

Pre vysoko bezpečné priemyselné návrhy zvážte:

• Tamper-evident kryty — fyzické pečate ukazujúce, či bolo zariadenie otvorené
• Tamper-responsive — aktívna sieť nad citlivými komponentmi, vymaže kľúče pri narušení
• Konfórny náter — chráni PCB stopy pred sondovaním
• BGA puzdra — ball grid array komponenty sa ťažšie sondujú ako QFP
• Zalievacia hmota — zapuzdrite bezpečnostne kritické komponenty do epoxidu

Regulačná zhoda EÚ

EU Cyber Resilience Act (CRA) — Hardvérové požiadavky

CRA (účinný od 2027) ukladá výrobcom hardvéru špecifické povinnosti:

CRA Požiadavka	Hardvérová implementácia
Bezpečnosť podľa návrhu	Hardware Root of Trust, secure boot z ROM
Riadenie zraniteľností	OTA aktualizácie, PSIRT proces
SBOM (Software Bill of Materials)	Zahrnutie komponentov firmvéru, verzie bootloadera, krypto knižníc
Žiadne známe zneužiteľné zraniteľnosti pri vydaní	Pred-release bezpečnostné testovanie, penetračné testy
Autentifikované aktualizácie počas celej životnosti	Podpísané OTA, rollback ochrana, A/B partícionovanie
Nahlásenie aktívne zneužívaných zraniteľností do 24h	Plán reakcie na incidenty, monitoring flotily

IEC 62443 — Bezpečnosť priemyselnej automatizácie

Medzinárodný štandard pre priemyselnú kybernetickú bezpečnosť definuje Security Levels (SL):

Level	Význam	Hardvérové požiadavky
SL 1	Ochrana proti náhodnému narušeniu	Ochrana heslom, základné riadenie prístupu
SL 2	Ochrana proti úmyselnému narušeniu s nízkou vybavenosťou	Unikátna identita, podpísaný firmvér, TLS
SL 3	Ochrana proti sofistikovanému útoku so strednou vybavenosťou	Hardware Root of Trust, detekcia manipulácie, mTLS
SL 4	Ochrana proti štátnemu útoku s rozšírenými zdrojmi	Secure element (EAL5+), aktívna odpoveď na manipuláciu, formálna verifikácia

Pre projekty cieliace na IEC 62443 SL 3+ musí byť návrh hardvérovej bezpečnosti zahrnutý od fázy architektúry. Pozrite náš Sprievodca EÚ certifikáciou.

ETSI EN 303 645 — Bezpečnosť spotrebiteľského IoT

Európsky základný štandard pre spotrebiteľské IoT požaduje:

• Žiadne univerzálne predvolené heslá
• Implementovať prostriedky na správu hlásení zraniteľností
• Udržiavať softvér aktuálny
• Bezpečne ukladať citlivé bezpečnostné parametre
• Komunikovať bezpečne
• Minimalizovať exponované útočné plochy

Verifikácia a testovanie bezpečnosti

Pred-produkčný bezpečnostný testovací checklist

□ Penetračné testovanie (extrakcia firmvéru, prístup k debug portu)
□ Fuzzing (parsery protokolov, handler aktualizácie firmvéru)
□ Analýza postranných kanálov (ak sa manipuluje s vysoko hodnotnými kľúčmi)
□ Testovanie obídenia secure boot (glitching, fault injection)
□ Testovanie validácie certifikátov (expirované, revokované, nesprávna CA)
□ Testovanie OTA aktualizácií (rollback, prerušenie, poškodenie)
□ Testovanie bezpečnosti rádia (ak bezdrôtové: BLE, Wi-Fi, LoRaWAN)
□ Testovanie fyzického prístupu (JTAG, čítanie flash, sniffovanie zbernice)
□ Verifikácia zhody (CRA, IEC 62443, ETSI EN 303 645)

Nástroje pre testovanie embedded bezpečnosti

Nástroj	Účel	Cena
Ghidra	Reverzné inžinierstvo firmvéru	Zadarmo (NSA open-source)
Binwalk	Extrakcia a analýza firmvéru	Zadarmo
ChipWhisperer	Analýza postranných kanálov a glitching	300–3 000 €
Logický analyzátor (Saleae)	Sniffovanie zbernicových protokolov	150–1 500 €
JTAG debugger (J-Link)	Testovanie prístupu k debug portu	50–1 000 €
AFL/LibFuzzer	Fuzzing protokolov	Zadarmo
OpenSSL s_client	Testovanie TLS konfigurácie	Zadarmo

Často kladené otázky

Aké je najväčšie bezpečnostné riziko IoT?

Najväčším rizikom je chýbajúci Hardware Root of Trust. Bez neho sa dá firmvér extrahovať a klonovať, šifrovacie kľúče sa dajú prečítať z flash pamäte a secure boot sa dá obísť. Bezpečnosť založená iba na softvéri sa dá vždy prekonať s fyzickým prístupom k zariadeniu. Secure element za 1 € eliminuje najzávažnejšiu kategóriu útokov.

Koľko stojí pridanie IoT bezpečnosti?

Základný bezpečnostný zásobník (secure element + secure boot + šifrované OTA) pridáva 1–5 € na kus v nákladoch na komponenty a 10 000–30 000 € vo vývojovom čase. Porovnajte to s priemernými nákladmi priemyselného narušenia 4,7 milióna €. IoT bezpečnosť nie je nákladové stredisko — je to mitigácia rizika s kvantifikovateľnou návratnosťou.

Dajú sa existujúce IoT zariadenia dodatočne zabezpečiť?

Čiastočne. K nasadeným zariadeniam sa dajú pridať opatrenia na úrovni siete (segmentácia, monitoring, VPN). Ale bezpečnosť na úrovni zariadenia (secure boot, Hardware Root of Trust) nie je možné pridať po výrobe — musí byť navrhnutá od začiatku. Preto sa rozhodnutia o bezpečnostnej architektúre musia robiť na začiatku V-Model vývojového procesu, nie na konci.

Aký je rozdiel medzi IT bezpečnosťou a OT bezpečnosťou?

IT bezpečnosť uprednostňuje dôvernosť (ochrana dát). OT bezpečnosť uprednostňuje dostupnosť a bezpečnosť (udržanie systémov v prevádzke a ľudí v bezpečí). V OT môže bezpečnostná záplata spôsobujúca 5 minút neplánovaného výpadku stáť viac než zraniteľnosť, ktorú opravuje. Preto OT bezpečnosť vyžaduje starostlivé riadenie zmien, otestované záplaty a často hardvérové riešenia, ktoré nevyžadujú reštart.

Ako sa líši IEC 62443 od EU CRA?

IEC 62443 je dobrovoľný medzinárodný štandard pre bezpečnosť priemyselnej automatizácie, široko adoptovaný vo výrobe. EU CRA je povinná regulácia pre všetky produkty s digitálnymi prvkami predávané v EÚ. Dopĺňajú sa: IEC 62443 poskytuje detailné technické implementačné pokyny; CRA poskytuje právnu povinnosť implementovať bezpečnosť. Produkty certifikované podľa IEC 62443 SL 2+ pravdepodobne splnia väčšinu požiadaviek CRA.

Potrebujú FPGA inú bezpečnosť ako MCU?

Áno. FPGA majú unikátne útočné plochy, pretože celá hardvérová konfigurácia (bitstream) sa načítava pri zapnutí. Kľúčové rozdiely: 1) bitstream musí byť šifrovaný (AES-256) a autentifikovaný (RSA/ECDSA), 2) konfiguračné kľúče uložené v eFUSE alebo batériou zálohovanej RAM, 3) aj čiastočná rekonfigurácia musí byť autentifikovaná a 4) samotná FPGA štruktúra môže implementovať bezpečnostné funkcie (hardvérové krypto, PUF), ktoré MCU nedokážu. Pozrite naše FPGA bezpečnostné design služby.

Ako Inovasense zabezpečuje priemyselné IoT

Bezpečnosť je zabudovaná do každého projektu, ktorý dodávame, nie pripojená na konci:

• Bezpečnostná architektúra — threat modeling, výber secure elementov, návrh správy kľúčov
• Implementácia secure boot — od boot ROM cez aplikáciu na platformách ARM, RISC-V a FPGA
• Bezpečnosť firmvéru — podpísané OTA aktualizácie, A/B partícionovanie, rollback ochrana
• Návrh hardvéru — PCB layouty odolné voči manipulácii, ochrana debug portov, konfórny náter
• Bezpečnosť FPGA — šifrovanie bitstreamu, hardvérové krypto enginy, PUF integrácia
• Zhoda — CRA pripravenosť, IEC 62443, CE certifikácia
• Testovanie — penetračné testovanie, analýza postranných kanálov, bezpečnostný audit

Kontaktujte nás na diskusiu o vašich požiadavkách na IoT bezpečnosť — či už pre nový návrh produktu alebo hardening existujúceho.