Публічні ключі GPG: формати, відбитки та перевірка

Звичайна порада щодо публічних ключів GPG починається із завантаження файла та виконання gpg --import. Це інструкція з передавання, а не перевірка особи. Завантажений ключ — твердження про його власника, а імпорт не робить це твердження правдивим.

Для команди, яка працює з підписами випусків, файлами постачальників або казначейськими дорученнями, корисний результат — не повідомлення про успішний імпорт. Це перевірений відбиток і запис у реєстрі про те, хто, яким каналом і коли його перевірив. Головна загроза — непомітне перенаправлення: використання неправильного ключа без жодних ознак проблеми, адже всі криптографічні операції й далі успішні.

Зміст

• Що містить публічний ключ GPG
  • Читайте відбиток, а не лише підпис
• Команди експорту, імпорту та перевірки
  • Контрольована послідовність підключення
• Сервери ключів і межі публічного розповсюдження
  • Правила розповсюдження для командної інструкції
• Алгоритми та розміри ключів, які варто використовувати
  • Зробіть сумісність свідомим рішенням
• Як перевірити, що ключ належить власнику
  • Перевірте, засвідчіть і зафіксуйте
  • Спільні ідентичності та заміна ключів
• Строк дії, ротація та записи про відкликання
  • Підготуйте відкликання до того, як воно знадобиться
• Контролі для командних процесів і ключів API
  • Розділяйте ідентичність, повноваження та виконання
  • Починайте аудит із практичних запитань
• Поширені запитання про публічні ключі GPG
  • Чи можна видалити ключ із сервера ключів після публікації?
  • Яким має бути строк дії ключа GPG?
  • Що робити, якщо змінився відбиток ключа партнера?
  • Чи замінює ключ GPG облікові дані API?
• Узгодьте політику перевірки до запуску
  • Застосуйте таку саму дисципліну до інфраструктури гаманців

Що містить публічний ключ GPG

Публічний ключ GPG зазвичай є передаваним сертифікатом OpenPGP, а не одним числом. Він поєднує криптографічний матеріал із твердженнями про особу, підписами та операційними ключами. GnuPG — це програмне забезпечення, а OpenPGP — формат і протокол, який воно реалізує.

Структуру сертифіката й ідентифікатори для різних версій визначає RFC 9580: відбитки версії 4 містять 40 шістнадцяткових символів, а версії 6 — 64. Ці відбитки ідентифікують ключ, але для зв’язку ключа з людиною чи організацією все одно потрібна незалежна перевірка.

Компоненти публічного ключа GPG

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

Підключ виконує окреме завдання, наприклад шифрування або підписання. Розділення цих завдань дає змогу замінити операційний підключ без обов’язкової заміни первинного ключа ідентичності.

Читайте відбиток, а не лише підпис

Короткий ідентифікатор ключа — це засіб вибору, а не авторитетне посилання на ідентичність. GnuPG рекомендує повні відбитки для автоматизованої обробки, оскільки коротші ідентифікатори можуть бути неоднозначними. Не робіть електронну адресу чи короткий ідентифікатор ключа первинним ключем у базі даних.

Виконайте gpg --list-keys --fingerprint --with-subkey-fingerprint. Знайдіть запис pub, його первинний відбиток, записи uid і кожен запис sub із власним відбитком. Зафіксуйте первинний відбиток як посилання на сертифікат і зберігайте поруч зв’язки з підключами.

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

Команди експорту, імпорту та перевірки

Замініть FINGERPRINT повним первинним відбитком. Перед виконанням будь-якої команди сервера ключів замініть SERVER на схвалений вашою командою сервер. Це заповнювачі, а не значення для копіювання без змін.

Текстове представлення ASCII armor — це кодування публічного сертифіката. Двійковий експорт переносить еквівалентний публічний вміст у нетекстовій формі; зміна кодування не створює нового ключа й не змінює його ідентичність.

Контрольована послідовність підключення

1. Перелічіть власні сертифікати. Скористайтеся командою зі списку й переконайтеся, що вибрали потрібну робочу ідентичність, а не особистий або виведений з ужитку ключ.
2. Експортуйте текстовий сертифікат. Щоб зберегти результат, а не вивести його на екран, виконайте gpg --armor --export FINGERPRINT > key.asc.
3. Відокремте доставку від підтвердження. Надішліть файл узгодженим каналом, а відбиток повідомте через незалежно встановлений спосіб зв’язку.
4. Перевірте отриманий файл командою з таблиці. Щоб явно побачити первинний відбиток і відбитки підключів, виконайте gpg --show-keys --fingerprint --with-subkey-fingerprint key.asc.
5. Імпортуйте після успішного порівняння. Виконайте команду імпорту, а до операційного використання завершіть запис про схвалення за правилами команди.

