объявляет, что сертифицировать можно только «законченные криптографические продукты». Что

это такое – толком никто не знает, четких определений нет, одни интуитивные понятия

чиновников, но CSP, на взгляд чиновников, таковым не является.

Да и всяких других чудес от чиновников можно ожидать в любой момент. IT-россияне к

этому привыкли, монополию Стекляшки на российскую криптографию отменить нельзя: считается

аксиомой. Некоторые из IT-нероссиян согласились с этой аксиомой, но все-таки далеко не все.

Вместо принципа «дружить со Стекляшкой» используют принцип держаться от криптографической России подальше.

Ах вы такие-сякие! Да мы тогда сами поломаем ваш Windows и впихнем туда творения

наших чиновников. Реализация усложнится и скорость уменьшится? Плевать!!!

И вот стали все российские IT-компании, которые дружат со Стекляшкой, ломать Windows, встраивать в него всякие доморощенные Kernel Drivers только с одной целью: продолжить дружить со Стекляшкой. Да только вот беда-то какая.

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

(например, только для военных), то всех их можно принудительно заставить сломать свой

Windows. А если, к примеру, разрабатывается замечательный по задумке и исполнению портал

ГосУслуг, то там круг потребителей не определен. Всем нужен портал ГосУслуг. А доступ к порталу

должен быть безопасным, т.е. необходим зашифрованный трафик. SSL-протокол с RSA органически встроен куда угодно: и в Windows, и в IOS, и в Андроид и вообще в любую пуговицу.

Как там использовать «российские криптографические алгоритмы»?

Прежде всего отметим, что давняя мечта российских криптографических чиновников – это

чтобы «неопределенный круг пользователей», т.е. практически все россияне, дружили со

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

Windows единым живет нынче цифровой мир. Если Windows любезно предоставляет

возможность сравнительно легко ломать себя с помощью Kernel Drivers, то всякие там IOS и

примкнувшие к ней другие операционные системы для смартфонов – нет. Подписывают они

основные файлы в своих операционных системах с помощью того же RSA.

И вот что делают разумные разработчики, несмотря на майские Указы Президента.

Сертификат портала ГосУслуг Российской Федерации.

Сертификат сервера Сбербанка.

Сертификат сервера КриптоПро.

И так далее.

Сжав челюсти, Стекляшка закрывает глаза на эти безобразия. Тут, правда, должен

заметить, что эти сертификаты предназначены для организации SSL - защищенного протокола

связи с сервером. Они являются сертификатами сервера и не предназначены для

криптографической аутентификации пользователей.

Везде сертификат используется фактически только для организации протокола SSL. Есть и

аналогичное российское создание – протокол TLS, но «неопределенный круг пользователей»

почему-то не хочет менять на него всем уже привычный и неприхотливый SSL. Да и 99% этих

пользователей вообще слабо себе представляют, что такое SSL и TLS, и почему вдруг надо

создавать себе какую-то дополнительную головную боль.

Пользовательские преимущества SSL по сравнению с TLS настолько очевидны, что их не

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

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

политикой «анти RSA» практически на корню извела криптографическую аутентификацию

пользователей, о которой самое время сейчас поговорить.

Криптографическая аутентификация пользователей

Интуитивно ясно: логин и пароль – вот и аутентификация. Только уж больно ненадежная, мало ли было сообщений «о взломе электронной почты», а все отчего: от того, что там вся

аутентификация – логин и пароль.

Например, для банковской системы надо что-то понадежнее. А что? Сразу вспоминаем:

«на ваш мобильный телефон направлен код подтверждения». Такую аутентификацию во всем

мире принято именовать OTP – One Time Password. Одноразовый пароль. Надежная? Да, безусловно. А удобная и вообще работоспособная? Только если мобильный телефон работает. А

если нет мобильной связи?

6 лет я жил в Сеуле, а там российские мобильные телефоны не работают. Да и в России, в

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

проблемы с мобильником. Как быть?

Нужно что-то еще, помимо OTP. Ну и как же тут не вспомнить про криптографию и

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

аутентификации. Во всей Южной Корее такая аутентификация широко применяется всеми

банками и, приезжая в Москву, я легко мог работать со своими счетами в корейских банках. А вот

в Сеуле со счетом в Сбербанке – нет, нет мобильной связи. Почему же все российские банки так

любят OTP?

Да потому, что не хотят связывать своих клиентов с российской криптографией, заставлять

их «дружить со Стекляшкой». Растерять можно клиентов из-за такой «дружбы».

Пусть, к примеру, вы захотите использовать криптографическую аутентификацию в своем

Интернет-банкинге, если, конечно, ее ваш банк поддерживает. В этом случае будьте добры: 1) Установите на своем компьютере российский криптопровайдер (небесплатно);

2) Приобретите токен для хранения секретного ключа (тоже небесплатно, а по ценам, в 5

раз выше, чем за такой же токен с вас возьмут в корейском банке);

3) Приобретите головную боль за счет процедуры получения сертификата для подписи.

Ну и будьте готовы ко всяким неожиданностям при работе с банком с использованием

криптографической аутентификации, ибо OTP используют очень многие клиенты банка, а

криптоаутентификация – экзотика.

Криптоаутентификация объективно содержит в себе много технических сложностей, связанных с обеспечением клиентов сертификатами, необходимыми для аутентификации, их

обновлением и отзывом, работой банковского сервера с базой данных клиентских сертификатов и

т.п. А в России эти проблемы значительно усугубляются еще и политикой «анти RSA». Ведь все

перечисленные выше сложности являются общеизвестными, во всем мире их пытаются разрешить

и оптимизировать, но при непременном условии: для подписи используем RSA.

Криптографическая аутентификация уже встроена в упоминавшийся в предыдущем

разделе протокол SSL. То, как сервер будет связываться с клиентом, определяет только сам

сервер. Если без криптоаутентификации, то достаточно только сертификата сервера. Если же

выбрана криптографическая аутентификация, то в протоколе обмена сообщениями между

клиентом и сервером предусмотрена отправка некоторого сообщения, подписанного клиентом, и

сертификата клиента, с помощью которого сервер осуществляет проверку подписи, а перед