Concepts/OpenPGP Getting Started/uk

Вступ

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

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

Перші кроки

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

І пам’ятайте:

1. Усе, що здається зручним (принаймні на перший погляд), становить загрозу вашим даним.
2. Чим більше захисту, тим краще. Зважайте на можливі наслідки (ця порада працює і у зворотний бік: чим важливішими є дані, тим кращим має бути захист).

Вітаємо вас у світі криптографії!

Захист ключів

Якщо ви маєте справу з ключами, основним питанням є таке: наскільки безпечним та надійним є самі ключі та використання цих ключів? Найважливішим правилом у криптографії є не «зробити це ще безпечнішим», а «(1) Обдумайте, наскільки високий рівень безпеки вам потрібен. (2) Вирішіть, які технічні зусилля необхідні (нижня межа) та достатні (верхня межа) для встановлення цього рівня безпеки. (3) Виконайте строгий аналіз визначених вами правил (запишіть ці правила). (4) Якщо питання захисту стосується інших людей (так, зазвичай, і трапляється), надайте їм точні і безпечні відомості щодо обмежень у використанні та рівня безпеки ключа.» Більшу частину викладеної нижче статті присвячено безпеці і прозорості відомостей щодо захисту і призначення ключів.

Ніхто тепер не зламує ключі за допомогою простого перебирання. Такий злам (навіть для доволі коротких ключів, наприклад 1024-бітових) просто неможливий найближчими десятиліттями для будь-кого, окрім урядових установ якоїсь з «багатих» країн. Крім того, подібний злам не має сенсу: ключ простіше викрасти. З величезною ймовірністю, система, якою ви користуєтеся для читання цього тексту (якщо цей текст не надруковано) не є дуже безпечною. Фактично, жодна з систем, що використовуються для читання електронної пошти або сторінок інтернету, не є безпечною. Не сперечайтеся, це правда. Якщо ви не погодитеся з цим, ви просто обманюватимете себе. Ключ ніколи не буде захищенішим за найменш безпечну систему, на якій він використовується (це, звичайно ж, стосується і системи, де ключ було створено). І цей же ключ безпечніший за найнезахищенішу систему, на якій цей ключ зберігається з доступом у формі пароля, який не захищено від прямого перебирання, якщо цей пароль не є насправді випадковим і складається з менше ніж 16 символів (малих і великих літер та цифр).

Використовувати OpenPGP на таких незахищених системах (тобто звичайних комп’ютерах) можна і потрібно. Просто ви і ваші кореспонденти (!) мають чітко розуміти рівень захисту таких систем. Вищим рівнем захисту є смарткарти. Викрасти ключ зі смарткарти неможливо (втім, ним можна скористатися із шахрайською метою, якщо хтось зможе отримати керування системою, з якою з’єднано смарткарту). На ще вищому рівні над смарткартами є безпечні системи: від’єднайте жорсткий диск, вийміть усі флеш-картки USB (та інші подібні сховища даних), вимкніть мережу, завантажте систему з безпечного носія, подібного до носія портативної системи Linux на DVD (образ системи, звичайно ж, має бути отримано з надійного джерела!). Високозахищені ключі слід використовувати лише у таких безпечних середовищах (варто також використовувати ключі для шифрування лише документів у безпечних текстових форматах, зокрема у форматі звичайного тексту або HTML).

Основний ключ і підключі

У більшості ключів OpenPGP є принаймні один підключ (кожен з підключів має лише один основний ключ). Зазвичай, вам не потрібно перейматися вибором підключів: ваша програма (якщо точніше, базова програма, зазвичай GnuPG) вибере належний ключ автоматично. Основним є ключ, з яким пов’язано відбиток ключа. Основний ключ може виконувати сертифікацію таких даних: ваших власних підключів, ідентифікаторів користувачів і ідентифікаторів користувачів інших ключів. Підключі можна використовувати для виконання усіх інших завдань (в основному розшифровування та підписування), якщо ви належними чином налаштуєте ці підключі. Причиною того, що ми взагалі згадали про відмінність між цими типами ключів у цій статті, є те, що ця відмінність є важливою для створення ключів: ви можете відокремити основний закритий ключі від закритих підключів (за допомогою GnuPG; цей поділ не є частиною стандарту OpenPGP!). Підключі можна замінити пізніше, основний ключі не можна замінювати (ключ-замінник буде зовсім новим ключем, а не просто зміненим початковим ключем). Таким чином, якщо ви створите окремий основний ключ, який ви захистите дуже стійким паролем, зберігайте принаймні пароль у безпечному місці і використовуйте основний ключ (та пароль до нього) лише у безпечних середовищах, і тоді ви зможете користуватися основним ключем «вічно» (скажімо, 20 років). Це важливо для ключів повсякденного використання. Високозахищені ключі не потребують такого відокремлення (зазвичай, такі ключі взагалі не потребують підключів). Вам слід створити один підключ для кожного з завдань, які ви маєте намір виконувати: шифрування, підписування та, можливо, розпізнавання (для SSH).

Безпечне середовище

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