Стандартна операція --export виводить лише публічний матеріал. Експорт секретних ключів потребує окремої свідомої команди; не підміняйте ним експорт, коли хтось просить ваш публічний сертифікат.

Повідомлення про імпорт означає, що GnuPG обробив сертифікат. Воно не означає, що особу з ідентифікатора користувача автентифіковано, і не уповноважує постачальника чи працівника використовувати ключ від імені вашої компанії.

Практичне правило: вважайте роботу з файлом, перевірку особи та бізнес-схвалення окремими діями.

Для встановлення та усунення проблем зі сховищем ключів скористайтеся покроковою інструкцією з додавання ключа GPG. В інструкції фіксуйте відбиток, а не покладайтеся на key.asc, тему вкладення чи показану адресу відправника.

Сервери ключів і межі публічного розповсюдження

Сервер ключів розповсюджує публічні сертифікати, щоб інші могли їх отримати. Він не є органом перевірки особи: отримання сертифіката із сервера не доводить, що завантажувач контролює зазначену компанію, поштову скриньку чи бізнес-роль.

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

Правила розповсюдження для командної інструкції

1. Схваліть сервіс розповсюдження. Зафіксуйте адресу обраного сервера та замініть SERVER у команді перед використанням. Перевірте його політики публікації й видалення.
2. Публікуйте й отримуйте за повним відбитком, а не за результатом пошуку електронної адреси. Відповідного підпису скриньки недостатньо для вибору сертифіката.
3. Негайно розповсюджуйте відкликання. Імпортуйте відкликання в локальний сертифікат, а потім опублікуйте оновлений сертифікат тими самими каналами, що й оригінал.
4. Отримавши сертифікат, порівняйте його з незалежно підтвердженим відбитком власника до засвідчення чи схвалення для робочого режиму. Отримання із сервера ключів саме імпортує сертифікат у локальне сховище, тому не плутайте імпорт із наданням повноважень.
5. Підтримуйте контрольоване власником посилання. Опублікуйте відбиток на офіційній сторінці компанії чи підписаній сторінці випуску, зберігаючи незалежний процес підтвердження для підключення та змін.

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

Публікуйте лише ті ідентифікаційні дані, які готові поширювати відкрито. Сервер ключів — канал розповсюдження, а не етап перевірки.

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

Алгоритми та розміри ключів, які варто використовувати

Обирайте Ed25519 для підписання з підключем шифрування Curve25519, коли всі потрібні клієнти підтримують цю комбінацію. RSA використовуйте як резервний варіант для сумісності, а не тому, що більшу кількість бітів можна напряму порівняти з розміром ключа на еліптичній кривій. Ці числа описують різні криптографічні конструкції.

Емпіричне дослідження екосистеми OpenPGP повідомляє, що з 2009 року GnuPG використовував 2048-бітний RSA за замовчуванням, цей розмір залишався поширенішим приблизно до 2015 року, після чого дедалі частіше використовувався 4096-бітний RSA. У наборі даних із приблизно 5 мільйонів ключів RSA та DSA разом становили 99,75% спостережуваних алгоритмів публічних ключів. Це опис того історичного набору, а не вашої поточної інвентаризації.

Зробіть сумісність свідомим рішенням

1. Перевірте найстаріший обов’язковий клієнт. Врахуйте партнерську автоматизацію, інструменти пакування, системи відновлення й апаратні пристрої, а не лише ноутбуки інженерів.
2. Оберіть найсучасніший підтримуваний варіант і випробуйте фактичне шифрування та перевірку підпису. Успішний імпорт сам по собі не є перевіркою сумісності.
3. Зафіксуйте рішення. Запишіть у реєстрі алгоритм, розмір або криву, причину сумісності та відповідального за заміну.

DSA та ElGamal мають бути в плані міграції застарілих систем, а не в шаблоні нового ключа. Позначте сертифікати RSA-2048 і DSA для перевірки, визначте залежні від них системи й призначте дати заміни замість видалення до того, як запрацюють наступники.

Не плутайте ключі OpenPGP зі спільними мережевими секретами. Якщо команда також керує обліковими даними Wi-Fi чи VPN, корисний контекст для цієї окремої моделі дають рекомендації з безпеки PSK від Finchum Fixes IT.

