Цифровые подписи и их проверка

Цифровая подпись удостоверяет создателя и дату создания документа. Если документ будет каким-либо образом изменен, то проверка цифровой подписи будет неудачной. Цифровая подпись может использоваться в тех же целях, что и обычная подпись. Исходные тексты GnuPG, например, подписаны, и Вы можете убедиться, что они дошли до Вас неизменёнными.

Создание и проверка подписей отличается от зашифрования/расшифрования. При подписи документа используется закрытый ключ подписывающего, а проверяется подпись с использованием его открытого ключа. Например, Alice использует свой секретный ключ, чтобы подписать свою новую статью в журнал. Редактор, получив письмо, использует открытый ключ Alice, чтобы проверить, что письмо действительно от Alice и не было изменено за время пересылки.

Для подписи документов используется команда --sign.

alice% gpg --output doc.sig --sign doc You need a passphrase to unlock the secret key for user: "Alice (test key) <alice@wonderland.uk>" 1024-bit RSA key, ID B115BDB6, created 2002-05-01 Enter passphrase:

Если не указать подписываемый документ, то данные считываются со стандартного ввода. Перед подписью документ сжимается. Подписанный документ выводится в двоичном формате.

Имея подписанный документ, Вы можете либо только проверить подпись, либо проверить подпись и восстановить исходный документ. Для проверки подписи используется команда --verify. Для проверки подписи и извлечения документа используется команда --decrypt.

blake% gpg --output doc --decrypt doc.sig gpg: Signature made Sat May 4 19:04:21 2002 MSD using RSA key ID B115BDB6 gpg: Good signature from "Alice (test key) <alice@wonderland.uk>"

Генерация новой пары ключей

Для создания первичной пары ключей используется команда --gen-key.

alice$ gpg --gen-key gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection?

GnuPG может создавать несколько разных типов ключей, но первичный ключ должен быть пригоден для создания подписи (signature). Поэтому в данном меню предлагается только три варианта. Вариант 1 создает две пары ключей. DSA - первичная, используемая только для подписи. ElGamal - подчиненная, используемая для шифрования. Вариант 2 похож, но создает только пару DSA, которая не может использоваться для шифрования. Вариант 5 создаёт пару RSA, которая может использоваться только для подписи. В любом случае, позже можно создать дополнительные подчинённые пары ключей для подписи и шифрования.

Также Вы должны выбрать размер ключа. Размер ключа DSA должен быть между 512 и 1024 бит. Ключи ElGamal и RSA могут иметь любой размер. GnuPG не допускает длину ключей менее 768 бит. Если Вы выбрали вариант 1, то размер DSA ключа полагается равным 1024 битам и запрашивается только размер ключа ElGamal.

Your selection? 1 DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)

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

Наконец, Вы должны указать срок действия ключа. В случае варианта 1, указанный срок используется для обоих ключей.

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0)

Большинству пользователей подойдет бессрочный ключ.
Срок действия следует выбирать с осторожностью; хотя можно изменить срок действия после создания ключа, не исключены проблемы с передачей изменений тем пользователям, у которых уже имеется Ваш открытый ключ.

В дополнение к параметрам ключа, Вы должны указать идентификатор пользователя. Идентификатор нужен, чтобы связать созданный ключ с конкретным лицом.

You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: Alice Email address: alice@wonderland.uk Comment: test key You selected this USER-ID: "Alice (test key) <alice@wonderland.uk>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? Для того, чтобы принять данный идентификатор введите 'O'. Если Вы хотите изменить имя, коментарий или адрес e-mail введите, соответственно, 'N', 'C' или 'E'. Ввод символа 'Q' приведёт к выходу из программы. При генерации ключа создается только один идентификатор пользователя, но возможно создание дополнительных идентификаторов, если Вы хотите использовать ключ в нескольких контекстах; например, как инженер на работе и как политический деятель после нее. Идентификатор пользователя не может быть отредактирован после создания.

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

You need a Passphrase to protect your private key. Enter passphrase: На длину пароля нет ограничений, и его следует выбирать тщательно. С точки зрения безопасности, пароль для защиты ключа очень важен в GnuPG (и других системах с открытым ключом), т.к. это Ваша единственная защита в случае, если Ваш секретный ключ попадет в чужие руки. Не следует брать слова из БСЭ, чередуйте регистр букв и используйте неалфавитные символы. Хороший пароль критичен для надежности GnuPG. При вводе пароля GnuPG не отображает вводимые символы.

Далее GnuPG генерирует ключ. В случае если в Вашей системе не очень хороший генератор случайных чисел, процедура генерации ключа может занять довольно много времени.


В некоторых случаях помогает шевеление мышкой, в некоторых настройка системы.

We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++++++++++++++++++++++.+++++++++++++++.+++++.++++++++++...+++++.+++++.++ +++++++++++++...++++++++++++++++++++.+++++...+++++..++++++++++..+++++.+++++.>+++ ++............<+++++>+++++...................................................... .+++++ We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++.++++++++++++++++++++++++++++++..++++++++++++++++++++.+++++.+++++.+++++.+++ ++.++++++++++...+++++.+++++.+++++++++++++++.+++++++++++++++...++++++++++++++++++ ++>++++++++++>..+++++........................................................... ...............................................................+++++^^^^^ gpg: /home/alice/.gnupg/trustdb.gpg: trustdb created gpg: key 5715A306 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024D/5715A306 2005-04-09 Key fingerprint = F62B 2DBE A548 8077 6AA1 088F F69B 1489 5715 A306 uid alice (test key) <alice@wonderland.uk> sub 2048g/4710371E 2005-04-09

Генерация подключа.

Если Вы при генерации ключа выбрали вариант 2 (DSA) или 5 (RSA), то имеющийся у Вас ключ может использоваться только для подписи. Для того, чтобы Ваши корреспонденты могли зашифровывать направляемые Вам сообщения, необходимо создать дополнительный ключ, который может использоваться для шифрования. Генерация дополнительного ключа осуществляется в режиме редактирования.

alice%gpg --edit-key alice@wonderland.uk Secret key is available. pub 1024R/B115BDB6 created: 2002-05-01 expires: never trust: u/u (1). Alice (test key) <alice@wonderland.uk> Command> addkey Key is protected. You need a passphrase to unlock the secret key for user: "Alice (test key) <alice@wonderland.uk>" 1024-bit RSA key, ID B115BDB6, created 2002-05-01 Please select what kind of key you want: (2) DSA (sign only) (3) ElGamal (encrypt only) (5) RSA (sign only) (6) RSA (encrypt only) Your selection?

Если Вы намерены использовать подключ для шифрования, то следует выбрать вариант 3 или 6.

Your selection? 6 What keysize do you want? (1024) Requested keysize is 1024 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct (y/n)? y Really create? y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++ ..+++++ pub 1024R/B115BDB6 created: 2002-05-01 expires: never trust: u/u sub 1024R/89D3ED33 created: 2002-05-03 expires: never (1). Alice (test key) <alice@wonderland.uk> Command> save

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

Быстрый старт

$Id: c1.xml 5 2005-10-02 16:50:06Z zwon $

GnuPG - инструмент для защиты коммуникаций. В этой главе кратко описываются основы работы с GnuPG, включая создание пары ключей, обмен ключами и их проверку, зашифрование и расшифрование документов, заверение документов цифровой подписью. Здесь не описываются в деталях принципы криптографии с открытым ключом, шифрования и цифровых подписей, эти вопросы более подробно рассмотрены в главе (желательно прочитать её до того, как Вы начнёте использовать GnuPG для практических целей). Здесь, также, не рассматриваются тонкости использования GnuPG, эти вопросы рассматриваются в главах и .

GnuPG использует криптографию с открытым ключом. Каждый пользователь имеет пару ключей (keypair), состоящую из секретного (private) и открытого (public) ключей. Секретный ключ является секретом пользователя и не может быть передан другому лицу, ни при каких обстоятельствах. Открытый ключ передается всем людям, с которыми пользователь будет обмениваться сообщениями. На самом деле GnuPG использует несколько более хитроумную схему, при которой пользователь имеет первичную пару ключей и, возможно, дополнительно несколько подчиненных. Первичный и подчиненные ключи объединены, для упрощения их использования, и эта связка, зачастую, может рассматриваться просто, как одна пара ключей.

Импорт открытого ключа

Открытый ключ может быть добавлен к связке Ваших открытых ключей при помощи команды --import.

alice% gpg --import blake.asc gpg: key 01A1FE63: public key "Blake (dumb) <blake@anywhere.ru>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) alice% gpg --list-keys /home/alice/.gnupg/pubring.gpg --------------------------------------- pub 1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk> pub 1024R/01A1FE63 2002-05-01 Blake (dumb) <blake@anywhere.ru> sub 1024R/526C7F7F 2002-05-01 [expires: 2003-05-01]

Достоверность импортированного ключа должна быть подтверждена. GnuPG использует гибкую и мощную модель проверки подлинности, не требующую, чтобы Вы лично проверяли достоверность каждого импортированного ключа. Тем не менее, достоверность некоторых ключей Вам придется проверить самому. Сначала проверяется отпечаток (fingerprint) ключа, затем ключ заверяется подписью, для подтверждения того, что он достоверен. Отпечаток ключа можно быстро просмотреть командой --fingerprint.

alice% gpg --fingerprint alice@wonderland.uk pub 1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk> Key fingerprint = DE49 CDEF 12A3 8B7B 272B A572 C73A 9987 B115 BDB6 alice% gpg --fingerprint /home/test/.gnupg/pubring.gpg ----------------------------- pub 1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk> Key fingerprint = DE49 CDEF 12A3 8B7B 272B A572 C73A 9987 B115 BDB6 pub 1024R/01A1FE63 2002-05-01 Blake (dumb) <blake@anywhere.ru> Key fingerprint = 80B8 1955 7D68 FE4F D882 DAD1 D85C 124A 01A1 FE63 sub 1024R/526C7F7F 2002-05-01 [expires: 2003-05-01]

