Здравствуйте. Возникла задача, решение которой я вижу в абстрактных образах, но не в конкретике. Итак. -Заказчик имеет некое приложение, которое крутится в java-машине. -Приложение гененирует некую строку. -Эта строка должна быть подписана аппаратно(!) и передана по сети на сервер. -Сервер её принимает, проверяет корректность подписи и делает с ней что-то дальше. На данный момент мне надо выбрать аппаратную часть, которая будет заниматься подписью. Мои познания в этой областьи ограничиваются работой со смарт-картами стандарта ACOS-3. В интернете я нашел кое-какие фирмы, предоставляющие электронные устройства, поддерживающие сертифицированные ФСБ (это важно) алгоритмы криптозащиты. Вот только в плане поддержки они какие-то никакие. Не могу выбрать что мне надо. В общем мне нужна "флешка", которую с собой таскает Вася. Он её втыкает в свою банку, заходит в приложение, жмёт кнопки, в конце нажимает "ОК". Прога генерирует строку, передаёт её на подпись во "флешку", после чего по интернету передаёт эту строку+подпись на сервак. Кто имел дело с подобной задачей? Подскажите, пожалуйста, что брать, что качать, что читать. Важно, чтобы java могла легко общаться с устройством безо всяких уродливых костылей. Спасибо.
Обычно делается не так: сервер генерит строку, отдает ее клиенту, клиент подписывает и возвращает серверу. Иначе трафик можно перехватить и каждый раз отдавать серверу одни и те же данные.
_DEN_ Спасибо за ответ. У нас передача будет по HTTPS. Так что трафик не перехватить. Не понимаю, зачем сервер должен что-то слать. Строку подписывать должен клиент, это нужно для того, чтобы он не отвертелся от того, что именно он послал эту строку. Для примера, представьте себе обычный терминал оплаты, который шлёт серверу строку "пополни баланс абонента +79056812242 на сумму 100 руб". Эта строка подписывается закрытым ключом, а на серверной стороне проверяется. У нас не терминалы оплаты, если что, но схема похожая.
HuXTUS Если у тебя уже есть HTTPS, то зачем нужно что-то еще? Достаточно сделать двухстороннюю валидацию при SSL-handshake, и дальше слать по HTTPS сообщения "пополни баланс абонента +79056812242 на сумму 100 руб" безо всяких подписей. В таком случае твоим клиентским "секретом" будет клиентский сертификат.
_DEN_ А если на компе троян? Он узнает пароль Васи и пиши пропало! Теперь троян сможет пополнять любой счёт на любую сумму. Наличие аппаратной части на клиентской стороне гарантирует, что на серверной стороне можно проверить валидность операции.
Скажу проще - заказчик хочет аппаратную подпись. На данный момент я рассматриваю Aladdin'овские токены и RuToken.
HuXTUS Наличие аппаратной части ничего не гарантирует. Если платеж можно сделать, нажав на кнопку руками, то его же можно сделать и сэмулировав те же действия из "трояна". Другое дело - что обычный клиентский сертификат проще украсть и использовать на другом компе. Сертификат можно защитить паролем, однако это, конечно, не спасает от перехвата пароля трояном во время его введения. Было бы хорошо, если бы сам сертификат хранился внутри какого-то девайса-брелка, и был бы доступен по интерфейсу "черного ящика" функциями "расшифровать-зашифровать-подписать-проверить". Чистый HTTPS удобен тем, что не нужно ничего изобретать - все необходимые техники уже есть, если есть HTTPS. Еще, что касается трояна на компе. А что если троян перехватит отправку команды на пополнение счета вместе с ее подписью, и позже отправит ее повторно? В этом случае в тело подписываемых данных придется включать номер транзакции, а на сервере - помнить номера совершённых транзакций. Если же у сервера будет несколько клиентов (что скорее всего и есть), то и это не поможет. Серверу придется предварительно отправлять некий блоб, который нужно добавлять к сообщению и подписывать все вместе. Иначе это опять же не спасает от повторной отправки копии сообщения. То есть, как я себе представляю наиболее защищенный вариант: 1. Устанавливаем соединение с сервером. 2. Отправляем серверу "я хочу сделать платеж". 3. Сервер отвечает рандомным блобом, мол "добавь этот блоб к сообщению и подпиши". 4. Склеиваем сообщение с блобом, подписываем хардварным устройством, имеющим интерфейс черного ящика. 5. Отправляем серверу сообщение и подпись. В самом фантастическом случае нужно помнить, что троян может заинжектить в память какую-то другую сумму, прежде чем сообщение уйдет в устройство на подпись. Нужно убедиться в том, что устройства подписывают данные самостоятельно, внутри себя, через интерфейс черного ящика. Иначе, если в устройстве просто хранится ключ, а подпись делается компом, это ничуть не безопаснее сертификата с паролем, который я описал ранее.
Хотя, все еще проще. Троян может перехватить пароль от устройства (если такой имеется), и далее самостоятельно инициировать соединения на сервер, подписывать сообщения и делать платежи. Чтобы совсем уж все было по-взрослому, устройство на каждую сессию должно просить юзера ввести капчу, которая опять же, генерится и валидируется внутри устройства Если система работает автономно, и капчу вводить некому, и на компе есть троян, то я не вижу принципиальной разницы в безопасности (уязвимости) между хардварным устройством и обычным сертификатом. Чтобы обезопаситься на все 99.999%, нужно грузить операционную систему с read-only устройства и разрешать доступ в инет только к серверу. И этой операционной системе лучше бы быть чем-то отличным от Windows
_DEN_ Да, но только когда токен вставлен. Без него операцию не провести. У нас внутри брелка (это и есть чёрный ящик, см. ниже) будет закрытый ключ, которым будет подписываться строка. Этого достаточно. У сервера планируется куча клиентов, часто совершающих транзакции. Но проблемы с номерами транзакции нет - пара ClientID/Номер_транзакции всякий раз должна быть уникальной. В качестве Номера_транзакции может быть текущее время или случайно сгенерированное число. Обычно смарткарты умеют их генерировать. Именно так. Ради этого смарт-карты и используются. Считается технологически сложным взлом смарт-карты. Можно считать, что заглянуть внутрь и вытащить ключ - невозможно. Внутрь железки попадает строка, подписывается и на выходе из черного ящика появляется подписанная строка. Тут ты прав. Если юзер за компом проводит операцию, токен вставлен, то нет проблемы подменить строку до того, как она будет подписана. На этот случай я пока думаю можно поступать просто: после получения строки сервером и валидации, отправлять её обратно и просить подтверждения "Вы действительно хотите пополнить +76666666666 на 999 руб.?". Впрочем, рассуждая пессимистично, троян и тут может перехватить вывод на экран и заменить текст, или просто жамкнуть "Да". Этот момент в процессе обдумывания. Пароль от устройства это что? И как его можно перехватить, когда в оперативной памяти компа он не мелькает? Перехватить можно PIN-код пользователя (обычно PIN вводят как дополнительный фактор, на случай кражи брелка), потому что он вводится с клавы. Но зная PIN и не владея токеном подписать документ невозможно. Как я уже сказал, у наших заказчиков линукс, но не из соображений безопасности, а потому что так дешевле Зато мне гемора больше. Я рассматриваю скорее не взлом клиентской машины по сети, а специально-заточенную инсайдерскую атаку, когда Петя, работающий с Васей запустит вредоносное ПО на его компе и, потирая руки, будет ждать когда Вася своими руками активирует ящик пандоры. Внимание, вопрос: кто знает как под линуксом слать смарт-картам APDU-команды? Пока не выбрал модель, с которой буду работать, но они все суть - смарт-карты. С ними дело я имел, но в винде. В msdn подробно описано какие API дёргать. Но под линуксом (как всегда) [много ругательных слов].
Я бы предложил все-таки подумать над вариантом с блобом Уникальные номера придется хранить глобально, и видимо в базе, чтобы при перезагрузке сервера они не терялись. И на каждую транзакцию придется лезть в базу, мол "а не было ли уже такой транзакции?". А с блобом проще - его достаточно хранить в памяти, и его время жизни = время жизни одной сессии. Если каждый платеж делается человеком-оператором, то тут спасет капча Ну да, я и имею ввиду PIN - то есть нечто, что нужно ввести с клавиатуры чтобы получить доступ к девайсу. Сценарий такой: троян хукает ввод пина и запоминает его у себя. Троян мониторит наличие девайса в USB, и когда девайс включен, втихую рассылает бабло на нужные счета. По смарткартам под линь, к сожалению, ничего не посоветую. Я сам работал с ними только под винду, и даже под винду мне оно не особо понравилось Попробуй пообщаться напрямую с производителем. Поскольку ты не единичный покупатель, а организация, то есть шанс, что тебе, как оптовику, помогут, расскажут и покажут Я в таких ситуациях напрягаю кастомера чтобы связал меня напрямую с технорями вендора, чтобы пообщаться лично, где и что мне нужно.
Спасибо, подумаю. Всему своё время. На данный момент приоритетная задача - разобраться с самым низким уровнем, т.е. с протоколом взаимодействия софт-ОС-токен, а что будет происходить "наверху" додумаем по ходу дела и, может быть, сто раз ещё передумаем. Спасёт, но пользователи ненавидят капчу, заказчику это не понравится и смарт-карты не умеют генерировать капча-картинки Чтобы заказчик купил, надо ему теоретически обосновать что наше "железное" решение - эфективно и красиво, а рассказ про капчу его напугает. <почти офтоп> Если говорить про капчу и смарт-карты, то есть токены, которые содержат в себе java-машину и в них (теоретически, сам не пробовал) можно загрузить апплет по генерации капчи. Даже если предположить, что это будет сделано, то не факт, что злодей-Петя не сможет написать в своём трояне распознавание. В общем капча это экзотика, а пользователи будут страдать. В теории всё так, правда добавлю, что трояну надо будет ещё и научиться различать разные токены, ведь за комп не обязательно сядет Вася, но может и Алёна с Костей, а у них другой PIN. Но так как у нас сферический троян в вакууме и сценарий самый пессимистичный, будем считать, что он всё это может. А теперь хорошая новость: за машину, на которой линукс отвечаю не я, а какой-то злой админ и он не идиот. Сферический троян под линукс написать можно, но злой админ его всё равно найдёт и дырку закроет. Если на компе троян, это всё же не мои проблемы, а админов. Моя задача сделать ЭЦП с помощью внешнего устройства. А там, хоть трава не расти: проник троян и рассылает поддельные запросы? - сами виноваты. Мне главное гарантировать, что без вставленного токена ничего работать не будет. Квинтэссенция идеи: у кого токен, тот и прав. Если токен у трояна, значит прав троян. Но вытащить ключи из смарт-карты и работать без неё невозможно. На данный момент писал им на мыло и форумы, все молчат. После выходных начну звонить.
HuXTUS можно использовать несвязанное подтверждающее устройство. те, запрос валидируется через устройство не связанное с устройством запроса.
Капча - зло, люди с хорошим-то зрением не всегда могут её распознать.А применение капчи в целях защиты от вирусов это мягко говоря совсем бред. Кстати, я бы картинке предпочёл звук.
Звук? Ага я так и представил в этой роли Microsoft Sam =)))) И чтоб фраза была по сложнее =) Маты обеспечены =)
