Введение в Client Certificate – сертификаты пользователей для аутентификации и авторизации – Часть 2.

May 10th, 2012 § 0 comments § permalink

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

HASH – это определенная строка (набор цифр или символов), которая получается из исходного сообщения. Сразу скажу, что HASH строка не обратима, а это значит что получив HASH строку  из сообщения нет возможности понять из какого сообщения она была сделана, только при повторном создании HASH строки и сравнении двух получившихся результатов можно вычислить методом перебора какое было исходное сообщение. В ряде случаев это очень даже необходимо, когда речь идет о защите информации.

Есть и ложка дегтя – HASH строка сообщения не является уникальной. Это значит что существуют два (и более) разных исходных сообщения, которые при одинаковом преобразовании дают одинаковую HASH строку. Это плохо, хотя бы с той точки зрения, что можно передать другое сообщение, которое при проверке будет давать положительный результат, а на самом деле будет ложью.

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

Для формирования HASH строки, как правило пользуются 2-мя алгоритмами:

  1. MD5 – более сложный алгоритм получения HASH строки сообщения,
  2. SHA1 – более простой алгоритм получения HASH строки сообщения.

MD5 работает по простому алгоритму, условно состоящий из трех этапов:

  1. исходное сообщение делится на блоки по 512 бит = 64 байта;
  2. после этого от каждого блока вычисляется замысловатая но простая в реализации функция;
  3. после этого все результаты функций собираются вместе в 128-битный хеш.

SHA1 по сути работает по такому же принципу, как и MD5:

  1. сообщение разбивается на блоки – дополняется битом «1», нулями и 64-битным представлением длины сообщения (в отличие от MD5, здесь другой порядок байт 64-битного числа);
  2. далее обрабатывается 512-битный блок;
  3. после обработки все блоки соеднияются и получается 160-битный HASH (5 регистров по 32 бита).

Отличием MD5 от SHA1 является то, что в SHA1 байты регистров нумеруются наоборот.

В сертификатах пользователей HASH применяется для осуществления подписи. Данная подпись позволяет в любой момент (при наличии открытого ключа центра сертификации, который подписал или как говорится правильно – выпустил, данный сертификат) проверить подлинность сертификата. Для этого необходимо выполнить следующие действия:

  1. вычислить HASH открытой части сертификата;
  2. взять зашифрованную подпись сертификата и расшифровать её открытым ключом центра сертификации;
  3. сравнить 2 HASH строки: которую вычислил из открытой части сертификата и ту, которая получилась при расшифровке открытым ключом центра сертификации.

Если данные строки идентичны, то с очень большой долей вероятности можно утверждать, что сертификат подлинный (конечно же, если мы заведомо доверяем центру сертификации, выдавшему данный клинетский сертификат).

Кончено же, тема о Client Certificate намного шире и глубже, чем я описал в этих двух статьях. Но если рассматривать их в качестве ознакомительной информации, для понимания основ и возможного применения, то этой информации вполне достаточно. По крайней мере, я надеюсь, теперь есть понимание в какую сторону надо “копать” – искать информацию для решения ваших задач.

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

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

Введение в Client Certificate – сертификаты пользователей для аутентификации и авторизации – Часть 1.

May 9th, 2012 § 0 comments § permalink

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

  1. аутентификация пользователя,
  2. авторизация пользователя,
  3. обеспечение блокировки пользователя при необходимости, например увольнении.

Особенностью клиентского сертификата заключается тот факт, что для одного пользователя их может быть выдано большое количество. В Microsoft Active Directory (AD) сертификаты пользователя привязываются к учетной записи. Тоесть в AD создается пользователь, после этого выдается на него сертфикат, открытая часть которого подписывается в Корпоративном Центре Сертификации (ЦС).

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

Асинхронное шифрование – это такое шифрование, при котором сообщение шифруется одним ключом, а расшифровать его можно только с помощью второго парного ключа.

Благодаря этому гениальному асинхронному шифрованию и появилась возможность производить 2 действия:

  1. подписывать сообщения, чтобы все могли удостовериться, что данное сообщение написано именно тем субъектом, за кого он себя выдает;
  2. обмениваться сообщениями между субъектами и быть уверенным, что прочитать его сможет только тот, кому оно предназначается.

Конечно же, вышеописанные 2 пункта действуют только при условии, что секретный ключ не был утерян или украден у настоящего владельца.

Секрет асинхронного шифрования заключается в том, что:

  1. есть определенная математическая функция, передав в которую исходное сообщение и определенный ключ, на выходе получим “нечитаемую последовательность символов”;
  2. полученную “нечитаемую последовательность симоволов” можно вернуть в исходное состояние (исходное сообщение), но не при помощи ключа, который использовался для шифрования, а при помощи другого определенного ключа. Тоесть передав в функцию “нечитаемую последовательность символов” и второй ключ на выходе мы получаем исходное сообщение.

Это действительно просто (если не вдаваться в подробности как это все происходит на уровне математики).

А теперь самое главное для понимания. В применении к области защиты информации, асинхронное шифрование содержит:

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

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

Закрытый ключ – данный ключ применяется:

  1. Чтобы подписывать свои сообщения (распространенное применение на сегодняшний день — электронно-цифровая подпись). Это гарантирует читателю, что данное сообщение было написано именно этим суюъектом. Для проверки необходим второй ключ из пары открытый и закрытый ключ.
  2. Чтобы расшифровывать те сообщения, которые были зашифрованы с помощью открытого ключа. Тоесть, любой, у кого есть открытый ключ из пары открытый и закрытый ключ (а он есть у всех, кому необходим и не является в данной концепции защиты информации объектом защиты от утечки) может зашифровать свое сообщение и никто не соможет прочитать его кроме владельца второго закрытого ключа.

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

А немного позже напишу пост о http_x_arr_clientcert – переменная, которая применяется в Microsoft IIS при настройке редиректа.