Як перевірити, що ключ належить власнику

Завантажений публічний ключ — твердження, а не доказ особи. Доказ з’являється після перевірки повного відбитка незалежним каналом і фіксації того, хто та чому схвалив збіг.

Правильні команди не замінять чіткої процедури схвалення. Людина може успішно імпортувати й використовувати ключ, водночас надсилаючи конфіденційну інформацію не тому одержувачу.

Перевірте, засвідчіть і зафіксуйте

1. Отримайте повний первинний відбиток незалежно. Зателефонуйте встановленому контакту за вже відомим номером або порівняйте відбитки особисто. Номер із того самого підозрілого листа не є незалежною перевіркою.
2. Порівняйте повний відбиток символ за символом. Ігноруйте пробіли та регістр літер, але не покладайтеся на знайоме закінчення.
3. Після збігу засвідчіть локально. Якщо політика передбачає локальне засвідчення, виконайте gpg --lsign-key FINGERPRINT і виберіть лише перевірені ідентичності. Локальне засвідчення фіксує вашу перевірку; довіра до власника визначає, наскільки ви покладаєтеся на засвідчення іншої людини.
4. Додайте схвалений відбиток до командного реєстру разом із датою, особою, методом перевірки й дозволеною бізнес-метою. Збережіть достатньо доказів, щоб інший рецензент міг відтворити рішення.
5. Зупиніться, якщо відбиток несподівано змінився. Вважайте нове значення новим твердженням, яке потрібно перевірити, а не автоматичним оновленням конфігурації.

Наприклад, постачальник надсилає ключ для скриньки кредиторської заборгованості. Дзвінок фінансовому контакту за раніше відомим номером може підтвердити, хто його дозволив. Відповідь на ту саму скриньку лише перевіряє доступ до каналу, яким доставили ключ.

Спільні ідентичності та заміна ключів

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

Ключ-замінник має новий первинний відбиток. Заява, підписана старим ключем, може допомогти підтвердити безперервність, але її недостатньо, якщо причиною зміни була компрометація.

Контроль також залежить від залучених людей і каналів. Рекомендації щодо захисту облікових записів працівників від кібератак дають контекст для безпеки цих записів.

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

Строк дії, ротація та записи про відкликання

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

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

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

Підготуйте відкликання до того, як воно знадобиться

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

Щоб розповсюдити підготовлене відкликання, імпортуйте його локально й повторно опублікуйте оновлений публічний сертифікат. Не завантажуйте неактивоване аварійне відкликання лише для тесту розповсюдження, бо його застосування виводить ключ з ужитку.

• Завершення строку підключа: заміна операційного підключа може зберегти первинний відбиток. Зафіксуйте зв’язок нового підключа та розповсюдьте оновлений сертифікат.
• Звільнення працівника: за потреби відкличте особисті робочі ідентичності. Для організаційного ключа передавайте відповідальність лише після оцінювання доступу та заміни матеріалу, копію якого працівник міг зберегти.
• Автоматизоване навантаження: призначте відповідальну людину, яка може схвалювати зміни й реагувати на помилки підписання або розшифрування.

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

Аудит має з’ясовувати не лише те, чи сертифікат чинний сьогодні. Команда повинна довести, що саме вона прийняла під час конкретного обміну.

Контролі для командних процесів і ключів API

Непомітне перенаправлення виникає, коли конфіденційні дані отримує неправильний чи застарілий ключ або коли застосунок приймає підписи неуповноваженої ідентичності. Сильні алгоритми не виправлять систему, що обирає не ту уповноважену сторону.

Використовуйте повний відбиток як посилання інтеграції на сертифікат. Зберігайте версію ключа, алгоритм, час створення, стан строку дії, статус відкликання, зв’язки підключів, названого власника, дозволену мету й докази схвалення. Відокремлюйте схвалення ідентичності від дозволів застосунку.

Рекомендації NIST із керування ключами охоплюють захист ключового матеріалу та функції планування й керування криптографією. Застосовуйте це врядування: відокремлюйте публічне розповсюдження від захисту приватного ключа, документуйте повноваження на схвалення та зберігайте докази життєвого циклу.

Розділяйте ідентичність, повноваження та виконання

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