За будь-яких умов, у такому безпечному середовищі завантаження не повинне відбуватися зі звичайного вінчестера (за ідеальних умов, вам слід від’єднати вінчестер). Слід завантажувати систему лише з надійного носія, придатного лише для читання даних. Таким носієм, зазвичай, є компакт-диск або DVD з Linux. Вам слід приділити увагу тому, щоб образ системи було отримано з безпечного джерела. Отримання образу системи з інтернету і записування його на порожній носій з даними не дасть вам безпечного середовища. Надійнішим є використання друкованого компакт-диска або DVD (наприклад, диска з журналу або купленого у крамниці).

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

Ідентифікатори користувачів

Формально, ідентифікатори користувачів є наборами довільних рядків. Серед цих рядків має бути ім’я, необов’язковий коментар та адреса електронної пошти. Така структура надає змогу програмному забезпеченню для роботи з електронною поштою знаходити відповідний ключ для адреси отримувача (більшість програм потребує вашого підтвердження цієї дії з очевидних причин). З відкритим ключем OpenPGP (якщо точніше, сертифікатом) має бути пов’язано один ідентифікатор користувача, але таких ідентифікаторів може бути довільна кількість. Отже, ви можете використовувати той самий ключ для декількох адрес електронної пошти (це має сенс, лише якщо ці адреси має бути використано на однаковому рівні захисту). Використання декількох адрес має переваги і недоліки. Основною перевагою є те, що вам потрібно буде менше ключів, отже, у вас і інших користувачів буде менше роботи з сертифікацією. Основним недоліком є те, що ви можете відкликати ідентифікатори користувачів, але ці ідентифікатори залишаться видимими, а такі комбіновані ключі уможливлюють тривіальне з’єднання між різними ролями, зв’язок між якими ви не бажали б встановлювати: приватної особи, ділової особи, працівника установи (асоціації, політичної партії тощо). Вам варто тримати ці ролі відокремленими. Крім того, можуть бути причини відокремити адреси електронної пошти для кожної з ролей: ділова адреса ([email protected]), анонімна адреса ([email protected]), адреса для захоплень ([email protected]). Також, може статися, що з певними адресами ніколи не виникне потреби у використанні OpenPGP. Такі адреси, звичайно ж, не слід включати до ідентифікатора користувача. Рішення щодо додавання адреси до ключа вже не можна буде скасувати. Втім додати адресу до ключа дуже просто. Тому список адрес слід обдумати до створення ключа. Якщо щось піде не так, проблеми торкнуться меншої кількості адрес.

Варто мати спеціальний ідентифікатор користувача без прив’язування до адреси електронної пошти. Користування більшістю адрес електронної пошти не може бути вічним. Якщо ви відкличете ідентифікатор користувача, оскільки ви вже не користуєтеся певною адресою, ви втратите усі сертифікації цього ідентифікатора користувача. Але ви ніколи не зможете втратити власного імені (навіть якщо ви одружитеся або зміните прізвище, зазвичай причин відкликати ідентифікатор користувача не виникне). Отже, вам слід намагатися не втратити сертифікації ідентифікатора ключа за будь-яку ціну. Коментарем у ідентифікаторі користувача можна скористатися для інструкцій щодо самого ключа: «повсякденний ключ з безпечним автономним основним ключем та правилами використання ключа».

Тип і довжина ключа

Типами ключів з широкою підтримкою є DSA (лише для підписування), ElGamal (лише для шифрування) та RSA (для підписування і шифрування). Скоро до цих типів буде додано ECDSA (використання еліптичних кривих). У GnuPG передбачено можливість створення ключів з довжиною від 1024 до 4096 бітів. Такою є поточна ситуація станом на 2013 рік.

The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem.

Підсумок: якщо у вас немає конкретної і важливої причини для прийняття іншого рішення, використовуйте 2048-бітові ключі (принаймні для ключів повсякденного використання).

Строк дії ключа

The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice.

Сертифікат відкликання

A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature).

If you (or someone else you really trust) have another key which is secure enough then you may add this key as a designated revoker to yours (you need not publish this). A designated revoker can revoke another key. Of course, the signature for the designated revoker must be available when this shall be used. If you have not given it to the other person and lost it together with your key then this is useless. If you prefer security over availability then you may make friend A your designated revoker, encrypt this signature for friend B and ask friend C to store it.

Пароль, безпечне сховище і резервні копії

You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too.

And, of course, you should have reliable backups of your key. It is nice if you need not be afraid that somebody has stolen your key but it is probably very unpleasant if you cannot decrypt your data any more. If you have a secure passphrase then you may even put a backup of your secret main key on your web site.

Правила поводження з ключем та адреса правил

You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: http://yourdomain.example.org/openpgp/0x12345678__policy.1.html This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document.

Пріоритетний сервер ключів

Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (--keyserver) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: http://yourdomain.example.org/openpgp/0x12345678.asc

Availability is improved if a server pool (with the same DNS address) is used. If you have no better idea then you may use hkp://pool.sks-keyservers.net or one of the more local pools hkp://eu.pool.sks-keyservers.net (Europe), hkp://na.pool.sks-keyservers.net (North America) or hkp://sa.pool.sks-keyservers.net (South America). See http://sks-keyservers.net/overview-of-pools.php

Пріоритет алгоритму

You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your gpg.conf (due to design flaws AES256 and AES192 are less secure than AES(128) is currently believed to be...):

personal-cipher-preferences AES,AES256,AES192,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

Інші корисні статті

• KGpg

• KMail PGP/MIME

• KMail gpg

• OpenPGP для початківців

• OpenPGP для досвідчених користувачів