Я відмовився від PGP

Про автора: Філіппо Валсорда займається криптографією і TLS, називає себе «послом urandon», входить в криптогруппу компанії Cloudflare, підняв відомий сервіс для тестування на вразливість Heartbleed. Ви могли зустрічати його на конференціях по криптографії та комп'ютерної безпеки або під ніком @FiloSottile на Github і в твіттері

Через роки мук з GnuPG з різним рівнем ентузіазму я прийшов до висновку, що воно не варто того, і я здаюся. Принаймні щодо концепції довгострокових ключів PGP.

Мова не про саму програму
gpg
та не про криптографічних інструментах в принципі. Багато писали на цю тему. Я кажу про моделі довгострокових ключів PGP, будь вона гарантована мережею довіри, відбитками відкритих ключів або моделлю TOFU — неважливо. Я кажу про те, що вона не підходить для мене особисто.

Якщо ви отримали посилання на цю статтю у відповідь на своє зашифрований лист або у відповідь на прохання відкритого ключа, то можете відразу переходити до розділу «Що далі».

Повірте, я намагався. Я пройшов через все. Пробував Enigmail. У мене були офлайнові майстер-ключі на виділеному Raspberry Pi з короткостроковими підключили. Я написав спеціальні програми для виготовлення рукописних резервних копій офлайнових ключів на папері (які я опублікую рано або пізно). У мене були апаратні ключі YubiKey. Цілі дні у мене пішли на розробку правил використання відкритих ключів PGP.

Я витратив дві години на поїздку потягом до найближчого користувачеві Biglumber в Італії, щоб отримати першу підпис в міцному наборі. У мене є підпис від самого пов'язаного ключа в наборі. Я ходив на вечірки з обміну підписами ключів на декількох континентах. Я навіть організував кілька таких.

Я навіть мав зухвалість говорити, що розумію PGP. У 2013 році я препарував пакетний формат, щоб сбрутить короткі ідентифікатори. Я винайшов по-нездорового складні системи, щоб підключ пристрою прив'язувався одночасно до мого особистого майстер-ключа і до корпоративного майстер-ключа. Я складав тікети з проблем юзабіліті і безпеки GnuPG і його різних дистрибутивів.

За всіма ознаками, я повинен бути ідеальним користувачем PGP. Компетентний ентузіаст, оточений співтовариством таких же однодумців.

Але це просто не працювало.

По-перше, нікуди не зникла проблема малопопулярности шифрування, про яку інші багато говорили. Я отримував максимум два зашифрованих листи на рік.

Потім, проблема незручності. Легко допустимі критичні помилки. Плутані лістинги серверів з ключами багаторічної давності. «Я не можу прочитати цей лист на своєму телефоні». «Або на ноутбуці, я залишив ключі, які ніколи не використовую, на іншій машині».

Але справжні проблеми, які я побачив, набагато більш тонкі. Я ніколи не відчував, що мої довготривалі ключі знаходяться в безпеці. Чим більше проходило часу, тим меншою була впевненість у кожному конкретному з них. Ключі YubiKey можуть перехопити в номері готелю. Офлайнові ключі можуть залишитися в далекій шуфлядке або сейфі. Можуть оголосити про нові уразливості. До USB-пристроїв можуть підключитися.

Безпека довгострокових ключів відповідає мінімальному загальному дільнику ваших дій у галузі безпеки протягом усього життя. Це слабка ланка.

Що ще гірше, існуючі практики поводження з довготривалими ключами, такі як збір підписів ключів та друк відбитків відкритих ключів на візитних картках, суперечать іншим шаблонами поведінки, які в іншому випадку вважалися б очевидною гігієнічної рутиною: часто міняти ключі, мати різні ключі на різних пристроях, застосовувати компартментализацию (різні профілі мислення в різних областях, наприклад, на роботі і вдома — прим.пер.). Існуючі практики поводження з довготривалими ключами насправді розширюють вектор атаки, оскільки підштовхують робити резервні копії ключів.

Ми говоримо про гру кішки з мишкою в інфраструктурі, але ця концепція також відноситься і до ключів! Якщо я підозрюю злом, то хочу бути в змозі кинути ноутбук і почати з нуля з мінімальними втратами. Найгірший можливий результат — це прив'язати користувача до ключа, який він вважає потенційно скомпрометованим, тому що ціна заміни ключа занадто висока.

І все це заради чого?

«Звичайно, заради довготривалого довіри».