Отпечатки ключа проверяются его владельцем. Это может быть сделано при личной встрече, по телефону, или любым другим способом, гарантирующим, что Вы общаетесь с владельцем ключа. Если отпечатки полученные Вами совпадают с указанными владельцем ключа, то можете быть уверены, что обладаете достоверной копией ключа.

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

Для подписи ключа необходимо перейти в режим редактирования ключа при помощи команды --edit-key.

alice% gpg --edit-key blake@anywhere.ru pub 1024R/01A1FE63 created: 2002-05-01 expires: never trust: -/- sub 1024R/526C7F7F created: 2002-05-01 expires: 2003-05-01 (1). Blake (dumb) <blake@anywhere.ru> Command> sign pub 1024R/01A1FE63 created: 2002-05-01 expires: never trust: -/- Primary key fingerprint: 80B8 1955 7D68 FE4F D882 DAD1 D85C 124A 01A1 FE63 Blake (dumb) <blake@anywhere.ru> How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don't know what to answer, enter "0". (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking. Your selection? 3 Are you really sure that you want to sign this key with your key: "Alice (test key) <alice@wonderland.uk>" Really sign? y GnuPG поинтересуется насколько тщательно Вы проверили достоверность ключа и попросит подтвердить Ваше желание подписать ключ. Подписав ключ, Вы можете просмотреть список подписей на ключе и увидеть там добавленную Вами. Каждый идентификатор пользователя ключа подписан самим ключом и ключом каждого пользователя, заверившего этот ключ.

Command> check uid Blake (dumb) <blake@anywhere.ru> sig!3 01A1FE63 2002-05-01 [self-signature] sig! B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>
[1] Многие, часто используемые, опции командной строки могут быть установлены в файле конфигурации.

Страницы: :: :: :: 2 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Экспорт открытого ключа

Перед тем как послать кому-либо открытый ключ, Вы должны его экспортировать. Для этого используйте команду --export. Ей требуется, дополнительно, аргумент, идентифицирующий экспортируемый открытый ключ, как и для --gen-revoke.

alice% gpg --output alice.gpg --export alice@wonderland.uk

Ключ экспортируется в двоичном формате, что бывает неудобно. GnuPG имеет опцию командной строки --armor, которая указывает на необходимость вывода в формате ASCII. Практически любой вывод GnuPG, т.е. ключи, зашифрованные документы, подписи, может происходить в формате ASCII.[1]

alice% gpg --armor --export alice@wonderland.uk -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.0 (FreeBSD) mIsEPNAu8wEEALf1zGv9/bkEKL1fTpkr0lvsmtK5Frgymlk7uInWfFdoucjAci9t wyU8HXNdFNCx1utWT5GNDD1aDhiFukc7UrFVuVbAjtOikFrZ939RrLKqOEoVd8XI ZXbgiSjs2ZqG32PpB+9X+3Z4OM64tna0NTvyqYP9LtOPHZpYGHwd5McfAAYptCZB bGljZSAodGVzdCBrZXkpIDxhbGljZUB3b25kZXJsYW5kLnVrPoiyBBMBAgAcBQI8 0C7zAhsDBAsHAwIDFQIDAxYCAQIeAQIXgAAKCRDHOpmHsRW9tvsYBACmRyUoCnj5 Awh/bFTcmsZi687ec4EzCby8OF586FAQSj4HX4LvAUc/u+4NHVbQRkKW2RJVnaHv YHUmjgteywMN3YqKd80/fbWIjyIgKNY+vgSEPMwiNMo6hR1frtfTMBnmwIWADMn0 3I1kxP2GfreSCHgy+FA3k5lrxvFnZwkXcA== =RowZ -----END PGP PUBLIC KEY BLOCK-----

Обмен ключами

Для общения с кем-либо, вы должны обменяться ключами. Просмотреть список имеющихся открытых ключей, можно используя команду --list-keys.

alice% gpg --list-keys /home/alice/.gnupg/pubring.gpg --------------------------------------- pub 1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>

Отделённая подпись

Применение подписанных документов ограниченно. Получатель должен восстанавливать документ из подписанной версии, и даже в случае прозрачной подписи, подписанный документ должен быть отредактирован для получения оригинала. Поэтому имеется третий метод подписи документов, который создает отделённую подпись (detached signature). Отделённая подпись создается при использовании команды --detach-sign.

alice% gpg --output doc.sig --detach-sign doc You need a passphrase to unlock the secret key for user: "Alice (test key) <alice@wonderland.uk>" 1024-bit RSA key, ID B115BDB6, created 2002-05-01 Enter passphrase:

Для проверки подписи необходимы и подпись, и сам документ. Для проверки используется команда --verify.

blake% gpg --verify doc.sig doc gpg: Signature made Sat May 4 19:34:08 2002 MSD using RSA key ID B115BDB6 gpg: Good signature from "Alice (test key) <alice@wonderland.uk>"

Страницы: :: :: :: :: :: 4 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Прозрачно подписанные(Clearsigned) документы

Обычно цифровые подписи применяются при подписи сообщений usenet и e-mail. При этом нежелательно сжимать подписываемые документы. Команда --clearsign добавляет к документу цифровую подпись в формате ASCII, не изменяя при этом сам документ.

alice% gpg --output doc.asc --clearsign doc You need a passphrase to unlock the secret key for user: "Alice (test key) <alice@wonderland.uk>" 1024-bit RSA key, ID B115BDB6, created 2002-05-01 Enter passphrase: alice% cat doc.asc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GnuPG - инструмент для защиты коммуникаций. Эта глава коротко описывает основы работы с GnuPG, включая создание пар ключей, обмен ключами и их проверку, зашифровку и расшифровку документов, заверение документов цифровой подписью. Она не описывает в деталях принципы криптографии с открытым ключом, шифрования и цифровых подписей. Эти вопросы рассматриваются в главе 2. Здесь, также, не рассматриваются тонкости использования GnuPG. Эти вопросы рассматриваются в главах 3 и 4. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iQCVAwUBPNP8VMc6mYexFb22AQLdAAP/SXHINHglH00hLlscGoVE1FCiFX7qTSO3 qwUFQi29WhqCXCq4DFTfZGTs4XQzb7592KpDy9swwNZ2sB7vaxQjqukffBdWrksZ ERSZsz+xxKLWPiiBURg958Nym/eIRFY7nislv9Kc4V0UFDD9CjuE0rA7eWCg1XEX 0RcI2Zxiiv4= =UV8s -----END PGP SIGNATURE-----

Создание отзывающего сертификата

После создания пары ключей, Вам следует создать отзывающий сертификат (revokation certificate) для первичного открытого ключа, используя команду --gen-revoke. Если Вы забудете пароль, либо Ваш секретный ключ будет похищен или утерян, этот сертификат может быть разослан для уведомления о том, что открытый ключ нельзя больше использовать. Отозванный открытый ключ может использоваться для проверки сделанных Вами подписей и дальше, но он не может быть использован для зашифрования сообщений для Вас. При этом, Вы сохраняете возможность расшифровывать отправленные Вам сообщения, при наличии секретного ключа.

alice% gpg --output revoke.asc --gen-revoke mykey [...]

Аргумент mykey - идентификатор Вашей первичной пары ключей или любая часть идентификатора пользователя Вашей пары ключей. В нашем случае в качестве аргумента можно указать, например: 'alice', 'alice@wonderland.uk', '5715A306'. '5715A306' -- это идентификатор ключа, он был выведен при выполнении команды --gen-key после генерации ключа (см. предыдущий раздел). Сгенерированный сертификат будет сохранен в файле revoke.asc. Если опция --output опущена, результат помещается в стандартный вывод. Кроме того, GnuPG запрашивает причину генерации отзывающего сертификата.

alice% gpg --output revoke.asc --gen-revoke alice@wonderland.uk sec 1024D/5715A306 2005-04-09 alice (test key) <alice@wonderland.uk> Create a revocation certificate for this key? y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 1 Enter an optional description; end it with an empty line: > Reason for revocation: Key has been compromised (No description given) Is this okay? y

Вы можете вывести сертификат на принтер и хранить его где-нибудь в надежном месте (банковский сейф подойдет). Сертификат ни в коем случае не должен попасть к посторонним лицам. Если сертификат попадет в чужие руки и будет опубликован, то Ваш открытый ключ утратит свое действие.

Страницы: :: :: 1 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Зашифрование и расшифрование документов

Открытый и секретный ключи, играют каждый свою роль при зашифровке и расшифровке документов. Открытый ключ можно представить как открытый сейф. Когда корреспондент зашифровывает сообщение при помощи открытого ключа, это сообщение помещается в сейф и сейф закрывается. Соответствующий закрытый ключ - комбинация, необходимая для того, чтобы открыть сейф и получить документ. Другими словами, только обладатель закрытого ключа может восстановить документ, зашифрованный соответствующим открытым ключом.

Если Вы хотите послать сообщение другу, то зашифровываете его при помощи открытого ключа друга, а тот расшифровывает его при помощи своего секретного ключа. Если друг захочет Вам ответить, то он зашифрует ответ при помощи Вашего открытого ключа, а Вы расшифруете его своим секретным.

Для зашифрования документа используется команда --encrypt. Вы должны иметь открытые ключи предполагаемых получателей. Программа ожидает в качестве параметра имя шифруемого документа или, в случае его отсутствия, шифрует стандартный ввод. Зашифрованный результат помещается в стандартный вывод, если не указана опция --output. Для повышения защиты документ дополнительно сжимается.

alice% gpg --output message.gpg --encrypt --recipient blake@anywhere.ru message.txt

Опция --recipient используется для каждого получателя и имеет аргумент, идентифицирующий открытый ключ, которым должен быть зашифрован документ. Зашифрованный документ может быть расшифрован только тем, чей секретный ключ соответствует одному из указанных открытых ключей. В частности, Вы не можете расшифровать зашифрованный Вами документ, если не включили свой открытый ключ в список получателей.

