ЭЦП - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
После такого вопроса можно закрывать общение.
Развернутый ответ потер, поскольку не вижу с вашей стороны желания или способностей разбираться в сути вопросов.
Вы действительно не знаете, для чего существует ЭЦП? Удивительно.
Видимо, Вы думаете, что сотрудники брокера ходят в систему и делают в ней что хотят без наличия авторизации и контроля прав?
Нет, я не в коем случае так не думаю.
Если честно, то я просто пропустил ваше сообщение пока писал свое (на 6 мин позже опубликовал).
В MetaTrader 5 мы добавим четкий статус каждой торговой операции, чтобы было видно кто совершил операцию:
- трейдер вручную
- трейдер через экспертов
- трейдер через апи
- дилер/менеджер сам
- дилер/менеджер по запросу клиента
- дилер/менеджер в качестве корректировки
- ....
- серверная автоматическая операция свопов
- ....
Статусы будут видны в клиентском терминале и отчетах. Это позволит в большинстве случаев снять проблемы трейдеров с вопросом "кто совершил операцию".И если, все будет на реальном счете работать как Вы сказали, с возможностью просмотра на клиенте, то у меня
действительно больше нет вопросов.
Понятно, что файлы логов надо посылать полностью, а не кусками. Если трейдер изменит хоть один символ, то это сразу будет видно.
Хотя эта функция контрольных сумм ускоряет разбирательства и дает некоторую гарантию корректности присланных логов терминала, но она не является достаточным условием (так как контрольные суммы можно подделать). Все равно финальное решение остается за серверными логами, которые также защищены контрольными суммами для контроля их целостности.
Получается, что контрольные суммы проблемы не решают и даже вводят в заблуждение.
Почему бы не применить механизм ЭЦП (даже необязательно именно ГОСТовой ЭЦП), по крайней мере, для важных операций?
Например, клиентский терминал отсылает запрос, подписанный клиентской ЭЦП, ДЦ-шный сервер, имея сертификат клиента, проверяет, что запрос не подделан и отправлен именно этим клиентом.
Далее, сервер отсылает подверждение, в которое включён и клиентский запрос с клиентской ЭЦП. Это составное подтверждение от сервера подписывается ДЦ-шной ЭЦП.
Теперь у клиента есть подтверждение открытия/модификации/закрытия позиции, подписанное ДЦ-шной ЭЦП.
И теперь любой, в том числе и судья, может взять сертификат ДЦ и убедиться, что клиент не врёт, и подтверждение от ДЦ - подлинное, не подделаное.
Если клиент предоставит свой сертификат, то теперь любой может взять и проверить, что ДЦ не сжульничал и не подделал клиентский запрос, включённый в подтверждение.
В том числе, ДЦ не сможет открыть/модифицировать/закрыть позицию от имени клиента без его, клиента, на то желания.
С практической точки зрения теперь есть гарантия того, что никто не сможет сжульничать в этом месте, ни ДЦ, ни клиент.
Конечно, это несколько увеличит трафик, но, думаю, - совсем незначительно. К тому же, оно того стОит.
Получается, что контрольные суммы проблемы не решают и даже вводят в заблуждение.
Почему бы не применить механизм ЭЦП (даже необязательно именно ГОСТовой ЭЦП), по крайней мере, для важных операций?
Например, клиентский терминал отсылает запрос, подписанный клиентской ЭЦП, ДЦ-шный сервер, имея сертификат клиента, проверяет, что запрос не подделан и отправлен именно этим клиентом.
Далее, сервер отсылает подверждение, в которое включён и клиентский запрос с клиентской ЭЦП. Это составное подтверждение от сервера подписывается ДЦ-шной ЭЦП.
Такое сделать можно (для каждой исходящей транзакции генерировать и сохранять на стороне клиента отдельное подтверждение с цифровой подписью сервера), только вот что делать с массой операций, совершаемых не со стороны клиента?
Это всевозможные ролловеры, активации ордеров, срабатывание стопов, коррекции и тд.
Еще вопрос - в каком формате и кто будет расшифровывать эти цифровые блоки? По всей видимости надо будет нам создать (и предоставлять сервис?) специальный сервер, проверяющий корректность подписей.
Это будет правильное решение.
Вы уже проявили себя. Терпеть бездумных обвинителей мы не будем.
Это не Вам адресовалось. И не по форуму, а по ветке. Хотя Ваша реакция вполне прогнозируемая.
(это не обвинения - это поддержка МТ, если Вы не поняли)
С интересом слежу за веткой, дабы понять, как будут (могут) развиваться отношения МТ5 теми ДЦ, которые уже давно практикуют ЭЦП в своей работе, и не собираются отказываться от этой процедуры. Будет ли ЭЦП камнем преткновения для работы с этими ДЦ с помощью МТ5?
Такое сделать можно (для каждой исходящей транзакции генерировать и сохранять на стороне клиента отдельное подтверждение с цифровой подписью сервера), только вот что делать с массой операций, совершаемых не со стороны клиента?
Это всевозможные ролловеры, активации ордеров, срабатывание стопов, коррекции и тд.
Еще вопрос - в каком формате и кто будет расшифровывать эти цифровые блоки? По всей видимости надо будет нам создать (и предоставлять сервис?) специальный сервер, проверяющий корректность подписей.
Операции, совершаемые не со стороны клиента подписываются ДЦ-шной ЭЦП и передаются клиенту.
У клиента будет доказательство того, что, во-первых, операция совершена, и совершена от имени ДЦ, а, во-вторых, - операция совершена не по инициативе клиента.
В случае ролловеров, активаций ордеров и прочих операций у клиента будет уверенность (и одновременно - доказательство), что информация не искажена и имеет ДЦ-шное авторство (что нормально).
В других же случаях, при попытке сжульничать, например, ДЦ не сможет задать вопрос "а как вы докажете, что это не вы совершили операцию?". Тут и доказывать будет нечего.
Сервис проверки подписи должен быть встроен и в терминал для клиента, и в серверную часть для ДЦ, - это просто утилитарный код и GUI-интерфейс.
Этот утилитарный код, в принципе, должен работать постоянно, проверяя запросы и ответы на подлинность.
Чтобы сервер был "уверен", что общается с клиентом, и - правильным клиентом, а клиент, - что общается именно с сервером.
Плюс дополнительная возможность для пользователя (как клиента, так и ДЦ) - через GUI проверить на подлинность указанную часть лога, в том числе и присланную, например.
Специальный сервер, проверяющий корректность подписей, не нужен.
Сертификат ДЦ доступен с сервера ДЦ и обычно при открытии счёта копируется на компьютер клиента.
Сертификат клиента генерируется во время открытия счёта и копируется на сервер ДЦ.
Однако можно стать Certification Authority для ДЦ и подписывать своим ключом сертификаты, сгенерённые ДЦ. Как послепродажный дополнительный сервис безопасности.
А клиентские сертификаты можно подписывать на ДЦ-шном, то есть, ДЦ будет выступать Certification Authority более низкого уровня для клиента. Как обязательный сервис безопасности для клиента от ДЦ.
Тогда клиент (его терминал) всегда может быть уверен, что сертификат от ДЦ не подделан, проверив его подпись.
И вообще, сжульничать можно будет только, скомпрометировав Certification Authority.
ДЦ-шный сертификат не подделать, потому что он подписан сертификатом Certification Authority, а сертификат клиента - потому что он подписан подлинным, только что проверенным сертификатом ДЦ.
Единственное условие - доступность сертификата Certification Authority (для проверки валидности локальной копии), на котором подписаны ДЦ-шные сертификаты.
Специальный сервер, на котором будет храниться и будет доступен сертификат Certification Authority?
Не думаю, что для этого понадобится специальный сервер.
После такого вопроса можно закрывать общение.
Вот, пожалуста, пользователи делают конкретные предложения по развитию вашего продукта. Что-то новое для вас, занимающихся безопасностью 9 лет. Так может быть не стоит встречать все замечания так агрессивно?Операции, совершаемые не со стороны клиента подписываются ДЦ-шной ЭЦП и передаются клиенту.
У клиента будет доказательство того, что, во-первых, операция совершена, и совершена от имени ДЦ, а, во-вторых, - операция совершена не по инициативе клиента.
В случае ролловеров, активаций ордеров и прочих операций у клиента будет уверенность (и одновременно - доказательство), что информация не искажена и имеет ДЦ-шное авторство (что нормально).
В других же случаях, при попытке сжульничать, например, ДЦ не сможет задать вопрос "а как вы докажете, что это не вы совершили операцию?". Тут и доказывать будет нечего.
Сервис проверки подписи должен быть встроен и в терминал для клиента, и в серверную часть для ДЦ, - это просто утилитарный код и GUI-интерфейс.
Этот утилитарный код, в принципе, должен работать постоянно, проверяя запросы и ответы на подлинность.
Чтобы сервер был "уверен", что общается с клиентом, и - правильным клиентом, а клиент, - что общается именно с сервером.
Спасибо. Только фактически техническая реализация такой "защиты трейдера" превысит сложность самого процесса трейдинга и решая одну проблему, создаст на порядок больше проблем.
Смотрите на проблему шире, а не только со стороны трейдера, который не хочет ничего знать ни про брокера, ни про его процессы и процессы стороны исполнения.
Решением может быть ежедневный/ежемесячный (но никак не моментальный в момент исполнения транзакции) отчет брокера, подписанный цифровой подписью. Например, штатный PDF отчет с интегрированной подписью. Этот документ легко проверяется сторонними программами и не требует привязки к терминалу или другому спецсофту.
Спасибо. Только фактически техническая реализация такой "защиты трейдера" превысит сложность самого процесса трейдинга и решая одну проблему, создаст на порядок больше проблем.
А как же "9 лет занятий безопасностью"?
Причина, скорее, не в технической реализации.
Смотрите на проблему шире, а не только со стороны трейдера, который не хочет ничего знать ни про брокера, ни про его процессы и процессы стороны исполнения.
Я и смотрю шире. Схема Public Key Infrastructure (PKI) доказала свою жизнеспособность.
Решением может быть ежедневный/ежемесячный (но никак не моментальный в момент исполнения транзакции) отчет брокера, подписанный цифровой подписью. Например, штатный PDF отчет с интегрированной подписью. Этот документ легко проверяется сторонними программами и не требует привязки к терминалу или другому спецсофту.
В качестве промежуточного решения может использоваться и схема отложенного подтверждения, однако она всё ещё даёт ДЦ возможность задать клиенту вопрос: "А как вы докажете, что это не вы открыли позицию?".
Однако, видимо, - важно, чтобы серверная часть давала ДЦ такие возможности.
Если так важно иметь формат, понимаемый сторонними программами, то не думаю, что решение не может быть найдено.
Важнее, чтобы было, что экспортировать в этот формат.
А техническая реализация должна быть просто выполнена компетентными людьми.
Если исполнителям не хватает компетенции, значит, надо повысить их компетенцию, например, методом обучения.
Нынче возможности для этого все есть.