пятница, 19 июля 2013 г.

HOWTO: использование ЭЦП и шифрования на практике

Часть первая

Часть вторая

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

Напомню краткое содержание первой части: там мы разобрали вопрос полезности ключей, а также их генерации. ИМХО полезно составить небольшую шпаргалку:


# создание нового ключа
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, используемый по умолчанию.

Комментариев нет:

Отправить комментарий