Для расшифрования сообщения используется команда --decrypt. Вам нужен секретный ключ, для которого это сообщение было зашифровано. Документ для расшифровки на входе программы, расшифрованный документ на выходе.

blake% gpg --output message.txt --decrypt message.gpg You need a passphrase to unlock the secret key for user: "Blake (dumb) <blake@anywhere.ru>" 1024-bit RSA key, ID 526C7F7F, created 2002-05-01 (main key ID 01A1FE63) Enter passphrase:

Документы, также, можно зашифровывать без открытого ключа. Вместо этого используется симметричный алгоритм для зашифровки документа. Ключ, используемый при зашифровании, образуется из ключевой фразы. Для большей безопасности эта ключевая фраза не должна совпадать с той, которую Вы используете для защиты секретного ключа. Симметричный шифр применим, когда нет необходимости обмениваться ключевой фразой. Для использования симметричного шифра применяется команда --symmetric.

alice% gpg --output message.gpg --symmetric message.txt Enter passphrase:

Страницы: :: :: :: :: 3 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Цифровые подписи.

Некоторые алгоритмы с открытым ключом могут быть использованы для подписи документов. Подписывающий генерирует подпись используя свой секретный ключ. А желающий проверить подпись, использует для этого открытый ключ подписавшего.

На практике, алгоритмы с открытым ключом непосредственно для подписи данных не используются, по тем же причинам, что и в случае с шифрованием данных. Вместо этого используется гибридная схема, т.е. алгоритм с открытым ключом используется совместно с хэш-функцией. Для подписи документа сначала вычисляется значение хэш-функции для документа, а затем это значение подписывается секретным ключом автора документа. Для проверки подлинности документа необходимо вычислить его хэш-значение и сравнить с подписанным хэш-значением. Если оба значения совпадают, то подпись верна, иначе документ был изменён.

Страницы: :: :: :: :: :: :: :: :: :: :: :: 10 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Гибридные шифры

Шифры с открытым ключом тоже имеют недостатки. Во-первых, операции зашифрования/расшифрования требуют значительно больше вычислительных ресурсов и, соответственно, выполняются медленнее, чем при использовании симметричных шифров. Во-вторых, алгоритмы с открытым ключом имеют определённые особенности, которые затрудняют их использование и делают нежелательным применение этих алгоритмов для зашифрования больших объёмов данных. Шифры с открытым ключом, тем не менее, эффективны при распространении ключей симметричных шифров и именно для этой цели они используются в гибридных криптосистемах.

Гибридный шифр использует и симметричный шифр, и шифр с открытым ключом. Сначала генерируется случайный ключ для симметричного шифра, называемый сеансовым ключом. Сообщение зашифровывается симметричным шифром с использованием сеансового ключа. Затем сеансовый ключ зашифровывается открытым ключом получателя. Сеансовый ключ, зашифрованный шифром с открытым ключом, и сообщение, зашифрованное симметричным шифром, автоматически объединяются вместе. Получатель использует свой секретный ключ для расшифровки сеансового ключа и, затем, использует полученный сеансовый ключ для расшифровки сообщения. Так как ключ симметричного шифра передаётся защищённым образом, то для каждого сообщения генерируется новый сеансовый ключ. Дополнительно, появляется возможность зашифровать сообщение сразу для нескольких получателей, при этом к сообщению, зашифрованному сеансовым ключом, добавляется несколько копий сеансового ключа, зашифрованного открытыми ключами разных получателей. И PGP и GnuPG используют именно гибридную схему.

Следует помнить, что гибридный шифр не устойчивее чем слабейший из используемых им шифров. Т.е. если используется слабый симметричный шифр, то не имеет смысла использовать шифр с открытым ключом с огромной длиной ключа.

Страницы: :: :: :: :: :: :: :: :: :: 8 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Основы криптографии

$Id: c2.xml 7 2005-10-18 21:05:13Z zwon $

GnuPG использует несколько криптографических методов, включая симметричные шифры, шифры с открытым ключом, и однонаправленное хэширование. Если Вы используете GnuPG, то Вам необходимо, хотя бы в общих чертах, понимать как работают эти методы.

Эта глава содержит краткое описание основных криптографических методов, используемых в GnuPG. Для более серьёзного знакомства с криптографией Вам следует обратиться к другим источникам. Хорошая книга, для дальнейшего изучения: . (Имеется перевод на русский язык: Б.Шнайер. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си.-М.:Издательство ТРИУМФ, 2002 - 816с.:ил.)

Хэширующие функции.

Хэширующая функция это многозначная функция H, ставящая в соответствие своему аргументу M произвольной длины значение h=H(M) фиксированной длины. Простая хэширующая функция - f(x) = 0 для всех целых x. Более интересна функция f(x) = x mod 37, которая отображает x в остаток от деления x на 37. Хэш-функции используемые в криптографических приложениях обладают следующими свойствами:

Для любого M легко вычислить его хэш-значениељ h=H(M);По известному значению h=H(M) практически невозможно определить M;Для сообщения M практически невозможно найти сообщение M' такое, что H(M)=H(M')Практически невозможно найти два случайных сообщения M и M' таких, что H(M)=H(M') љ(свойство сильной устойчивости к коллизиям).

Хэш-значение сообщения может использоваться в качестве его уникального идентификатора. Если сообщение изменить, то изменится и хэш-значение. Найти другое сообщение с точно таким же хэш-значением практически невозможно. Благодаря этому свойству хэш-функции можно использовать для проверки целостности документов и для цифровой подписи. Предположим, что Алиса отправила Бобу некоторое сообщение, и хочет быть уверена, что никто посторонний не изменит сообщение по пути к Бобу. Алиса может вычислить значение хэш-функции для сообщения и передать это значение Бобу некоторым защищённым образом (например по телефону). Боб, приняв сообщение, может вычислить его хэш-значение и сравнить с тем, которое передала Алиса. Если значения совпадут, то сообщение дошло без изменений, в противном случае сообщение было повреждено. Очевидно, что наиболее важным параметром хэш-функции является длина возвращаемого ею значения. Если эта длина n бит, то для того, чтобы найти сообщение M', имеющее такое же хэш-значение, как и M, придётся перебрать в среднем 2n-1 различных сообщений.

Свойство сильной устойчивости к коллизиям так же является очень важным. Предположим, что Чарли хочет, чтобы Алиса подписала некоторый документ, но он знает, что Алиса его ни за что не подпишет. Чарли может создать другой документ, который Алиса согласится подписать, а затем, внося случайные изменения в оба документа (например, добавляя пробелы в разных местах текста) он может найти пару разных документов с одинаковым хэш-значением перебрав всего 2n/2 вариантов[4]. После этого Чарли даёт Алисе на подпись вариант хорошего документа, а затем прилагает полученную подпись к варианту плохого документа с тем же хэш-значением.

[4] Это явление называется парадоксом дней рождений. Если Вы хотите, чтобы с вероятностью 1/2 у одного из пришедших к Вам гостей день рождения совпадал с Вашим, то придётся пригласить 253 человека. Если же Вы хотите, чтобы с вероятностью 1/2 день рождения совпадал у любых двух гостей, то достаточно пригласить только 23 человека.

Страницы: :: :: :: :: :: :: :: :: :: :: 9 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Шифры

Предположим, что Алиса хочет переслать Бобу сообщение M таким образом, чтобы никто кроме Боба не мог прочитать это сообщение. Алиса может преобразовать это сообщение в некоторую недоступную для прочтения посторонними лицами форму C=EK(M) и в таком виде переслать Бобу. Боб получив C выполняет обратное преобразование и восстанавливает исходное сообщение M=DK(C). Принято называть исходное сообщение M открытым текстом, его закрытую форму C шифртекстом, преобразование EK(M) функцией зашифрования, а DK(C) функцией расшифрования. Дополнительный параметр K функций зашифрования и расшифрования называется ключом. Преобразования E и D обычно известны и не сохраняются в тайне, но для вычисления значения DK(C) необходимо ещё знать ключ расшифрования K, соответствующий тому ключу, который был использован при зашифровании. Без знания ключа расшифровать сообщение нельзя. Значение ключа выбирается из некоторого множества допустимых значений, достаточно большого, чтобы сделать перебор всех возможных ключей практически нереализуемым.

Вместе функции зашифрования и расшифрования образуют шифр. Если в шифре ключ расшифрования совпадает с ключом зашифрования, или может быть легко из него получен, то шифр называется симметричным. Если ключ расшифрования практически невозможно получить из ключа зашифрования, то шифр называется шифром с открытым ключом или ассиметричным. В ассиметричных шифрах ключ зашифрования называется открытым (public key), а соответствующий ему ключ расшифрования секретным или закрытым (secret key, private key). Открытый и секретный ключи образуют пару ключей (keypair).

Страницы: :: :: :: :: :: :: 5 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Шифры используемые в GnuPG

В данном разделе содержатся краткие сведения об используемых в GnuPG шифрах. При выборе предпочитаемых алгоритмов шифрования следует учитывать, что в других реализациях OpenPGP некоторых из перечисленных шифров может не быть. Стандарт требует, чтобы в любой реализации имелись 3DES, DSA, ElGamal для шифрования и SHA1. Другие шифры могут отсутствовать.

Таблица 2.1. Симметричные шифры

НазваниеРазмер блока, битДлина ключа, битОписание

