Concepts/OpenPGP Getting Started/uk: Difference between revisions
(Updating to match new version of source page) |
No edit summary |
||
Line 52: | Line 52: | ||
== Тип і довжина ключа == | == Тип і довжина ключа == | ||
Типами ключів з широкою підтримкою є DSA (лише для підписування), ElGamal (лише для шифрування) та RSA (для підписування і шифрування). Скоро до цих типів буде додано ECDSA (використання еліптичних кривих). У GnuPG передбачено можливість створення ключів з довжиною від 1024 до 4096 бітів. Такою є поточна ситуація станом на 2020 рік. | |||
Типами ключів з широкою підтримкою є DSA (лише для підписування), ElGamal (лише для шифрування) та RSA (для підписування і шифрування). Скоро до цих типів буде додано ECDSA (використання еліптичних кривих). У GnuPG передбачено можливість створення ключів з довжиною від 1024 до 4096 бітів. Такою є поточна ситуація станом на | |||
Відмінності у захисті, часі обробки, розмірі підпису та обов’язковості чи бажаності певних вимог до ключа у стандарті (rfc4880) для більшості сценаріїв використання є неважливими. Важливою є лише одна відмінність: у смарткартах g10 передбачено підтримку лише ключів RSA. Тому, якщо немає конкретних і важливих причин вибрати інший тип ключа, варто надавати перевагу створенню ключів RSA. 1024-бітові ключі вважаються придатними до зламу відомими державними установами за теперішнього технологічного рівня або технологічного рівня близького майбутнього. 2048-бітові ключі вважаються убезпеченими від зламу на десятиліття. Втім, слід пам’ятати: такі державні установи не будуть витрачати свого часу і грошей на спроби зламати ваш ключ. Їм простіше його викрасти. Тому, якщо вибравши довший ключ, ви хочете захиститися від установ такого рівня, вам слід подбати про те, щоб ключ було важко викрасти. Заходи з убезпечення ключа потребують глибоких знань, дисципліни та, ймовірно, певних грошових вкладень. Практичним обмеженням на довжину ключа є те, що у розповсюджених версіях GnuPG не передбачено підтримки ключів з довжиною, більшою за 2048 або 3072 бітів. Робота з асиметричними ключами потребує доволі потужного обладнання. Простіше: збільшення довжини ключа удвічі призведе до збільшення часу обробки даних у вісім разів. Створення довших ключів є також тривалішим. Для мобільних пристроїв подібне навантаження на процесор може виявитися основною проблемою. | Відмінності у захисті, часі обробки, розмірі підпису та обов’язковості чи бажаності певних вимог до ключа у стандарті (rfc4880) для більшості сценаріїв використання є неважливими. Важливою є лише одна відмінність: у смарткартах g10 передбачено підтримку лише ключів RSA. Тому, якщо немає конкретних і важливих причин вибрати інший тип ключа, варто надавати перевагу створенню ключів RSA. 1024-бітові ключі вважаються придатними до зламу відомими державними установами за теперішнього технологічного рівня або технологічного рівня близького майбутнього. 2048-бітові ключі вважаються убезпеченими від зламу на десятиліття. Втім, слід пам’ятати: такі державні установи не будуть витрачати свого часу і грошей на спроби зламати ваш ключ. Їм простіше його викрасти. Тому, якщо вибравши довший ключ, ви хочете захиститися від установ такого рівня, вам слід подбати про те, щоб ключ було важко викрасти. Заходи з убезпечення ключа потребують глибоких знань, дисципліни та, ймовірно, певних грошових вкладень. Практичним обмеженням на довжину ключа є те, що у розповсюджених версіях GnuPG не передбачено підтримки ключів з довжиною, більшою за 2048 або 3072 бітів. Робота з асиметричними ключами потребує доволі потужного обладнання. Простіше: збільшення довжини ключа удвічі призведе до збільшення часу обробки даних у вісім разів. Створення довших ключів є також тривалішим. Для мобільних пристроїв подібне навантаження на процесор може виявитися основною проблемою. |
Latest revision as of 16:00, 7 September 2020
Вступ
Під час створення ключа ви приймаєте декілька технічних та організаційних рішень (знаєте ви про це чи ні), які значно впливають на захист та придатність до користування вашого ключа, а отже і на строк придатності цього ключа. Деякі з цих рішень після створення ключа вже не можна змінити. З декількох причин бажано, щоб звичайні ключі, навіть доволі незахищені, принаймні у основній частині мали довгий строк придатності.
Отже, у цій статті ми познайомимося з важливими аспектами створення ключів. Стаття допоможе вам створити якісний ключ, яким ви зможете користуватися багато років. У цій статті ви знайдете лише загальні поняття, з якими варто бути ознайомленими. У ній не викладено покрокової процедури створення ключа, оскільки саму процедуру слід відокремити: спочатку слід чітко зрозуміти основні принципи, спланувати ваші дії, а потім вже виконати необхідні приготування. Якщо ви вже знайомі з усіма потрібними поняттями і усе вже спланували, зверніться до статті, присвяченої створенню ключа OpenPGP.
Перші кроки
Створити якийсь ключ для того, щоб побавитися ним, доволі просто. Але якщо такий ключ буде прийнято і підтверджено іншими користувачами, ви ризикуєте у майбутньому втратити результати вашої роботи. Вашою метою має бути створення одного або декількох довготермінових ключів. Найкращою порадою у такій ситуації буде: якщо це можливо, не намагайтеся усе зробити самостійно. Якщо можна, зверніться до експертів, людей, які вже міняли власний ключ і багато чому з цього навчилися. Користуйтеся безпечними системами для створення ключів, зберігайте основний ключ у безпечному місці без доступу з мережі і вкажіть для основного ключа і підключів строк дії (цей строк не повинен перевищувати року). Визначте правила поводження з ключами (у цих правилах має бути описано захист і прийоми користування основним ключем і підключами) і дотримуйтеся цих правил. Якщо ви виконуєте сертифікацію ключів сторонніх осіб до створення правил сертифікації, не виконуєте повної сертифікації (сертифікації для мережі довіри), замість цього виконайте локальне підписування (лише для вас). Уникайте виконання нових для вас дій, доки добре не зрозумієте їх наслідки.
І пам’ятайте:
- Усе, що здається зручним (принаймні на перший погляд), становить загрозу вашим даним.
- Чим більше захисту, тим краще. Зважайте на можливі наслідки (ця порада працює і у зворотний бік: чим важливішими є дані, тим кращим має бути захист).
Вітаємо вас у світі криптографії!
Захист ключів
Якщо ви маєте справу з ключами, основним питанням є таке: наскільки безпечним та надійним є самі ключі та використання цих ключів? Найважливішим правилом у криптографії є не «зробити це ще безпечнішим», а «(1) Обдумайте, наскільки високий рівень безпеки вам потрібен. (2) Вирішіть, які технічні зусилля необхідні (нижня межа) та достатні (верхня межа) для встановлення цього рівня безпеки. (3) Виконайте строгий аналіз визначених вами правил (запишіть ці правила). (4) Якщо питання захисту стосується інших людей (так, зазвичай, і трапляється), надайте їм точні і безпечні відомості щодо обмежень у використанні та рівня безпеки ключа.» Більшу частину викладеної нижче статті присвячено безпеці і прозорості відомостей щодо захисту і призначення ключів.
Ніхто тепер не зламує ключі за допомогою простого перебирання. Такий злам (навіть для доволі коротких ключів, наприклад 1024-бітових) просто неможливий найближчими десятиліттями для будь-кого, окрім урядових установ якоїсь з «багатих» країн. Крім того, подібний злам не має сенсу: ключ простіше викрасти. З величезною ймовірністю, система, якою ви користуєтеся для читання цього тексту (якщо цей текст не надруковано) не є дуже безпечною. Фактично, жодна з систем, що використовуються для читання електронної пошти або сторінок інтернету, не є безпечною. Не сперечайтеся, це правда. Якщо ви не погодитеся з цим, ви просто обманюватимете себе. Ключ ніколи не буде захищенішим за найменш безпечну систему, на якій він використовується (це, звичайно ж, стосується і системи, де ключ було створено). І цей же ключ безпечніший за найнезахищенішу систему, на якій цей ключ зберігається з доступом у формі пароля, який не захищено від прямого перебирання, якщо цей пароль не є насправді випадковим і складається з менше ніж 16 символів (малих і великих літер та цифр).
Використовувати OpenPGP на таких незахищених системах (тобто звичайних комп’ютерах) можна і потрібно. Просто ви і ваші кореспонденти (!) мають чітко розуміти рівень захисту таких систем. Вищим рівнем захисту є смарткарти. Викрасти ключ зі смарткарти неможливо (втім, ним можна скористатися із шахрайською метою, якщо хтось зможе отримати керування системою, з якою з’єднано смарткарту). На ще вищому рівні над смарткартами є безпечні системи: від’єднайте жорсткий диск, вийміть усі флеш-картки USB (та інші подібні сховища даних), вимкніть мережу, завантажте систему з безпечного носія, подібного до носія портативної системи Linux на DVD (образ системи, звичайно ж, має бути отримано з надійного джерела!). Високозахищені ключі слід використовувати лише у таких безпечних середовищах (варто також використовувати ключі для шифрування лише документів у безпечних текстових форматах, зокрема у форматі звичайного тексту або HTML).
Основний ключ і підключі
У більшості ключів OpenPGP є принаймні один підключ (кожен з підключів має лише один основний ключ). Зазвичай, вам не потрібно перейматися вибором підключів: ваша програма (якщо точніше, базова програма, зазвичай GnuPG) вибере належний ключ автоматично. Основним є ключ, з яким пов’язано відбиток ключа. Основний ключ може виконувати сертифікацію таких даних: ваших власних підключів, ідентифікаторів користувачів і ідентифікаторів користувачів інших ключів. Підключі можна використовувати для виконання усіх інших завдань (в основному розшифровування та підписування), якщо ви належними чином налаштуєте ці підключі. Причиною того, що ми взагалі згадали про відмінність між цими типами ключів у цій статті, є те, що ця відмінність є важливою для створення ключів: ви можете відокремити основний закритий ключі від закритих підключів (за допомогою GnuPG; цей поділ не є частиною стандарту OpenPGP!). Підключі можна замінити пізніше, основний ключі не можна замінювати (ключ-замінник буде зовсім новим ключем, а не просто зміненим початковим ключем). Таким чином, якщо ви створите окремий основний ключ, який ви захистите дуже стійким паролем, зберігайте принаймні пароль у безпечному місці і використовуйте основний ключ (та пароль до нього) лише у безпечних середовищах, і тоді ви зможете користуватися основним ключем «вічно» (скажімо, 20 років). Це важливо для ключів повсякденного використання. Високозахищені ключі не потребують такого відокремлення (зазвичай, такі ключі взагалі не потребують підключів). Вам слід створити один підключ для кожного з завдань, які ви маєте намір виконувати: шифрування, підписування та, можливо, розпізнавання (для SSH).
Безпечне середовище
Ключ має бути створено у безпечному середовищі, а основний закритий ключ ніколи не слід використовувати у незахищеному середовищі. Але що ж таке безпечне середовище? Відповідь на це питання залежить від рівня захисту ключа. Якщо вам потрібно убезпечити коди запуску ракет з ядерними боєголовками, вимоги до обладнання та програмного забезпечення мають бути вищими за вимоги до убезпечення ваших ділових секретів.
За будь-яких умов, у такому безпечному середовищі завантаження не повинне відбуватися зі звичайного вінчестера (за ідеальних умов, вам слід від’єднати вінчестер). Слід завантажувати систему лише з надійного носія, придатного лише для читання даних. Таким носієм, зазвичай, є компакт-диск або DVD з Linux. Вам слід приділити увагу тому, щоб образ системи було отримано з безпечного джерела. Отримання образу системи з інтернету і записування його на порожній носій з даними не дасть вам безпечного середовища. Надійнішим є використання друкованого компакт-диска або DVD (наприклад, диска з журналу або купленого у крамниці).
Також важливим є обладнання. Якщо комусь стане відомим, що якусь систему ви використовуєте для створення високозахищених ключів, у нього може виникнути ідея щодо додавання у систему апаратного записувача даних щодо натиснутих клавіш. Зверніть увагу на запобігання простим вадам безпеки: не давайте нікому побачити, як вводите пароль (навіть крізь вікно), або бачити шматок паперу з записаним паролем. Перезавантажуйте систему після створення кожного з ключів або (що краще) вимикайте систему і не вмикайте її перед тим, як запустите її знову, протягом трьох хвилин.
Ідентифікатори користувачів
Формально, ідентифікатори користувачів є наборами довільних рядків. Серед цих рядків має бути ім’я, необов’язковий коментар та адреса електронної пошти. Така структура надає змогу програмному забезпеченню для роботи з електронною поштою знаходити відповідний ключ для адреси отримувача (більшість програм потребує вашого підтвердження цієї дії з очевидних причин). З відкритим ключем OpenPGP (якщо точніше, сертифікатом) має бути пов’язано один ідентифікатор користувача, але таких ідентифікаторів може бути довільна кількість. Отже, ви можете використовувати той самий ключ для декількох адрес електронної пошти (це має сенс, лише якщо ці адреси має бути використано на однаковому рівні захисту). Використання декількох адрес має переваги і недоліки. Основною перевагою є те, що вам потрібно буде менше ключів, отже, у вас і інших користувачів буде менше роботи з сертифікацією. Основним недоліком є те, що ви можете відкликати ідентифікатори користувачів, але ці ідентифікатори залишаться видимими, а такі комбіновані ключі уможливлюють тривіальне з’єднання між різними ролями, зв’язок між якими ви не бажали б встановлювати: приватної особи, ділової особи, працівника установи (асоціації, політичної партії тощо). Вам варто тримати ці ролі відокремленими. Крім того, можуть бути причини відокремити адреси електронної пошти для кожної з ролей: ділова адреса (ivan.ivanenko@example.com), анонімна адреса (heejei7u@example.org), адреса для захоплень (superman17@example.org). Також, може статися, що з певними адресами ніколи не виникне потреби у використанні OpenPGP. Такі адреси, звичайно ж, не слід включати до ідентифікатора користувача. Рішення щодо додавання адреси до ключа вже не можна буде скасувати. Втім додати адресу до ключа дуже просто. Тому список адрес слід обдумати до створення ключа. Якщо щось піде не так, проблеми торкнуться меншої кількості адрес.
Варто мати спеціальний ідентифікатор користувача без прив’язування до адреси електронної пошти. Користування більшістю адрес електронної пошти не може бути вічним. Якщо ви відкличете ідентифікатор користувача, оскільки ви вже не користуєтеся певною адресою, ви втратите усі сертифікації цього ідентифікатора користувача. Але ви ніколи не зможете втратити власного імені (навіть якщо ви одружитеся або зміните прізвище, зазвичай причин відкликати ідентифікатор користувача не виникне). Отже, вам слід намагатися не втратити сертифікації ідентифікатора ключа за будь-яку ціну. Коментарем у ідентифікаторі користувача можна скористатися для інструкцій щодо самого ключа: «повсякденний ключ з безпечним автономним основним ключем та правилами використання ключа».
Тип і довжина ключа
Типами ключів з широкою підтримкою є DSA (лише для підписування), ElGamal (лише для шифрування) та RSA (для підписування і шифрування). Скоро до цих типів буде додано ECDSA (використання еліптичних кривих). У GnuPG передбачено можливість створення ключів з довжиною від 1024 до 4096 бітів. Такою є поточна ситуація станом на 2020 рік.
Відмінності у захисті, часі обробки, розмірі підпису та обов’язковості чи бажаності певних вимог до ключа у стандарті (rfc4880) для більшості сценаріїв використання є неважливими. Важливою є лише одна відмінність: у смарткартах g10 передбачено підтримку лише ключів RSA. Тому, якщо немає конкретних і важливих причин вибрати інший тип ключа, варто надавати перевагу створенню ключів RSA. 1024-бітові ключі вважаються придатними до зламу відомими державними установами за теперішнього технологічного рівня або технологічного рівня близького майбутнього. 2048-бітові ключі вважаються убезпеченими від зламу на десятиліття. Втім, слід пам’ятати: такі державні установи не будуть витрачати свого часу і грошей на спроби зламати ваш ключ. Їм простіше його викрасти. Тому, якщо вибравши довший ключ, ви хочете захиститися від установ такого рівня, вам слід подбати про те, щоб ключ було важко викрасти. Заходи з убезпечення ключа потребують глибоких знань, дисципліни та, ймовірно, певних грошових вкладень. Практичним обмеженням на довжину ключа є те, що у розповсюджених версіях GnuPG не передбачено підтримки ключів з довжиною, більшою за 2048 або 3072 бітів. Робота з асиметричними ключами потребує доволі потужного обладнання. Простіше: збільшення довжини ключа удвічі призведе до збільшення часу обробки даних у вісім разів. Створення довших ключів є також тривалішим. Для мобільних пристроїв подібне навантаження на процесор може виявитися основною проблемою.
Підсумок: якщо у вас немає конкретної і важливої причини для прийняття іншого рішення, використовуйте 2048-бітові ключі (принаймні для ключів повсякденного використання).
Строк дії ключа
Основним ключем може встановлюватися (і змінюватися) строк дії для самого цього ключа та його підключів. Єдиним недоліком встановлення строку дії для інших користувачів ключа є те, що їм доведеться оновлювати ключ для підтримання його працездатності. Але ключі слід регулярно оновлювати за будь-яких умов, отже це можна також вважати перевагою. Основною перевагою встановлення строку дії (також і для основного ключа) є те, що ключі, які вже не використовуються, можна легко відрізнити від тих, які ще використовуються. «Офіційний» шлях, звичайно ж, є іншим. Якщо ключ визнається нечинним, слід оприлюднити сертифікат відкликання. Втім, таке оприлюднення може бути неможливим (втрачено ключ або пароль, сертифікат відкликання не було створено (або також втрачено)) або ви можете просто забути про це (або оприлюднити сертифікат всюди). «Належний» період чинності є компромісом між зменшенням об’єму проблем, пов’язаних із застаріванням ключів (з обох боків: не забувайте, що для зміни строку дії основного ключа вам доведеться користуватися безпечним середовищем), та часом, протягом якого ключ може залишатися чинним. Строк дії у один рік має бути непоганим вибором.
Сертифікат відкликання
Сертифікат відкликання є файлом (або відбитком на папері), який ви можете створити попередньо для наступного відкликання усього ключа, якщо ви втратите доступ до основного ключа. Ця можливість є дуже корисною, якщо втрату вами доступу до ключа буде поєднано з отриманням цього доступу іншою особою! Недоліком є те, що вам слід захистити цей файл або відбиток на папері у спосіб, подібний до способу захисту основного закритого ключа. Втрата сертифіката відкликання може завдати вам значної шкоди, якщо у вас є лише один ключ, вам він терміново потрібен, а хтось знищує його за допомогою сертифікат відкликання. Очевидно, відкликання основного ключа не можна скасувати (його не можна скасувати новішим самопідписуванням ключа).
Якщо ви (або хтось інший, кому ви справді довіряєте) має інший ключ, який є достатньо безпечним, ви можете додати ключ як підписаний ключ для відкликання вашого (вам не потрібно це оприлюднювати). Підписаний ключ відкликання може відкликати інший ключ. Звичайно ж, ви повинні мати доступ до підписування призначеним ключем для відкликання на час відкликання. Якщо ви не передасте цей ключ комусь іншому і втратите його разом з вашим ключем, цим способом не вдасться скористатися. Якщо ви надаєте перевагу безпеці перед доступністю відкликання, ви можете надати право підписаного відкликання вашому першому другу, зашифрувати підпис відкликання для вашого другого друга і передати зашифровані дані для зберігання третьому другові.
Пароль, безпечне сховище і резервні копії
Вам слід слід обдумати те, де ви зберігатимете пароль до основного ключа та файл або відбиток на папері сертифіката відкликання. Безпечні паролі важко запам’ятовувати. Найімовірніше, ви його десь запишете. Категорично не радимо вам використовувати пароль, який ви будь-коли використовували у незахищеній системі (і, звичайно ж, вам не слід використовувати цей пароль будь-де у майбутньому). Вам слід вибрати щось подібне до rsbBwNl137LcWP33RI: 18 символів з використанням малих і великих літер та цифр. Не використовуйте символів кирилиці або символів з акцентами. Додаткового захисту це не додасть (якщо ви не можете запам’ятати 18 випадкових символів, ви, ймовірно, не зможете запам’ятати і 15), а лише може додати проблем, якщо вам раптом знадобиться скористатися ключем у системі для відновлення даних (Linux у текстовому режимі), де введення «неправильних» символів буде проблематичним. Ви покращите захист, якщо запам’ятаєте частину пароля і запишете лише його решту або запишете половинки пароля окремо і зберігатимете їх у різних місцях (наприклад, один зберігатимете у гаманці, а — інший вдома). Втім, якщо ви зберігаєте дві частини пароля у 18 символів, і зловмисник отримає доступ до однієї з цих половинок, решта 9 символів уже не зможуть забезпечити належний захист. Якщо вами було створено сертифікат відкликання, вам слід також зберігати його у безпечному місці.
І, звичайно ж, вам слід мати надійні резервні копії вашого ключа. Добре, якщо вам не слід перейматися тим, що ваш ключ буде кимось викрадено, але буде дуже прикро, якщо ви не зможете розшифрувати власноруч зашифровані дані. Якщо ваш ключ захищено паролем, ви навіть можете зберігати ваш закритий основний ключ на вашому сайті у інтернеті.
Правила поводження з ключем та адреса правил
Вам слід створити документ (текстовий або у форматі HTML), у якому буде описано призначення та захист вашого ключа та (можна додати пізніше) ваші критерії щодо сертифікації ключів інших людей. Ви можете записати одну або декілька адрес, за якими цей документ пізніше можна буде знайти, до ключа та до кожного створеного з його допомогою підпису. Цей ключовий компонент називається адресою правил. Вам варто оприлюднювати лише ті підписи ідентифікаторів користувачів, які містять адреси правил. Важливо, щоб користувачі вашого ключа могли перевірити, чи певний документ належить до правил (сервер у інтернеті не є достатньо безпечним місцем, навіть сервер з підтримкою HTTPS). Тому вам слід змінювати адресу правил кожного разу, коли ви вноситиме зміни до документа і вказувати адресу у видимому місці документа. Ви можете скористатися таким зразком: http://ваш_домен.приклад.org/openpgp/0x12345678__policy.1.html Цей документ має містити окремий файл підпису (або текстовий підпис, якщо документ є текстовим) основним ключем. Вам слід додати до документа посилання на окремий файл підпису.
Пріоритетний сервер ключів
До ключа, подібно до адреси правил, може бути записано адресу сервера ключів. Вам слід вирішити, який сервер ключів має бути уповноважено на керування вашим ключем, щоб користувачі вашого ключа знали, де слід шукати «офіційну поточну версію» вашого ключа. Це має бути сервер ключів, на який ви першим вивантажуєте ключ. Це також має бути сервер, який ви налаштували у вашому файлі налаштувань GnuPG (--keyserver
) для пошуку і вивантаження ключів. Адреса сервера має бути доступною увесь час або принаймні бути недоступною протягом коротких періодів часу. Ви навіть можете скористатися вашим власним сайтом: http://ваш_домен.приклад.org/openpgp/0x12345678.asc
Доступність відкритого ключа покращиться, якщо ви скористаєтеся пулом серверів (з однією адресою DNS). Якщо інших варіантів немає, ви можете скористатися hkp://pool.sks-keyservers.net або одного з локальних пулів: hkp://eu.pool.sks-keyservers.net (Європа), hkp://na.pool.sks-keyservers.net (Північна Америка) або hkp://sa.pool.sks-keyservers.net (Південна Америка). Повний список можна знайти за цією адресою: http://sks-keyservers.net/overview-of-pools.php
Пріоритет алгоритму
Ви також можете записати до вашого ключа (для інших користувачів) та до вашого файла налаштувань (для ваших власних дій) дані щодо пріоритетності використання алгоритмів шифрування та обчислення контрольних сум. Зробити це слід до створення ключа (так простіше, ніж потім вносити зміни). Не варто використовувати алгоритм SHA-1. Будь ласка, зверніть увагу на те, що ви не можете заборонити GnuPG створювати підписи SHA-1 за допомогою вашого ключа (оскільки це єдиний алгоритм обчислення контрольних сум, передбачений стандартом). Вам варто додати до вашого файла gpg.conf рядки подібні до наведених нижче:
personal-cipher-preferences AES256,AES192,AES,CAST5,3DES personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1 cert-digest-algo SHA512 default-preference-list AES,AES256,AES192,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP