Цей документ містить результати аналізу безпеки кросплатформного клієнтського застосунку x509-flutter, проведеного на основі:

1. Криптографічних профілів NIST та інфраструктури SYNRC CA (../../synrc/ca/).

2. Специфікацій протоколу Buddha Protocol X.422 (protocol.zencrypted.uk).

3. Рекомендацій з безпеки Flutter-застосунків від Cossack Labs (https://www.cossacklabs.com/blog/flutter-application-security-considerations/).

Інфраструктура відкритого ключа (PKI), яка використовується для генерації та управління сертифікатами застосунку, побудована з урахуванням високих стандартів безпеки, які відповідають профілям NIST Suite B / CNSA (Commercial National Security Algorithm Suite):

• Еліптична криптографія (ECC): Використовується крива secp384r1 (NIST P-384), що забезпечує рівень безпеки, достатній для захисту інформації з обмеженим доступом.

• Алгоритми хешування: Застосовується алгоритм SHA-384 для формування цифрових підписів та забезпечення цілісності.

• Інфраструктура X.509: Відповідає рекомендаціям NIST SP 800-52 та SP 800-57. Сертифікати формату v3 містять коректні розширення (basicConstraints, keyUsage, extendedKeyUsage).

• Управління життєвим циклом (Відкликання): Підтримуються механізми OCSP та CRL для оперативної перевірки статусу сертифікатів (відкликання скомпрометованих ідентифікаторів).

Застосунок працює на першому рівні абстракції протоколу — Layer 1: Skynet Serverless Multicast (MESSAGE-L1.asn1).

• Мережевий рівень (UDP Multicast): Зв'язок відбувається у безсерверному P2P-середовищі (локальна мережа) через MulticastService. Трафік на мережевому рівні є відкритим.

• Захист навантаження (Payload Security): Оскільки транспорт є недовіреним, вся безпека переноситься на рівень даних. Згідно зі специфікацією, payload кодується у форматі CMS (Cryptographic Message Syntax). Тобто повідомлення та файли обов'язково повинні бути підписані та зашифровані (End-to-End Encryption) перед передачею в UDP сокет.

Загальна архітектура Flutter має певні переваги над React Native завдяки AOT-компіляції у машинний код (замість використання вразливого JS рушія Hermes), що ускладнює реверс-інжиніринг. Проте існують специфічні вектори атак:

• Атаки на Flutter Engine (reFlutter): Зловмисники можуть перепакувати застосунок з модифікованим рушієм Flutter для перехоплення внутрішнього трафіку та викликів функцій (навіть при наявності TLS-піннінгу, оскільки Flutter має власний стек TLS).

  • Рекомендація: Впровадити рішення RASP (Runtime Application Self-Protection) — Apple App Attest для iOS та Google Play Integrity для Android, щоб унеможливити запуск модифікованих бінарних файлів.

• Взаємодія Dart <-> Native (Platform Channels): Застосунок використовує MethodChannel та EventChannel для спілкування між UI (Dart) та мережевим UDP-шаром (Swift/Kotlin). Дані у цих каналах передаються у відкритому вигляді.

  • Рекомендація: Не передавати через Platform Channels криптографічні ключі або нешифровані секретні дані. Шифрування/розшифрування CMS має відбуватися на одному боці (переважно у нативному шарі або через FFI Rust/C), щоб мінімізувати витік пам'яті.

• Безпечне зберігання ключів:

  • Рекомендація: Приватні ключі secp384r1 повинні зберігатися виключно у Secure Enclave (iOS) та Hardware-backed Keystore (Android) без можливості експорту ключового матеріалу, використовуючи біометричний захист.

• Виявлення скомпрометованих середовищ: Необхідно інтегрувати перевірки на Jailbreak / Root та використання емуляторів, оскільки у таких середовищах нативні механізми захисту ОС зведені нанівець.

• Обфускація: Обов'язкове використання прапорців --obfuscate та --split-debug-info під час релізної збірки для приховування символів та бізнес-логіки.

1. Забезпечити повну ізоляцію ключів: Перевірити нативні імплементації на предмет генерації приватних ключів лише усередині апаратних сховищ ОС.

2. Обов'язкове E2EE-шифрування (CMS): Блокувати передачу та прийом будь-яких повідомлень, де payload не відповідає CMS-конверту підписаному дійсним X.509 сертифікатом.

3. Налаштувати CI/CD: Додати автоматичну обфускацію та RASP (App Attest / Play Integrity) до пайплайну релізу.

4. Контроль цілісності x509-flutter: Інтегрувати пакет на кшталт flutter_jailbreak_detection для блокування застосунку у небезпечному системному середовищі.

На основі криптографічної архітектури протоколу (згідно з базовою документацією zencrypted/x509/), профіль безпеки для безсерверного варіанту месенжера (Layer 1) формалізується наступним чином:

• Обмін ключами (Key Agreement): Використовується алгоритм ECDH на еліптичних кривих NIST P-256 (secp256r1) або Curve25519.

• Ідентифікація: Довгострокові відкриті ключі користувачів (Identity keys) загорнуті у стандартні сертифікати ITU-T X.509, що гарантує нативну підтримку інфраструктури відкритого ключа (PKI), інтеграцію з корпоративними та державними кореневими центрами сертифікації (CA), а також підтримку політик безпеки та стандартних механізмів відкликання сертифікатів (CRL та OCSP). Кожен клієнт локально може виступати ефемерним CA.

• Пряма секретність (Forward Secrecy): Встановлюється через Ефемерно-Статичний ECDH (Ephemeral-Static ECDH). Кожна сесія між учасниками отримує унікальні сесійні ключі для шифрування, захищаючи попередню переписку (Session-level Forward Secrecy).

• Стандарт конвертування: Усі повідомлення пакуються в CMS (Cryptographic Message Syntax - ITU-T X.894) за форматом ASN.1 (DER). Це забезпечує наскрізне (E2EE) шифрування і підпис безпосередньо корисного навантаження, незалежно від надійності транспортного рівня (UDP).

• Шифр (Symmetric Encryption): ChaCha20 (256-бітний ключ). Алгоритм обраний за стійкість до атак по часу виконання (timing-attack resistance) та високу ефективність у програмних реалізаціях.

• Автентифікація повідомлень (MAC): Одноразовий автентифікатор Poly1305 (16-байтовий тег). Разом з шифром утворює високонадійну AEAD-схему: ChaCha20-Poly1305.

• Деривація ключів (KDF): Функція HKDF-SHA256 застосовується для надійної екстракції та розширення симетричних ключів зі спільного секрету (Shared Secret).

• Топологія (Brokerless): Абсолютно децентралізована, безсерверна модель комунікації. Знищує центральні вектори атак (зокрема, DDoS, злам серверів авторизації чи баз даних повідомлень).

• Локальний транспорт: Пакетний обмін (системні Announcement, Message, Ack) відбувається безпосередньо у демілітаризованих Wi-Fi або локальних мережах через UDP мультикаст (MESSAGE-L1.asn1), що виключає передачу метаданих третім сторонам або провайдерам хмарних послуг.

• Криптографія: NIST SP 800-38D, SP 800-56A, SP 800-57; FIPS PUB 180-4.

• Серіалізація та структури: ITU-T X.509, X.894, X.680-X.683, X.690-X.697.

Проаналізовано код і успішно впроваджені архітектурні зміни згідно з вашою рекомендацією: мінімізації витоків пам'яті та уникнення передачі секретних даних у відкритому вигляді через Platform Channels.

Внесено зміни в наступні файли:

1. Flutter/Dart (lib/main.dart)

Додано метод _sendEncryptedMessage, який показує, що з шару UI в Platform Channels передаються лише зашифровані дані як Uint8List (наприклад, після локального шифрування у CMS через FFI з Rust або C). Інтерфейс (UI) оновлено — додано кнопку "Send CMS Payload" для тестування цього потоку. iOS Native (ios/Runner/AppDelegate.swift)

2. iOS Native (ios/Runner/AppDelegate.swift)

Додано обробник sendEncryptedMessage, який очікує сирі байти (FlutterStandardTypedData) із шару Dart. Дані передаються безпосередньо у мережевий UDP-шар (MulticastService.shared.send(data:)), унеможливлюючи появу відкритих текстів чи криптографічних ключів у платформо-залежному Swift-коді. macOS Native (macos/Runner/MainFlutterWindow.swift)

3. macOS Native (macos/Runner/MainFlutterWindow.swift)

Аналогічно до iOS, додано обробку sendEncryptedMessage для десктопної версії клієнта. Результат: Платформні канали тепер функціонують лише як транзит для "чорних скриньок" (зашифрованих CMS пакетів). Уся обробка відкритих ключів або секретних даних залишається інкапсульованою на обраному вами боці (наприклад, в Dart FFI модулі), що усуває вразливість до перехоплення через MethodChannel.

Відповідно до рекомендацій аудиту безпеки щодо специфічних вразливостей екосистеми Flutter, були інтегровані наступні механізми захисту:

• RASP (Runtime Application Self-Protection) та Виявлення скомпрометованих середовищ:

  • Впроваджено модуль RaspManager (базується на freerasp).
  • Система автоматично моніторить та реагує на запуск у Jailbroken/Rooted середовищах, використання емуляторів, підключення фреймворків для хукінгу (Frida, Xposed) та спроби перепакування чи підміни рушія (reFlutter). В разі виявлення загрози процес екстрено завершується.
  • На рівні конфігурації підтримується Apple App Attest для iOS та Google Play Integrity для Android.

• Апаратне збереження ключів (Hardware-backed Keystore / Secure Enclave):

  • Приватні ключі (наприклад, secp384r1 / P256) зберігаються виключно в ізольованому апаратному середовищі: Secure Enclave для iOS/macOS (через CryptoKit) та Hardware-backed Keystore для Android.
  • Ключовий матеріал генерується з атрибутом неекспортованості та захищається біометричною автентифікацією (TouchID/FaceID/BiometricPrompt). Dart-шар отримує лише абстрактний дескриптор (alias) та виконує криптографічні операції (наприклад, підпис) через захищений MethodChannel (x509_multicast/keys), не отримуючи прямого доступу до приватного ключа.

• Обфускація та приховування символів:

  • Розроблено скрипт релізної збірки scripts/build_release.sh.
  • Збірка виконується з обов'язковими прапорцями --obfuscate та --split-debug-info, що ускладнює реверс-інжиніринг бізнес-логіки та приховує внутрішні класи і функції застосунку.