В действительности эту проблему можно решить сформировав доверенную среду. То есть выполнив комплекс административных и технических мер на месте создания ЭЦП. Какие-то «устройства с отдельным экраном» это только малая часть комплекса и, скорее всего, избыточная ибо в по-настоящему доверенной среде проблемы вида «Man-in-a-browser» должны исключаться административными и техническими средствами полностью. А использование «устройств с экранами» у обычных пользователей представляется избыточно дорогим.
Покажу как она работает.
1) Используем MS Crypto API + например Крипто-Про CSP;
2) Создаём контекст хэша данных функцией «CryptCreateHash»;
3) Устанавливаем любое значение хэша функцией «CryptSetHashParam(HP_HASHVAL)»;
4) Подписываем сообщение с помощью функции «CryptSignHash»;
Вы сильно ошибаетесь — на самом деле использование хэшей в процессе создания подписи как-раз связано с оптимизацией работы алгоритмов, использующих криптографию на асинхронных ключах. То есть можно использовать алгоритмы создания подписи и прямо на исходных данных, однако это многократно замедлит процесс.
В первом упомянутом мною варианте отсутствует хэширование — там предполагается сразу выполнять подпись. Вполне возможно, что Рутокен оптимизирован на более быстрые операции подписи, чем на быстрое хэширование.
Проводилось ли тестирование по скорости между двумя вариантами?
1) Подпись всего документа на клиенте (по той же процедуре, что и подписание хэша) и потом передача готовой подписи на сервер;
2) Передача документа на сервер, хэширование на сервере, передача обратно на клиент, подпись на клиенте, передача строки на сервер;
Я позволю себе процитировать то, что написано выше:
Так как статья достаточно большая по меркам Хабра и содержит большое количество различных форматированных списков, то на этом сайте будет (как минимум пока) приведено лишь оглавление общей статьи и прямая ссылка на полную версию статьи в формате PDF.
Насчет ссылки — ищите сами, вводные все даны. По-моему эта информация относится либо к войне в Ираке, либо в Югославии. То есть к событиям 20-ти — 15-ти летней давности. Или можете не искать и считать что я всё придумал, как угодно :)
При условии закрытой системы, как я и сказал, только производитель ответственен за качество кода продукта. То есть, как и было сказано, это вопрос качества аудита, абсолютно согласен.
Насчет преимуществ закрытых систем: сложность поиска ошибок. То есть даже для АНБ закрытый продукт анализировать гораздо сложнее, чем открытый. Если АНБ что-то нашло, то легко можно поменять код (относительно существенно), и так с определённой периодичностью. Так что затрудняем работу потенциальному противнику это раз. Во-вторых в закрытых системах можно легко и непринуждённо менять внутренний функционал. То есть захотел, чтобы шифрование по-умолчанию было не RSA, а ГОСТ — сделал. Вы, конечно, можете возразить «Так в открытых системах так тоже можно сделать!». Согласен, только вот после серии подобных переделок под себя процесс доработки данной ОС может по сложности сравняться с разработкой национальной ОС. Кстати ведь так китайцы и делают — берут какую-то основу и переделывают под себя.
Ну и в третьих, как написали несколько ниже в комментариях, при разработке сложных продуктов национального масштаба присутствует «мультипликативный эффект». То есть от разработки специфической ОС возникает группа специалистов, которая может такие ОС делать, возникают побочные предприятия, которые делают программы для этой ОС, возможно возникает какое-то производство компонентов. Таким образом увеличивается занятость населения и повышается уровень квалификации программистов.
А вот насчет «кто в трезвом уме оценивает исследователей безопасности численностью?» не понял — а в чем их оценивают, просветите пожалуйста.
Конечно, вариант когда исходный код делается в другой стране, а только потом передаётся вашей ущербен, как и правильно было замечено. Именно поэтому и важно разрабатывать собственную ОС, с гарантией владения полным исходным кодом и людьми, которые этот код разработали.
Насчет плохо или хорошо: это уже вопрос применения данной ОС данным государством. Я тут лишь говорю о том, что для вопросов национальной безопасности вариант с разработной собственной ОС лучше, чем с использованием ОС разработки другого государства.
Стандарты могут быть любыми, важен лишь вопрос — кто контролирует их реализацию. Возможен также вариант с предоставлением исходного кода готового продукта контролирующим структурам государства, как делается в случае с Microsoft Windows.
А насчет обычных людей — возможны произвольные ситуации. В настоящий момент в России существует защищённая мобильная связь «для избранных». Там присутствует как своё оборудование, так и своё программное обеспечение. Только работает оно для ограниченного круга граждан страны. В Китае же есть возможность обеспечить контроль за оборудованием и ПО для всех пользователей страны, что хорошо для национальной безопасности.
При том, что «обычные люди» и есть главное достояние любой нации.
А если проще то скажу, что в случае с ОС произведённой сторонним производителем возникает опасность не санкционированной прослушки телефонных переговоров или добавления программных «закладок», что в свою очередь создаёт потенциальную угрозу именно национальной безопасности. То есть в качестве «обычных людей» могут быть например ученые данной страны, или охранники президента.
Кстати я сильно сомневаюсь, что США допустят данную ОС к эксплуатации на своей территории, аргументируя это как-раз вопросами национальной безопасности. Также поступили бы и в СССР. Критически важно иметь возможность контроля над производством.
Как минимум этот «изоляционизм» позволяет контролировать процесс производства ОС. А если ОС которую использует государство и граждане производится кем-то из вне то такую ситуацию можно, пожалуй, сравнить с тем случаем, когда противоракетную оборону стране обеспечивает другая страна. Затрудняюсь вспомнить где эта ситуация была, но читал, что США перед вторжением в какую-то страну просто отключило комплексы Patriot, которые в этой стране использовались.
Так что то, о чем Вы сказали в своём комментарии не вопрос изоляции ОС, а вопрос только тщательности анализа защищённости, произведенной производителем. То есть теперь только производитель оказывает влияние на ОС и, следовательно, только производитель отвечает за последствия эксплуатации этой ОС.
А насчет культурности независимых исследователей: дело в том, что квалифицированных независимых исследователей достаточно мало и у них мало стимулов исследовать новую ОС. Но вот разведка противника очень даже может нанять большой штат крайне квалифицированного персонала, который быстренько разберёт все недостатки вашей ОС. И, естественно, сообщит это всё только своему начальству.
Так что на мой взгляд иметь закрытую ОС, производимую внутри госструктур государства — это вопрос национальной безопасности.
На мой взгляд эта ОС является просто частью китайской «стратегии кибербезопасности». Свои производственные мощности они имеют, сделать телефоны/компьютеры под себя могут. Теперь ещё и ОС под себя сделали. Так что молодцы.
Да-да, этим и пользуюсь.
Но все-таки пока считаю написание транслятора из С++ скажем в JavaScript напрямую достижимой задачей. Конечно очень сложной, но достижимой. Насчет «кому это нужно» — собственно ради того, чтобы узнать общественное мнение я и написал свой комментарий.
Насчет «но чтобы человек с 10 — 20 летним опытом всерьез предлагал такое, это уже перебор»: мне вот сейчас бывает нужно перевести реализации сложных программ с С++ на JavaScript. И такое возможно, существуют программы-трансляторы. Уверяю Вас, что это полезные программы и многим могут пригодиться. Конечно часть приходится переводить вручную, но хотелось бы иметь некий универсальный инструмент. И очень бы хотелось (уверен это возможно) получать полностью работоспособный код после трансляции любой программы. Это, конечно, сложно и сравнимо по уровню сложности с написанием собственно компилятора языка, но на мой взгляд очень полезно.
Профессионально программирую на С++ 15 лет, не профессионально — считай 20 лет. Язык мне нравится, всё устраивает. Но здесь я хотел бы сказать о другом.
При спорах о языке часто забывают, что на самом деле исполняется не тот текст, который написали на определённом языке, а машинный код. И чтобы этот машинный код получить нужен компилятор. И на самом деле быстроту и производительность даёт (или не даёт) по бОльшей части именно этот преобразователь из вашего любимого языка в машинный. А язык программирования — всего-лишь некий удобный инструмент, на котором вам лично удобно разрабатывать определённые решения для опредеённых задач. Для каких-то задач удобнее С++, для каких-то Haskell. Важно лишь понимать, что нужна некая программа, которая сконвертирует ваш любимый Haskell в машинный код.
Но вот что (IMHO) по настоящему интересно — это иметь программы, которые конвертируют один язык в другой. Знаешь ты например только С++, а тебе надо сделать что-то на C#: используешь преобразователь «С++ — C#». Просто в глобальном масштабе следует «заточить» какие-то языки программирования по определённые задачи, а потом написать преобразователи из других языков. Это как в математике: где-то действует математика вещественных чисел, а где-то — комплексных, есть переходы между числами, определены какие-то области использования. На мо взгляд пора перейти к этому и в языках программирования. То есть стОит переходить от неких общих языков программирования к задаче-ориентированным и написанию «переходников» от одних языков к другим.
Всё вышесказанное — только для «мониторинга» общественного мнения по этому вопросу. Насчет «holly-wars» скажу, что каждый язык хорош по своему :)
Кстати ещё одной причиной существования множества сертификатов от разных УЦ является то, что существует понятия «доверия» между УЦ. То есть для участия в определенной системе надо иметь сертификат в «доверенном» УЦ. А вот такие «доверительные отношения» сейчас далеки от «все со всеми». Так что для участия в разных системах зачастую надо иметь сертификаты от разных УЦ,
Отвечу пока на выделенный автором вопрос «Почему нельзя выдавать каждому сотруднику 1 (ОДНУ) ЭЦП и просто при каких либо изменениях добавлять или удалять в этом сертификате области использования?».
Во-первых просто так «добавлять или удалять» в сертификате ничего нельзя. В случае изменения контента сертификата он должен быть заново выпущен УЦ.
Во-вторых разные области использования обычно возникают как бы по мере необходимости. Например сначала сотруднику надо участвовать в электронных торгах, потом работать ещё в какой-то смежной системе и т.п. В каждой из систем зачастую необходимы свои политики применения сертификата. А так как сертификат нельзя вот просто так изменить то для новых областей использования выпускается новый сертификат.
Идеальный выход — это для всего набора политик использования сделать ещё один новый сертификат. Но тогда возникает другая проблема — зачастую ранее выпущенные сертификаты уже зарегистрированы в сторонних системах документооборота и привязаны к текущему пользователю. То есть после выпуска нового сертификата необходимо отозвать старые и заново «перепривязать» пользователя и новый сертификат в сторонних системах документооборота.
Стандарт X.509 определяет, что основная кодировка для сертификата — ASN.1 DER. Стандарт PEM (Privacy Enhancement for Internet Electronic Mail) был изначально придуман для передачи бинарных сообщений в составе S/MIME сообщений (то есть для передачи бинарных сообщений в обычной электронной почте). Действительно PEM — это простое применение BAS64 кодирования к начальному бинарному сообщению.
Для бОльшего знания в этом вопросе можно почитать стандарты RFC 1421-1424.
1) Используем MS Crypto API + например Крипто-Про CSP;
2) Создаём контекст хэша данных функцией «CryptCreateHash»;
3) Устанавливаем любое значение хэша функцией «CryptSetHashParam(HP_HASHVAL)»;
4) Подписываем сообщение с помощью функции «CryptSignHash»;
Так что и здесь вы ошибаетесь.
1) Подпись всего документа на клиенте (по той же процедуре, что и подписание хэша) и потом передача готовой подписи на сервер;
2) Передача документа на сервер, хэширование на сервере, передача обратно на клиент, подпись на клиенте, передача строки на сервер;
Так как статья достаточно большая по меркам Хабра и содержит большое количество различных форматированных списков, то на этом сайте будет (как минимум пока) приведено лишь оглавление общей статьи и прямая ссылка на полную версию статьи в формате PDF.
При условии закрытой системы, как я и сказал, только производитель ответственен за качество кода продукта. То есть, как и было сказано, это вопрос качества аудита, абсолютно согласен.
Насчет преимуществ закрытых систем: сложность поиска ошибок. То есть даже для АНБ закрытый продукт анализировать гораздо сложнее, чем открытый. Если АНБ что-то нашло, то легко можно поменять код (относительно существенно), и так с определённой периодичностью. Так что затрудняем работу потенциальному противнику это раз. Во-вторых в закрытых системах можно легко и непринуждённо менять внутренний функционал. То есть захотел, чтобы шифрование по-умолчанию было не RSA, а ГОСТ — сделал. Вы, конечно, можете возразить «Так в открытых системах так тоже можно сделать!». Согласен, только вот после серии подобных переделок под себя процесс доработки данной ОС может по сложности сравняться с разработкой национальной ОС. Кстати ведь так китайцы и делают — берут какую-то основу и переделывают под себя.
Ну и в третьих, как написали несколько ниже в комментариях, при разработке сложных продуктов национального масштаба присутствует «мультипликативный эффект». То есть от разработки специфической ОС возникает группа специалистов, которая может такие ОС делать, возникают побочные предприятия, которые делают программы для этой ОС, возможно возникает какое-то производство компонентов. Таким образом увеличивается занятость населения и повышается уровень квалификации программистов.
А вот насчет «кто в трезвом уме оценивает исследователей безопасности численностью?» не понял — а в чем их оценивают, просветите пожалуйста.
Насчет плохо или хорошо: это уже вопрос применения данной ОС данным государством. Я тут лишь говорю о том, что для вопросов национальной безопасности вариант с разработной собственной ОС лучше, чем с использованием ОС разработки другого государства.
А насчет обычных людей — возможны произвольные ситуации. В настоящий момент в России существует защищённая мобильная связь «для избранных». Там присутствует как своё оборудование, так и своё программное обеспечение. Только работает оно для ограниченного круга граждан страны. В Китае же есть возможность обеспечить контроль за оборудованием и ПО для всех пользователей страны, что хорошо для национальной безопасности.
А если проще то скажу, что в случае с ОС произведённой сторонним производителем возникает опасность не санкционированной прослушки телефонных переговоров или добавления программных «закладок», что в свою очередь создаёт потенциальную угрозу именно национальной безопасности. То есть в качестве «обычных людей» могут быть например ученые данной страны, или охранники президента.
Кстати я сильно сомневаюсь, что США допустят данную ОС к эксплуатации на своей территории, аргументируя это как-раз вопросами национальной безопасности. Также поступили бы и в СССР. Критически важно иметь возможность контроля над производством.
Так что то, о чем Вы сказали в своём комментарии не вопрос изоляции ОС, а вопрос только тщательности анализа защищённости, произведенной производителем. То есть теперь только производитель оказывает влияние на ОС и, следовательно, только производитель отвечает за последствия эксплуатации этой ОС.
А насчет культурности независимых исследователей: дело в том, что квалифицированных независимых исследователей достаточно мало и у них мало стимулов исследовать новую ОС. Но вот разведка противника очень даже может нанять большой штат крайне квалифицированного персонала, который быстренько разберёт все недостатки вашей ОС. И, естественно, сообщит это всё только своему начальству.
Так что на мой взгляд иметь закрытую ОС, производимую внутри госструктур государства — это вопрос национальной безопасности.
Но все-таки пока считаю написание транслятора из С++ скажем в JavaScript напрямую достижимой задачей. Конечно очень сложной, но достижимой. Насчет «кому это нужно» — собственно ради того, чтобы узнать общественное мнение я и написал свой комментарий.
При спорах о языке часто забывают, что на самом деле исполняется не тот текст, который написали на определённом языке, а машинный код. И чтобы этот машинный код получить нужен компилятор. И на самом деле быстроту и производительность даёт (или не даёт) по бОльшей части именно этот преобразователь из вашего любимого языка в машинный. А язык программирования — всего-лишь некий удобный инструмент, на котором вам лично удобно разрабатывать определённые решения для опредеённых задач. Для каких-то задач удобнее С++, для каких-то Haskell. Важно лишь понимать, что нужна некая программа, которая сконвертирует ваш любимый Haskell в машинный код.
Но вот что (IMHO) по настоящему интересно — это иметь программы, которые конвертируют один язык в другой. Знаешь ты например только С++, а тебе надо сделать что-то на C#: используешь преобразователь «С++ — C#». Просто в глобальном масштабе следует «заточить» какие-то языки программирования по определённые задачи, а потом написать преобразователи из других языков. Это как в математике: где-то действует математика вещественных чисел, а где-то — комплексных, есть переходы между числами, определены какие-то области использования. На мо взгляд пора перейти к этому и в языках программирования. То есть стОит переходить от неких общих языков программирования к задаче-ориентированным и написанию «переходников» от одних языков к другим.
Всё вышесказанное — только для «мониторинга» общественного мнения по этому вопросу. Насчет «holly-wars» скажу, что каждый язык хорош по своему :)
Во-первых просто так «добавлять или удалять» в сертификате ничего нельзя. В случае изменения контента сертификата он должен быть заново выпущен УЦ.
Во-вторых разные области использования обычно возникают как бы по мере необходимости. Например сначала сотруднику надо участвовать в электронных торгах, потом работать ещё в какой-то смежной системе и т.п. В каждой из систем зачастую необходимы свои политики применения сертификата. А так как сертификат нельзя вот просто так изменить то для новых областей использования выпускается новый сертификат.
Идеальный выход — это для всего набора политик использования сделать ещё один новый сертификат. Но тогда возникает другая проблема — зачастую ранее выпущенные сертификаты уже зарегистрированы в сторонних системах документооборота и привязаны к текущему пользователю. То есть после выпуска нового сертификата необходимо отозвать старые и заново «перепривязать» пользователя и новый сертификат в сторонних системах документооборота.
Для бОльшего знания в этом вопросе можно почитать стандарты RFC 1421-1424.