• Звужуйте дозволи облікових даних. Надайте процесу звірки доступ на читання, а не повноваження на виведення. Розділяйте облікові дані робочого й тестового режимів.
• Зробіть повторні спроби безпечними. Зберігайте один ключ ідемпотентності з кожною бізнес-операцією та повторно використовуйте його з тими самими параметрами, доки з’ясовуєте невизначений результат.
• Підготуйте аварійну заміну. Перевірте, як вимкнути облікові дані, схвалити заміну та відновити сервіс без обходу перевірки.

Документація Stripe про ідемпотентні запити пояснює, як створені клієнтом ключі позначають повторні спроби тієї самої операції. Застосовуйте це до виплат: тайм-аут означає, що результат невідомий, а не що операція не вдалася, тому не створюйте нову бізнес-операцію лише для повторення передавання.

Використовуйте події WebSocket для операційної видимості, а потім звіряйте стан із подій з операційним журналом і результатом у мережі. Сповіщення про подію саме по собі не є повним бухгалтерським записом чи доказом досягнення потрібної остаточності транзакції.

Починайте аудит із практичних запитань

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

До автоматизованих агентів застосовуйте той самий стандарт, що й до людей. Здатність агента сформувати запит не має означати необмеженого права його схвалити чи підписати.

Поширені запитання про публічні ключі GPG

Чи можна видалити ключ із сервера ключів після публікації?

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

Використайте відкликання, щоб повідомити про виведення ключа з ужитку, і сповістіть контрагентів безпосередньо. Правила в розділі Сервери ключів і межі публічного розповсюдження допомагають відрізнити видалення розміщеної копії від попередження наявних власників.

Яким має бути строк дії ключа GPG?

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

Скористайтеся плановою перевіркою з розділу Строк дії, ротація та записи про відкликання, щоб вирішити, продовжувати чи замінювати ключ. Короткий строк без працездатного процесу оновлення може спричинити зайву зупинку.

Що робити, якщо змінився відбиток ключа партнера?

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

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

Чи замінює ключ GPG облікові дані API?

Ні. OpenPGP підтримує шифрування повідомлень і перевірку підписів; його гібридна конструкція захищає дані симетричним сеансовим ключем і шифрує цей ключ для одержувачів, як описано в RFC 4880.

Облікові дані API автентифікують запити застосунку за власним протоколом і правилами авторизації API. Використовуйте контролі власності, дозволів і заміни з розділу Контролі для командних процесів і ключів API для обох випадків, не вважаючи формати чи дозволи взаємозамінними.

Узгодьте політику перевірки до запуску

Узгодьте політику схвалення до підключення ключа до робочого режиму:

• Повноваження на схвалення: визначте, хто може приймати відбитки партнерів і дозволяти заміни.
• Незалежний канал: укажіть, які встановлені способи зв’язку придатні для підтвердження.
• Графік перевірок: визначте перевірки строку дії та відповідального за прострочені дії.
• Зберігання для відновлення: зафіксуйте, де лежать сертифікати відкликання та хто може їх отримати.
• Власник реєстру: зберігайте історію схвалень там, де операційна команда, безпека й команда з відповідності мають належний доступ.

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

Застосуйте таку саму дисципліну до інфраструктури гаманців

Для платіжних, казначейських і підписних процесів BroSettlement надає орієнтовану на API інфраструктуру гаманців із DKG, відправленням у мережу та підписанням MPC 2-з-3 у 10 мережах. Частки ключа розподілено між незалежними сторонами, а контрольований клієнтом Co-Signer додає до політики підписання етап схвалення на боці клієнта; жоден власник однієї частки не може підписати самостійно.

У ширшому наборі продуктів BroWallet підтримує процеси для користувачів гаманців, а AI Agents можуть використовувати окремі гаманці для кожного агента з рольовими контролями та журналами аудиту. Поєднуйте вузькі дозволи ключів API з перевірками політик, використовуйте події WebSocket для спостереження за результатами та звіряйте незмінний операційний журнал із завершеними операціями. Автентифікація Ed25519 застосовується до кожного запиту, але вона все одно потребує явної авторизації та контролю повторних спроб.

Ці контролі зменшують ризик відмови одного ключа. Вони не замінюють перевірки відбитків партнерів, не перетворюють сертифікат GPG на облікові дані API й не скасовують обов’язок схвалити потрібного контрагента.

BroLabel пропонує модульну інфраструктуру гаманців, підписання, журналу й подій для команд, яким потрібні підзвітні фінансові операції, а не ізольований інструмент керування ключами. Відвідайте BroLabel, щоб переглянути налаштування тестового середовища й консолі, а потім перевірте політики схвалення, повторних спроб і звірки до ввімкнення підписання в робочому режимі. Bro has your back!