IDEA	64	128	IDEA (International Data Encryption Algorithm) разработали Джеймс Мэсси (James Massey) и Ксуэджа Лай (Xuejia Lai) в 1991 году. Алгоритм используется в PGP 2.x и необходим для обмена информацией с пользователями PGP 2.x. Алгоритм запатентован и поэтому в основной дистрибутив GnuPG не входит, но может быть подключен в виде модуля расширения.
3DES	64	168	3DES (Triple-DES) шифр заключающийся в троекратном шифровании с помощью алгоритма DES - американского стандарта блочного шифрования до 2002 года. Сравнительно медленный, но зато имеется в любой реализации стандарта OpenPGP (RFC 2440).
CAST5	64	128	CAST5 (CAST-128) - алгоритм описанный в RFC 2144. Обладает высокой скоростью работы. Совместим с большинством реализаций.
Blowfish	64	128	Разработан Брюсом Шнайером в 1993 году.
AES	128	128	AES (Advanced Encryption Standard). Американский стандарт блочного шифрования (FIPS PUB 197) с 2001 года, разработаный на основе алгоритма Rijndael.
AES192	128	192
AES256	128	256
Twofish	128	256	Разработан группой специалистов во главе с Брюсом Шнайером в качестве кандидата на AES.

Таблица 2.2. Алгоритмы с открытым ключом

НазваниеОписание

RSA	Алгоритм RSA разработан Рональдом Райвестом (Ronald Rivest), Ади Шамиром (Adi Shamir) и Леонардом Адлеманом (Leonard Adleman) в 1978 году. Это первый алгоритм с открытым ключом, получивший широкое распространение. Алгоритм может использоваться как для подписи, так и для шифрования.
ElGamal	Алгоритм предложил Тахер Эль-Гамаль (Taher ElGamal) в 1985 году. Алгоритм может использоваться и для подписи и для шифрования, но в реализациях алгоритма для подписей были обнаружены уязвимости и теперь алгоритм используется в GnuPG только для шифрования. ElGamal для шифрования имеется в любой реализации OpenPGP.
DSA	Алгоритм описанный в стандарте цифровой подписи США (Digital Signature Standard (DSS), FIPS PUB 186-2). Обязателен для любой реализации OpenPGP.

<
p> Длина ключа в алгоритмах с открытым ключом выбирается пользователем в зависимости от личных потребностей. Не следует использовать ключи длиной менее 1024 бит. Для DSA это максимально допустимая длина. RSA и ElGamal позволяют использовать ключи большей длины. Не следует, однако, выбирать слишком большую длину ключа, т.к. это приводит к увеличению времени шифрования и генерации/проверки подписей, увеличивает размер подписей. Не следует забывать и о том, что надёжность гибридной схемы не выше, чем у слабейшего из компонентов. Т.е., например, нет смысла использовать ключ длиной 4096 бит с хэш-функцией со значением 160 бит. Рекомендации по выбору размера ключа можно найти на сайте

Таблица 2.3. Хэш-функции

НазваниеДлина значения, битОписание

MD5	128	Хэш-функция разработанная Рональдом Райвестом. Широко распространена. В данной хэш-функции были найдены уязвимости и использовать её не рекомендуется
SHA1	160	SHA-1 (Secure Hash Algorithm). Определена стандартом США FIPS PUB 180-2. В данной хэш-функции, как и в MD5, найдены уязвимости. Отказаться от использования данной хэш-функции не представляется возможным, т.к. её использование предусмотрено стандартом DSS. Кроме того, данная функция используется в OpenPGP для вычисления отпечатков и идентификаторов ключей.
RIPEMD160	160	Разработана в рамках проекта RIPE. Используется сравнительно редко
SHA256	256	Функции определены стандартом FIPS PUB 180-2 в качестве замены SHA1 и имеют большую длину значения.
SHA384	384
SHA512	512

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: 11 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Шифры с открытым ключом

Основная проблема симметричных шифров - обмен ключами. Отправитель и получатель должны обменяться ключами, которые будут использоваться для защищенного обмена информацией, но каким защищенным каналом они могут воспользоваться для обмена самими ключами? Шифры с открытым ключом позволяют решить эту проблему. При использовании такого шифра у каждого пользователя имеется пара ключей. Один ключ открытый, его не требуется сохранять в тайне и можно передать любому другому лицу. Второй ключ секретный, который хранится только у владельца пары и ни при каких обстоятельствах не должен попасть к посторонним. Отправитель зашифровывает сообщение открытым ключом получателя, и, будучи зашифровано этим ключом, сообщение может быть расшифровано только закрытым ключом получателя.

Этот метод решает проблему обмена ключами, присущую симметричным шифрам. Отпадает необходимость договоренности о ключе между отправителем и получателем. Все что требуется, это чтобы отправитель до начала секретного обмена информацией взял копию открытого ключа получателя.[3] Кроме того, один открытый ключ может использоваться всеми корреспондентами получателя. Таким образом, только n пар ключей необходимо для n человек, переписывающихся друг с другом. Ещё одним достоинством шифров с открытым ключом является возможность их использования для цифровой подписи.

Шифры с открытым ключом основываются на некоторых математических задачах, которые могут быть легко решены при наличии определённых данных и практически неразрешимы при их отсутствии. Практически неразрешимы означает, что для решения задачи необходимы очень большие вычислительные ресурсы, которые не доступны в настоящий момент времени и в обозримом будущем. Функция зашифрования в алгоритме с открытым ключом представляет собой некоторую легко вычисляемую функцию. Однако вычисление обратной функции является очень сложной задачей, если только не известны некоторые дополнительные данные (собственно, эти данные и являются секретным ключом). Например, легко вычислить произведение двух больших простых чисел, но трудно разложить это произведение на множители.
Несложно возвести в большую степень одно число по модулю другого, но трудно вычислить логарифм по модулю. Легко вычислить квадрат числа по модулю, но трудно извлечь корень.

Как и в случае симметричных шифров, безопасность шифра с открытым ключом зависит от ключа. Так же, как и для симметричных шифров, чем больше размер ключа, тем выше защита шифра, но нельзя сравнивать длины ключей симметричных шифров и шифров с открытым ключом как меру их относительной надежности. При грубом взломе симметричного шифра с ключом длиной 128 бит, взломщик должен перебрать до 2128-1 ключей для нахождения правильного. При взломе шифра RSA с открытым ключом с длиной ключа 1024 бита, взломщик должен разложить на множители число длиной 1024 бита. В зависимости от типа шифра с открытым ключом действия взломщика сильно различаются, поэтому нельзя сравнивать даже длины ключей различных шифров с открытым ключом.

[3] На самом деле здесь тоже имеются определённые сложности. Подробности описаны в главе

Страницы: :: :: :: :: :: :: :: :: 7 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Симметричные шифры

Симметричный шифр это шифр в котором ключ расшифрования совпадает с ключом зашифрования (или может быть легко из него вычислен). Стороны, общающиеся при помощи симметричного шифра, должны договориться о ключе до начала обмена сообщениями. После того как они договорились, отправитель зашифровывает сообщение, используя ключ, отправляет получателю, и получатель расшифровывает сообщение, используя тот же самый ключ. Симметричные шифры делятся на блочные и потоковые. Блочные шифры обрабатывают данные блоками фиксированной длины, а потоковые побитно или побайтно. GnuPG использует только блочные шифры.

К достоинствам симметричных шифров можно отнести их высокую скорость работы и простоту использования для защиты данных. Недостатком симметричных шифров является сложность распространения ключей и невозможность использования их для цифровой подписи. Предположим, что Алиса хочет обмениваться данными с Бобом используя симметричный шифр, тогда она должна договориться с ним об используемом ключе. Для этого ей, скорее всего, придётся лично встретиться с Бобом, поскольку необходимо исключить вероятность попадания ключа к посторонним лицам. Если Алиса захочет переписываться с двумя десятками своих друзей, то ей придётся встретится с каждым, что может быть проблематично, особенно если друзья разбросаны по всему миру. Если друзья Алисы захотят переписываться не только с ней, но и друг с другом[2]...

Наиболее важными характеристиками блочного шифра являются длина ключа и размер блока. В общем случае, чем больше длина ключа, тем более надёжен шифр. Если длина ключа n бит, то количество возможных ключей 2n. В среднем необходимо перебрать 2n-1 ключей до нахождения правильного. GnuPG использует шифры с длиной ключа от 128 бит. 2128 это огромное число и, даже если объединить все компьютеры нашей планеты, им потребуется времени больше, чем возраст вселенной, для нахождения ключа. Однако, на практике ключ шифрования зачастую генерируется по определённому алгоритму из задаваемой пользователем ключевой фразы (пароля). В этом случае можно вместо перебора всех возможных ключей попытаться угадать или подобрать ключевую фразу, которая зачастую значительно короче, чем 128 бит. Поэтому очень важно выбирать хорошие ключевые фразы. Длина блока также важна, но она меньше влияет на надёжность шифра. Размер блока у современных шифров 64-256 бит.

[2] Если имеется группа из n человек, попарно переписывающихся друг с другом, то для каждой пары потребуется свой ключ, т.е.

ключей.

Страницы: :: :: :: :: :: :: :: 6 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Целостность ключа.

При распространении открытого ключа Вы распространяете открытые компоненты Вашего главного и подчиненных ключей и идентификаторы пользователя. Распространение этого материала, обычно, рискованно с точки зрения безопасности, т.к. делает возможной подмену ключа. Открытый ключ может быть изменен добавлением или заменой ключей, или добавлением или заменой идентификаторов пользователя. Подменой идентификатора пользователя, взломщик может изменить адрес электронной почты пользователя, чтобы получать перенаправленную ему почту. При изменении одного из ключей шифрования, взломщик сможет, также, расшифровывать перенаправленные ему сообщения.

Использование цифровых подписей решает эту проблему. Когда данные подписаны секретным ключом, соответствующий открытый ключ ограничен подписанными данными. Другими словами, только соответствующий открытый ключ может быть использован для проверки подписи и гарантирует, что данные не были изменены. Открытый ключ может быть защищен от изменения использованием соответствующего главного секретного ключа для подписи компонентов открытого ключа и идентификаторов пользователя, привязывая, таким образом, компоненты главного открытого ключа. Подпись компонентов открытого ключа соответствующим главным секретным подписывающим ключом называется самоподписью (self-signing), и открытый ключ, имеющий самоподписанные идентификаторы пользователя, привязанные к нему, называется сертификатом (certificate).

