Всем же понятно, что можно было в драйвер рутокена или в плагин браузера добавить хеширование и ничего бы не изменилось, кроме, возможно, юридического статуса
А для таких проектов зачем хеширование на сервере? Чем не устраивало такое же программное хэширование на клиенте? При этом не надо иметь «супер-доверенный» сервер, клиент должен доверять только самому себе и т.д.
Можете пояснить в чем выигрышь от вашего решения?
Во всяких серьезных применениях так и делают: СРД, отдельная сеть, без доступа в интернет (еще и на аппаратных шифраторах), контроль целостности ОС при старте, т.е. замок, автоматчик, стреляющий в коленку, при попытке слить информацию и т.д. Все это пипец как дорого, а главное — геморрой для конечного пользователя.
Все правильно. Способ защиты всегда зависит от модели угроз.
В данном случае проблема в расширении зоны доверия пользователя на сервер. Это делает саму идею PKI и подпись хэша на клиенте бессмысленным занятием. Т.е. мониторчики и другие способы защиты канала отображения — это вторично :)
Вот, я как раз выше написал про хранение приватного ключа на сервере. Это упростит жизнь клиенту и поднимет безопасность. Зачем в данной схеме токен я вообще не понимаю.
Все равно это противоречит самой идее PKI. Изначально идея состоит в том, чтобы никто, кроме самого клиента, не мог сформировать подпись. Большинство заморочек PKI связаны с генерацией приватного ключа на клиенте. А тут мы расширяем зону доверия на сервер. Если он супер-доверенный, то зачем тогда токен и PKI? Может быть проще было оставить приватный ключ на сервере? При этом безопасность системы только возрастет. Клиент и так полностью доверяет серверу, так как тот для него формирует хэш, т.е. клиент просто подписывает не глядя. Но, нам приходится этот хэш туда-сюда гонять, что снижает безопасность. Проще уж сделать так, чтобы приватный ключ лежал на доверенном сервере: его и защищать проще и хэш не надо передавать. Вопрос только в защите канала, по которому клиенту документ отображается, но его и так надо защищать…
В общем какая-то фиговая идея, на мой взгляд.
Я вообще вижу только один более-менее безопасный вариант, как можно сделать хэширование на доверенном сервере: надо чтобы токен использовался как смарт-карта и сам проводил взаимную аутентификацию с сервером, используя комп, браузер и интернет как недоверенный транспорт. Отдельный сессионный ключ отдать браузеру и использовать его для шифрования транспорта с сервером. И отдельный сессионный ключ использовать для общения непосредственно токена и сервера (получение хэша). Все равно остается уязвимое место — браузер, который может показать пользователю не то, что есть на самом деле, но, по крайней мере, мы не падаем в безопасности относительно модели с локальной подписью на токене.
Как я уже говорил, чтобы избавиться от последнего уязвимого звена, нужно выпустить токены с мониторчиком :)
Да суть не в том, на сколько доверенный сервер. По дороге очень много уязвимых точек. Я не понимаю какая тут модель угроз.
Сама идея использования токенов состоит в том, что если злоумышленник умудрится подсадить вирус на комп (например в процесс браузера), он не сможет достать приватный ключ и подписать какую-нибудь фигню. А тут ему вообще не надо ничего доставать, подписывай сколько угодно чего угодно :)
Может быть где-то есть хотя бы use-case'ы для модели угроз? Вы же что-то анализировали прежде чем разрабатывать.
Мне одному кажется, что тут нарушается сама идея подписи? Клиент читает документ, говорит «ок, вроде все хорошо», отсылает его на какой-то сервер. Тот считает хэш непонятно от чего (от завещания на квартиру клиента) и отправляет обратно. А клиент такой наивный, что подписывает это завещание.
В последнее время все популярней становится идея подписи документа на отдельном устройстве с экраном, которое еще раз показывает документ перед подписью. Чтобы вирус на компе не смог скормить в подписывалку модифицированный документ. А тут клиент какой-то совсем наивный.
Может тогда клиент просто свой приватный ключ серверу отдаст? Пусть он все подписывает и токен не нужен :)
Под «абсолютной криптостойкостью» подразумевается, что если у нас есть идеально-случайная последовательность длинной в сообщение, которую мы передали по идеально защищенному каналу, то xor сообщения с этой последовательностью, никаким криптоанализом нельзя расшифровать, так как он не несет в себе вообще никакой информации об исходном сообщении. Если я не ошибаюсь, это доказал Шенон.
А какие есть криптографические задачи, в которых требуется на столько много случайных чисел, чтобы замедление в 10 раз RNG заметил пользователь? Как правило RNG — это соль, ключи и т.д. т.е. очень небольшие объемы данных.
Если честно, я никогда серьезно не занимался криптоанализом, просто моя работа сильно связана с криптографией. Я бы начал с гугления, возможно это что-то прояснит. Тем не менее, я многократно читал о том, что LCG не является криптографически стойким генератором и применять его в криптографии нельзя (также как MT, WELL и т.д.)
Анализ криптостойкости RNG — нетривиальная область, я тоже был бы рад, если бы кто-нибудь из экспертов написал на хабр цикл статей «криптоанализ для чайников».
Можете пояснить в чем выигрышь от вашего решения?
В данном случае проблема в расширении зоны доверия пользователя на сервер. Это делает саму идею PKI и подпись хэша на клиенте бессмысленным занятием. Т.е. мониторчики и другие способы защиты канала отображения — это вторично :)
В общем какая-то фиговая идея, на мой взгляд.
Как я уже говорил, чтобы избавиться от последнего уязвимого звена, нужно выпустить токены с мониторчиком :)
Сама идея использования токенов состоит в том, что если злоумышленник умудрится подсадить вирус на комп (например в процесс браузера), он не сможет достать приватный ключ и подписать какую-нибудь фигню. А тут ему вообще не надо ничего доставать, подписывай сколько угодно чего угодно :)
Может быть где-то есть хотя бы use-case'ы для модели угроз? Вы же что-то анализировали прежде чем разрабатывать.
В последнее время все популярней становится идея подписи документа на отдельном устройстве с экраном, которое еще раз показывает документ перед подписью. Чтобы вирус на компе не смог скормить в подписывалку модифицированный документ. А тут клиент какой-то совсем наивный.
Может тогда клиент просто свой приватный ключ серверу отдаст? Пусть он все подписывает и токен не нужен :)
Анализ криптостойкости RNG — нетривиальная область, я тоже был бы рад, если бы кто-нибудь из экспертов написал на хабр цикл статей «криптоанализ для чайников».