Поддержкой стандарта PKCS#11 для российской криптографии занимается технический комитет по стандартизации «Криптографическая защита информации» (ТК 26).
Если говорить о токенах с поддержкой российский криптографии, то можно говорить о программных токенах, программно-аппаратных токенах и аппаратнах токенах.
Криптографические токены обеспечивают как хранение сертификатов и ключевых пар (открытого и закрытого ключа), так и выполнение криптографических операций с соответствии со стандартом PKCS#11. Слабым звеном здесь является хранение закрытого ключа. Если пропал открытый ключ, то его всегда можно восстановить по закрытому ключу или взять из сертификата. Пропажа/уничтожение закрытого ключа имеет печальные последствия, например, вы не сможете расшифровать зашифрованные на вашем открытом ключе файлы, не сможете поставить электронную подпись (ЭП). Для формирования ЭП вам потребуется сгенерить новую ключевую пару и за определенные деньги получить новый сертификат на одном из удостоверяющих центров.
Выше мы упоминали программные, программно-аппаратные и аппаратные токены. Но можно рассматривать еще один вид криптографического токена – облачный.
Сегодня уже никого не удивишь облачной флэшкой. Все преимущества и недостатки облачной флэшки практически один в один присущи и облачному токену.
Главное здесь безопасность хранимых в облачном токене данных, прежде всего, закрытых ключей. Может ли это облачный токен обеспечить? Мы говорим – ДА!
И так как работает облачный токен? Первым шагом является регистрация клиента в облаке токенов. Для этого должна быть предусмотрена утилита, которая позволяет получить доступ к облаку, и зарегистрировать в нем свой логин/nickname.
После регистрации в облаке пользователь должен проинициализировать свой токен, а именно установить метку токена и самое важное установить SO-PIN и пользовательский PIN-коды. Эти операции должны проводиться только по защищенному/шифрованному каналу. Для инициализации токена используется утилита pk11conf. Для шифрования канала предлагается использовать алгоритм шифрования Магма-CTR (ГОСТ Р 34.13-2015).
Для выработки согласованного ключа, на основе которого будет защищаться/шифроваться трафик между клиентом и сервером, предлагается использовать рекомендованный ТК 26 протокол SESPAKE — протокол выработки общего ключа с аутентификацией на основе пароля.
В качестве пароля, на основе которого будет вырабатываться общий ключ, предлагается использовать механизм одноразовых паролей. Поскольку мы говорим о российской криптографии, то, естественно, генерировать одноразовые пароли с использованием механизмов CKM_GOSTR3411_12_256_HMAC, CKM_GOSTR3411_12_512_HMAC или CKM_GOSTR3411_HMAC.
Использование данного механизма гарантирует, что доступ к объектам персонального токена в облаке через SO и USER PIN-коды доступен только пользователю, который их установил с помощью утилиты pk11conf.
Все, после выполнения этих действий, облачный токен готов к использованию. Для доступа в облачному токену достаточно установить на PC библиотеку LS11CLOUD. При использовании облачного токена в приложениях на платформах Android и iOS предусматривается соответствующее SDK. Именно эта библиотека будет указываться при подключении облачного токена в браузере Redfox или прописываться в файле pkcs11.txt для google-chrome. Библиотека LS11CLOUD взаимодействует с токеном в облаке также по защищенному каналу на базе SESPAKE, создаваемому при вызове функции PKCS#11 C_Initialize!
Вот и все, теперь можно заказывать сертификат, устанавливать его в свой облачный токен и идти на сайт госуслуг.
Комментарии (19)
sumanai
26.10.2016 16:52+2Хранить закрытый ключ в облаке? Спасибо, не нужно.
saipr
26.10.2016 19:07А пароль/код банковской карты в банке хранить нормально? Т.е. банку доверять можно, а гособлаку нельзя?
sumanai
26.10.2016 20:48Если банк в открытую хранит мой пароль, то это плохой банк. По идее там должно быть криптостойкое хеширование, чтобы даже утечка хеша не помогла злоумышленникам узнать пароль.
timzi
26.10.2016 18:12Есть возможность использовать RSA в облачном токене?
saipr
26.10.2016 18:12А что мешает?
timzi
26.10.2016 18:35Если в облачном токене можно работать с ключевыми парами и сертификатами RSA, то возможно ли загрузить вашу LS11CLOUD в «обычный Firefox», как библиотеку реализующию интерфейс PKCS#11 для доступа к моим «облачным сертификатам»
saipr
26.10.2016 18:58Загрузить то вы загрузите и сертификаты увидите, но «обычный Firefox» так устроен, что у него часть криптоографических функций включена не только в NSS и токен, но и сам Firefox. Поэтому у вас не пройдет проверка сертификатов. Еще бич Firefox — это кириллица, например пароль с русскими буквами и исправлять клюки они не торопятся, мягко говоря. По этому ставьте Redfox. Но если вы подключите LS11CLOUD в «обычный Google Chrome» (http://soft.lissi.ru/articles/googlechromgost/ ), то вы прекрасно получите доступ в хранилищу сертификатов и сертификаты будут, естественно, проверяться. Но при этом у вас на компьютере должен стоять пакет NSS с поддержкой российцских криптографических интерфейсов.
Да, что касается RSA. Сегодня в LS11CLOUD поддержка RSA не включена. Но если есть желание…
mihmig
27.10.2016 07:01+2Очередной криптографический паразит на теле IT.
Проприетарное, ни с чем не совместимое решение. Любой шаг в сторону — платная поддержка с негарантированным результатом. Проходили.saipr
27.10.2016 09:01Ну это не правда. Речь идет именно о следовании стандарта PKCS#11 v. 2.40!!!
И программисты и приложения видят облачный токен именно как токен стандарта PKCS#11 v. 2.40, включая поддержку российской криптографии в соответствии с рекомендациями ТК-26!!!
ValdikSS
Разве суть токенов не в том, что закрытый ключ находится в неизвлекаемом виде на носителе, и можно физически высунуть токен из порта и быть уверенным, чтобы им не смогут воспользоваться? С вашим подходом получается так, что условный троян может украсть пароль для токена, передать его злоумышленнику, а тот воспользуется им без вашего ведома.
saipr
Если токен вынут из порта и он лежит у вас кармане и вы в этом уверены, то да!
К сожалению у нас токены у нас на 99% используются как флэшки.
Доступ к закрытым объектам облачного токена (как и к любому другому токену) возможен только при условии корректного ввода PIN. Это главный секрет любого токена. А его знает только владелец. Ну и, наверное, самое главное — это доверие к сервису (он может быть и корпоративным), к тому, кто его поддерживает.
Shatun
Кроме доверия к сервису(что тоже далеко неоднозначный момент для такой вещи как токен), еще нужно быть всегда уверенным что никто не узнает твой пароль. Если у меня заведется вирус, который может украсть пароль от токена, который физически у меня,-это не так уж страшно. Никто все равно не сможет сформировать ЭЦП. Однако же в случае облачного токена кража пароля=возможность совершить любое действие от вашего имени.
saipr
Как не пародоксально, кража пароля (я думаю под этим вы имеете ввиду PIN-код токена) и в облачном токене ничего не дает (кстати, кража возможно, если вы его храните на бумаге или другом носителе или проговорились кому-то). Ведь доступ к виртуальному токену проводится не только по логину, но и с использованием одноразового пароля (не путать с PIN-кодом), который даже вы не знаете каким будет в момент обращения к облачному токену.
ValdikSS
Вы говорите о двухфакторной аутентификации, или о чем-то другом?
MonkAlex
«Облачный» токен пиарят для мобильных устройств. Типа с телефона согласовал документ и херак — подписал его своим ключом. В целом закон оно не нарушает конечно, а вот вероятность взлома — хз какая. Тут уже достаточно перехватить ключ к токену, чтобы подписывать за человека…
saipr
А как его перехватить, если обмен идет по шифрованному каналу, в котором для каждого пакета/сообщения используется свой ключ!!!
MonkAlex
Чтобы защитить подпись я должен защитить канал. Оберни защиту в защиту чтобы защищать!
saipr
Саму подпись защищать не надо. Это вещь публичная. Защищать надо PIN-токена, который позволяет получить доступ с закрытому ключу и использовать его для формирования подписи. Да, канал между приложением и облаком защищен.
MonkAlex
Таким образом, надо не только продолжать защищать свой токен (не всегда же облачная подпись доступна), но надо ещё и защищать соединение с облачной подписью. Не только со стороны сервиса, со стороны клиента — тоже. Увеличение уязвимых точек очевидно, а компенсироваться оно может только удобством пользователя.
Я же не против, я просто намекаю на то, что тут тоже есть свои минусы.