Щит и меч в системах ДБО – 2, или как бороться с MITM-атаками и несанкционированным удаленным доступом

    В январе 2013 мы уже писали про универсальное решение для систем ДБО. За прошедший год был совершен ряд переработок, направленных на совершенствование защиты от хищений и увеличение юзабилити.

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

    Итак, напомним, что такое Рутокен PINPad. Это решение класса TrustScreen, способное формировать доверенную среду и визуализировать подписываемый документ перед наложением электронной подписи. Подпись происходит непосредственно на самом устройстве после физического нажатия пользователем соответствующей кнопки на экране. Таким образом, мы защищаемся от атак, совершаемых при помощи средств удаленного управления, подмены содержимого документа при передаче его на подпись (Man-in-the-browser).

    image

    Как можно заметить, мы сделали новый корпус со специальной подставкой, полностью переработали дизайн интерфейсов, а также снабдили устройство дополнительным функционалом.

    Итак, основные моменты:
    • Визуализация документов и их подпись на самом устройстве
    • Реализация отечественных криптографических алгоритмов «на борту устройства»
    • Неизвлекаемые ключи
    • Аппаратный ввод PIN-кода на экране
    • Возможность формирования и подтверждения запроса на сертификат в формате PKCS#10
    • Поддержка формата X.509 и инфраструктуры PKI
    • Отсутствие возможности подписи непроверенных данных
    • Возможность осуществления массовых платежей по «белым» спискам
    • Возможность кэширования PIN-кода
    • Журнал операций для расследования инцидентов
    • Работа с любым браузером через плагин
    • Цветной сенсорный экран

    Теперь покажем, как это все выглядит при использовании.
    Проследуем в наш Демобанк, где для начала работы пройдем процесс регистрации, а именно – сформируем запрос на сертификат.

    Выберем из списка подключенных устройств PINPad:

    image

    Придумаем себе логин:

    image

    Запрос отображается на экране и, если мы согласны, нажимаем галочку и вводим PIN-код:

    image

    image

    Теперь авторизация. Выбираем наш сертификат, смотрим на экране с каким сертификатом происходит вход и по какому адресу.

    image

    Соглашаемся и вводим PIN-код на устройстве для авторизации:

    image

    Заметим, что регистрация и аутентификация происходят посредством подписи случайных данных на устройстве в формате CMS c отображением на экране устройства запроса.

    В Демобанке есть реализация белого списка, в который занесены контрагенты, с которыми мы постоянно работаем и полностью им доверяем.

    image

    Что означает восклицательный знак у платежки? В данном случае реализовано визуальное подтверждение платежа для респондентов не из белого списка и подтверждение платежа с суммой, превышающей 100 000 рублей. Такие платежи требуют визуализации и дополнительного подтверждения с помощью Рутокен PINPad.

    image

    Если мы будем проводить массовый платеж из 4-х платежек, то две из них, не отмеченные восклицательным знаком, будут подписаны без визуализации, а остальные две выведены на экран PINPad:

    image

    В случае подмены платежного документа злоумышленником, на экране устройства мы замечаем неверные реквизиты и отклоняем платеж:

    image

    Если же все ОК, то подписываем платежное поручение, формируется подпись, затем все данные шифруются и отправляются на сервер:

    image

    После просмотра и подтверждения сформирована подпись в формате CMS:

    image
    image

    Заметим, что в зависимости от выбранной политики безопасности есть возможность кэшировать PIN-код при авторизации и использовать в сессии этот кэш, не запрашивая PIN-код при каждой операции.

    В качестве заключения:

    Представленное решение способно максимально защитить счета пользователей от различных видов угроз, в том числе связанных с удаленным управлением и подменой документов. Также PINPad позволяет реализовать безопасные массовые платежи, организовывать расследование инцидентов.
    В настоящее время ведутся работы по поддержке Рутокен PINPad в наиболее распространенных системах ДБО и ряде банков.
    «Актив»
    47,00
    Компания
    Поделиться публикацией

    Комментарии 97

      +5
      1. Поддержка в линуксах?
      2. Защита от повторной отправки?

      И я только что придумал довольно забавный вариант атаки:

      Алиса должна заплатить Еве через Боба (банк)
      Ева контролирует канал связи между Алисой и Бобом.
      Ева пропускает запрос к Алисе.
      Алиса подписывает запрос. Ева подменяет запрос невалидным и сохраняет оригинал у себя.
      Боб отвергает запрос Алисы.
      Ева требует от Алисы оплаты.
      Алиса снова отправляет запрос Бобу.
      Ева отправляет первый запрос из сохранённого оригинала.
      Ева пропускает второй запрос.

      Итог: У Евы x2 денег, а Боб утверждает, что Алиса дважды подряд отправила два запроса на перевод средств.
        0
        Но Ева же переслала Бобу невалидный ответ от Алисы в превом случае… Значит отправка валидного теперь ничего не даст
          +1
          Это не обязательно сообщение прикладного уровня. Ева вполне может ничего не послать Бобу, а Алисе показать ложное сообщение об ошибке (благо, для этого достаточно всего лишь послать RST в TCP-поток).
          +1
          Спасибо за вопрос.
          1. Легко, например через кроссплатформенный Плагин
          2. Девайс сам по себе не защитит от такой атаки, но подразумевается его использование в комплексе с банковской системой fraud-анализа.
          Плюс, отправка платежа злоумышленнику невозможна, скорее, это некое вредительство: отправка лишнего платежа валидному пользователю из «белого списка».
            +1
            Что линукс хорошо. Что нет исходных текстов плагина — плохо. Я сейчас даже не про Free Software, я про Open Source. Без открытого исходного текста никому не понятно — есть там бэкдор или нет.

            Как фрод-система может поймать две транзакции как подозрительные, если одна — не подозрительная?

            Описанная атака — это не вредительство, это чистой воды мошенничество (со стороны конагента).

            Кстати, если девайс не защитит от подобной атаки, значит, у него нет криптоканала до банка, то есть обмен идёт сообщениями через контролируемый злоумышленником канал. (Я ожидал ответа про то, что между устройством и банком защищённый канал).
              0
              В подпись можно добавить метку времени. У двух разных подписей будет разное время. 2 платежки с одинаковым временем не принимаются.
                0
                В описанной атаке Алиса подписывает две разные платёжки с разным временем.
                  0
                  Пардон, не так прочитал. Метки времени — это от повторной отправки одной и той же подписанной платежки.
                    0
                    А почему платёжка будет та же самая?

                    Я же описываю простой сценарий: не удалось отправить платёжку. Бухгалтер идёт и пробует ещё раз (то есть выписывает ещё одну).

                    Вся соль атаки не в том, что можно уговорить бухгалтера, а в том, что платёжку можно отправить позже и устройство позволяет отправить «да, платите» без получения подтверждения о приёме (то есть нет неотказуемости).
                      0
                      Уведомления о приеме — это логика системы, а не устройства. Сервер может присылать подписанные уведомления о приеме платежа, которые могут проверяться на устройстве и требовать от бухгалтера подписать подтверждение. И только после получения подтверждения запускать транзакцию.
                        0
                        Вы сейчас пытаетесь изобрести криптопротокол с неотказуемостью. В описанной вами схеме злоумышленник задерживает «подписанное подтверждение», добивается повторной транзакции и после этого отправляет в систему ранее задержанное подписанное подтверждение.

                        Неотказуемость делается не так.
                          0
                          Получается, что на сервер пришли сначала 2 платежки, потом 2 подтверждения. Это как раз может навести антифрод на мысль об атаке. И он прервет обе транзакции. До выяснения.

                          Я не претендую на изобретение протокола :)
                        +1
                        Вообще не понял, зачем ему выписывать еще одну платежку с другим номером? Он ту же самую и будет отправлять, пока успеха не будет.
                        Вы в ДБО для юрлиц когда-нибудь работали?
                          +2
                          Так не банк выпишет, а злоумышленник. Подразумевается, что браузер уже под контролем и в списке платежей дубль можно скрыть.
                            0
                            Банк выпишет? Серьезно?
                              0
                              Так банк об этой платежке знать ничего не будет. Соответственно с его точки зрения придет левая корректно подписанная платежка. Антифрод ее не должен пропустить.
                                0
                                Злоумышленник через банк выставит второй счёт на оплату. С тем же основанием, датой, суммой. Почему банк должен посчитать это подозрительным?
                                  0
                                  Ок, выставил злоумышленник платежку. А каким образом она будет подписана?
                                    0
                                    А как первая платёжка подписывается?
                                      0
                                      Как описано в статье, например
                                        0
                                        Так мы и обсуждаем атаку, когда бухгалтер два раза подпишет разные платёжки, посчитав, что это одна и та же, и что первая подпись не прошла — ниже
                                          +1
                                          Так а в чём вэлью такой атаки?

                                          1. Вы сами написали, что «Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.»

                                          Если много платежей, значит это проверенный контрагент, вы с ним работаете продолжительное время и он будет в белом списке. Визуализации платежек для него вообще не будет. Долговременный партнер потихоньку таскает у вас деньги? Зачем? Чтобы украсть один\два лишних платежа? Плюс, это вскроется при первом же аудите. Быстро скрыться у него не выйдет.

                                          2. «Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтвердил платёж 293, а теперь устройство просит подтвердить 294. Как так?»

                                          Совершенно верно, бухгалтер заметит, что платежка другая и не будет ее проводить.
                                            0
                                            Это я и пытался доказать 404 amarao, а он пытался доказать, что теоретически атака возможна. По-хорошему, если девайс позиционирует себя как механизм защиты, он должен исключить все атаки, которые только может. А против такой атаки наверняка что-то можно сделать в рамках формата девайса.
                                              0
                                              Не проблема, можно первым полем показывать номер платежки. Так же можно добавить инфу о предыдущем платеже, то есть подчеркнуть, что предыдущий платеж был на того же респондента.
                                                0
                                                Теоретически всё можно. Вопрос, может ли юзер прямо сейчас взять и включить этот режим. Есть ли такая галочка в настройках.

                                                Кстати, интересно. Пакет с информацией для экранчика формируется и подписывается в банке?
                                                  0
                                                  Да
                    0
                    Когда Плагин пройдет сертификацию ФСБ — это будет достаточной гарантией отсутствия закладок?

                    Устройство — это часть интернет-банкинга, дополнительная защита, вы думаете, что PINPad напрямую с банком общается чтоли?
                      +3
                      > Когда Плагин пройдет сертификацию ФСБ — это будет достаточной гарантией отсутствия закладок?

                      146 % :)
                        +7
                        Нет, разумеется. Чья-либо сертификация — это выпуск бумажки от том, что сертифицируемое устройство было сертифицировано, то есть для него был выпущен сертификат о том, что устройство сертифицировано.

                        Единственная вызывающая доверия модель — это независимый аудит публично доступных исходных текстов. На этом вся современная криптография базируется.
                          0
                          Вы безусловно правы, но есть одно НО. Мы предлагаем продукт для конкретного рынка с конкретным регулятором. Предлагаю вам при оказии обсудить с ИБ любого банка вопрос значимости сертификата ФСБ в современных реалиях. А также предложить провести независимый аудит) А также рассказать им, как же этот аудит поможет при судебных разбирательствах)
                            +4
                            Вы путаете вопрос юридического соответствия (что надо моей организации чтобы мы в ней все были в белом фраке с блестками) и т.н. sureity (то есть типа уверенность в том что организация отдала деньги за качественный продукт).

                            В идеале это одно и то же.

                            В не-идеале это разные понятия и используются в разном контексте.

                            GPS подсказывает, что я в нахожусь в не-идеальном месте.
                              0
                              Вы в любом случае решение о качестве продукта принимаете на основе некоторого экспертного мнения. Исследованием качества занимаются независимые лаборатории. PINPad тестировался в GROUP-IB.

                              www.rutoken.ru/manual/OpinionGroupIB.pdf
                                0
                                Не вполне согласен. Конечно, в рамках принятия управленческого решения sureity может быть достигнуто экспертной оценкой, но тут масса методологических уловок.

                                Я бы сказал так — я не имею ничего против closed source (и управлял коллективом, работавшим в такой среде, и никто не погиб ;-) ) но лично мое предпочтение на стороне OpenSource решений, тем паче что и зарубежная, и даже российская практика указывают на возможность использования OpenSource в обсуждаемом контексте.
                                  0
                                  забыл маленькое уточнение. Мое предпочтение, оно конечно при соблюдении ceteris paribus
                                    0
                                    А в случае OpenSource вы принимаете решение не на основе экспертного мнения? Только это экспертное мнение неопределенной группы лиц.

                                    p.s. Я не противник OpenSource. Более того, основа Рутокен Плагин — OpenSSL.
                                      0
                                      Строго говоря, OpenSource решение можно подвергнуть экспертизе «определенной группы лиц» вдобавок ко всему. Я же специально дописал что ceteris paribus соблюдается, и все заключения / сертификаты / банты есть у «обеих альтернатив», просто одна еще любезно дает исходники.
                                  0
                                  В РФ юридическое соответствие (сертификат ФСБ) == «sureity».
                                  Мы играем по правилам рынка, а не по идеалистическим концепциям. Не забывайте, это блог коммерческой компании. Так что, боюсь, путаете вы.
                                    +2
                                    Я бы все-таки сказал что сертификат это compliance даже в РФ.

                                    А 2+2 это 4 даже в условиях военного времени.

                                    Никто по-моему кстати не предлагал «заменить» сертификацию на OpenSource'ность, так что я не совсем понимаю причем тут «правила рынка».
                                    Регулятор по-моему открывать исходники не запрещает, разве нет?

                                      0
                                      Ну, 2+2=все что угодно, смотря какое поле и как задать операцию "+")
                                      Но оставим высшую алгебру и вернемся к реалиям. А они таковы, что без сертификата с тобой никто особо не разговаривает) вот и все)
                                        +3
                                        Мне кажется мы немного непонимаем друг друга. Речи о «не-сертификации» не идет.
                                        Без сертификата оно понятное дело никуда, ибо это compliance и за его нарушение могут последовать санкции.

                                        Речь идет о том, что наличие исходников вдобавок к сертификату и заключением лабов было бы очень похвально и увеличивало бы sureity (или если угодно «воспринимаемую sureity» :) )

                                        P.S.:
                                        А насчет + уели, молодец. Ценю.
                                0
                                Есть ли исходные тексты криптопровайдеров компании Microsoft, которые входят в винду?
                                  0
                                  Нет. Потому можно смело быть уверенным, что криптосредства MS ненадёжны. Сравнить с трукриптом, например, или gnupg.
                                    0
                                    Спорно
                                      +3
                                      А при чём здесь исходники криптопровайдера?
                                      Закладка, сохраняющая ключи, может быть хоть в драйвере null.sys.
                                      Алгоритмы хеширования и шифрования детерминированы и другой результат дать не могут — закладки там не в реализации, а в алгоритмах. Остаётся только генераторы СЧ, но поскольку генерация RND, генерация ключа и его использование разнесены, можно RND ксорить с хешем скриншота и получить ту же надёжность, как и при открытых исходниках ms-крипты.
                            0
                            Ева отправляет первый запрос из сохранённого оригинала.

                            Но как она авторизуется, если
                            Заметим, что регистрация и аутентификация происходят посредством подписи случайных данных на устройстве в формате CMS c отображением на экране устройства запроса.

                            Внутрь открытой и авторизованной SSL-сессии Алиса может влезть?
                              0
                              Там есть сессия между устройством и банком? Насколько я понял по описанию, там просто подпись сообщения, а каналы оставлены на откуп компьютеру (то есть потенциальному MitM).
                                0
                                Понятно. Тут уже больше не вопрос, связанный с криптодевайсом, а человеческий фактор.

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

                                Если платежей в «ЗАО Вавилон» мало, то бухгалтер насторожится: он только что подтердил платёж 293, а теперь устройство просит подтвердить 294. Как так?

                                Если платежей в «ЗАО Вавилон» много, то никакой MITM не нужен. Получатель выставляет два счёта и ждёт, что бухгалтер оплатит оба, досконально всё не проверив.
                                  0
                                  В описываемой атаке бухгалтер проверяет операции и видит, что подтверждённая операция не проведена. После этого «пробует ещё раз» (да, десятилетиями сисадмины требовали от пользователей попробовать ещё раз — и в этот раз этому совету снова последуют).

                                  Много-мало платёжек не важно. Это может быть огромная сумма на фоне мелкой текучки, достаточная для того, чтобы компанию несколько месяцев окучивать. Получить её дважды — очень вкусная идея.
                                    0
                                    Спасибо за идею, как же я раньше то не додумался, пойду украду пару\тройку ярдов =)
                            0
                            Насчет «неизвлекаемых ключей»: данные ключи видны внешним стандартным средствам? То есть попадут ли контейнеры ключей на этом устройстве при перечислении всех контейнеров в системе например с помощью стандартных функций MS Crypto API?

                            Смежный вопрос: можно ли эти ключи (и сертификаты, установленные в ключевых контейнерах) использовать сторонними средствами?
                              0
                              Мы предоставляем 3 основных программных интерфейса к устройству: PKCS#11, openssl style интерфейс, Рутокен Плагин.
                              Есть криптопровайдеры (например, СигналКом CSP), которые работают с PKCS#11-совместимыми устройствами. Будем проводить тестирование на совместимость.
                                0
                                То есть можно в обход этого устройства напрямую воспользоваться ключами и осуществить подпись документа? Естественно для этого необходимо знать PIN-код.
                                  0
                                  Нет, нельзя. Ключи неэкспортируемые.
                                    0
                                    Существует ли программный интерфейс, который бы позволил внешней программе вызвать функцию подписи на этом устройстве для произвольных внешних данных?
                                      0
                                      Да. В устройстве есть 2 типа ключей. Ключ без визуализации и ключ с визуализацией. Ключом без визуализации могут быть подписаны произвольные данные.
                                        0
                                        А сертификаты связанные с этим ключевым контейнером ассоциируются с каким типом ключей?
                                          0
                                          Один сертификат ассоциируется с одним закрытым ключом. Вне зависимости от его типа.
                                            0
                                            То есть на самом устройстве на самом деле присутствуют две независимые ключевые пары?
                                            Или под «двумя типами ключей» подразумевается что-то иное?
                                              0
                                              На устройстве может присутствовать столько ключевых пар, сколько памяти хватит. Но вы правы, для удобного использования устройства в случае массовых платежей рекомендуется 2 ключа. На одном подписываются без визуализации «доверенные» платежки, на другом — подозрительные, с визуализацией.
                                                0
                                                Как происходит процесс записи сертификата на устройство?
                                                Я думаю вы предоставляете само устройство сразу с двумя сгенерированными ключами и даёте возможность пользователю сгенерировать собственный сертификат?
                                                  0
                                                  Пользователь сам генерирует ключ, потом формируется подписанный запрос PKCS#10 (устройство умеет «парсить» PKCS#10), потом в устройство импортируется выданный в УЦ сертификат.
                                                    0
                                                    То есть возможен случай, когда сертификат будет сгенерирован для ключевой пары типа «без визуализации»?
                                                      0
                                                      Да
                                                        0
                                                        Операции с ключевой парой типа «с визуализацией» вызывают безусловное отображение данных на экране устройства?
                                                        В любом случае, при любых операциях?
                                                          0
                                                          При подписи. Специальным образом отформатированные данные «загоняются» в устройство. Отображаются, затем от них аппаратно считается хэш, этот хэш подписывается. «Влезть» в устройство между «загоном» данных и вычислением подписи нельзя. Это блокирующая транзакция.
                                                            0
                                                            1. Возможно ли поменять тип ключевой пары с «с визуализацией» на «без визуализации»?
                                                            2. Есть ли разграничение доступа к устройству? Пароль или может быть (а вдруг?) считывание биометрии?
                                                              0
                                                              1. Нет
                                                              2. Я не совсем понял вопрос.
                                                                0
                                                                1. То есть если при первом парсинге PKCS#10 пользователь ошибься и указал другой тип ключевой пары то никакого выхода у него нет? Только стирать существующую ключевую пару и загружать PKCS#10 заново?
                                                                2. Я имею в виду: есть ли пароль на доступ к этому устройству? Или оно просто лежит на столе и любой сотрудник может им воспользоваться?
                                                                  0
                                                                  2. Скриншот «введите pin-код» как бы намекает…
                                                                    0
                                                                    PIN-код — это доступ к ключевому контейнеру. Я же говорю про пароль на устройство в целом.
                                                                    0
                                                                    1. Удалять ключ, заново формировать PKCS#10. Это представляется сложным? Возможность смены атрибута ключа — это дыра в безопасности.
                                                                    2. В каком смысле воспользоваться?
                                                                      0
                                                                      1. Ну и можно раз в год поднапрячься и выбрать ту галочку :)
                                                                        0
                                                                        То есть возможно, что имеющий доступ к устройству может:
                                                                        1. Удалить существующий сертификат и связанный с ним ключевой контейнер с типом «с визуализацией»;
                                                                        2. Повторно загрузить тот же PKCS#10 и сертификат, однако указав тип ключа «без визуализации»;
                                                                        3. Выполнить какие-то не санкционированные действия с помощью этого изменённого ключа;
                                                                        4. Вернуть всё на место (заново присвоив тип «с визуализацией»);
                                                                          0
                                                                          Закрытый ключ неэкспортируемый. Нельзя его сначала создать с меткой «визуализация», потом экспортировать, потом импортировать без метки «визуализация».
                                                                            0
                                                                            То есть я ошибочно понял цитату?
                                                                            Пользователь сам генерирует ключ, потом формируется подписанный запрос PKCS#10 (устройство умеет «парсить» PKCS#10), потом в устройство импортируется выданный в УЦ сертификат.


                                                                            Ключевая пара формируется самим устройством, а не вне его?
                                                                              0
                                                                              Да, ключ генерируется аппаратно, самим устройством. Имелось ввиду, что пользователь сам инициирует этот процесс.
                                                                            0
                                                                            В пункте 1 вы удаляете ключевой контейнер, т.е. ключи, а в п. 2 пытаетесь загрузить PKCS#10 запрос на сертификат для ключа, которого нет в устройстве.
                                                                              0
                                                                              Формально запрос на сертификат может также содержать отдельные поля как для публичного, так и для приватного ключа. Как я уже упомянул ранее, я ошибочно посчитал, что ключи первично генерируются вне устройства.
                                                                                0
                                                                                Только публичного
                                                                                  0
                                                                                  Если вы обрабатываете PKCS#10 с помощью загрузки BASE-64 кодированного сообщения с заголовками (BEGIN CERTIFICATE REQUEST etc.) и обрабатываете его с помощью OpenSSL, то ничего не мешает добавить отдельные разделы «BEGIN PUBLIC KEY» и «BEGIN PRIVATE KEY».
                                    0
                                    Реализация отечественных криптографических алгоритмов «на борту устройства»

                                    Не придется каждый год платить за крипто-про?

                                    На сайте рутокена цена 3400руб., а какие гарантии на устройство?
                                      0
                                      В предлагаемой схеме нет Крипто-Про, зачем же за него платить?)
                                      В устройстве все алгоритмы реализованы на аппаратном уровне. Плагин наш бесплатный. На девайс гарантия 1 год.
                                      0
                                      Какие «документы» может визуализировать устройство?
                                        0
                                        Специальным образом отформатированные
                                          0
                                          То есть никакой речи о том, чтобы подписать pdf или docx, не идет?
                                            0
                                            Устройство имеет два типа ключей — с визуализацией и без. Вторым типом ключей можно подписать произвольные данные.
                                            Все-таки данное устройство специализированное. Ориентировано на подпись текстовых платежек. Если нужно подписать документ формата аля PDF с визуализацией, то мы рекомендуем «вытащить» из него значимые атрибуты, их визуализировать и подписать совместно с невизуализированным документом в прицепе.
                                              0
                                              … дальше пойдет речь о сертификации механизма вытаскивания значимых атрибутов, и мы вернемся к изначальной проблеме доверия к подписываемому документу.
                                                0
                                                Уточните, пожалуйста, на основе каких документов может потребоваться сертификация такого механизма?
                                                  0
                                                  Я не очень знаком с конкретной нормативкой в области ЭЦП, но при анализе решения, которое будет встраиваться в курируемую мной систему я буду требовать доказательств того, что система не позволяет подмены подписываемого документа (т.е. атаки «показали одно, подписали другое»).
                                        0
                                        А как быть пользователям мобильных устройств? Они опять в пролете? Например директор уехал в Париж, а тут срочно нужно подписать пару платежек, у директора есть iPad или Android телефон, что делать?
                                          0
                                          Для мобильных платформ есть другое решение — Рутокен ЭЦП Bluetooth. Его официальный пресс-релиз будет чуть позже, но мы обязательно про него расскажем.
                                            0
                                            Рутокен ЭЦП Bluetooth поддерживает КриптоПро CSP


                                            Ээээ простите, а каким макаром на iOS я поставлю КриптоПро CSP?
                                              0
                                              КриптоПро CSP под Android пока в статусе — несертифицированный, так что его использование сомнительно и я сомневаюсь что его сертифицируют.
                                                0
                                                Есть прецеденты сертификации СКЗИ под Android.
                                                0
                                                КриптоПро CSP — достаточное, но не необходимое условие работы с Рутокен ЭЦП Bluetooth =)

                                                А вообще, инсталляция КриптоПро CSP для iOS производится в составе прикладной программы, разработанной с применением КриптоПро CSP.
                                                  0
                                                  Насколько я понимаю для мобильных устройств обычно задействуют КриптоПро JCP, хотя опыта коммерческого использования этого продукта у меня нет.
                                                    0
                                                    КриптоПро CSP, начиная с версии 3.6 поддерживает iOS с версии 4.2 включительно.
                                                    КриптоПро CSP 4.0 поддерживает Android 3.2+.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое