12.05.2023
2 хв
2268
Для розуміння механізму роботи PGP необхідно мати уявлення про базові поняття криптографії, зокрема – про симетричний та асиметричний підхід до шифрування. Роз’яснення нижче носять пізнавальний характер, оскільки у рамках цього розділу заглиблюватися в криптографію та математичні методи, що застосовуються в ній, ми не будемо. Для спрощення сприйняття процес шифрування варто розуміти як якусь чорну скриньку (за фактом – математичний вираз), проходячи через яку дані, під впливом ключів (по суті – змінні в рівнянні), або шифруються, або дешифруються .PGP – Pretty Good Privacy – є найбільш поширеною і популярною технологією шифрування даних. У мережі найчастіше можна зустріти такі абревіатури як PGP, OpenPGP, GPG (GnuPG). Якщо не брати до уваги деталі, то всі є близькими родичами і побудовані на одних і тих же принципах, за рахунок чого є взаємозамінними і взаємно сумісними. Цей розділ не передбачає історичної довідки, але за наявності інтересу до історії можна ознайомитися з особистістю Філліпа Циммермана – творця PGP. Головна відмінність асиметричного методу від симетричного полягає в тому, що навіть якщо третя особа перехопить зашифроване публічним ключем повідомлення – розшифрувати його без приватної частини не вдасться.
Вагомим мінусом є те, що асиметричний підхід досить ресурсоємний, тому використовувати його для великого обсягу даних просто недоцільно. Однак, цей метод знайшов собі застосування у зв’язках із симетричним шифруванням – такий тандем часто називають гібридним шифруванням. У цьому контексті передбачає, що між учасниками обміну даними встановлюється деяка сесія, під час якої для оптимізації витрат часу на шифрування та дешифрування даних використовується виключно симетричний метод. Розсилка симетричних ключів відбувається за допомогою механізму асиметричного шифрування – тобто симетричні ключі шифруються публічним ключем одержувача, і в такий спосіб вирішується проблема поширення секретів симетричного методу.
Ці чорні ящики можуть бути засновані як на симетричному шифруванні, так і на асиметричному.
Припускає, що і відправник, і одержувач використовують один і той самий ключ як для шифрування, так і для дешифрування. Тобто. всі, хто має такий ключ, можуть легко читати всі зашифровані ним дані.
Незважаючи на те, що цей метод є найшвидшим у плані роботи з даними, він має один критичний недолік – проблема безпечного поширення ключів. Фактично, єдиним безпечним способом передати ключ другій стороні є передача його особисто на якомусь фізичному носії, що в сучасних реаліях вкрай незручно. Тому в чистому вигляді даний метод не застосовується і завжди використовує асиметричне шифрування, яке вирішує проблему безпечного поширення симетричних ключів.
Припускає, що одержувач і відправник мають пару ключів. У кожну пару ключів входять:
Слід зазначити , що на цьому моменті часто виникає помилкове враження, що лише приватним ключем можна розшифрувати, і лише публічним – шифрувати. Це докорінно неправильно – таких технічних обмежень немає. Обидві частини ключа абсолютно рівноправні, розподіл на публічні та приватні частини умовний, і за бажання можна використовувати публічний ключ як приватний, і приватний – як публічний.
Насамперед PGP треба сприймати не як єдиний алгоритм, а як послідовність з кількох алгоритмів. Залежно від реалізації і навіть версії для кожного з етапів цієї послідовності можуть застосовуватися різні варіації алгоритмів. При цьому як оригінальна технологія PGP, так і непропрієтарні версії типу OpenPGP повністю сумісні один з одним.
Одноразовий симетричний ключ створюється автоматично за допомогою генератора рандомних чисел
У загальному вигляді має такий вигляд:
Cтворення хешу даних.
Компресія (стиснення) даних.
Створення одноразового симетричного ключа *
Підпис хеша, отриманого на 1 етапі, приватним ключем відправника.
Шифрування стислих даних одноразовим сесійним симетричним ключем.
Шифрування одноразового ключа та зашифрованого повідомлення публічним ключем одержувача.
Перевірка підпису (одержувач намагається розшифрувати сигнатуру з допомогою публічного ключа відправника)
Розшифровка симетричного ключа
Розшифровка даних своїм приватним ключем
Отримання хеша даних
Перевірка цілісності (порівняння двох отриманих хешів)
Перевірка підпису дозволяє переконатися, що хеш був відправлений очікуваною сутністю або користувачем. Якщо перевірка підпису провалилася, таке повідомлення не може вважатися валідним. Щоб упевнитися в тому, що дані дійшли без спотворень або втручань, можна порівняти два хеші. Якщо надісланий та отриманий хеш відрізняються, дані вважаються скомпрометованими та не можуть вважатися достовірними.
Key-сервери є окремими ресурсами, які зберігають дані про зареєстровані ключі з прив’язкою до ID або email власника. Існують як сервери загального користування, куди можуть експортувати свої ключі всі бажаючі, так і закриті. Останні найчастіше прив’язані до певних програм або сервісів, що надають кінцевому користувачеві можливість шифрування. Наприклад, той же FlowCrypt зберігає публічні ключі своїх користувачів на сервері attester.flowcrypt.com. Потрібно відзначити, що сервер FlowCrypt не можна вважати повністю закритим, тому що будь-хто бажає, знаючи id або email. може шукати там громадські ключі.
До key-серверів варто ставитися як до опціональної можливості: якщо мета створення пари асиметричних ключів була в тому, щоб спілкуватися могла обмежена група осіб – достатньо буде обмінятися відкритими ключами всередині цієї групи.
Крім цього, ECDSA/EdDSA пропонує на вибір кілька варіацій алгоритмів. Якщо коротко:
ed25519(cv25519) – використовує EdDSA, за замовчуванням це стандарт.
brainpool – використовує ECDSA, розроблений великою спільнотою німецьких криптографів.
NIST – використовує ECDSA, родом з Америки, просувається у себе на батьківщині як стандарт для державних установ.
У більшості випадків вибирається ed25519 або brainpool, тому що наявність NIST в офіційних рекомендаціях США наштовхує багатьох користувачів на думку, що десь усередині цієї варіації є прикопана лазівка для спецслужб. RSA та DSA пропонують вибрати довжину ключа, і в цьому виборі варто спиратися на реальні вимоги до криптостійкості та швидкості роботи. Важливо пам’ятати, що навіть найдовші ключі піддаються злому, а безпека – це тонкий баланс між параноєю та мінімізуванням ризиків.
Найчастіше PGP ключі зустрічаються у пересиланні повідомлень (банальний email), проте одним цим полем застосування вони необмежені. Різноманітні системи керування репозиторіями (GitLab, GitHub, Bitbucket) також підтримують PGP для доступу до репозиторій та підписів коммітів.
Способів згенерувати свою пару ключів – безліч. Нерідко програми типу FlowCrypt пропонують створити пару ключів за користувача. З плюсів можна назвати повну автоматизацію процесу та розташування ключа на окремому key-сервері, а не на дефолтному для багатьох keyserver.ubuntu.com. Однак, для більшого контролю краще займатися генерацією самостійно – так у разі компрометації можна швидко відкликати втрачений ключ та й опцій генерації стає більше. Найбільш популярні програми менеджменту ключів – це Kleopatra та консольне рішення gpg.
Якщо на машині до цього не було створено жодних PGP ключів, то при запуску Клеопатра запропонує їх створити або імпортувати. На імпорті зупинятись не будемо, бо там все інтуїтивно зрозуміло, а ось на деякі моменти створення ключів хотілося б звернути увагу.
Внизу відразу натискаємо на Advanced Settings і бачимо, що пропонують різноманітні варіанти алгоритмів.
У принципі, допустимо залишаємо все по-дефолту. Докладніше про наведені алгоритми можна прочитати у розділі нижче. Також звертаємо увагу на галочку Valid until. Залежно від конкретного випадку її можна прибрати або залишити. Тиснемо Create, після чого Клеопатра запропонує зробити бекап приватного ключа, від чого рекомендуємо не відмовлятися.
Щоб отримати публічний ключ, достатньо вибрати потрібну пару зі списку та натиснути велику кнопку Export. Важливо відзначити, що Клеопатра не надсилає публічний ключ на key-сервер автоматично! Усі згенеровані програмою ключі будуть доступні виключно в межах локальної системи для програм, що підтримують роботу з PGP (наприклад gpg, Thunderbird, інші менеджери ключів). Якщо потрібно зробити публічний ключ надбанням громадськості – необхідно клацнути лівою кнопкою миші на потрібній парі зі списку та вибрати опцію Publish on server. Варто звернути увагу, що від моменту публікації до доступності публічного ключа може пройти кілька годин.
В цілому, Клеопатра є досить самодостатнім інструментом. Якщо з деяких причин немає можливості або бажання користуватися плагінами або окремими програмами для шифрування повідомлень, достатньо імпортувати в Клеопатру публічні ключі потрібних сутностей або користувачів. Маючи їх, через Notepad можна зашифрувати текст будь-яким доступним публічним ключем одержувача, і вже зашифрований текст можна надіслати будь-яким зручним способом.
У консольній версії просто gpg/gpg2. Зазвичай пакет вже є в системі, але якщо такого не знайшлося, можна використовувати команду
sudo apt install gnupg
Сама утиліта має досить виразний мануал –help і man, тому тут буде наведено дуже сухий how-to.
Створення ключів може здійснюватися кількома способами:
sudo git –gen-key – попросить тільки ім’я, имейл і ввести пароль, решта параметрів буде дефолтні (алгоритм – RSA, термін придатності ключа – два роки).
sudo gpg –full-generate-key – надає більше гнучкості у створенні ключів, дає вибрати алгоритм шифрування, термін придатності ключів, а також як бонус – можливість залишити коментар до ключів. Остання досить корисна, якщо, наприклад, користувач має кілька ящиків і користується для них різними парами ключів. Тоді відправник може за коментарем визначити, який із відкритих ключів для якої пошти використовувати.
Після того, як ключі будуть згенеровані, вони будуть доступні лише у локальній системі. Щоб поділитись ними зі світом, потрібно вибрати key-сервер і відправити його туди. Робиться це так:
sudo gpg –send-keys KEY_FINGERPRINT або sudo gpg –keyserver KEYSERVER –send-keys KEY_FINGERPRINT
Де KEYSERVER – адреса нашого сервера (за дефолтом hkps.pool.sks-keyservers.net), а KEY_FINGERPRINT – відбиток потрібного ключа.
Дізнатися його можна через команду:
sudo gpg –list-keys
Для кращого розуміння візьмемо за приклад ключ :
pub rsa3072 2022-04-30 [SC [expires: 2024-04-29] 980A28B56D8DD95B3B954 D8A2F86AF60ED1C317 uid [ultimate] test-user-1984 <[email protected]> sub rsa3072 2022-04-30 [E] [expires: 2024-04-29]
З тим, що таке pub та sub ключі розберемося нижче, поки просто розглянемо, що нам говорить висновок.
pub/sub – тип ключа
rsa3072 – вказівка, який алгоритм використовувався для створення ключа, у нашому випадку це RSA із довжиною ключа 3072
2022-04-3 – дата створення
[SC] – usage-прапори, тому що ключі можуть використовуватися для різних цілей, навпроти них завжди вказується для чого вони призначені:C – key certificationS – sign dataE – encrypt communicationsstorageA – authentificationЗа фактом таких прапорів більше, і вони встановлюються в системі hex, але докладний розбір виходить за базові рамки курсу. За бажання глибше ознайомитися з пристроєм PGP ключів варто вивчити статтю https://davesteele.github.io/gpg/2014/09/20/anatomy-of-a-gpg-key/
[expires: 2024-04-29] – дата, коли ключ перестане вважатися дійсним, тобто. закінчиться його термін придатності
980A28B56D8DD95B3B9549D8A2F86AF60ED1C317 – фінгерпринт, унікальний відбиток ключа
uid – ID користувача, зазвичай задається ім’ям та адресою[ultimate] – статус довіри до ключа. Для згенерованих особисто він завжди буде ultimate, в той час як експортовані нові ключі можуть бути позначені як undefined, never, marginally, fully, ultimately. Всі ці статуси пов’язані з Web of Trust, про яку можна прочитати трохи нижче.
Насправді PGP досить давно відмовився від єдиної пари ключів і зараз це більше нагадує зв’язку. Якісь ключі використовуються для підпису, якісь для шифрування, треті для доступу до ресурсів. При цьому між ними є ієрархія: на чолі завжди знаходиться кореневий, перевірений та довірений ключ. Як правило, ці ключі намагаються не використовувати для шифрувань або підписів, натомість задіють створені на його основі sub-ключі. Кореневі використовуються для сертифікатів. У такому сертифікаті говориться, що такий-то юзейр або сутність є власником такого-то ключа, всі sub-ключі (наводиться список) якого також вважаються валідними і довіреними, і можуть використовуватися для того-то того-то. Навіщо так ускладнювати життя і чому не створювати для кожного конкретного випадку просту пару PGP ключів? Вся справа у пристрої Web of Trust. Щоб ключ вважався довіреним, за нього повинні поручитися ряд користувачів, і чим більше користувачів визнало ключ достовірним, тим у більшій кількості ділянок Web of Trust цей ключ буде котируватися. Якщо ж з якоїсь причини ключ потрібно буде замінити, то доведеться знову заробляти довіру, що не завжди підходить за родом завдань. Ця проблема повністю вирішується за рахунок sub-ключів. При його відкликанні або заміні, достатньо оновити дані в сертифікаті і з цього моменту новий sub-ключ буде користуватися рівнем довіри, який має кореневий ключ, а віддалений sub-ключ хоч і матиме відсилання у своєму батькові, але більше не фігуруватиме в сертифікаті і, відповідно, вважатиметься валідним.
Говорячи про PGP не можна хоча б миттєво не торкнутися теми Web of Trust. Загалом є дві основні моделі аутентифікації (перевірки справжності, дійсності) ключів/сертифікатів користувачів:
x.509 PKI – централізована система побудована на тому, що є низка ресурсів (CA – certificate authority), які видають сертифікати та яким довіряють усі учасники мережі.
Web of trust – децентралізована система, де довіра до сертифікату визначається ставленням учасників мережі до конкретного сертифіката.
