Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Госзаказ? Или с каких побуждений реализовали?
Во-первых, неплохо бы указать, что это осмысленно для Украины, потому что аббревиатура ДСТУ не всем знакома.
А во-вторых: вот нажал я sign in with eU, получил непонятную страницу с (неграмотным) вопросом «Website dstu blog want's to know your identity» (я уже в панике, никогда не отвечу Grant на такое), я нажал Grant, появилась некая дроп-зона. И что дальше?
В-третьих, такие вещи имеют смысл, когда они дают логину хоть какую-то юридическую значимость (как нечастная российская ЕСИА). А тут вы предлагаете пользоваться сервисом, предоставляемым неким неопределенным третьим лицом (т.е. нет никаких гарантий, что он предоставляет именно те данные, которые передает пользователь), плюс еще и пользователь не знает, как именно вы будете использовать его сертификат.
Ну и в-четвертых — а как ваш сигнер-бокс работает-то?
А во-вторых: вот нажал я sign in with eU, получил непонятную страницу с (неграмотным) вопросом «Website dstu blog want's to know your identity» (я уже в панике, никогда не отвечу Grant на такое), я нажал Grant, появилась некая дроп-зона. И что дальше?
В-третьих, такие вещи имеют смысл, когда они дают логину хоть какую-то юридическую значимость (как нечастная российская ЕСИА). А тут вы предлагаете пользоваться сервисом, предоставляемым неким неопределенным третьим лицом (т.е. нет никаких гарантий, что он предоставляет именно те данные, которые передает пользователь), плюс еще и пользователь не знает, как именно вы будете использовать его сертификат.
Ну и в-четвертых — а как ваш сигнер-бокс работает-то?
>т.е. нет никаких гарантий, что он предоставляет именно те данные, которые передает пользователь
Вся криптография проверяется у вас на сервере, доверять мне, как третьей стороне совершенно не нужно, в этом и прелесть ЭЦП.
>я нажал Grant, появилась некая дроп-зона. И что дальше?
Спасибо за позитивно-мотивирующий комментарий, над UI работать еще предстоит конечно.
Вся криптография проверяется у вас на сервере, доверять мне, как третьей стороне совершенно не нужно, в этом и прелесть ЭЦП.
>я нажал Grant, появилась некая дроп-зона. И что дальше?
Спасибо за позитивно-мотивирующий комментарий, над UI работать еще предстоит конечно.
Тааак.
Во-первых, на сервере выполняется действительно вся криптография? Т.е. сертификат полностью передается с компьютера пользователя?
Во-вторых, если вся криптография выполняется у меня на сервере, то зачем мне регистрироваться у вас?
Во-первых, на сервере выполняется действительно вся криптография? Т.е. сертификат полностью передается с компьютера пользователя?
Во-вторых, если вся криптография выполняется у меня на сервере, то зачем мне регистрироваться у вас?
>Во-первых, на сервере выполняется действительно вся криптография? Т.е. сертификат полностью передается с компьютера пользователя?
У вас на сервере выполняется проверка подписи. В сигнербоксе происходит ее создание. Поэтому публичный ключ уходит к вам для проверки, а приватный живет на машине пользователя и никуда с нее не ходит.
>Во-вторых, если вся криптография выполняется у меня на сервере, то зачем мне регистрироваться у вас?
Вы можете взять библиотеки и построить это все прямо у себя, но для этого пользователю придется доверять каждому такому сайту свой приватный ключ. Это не есть хорошо.
У вас на сервере выполняется проверка подписи. В сигнербоксе происходит ее создание. Поэтому публичный ключ уходит к вам для проверки, а приватный живет на машине пользователя и никуда с нее не ходит.
>Во-вторых, если вся криптография выполняется у меня на сервере, то зачем мне регистрироваться у вас?
Вы можете взять библиотеки и построить это все прямо у себя, но для этого пользователю придется доверять каждому такому сайту свой приватный ключ. Это не есть хорошо.
пользователю придется доверять каждому такому сайту свой приватный ключ
Вообще-то пользователь не должен доверять свой приватный ключ никакому сайту, включая ваш. Это азы безопасности.
Не доверять приватный ключ софтверу, который этим приватным ключем подписывает данные — это новое слово в криптографии.
При обострении паранои, разумеется можно отключать интернет в момент подписи, чтобы злой жаваскрипт ничего никуда не увел.
На самом деле это все серьезно, но вы как-то очень в недружелюбном и неприятном тоне все пишете, совершенно убивая желание вести с вами нормальную дискусси.
При обострении паранои, разумеется можно отключать интернет в момент подписи, чтобы злой жаваскрипт ничего никуда не увел.
На самом деле это все серьезно, но вы как-то очень в недружелюбном и неприятном тоне все пишете, совершенно убивая желание вести с вами нормальную дискусси.
Закрытый ключ не должен покидать компьютер пользователя (а лучше — токен), поэтому все подписание должно происходить на клиенте. В этом случае нет проблемы доверия — пользователь знает (поскольку используемое ПО сертифицируемо), что его ключ в безопасности, и им не будет подписано что-либо еще.
Вы определитесь, у вас подписание на сервере или на клиенте? А то из разных комментов создается разное впечатление.
Вы определитесь, у вас подписание на сервере или на клиенте? А то из разных комментов создается разное впечатление.
>Вы определитесь, у вас подписание на сервере или на клиенте?
на клиенте, разумеется.
на клиенте, разумеется.
Тогда откуда проблема «пользователю придется доверять каждому такому сайту свой приватный ключ», если закрытый ключ используется только на клиенте, а сайту уходят только зашифрованные данные?
>закрытый ключ используется только на клиенте, а сайту уходят только зашифрованные данные?
Пользователю приходится доверять, что это будет именно так. Это банальный фишинг — показать формочку для сброса ключа, а потом вместо создания подписи просто его утащить к себе.
Пользователю приходится доверять, что это будет именно так. Это банальный фишинг — показать формочку для сброса ключа, а потом вместо создания подписи просто его утащить к себе.
Ни один вменяемый пользователь никогда не будет «сбрасывать» свой ключ куда бы то ни было. Я потому и спрашивал, как это устроено, и с помощью чего вы делаете подпись, что это должно выглядеть (и работать) не так.
Ну если вы *лучше* знаете, что все должно быть не так — сразу бы и сказали. Меньше бы потратили моего и вашего времени, извините.
>Ну и в-четвертых — а как ваш сигнер-бокс работает-то?
Работает достаточно тривиально. Считывает приватный ключ пользователя и подписывает им строку «NONCE|DOMAIN», после чего редиректит обратно на сайт, иницировавший аутентификацию, передавая nonce, подпись и ссылку по которой можно скачать сертификат.
Дальше на сайте-инициаторе происходит проверка соответствия подписи этому сертификату.
Работает достаточно тривиально. Считывает приватный ключ пользователя и подписывает им строку «NONCE|DOMAIN», после чего редиректит обратно на сайт, иницировавший аутентификацию, передавая nonce, подпись и ссылку по которой можно скачать сертификат.
Дальше на сайте-инициаторе происходит проверка соответствия подписи этому сертификату.
Считывает приватный ключ пользователя и подписывает им строку «NONCE|DOMAIN»,
Считывает откуда? Подписывает где?
передавая nonce, подпись и ссылку по которой можно скачать сертификат.
Откуда берется сертификат?
Ну и самое важное: а где гарантия, что сигнер-бокс
(а) передал сайту-инициатору данные реального пользователя, а не кого-то другого
(б) передал данные пользователя сайту-инициатору, а не кому-то другому?
>Считывает откуда? Подписывает где?
Вот в этой непонятном дропзоне и считывает. Подписывает у клиента в браузере.
>(а) передал сайту-инициатору данные реального пользователя, а не кого-то другого
>(б) передал данные пользователя сайту-инициатору, а не кому-то другому?
В данном случае при проверке подпись не сойдется.
Вот в этой непонятном дропзоне и считывает. Подписывает у клиента в браузере.
>(а) передал сайту-инициатору данные реального пользователя, а не кого-то другого
>(б) передал данные пользователя сайту-инициатору, а не кому-то другому?
В данном случае при проверке подпись не сойдется.
Подписывает у клиента в браузере.
С помощью чего? В каких браузерах это работает?
В данном случае при проверке подпись не сойдется.
Почему же?
В первом сценарии ничто не мешает вашему сервису использовать закрытый ключ известного ему сертификата для формирования подписи, и передавать тот же сертификат по ссылке, сайт-инициатор так и не узнает, что это не сертификат пользователя.
Во втором сценарии просто нет никакой проверки подписи, пользователь не знает, что он подписывает.
>В первом сценарии ничто не мешает вашему сервису использовать закрытый ключ известного ему сертификата для формирования подписи, и передавать тот же сертификат по ссылке, сайт-инициатор так и не узнает, что это не сертификат пользователя.
В таком сценарии вы можете в форме логина спрашивать у пользователя ИНН и потом сверять с тем, что написано в сертификате.
>Во втором сценарии просто нет никакой проверки подписи, пользователь не знает, что он подписывает.
Есть вариант лучше — я просто считываю приватный ключ, отправляю его на сервере и у всех все плохо. Это не решается технически, только аудитом, к сожалению.
В таком сценарии вы можете в форме логина спрашивать у пользователя ИНН и потом сверять с тем, что написано в сертификате.
>Во втором сценарии просто нет никакой проверки подписи, пользователь не знает, что он подписывает.
Есть вариант лучше — я просто считываю приватный ключ, отправляю его на сервере и у всех все плохо. Это не решается технически, только аудитом, к сожалению.
Есть вариант лучше — я просто считываю приватный ключ, отправляю его на сервере и у всех все плохо. Это не решается технически, только аудитом, к сожалению.
Вот именно поэтому в таких системах должны использоваться только сертифицированные средства криптографии, которые такого не позволяют.
А технически, кстати, это решается просто: неэкспортируемым сертификатом на токене с вычислением подписи на самом токене. Тут, правда, возникает следующая проблема — содержания подписываемого документа, для ее решения используются токены с дисплеем, но у них тоже есть проблемы — они умеют не все документы.
Так что возращаемся на шаг 1: только сертифицированное ПО.
>Вот именно поэтому в таких системах должны использоваться только сертифицированные средства криптографии, которые такого не позволяют.
Все так. Проблема в том, что в случае веба, вокруг сертифицированной библиотеки криптопреобразований будет висеть обычный код для ввода-вывода информации, а в запущенных случаях — тридцать пять скриптов на жквери, каждый из которых может перехватить ввод, подменить документ и увести приватный ключ.
Все так. Проблема в том, что в случае веба, вокруг сертифицированной библиотеки криптопреобразований будет висеть обычный код для ввода-вывода информации, а в запущенных случаях — тридцать пять скриптов на жквери, каждый из которых может перехватить ввод, подменить документ и увести приватный ключ.
Это так не работает.
Во-первых, сертифицированная библиотека ни при каких условиях не выпускает приватный ключ наружу (без этого она вообще сертифицирована не будет).
Во-вторых, хорошая сертифицированная библиотека показывает подписываемую информацию.
Поэтому оба описанных вами сценария не применимы.
Во-первых, сертифицированная библиотека ни при каких условиях не выпускает приватный ключ наружу (без этого она вообще сертифицирована не будет).
Во-вторых, хорошая сертифицированная библиотека показывает подписываемую информацию.
Поэтому оба описанных вами сценария не применимы.
>Во-первых, сертифицированная библиотека ни при каких условиях не выпускает приватный ключ наружу (без этого она вообще сертифицирована не будет).
все правильно, поэтому ключ надо перехватывать на входе.
все правильно, поэтому ключ надо перехватывать на входе.
Так нет же никакого «входа». Библиотека общается с ключом через системные средства, к ним у приложения доступа нет, и перехватить ничего нельзя.
Для запущенных параноиков — подписание напрямую на токене.
Для запущенных параноиков — подписание напрямую на токене.
>Так нет же никакого «входа». Библиотека общается с ключом через системные средства, к ним у приложения доступа нет, и перехватить ничего нельзя.
Окей, расскажите, как это будет выглядеть для веба.
Окей, расскажите, как это будет выглядеть для веба.
Сертифицированный (или, по крайней мере, доверенный) плагин, который стоит на компьютере пользователя, и интерфейс которого состоит из (в нашем случае) одной операции: «подпиши вот такой документ». Дальше уже сам плагин предлагает пользователю выбрать сертификат, если необходимо — ввести пин, внутри себя подписывает документ, и отдает подпись наружу.
>Сертифицированный (или, по крайней мере, доверенный) плагин
Ну вот таким доверенным плагином и хочется быть. Разница в том, как отделять контекст плагина от самого приложения — ставить на машину заранее, либо подгружать с доверенного домена.
В дальнейшем я планирую повысить уровень паранои и подписывать заранее установленным на машине пользователя кодом, либо мобильным приложением.
Существующая же сейчас практика интеграции ЭЦП, в виде жава-апплета, подключаемого прямо в страницу мне не нравится, поскольку это дыра. Поэтому и делаю, то что делаю.
Ну вот таким доверенным плагином и хочется быть. Разница в том, как отделять контекст плагина от самого приложения — ставить на машину заранее, либо подгружать с доверенного домена.
В дальнейшем я планирую повысить уровень паранои и подписывать заранее установленным на машине пользователя кодом, либо мобильным приложением.
Существующая же сейчас практика интеграции ЭЦП, в виде жава-апплета, подключаемого прямо в страницу мне не нравится, поскольку это дыра. Поэтому и делаю, то что делаю.
Ну вот таким доверенным плагином и хочется быть.
В корпоративной среде разве что, если вам удастся убедить тамошнюю СБ. Ну или полная госсертификация, не знаю, как с этим на Украине.
И в любом случае, вы либо выступаете плагином (тогда вам не нужен свой сайт, вы выпускаете именно плагин), либо делаете сайт с полным механизмом, но в этом случае вы вообще не передаете подпись/сертификат потребителю, а передаете сразу идентификационные данные, подписанные ключом вашего сайта (как делает та же ЕСИА).
Разница в том, как отделять контекст плагина от самого приложения — ставить на машину заранее, либо подгружать с доверенного домена.
Это, по факту, одно и то же все равно.
Существующая же сейчас практика интеграции ЭЦП, в виде жава-апплета, подключаемого прямо в страницу мне не нравится, поскольку это дыра.
Во-первых, это далеко не единственная практика. А во-вторых, что в ней дырявого (если, конечно, апплет нормально написан)? Или вы судите по одному конкретному примеру?
>Во-первых, это далеко не единственная практика. А во-вторых, что в ней дырявого (если, конечно, апплет нормально написан)? Или вы судите по одному конкретному примеру?
В том, что запрашивает доступ к ключу через веб-интерфейс страницы. Правильность, доверенность и сертифицированность самого апплета при этом перестает играть какую-то роль.
В том, что запрашивает доступ к ключу через веб-интерфейс страницы. Правильность, доверенность и сертифицированность самого апплета при этом перестает играть какую-то роль.
>И в любом случае, вы либо выступаете плагином (тогда вам не нужен свой сайт, вы выпускаете именно плагин), либо делаете сайт с полным механизмом, но в этом случае вы вообще не передаете подпись/сертификат потребителю, а передаете сразу идентификационные данные, подписанные ключом вашего сайта (как делает та же ЕСИА).
Вы зачему-то путаете в одну кучу безопасность для пользователя, признание подписываемых данных государством и вопрос доверия сайта-инициатора.
* Первое решается вынесением работы с ключем в отдельный контекст (это есть)
* для второго нужна сертификация или экспертиза (этого сейчас нет и не всем нужно)
* вопрос доверия сайта-инициатора решается проверкой подписи на его стороне (это есть) и вводом ИНН в форме логина (это вопрос интеграции, я подумаю над ним)
Вы зачему-то путаете в одну кучу безопасность для пользователя, признание подписываемых данных государством и вопрос доверия сайта-инициатора.
* Первое решается вынесением работы с ключем в отдельный контекст (это есть)
* для второго нужна сертификация или экспертиза (этого сейчас нет и не всем нужно)
* вопрос доверия сайта-инициатора решается проверкой подписи на его стороне (это есть) и вводом ИНН в форме логина (это вопрос интеграции, я подумаю над ним)
Вот признание подписываемых данных государством я еще вообще не затрагивал, это отдельная тема.
А безопасность для пользователя и безопасность для потребителя — это две стороны одной и той же монеты: вы вводите никому не известный сервис в качестве посредника при идентификации. Неудивительно, что возникают вопросы.
Вы путаете, как раз. Безопасность для пользователя решается рядом технических мер, но гарантируется (и без этих гарантий пользователь не должен пользоваться вашим сервисом) как раз экспертизой (с возможным подтвержденим сертификацией).
Ну и отдельный, конечно, вопрос, как в реальности у вас это сделано. Можете показать код и кратко его описать?
Ввод ИНН — это бессмысленное усложнение процедуры для пользователя, которому совершенно незачем это делать.
А безопасность для пользователя и безопасность для потребителя — это две стороны одной и той же монеты: вы вводите никому не известный сервис в качестве посредника при идентификации. Неудивительно, что возникают вопросы.
Первое [безопасность для пользователя] решается вынесением работы с ключем в отдельный контекст (это есть)
Вы путаете, как раз. Безопасность для пользователя решается рядом технических мер, но гарантируется (и без этих гарантий пользователь не должен пользоваться вашим сервисом) как раз экспертизой (с возможным подтвержденим сертификацией).
Ну и отдельный, конечно, вопрос, как в реальности у вас это сделано. Можете показать код и кратко его описать?
вопрос доверия сайта-инициатора решается проверкой подписи на его стороне (это есть) и вводом ИНН в форме логина (это вопрос интеграции, я подумаю над ним)
Ввод ИНН — это бессмысленное усложнение процедуры для пользователя, которому совершенно незачем это делать.
Нет уж такого минестерства, теперь — это Государственная фискальная служба.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сигнербокс — аутентификация через ДСТУ 4145