Так, і про це. Я ще ніколи, жодного разу не використовував мережу довіри для валідації публічного ключа. І пам'ятайте, у мене добре пов'язаний ключ. Я не проводив формального дослідження, але майже впевнений, що кожен, хто використовував PGP для зв'язку зі мною, зробив або може зробити (якщо попросять) одну з наступних речей:

  • витягнув найбільш вподобаний ключ з сервера ключів, швидше за все навіть не за TLS;
  • використовує інший ключ, якщо відповісти йому зі словами «це мій новий ключ»;
  • перешле лист у відкритому вигляді, якщо попросити його з відмовкою кшталт «я в поїздці».
Поїздки та подорожі особливо ворожі до довгостроковим джерелам, роблячи неможливим такий тип старту з чистого аркуша.

Більше того, я навіть не впевнений, що існує зловмисник, проти якого довготривалі ключі мають сенс. Ваш звичайний середній ворог напевно не зможе провести MitM-атаку на особисті повідомлення в твіттері (це означає, що ви можете опортуністично використовувати особисті повідомлення для обміну відбитками відкритих ключів, все ще зберігаючи приватність). Моссад зробить моссадовские речі з вашою машиною, якою б ключ ви ні використовували.

Зрештою, в наш час я більше дбаю про прямий секретності, можливості відмови і ефемерності, ніж про непорушну довірі. Ви впевнені, що можете захищати довготривалий ключ вічно? Тому що коли зловмисник вирішить зробити вас своєю мішенню і доб'ється успіху, він отримає доступ не тільки до усіх ваших повідомлень з цього моменту, але до всіх минулим повідомленнями теж.

далі
Я не опущуся до текстових листів. Зовсім навпаки. Але більше я не буду охороняти свій довготривалий ключ.

В основному, я буду використовувати Signal або WhatsApp, які пропонують значно кращий захист кінцевих точок під iOS, ефемерність і безболісну ротацію ключів.

Якщо ви хочете безпеки зв'язатися зі мною, найкраще запитати через особисте повідомлення в твіттері мій номер Signal. Якщо необхідно, ми можемо визначити відповідний спосіб порівняти відбитки.

Якщо ми зустрічаємося особисто і буде потрібно встановити захищений канал, ми просто обміняємося секретної парольної фрази для використання в найбільш відповідною програмою: OTR, Pond, Ricochet.

Якщо виявиться, що нам дійсно потрібен PGP, ми встановимо які-небудь відповідні ключі, скоріше в стилі Operational PGP. Те ж саме для будь-яких підписаних релізів або canaries, які я можу підтримувати в майбутньому.

Для обміну файлами використовуємо Magic Wormhole, OnionShare або відповідні ключів PGP через захищений канал, який у нас вже є. Тут мета уникнути використання не
gpg
, а моделі управління ключами PGP.

Якщо вам дійсно потрібно швидко надіслати мені повідомлення, я можу зберегти ключ Keybase, але не обіцяю. Мені подобається більше вкорінювати довіру у ваших профілях соціальних, тому що так ротація ключів відбувається більш природним чином. І в будь-якому випадку, це певно той спосіб, яким більшість буде зв'язуватися зі мною.

Я також не відмовляюся від апаратних ключів YubiKey. Мені дуже подобається мій новий YubiKey 4 з датчиком дотику пальця, який я використовую для зберігання ключів SSH, паролів і початкового завантаження машини. Але ці речі на 100% під моїм контролем.

Про моїх старих ключах і переході
Я зламав захист на всіх офлайнових сховищах моїх ключів. У мене немає причин думати, що вони скомпрометовані, але вам слід припинити використовувати їх прямо зараз.

Нижче додані підписи для Markdown-версії цього документа (стаття "Giving up on PGP") зі всіх ключів, які я поки ще можу знайти.

У найближчі тижні я імпортують всі отримані підпису, зроблю всі підписи, які обіцяв, а потім зроблю відгуки на серверах ключів. Я поміняю мій ключ Keybase. В решт-решт, я знищу секретні ключі.

Побачимося в Signal. (Або twitter).

Giving up on PGP.md
Giving up on PGP.md.B8CC58C51CAEA963.asc
Giving up on PGP.md.C5C92C16AB6572C2.asc
Giving up on PGP.md.54D93CBC8AA84B5A.asc
Giving up on PGP.md.EBF01804BCF05F6B.asc [буде, коли я відновлю парольну фразу з іншої країни]

Примітка. Я планую з часом розширити розділ «Що далі», адже інструменти з'являються і зникають. Підписаний файл
.md
не зміниться, непідписаний
.diff
з'явиться нижче для зручності верифікації.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.