Например, у Джо есть два идентификатора пользователя и три подключа. Подписи на идентификаторах пользователя могут быть проверены командой check из меню редактирования ключа.

joe% gpg --edit-key joe Secret key is available. pub 1024R/3AA48DCE created: 2002-05-05 expires: never trust: u/u sub 1024D/13375D62 created: 2002-05-06 expires: never sub 2048G/3745CA64 created: 2002-05-06 expires: 2004-05-05 sub 1024g/015418C9 created: 2002-05-06 expires: 2004-05-05 (1) Joe Duck <joe@duck.zu> (2). Joe Duck (cook) <jd@other.mail.zu> Command> check uid Joe Duck <joe@duck.zu> sig!3 3AA48DCE 2002-05-05 [self-signature] uid Joe Duck (cook) <jd@other.mail.zu> sig!3 3AA48DCE 2002-05-06 [self-signature]

Как и ожидалось, все подписи сделаны главным подписывающим ключом с идентификатором ключа 0x3AA48DCE. Самоподписи на подключах также представлены в открытом ключе, но они не показываются в GnuPG.

Добавление и удаление компонент ключа

Как новые подключи, так и идентификаторы пользователя могут быть добавлены к Вашей паре ключей после ее создания. Идентификатор пользователя добавляется командой adduid. Вам будет выдан запрос относительно Вашего имени, адреса электронной почты и комментария, также как при создании пары ключей. Подключ добавляется командой addkey. Процедура аналогична используемой при первичном создании пары ключей. Подключ может быть подписывающим DSA ключом, ElGamal ключом пригодным только для шифрования, ключом ElGamal пригодным и для подписи и для шифрования или ключом RSA пригодным либо для подписи, либо для шифрования. Когда создаются подключ или идентификатор пользователя, они подписываются главным подписывающим ключом, при этом Вы должны ввести пароль, которым защищён главный ключ.

Дополнительные идентификаторы применимы, когда Вы выступаете в нескольких качествах. Например, Вы можете быть работником какой-либо фирмы и, в то же время, политическим деятелем. Коллеги по соответствующему виду деятельности будут знать Вас по соответствующему идентификатору. Так как эти группы людей не пересекаются, то каждая группа может не доверять другому идентификатору. Следовательно, оба идентификатора нужны.

Дополнительные подключи также могут быть полезны. Идентификаторы пользователя, ассоциированные с Вашим главным открытым ключом, заверяются другими людьми, с которыми Вы общаетесь, и смена главного ключа, следовательно, потребует переподтверждения. Это может оказаться сложным и занять много времени, если Вы общаетесь со многими людьми. С другой стороны, неплохо периодически менять подключи шифрования. Если подключ взломан, все данные, зашифрованные им, станут уязвимы. При смене подключа, уязвимой станет только часть данных.

Подключи и идентификаторы пользователя могут быть удалены. Для удаления подключа или идентификатора пользователя, Вы должны сначала выбрать его, используя команду key или uid. Это команды переключатели. Например, команда key 2 выберет второй подключ, повторная команда key 2 отменит выбор.
Если не заданы дополнительные аргументы, выбор всех подключей или идентификаторов пользователя будет отменен. Если идентификатор пользователя, который надо удалить, выбран, то команда deluid удалит его из ключа. Аналогично, команда delkey удаляет все выбранные подключи из обоих, открытого и секретного, ключей.

Для управления локальными наборами ключей, удаление компонентов ключа -- хороший способ очистить открытые ключи других людей от ненужного материала. Удаление идентификаторов пользователя и подключей из Вашего собственного ключа, однако, не всегда разумно, т.к. усложняет распространение ключа. По умолчанию, когда пользователь импортирует Ваш обновленный открытый ключ, тот объединяется со старой копией Вашего открытого ключа, если она есть в его наборе ключей. Компоненты обоих ключей объединяются, и это эффективный способ восстановить удаленные Вами компоненты. Чтобы правильно обновить ключ, пользователь должен сначала удалить старую версию Вашего ключа и только затем импортировать новую. Это добавляет мороки людям, с которыми Вы общаетесь. Кроме того, если Вы отправляете ключ на сервер ключей, объединение произойдет неминуемо, и никто из получивших Ваш ключ с сервера ключей никогда не узнает о том, что Вы что-то там удалили. Следовательно, для обновления Вашего собственного ключа лучше отозвать соответствующие компоненты ключа, нежели удалять их.

Доверие владельцу ключа

На практике доверие субъективно. Например, ключ Блэйка достоверен, т.к. Элис подписала его, но она может не быть уверена, что Блэйк правильно проверяет ключи, которые он подписывает. В этом случае, она не будет считать ключи Хлой и Дхармы достоверными, основываясь на подписи Блэйка. Модель сети доверия решает эту задачу связывая с каждым открытым ключом в Вашем наборе значение указывающее уровень Вашего доверия владельцу ключа. Имеется пять уровней доверия.

unknown (неизвестное)

Ничего не известно о политике подписания ключей данным владельцем. Ключам в Вашем наборе, кроме Вашего собственного, первоначально присваивается этот уровень доверия.

none (нет)

Известна недобросовестность этого лица при подписи чужих ключей.

marginal (граничное)

Понимает смысл подписания ключей и проверяет их достоверность перед тем, как подписывать.

full (полное)

Владелец очень разборчив в подписи ключей и тщательно проверяет их перед тем, как подписывать.

ultimate (безоговорочное)

Владельцу данного ключа Вы верите как самому себе.

Уровень доверия ключу это то, что Вы присваиваете лично, и это Ваша частная информация. Она не экспортируется с ключом; она даже хранится отдельно от ключей в специальной базе данных.

Для присвоения уровня доверия владельцу ключа используется команда trust режима редактирования ключа. В этом примере Элис редактирует уровень своего доверия Блэйку и затем обновляет базу данных доверия, чтобы пересчитать достоверность ключей основываясь на новом значении доверия Блэйку.

alice% gpg --edit-key blake pub 1024R/01A1FE63 created: 2002-05-01 expires: never trust: -/f sub 1024R/526C7F7F created: 2002-05-01 expires: 2003-05-01 (1). Blake (dumb) <blake@anywhere.ru> Command> trust pub 1024R/01A1FE63 created: 2002-05-01 expires: never trust: -/f sub 1024R/526C7F7F created: 2002-05-01 expires: 2003-05-01 (1). Blake (dumb) <blake@anywhere.ru> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately i = please show me more information m = back to the main menu Your decision? 3 pub 1024R/01A1FE63 created: 2002-05-01 expires: never trust: m/f sub 1024R/526C7F7F created: 2002-05-01 expires: 2003-05-01 (1). Blake (dumb) <blake@anywhere.ru>

Доверие владельцу ключа и достоверность ключа выводятся справа от ключа, когда выводится ключ. Доверие владельцу выводится первым, достоверность ключа второй[5]. Пять уровней доверия/достоверности обозначаются символами: неизвестный (q), нет (n), граничный (m), полный (f), безоговорочный (u). В этом случае, ключ Блэйка полностью достоверен, т.к. Элис сама подписала его. Изначально установлено неизвестное доверие относительно правильности подписи Блэйком ключей, но Элис решает установить граничный уровень доверия.

Управление ключами

$Id: c3.xml 7 2005-10-18 21:05:13Z zwon $

Подделка ключа - наиболее слабое место в криптографии с открытым ключом. Злоумышленник может изменить пользовательскую связку ключей или подделать открытый ключ пользователя и посылать его другим для загрузки и использования. Например, предположим, что Хлой хочет отслеживать сообщения, которые Элис посылает Блэйку. Она могла бы использовать атаку, называемую человек в середине (man in the middle). Для этого Хлой создает новую пару ключей. Она заменяет копию открытого ключа Блэйка, принадлежащую Элис, новым открытым ключом. Затем она перехватывает сообщения, которые Элис посылает Блэйку. Каждое перехваченное сообщение она расшифровывает, используя новый секретный ключ, зашифровывает настоящим открытым ключом Блэйка и направляет их ему. Все сообщения, направленные Элис Блэйку, теперь могут быть прочитаны Хлой.

Правильное управление ключами является решающим фактором для обеспечения целостности не только Ваших связок ключей, но и связок ключей других пользователей. Основой управления ключами в GnuPG является подписание ключей. Подписание ключей имеет два основных применения: это позволяет Вам обнаруживать вмешательство в Вашу связку ключей, а также позволяет удостоверять, что ключ действительно принадлежит человеку, чьим идентификатором пользователя он помечен. Подписи на ключах также используются в схеме известной как сеть доверия (web of trust), которая позволяет считать допустимыми не только ключи подписанные лично Вами, но и подписанные людьми, которым Вы доверяете. Аккуратные пользователи, правильно реализовавшие управление ключами, могут исключить подмену ключей как вид атаки на конфиденциальность связи при помощи GnuPG.

Использование доверия для проверки достоверности ключей

Сеть доверия позволяет использовать весьма гибкий алгоритм для проверки достоверности ключа. Если прежде достоверными считались только те ключи, которые Вы подписали лично, то теперь используется следующий алгоритм. Ключ K считается достоверным, если он удовлетворяет следующим двум условиям:

он подписан достаточным количеством достоверных ключей, т.е.

Вы подписали его лично (или обладатель ключа, которому Вы безоговорочно доверяете),

он был подписан ключом владельцу которого Вы полностью доверяете, или

он был подписан тремя ключами с граничным уровнем доверия владельцу; и

цепочка подписанных ключей начинающаяся с K и заканчивающаяся Вашим ключом не длиннее пяти ключей.

