Часть первая
Часть вторая
Использование ключей для шифрования и для подписи.
Напомню краткое содержание первой части: там мы разобрали вопрос полезности ключей, а также их генерации. ИМХО полезно составить небольшую шпаргалку:
Часть вторая
Использование ключей для шифрования и для подписи.
Напомню краткое содержание первой части: там мы разобрали вопрос полезности ключей, а также их генерации. ИМХО полезно составить небольшую шпаргалку:
# создание нового ключа
gpg --gen-key
# создаёт новые ключ. Ещё раз напомню, что СЕКРЕТНЫЙ КЛЮЧ ДОЛЖЕН БЫТЬ СВОЙ У КАЖДОЙ СИСТЕМЫ.
# список ключей
gpg --list-keys
gpg --list-keys KID
# список ключей и их субключей.
# NOTE: можно добавить параметр KID -- уникальный кусок чего-то от какого-нить ключа.
# К примеру, если у меня только одни ключ содержит XYZ в имени или в описании или в почтовом адресе,
# я могу добавить только XYZ, и gpg выведет только этот ключ. Это верно и для многих других команд.
# также можно использовать ID ключа -- уникальное шестнадцатеричное восьмизначное число,
# которое выводится в списке ключей и в других случаях (это последние цифры отпечатка ключа, см. ниже)
# редактирование ключа
gpg --edit-key KID
# (см. выше NOTE, верно и для KID)
# подробности ниже
# экспорт ключа
gpg --export KID
gpg --armor --export KID
# выводит ключ на стандартный вывод
# --armor нужен для вывода в текстовом виде(такое можно смело вставлять в любой текст)
# импорт
gpg --import
# добавление ключа(ключей) из стандартного ввода в в ваше кольцо (keyring).
# шифрование
gpg --encrypt --recipient KID FILENAME
# данная команда шифрует файл FILENAME для KID.
# создаётся новый файл с именем FILENAME.gpg
# который может прочитать только KID
# можно задать несколько реципиентов, в т.ч. и себя, если это например бекап
# допустимо использовать ключ --armor, тогда имя файла будет FILENAME.asc
# и файл будет годен для вставки в любой текст
# дешифровка
gpg --decrypt FILENAME.{asc,gpg}
# расшифровывает файл и отправляет его в ст. вывод(допустимо и в файл с --output)
# для расшифровки нужен секретный ключ одного из реципиентов.
# проверка подписи
gpg --verify FILENAME.{asc,gpg,sig}
# проверяет ЭЦП FILENAME
# подпись может содержаться в самом FILENAME.gpg или лежать отдельно в файле FILENAME.sig или в FILENAME.asc
# подпись файла
gpg --sign FILENAME
gpg --sign --detach-sign FILENAME
# подписывает файл FILENAME
# если использовать --detach-sign, то подпись будет в виде отдельного файла FILENAME.sig
# вместе с --detach-sign можно использовать --armor
# для подписания требуется Ваш секретный ключ
# комбинация шифрования и подписи
gpg --sign --encrypt --recipient KID FILENAME
# шифрование и подпись можно и нужно комбинировать.
# тогда ваш реципиент будет уверен в том, что файл не подделка
# проблема в том, что публичный ключ реципиента известен всем
# в т.ч. и злоумышленнику
# а значит он может просто подменить наше сообщение
К примеру, Алиса желает отправить сообщение Бобу. У них имеется незащищённое хранилище insecure_storage, пусть это будет обычный каталог, к которому смонтированно облако яндекс-диска. Т.о. если Алиса просто отправит туда message, то злоумышленник может его не только прочитать, но и изменить. На компьютере Алисы
cp message insecure_storage/На компьютере Боба
cp insecure_storage/message .Тем временем на компьютере КровавойГБни
cp insecure_storage/message . vim message # Вау! cp message insecure_storage/messageт.о. в иттоге Боб получит перлюстрированное и исправленное message. ИЧСХ, даже об этом не узнает, а будет уверен, что это личное дело между ним и Алисой.
Как избежать такой атаки?
Шаг №1: Алиса и Боб создают свои ключи, и отправляют их в insecure_storage. Создание ключей уже обсуждалось. Экспорт осуществляется ключом ---export, например на компьютере Алисы
gpg --export Alice >insecure_storage/alice.keyТеперь забираем ключ Боба
gpg --import insecure_storage/bob.key
(очевидно, Боб должен сделать тоже самое)
Шаг №2
В принципе, теперь Алиса может смело шифровать своё message
gpg --sign --encrypt --recipient Bob message cp message.gpg insecure_storage/Но не всё так просто...
Кровавая ГБня может с лёгкостью подменить insecure_storage/alice.key на свой. В дальнейшем она может непрерывно отслеживать insecure_storage, и постоянно подменять там message от Алисы на свои, подписанные фейковым ключом. Боб этого не заметит. Также Кровавая ГБня может подменить insecure_storage/bob.key, и потому Алиса будет шифровать не для Боба, а для Кровавой ГБни. Ей(ГБне) останется только вовремя удалить insecure_storage/message от Алисы, прочитать фейковым ключом якобы Боба, а потом подписать фейковым ключём якобы Алисы и зашифровать настоящим ключом Боба. При этом Боб никак НЕ узнает, что message прочитано, и при необходимости изменено.
Данная ситуация НЕ решается в данных условиях. Имея только insecure_storage наладить связь невозможно. К счастью, не всё так трагично. В нашем сегодняшнем мире циркулируют тысячи гигабайт мусора во всех направлениях, и отследить их все в принципе невозможно.
Единственное, что нужно Алисе -- доказать Бобу, что она, это ОНА, а вовсе не Кровавая ГБня. В качестве доказательства можно использовать третью сторону, но это не слишком безопасно и надёжно (Кровавая ГБня может отслеживать третью сторону, и с помощью ректального криптоанализа _может_ заставить её делать то, что велит Политика Партии).
В качестве пруфа(доказательства), Алиса может воспользоваться своим отпечатком ключа(fingerprint). Вот к примеру отпечаток ключа моего нетбука
$ gpg --fingerprint amilo pub 2048R/6D300475 2013-07-18 Отпечаток ключа = E3A9 7C06 C734 B779 92D3 69B5 3494 1316 6D30 0475 uid drBatty (amilo key)(Отпечаток выделен)sub 2048R/FFE32EF7 2013-07-18
Этот отпечаток НЕ является секретным. Передать его можно вместе с _любым_ мусором, к пример прицепив его к любой фотке, что-бы его было не так заметно, его можно преобразовать, к примеру посчитать его md5. Тут даже не нужна возможность обращения Бобом этой md5, ведь получив alice.key Боб тоже узнает отпечаток, и может самостоятельно вычислить его md5. Алисе нужно лишь отправить по какому-то другому каналу Бобу этот отпечаток в любом виде. А вот задача Кровавой ГБни существенно осложняется: ей придётся закопаться во ВЕСЬ мусор, который _может_ генерировать Алиса. И в онлайне, и даже IRL(Алиса _может_ написать fingerprint на использованной прокладке, и её выкинуть на какой-то помойке. Расковыряв прокладку Боб узнает отпечаток. Т.о. Кровавой ГБне придётся даже все алисины прокладки распотрошить)
Зная отпечаток ключа, Боб может подписать alice.key своей ЭЦП, дабы в будущем не мучаться, сверяя этот отпечаток. Вот пример подписывания ключа моего нетбука. Сейчас я нахожусь дома, за десктопом ksu, GPG ID: 3B210778. При этом ключ нетбука amilo, GPG ID: 6D300475.
$ gpg --edit-key amilo
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub 2048R/6D300475 создан: 2013-07-18 годен до: неогранич применяемость: SC
доверие: полное достоверность: полное
sub 2048R/FFE32EF7 создан: 2013-07-18 годен до: неогранич применяемость: E
[ полное ] (1). drBatty (amilo key)
gpg> sign
pub 2048R/6D300475 создан: 2013-07-18 годен до: неогранич применяемость: SC
доверие: полное достоверность: полное
Отпечаток главного ключа: E3A9 7C06 C734 B779 92D3 69B5 3494 1316 6D30 0475
drBatty (amilo key)
Вы уверены, что хотите подписать этот ключ
своим ключом: "drBatty (ksu) " (3B210778)
Действительно подписать? (y/N)y
Необходим пароль для доступа к секретному ключу пользователя: "drBatty (ksu) "
2048-бит RSA ключ, ID 3B210778, создан 2011-04-02
здесь был пароль к ключу ksu
gpg> quit
Сохранить изменения? (y/N)y
(выделено то, что я вбивал)Note: здесь используются два ключа: один подписывается, а ВТОРЫМ подписывают. Второй ключ получается автоматически, это первый ключ в кольце, который имеет секретную часть. Если вам нужен другой ключ, то перед командой --sign нужно указать --default-key KID, указывающий на нужный секретный ключ.
Вот теперь проверять Боб может не только просто так. Если подпись Алисы не подписана Бобом(в смысле, публичный ключ Алисы, который есть у Боба, не подписан ключом Боба), он увидит предупреждение:
gpg: ВНИМАНИЕ: Данный ключ не заверен доверенной подписью! gpg: Нет указаний на то, что подпись принадлежит владельцу. Отпечаток главного ключа: ...
Если предупреждения не было, Боб может быть уверен, что сообщение действительно от Алисы.
Даже если мы работаем с двумя компьютерами, всё равно в ключах просто запутаться. Нужно поставить степень доверия ключу командой trust (она вводится тоже после gpg --edit-key KID).
Укажите насколько Вы доверяете данному пользователю в вопросах проверки достоверности ключей других пользователей. Проверяет паспорт, сверяет отпечатки ключей и т.п.? 1 = Не знаю или не буду отвечать 2 = Не доверяю 3 = Доверяю ограниченно 4 = Полностью доверяю 5 = Абсолютно доверяю m = вернуться в главное меню
Я использую абсолютную(5) степень доверия для локальных ключей, полную(4) для своих, и ограниченную(3) для чужих ключей.
Note: степень доверия локальна. Владелец этого ключа никогда не узнает, насколько вы ему доверяете. Данная опция не имеет никакого отношения к сети сертификатов.
Редактирование и удаление ключей
У каждого ключа есть свой uid(User ID), он создаётся автоматически. Но этих uid'ов может быть и более одного. Именно на uid, а вовсе не на сам ключ, и устанавливается подпись. Можно добавлять/удалять uid командами adduid/deluid, что-бы удалить uid надо его для начала выбрать, просто набрав его номер. А затем можно удалять командой deluid.
gpg> list
pub 2048R/BEC9B8A8 создан: 2013-07-19 годен до: 2014-07-19 применяемость: SC
доверие: полное достоверность: полное
sub 2048R/EFF1C7DB создан: 2013-07-19 годен до: 2014-07-19 применяемость: E
[ полное ] (1). emulek2 (test)
[ полное ] (2) emulek (autosign)
gpg> 1
pub 2048R/BEC9B8A8 создан: 2013-07-19 годен до: 2014-07-19 применяемость: SC
доверие: полное достоверность: полное
sub 2048R/EFF1C7DB создан: 2013-07-19 годен до: 2014-07-19 применяемость: E
[ полное ] (1)* emulek2 (test)
[ полное ] (2) emulek (autosign)
gpg> deluid
Вы действительно хотите удалить данный User ID? (y/N)y
pub 2048R/BEC9B8A8 создан: 2013-07-19 годен до: 2014-07-19 применяемость: SC
доверие: полное достоверность: полное
sub 2048R/EFF1C7DB создан: 2013-07-19 годен до: 2014-07-19 применяемость: E
[ полное ] (1) emulek (autosign)
Как видите, выбранный uid выделяется звёздочкой (*). Именно таким образом и "редактируется" ключ, если в желаете например сменить своё имя, или почтовый адрес.Точкой "." обозначается последний добавленный uid, используемый по умолчанию.
Комментариев нет:
Отправить комментарий