Комментарии 97
1. Поддержка в линуксах?
2. Защита от повторной отправки?
И я только что придумал довольно забавный вариант атаки:
Алиса должна заплатить Еве через Боба (банк)
Ева контролирует канал связи между Алисой и Бобом.
Ева пропускает запрос к Алисе.
Алиса подписывает запрос. Ева подменяет запрос невалидным и сохраняет оригинал у себя.
Боб отвергает запрос Алисы.
Ева требует от Алисы оплаты.
Алиса снова отправляет запрос Бобу.
Ева отправляет первый запрос из сохранённого оригинала.
Ева пропускает второй запрос.
Итог: У Евы x2 денег, а Боб утверждает, что Алиса дважды подряд отправила два запроса на перевод средств.
2. Защита от повторной отправки?
И я только что придумал довольно забавный вариант атаки:
Алиса должна заплатить Еве через Боба (банк)
Ева контролирует канал связи между Алисой и Бобом.
Ева пропускает запрос к Алисе.
Алиса подписывает запрос. Ева подменяет запрос невалидным и сохраняет оригинал у себя.
Боб отвергает запрос Алисы.
Ева требует от Алисы оплаты.
Алиса снова отправляет запрос Бобу.
Ева отправляет первый запрос из сохранённого оригинала.
Ева пропускает второй запрос.
Итог: У Евы x2 денег, а Боб утверждает, что Алиса дважды подряд отправила два запроса на перевод средств.
Но Ева же переслала Бобу невалидный ответ от Алисы в превом случае… Значит отправка валидного теперь ничего не даст
Спасибо за вопрос.
1. Легко, например через кроссплатформенный Плагин
2. Девайс сам по себе не защитит от такой атаки, но подразумевается его использование в комплексе с банковской системой fraud-анализа.
Плюс, отправка платежа злоумышленнику невозможна, скорее, это некое вредительство: отправка лишнего платежа валидному пользователю из «белого списка».
1. Легко, например через кроссплатформенный Плагин
2. Девайс сам по себе не защитит от такой атаки, но подразумевается его использование в комплексе с банковской системой fraud-анализа.
Плюс, отправка платежа злоумышленнику невозможна, скорее, это некое вредительство: отправка лишнего платежа валидному пользователю из «белого списка».
Что линукс хорошо. Что нет исходных текстов плагина — плохо. Я сейчас даже не про Free Software, я про Open Source. Без открытого исходного текста никому не понятно — есть там бэкдор или нет.
Как фрод-система может поймать две транзакции как подозрительные, если одна — не подозрительная?
Описанная атака — это не вредительство, это чистой воды мошенничество (со стороны конагента).
Кстати, если девайс не защитит от подобной атаки, значит, у него нет криптоканала до банка, то есть обмен идёт сообщениями через контролируемый злоумышленником канал. (Я ожидал ответа про то, что между устройством и банком защищённый канал).
Как фрод-система может поймать две транзакции как подозрительные, если одна — не подозрительная?
Описанная атака — это не вредительство, это чистой воды мошенничество (со стороны конагента).
Кстати, если девайс не защитит от подобной атаки, значит, у него нет криптоканала до банка, то есть обмен идёт сообщениями через контролируемый злоумышленником канал. (Я ожидал ответа про то, что между устройством и банком защищённый канал).
В подпись можно добавить метку времени. У двух разных подписей будет разное время. 2 платежки с одинаковым временем не принимаются.
В описанной атаке Алиса подписывает две разные платёжки с разным временем.
Пардон, не так прочитал. Метки времени — это от повторной отправки одной и той же подписанной платежки.
А почему платёжка будет та же самая?
Я же описываю простой сценарий: не удалось отправить платёжку. Бухгалтер идёт и пробует ещё раз (то есть выписывает ещё одну).
Вся соль атаки не в том, что можно уговорить бухгалтера, а в том, что платёжку можно отправить позже и устройство позволяет отправить «да, платите» без получения подтверждения о приёме (то есть нет неотказуемости).
Я же описываю простой сценарий: не удалось отправить платёжку. Бухгалтер идёт и пробует ещё раз (то есть выписывает ещё одну).
Вся соль атаки не в том, что можно уговорить бухгалтера, а в том, что платёжку можно отправить позже и устройство позволяет отправить «да, платите» без получения подтверждения о приёме (то есть нет неотказуемости).
Уведомления о приеме — это логика системы, а не устройства. Сервер может присылать подписанные уведомления о приеме платежа, которые могут проверяться на устройстве и требовать от бухгалтера подписать подтверждение. И только после получения подтверждения запускать транзакцию.
Вообще не понял, зачем ему выписывать еще одну платежку с другим номером? Он ту же самую и будет отправлять, пока успеха не будет.
Вы в ДБО для юрлиц когда-нибудь работали?
Вы в ДБО для юрлиц когда-нибудь работали?
Так не банк выпишет, а злоумышленник. Подразумевается, что браузер уже под контролем и в списке платежей дубль можно скрыть.
Банк выпишет? Серьезно?
Так банк об этой платежке знать ничего не будет. Соответственно с его точки зрения придет левая корректно подписанная платежка. Антифрод ее не должен пропустить.
Злоумышленник через банк выставит второй счёт на оплату. С тем же основанием, датой, суммой. Почему банк должен посчитать это подозрительным?
Ок, выставил злоумышленник платежку. А каким образом она будет подписана?
А как первая платёжка подписывается?
Как описано в статье, например
Так мы и обсуждаем атаку, когда бухгалтер два раза подпишет разные платёжки, посчитав, что это одна и та же, и что первая подпись не прошла — ниже
Так а в чём вэлью такой атаки?
1. Вы сами написали, что «Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.»
Если много платежей, значит это проверенный контрагент, вы с ним работаете продолжительное время и он будет в белом списке. Визуализации платежек для него вообще не будет. Долговременный партнер потихоньку таскает у вас деньги? Зачем? Чтобы украсть один\два лишних платежа? Плюс, это вскроется при первом же аудите. Быстро скрыться у него не выйдет.
2. «Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтвердил платёж 293, а теперь устройство просит подтвердить 294. Как так?»
Совершенно верно, бухгалтер заметит, что платежка другая и не будет ее проводить.
1. Вы сами написали, что «Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.»
Если много платежей, значит это проверенный контрагент, вы с ним работаете продолжительное время и он будет в белом списке. Визуализации платежек для него вообще не будет. Долговременный партнер потихоньку таскает у вас деньги? Зачем? Чтобы украсть один\два лишних платежа? Плюс, это вскроется при первом же аудите. Быстро скрыться у него не выйдет.
2. «Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтвердил платёж 293, а теперь устройство просит подтвердить 294. Как так?»
Совершенно верно, бухгалтер заметит, что платежка другая и не будет ее проводить.
Это я и пытался доказать 404 amarao, а он пытался доказать, что теоретически атака возможна. По-хорошему, если девайс позиционирует себя как механизм защиты, он должен исключить все атаки, которые только может. А против такой атаки наверняка что-то можно сделать в рамках формата девайса.
Когда Плагин пройдет сертификацию ФСБ — это будет достаточной гарантией отсутствия закладок?
Устройство — это часть интернет-банкинга, дополнительная защита, вы думаете, что PINPad напрямую с банком общается чтоли?
Устройство — это часть интернет-банкинга, дополнительная защита, вы думаете, что PINPad напрямую с банком общается чтоли?
> Когда Плагин пройдет сертификацию ФСБ — это будет достаточной гарантией отсутствия закладок?
146 % :)
146 % :)
Нет, разумеется. Чья-либо сертификация — это выпуск бумажки от том, что сертифицируемое устройство было сертифицировано, то есть для него был выпущен сертификат о том, что устройство сертифицировано.
Единственная вызывающая доверия модель — это независимый аудит публично доступных исходных текстов. На этом вся современная криптография базируется.
Единственная вызывающая доверия модель — это независимый аудит публично доступных исходных текстов. На этом вся современная криптография базируется.
Вы безусловно правы, но есть одно НО. Мы предлагаем продукт для конкретного рынка с конкретным регулятором. Предлагаю вам при оказии обсудить с ИБ любого банка вопрос значимости сертификата ФСБ в современных реалиях. А также предложить провести независимый аудит) А также рассказать им, как же этот аудит поможет при судебных разбирательствах)
Вы путаете вопрос юридического соответствия (что надо моей организации чтобы мы в ней все были в белом фраке с блестками) и т.н. sureity (то есть типа уверенность в том что организация отдала деньги за качественный продукт).
В идеале это одно и то же.
В не-идеале это разные понятия и используются в разном контексте.
GPS подсказывает, что я в нахожусь в не-идеальном месте.
В идеале это одно и то же.
В не-идеале это разные понятия и используются в разном контексте.
GPS подсказывает, что я в нахожусь в не-идеальном месте.
Вы в любом случае решение о качестве продукта принимаете на основе некоторого экспертного мнения. Исследованием качества занимаются независимые лаборатории. PINPad тестировался в GROUP-IB.
www.rutoken.ru/manual/OpinionGroupIB.pdf
www.rutoken.ru/manual/OpinionGroupIB.pdf
Не вполне согласен. Конечно, в рамках принятия управленческого решения sureity может быть достигнуто экспертной оценкой, но тут масса методологических уловок.
Я бы сказал так — я не имею ничего против closed source (и управлял коллективом, работавшим в такой среде, и никто не погиб ;-) ) но лично мое предпочтение на стороне OpenSource решений, тем паче что и зарубежная, и даже российская практика указывают на возможность использования OpenSource в обсуждаемом контексте.
Я бы сказал так — я не имею ничего против closed source (и управлял коллективом, работавшим в такой среде, и никто не погиб ;-) ) но лично мое предпочтение на стороне OpenSource решений, тем паче что и зарубежная, и даже российская практика указывают на возможность использования OpenSource в обсуждаемом контексте.
В РФ юридическое соответствие (сертификат ФСБ) == «sureity».
Мы играем по правилам рынка, а не по идеалистическим концепциям. Не забывайте, это блог коммерческой компании. Так что, боюсь, путаете вы.
Мы играем по правилам рынка, а не по идеалистическим концепциям. Не забывайте, это блог коммерческой компании. Так что, боюсь, путаете вы.
Я бы все-таки сказал что сертификат это compliance даже в РФ.
А 2+2 это 4 даже в условиях военного времени.
Никто по-моему кстати не предлагал «заменить» сертификацию на OpenSource'ность, так что я не совсем понимаю причем тут «правила рынка».
Регулятор по-моему открывать исходники не запрещает, разве нет?
А 2+2 это 4 даже в условиях военного времени.
Никто по-моему кстати не предлагал «заменить» сертификацию на OpenSource'ность, так что я не совсем понимаю причем тут «правила рынка».
Регулятор по-моему открывать исходники не запрещает, разве нет?
Ну, 2+2=все что угодно, смотря какое поле и как задать операцию "+")
Но оставим высшую алгебру и вернемся к реалиям. А они таковы, что без сертификата с тобой никто особо не разговаривает) вот и все)
Но оставим высшую алгебру и вернемся к реалиям. А они таковы, что без сертификата с тобой никто особо не разговаривает) вот и все)
Мне кажется мы немного непонимаем друг друга. Речи о «не-сертификации» не идет.
Без сертификата оно понятное дело никуда, ибо это compliance и за его нарушение могут последовать санкции.
Речь идет о том, что наличие исходников вдобавок к сертификату и заключением лабов было бы очень похвально и увеличивало бы sureity (или если угодно «воспринимаемую sureity» :) )
P.S.:
А насчет + уели, молодец. Ценю.
Без сертификата оно понятное дело никуда, ибо это compliance и за его нарушение могут последовать санкции.
Речь идет о том, что наличие исходников вдобавок к сертификату и заключением лабов было бы очень похвально и увеличивало бы sureity (или если угодно «воспринимаемую sureity» :) )
P.S.:
А насчет + уели, молодец. Ценю.
Есть ли исходные тексты криптопровайдеров компании Microsoft, которые входят в винду?
Нет. Потому можно смело быть уверенным, что криптосредства MS ненадёжны. Сравнить с трукриптом, например, или gnupg.
Спорно
А при чём здесь исходники криптопровайдера?
Закладка, сохраняющая ключи, может быть хоть в драйвере null.sys.
Алгоритмы хеширования и шифрования детерминированы и другой результат дать не могут — закладки там не в реализации, а в алгоритмах. Остаётся только генераторы СЧ, но поскольку генерация RND, генерация ключа и его использование разнесены, можно RND ксорить с хешем скриншота и получить ту же надёжность, как и при открытых исходниках ms-крипты.
Закладка, сохраняющая ключи, может быть хоть в драйвере null.sys.
Алгоритмы хеширования и шифрования детерминированы и другой результат дать не могут — закладки там не в реализации, а в алгоритмах. Остаётся только генераторы СЧ, но поскольку генерация RND, генерация ключа и его использование разнесены, можно RND ксорить с хешем скриншота и получить ту же надёжность, как и при открытых исходниках ms-крипты.
Ева отправляет первый запрос из сохранённого оригинала.
Но как она авторизуется, если
Заметим, что регистрация и аутентификация происходят посредством подписи случайных данных на устройстве в формате CMS c отображением на экране устройства запроса.
Внутрь открытой и авторизованной SSL-сессии Алиса может влезть?
Там есть сессия между устройством и банком? Насколько я понял по описанию, там просто подпись сообщения, а каналы оставлены на откуп компьютеру (то есть потенциальному MitM).
Понятно. Тут уже больше не вопрос, связанный с криптодевайсом, а человеческий фактор.
В любом случае, банк фиксирует два платежа, и можно обжаловать в суде, попросив показать, на каком основании (договора и т.п.) они сделаны. Поэтому интересен только случай, когда получатель быстро сматывается с деньгами.
Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтердил платёж 293, а теперь устройство просит подтвердить 294. Как так?
Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.
В любом случае, банк фиксирует два платежа, и можно обжаловать в суде, попросив показать, на каком основании (договора и т.п.) они сделаны. Поэтому интересен только случай, когда получатель быстро сматывается с деньгами.
Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтердил платёж 293, а теперь устройство просит подтвердить 294. Как так?
Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.
В описываемой атаке бухгалтер проверяет операции и видит, что подтверждённая операция не проведена. После этого «пробует ещё раз» (да, десятилетиями сисадмины требовали от пользователей попробовать ещё раз — и в этот раз этому совету снова последуют).
Много-мало платёжек не важно. Это может быть огромная сумма на фоне мелкой текучки, достаточная для того, чтобы компанию несколько месяцев окучивать. Получить её дважды — очень вкусная идея.
Много-мало платёжек не важно. Это может быть огромная сумма на фоне мелкой текучки, достаточная для того, чтобы компанию несколько месяцев окучивать. Получить её дважды — очень вкусная идея.
Насчет «неизвлекаемых ключей»: данные ключи видны внешним стандартным средствам? То есть попадут ли контейнеры ключей на этом устройстве при перечислении всех контейнеров в системе например с помощью стандартных функций MS Crypto API?
Смежный вопрос: можно ли эти ключи (и сертификаты, установленные в ключевых контейнерах) использовать сторонними средствами?
Смежный вопрос: можно ли эти ключи (и сертификаты, установленные в ключевых контейнерах) использовать сторонними средствами?
Мы предоставляем 3 основных программных интерфейса к устройству: PKCS#11, openssl style интерфейс, Рутокен Плагин.
Есть криптопровайдеры (например, СигналКом CSP), которые работают с PKCS#11-совместимыми устройствами. Будем проводить тестирование на совместимость.
Есть криптопровайдеры (например, СигналКом CSP), которые работают с PKCS#11-совместимыми устройствами. Будем проводить тестирование на совместимость.
То есть можно в обход этого устройства напрямую воспользоваться ключами и осуществить подпись документа? Естественно для этого необходимо знать PIN-код.
Нет, нельзя. Ключи неэкспортируемые.
Существует ли программный интерфейс, который бы позволил внешней программе вызвать функцию подписи на этом устройстве для произвольных внешних данных?
Да. В устройстве есть 2 типа ключей. Ключ без визуализации и ключ с визуализацией. Ключом без визуализации могут быть подписаны произвольные данные.
А сертификаты связанные с этим ключевым контейнером ассоциируются с каким типом ключей?
Один сертификат ассоциируется с одним закрытым ключом. Вне зависимости от его типа.
То есть на самом устройстве на самом деле присутствуют две независимые ключевые пары?
Или под «двумя типами ключей» подразумевается что-то иное?
Или под «двумя типами ключей» подразумевается что-то иное?
На устройстве может присутствовать столько ключевых пар, сколько памяти хватит. Но вы правы, для удобного использования устройства в случае массовых платежей рекомендуется 2 ключа. На одном подписываются без визуализации «доверенные» платежки, на другом — подозрительные, с визуализацией.
Как происходит процесс записи сертификата на устройство?
Я думаю вы предоставляете само устройство сразу с двумя сгенерированными ключами и даёте возможность пользователю сгенерировать собственный сертификат?
Я думаю вы предоставляете само устройство сразу с двумя сгенерированными ключами и даёте возможность пользователю сгенерировать собственный сертификат?
Пользователь сам генерирует ключ, потом формируется подписанный запрос PKCS#10 (устройство умеет «парсить» PKCS#10), потом в устройство импортируется выданный в УЦ сертификат.
То есть возможен случай, когда сертификат будет сгенерирован для ключевой пары типа «без визуализации»?
Да
Операции с ключевой парой типа «с визуализацией» вызывают безусловное отображение данных на экране устройства?
В любом случае, при любых операциях?
В любом случае, при любых операциях?
При подписи. Специальным образом отформатированные данные «загоняются» в устройство. Отображаются, затем от них аппаратно считается хэш, этот хэш подписывается. «Влезть» в устройство между «загоном» данных и вычислением подписи нельзя. Это блокирующая транзакция.
1. Возможно ли поменять тип ключевой пары с «с визуализацией» на «без визуализации»?
2. Есть ли разграничение доступа к устройству? Пароль или может быть (а вдруг?) считывание биометрии?
2. Есть ли разграничение доступа к устройству? Пароль или может быть (а вдруг?) считывание биометрии?
1. Нет
2. Я не совсем понял вопрос.
2. Я не совсем понял вопрос.
1. То есть если при первом парсинге PKCS#10 пользователь ошибься и указал другой тип ключевой пары то никакого выхода у него нет? Только стирать существующую ключевую пару и загружать PKCS#10 заново?
2. Я имею в виду: есть ли пароль на доступ к этому устройству? Или оно просто лежит на столе и любой сотрудник может им воспользоваться?
2. Я имею в виду: есть ли пароль на доступ к этому устройству? Или оно просто лежит на столе и любой сотрудник может им воспользоваться?
2. Скриншот «введите pin-код» как бы намекает…
1. Удалять ключ, заново формировать PKCS#10. Это представляется сложным? Возможность смены атрибута ключа — это дыра в безопасности.
2. В каком смысле воспользоваться?
2. В каком смысле воспользоваться?
1. Ну и можно раз в год поднапрячься и выбрать ту галочку :)
То есть возможно, что имеющий доступ к устройству может:
1. Удалить существующий сертификат и связанный с ним ключевой контейнер с типом «с визуализацией»;
2. Повторно загрузить тот же PKCS#10 и сертификат, однако указав тип ключа «без визуализации»;
3. Выполнить какие-то не санкционированные действия с помощью этого изменённого ключа;
4. Вернуть всё на место (заново присвоив тип «с визуализацией»);
1. Удалить существующий сертификат и связанный с ним ключевой контейнер с типом «с визуализацией»;
2. Повторно загрузить тот же PKCS#10 и сертификат, однако указав тип ключа «без визуализации»;
3. Выполнить какие-то не санкционированные действия с помощью этого изменённого ключа;
4. Вернуть всё на место (заново присвоив тип «с визуализацией»);
Закрытый ключ неэкспортируемый. Нельзя его сначала создать с меткой «визуализация», потом экспортировать, потом импортировать без метки «визуализация».
В пункте 1 вы удаляете ключевой контейнер, т.е. ключи, а в п. 2 пытаетесь загрузить PKCS#10 запрос на сертификат для ключа, которого нет в устройстве.
Реализация отечественных криптографических алгоритмов «на борту устройства»
Не придется каждый год платить за крипто-про?
На сайте рутокена цена 3400руб., а какие гарантии на устройство?
Какие «документы» может визуализировать устройство?
Специальным образом отформатированные
То есть никакой речи о том, чтобы подписать pdf или docx, не идет?
Устройство имеет два типа ключей — с визуализацией и без. Вторым типом ключей можно подписать произвольные данные.
Все-таки данное устройство специализированное. Ориентировано на подпись текстовых платежек. Если нужно подписать документ формата аля PDF с визуализацией, то мы рекомендуем «вытащить» из него значимые атрибуты, их визуализировать и подписать совместно с невизуализированным документом в прицепе.
Все-таки данное устройство специализированное. Ориентировано на подпись текстовых платежек. Если нужно подписать документ формата аля PDF с визуализацией, то мы рекомендуем «вытащить» из него значимые атрибуты, их визуализировать и подписать совместно с невизуализированным документом в прицепе.
А как быть пользователям мобильных устройств? Они опять в пролете? Например директор уехал в Париж, а тут срочно нужно подписать пару платежек, у директора есть iPad или Android телефон, что делать?
Для мобильных платформ есть другое решение — Рутокен ЭЦП Bluetooth. Его официальный пресс-релиз будет чуть позже, но мы обязательно про него расскажем.
Рутокен ЭЦП Bluetooth поддерживает КриптоПро CSP
Ээээ простите, а каким макаром на iOS я поставлю КриптоПро CSP?
КриптоПро CSP под Android пока в статусе — несертифицированный, так что его использование сомнительно и я сомневаюсь что его сертифицируют.
КриптоПро CSP — достаточное, но не необходимое условие работы с Рутокен ЭЦП Bluetooth =)
А вообще, инсталляция КриптоПро CSP для iOS производится в составе прикладной программы, разработанной с применением КриптоПро CSP.
А вообще, инсталляция КриптоПро CSP для iOS производится в составе прикладной программы, разработанной с применением КриптоПро CSP.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Щит и меч в системах ДБО – 2, или как бороться с MITM-атаками и несанкционированным удаленным доступом