Длина цепочки, число требуемых ключей с граничным уровнем доверия и число ключей с полным доверием может быть изменено при помощи параметров --max-cert-depth, --marginals-needed и --completes-needed. Цифры приведенные выше - значения используемые GnuPG по умолчанию.

рассмотрим сеть доверия начинающуюся с Элис. Граф иллюстрирует кто подписал чей ключ. Таблица показывает ключи, которые Элис признает достоверными основываясь на доверии другим членам сети. Этот пример предполагает, что для признания другого ключа достоверным требуется два ключа с граничным доверием или один с полным. Максимальная длина цепочки равна трем.

При вычислении достоверности ключей, в этом примере, ключи Блэйка и Дхармы всегда считаются полностью достоверными, т.к. они подписаны Элис. Достоверность других ключей зависит от доверия. В первом случае, доверие Дхарме полное, что делает ключи Хлой и Фрэнсиса полностью достоверными. Во втором случае, доверие Блэйку и Дхарме граничное. Т.к. два ключа с граничным доверием требуется для подтверждения достоверности ключа, ключ Хлой будет признан полностью достоверным, но достоверность ключа Фрэнсиса будет только частично подтверждена. В случае граничного доверия Хлой и Дхарме, ключ Хлой будет частично достоверен, а ключ Дхармы полностью достоверен. Ключ Фрэнсиса будет частично достоверен, т.к.
только полностью достоверный ключ может быть использован для подтверждения достоверности других ключей, а единственный полностью достоверный ключ, которым подписан ключ Фрэнка, это ключ Дхармы. После добавления граничного доверия Блэйку ключ Хлой становится полностью достоверным и может быть использован для полного подтверждения достоверности ключа Фрэнсиса и частичного подтверждения достоверности ключа Елены. Наконец, если доверие Блэйку, Хлой и Елене полное, этого все еще не достаточно для подтверждения достоверности ключа Джефа, т.к. максимальная длина цепочки подтверждения равна трем, но путь от Джефа к Элис равен четырем.

Модель сети доверия реализует гибкий подход к проблеме безопасного обмена ключами. Она позволяет настраивать GnuPG в соответствии с Вашими потребностями. Вы можете требовать много коротких цепочек от Вашего ключа до ключа K для признания его достоверным. С другой стороны, Вы можете быть удовлетворены одной длинной цепочкой. Требование многочисленных коротких цепочек - сильная гарантия того, что ключ K принадлежит тому, на кого указывает его идентификатор пользователя. Цена за такую надежность, конечно, выше, т.к. Вы лично должны проверить и подписать большее количество ключей, чем в случае когда Вас устраивает небольшое число длинных цепочек.

Рисунок 3.1. Пример сети доверия

довериедостоверностьграничноеполноеграничнаяполная

љ	Дхарма	љ	Блэйк, Хлой, Дхарма, Фрэнсис
Блэйк, Дхарма	љ	Фрэнсис	Блэйк, Хлой, Дхарма
Хлой, Дхарма	љ	Хлой, Фрэнсис	Блэйк, Дхарма
Блэйк, Хлой, Дхарма	љ	Елена	Блэйк, Хлой, Дхарма, Фрэнсис
љ	Блэйк, Хлой, Елена	љ	Блэйк, Хлой, Елена, Фрэнсис

[5] GnuPG перегружает слово ``доверие'' используя его в смысле доверия владельцу и в смысле доверия ключу. Это может вызвать путаницу. Иногда доверие владельцу указывается прямо. В основном, в этом руководстве, термин ``доверие'' используется в смысле доверия владельцу ключа и термин ``достоверность'' для обозначения уверенности в том, что ключ принадлежит человеку указанному идентификатором пользователя.

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 13 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Изменение срока действия ключа

Срок действия ключа может быть изменен командой expire из меню редактирования ключа. Если нет выбранных ключей, то будет изменен срок действия первичного ключа. Иначе изменяется срок действия выбранного подчиненного ключа.

Время окончания срока действия ключа связано с самоподписью на ключе. Окончание срока действия изменяется удалением старой подписи и добавлением новой. Так как Ваши корреспонденты не будут удалять старую копию ключа, они будут видеть дополнительную самоподпись на ключе после его обновления. Позднейшая самоподпись имеет приоритет, поэтому все корреспонденты будут однозначно осведомлены о времени действия Вашего ключа.

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: 12 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Отзыв компонент ключа

Для отзыва подключа он должен быть выбран. Будучи выбран, он может быть отозван командой revkey. Ключ отзывается добавлением отзывающей самоподписи к ключу. В отличие от опции командной строки --gen-revoke, эффект наступает немедленно.

Command> revkey Do you really want to revoke this key? y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel Your decision? 2 Enter an optional description; end it with an empty line: > Reason for revocation: Key is superseded (No description given) Is this okay? y You need a passphrase to unlock the secret key for user: "Joe Duck (cook) <jd@other.mail.zu>" 1024-bit RSA key, ID 3AA48DCE, created 2002-05-05 pub 1024R/3AA48DCE created: 2002-05-05 expires: never trust: u/u sub 1024D/13375D62 created: 2002-05-06 expires: never sub 2048G/3745CA64 created: 2002-05-06 expires: 2004-05-05 rev! subkey has been revoked: 2002-05-07 sub 1024g/015418C9 created: 2002-05-06 expires: 2004-05-05 (1) Joe Duck <joe@duck.zu> (2). Joe Duck (cook) <jd@other.mail.zu>

Идентификатор пользователя отменяется иначе. Как правило, на идентификатор пользователя ставятся подписи, удостоверяющие личность обладателя ключа. Теоретически, идентификатор вечен, т.к. человек всегда остаётся собой. На практике, однако, элементы идентификатора пользователя, такие, как адрес электронной почты и комментарий могут изменяться, делая идентификатор пользователя недействительным.

Спецификация OpenPGP не поддерживает отзыв идентификатора пользователя, но идентификатор может быть эффективно отозван отзывом самоподписи на нем. По причинам безопасности, описаным , корреспонденты не будут доверять идентификатору пользователя не имеющему самоподписи.

Подпись отзывается командой revsig. Т.к. Вы можете иметь любое число подписанных идентификаторов пользователя, программа запросит Вас о каждой подписи.

Command> revsig You have signed these user IDs: Joe Duck <joe@duck.zu> signed by 3AA48DCE at 2002-05-05 Joe Duck (cook) <jd@other.mail.zu> signed by 3AA48DCE at 2002-05-06 user ID: "Joe Duck <joe@duck.zu>" signed with your key 3AA48DCE at 2002-05-05 Create a revocation certificate for this signature? (y/N) n user ID: "Joe Duck (cook) <jd@other.mail.zu>" signed with your key 3AA48DCE at 2002-05-06 Create a revocation certificate for this signature? (y/N) y You are about to revoke these signatures: Joe Duck (cook) <jd@other.mail.zu> signed by 3AA48DCE at 2002-05-06 Really create the revocation certificates? (y/N) y Please select the reason for the revocation: 0 = No reason specified 4 = User ID is no longer valid Q = Cancel Your decision? 4 Enter an optional description; end it with an empty line: > Reason for revocation: User ID is no longer valid (No description given) Is this okay? y You need a passphrase to unlock the secret key for user: "Joe Duck (cook) <jd@other.mail.zu>" 1024-bit RSA key, ID 3AA48DCE, created 2002-05-05 pub 1024R/3AA48DCE created: 2002-05-05 expires: never trust: u/u sub 1024D/13375D62 created: 2002-05-06 expires: never sub 2048G/3745CA64 created: 2002-05-06 expires: 2004-05-05 rev! subkey has been revoked: 2002-05-07 sub 1024g/015418C9 created: 2002-05-06 expires: 2004-05-05 (1) Joe Duck <joe@duck.zu> (2). Joe Duck (cook) <jd@other.mail.zu>

Отозванный идентификатор пользователя указан отзывающей подписью при перечислении подписей на идентификаторах пользователя.

Command> check uid Joe Duck <joe@duck.zu> sig!3 3AA48DCE 2002-05-05 [self-signature] uid Joe Duck (cook) <jd@other.mail.zu> rev! 3AA48DCE 2002-05-07 [revocation] sig!3 3AA48DCE 2002-05-06 [self-signature]

Отзыв и подключей, и самоподписей на идентификаторе пользователя добавляет отзывающие самоподписи к ключу. Т.к. подписи были добавлены, и ничего не удалялось, то отзыв всегда будет виден другим при распространении Вашего обновленного открытого ключа и объединении его с ранними копиями. Отзыв, таким образом, гарантирует, что у всех будет непротиворечивая копия Вашего открытого ключа.

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

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

GnuPG решает эту проблему при помощи механизма именуемого сеть доверия (web of trust). В модели сети доверия ответственность за проверку открытых ключей возложена на людей, которым Вы доверяете. Например, предположим

Элис подписала ключ Блэйка, а

Блэйк подписал ключи Хлой и Дхармы.

Если Элис уверена, что Блэйк проверяет достоверность ключей, которые он подписывает, то Элис может быть уверена, что ключи Хлой и Дхармы достоверны не проверяя их лично. Она просто использует свою достоверную копию открытого ключа Блэйка для проверки его подписи на ключах Хлой и Дхармы. Вообще, предполагая, что Элис совершенно уверена, что все правильно проверяют ключи, перед тем как их подписать, то любой ключ, подписанный достоверным ключом, будет достоверным.

Распространение ключей

В идеале, Вы распространяете Ваши ключи персонально передавая его Вашим корреспондентам. На практике, однако, ключи часто распространяются по электронной почте или другими способами электронной связи. Распространение по электронной почте хорошо когда Вы имеете только нескольких корреспондентов, если корреспондентов много, Вы можете разместить свой ключ на персональной веб-странице. Это не применимо, однако, если люди, которым нужен Ваш открытый ключ, не знают где найти его в сети.

