date: 2022-01-16T03:00:00Z
# Як працюють наскрізні зашифровані повідомлення LocalCryptos
LocalCryptos — єдиний популярний P2P-маркет, який використовує наскрізне шифрування для захисту повідомлень між користувачами.
Повідомлення між користувачами на торговій платформі LocalCryptos P2P шифруються. Це означає, що повідомлення шифруються під час передачі від комп’ютера відправника до одержувача, не дозволяючи нікому перехопити та прочитати розмову під час передачі, включаючи LocalCryptos.
Платформа досягає цього за допомогою API веб-криптографії, сучасного API JavaScript, який забезпечує розширені криптографічні операції, такі як шифрування, дешифрування, перевірка підпису та генерування безпечних ключів для веб-браузерів.
Хоча надсилання та отримання повідомлень на LocalCryptos може виглядати так само, як і на будь-якому іншому веб-сайті, те, що відбувається «під капотом» на ЦП вашого пристрою, значно відрізняється від майже всіх інших веб-сайтів.
LocalCryptos є одним з небагатьох відомих веб-програм, які реалізують безпечну технологію наскрізного шифрування всередині веб-сайту, наприклад WhatsApp Web і Skiff.
Перед наскрізним шифруванням
Викриття про спостереження за масовими комунікаціями та серйозні порушення баз даних змусили споживачів обережніше ставитися до своєї конфіденційності в Інтернеті.
Відомі онлайн-сервіси стали об’єктом вторгнень з боку анонімних хакерів. У таких компаній, як Apple, TikTok, Target, Equifax, Yahoo, eBay, Ancestry.com, AOL, Adobe, LinkedIn, Microsoft, YouTube, Instagram, Quora, Airtel, Ashley Madison, Nintendo, Dropbox, було вкрадено багато конфіденційної інформації. T-Mobile, Uber, Поштова служба США та багато іншого в деяких із найбільших зломів даних в новітній історії.
Крім того, у 2013 році стало відомо, що США уряд таємно збирав дані від інтернет-компаній. Програма PRISM АНБ збирала дані з широкого кола компаній, включаючи Google, Microsoft, Yahoo, Facebook, YouTube, Skype, а також численних споживчих постачальників.
Ранні програми обміну миттєвими повідомленнями майже не забезпечували жодного захисту від подібних порушень. Хоча повідомлення надсилалися через зашифровані канали, канал зазвичай був між клієнтом і постачальником послуг. Постачальник послуг, такий як Facebook, Skype або Google, зміг прочитати вміст усіх повідомлень, доставлених через службу. Якщо постачальник був зламаний, історії повідомлень у відкритому тексті могли бути масово вилучені.
Поява наскрізного шифрування
У відповідь на ці загрози розробники та криптографи прискорили дослідження нових методів забезпечення безпеки в сучасному цифровому світі, де не можна довіряти ані постачальникам послуг, ані постачальникам послуг. Зараз багато поширених програм обміну миттєвими повідомленнями використовують передові криптографічні методи для досягнення наскрізної конфіденційності, включаючи OTR, iMessage від Apple, WhatsApp, Signal, Telegram і навіть Facebook Messenger.
LocalCryptos застосовує методи наскрізного шифрування, щоб фінансові дані та особиста інформація користувачів залишалися конфіденційними між залученими сторонами. Повідомлення між користувачами є наскрізними. ‐кінцеве шифрування, що означає, що навіть у випадку скомпрометованої бази даних, жодна конфіденційна інформація, така як інформація про банківський рахунок, не може бути вилучена з історичних повідомлень.
Розробники та дослідники протоколу миттєвого обміну повідомленнями Off-the-Record Messaging (OTR) надихнули технологію, яка лежить в основі наскрізного шифрування повідомлень на LocalCryptos.
Що не зашифровано на LocalCryptos
Перш ніж заглибитися в технічні деталі реалізації наскрізного шифрування LocalCryptos, необхідно обговорити, що не робиться секретним.
LocalCryptos не може читати вміст кожного повідомлення без дозволу одного з учасників, однак він може бачити деякі метадані, пов’язані з цими повідомленнями. Наприклад, ми знаємо, коли було надіслано повідомлення, кому воно було надіслано, а також знаємо, чи було прочитане конкретне повідомлення і коли.
Якщо ви думаєте про наскрізні зашифровані повідомлення як про листи, LocalCryptos — це поштовий сервіс, який доставляє конверти, що містять кожен лист. Хоча ми не вміємо читати листи, нам потрібно знати, куди доставити конверт.
Беручись з конвертами, ми також можемо зробити деякі обґрунтовані припущення щодо листа, не читаючи його:
- Якщо конверт здається важчим, ніж зазвичай, ми можемо зробити обґрунтоване припущення про його розмір, зваживши його. Однак відправники заповнюють лист пустими сторінками, тому ми не зможемо визначити точна кількість слів.
- Якщо до конверта додається посилка, очевидно, що ви надіслали вкладення (наприклад, зображення чи документ), а не звичайний лист. Звичайні повідомлення, як правило, менші за кілобайт, тоді як вкладення можуть бути в кілька тисяч разів більшими.
Тепер необхідно обговорити, що зашифровано і як працює наскрізний зашифрований протокол обміну повідомленнями в LocalCryptos.
Таємне узгодження ключа шифрування
Щоб два користувачі могли надсилати зашифровані повідомлення один одному, вони мають узгодити спільний секрет для шифрування та дешифрування цих повідомлень. Однак вони не можуть дозволити іншим бачити цей спільний секретний ключ, тому передача цього ключа через сервер LocalCryptos як посередника неможлива.
LocalCryptos використовує анонімну схему угоди з ключем, відому як Elliptic Curve Diffie–Hellman Key Exchange (ECDH). Ця криптографічна схема дозволяє двом людям з парами відкритих ключів отримати один і той самий спільний секрет, використовуючи приватний ключ однієї людини та відкритий ключ іншого.
Щоб це працювало, LocalCryptos виконує роль сервера ключів для розповсюдження криптографічних відкритих ключів користувачам. Веб-браузери користувачів також зберігають відкриті ключі інших користувачів у сховищі свого пристрою, щоб захистити від злому сервера ключів, однак ми залишимо ці деталі для іншої статті.
По-перше, користувачі вже повинні знати публічні ключі ідентифікації іншого або отримати їх із сервера ключів LocalCryptos. Ці пари ключів ідентифікації, які ніколи не змінюються, не використовуються в процесі ECDH; однак вони використовуються для аутентифікації іншого набору пар ключів, які використовуються в методі Діффі–Хеллмана.
На додаток до відкритих ключів ідентифікації, користувачі безшумно генерують велику кількість криптографічно захищених «попередніх ключів» (також «ключів виробника») під час першої реєстрації на платформі. Це ефемерні пари публічно-приватних ключів, які підписуються цифровим підписом за допомогою ключів ідентифікації користувача, а потім завантажуються на сервер ключів LocalCryptos. Метою цих «попередніх ключів» є можливість повністю асинхронного обміну ключами (тобто дозволити користувачам отримувати повідомлення в автономному режимі).
Коли користувач ініціює розмову, він на льоту генерує третю ефемерну пару ключів. Ми називаємо це «беручи ключ». Ця пара ключів є останньою частиною головоломки, яка забезпечує бездоганну роботу безпечної та асинхронної схеми угоди ключів.
Покроковий процес ініціювання безпечного протоколу наскрізного шифрування:
- Користувач, який ініціює розмову (Аліса), отримує ключову інформацію одержувача (Боба) із сервера ключів LocalCryptos. Це включає:
- Ідентифікаційний ключ Боба (відкритий ключ)
- Один із попередньо підписаних «попередніх ключів» Боба (відкритий ключ і цифровий підпис)
- Аліса перевірить, що цифровий підпис, доданий до «попереднього ключа» Боба, був підписаний ідентифікаційним ключем Боба.
- Аліса виконає операцію Діффі-Хеллмана, використовуючи приватний ключ свого «беручи ключ» та відкритий ключ «попереднього ключа» Боба. Результатом цього алгоритму стане загальний секрет (
SharedSecretRoot). SharedSecretRoot використовується як початковий елемент для обчислення більш безпечних ключів з використанням SHA-256 як функції виведення ключа. Оскільки використання одного ключа для кількох цілей вважається поганою практикою через потенційну небажану взаємодію в різних схемах, різні ключі отримують із кореня для різних цілей:SharedSecretEnc — для шифрування повідомлень за допомогою AES‐256, результат SHA256(SharedSecretRoot || "enc").SharedSecrets Mac — Для автентифікації повідомлень за допомогою HMAC-SHA256, результат SHA256(SharedSecretRoot || "mac").
- Аліса надасть Бобу через LocalCryptos свій відкритий ключ і доданий цифровий підпис (підписаний її ідентифікаційним ключем) «беручт ключ», який вона згенерувала під час цієї процедури.
Коли Боб отримає її відкритий ключ, у нього буде достатньо інформації, щоб виявити той самий спільний секрет, який обчислила Аліса.
Метод Діффі-Хеллмана створює той самий загальний секрет, коли вводяться зворотні введення відкритого та закритого ключа. Для будь-яких двох закритих ключів pk і p'k та відповідні відкриті ключі ECDSA pu і p'u:
Спільний секрет (SharedSecretRoot) — це функція ECDH, яка використовує параметри приватного ключа однієї сторони та відкритого ключа іншої. Для пари ключів виробника mk і tk і tu, загальний секретний корінь sr:</p>
<p spaces-before="0"><img src="./EndToEndEncryptedMessages_Text2.svg" alt="" /></p>
<p spaces-before="0">Це означає, що коли Боб входить в систему, щоб перевірити свої повідомлення:</p>
<ol start="1" spaces="0" level="0"> <li marker="1" level="0" spaces="0" spaces-after-marker="0">Боб отримає «беручи ключ» та цифровий підпис Аліси, зашифрований текст зашифрованого повідомлення, яке вона надіслала, та її ідентифікаційний ключ.</li> <li marker="2" level="0" spaces="0" spaces-after-marker="0">Боб перевірить, що цифровий підпис, доданий до «беручи ключ» Аліси, був підписаний за допомогою її пари ключів ідентифікації, щоб переконатися, що він справді належить їй.</li> <li marker="3" level="0" spaces="0" spaces-after-marker="0">Боб виконає операцію Діффі-Хеллмана, використовуючи приватний ключ свого «попереднього ключа» та відкритий ключ «беручи ключ» Аліси. Це надасть Бобу той самий <code>SharedSecretRoot, який створений Алісою. 4 Використовуючи ті самі функції виведення ключа, Боб знайде SharedSecretEnc і SharedSecretMac і використає їх для розшифрування зашифрованого повідомлення, надісланого Алісою.
Внутрішня структура повідомлень
Коли користувач пише повідомлення, воно форматується в кодований JSON корисний файл до початку процесу шифрування. На момент написання статті існують два типи корисних повідомлень: текстові повідомлення та вкладені файли. Повідомлення – це прості текстові повідомлення, а вкладення призначені для завантаження більших файлів, наприклад зображень або документів.
Корисне навантаження повідомлення — це проста структура JSON. Є три властивості, які повинні бути включені в кожне корисне навантаження незалежно від типу:
Стандартні повідомлення
type — Це може бути «повідомлення» або «вкладення». Підтримка інших типів може бути додана в майбутньому.trade_id — унікальний ідентифікатор цієї торгівлі. Це робиться для запобігання складним атакам повторного відтворення (тобто копіювання повідомлень з інших торгів і вдавання, що вони призначені для цього).client_timestamp — Поточна позначка часу на комп’ютері відправника (ISO 8601). Це також для виявлення складних атак відтворення, і це дозволяє арбітру викликати поганого актора, якщо він стверджує, що надіслав повідомлення пізніше або раніше, ніж реальність.
Ось приклад:
{
"type": "message",
"client_timestamp": "2022-01-13T00:00:00Z",
"trade_id": "xxxx-xxxx-xxxx-xxx",
"message": "Привіт! Це моє зашифроване пов��домлення».
}
Зашифровані вкладення
Іноді користувачі хочуть надсилати один одному вкладення, наприклад зображення та документи.
Проте включення вмісту вкладених файлів у зашифроване повідомлення може призвести до болючої роботи користувача, особливо для користувачів із поганим підключенням до Інтернету. Це означатиме, що одержувачу потрібно буде завантажити весь вкладений файл (який може становити кілька мегабайт), перш ніж він зможе навіть дізнатися, що це вкладення.
Замість цього ми розділяємо два: файл шифрується та завантажу��ться окремо, а зашифроване повідомлення просто вказує на розташування зашифрованого вкладення та інструкції щодо його розшифрування. Це дає одержувачу можливість не завантажувати вкладений файл.
Процес надсилання вкладеного файлу:
- Відправник генерує новий секретний 256-бітний ключ і вектор ініціалізації для шифрування вкладення (
AttachmentKey і AttachmentIv). - Відправник шифрує вміст вкладення за допомогою AES256-CBC за допомогою
AttachmentKey і AttachmentIv. - Хеш SHA-256
AttachmentCiphertext генерується для захисту цілісності вкладення (AttachmentHash). - Відправник завантажує
AttachmentCiphertext у хмарне сховище та отримує унікальний ідентифікатор (AttachmentBlobKey). - Відправник створює корисне повідомлення, що містить посилання на вкладений файл та інформацію, необхідну для його автентифікації та дешифрування (
AttachmentBlobKey, AttachmentKey, AttachmentIv і AttachmentHash). Вони також містять метадані, включаючи оригінальну назву файлу, розширення та розмір вкладеного файлу.
Ось приклад:
{
"type": "attachment",
"client_timestamp": "2022-01-13T00:00:00Z",
"trade_id": "xxxx-xxxx-xxxx-xxx",
"attachment_blob_key": "Ключ AttachmentBlobKey",
"attachment_sha256": "Hash вкладення",
"attachment_iv": "AttachmentIv",
"attachment_key": "AttachmentKey",
"filename": "UploadedFile.jpg",
"filesize": 1000000
}
Шифрування корисних даних повідомлень
Ці корисні дані, закодовані JSON, шифруються за допомогою спільного секрету бесіди, підписуються за допомогою ключа ідентифікації облікового запису відправника та хешуються за допомогою спільного ключа MAC. Це дає змогу іншому користувачеві переконатися, що повідомлення було надіслано відправником і чи воно не було підроблено на цьому шляху.
Ось як це працює:
- Відправник створює підпис ECDSA (
MessageSignature) keccak‐256 MessagePayload. - Відправник створює вектор ініціалізації для шифрування (
MessageIv). - Створюється пакет із JSON-кодуванням (
MessagePackage), що містить MessagePayload і MessageSignature, що створюється. MessagePackage шифрується за допомогою AES256-CBC до SharedSecretEnc з IV MessageIv і заповненням (MessageCiphertext).- Щоб захистити цілісність повідомлення, відправник створює код аутентифікації повідомлення (
MessageMac) як HMAC-SHA256(SharedSecretMac, MessageCiphertext). - Відправник надсилає
MessageCiphertext, MessageIv, і MessageMac до API, який доставляє їх одержувачу.
Запитання
Чи не порушить арбітраж мету наскрізного шифрування?
Не існує такого поняття, як зашифрований протокол обміну повідомленнями, який міг би зробити неможливим для одержувача повідомлення поділитися ним з кимось іншим.
Ви не можете заборонити людині, якій ви надсилаєте повідомлення, ділитися вашим повідомленням, так само як ви не можете перешкодити комусь зробити знімок екрана. Якщо хтось вирішить поділитися своєю розмовою, в тому числі з нами, він може це зробити.
Коли нам потрібно розслідувати заяви про шахрайство чи зловживання, або розглядати суперечки щодо оплати, ми заохочуємо користувачів ділитися з нами вмістом розмов.
Поширення спільного секрету розмови з нами дозволяє нам повернутися назад і розшифрувати стенограму цієї конкретної розмови, однак це не впливає на конфіденційність ваших інших розмов. Це пояснюється тим, що кожна торгівля використовує унікальний набір пар ключів для отримання спільного секрету, що робить спільні секрети також унікальними.
Які обмеження цієї системи?
Ми щойно розповіли вам, як захищені повідомлення на LocalCryptos. У дусі прозорості давайте також обговоримо, як вони можуть бути небезпечними.
Є деякі експерти, які виступають проти створення веб-додатків шифрування, розроблених з повагою до інтересів користувача, а не веб-провайдера, що ми і зробили. Хоча ми в кінцевому підсумку не згодні з цією загальною рекомендацією, оскільки вважаємо, що переваги переважають ризики, а веб-безпека з часом покращиться, аргументи проти використання API веб-криптографії на веб-сайтах не безпідставні.
Основним аргументом проти використання криптографії у веб-браузерах є те, що веб-програми в кінцевому підсумку менш безпечні, ніж програми та розширення браузера, коли справа доходить до доставки коду програми. Це пов’язано з принципом роботи веб-перегляду: коли ви відвідуєте цей або будь-який інший веб-сайт, ваш веб-браузер отримає останній код програми LocalCryptos безпосередньо з веб-сервера LocalCryptos і запустить його — не роблячи особливих зусиль, щоб підтвердити, що код дійсно є офіційний код LocalCryptos і не був змінений.
Ви можете подумати, що використання HTTPS вирішує цю проблему автентифікації, завдяки чому LocalCryptos може цифрово підписати код, який він надає, і ви частково праві, але лише до певної міри. Хоча HTTPS практично усуває переважну більшість теоретичних атак «людина посередині» на веб-користувачів, він не усуває загрозу, що сам веб-сервер LocalCryptos може бути скомпрометований. Розумний хакер може зламати веб-сервери LocalCryptos і обережно модифікувати один із файлів JavaScript, що доставляються кінцевим користувачам, можливо, щоб вставити кілька рядків коду для перекачування приватних ключів.
LocalCryptos робить багато, щоб мінімізувати цей ризик, використовуючи всі доступні механізми безпеки HTTP, DNS і BGP і дуже серйозно ставлячись до безпеки. Однак повністю усунути цю загрозу неможливо. Те ж саме можна сказати про буквально будь-який інший веб-сайт і веб-програму; завжди існує ймовірність того, що будь-який веб-сайт або додаток буде вразливим до дуже складної атаки. Зрештою, кібербезпека – це завжди ковзаюча шкала, яка вимагає тонкого та чесного обговорення, і кожен, хто скаже вам, що певний елемент програмного забезпечення неможливо зламати завжди неправильно.
Отже, що станеться з конфіденційністю ваших надісланих та отриманих приватних повідомлень, якщо веб-сайт LocalCryptos зазнає серйозного зламу? Це дійсно залежить. Якщо ваш веб-браузер виконує зловмисно отруєний код, введений досвідченим хакером, існує ймовірність того, що він може отримати доступ до матеріалу вашого приватного ключа та розшифрувати історію вашої розмови. Однак, якщо ваш веб-браузер не виконує гіпотетично отруєний код, ваші секретні розмови залишаться таємними, незалежно від порушення веб-сайту. Іншими словами, якщо ви відвідуєте сайт і входите в систему під час активної атаки, ви можете опинитися під загрозою; однак, якщо ви не відвідуєте веб-сайт активно під час атаки, ви не ризикуєте. Це тому, що ваш веб-браузер виконує код веб-сайту лише тоді, коли ви навмисно переходите на нього.
Для порівняння: якби централізовану службу обміну повідомленнями зламали, усі миттєво опинилися б під загрозою. Зловмисник зможе завантажити звичайний текст кожного надісланого та отриманого повідомлення, тому що кожне повідомлення буде просто зберігатися в базі даних у вигляді простого тексту. Наслідки від атаки на незашифровану службу обміну повідомленнями були б набагато більш руйнівними, ніж атака на наскрізне зашифроване веб-додаток.
Зрештою, ми вважаємо, що переваги безпеки від використання технології наскрізного шифрування на стороні клієнта значно перевищують ризик цілеспрямованої та складної атаки, і що безпека доставки додатків у веб-додатках з часом покращиться, оскільки нові технології безпеки стають доступними для сучасних браузерів.
Чому немає Double Ratchet?
Хоча деякі реалізації наскрізного зашифрованого обміну повідомленнями, такі як Signal, роблять оновлення ключів на крок далі завдяки угоді Діффі-Хеллмана після кожного повідомлення в обидва кінці, така практика не приносить користі LocalCryptos і насправді контрпродуктивна, оскільки ускладнює процес вирішення спорів.
Оновлення ключів на рівні повідомлень є зайвим для торгів, оскільки сесії тривають недовго. Має сенс продовжувати обмінюватися новими ключами для довготривалих розмов (наприклад, розмови у WhatsApp або Facebook, які можуть тривати роками), але більшість угод закінчуються дуже швидко.
Як я можу перевірити, що мої повідомлення зашифровані?
Якщо ви ввімкнете «Експертний режим» під час розмови, ви можете натиснути на кожне повідомлення, щоб розкрити низькорівневі відомості про кожне повідомлення.
Ці деталі включають все, що ми обговорили в статті. Однак вам потрібно добре розуміти прикладну криптографію, щоб зрозуміти значення та значення цих значень.
Ви можете натиснути кожне значення, щоб скопіювати його в буфер обміну та вручну переконатися, що математика виконується — використовуючи будь-який сторонній код чи інструмент, який ви виберете, або ви можете написати власний.
Крім того, ви можете перевірити, чи це єдина інформація, яка надсилається в LocalCryptos, за допомогою інструментів розробника вашого браузера.
Author
Michael is the co-founder and technical lead of LocalCryptos, the largest non-custodial peer-to-peer digital currency marketplace. Peer-to-peer traders use LocalCryptos to buy and sell crypto using non-custodial wallets and a secure decentralized escrow system.
Australia
