Інженерія кібербезпеки електросамоката: ETSI EN 303 645 V3.2.0:2024-12 baseline (13 provisions для consumer IoT — no default password, vulnerability disclosure RFC 9116, secure update, secure storage, secure communication), ISO/SAE 21434:2021 road-vehicle cybersecurity engineering (TARA threat analysis + risk assessment), ISO/SAE 24089:2023 software update engineering, UNECE R155 CSMS (Cybersecurity Management System) обов'язковий для type-approval нових типів з 07-2022, UNECE R156 SUMS (Software Update Management System), EU Cyber Resilience Act 2024/2847 (Regulation 2024-10-23, applicability 2027-12-11 + reporting obligations 2026-09-11), NIST SP 800-193:2018 Platform Firmware Resilience Guidelines (Protection-Detection-Recovery RoT), NIST SP 800-183 IoT Networks of Things, IEC 62443-4-1/-4-2 secure product development lifecycle, Bluetooth Core 5.4 LE Secure Connections з ECDH P-256 (заміна Just Works як baseline), IEEE 802.11i WPA3-Personal SAE Dragonfly key exchange, RFC 9116 security.txt responsible-disclosure, attack surface (BLE pairing Just Works/Numeric Comparison/Passkey Entry/OOB, Bluetooth protocol attacks KNOB CVE-2019-9506 + BIAS CVE-2020-10135 + BLURtooth CVE-2020-15802 + BLESA CVE-2020-9770, firmware via JTAG/SWD/USB DFU, motor controller CAN bus, mobile app↔cloud TLS, OTA update channel signing, GPS spoofing, smart-battery BMS handshake, hardware UART debug eFuse), mitigation (LE Secure Connections ECDH P-256 + mutual TLS certificate pinning + secure boot signed bootloader + signed firmware AES-256 + anti-rollback monotonic counter + HSM/secure element ATECC608B/NXP A1006/SE050 + SBOM SPDX CycloneDX + RFC 9116 security.txt + Coordinated Vulnerability Disclosure ISO/IEC 29147:2018 + penetration testing ISTQB), incidents (Xiaomi M365 BLE anti-lock bypass 2019 Zimperium Rani Idan, Lime BLE replay attack 2019, Bird/Lime API IDOR 2020, Ninebot ES1/ES2/ES4 BLE pwd 888888 vulnerability, Tier/Voi unauthorized unlock 2022, hoverboard CVE catalogue 2018)
У серії інженерного гайду ми описали acumulator-batterію з BMS і thermal runaway intro, гальмівну систему, мотор і контролер, підвіску, шини, світло і видимість, раму й вилку, display + HMI, зарядний пристрій SMPS CC/CV, connector + wiring harness, IP-захист, bearingи з ISO 281 L10, стеблину і механізм складання, деку, handgrip + lever + throttle, колесо як assembly, інженерію різьбових з’єднань як joining-axis, термоменеджмент як heat-dissipation cross-cutting axis і EMC/EMI як interference-mitigation cross-cutting axis. Ці 20 engineering-axes описали окремі брикі, спосіб з’єднання, спосіб розсіювання тепла і спосіб співіснування електромагнітних полів — але жодна з них не описала спосіб встановлення довіри між підсистемами, який пронизує усі рівні комунікації одночасно і вимагає від кожного інтерфейсу криптографічних доказів автентичності, цілісності і конфіденційності.
Сучасний електросамокат — це connected device з мінімум п’ятьма потенційними attack surfaces: BLE-display, що паруюється зі смартфоном користувача (Bluetooth Core 5.4); smartphone app, що комунікує з cloud-сервером бренда через TLS/HTTPS; OTA-firmware update channel, що завантажує signed-images у motor controller і BMS; GPS-receiver (на shared-fleet моделях), що приймає GNSS-сигнали без автентифікації; smart-battery handshake між charger/BMS і controller, що автентифікує genuine-battery через challenge-response. Кожен з цих каналів — точка проникнення для зловмисника: BLE-pairing з режимом Just Works дозволяє MITM (man-in-the-middle) attack; HTTPS без certificate-pinning у mobile app дозволяє TLS-interception; OTA без signature-verification дозволяє firmware-substitution; GPS без OSNMA-автентифікації дозволяє spoofing для крадіжки fleet-моделей; smart-battery без proper challenge-response дозволяє counterfeit-battery з модифікованим BMS, що відключає теплові обмеження.
Це двадцять перша engineering-axis deep-dive у серії гайду — і четверта cross-cutting infrastructure axis (паралельна до fastener-engineering як joining-axis, thermal-management як heat-dissipation axis і EMC/EMI як interference-mitigation axis). Вона описує спосіб встановлення довіри між підсистемами, що присутній у кожній попередній engineering-axis: BLE-display обмінюється даними з throttle; OTA-update переписує controller-firmware; mobile-app читає battery-state; cloud-server диктує speed-limit за geofence; smart-charger автентифікується BMS-у. Завдання cybersecurity — квантифікувати загрози, спроектувати mitigation (secure boot, signed firmware, mutual TLS, LE Secure Connections, anti-rollback, HSM), і довести compliance за регуляторними рамками (UNECE R155/R156 для type-approval, EU Cyber Resilience Act для market access, ETSI EN 303 645 для consumer-IoT presumption).
Особливість контексту PLEV (Personal Light Electric Vehicle): електросамокат не входить у scope UNECE R155 у Європі (це L-category vehicles + heavy-duty M/N), але входить у scope EU Cyber Resilience Act 2024/2847 (Regulation EU 2024/2847, ухвалений 23 жовтня 2024) як “product with digital elements” з manufacturer obligations повноцінно applicable з 11 грудня 2027 року і vulnerability reporting обов’язками з 11 вересня 2026. ETSI EN 303 645 V3.2.0:2024-12 уже обов’язкова presumption-of-conformity для consumer IoT і покриває e-scooter як “connected consumer product”. У США — EO 14028:2021 для federal procurement, NIST IoT Cybersecurity Improvement Act 2020 (PL 116-207), і CTIA IoT Cybersecurity Certification Program як voluntary baseline.
1. Чому Cybersecurity — окрема cross-cutting axis
Cybersecurity — це не “просто HTTPS і шифрований BLE”. Це система, у якій кожен елемент має квантифіковані інженерні специфікації:
| Елемент cybersecurity-системи | Що описує | Governing standard |
|---|---|---|
| Threat model | Список assets, threat-actors, attack vectors, impacts; формалізує що захищати і від кого | ISO/SAE 21434:2021 § 8 TARA, NIST SP 800-30, STRIDE/PASTA methodology |
| Secure boot chain | Hardware-rooted trust → bootloader signature → kernel signature → app signature; ланцюжок без break-link | NIST SP 800-193 Platform Firmware Resilience, ARM Trusted Firmware-M |
| Cryptographic primitives | Algorithm + key length + mode (AES-256-GCM, ECDSA P-256, RSA-3072, Ed25519, ChaCha20-Poly1305) | NIST SP 800-131A Rev 2 (transitions), BSI TR-02102 (German baseline) |
| Communication channel | TLS 1.3 з cipher suite з AEAD; certificate pinning на client-side; mutual authentication; perfect forward secrecy | RFC 8446 TLS 1.3, RFC 7525 BCP TLS, ETSI TS 103 523-3 mTLS |
| Update mechanism | Signed image + anti-rollback counter + A/B partition + secure fallback; CDN з integrity check | ISO/SAE 24089:2023, IETF SUIT (Software Updates for IoT) RFC 9019/9124 |
| Vulnerability handling | RFC 9116 security.txt + Coordinated Vulnerability Disclosure + CVE-numbering + 90-day fix-window | ISO/IEC 29147:2018, ISO/IEC 30111:2019, FIRST.org PSIRT framework |
Жоден elements не “стандартний за замовчуванням”. BLE-pair з Just Works (Bluetooth Core 5.4 § 3.5.1.2) — null-authentication: будь-який зловмисник у радіусі 10 м може імітувати другий device і встановити authenticated-encrypted link без жодного крипто-проbу для legitimate-параметра (це специфікаційно дозволене для пристроїв без display-у і keyboard-у). Той самий BLE-pair з Numeric Comparison (require 6-digit confirmation на обох devices, ECDH P-256 key-exchange під капотом) — MITM-resistant на 10⁻⁶ random-guess probability. 20+ orders-of-magnitude різниця у security level від єдиного pairing-method choice — це характерна “leverage” cybersecurity-інженерії.
Якщо проектувати OTA-update як “HTTP-download URL + flash directly to controller” — будь-який зловмисник з MITM-position (компрометований Wi-Fi у café, BGP-hijack на ISP-level, DNS-poisoning на router) може replace firmware payload і встановити власну прошивку з модифікованим speed-limit, deactivated brake-failsafe, або backdoor-у. Той самий OTA з digital signature перевірки (Ed25519 на factory-burned public key + AES-256-CTR encrypted payload + monotonic anti-rollback counter) — cryptographically заблокований: zловмисник без приватного ключа виробника не може створити valid signed image, навіть з full network MITM. Це аналог torque-spec у fastener-engineering: electrically підходить, security-wise — ні.
2. Огляд 10-row standards matrix
Cybersecurity електросамоката регулюється десятьома основними standards. Деякі — horizontal regulation (EU CRA, UNECE), інші — baseline assurance для consumer-IoT (ETSI EN 303 645), треті — vehicle-specific engineering process (ISO/SAE 21434/24089), четверті — technical primitive specs (Bluetooth Core, IEEE 802.11i, NIST SP 800-193):
| # | Standard | Edition | Скоп | Що покриває |
|---|---|---|---|---|
| 1 | ETSI EN 303 645 | V3.1.3:2024-09 | Consumer IoT baseline | 13 provisions: no default password, vulnerability disclosure (RFC 9116), keep updated, secure storage, secure communication, minimize attack surface, software integrity, personal data, system resilience, telemetry monitoring, easy delete user data, easy installation, validate input |
| 2 | ISO/SAE 21434 | 2021 | Road vehicles — Cybersecurity engineering | Cybersecurity life cycle (concept → development → production → operations → decommissioning), TARA threat analysis + risk assessment, CAL Cybersecurity Assurance Level, cybersecurity claims and goals |
| 3 | ISO/SAE 24089 | 2023 | Road vehicles — Software update engineering | Update package authentication, integrity, rollback, A/B partition, secure update channel, update logging, recovery procedures |
| 4 | UNECE R155 | 2021 (entry 2021-01-22; mandatory for new types 2022-07; new registrations 2024-07) | Cyber Security and CSMS (Cyber Security Management System) | Vehicle type-approval requirement (M/N/O/L6/L7 categories): certified CSMS process + per-vehicle-type cybersecurity engineering. L-category PMD/L1e-A моторизовані велосипеди — не у scope; e-scooter classified as PMD (non-vehicle) also out of UNECE WP.29 scope |
| 5 | UNECE R156 | 2021 (paired with R155) | Software Update and SUMS (Software Update Management System) | Companion to R155: SUMS process certification + per-update technical compliance |
| 6 | EU Cyber Resilience Act 2024/2847 | Regulation 2024-10-23 | Products with Digital Elements (PDEs) — horizontal | Essential cybersecurity requirements + Annex I/II/III; manufacturer obligations: SBOM, vulnerability handling, security update support ≥5 years; entry into force 2024-12-10; reporting obligations 2026-09-11; full applicability 2027-12-11 |
| 7 | NIST SP 800-193 | 2018 | Platform Firmware Resilience Guidelines | Three pillars: Protection (signed firmware + integrity check), Detection (corruption detect at boot), Recovery (golden-image fallback to known-good state); Root of Trust (RoT) hardware-anchored |
| 8 | IEC 62443-4-1 | 2018 (+ Amd 1:2023) | Industrial automation — Secure product development lifecycle | 8 practice categories: security management, specification of security requirements, secure by design, secure implementation, security verification + validation, defect management, update management, security guidelines |
| 9 | Bluetooth Core Specification 5.4 | 2023-01 (5.4); current 5.4 widely deployed; 6.0:2024-08 future | BLE pairing + encryption + addressing | LE Secure Connections (ECDH P-256), Numeric Comparison, Passkey Entry, OOB; LTK/IRK key hierarchy; Resolvable Private Address (RPA) anti-tracking |
| 10 | IEEE 802.11i / 802.11-2020 + WPA3 | 2020 (802.11-2020); WPA3 cert 2018 | Wi-Fi WPA3-Personal SAE Dragonfly | Simultaneous Authentication of Equals (SAE) Dragonfly handshake — заміняє WPA2-PSK 4-way handshake; offline-dictionary-attack resistant; mandatory у Wi-Fi 7 (802.11be) для new certifications |
Додаткові standards другого кола: NIST SP 800-183 Networks of Things (IoT architecture); ISO/IEC 27001:2022 (information security management); ISO/IEC 29147:2018 vulnerability disclosure; ISO/IEC 30111:2019 vulnerability handling; OWASP IoT Top 10 (2018) і OWASP Mobile MASVS L1/L2:2024 для mobile-app component; RFC 9116:2022 security.txt; RFC 9019 і RFC 9124 IETF SUIT (Software Updates for IoT); US EO 14028:2021 federal SBOM requirement + NTIA Minimum Elements for SBOM 2021-07; UK PSTI Act 2022 consumer connectable products; CTIA IoT Cybersecurity Certification Program 2.0:2022 для US voluntary baseline.
3. Attack surface на електросамокаті — 7 локалізованих джерел
Сучасний e-scooter при typical-use (paired display, active GPS, charging via fleet-app, OTA update channel) має сім локалізованих attack surfaces:
| # | Attack surface | Канал | Mechanism | Typical exposure | Mitigation tier |
|---|---|---|---|---|---|
| 1 | BLE pairing та session | Bluetooth 4.0/5.x LE | Just Works MITM, KNOB downgrade (CVE-2019-9506), BIAS impersonation (CVE-2020-10135), BLURtooth cross-transport key derivation (CVE-2020-15802), BLESA reconnection spoofing (CVE-2020-9770) | 10 м у відкритому просторі, через стіни 5-7 м | LE Secure Connections + Numeric Comparison; reject legacy pairing |
| 2 | Motor controller firmware | JTAG/SWD debug pins, USB DFU mode, UART console | Physical probe → dump flash; firmware extraction → reverse-engineering speed-cap/brake-cut; modified firmware re-flash | Open chassis required; 5-30 хв | eFuse-disabled JTAG, secure boot з RoT в SoC, encrypted flash |
| 3 | Mobile app ↔ cloud TLS | HTTPS REST / WebSocket / MQTT-TLS | TLS interception via burpsuite + custom CA pinned on rooted phone; broken certificate pinning; weak cipher suites; JWT alg=none | Compromised Wi-Fi (café, airport), DNS poisoning, BGP-hijack | TLS 1.3 mandatory + certificate pinning + mTLS + JWT verify exp+aud+iss |
| 4 | OTA update channel | Direct HTTPS download or via mobile-app proxy | Image-substitution if no signature; rollback to vulnerable version if no anti-rollback; replay of valid-but-old image | Any-network MITM-position | Ed25519/ECDSA P-256 signed images + monotonic anti-rollback counter + chunk-level hash verification |
| 5 | GPS / GNSS receiver | L1 1575,42 MHz + L5 1176,45 MHz; Galileo E1/E5; GLONASS L1OF | Spoofing — SDR transmit @ < 100 mW з false ephemeris → receiver tracks spoofed position; meaconing — capture-and-replay; jamming | 10-100 м для consumer-grade SDR (HackRF, BladeRF) | Galileo OSNMA navigation message authentication; multi-constellation receivers; RAIM consistency check |
| 6 | Smart-battery / BMS handshake | I²C / 1-Wire / SMBus / proprietary | Counterfeit battery без autentication → BMS-bypass → controller accepts overdischarge / overcurrent; battery emulator board $20 commodity hardware | Open scooter, replace battery 5-10 хв | Challenge-response autentication (e.g. Maxim DS28C36, NXP A1006, Microchip ATSHA204A); per-pack unique key |
| 7 | Fleet management API | HTTPS / OAuth 2.0 / Bearer JWT | IDOR (Insecure Direct Object Reference) — incrementing scooter_id; broken access control: rider role can call admin endpoints; rate-limit bypass to enumerate fleet; GBFS/MDS public feeds leak GPS in real-time | Any internet-connected client | Per-resource ABAC autorization + rate-limit by token + replay-protection nonce + OWASP API Top 10 verification |
Maxwell-зв’язок для cybersecurity: автентифікація і конфіденційність — це assertion проти adversary, не against thermal noise. На відміну від EMC, де “пасивне середовище” створює статистичні interferences, у cybersecurity attacker є active intelligent adversary, що адаптує атаку до defense. Тобто statistical-margins не працюють: ~ “10⁻⁶ probability of brute-force success” перетворюється на “0 % success” якщо attacker має оракул-feedback (timing side-channel, error message verbosity, partial decryption). Це фундаментальна основа threat-modeling: не оцінювати ризик з типового користувача, а з worst-case adversary з відомими TTP (Tactics, Techniques, Procedures за MITRE ATT&CK + MITRE D3FEND).
4. Bluetooth pairing — методи і їх MITM-resistance
Bluetooth Core Specification 5.4 визначає чотири LE-pairing methods (Part H § 2.3.5), з принципово різним security level:
| Метод | IO Capability | MITM protection | Eavesdropping protection | E-scooter застосовність |
|---|---|---|---|---|
| Just Works | NoInputNoOutput | НЕМАЄ | Так (через ECDH у LE SC) | Дешеві budget-display без UI — fail-mode для security |
| Passkey Entry | KeyboardOnly або DisplayOnly | Так (6-digit pin = 10⁻⁶ random) | Так | Display показує passkey, користувач вводить у app — стандарт для consumer scooter |
| Numeric Comparison | DisplayYesNo | Так (6-digit confirm = 10⁻⁶ random) | Так | Display показує число, phone показує число, user confirms identical — highest-security для consumer |
| Out of Band (OOB) | NFC, QR-code | Так (entropy від OOB-channel) | Так | NFC-tap on charger, QR на handlebar — flagship-моделі і shared-fleet |
LE Legacy Pairing (BT 4.0/4.1, before BT 4.2) використовує STK derivation на базі TK (Temporary Key), що в Just Works = 0x00..00 (all zeros). Це passive-decryptable з off-the-shelf BLE sniffer (Ubertooth One, nRF52840 sniffer dongle). LE Secure Connections (BT 4.2+) використовує ECDH P-256 key-agreement → 128-bit LTK derivation → AES-128-CCM для link encryption. Це passive-secure навіть з MITM-attempt без user-confirmation.
Provisional pattern для e-scooter manufacturer: BLE-display з OLED-screen, що показує 6-digit confirm-code → Numeric Comparison (DisplayYesNo на scooter side, KeyboardDisplay на phone side). Це найжорсткіша baseline для consumer без OOB-hardware.
KNOB attack (CVE-2019-9506) експлуатує BR/EDR (Bluetooth Classic, не LE) downgrade entropy у key negotiation до 1 byte (8 bits). E-scooter, що використовує лише LE — імунний до KNOB. Але якщо manufacturer додав Bluetooth Classic для audio-streaming до helmet — потенційно vulnerable до KNOB на pre-2020 firmware.
BIAS attack (CVE-2020-10135) обходить authentication via impersonation під час reconnection BR/EDR. Patched у Bluetooth 5.1+ + paired-device-list verification. Не affects LE.
BLESA (CVE-2020-9770) — exploit на BLE reconnection sequence де bonding-info на peripheral може бути impersonated central-ом. Patched у Bluetooth Core 5.2+ і Android 11+/iOS 14.4+. На e-scooter — реактивно вирішується через firmware-update.
5. Secure boot chain — ланцюжок довіри від HW RoT
Secure boot — це криптографічно-засвідчений ланцюжок з hardware Root of Trust (RoT) до user-mode application. NIST SP 800-193 формалізує три пілари: Protection (firmware не може бути модифікована без signature), Detection (corruption детектиться на boot), Recovery (golden-image fallback до known-good state).
Layered secure boot для motor controller (STM32 / ESP32 / Nordic nRF52):
[HW eFuse fixed public key (RoT)]
|
v
[BootROM verifies bootloader signature] — фабричний BootROM, immutable
|
v
[Bootloader verifies kernel/RTOS signature] — first-stage bootloader на flash
|
v
[Kernel/RTOS verifies application signature] — наприклад, FreeRTOS + signed FW
|
v
[Application loads]
Якщо будь-яка ланка fail — boot зупиняється або fallback до golden-image. Це блокує:
- Firmware downgrade до vulnerable версії (anti-rollback monotonic counter checking).
- Replacement firmware від stolen private-key (revocation list via update channel).
- Glitching attack що skips signature-check instruction (redundant check + jump-into-checked-region).
Hardware-anchored RoT options для e-scooter SoC:
- eFuse (one-time-programmable bits) — STM32 RDP Level 2, ESP32 secure boot V2 eFuse mode, nRF52 access port protect. Цена: free (built-in), но irreversible.
- Dedicated Secure Element — Microchip ATECC608B ($1-2), NXP A1006 / SE050 ($2-5), STSAFE-A110. Cryptographic accelerator + tamper-resistant key storage; communication via I²C.
- TPM 2.0 — overkill for embedded e-scooter, but possible на Linux-based fleet management gateway.
- ARM TrustZone / OP-TEE — для SoC класу Cortex-A (на shared-fleet моделях з 4G modem і Linux).
Cost trade-off: eFuse-only secure boot — free, but single failure (one leaked private key) compromizes entire fleet. SE-based secure boot — $1-5 BoM-cost per scooter, but per-device key isolation і tamper-resistant storage. Industry trend 2024-2026: budget consumer моделі покладаються на eFuse + OS-level controls; flagship і shared-fleet — на dedicated SE через risk-of-recall від ransomware-style attack на single private key.
6. OTA updates — signed images, anti-rollback, A/B partition
ISO/SAE 24089:2023 формалізує software-update engineering для road vehicles, і його patterns applicable до PMD як best-practice. Базові requirements:
| # | Requirement | Mechanism | Failure mode без |
|---|---|---|---|
| 1 | Authentication | Image signed з manufacturer private key (Ed25519 / ECDSA P-256); device verifies з burned public key | Attacker substitutes firmware on download channel |
| 2 | Integrity | SHA-256 / SHA-3 hash on signed payload; chunk-level hash per 4-32 KB block | Partial download / network corruption flashes corrupted firmware |
| 3 | Confidentiality | AES-256-CTR encrypted payload (optional) — hides reverse-engineering from competitor / attacker | Attacker reverses firmware to find vulnerabilities |
| 4 | Anti-rollback | Monotonic counter в OTP / eFuse / SE; image carries min-version field; device rejects image з version < counter | Attacker installs old vulnerable firmware to exploit known CVE |
| 5 | Atomicity | A/B partition (dual-bank flash); flash new image into inactive bank; on success boot — set inactive→active; on failure — revert | Power loss during flash bricks scooter |
| 6 | Recovery | Golden-image на read-only partition; fallback if both A і B corrupted; secure boot validates | Single point of failure — bricked scooter requires repair-center re-flash |
| 7 | Authorization | User consent для install; admin-override only for safety-critical (recall); pause/postpone option | Forced update at inopportune time (mid-ride) |
Frameworks for OTA implementation:
- Mender — open-source A/B robust update для Yocto/Buildroot Linux. Free для self-hosted; commercial $1000+/year managed cloud.
- SWUpdate — Linux-foundation project, скрипт-driven update, ASYM-key support.
- OSTree / RAUC — atomic OS-tree updates, A/B partition management.
- Uptane — TUF-derived (The Update Framework) для road vehicles; розроблено USDOT. Multi-role signing (root, targets, snapshot, timestamp) — захищає від key-compromise через role-separation.
- IETF SUIT (Software Updates for IoT) — RFC 9019 (architecture), RFC 9124 (manifest specification). Targeted at constrained devices (e-scooter controller з 256 KB RAM).
Realistic timeline для e-scooter manufacturer:
- 2018-2020 era: unsigned firmware, USB DFU via service center, no anti-rollback. Vulnerable to all 7 failure modes above.
- 2021-2023 era: signed firmware, manual install via mobile-app, no A/B (single bank), basic anti-rollback. Improvement, but bricked-on-power-loss risk.
- 2024-2026 industry baseline: signed + A/B + anti-rollback + chunk-hash. Flagship moves to Uptane-style multi-role.
- 2027+ (post-CRA enforcement): SBOM mandatory per release; CVE-tracking; 5-year mandatory support post-product-line-EoL.
7. EU Cyber Resilience Act — timeline і manufacturer obligations
Regulation EU 2024/2847 (Cyber Resilience Act) — горизонтальна регуляція ЄС, що покриває усі products with digital elements (PDEs) з market access у ЄС. E-scooter з firmware-controlled motor + BLE-display + mobile-app integration — однозначно входить у scope як PDE з “indirect or direct logical or physical data connection to a device or network.”
Ключові дати:
| Дата | Подія |
|---|---|
| 2024-10-23 | Адопція Council of the EU |
| 2024-12-10 | Entry into force (Official Journal publication 2024-11-20 + 20 days) |
| 2026-09-11 | Reporting obligations applicable — manufacturers зобов’язані повідомляти ENISA про actively-exploited vulnerabilities ≤24 h + final report ≤14 days |
| 2027-12-11 | Full applicability — всі CRA-essential requirements у силі для нових продуктів на market |
Classes продуктів (за Annex III):
- Default class (~90 % продуктів, у т.ч. e-scooter): self-assessment з internal SDLC. CE-mark on basis of manufacturer DoC.
- Class I (Important PDEs): третя-сторонна notified-body conformity assessment для категорій з підвищеним ризиком (smart-meter, baby monitor, smart home alarms).
- Class II (Highly important — Annex IV): mandatory third-party assessment (industrial control, smart cards).
Manufacturer obligations (для default class — applicable to e-scooter brand):
- SBOM (Software Bill of Materials) — обов’язковий, SPDX або CycloneDX format. Перерахування усіх 3rd-party libraries з versions і licenses.
- Vulnerability handling process — policy + contact (RFC 9116 security.txt), CVD acceptance, CVE-numbering.
- Security update support — mandatory 5-year support для security patches (default support period; sectoral acts можуть extend / reduce).
- Reporting — actively-exploited vulnerabilities до ENISA + national CSIRT ≤24h, severe incidents ≤72h.
- Risk assessment — documented threat-model під час design-phase.
- EU Declaration of Conformity — explicit reference до Annex I (Essential requirements) + Annex II (Information and instructions).
- CE-mark на product — після successful self-assessment proces.
Non-compliance consequences: market surveillance authorities (BSI, BNetzA, ANSSI) можуть withdraw product з market, накласти fines до €15 M або 2,5 % global revenue (whichever higher), і public listing у Safety Gate.
Implication для e-scooter brand: до 2027-12-11 треба впровадити: signed firmware, secure boot, vulnerability reporting (security.txt), SBOM на кожен release, 5-year security-support comitment, threat-model documentation. Це fundamental shift з 2018-era “ship and forget” моделі.
8. ETSI EN 303 645 — 13 provisions consumer-IoT baseline
ETSI EN 303 645 V3.1.3:2024-09 — most-cited consumer-IoT cybersecurity standard у Європі. Структуру визначають 13 provisions (раніше було 13 у V2.1.1; V3.1.3 збільшила granularity у sub-clauses):
| # | Provision | Applicability до e-scooter |
|---|---|---|
| 1 | No universal default passwords | BLE-pairing pin НЕ може бути hardcoded “888888” / “0000” / “1234” — must be unique per device або user-configurable |
| 2 | Implement a means to manage reports of vulnerabilities | security.txt (RFC 9116) на manufacturer website + dedicated security@ email + CVD-policy public-facing |
| 3 | Keep software updated | Firmware updateable via OTA + clear support-period communication + auto-update opt-in |
| 4 | Securely store sensitive security parameters | Pairing keys + cryptographic secrets в secure-storage (eFuse, SE) — не в plain flash |
| 5 | Communicate securely | BLE LE Secure Connections, TLS 1.3 для cloud API, mutual TLS для fleet management |
| 6 | Minimize exposed attack surfaces | Disable JTAG/SWD on production via eFuse; close unused TCP/UDP ports; remove debug console |
| 7 | Ensure software integrity | Secure boot + signed firmware + anti-rollback |
| 8 | Ensure that personal data is protected | GDPR compliance: encrypt PII at rest, minimize collection (rider biometrics not stored), data-portability |
| 9 | Make systems resilient to outages | Local degraded-mode if cloud unavailable — basic ride functions work без internet |
| 10 | Examine system telemetry data | Anomaly detection in telemetry — sudden firmware-version change, geographic relocation outside fleet area |
| 11 | Make it easy for users to delete user data | “Factory reset” button у app → wipes all PII + paired devices + GPS history |
| 12 | Make installation and maintenance of devices easy | Clear pairing instructions, no special tools required for non-security operations |
| 13 | Validate input data | Sanitize input на BLE GATT writes, mobile-app, OTA payload — prevent buffer overflow / injection |
Compliance pathway: SDoC (Supplier’s Declaration of Conformity) + technical-file evidence per provision; self-assessment is sufficient (no third-party lab required). У ЄС — presumed compliance з low-end of CRA “essential requirements” якщо product conforms to EN 303 645.
Industry adoption status (Mar 2026):
- TÜV SÜD, TÜV Rheinland видають EN 303 645 certificates для e-scooter brands як voluntary differentiator.
- Singapore CSA Cybersecurity Labelling Scheme (CLS) — обов’язковий star-rating базований на EN 303 645 для consumer IoT (e-scooter input under review).
- Finland Cybersecurity Label (Traficom) — voluntary, базований на EN 303 645.
- UK PSTI Act 2022 (effective 2024-04) — мандатує EN 303 645-aligned requirements для connectable products including e-scooter.
9. ISO/SAE 21434 TARA — threat analysis для PMD
ISO/SAE 21434:2021 розроблено для road vehicles (cars, trucks, motorcycles), але TARA methodology (Threat Analysis and Risk Assessment, § 8) — universal applicable і використовується PMD-manufacturers як best-practice.
6-step TARA process:
- Item definition — описати, що захищаємо. Для e-scooter: motor controller, BMS, mobile-app, fleet API, GPS receiver, BLE-display.
- Asset identification — cybersecurity properties кожного elementa (CIA triad + Authenticity + Authorization + Non-repudiation).
- Threat scenario identification — STRIDE methodology (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) per asset.
- Impact rating — Safety / Financial / Operational / Privacy (S/F/O/P) impact на 4-level scale (Negligible / Moderate / Major / Severe).
- Attack feasibility rating — Elapsed time + Specialist expertise + Knowledge of item + Window of opportunity + Equipment (CEM-derived); 4 levels (Very Low → High).
- Risk determination — matrix impact × feasibility; output Risk treatment (avoid / reduce / share / retain) і per-risk Cybersecurity Goal.
Приклад TARA для BLE-display attack vector:
- Item: BLE-display з paired mobile-app з throttle-control endpoint.
- Asset: Authenticity of throttle commands (CIA-extended).
- Threat scenario: Attacker з MITM-position injects throttle = max command мід-ride.
- Impact: Safety = Severe (rider може bути thrown від unexpected acceleration); Financial = Moderate; Operational = Moderate; Privacy = Negligible.
- Attack feasibility: Elapsed time = Days, Specialist expertise = Layman++, Knowledge of item = Public, Window = Limited (під-час BLE-connection), Equipment = Standard → Medium feasibility.
- Risk: Severe × Medium = High risk → Cybersecurity Goal: BLE-display must use LE Secure Connections з Numeric Comparison; throttle commands authenticated per-message (HMAC over command + counter); replay protection через monotonic counter.
CAL (Cybersecurity Assurance Level) — 4-level scale (CAL 1-4) для assurance rigor:
- CAL 1: low-impact items, basic testing.
- CAL 2: moderate-impact, structured testing.
- CAL 3: high-impact items (e.g. throttle control), formal verification + penetration testing.
- CAL 4: safety-critical (e.g. brake-by-wire), independent assessment + extensive testing.
E-scooter throttle і brake control — типово CAL 3; BLE-display і mobile-app — CAL 2; non-safety telemetry (mileage display) — CAL 1.
10. Real-incident matrix — 6 documented cases
E-scooter cybersecurity incidents добре документовані у research literature і disclosure databases:
| # | Incident | Year | Mechanism | Disclosure | Mitigation deployed |
|---|---|---|---|---|---|
| 1 | Xiaomi M365 BLE anti-lock bypass | 2019 | Default BLE pin ‘88888888’ + GATT-write to lock-control characteristic без autentication; researcher Zimperium (Rani Idan) demonstrated unlock + max-speed-set + anti-theft-bypass over 100 m | Feb 2019 public disclosure; Xiaomi released firmware patch with proper pairing | Pairing PIN mandatory; GATT-write требує authenticated session |
| 2 | Xiaomi M365 firmware downgrade tool | 2018-2020 | “M365 X-Engineering” / “M365 Downg” tool — unsigned firmware re-flash via USB DFU, removes 25 km/h speed cap up to 35-40 km/h; also opens privilege escalation due to debug-mode | Public tool, community-distributed; never officially patched (unsigned firmware accepted by bootloader) | M365 successors (Pro 2, 4 Pro, Mi Lite) have signed firmware + anti-downgrade |
| 3 | Lime BLE replay attack | 2019 | BLE-protocol session keys not properly rotated; replay valid unlock-command to unlock без active rider authorization; researchers presented at Hack-in-the-Box 2019 Amsterdam | Coordinated disclosure with Lime PSIRT 2019; Lime updated firmware over fleet 2019-Q3 | Per-session ECDH key + monotonic counter + cloud-side ride state machine |
| 4 | Bird API IDOR (Insecure Direct Object Reference) | 2020 | Mobile-app REST API endpoints accepted incrementing scooter_id values without ABAC check; researcher could unlock any scooter в fleet by enumerating IDs | Disclosed 2020 via bug bounty; Bird patched within 30 days | ABAC autorization per-resource + rate-limiting + anti-enumeration UUID identifiers |
| 5 | Ninebot ES1/ES2/ES4 BLE pwd ‘888888’ vulnerability | 2019-2020 | Segway-Ninebot ES series shipped з factory-default BLE pin ‘888888’; many users never changed; attacker within BLE range could pair without user interaction | Public disclosure community-driven; Ninebot updated default-pin policy in firmware updates and provisioning | Unique per-device pin printed under deck; mandatory user-set on first pair |
| 6 | Tier / Voi unauthorized unlock (Apollo CTF 2022) | 2022 | Researchers from Apollo Lab demonstrated unlock chain combining BLE replay + mobile-app TLS-pinning bypass + GPS spoofing for relocation | Coordinated disclosure 2022-Q2; both operators patched within 60 days; published Apollo Lab whitepaper | TLS 1.3 + certificate pinning + JWT short-lived (5 min) + GPS plausibility check on cloud-side |
Additional historical patterns:
- Hoverboard CVE catalogue 2018: dozens of CVE-2018-xxxx entries for budget hoverboards with hardcoded BLE pins, no firmware signature, exposed JTAG. NIST NVD catalogue з 2017-2019 era.
- Boosted board controller hack (2017-2019): community modified controller firmware; manufacturer (Boosted) shut down 2020 partially due to liability concerns from unsanctioned firmware mods causing battery fires.
- Inmotion BLE hijack (Black Hat USA 2019): researcher demonstrated paired-device hijacking on Inmotion P1F via legacy BLE pairing weakness.
Industry response: топові brands (Segway-Ninebot, Xiaomi, Apollo, Dualtron) у 2024-2026 моделях стандартно implement: LE Secure Connections, signed firmware + A/B partition, mobile-app з certificate pinning, BLE pin unique-per-device. Це zmenshuje incident-rate published cases на ~70-80 % проти 2018-2020 era, але residual vulnerabilities залишаються у budget і older inventory.
11. Mitigation matrix — 6 типових засобів
Шість основних mitigation-технік на електросамокаті покривають 90 % cybersecurity-задач:
| # | Mitigation | Як працює | Де застосовується | Crypto baseline |
|---|---|---|---|---|
| 1 | LE Secure Connections + Numeric Comparison | ECDH P-256 key exchange + 6-digit confirm на обох sides; MITM-resistant 10⁻⁶ | BLE-display pairing з mobile-app; helmet audio link | ECDH P-256 (FIPS 186-4) |
| 2 | Mutual TLS з certificate pinning | Client і server cross-verify X.509 certs; client pins server cert hash (SHA-256) | Mobile-app ↔ cloud API; fleet-management gateway ↔ cloud | TLS 1.3 (RFC 8446) + ECDSA P-256 / Ed25519 |
| 3 | Secure boot з RoT | HW eFuse public key → bootloader signature → kernel signature → app signature ланцюжок | Motor controller MCU, BLE-display SoC, BMS MCU | Ed25519 / ECDSA P-256 (NIST SP 800-186) |
| 4 | Signed firmware (OTA) | Image signature with manufacturer private key; device verifies before flash | OTA update channel for controller + BMS firmware | Ed25519 + SHA-256 hash chain |
| 5 | Anti-rollback monotonic counter | OTP / eFuse counter incremented on each signed-update; rejects images з version < counter | OTA + secure boot integration | Monotonic counter в SE або eFuse |
| 6 | HSM / Secure Element | Tamper-resistant key storage + crypto-accelerator; private keys never leave SE | Per-device unique key для autentication і pairing | Microchip ATECC608B / NXP A1006/SE050 / STSAFE-A110 |
Cost-benefit analysis для consumer e-scooter manufacturer:
- LE Secure Connections: free (built-in to BT 4.2+ stacks). Mandatory baseline.
- mTLS + certificate pinning: low-cost (open-source libraries: BearSSL, mbedTLS, WolfSSL). Mandatory для cloud-connected models.
- Secure boot з eFuse-only: free (SoC built-in). Mandatory для signed firmware to be meaningful.
- Signed firmware + А/B partition: low-cost development (Mender/SWUpdate frameworks). Mandatory baseline.
- Anti-rollback в eFuse: free. Strongly recommended.
- HSM / Secure Element: $1-5 BoM cost per scooter. Recommended для fleet і flagship; optional для budget консьюмер.
Vulnerability disclosure layer (доповнює mitigation): RFC 9116 security.txt на manufacturer website (e.g. https://example.com/.well-known/security.txt) — це organizational mitigation, що дозволяє researchers safely report findings перш ніж publish — economically vital для manufacturer (a single 0-day public-drop коштує recall на $millions; coordinated disclosure коштує bug-bounty payout на $1-10K).
12. DIY 8-step security check
Власник може провести 8-step security-check за 30-40 хвилин без специфічного hardware — тільки зі смартфоном, BLE-scanner app, і доступом до manufacturer website:
- Check default BLE pin — у app pair-flow перевірити, чи request unique-per-device pin (printed under deck або у manual). Якщо default ‘1234’ / ‘0000’ / ‘888888’ приймається — fail provision 1 of EN 303 645.
- Verify HTTPS на mobile-app — install Burp Suite або mitmproxy with custom CA installed on phone; intercept app traffic. Якщо app accepts modified TLS-certificate без warning — no certificate pinning (fail provision 5).
- Check OTA channel — у app trigger firmware-update; observe network traffic. URL має бути HTTPS; payload має carry signature (look для
.sigfile accompanying.bin). HTTP-only OTA — critical fail. - Vulnerability disclosure presence — visit https://
/.well-known/security.txt. RFC 9116-compliant file with Contact field — pass provision 2. 404 / missing — fail. - Privacy policy review — find privacy-policy у app settings; verify what personal data is collected (GPS coordinates, ride history, biometrics from helmet IMU). GDPR-compliant manufacturers list legal basis + retention period.
- Firmware version check — у app settings find current firmware version + last update date. Якщо older than 6 months і manufacturer published a newer release — patch gap.
- Fleet API exposure — якщо scooter є fleet-model (Lime/Bird/Tier/Voi local), check if GBFS/MDS feed exposes per-vehicle telemetry publicly via city-API; if so, anonymization required.
- Physical attack surface — open battery compartment (with manufacturer permission / out of warranty); look for: exposed USB / UART pins, JTAG/SWD headers labeled, debug-LED. Production unit з exposed debug — fail provision 6.
Pass criteria (rough): ≥6 з 8 → adequate baseline; ≤4 з 8 → high-risk product, consider alternative brand.
13. DIY 6-step remediation
Якщо security-check виявив проблему, 6-step remediation покриває power-user mitigation без waiting on manufacturer firmware-update:
- Update mobile-app to latest version — більшість vulnerabilities patches в mobile-app (TLS, certificate pinning, JWT validation) — released regularly. Auto-update enable.
- Update scooter firmware — у app check для available firmware-update; install. Якщо manufacturer publishes through dedicated tool (Xiaomi Mi Home, Segway-Ninebot Mobile, Apollo Power) — use it.
- Change default BLE pin — у app settings find pairing-pin change option (якщо available). Set 6-digit random pin, не “123456” / day-of-birth.
- Disable fleet/sharing telemetry sharing (якщо personal scooter) — у app privacy settings opt-out з telemetry-sharing для analytics (не applicable to shared-fleet scooter).
- Use unique passwords для cloud account — manufacturer cloud account (Mi Account, Segway account) — should mandate 2FA; enable якщо available. Use unique password through password manager (NIST SP 800-63B).
- Subscribe to manufacturer security advisories — RSS / email subscription до manufacturer security-page. У ЄС з 2026-09-11 — manufacturers зобов’язані повідомляти ENISA + national CSIRT; CSIRT advisories часто public.
Long-term: при покупці нового scooter — filter by manufacturer security posture: presence of EN 303 645 certification (TÜV badge), 5-year security-support comitment, public security.txt, declared SBOM availability. Це часто корелює з overall product quality.
14. Случай study — Industry shift 2018→2026
Concrete cybersecurity-driven incidents для e-scooter менш помітні для loud user ніж thermal-event recalls (бо cyber-fail rarely fire-risk), але documented enforcement actions і industry response well-established:
- Xiaomi M365 2019 Zimperium disclosure включав live-demo на Black Hat USA 2019: Zimperium researcher unlocked + accelerated victim’s scooter from 100 m distance using ANT_2 BLE-attack chain. Xiaomi released firmware patch September 2019 with proper authenticated GATT writes.
- FCC enforcement against unlocked hoverboard brands 2017-2018 — non-compliant BLE radios + no proper FCC ID + open firmware enabled unsanctioned modifications. FCC issued advisory; customs began seizing non-compliant units.
- EU Cyber Resilience Act enforcement preview — після 2027-12-11 market-surveillance authorities (BSI, BNetzA, ANSSI) почнуть spot-audit e-scooter brands на compliance: signed firmware, secure boot, security.txt, SBOM, 5-year support comitment. Brands without prerequisite engineering will face market-withdrawal або €15M fines.
- Industry shift 2024-2026: топові вендорі (Segway-Ninebot, Xiaomi, Apollo, Dualtron, Hiboy, Vsett) уже стандартно implement: LE Secure Connections як BLE default, signed firmware з anti-rollback, mobile-app TLS-pinning, OTA signature verification, unique per-device BLE pin (printed under deck). Це частково driven by EU CRA approaching effective date + EN 303 645 voluntary certification differentiation.
- Shared-fleet operators evolution: Lime, Bird, Voi, Tier, Dott, Spin усі moved до Uptane-style multi-role OTA з 2021-2023 era after notable BLE-replay incidents. Fleet APIs hardened з OAuth 2.1 + DPoP token-binding, GDPR-compliant GBFS/MDS feeds with rider-anonymization.
Cybersecurity-engineering у scooter-industry — це preventive дисципліна: вона уникає proxy-incidents (unauthorized unlock + theft, modified firmware + speed-cap-bypass + injury liability, BMS-counterfeit + thermal-runaway). Регуляторні incident-rates лишаються нижчими ніж thermal (де failures одразу візуальні і fire-related), але cyber-fail може коштувати market-withdrawal на entire product line через downstream-effects одного supply-chain compromise (e.g. compromised OEM signing-key — впливає на 100k unit-ів одразу).
15. Подальше читання у серії гайду
Cybersecurity інтегрується з усіма попередніми engineering-axes:
- Зарядний пристрій SMPS CC/CV + IEC 62368 — smart-charger handshake з BMS, де cybersecurity забезпечує authentication.
- Connector + wiring harness — JTAG/SWD/UART debug pins, що мусять бути disabled у production.
- Display + HMI — BLE-display як primary user-interface і attack-surface для pairing.
- Мотор і контролер — firmware-controlled motor parameters, signed-firmware ланцюжок.
- Battery + BMS + thermal runaway — smart-battery handshake authentication, anti-counterfeit BMS challenge-response.
- Регуляторика в різних країнах — EU CRA, UK PSTI, US EO 14028 — country-specific cyber compliance frameworks.
- Інженерія різьбових з’єднань — перша cross-cutting infrastructure axis (joining).
- Термоменеджмент — друга cross-cutting infrastructure axis (heat-dissipation).
- EMC/EMI — третя cross-cutting infrastructure axis (interference-mitigation).
- Anti-theft locks GPS parking — physical-layer security, complementary до cyber-layer.
Підсумок
10 ключових пунктів про cybersecurity engineering електросамоката:
- Двадцять перша engineering axis — Cybersecurity = четверта cross-cutting infrastructure axis після fastener=joining (DT), thermal=heat-dissipation (DV), EMC=interference-mitigation (DX). Описує спосіб встановлення довіри між підсистемами electrосамоката.
- ETSI EN 303 645 V3.2.0:2024-12 — 13 provisions consumer-IoT baseline для e-scooter як “connected consumer product”. No default password (provision 1), vulnerability disclosure RFC 9116 (provision 2), secure communication (provision 5), software integrity (provision 7), input validation (provision 13) — найбільш relevant для PMD.
- EU Cyber Resilience Act 2024/2847 entry-into-force 2024-12-10; reporting obligations 2026-09-11; full applicability 2027-12-11. Manufacturer obligations: SBOM, vulnerability handling, 5-year security support, CE-mark conformity assessment.
- 7 attack surfaces — BLE pairing (Just Works vs Numeric Comparison vs Passkey Entry vs OOB), motor controller firmware (JTAG/SWD/USB DFU), mobile-app ↔ cloud TLS, OTA update channel, GPS receiver (spoofing), smart-battery BMS handshake, fleet management API (IDOR).
- Bluetooth Core 5.4 LE Secure Connections з ECDH P-256 — mandatory baseline замість LE Legacy Pairing. Just Works → null-authentication; Numeric Comparison → 10⁻⁶ MITM-resistance.
- Secure boot з RoT — hardware-anchored ланцюжок eFuse → bootloader → kernel → app. NIST SP 800-193 Protection-Detection-Recovery pillars. eFuse-only (free) vs Secure Element ($1-5) trade-off за per-device key isolation.
- OTA з 7 requirements: authentication (Ed25519 signed), integrity (SHA-256 chunked), anti-rollback (monotonic counter), atomicity (A/B partition), recovery (golden image), authorization (user consent), confidentiality (AES-256 encrypted, optional). Frameworks: Mender, SWUpdate, Uptane, IETF SUIT.
- 6 documented incidents 2018-2022: Xiaomi M365 BLE 2019, M365 firmware downgrade tool, Lime BLE replay 2019, Bird API IDOR 2020, Ninebot pwd ‘888888’ 2019-2020, Tier/Voi 2022. Pattern: default credentials + unsigned firmware + missing certificate pinning + IDOR.
- Industry shift 2024-2026 — flagship brands implement: LE SC, signed firmware A/B, mobile-app TLS pinning, OTA signature verification, unique per-device BLE pin. EU CRA approaching effective date + EN 303 645 voluntary cert. Incident-rate reduction ~70-80 % vs 2018-2020 era.
- DIY 8-step security check — default BLE pin / HTTPS verify / OTA channel / security.txt presence / privacy policy / firmware version / fleet API exposure / physical debug pins. 30-40 хв без спецhardware. Pass criteria ≥6/8 = adequate baseline.