Для решения этой проблемы используются серверы открытых ключей, которые собирают и распространяют открытые ключи. Открытый ключ либо добавляется к базе данных сервера, либо объединяется с существующим ключом, если такой существует. Когда на сервер приходит запрос ключа, сервер просматривает базу данных и, если находит, возвращает запрошенный ключ.

Серверы ключей также полезны когда многие люди часто подписывают ключи других людей. Без сервера ключей, когда Блэйк подписывает ключ Элис, он должен послать ей подписанную им копию ее открытого ключа, которую Элис может добавить к свому набору и передавать, затем, всем своим корреспондентам. Выполнение этих действий способствует построению плотных сетей доверия и повышению безопасности PGP. Однако они становятся помехой когда ключи подписываются часто.

Использование серверов ключей облегчает этот процесс. Когда Блэйк подписывает ключ Элис он посылает подписанный ключ на сервер ключей. Сервер ключей добавляет подпись Блэйка к своей копии ключа Элис. Те кто интересуется обновлением копии ключей Элис, по своей инициативе связываются с сервером ключей и получают оттуда обновленный ключ Элис. Элис не принимает участия в распространении ключа и может получить подписи на своем ключе просто запросив сервер.

Один или более ключей могут быть отправлены на сервер ключей командой --send-keys. В качестве аргумента указываются один или более спецификаторов ключей. Сервер ключей, которому будут переданы ключи задается опцией --keyserver. Аналогично, команда --recv-keys используется для получения ключей с сервера, но команде --recv-keys требуется идентификатор ключа. В следующем примере Элис обновляет свой открытый ключ с новыми подписями с сервера ключей certserver.pgp.com и затем посылает свою копию открытого ключа Блэйка на тот же сервер ключей для передачи своей подписи на нем.

alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC gpg: requesting key B115BDB6 from certserver.pgp.com ... gpg: key B115BDB6: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 alice% gpg --keyserver certserver.pgp.com --send-key blake@anywhere.ru gpg: success sending to 'certserver.pgp.com' (status=200)

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

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 14 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Управление Вашей парой ключей

Пара ключей состоит из открытого и секретного ключей. Открытый ключ состоит из открытой части главного подписывающего ключа, открытых частей подчиненных подписывающих и шифрующих ключей, набора идентификаторов пользователя, ассоциирующих открытый ключ с реальным человеком. Каждая часть содержит данные о себе. Для ключа -- это его идентификатор, дата создания, срок действия и т.д. Для идентификатора пользователя -- имя человека, дополнительный комментарий и адрес email. Структура секретного ключа аналогична, но содержит секретные части ключей и не содержит информацию об идентификаторе пользователя.

Для просмотра пары ключей используется команда --edit-key. Например,

joe% gpg --edit-key joe@duck.zu Secret key is available. pub 1024R/3AA48DCE created: 2002-05-05 expires: never trust: u/u sub 1024D/13375D62 created: 2002-05-06 expires: never sub 2048G/3745CA64 created: 2002-05-06 expires: 2004-05-05 sub 1024g/015418C9 created: 2002-05-06 expires: 2004-05-05 (1) Joe Duck <joe@duck.zu> (2). Joe Duck (cook) <jd@other.mail.zu> Command>

При отображении открытого ключа выводится информация о том, доступен секретный ключ или нет. Затем выводится информация о каждом компоненте открытого ключа. Первая колонка показывает тип ключа. Символы pub обозначают открытую часть главного подписывающего ключа, а символы sub открытую часть подчиненных ключей. Вторая колонка показывает длину ключа в битах, тип и идентификатор. Тип D это ключ DSA, R - ключ RSA, g - ключ ElGamal, пригодный только для шифрования, G - ключ ElGamal, который может использоваться и для подписи и для шифрования. Дата создания и окончания срока действия показана в колонках три и четыре. Идентификаторы пользователя перечислены после ключей.

Дополнительная информация о ключе может быть получена различными командами. Команда toggle переключает между открытой и закрытой компонентами пары ключей, если обе из них доступны.

Command> toggle sec 1024R/3AA48DCE created: 2002-05-05 expires: never ssb 1024D/13375D62 created: 2002-05-06 expires: never ssb 2048G/3745CA64 created: 2002-05-06 expires: never ssb 1024g/015418C9 created: 2002-05-06 expires: never (1) Joe Duck <joe@duck.zu> (2) Joe Duck (cook) <jd@other.mail.zu> Command>

Представленная информация подобна выводимой для открытого ключа. Символы sec указывают секретный главный подписывающий ключ, символы ssb указывают секретные подчиненные ключи. Также выводятся идентификаторы пользователя из открытого ключа.

Повседневное использование GnuPG

$Id: c4.xml 5 2005-10-02 16:50:06Z zwon $

GnuPG сложный инструмент с набором технических, социальных и законодательных тонкостей, возникающих при его использовании. Технически, он был разработан для удовлетворения очень различающихся потребностей в защите. Это усложняет управление ключами. Социально, использование GnuPG не является только персональным решением. Для эффективного использования GnuPG, его должны использовать обе стороны. Наконец, законодательство ограничивает использование цифрового шифрования, и, в частности, ответ на вопрос о законности использования GnuPG различен в разных государствах.

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

Определение Ваших требований к защите

GnuPG инструмент для защиты Ваших секретов. Ваши секреты защищены если Ваши сообщения не доступны постороннему глазу.

То, как Вам следует использовать GnuPG, зависит от желания и возможностей тех, кто может захотеть прочесть Ваши сообщения. Это может быть бесцеремонный системный администратор, небрежно просматривающий Вашу почту, промышленный шпион, пытающийся похитить секреты Вашего предприятия, или государственные спецслужбы, интересующиеся Вами. Использование GnuPG для защиты от случайного просматривания отличается от использования GnuPG в случае если кто-то целенаправленно пытается прочесть Вашу почту. Ваша цель, в конечном счете, состоит в том, чтобы сделать расшифровку данных более дорогой чем их стоимость.

Настройка GnuPG включает решение четырех задач:

выбор размера Вашей пары ключей,

защита Вашего секретного ключа,

выбор сроков действия ключей, и

управление Вашей сетью доверия.

Правильно выбранный размер ключа защищает Вас от лобовых атак на зашифрованные сообщения. Защита Вашего секретного ключа предотвращает использование его кем-то другим для расшифровки направленных Вам сообщений и подписи своих сообщений Вашей подписью. Правильное управление Вашей сетью доверия предотвращает маскировку атакующего под человека с которым Вы переписываетесь. В конецном счете, от того как Вы соотносите решение этих проблем с потребностями защиты, зависит баланс между дополнительной работой, связанной с использованием GnuPG, и защитой, которую Вам это дает.

Построение Вашей сети доверия

Одного желающего использовать GnuPG недостаточно. Для того, чтобы сообщаться защищенно с другими, Вы должны иметь сеть доверия. Построение сети доверия похоже на укрощение. Люди, с которыми Вы общаетесь, должны использовать GnuPG[6], и должно иметься достаточное количество подписанных ключей, чтобы ключи могли подтверждаться. Это не столько технические, сколько социальные проблемы. Однако, Вы должны преодолеть эти проблемы, если хотите использовать GnuPG.

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

В дополнение к этой начальной сети доверия, Вы можете захотеть конфиденциально переписываться с другими людьми, также использующими GnuPG. Реализация этого желания, однако, может оказаться неуклюжей по двум причинам: (1) Вы не всегда знаете, что человек использует или желает использовать GnuPG, и (2) если Вы и знаете, что человек использует его, могут возникнуть сложности с подтверждением ключей. Первая причина является следствием того, что люди не всегда объявляют о том, что используют GnuPG. Возможный вариант решения этой проблемы, подать пример и объявить, что Вы используете GnuPG. Есть как минимум три способа сделать это: Вы можете подписывать свои сообщения, Вы можете положить свой открытый ключ на своей веб-странице, Вы можете указать идентификатор Вашего ключа в подписи почтового сообщения. Если Вы сообщаете о своем ключе, то делаете более уместным для других сообщить об их ключах. Более того, Вашим корреспондентам будет проще начать с Вами переписываться конфиденциально, если Вы проявите инициативу и сделаете ясным использование Вами GnuPG.

Проверка правильности ключа более сложна. Если Вы не знакомы лично с человеком, чей ключ собираетесь подписать, то не можете подписать ключ сами. Вы должны опираться на чужие подписи и постараться найти цепочку подписей, начиная с ключа под вопросом и заканчивая Вашим. Для нахождения цепочки, Вы должны проявить инициативу и получить Ваш ключ подписанный кем-либо за пределами Вашей начальной сети доверия.

Имейте однако в виду, что все это в зависимости от потребностей. Вы не обязательно должны заявлять о своем ключе или подписывать чужие ключи. Сила GnuPG состоит в том, что он достаточно гибок и может быть адаптирован к Вашим потребностям, какими бы они не были. При этом действительность такова, что Вы должны проявлять инициативу, если хотите расширить свою сеть доверия и использовать GnuPG как можно больше.

[6] В этом разделе, GnuPG относится к GnuPG реализации OpenPGP также, как к другим реализациям, типа PGP произодимому NAI.

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 16 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Управление Вашей сетью доверия.

Как и защита Вашего секретного ключа, управление сетью доверия является тем аспектом использования GnuPG, который требует соблюдения баланса между защитой и легкостью использования. Если Вы используете GnuPG для защиты от случайного подслушивания и подделок, то можете позволить себе относительную легкость в доверии чужим подписям на ключах. С другой стороны, если Вы считаете, что кто-либо заинтересован в получении доступа к Вашим секретам, то Вам следует проявлять меньшее доверие в отношении чужих подписей и тратить больше времени на проверку ключей.

Независимо от Ваших личных потребностей в защите, Вы всегда должны быть внимательны подписывая чужие ключи. Подписывать ключ опираясь на собственные потребности в защите эгоистично. На Вашу подпись могут полагаться другие, чьи требования, возможно, более высоки. Если они не смогут полагаться на Вас, это ослабит сеть доверия и затруднит общение всего сообщества пользователей GnuPG. Используйте те же меры предосторожности, подписывая ключи, какие Вы хотели бы, чтобы принимали те, на чьи подписи полагаетесь Вы.

На практике, управление Вашей сетью доверия сведено к присвоению значения доверия некоторому минимальному числу других лиц и настройке параметров --marginals-needed и --completes-needed. Любой ключ, подписанный Вами лично, считается подтвержденным, но, кроме как для маленьких групп, не является практичным подписывать ключ каждого, с кем Вы переписываетесь. Вы будете, следовательно, должны полагаться на других.

Наиболее разумно, проявить аккуратность присваивая значения доверия и затем настроить опции, указывающие GnuPG строгость проверки ключей. Например, Вы можете полностью доверять узкому кругу друзей, которые, как Вы знаете, осторожны при подписи ключей, и незначительно доверять всем остальным, чьи ключи имеются в Вашей связке. Тогда, Вы можете установить значения --completes-needed равным 1 и --marginals-needed равным 2. Если Вы более осторожны, то можете выбрать значения 1 и 3 или 2 и 3 соответственно. Если Вы меньше озабочены секретностью и просто заинтересованы в некотором приемлемом подтверждении достоверности, установите значения 1 и 1. В целом, более высокие значения этих параметров означают, что большее число людей должны сговориться против Вас, чтобы получить подтвержденный ключ, не принадлежащий тому, кому Вы думаете.

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 15 :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Выбор размера ключа

Выбор размера ключа зависит от типа ключа. В OpenPGP, пара открытого/закрытого ключей обычно состоит из нескольких ключей. Как минимум в нее входит главный ключ для подписи, кроме того, обычно она содержит один или несколько дополнительных ключей для шифрования. При использовании при генерации ключа параметров по умолчанию, главный ключ будет DSA ключом, а подключи будут ElGamal ключами.

DSA допускает ключи длиной до 1024 бит. Это не слишком много, учитывая сегодняшнее развитие технологии, но это то, что описывает стандарт. Если Вы используете DSA ключи, то их длина должна быть 1024 бита.

ElGamal и RSA ключи могут быть любого размера. Т.к. GnuPG смешанная система, открытый ключ используется для зашифрования 128-битного сеансового ключа, а закрытый ключ используется для его расшифрования. Размер ключа влияет на скорость зашифрования и расшифрования, т.к. стоимость этих алгоритмов экспоненциальна относительно размера ключа. Большие ключи также требуют больше времени для генерации и больше места для хранения. Наконец, если ключ слишком велик для атаки в лоб, похититель просто прибегнет к другим методам, чтобы получить интересующие его данные. Примерами других методов являются ограбление Вашего дома или офиса, либо нападение лично на Вас. 1024 бит - рекомендуемый размер ключа. Если Вы действительно нуждаетесь в ключе большего размера, то скорее всего уже знаете об этом и должны проконсультироваться с экспертом по защите данных.

Законность использования GnuPG

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

Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 17 :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::

Защита Вашего секретого ключа

Защита секретного ключа одна из наиболее важных задач для надёжной работы GnuPG. Если кто-либо получит Ваш секретный ключ, то он сможет расшифровывать все направленные Вам сообщения и сможет подписываться Вашей подписью. Если Вы потеряете Ваш секретный ключ, то не сможете больше расшифровывать документы зашифрованные для Вас и не сможете подписывать свои сообщения. Потеря единственной копии Вашего секретного ключа катастрофична.

Независимо от того, как Вы используете GnuPG Вы должны сохранить открытых ключей и резервную копию Вашего секретного ключа на защищенный от записи носитель и хранить его в надежном месте. Например, Вы можете записать копии на компакт-диск и хранить его в банковском сейфе. Можно, также, записать их на дискету и спрятать ее дома. Чтобы Вы ни делали, копии должны быть скопированы на носитель, на котором они смогут надежно храниться на протяжении всего срока использования ключа, и их следует спрятать более тщательно, чем копию Вашего секретного ключа для ежедневного использования.

Чтобы защитить Ваш ключ, GnuPG не сохраняет его на диск в чистом виде. Вместо этого он шифруется симметричным алгоритмом. Вот зачем нужна ключевая фраза для доступа к ключу. Поэтому взломщик должен решить две проблемы, чтобы получить Ваш секретный ключ: (1) он должен получить ключ, (2) он должен расшифровать ключ.

Надежное хранение секретного ключа - сложная задача. В идеале, Вы должны хранить секретный ключ на сменном, защищенном от записи диске и использовать его только на на однопользовательской машине не подключенной к сети. Это может оказаться неудобным или невозможным для Вас. Например, у Вас может не быть своего компьютера и Вы используете компьютер на работе, или это может означать, что Вам прийдется отключать компьютер от сети каждый раз когда Вы запускаете GnuPG

Это не означает, что Вы не можете или не должны использовать GnuPG. Это означает только, что Вы считаете свои данные достаточно важными, чтобы шифровать, но не настолько важными, чтобы принимать особые меры предосторожности для усиления первого барьера защиты.
Это Ваш выбор.

Хорошая ключевая фраза очень критична при использовании GnuPG. Любой взломщик, получивший Ваш секретный ключ, должен взломать шифр на секретном ключе. Вместо атаки в лоб, взломщик, наверняка, попробует угадать ключевую фразу.

Мотивацией для подбора ключевой фразы является то, что большинство людей выбирают ключевую фразу, которую проще подобрать, чем произвольный 128 битный ключ. Если в качестве ключевой фразы используется слово, то гораздо проще перепробовать все слова в словарях мировых языков. Даже если слово искажено, например, k3wldood, гораздо проще попробовать слова из словаря с каталогом перестановок. Таже проблема с цитированием. В общем случае, ключевые фразы основанные на естественном языке недостаточны, т.к. в естественных языках не хватает случайности и избыточности. Вы должны избегать использования естественных языков в ключевых фразах, если можете.

Хорошая ключевая фраза такова, что Вы можете ее запомнить, но ее трудно подобрать. Она должна включать символы из всего диапазона печатных символов на вашей клавиатуре. Сюда входят алфавитные символы, в разных регистрах, цифры и специальные символы, такие как } и |. Проявите творческий подход и затратьте немного времени обдумывая ключевую фразу, хороший выбор важен для обеспечения Вашей секретности.

Различные вопросы

$Id: c5.xml 5 2005-10-02 16:50:06Z zwon $

Эта глава рассматривает различные вопросы которым не нашлось места в другом месте руководства. Добавленные вопросы могут собираться и распределяться по главам. Если Вы хотели бы увидеть освещенным некоторый вопрос, пожалуйста сообщите об этом. А еще лучше, напишите черновую версию, описывающую интересующий Вас вопрос!

Написание пользовательского интерфейса

и провели пользовательского интерфейса PGP 5.0 и пришли к заключению, что начинающие пользователи находят PGP сложным и непонятным. По результатам их тестов, только четверо из двенадцати тестируемых правильно отправили зашифрованные сообщения членам их команды, и трое из двенадцати отправили секрет незашифрованным. При этом половина тестируемых прошли техническую подготовку.

Эти результаты не удивляют. PGP 5.0 имеет хороший пользовательский интерфейс, который превосходен если Вы уже понимаете как работает шифрование открытым ключом и дружите с моделью подтверждения ключей специфицированной OpenPGP. К сожалению, начинающие пользователи, не понимают ни шифрования с открытым ключом, ни правил управления ключами, и пользовательский интерфейс мало помогает им.

Вам следует внимательно ознакомиться с выводами Whitten'а и Tygar'а если Вы пишете пользовательский интерфейс. Они дают комментарии по каждому из тестируемых. Например, оказалось, что многие верят, что сообщение посылаемое другим людям надо зашифровывать своим собственным открытым ключом. Задумайтесь над этим, и Вы поймете, что легко допустить такую ошибку. Как правило, начинающие пользователи испытывают трудности в понимании различий между открытым и закрытым ключами когда используют GnuPG. Как дизайнер пользовательского интерфейса, Вы должны постараться сделать выбор того или ключа прозрачным. Вы можете, также, использовать мастера и другие общепринятые приемы GUI для проведения пользователя сквозь основные задачи, такие как генерация ключа, дополненная генерацией сертификата отзыва ключа, и т.п. Из документа следуют, также, следующие выводы.

Безопасность, обычно является второстепенной задачей; люди хотят отправлять почту, просматривать и т.д. Не думайте что пользователи станут читать толстые руководства или разбираться в настройках шифрования.

Защита сетевого компьютера не сильнее самого слабого из ее компонентов. Пользователи должны быть осведомлены обо всех аспектах своей безопасности, не ограничиваясь частичными сведениями, как это может быть с текстовыми процессорами или электронными таблицами.

Всегда используйте одинаковые термины для одинаковых действий. Избегайте употребления синонимов, типа ``encrypt'' и ``encipher''.

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



Разработка эффективного пользовательского интерфейса для управления ключами еще более сложна. Модель сети доверия OpenPGP, к сожалению, довольно трудна для понимания. Например, спецификация определяет три степени доверия пользователю: нет (none), относительное (marginal), и полное (сomplete). Все грани доверия, испытываемого пользователем, должны уместиться в эти три ячейки. Алгоритм подтверждения ключей также сложен для понимания не специалистов, особенно параметры ``marginals needed'' и ``completes needed''. Так как модель сети доверия четко определена и не может быть изменена, Вам прийдется постараться и разработать интерфейс, который поможет понять ее пользователю. Определенная функция, к примеру, могла бы отображать диаграмму того, как был подтвержден ключ, по запросу пользователя. Основные выводы следующие.

Пользователи могут оставаться в неведении относительно того, как и когда предоставить доступ.

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



Страницы: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: 18 :: :: :: :: :: :: :: :: :: :: :: :: :: ::

---

---