Привет, Хабр! Меня зовут Андрей, и в Компании «Актив» я отвечаю за развитие направления многофакторной аутентификации. В 2023 году мы выпустили линейку первых и (пока) единственных отечественных устройств на базе технологии FIDO2 – Рутокен MFA. Хотя FIDO2 в мире существует уже 7 лет и многие отечественные бигтехи (вроде Яндекса и VK) уже внедрили ее в свои сервисы, отечественные потребители слабо знакомы с этой технологией.
Как первопроходцам, нам, как компании, и мне лично пришлось заниматься евангелизмом и просвещением, что же это за такая технология, как она упрощает жизнь пользователям и какие преимущества несет. Самый популярный вопрос, который мне приходил – «А в чем разница с PKI?».

Сравнение двух технологий – читайте ниже во всех подробностях.

Привет, Хабр! Сегодня хочу поговорить о том, как компании-разработчики сами себе «ставят палки в колеса» — выбирают неэффективные модели лицензирования собственного ПО и теряют выручку. Казалось бы, что сложного? Настроил защиту от несанкционированного использования, прикрутил проверку лицензий, добавил пару условий в договор — и готово. Но на практике ошибки в лицензировании обходятся дорого: теряется выручка из-за пиратства и негибких продаж, растут операционные расходы, а клиенты уходят к конкурентам. Почему это важно? Лицензирование — не просто «замок» на софте. Это инструмент монетизации, который защищает код от нелегального использования, формирует стабильный доход (подписки, продажа обновлений и модулей ПО), автоматизирует процессы и делает конечных пользователей счастливыми.

Приветствую, Хабр! В моей предыдущей статье были описаны принятые в прошлом году стандарты США FIPS (Federal Information Processing Standard — Федеральный стандарт обработки информации — аналог стандартов ГОСТ Р в России) на постквантовые алгоритмы электронной подписи (FIPS 204 и FIPS 205) и инкапсуляции ключей (FIPS 203). Данные криптостандарты были приняты в результате тщательного анализа и отбора алгоритмов в рамках открытого конкурса, проводимого Институтом стандартов и технологий США NIST; данный конкурс также был описан в предыдущей статье.

Стандарты FIPS 203 [1] и FIPS 204 [2] описывают алгоритмы, основанные на применении структурированных алгебраических решеток, тогда как алгоритм, стандартизованный в FIPS 205 [3], базируется на стойкости нижележащих хеш‑функций; данный алгоритм называется Stateless Hash‑Based Digital Signature Algorithm (SLH‑DSA) — алгоритм электронной подписи на основе хеширования без сохранения состояния. Стоит сказать, что данные алгоритмы стали не первыми постквантовыми криптоалгоритмами, стандартизованными в США, — еще в 2020 году в США был издана «специальная публикация» (SP — Special Publication — аналог рекомендаций по стандартизации в России) NIST SP 800–208 [4], описывающая несколько алгоритмов электронной подписи с сохранением состояния, также основанных на хеш‑функциях.

Далее в статье — описание и схемы алгоритмов, описанных в NIST SP 800–208, а также небольшой анализ особенностей алгоритмов данного класса.

Всем привет! Меня зовут Анастасия Калиничева, я являюсь специалистом по информационной безопасности и ярым любителем поискать смысл в законодательстве о персональных данных (ПДн). Про оборотные штрафы написано уже много материалов, но в процессе анализа поправок невозможно обойтись без структурированного «разложить все по полочкам» и, конечно же, личного мнения о нововведениях. Делюсь с вами аналитикой на тему ужесточения ответственности за правонарушения в сфере законодательства РФ о ПДн.

Приветствую, Хабр!

В своей предыдущей статье (посвященной оценке необходимости срочного перехода на постквантовые криптоалгоритмы) я упомянул о принятых в США стандартах на постквантовые алгоритмы электронной подписи и обмена ключами. Данные стандарты были приняты в августе прошлого года (а перед этим они в течение года проходили оценку криптологическим сообществом в виде драфтов), при этом Институт стандартов и технологий США NIST анонсировал принятие дополнительных (альтернативных) постквантовых криптостандартов в будущем.

Поскольку принятие стандартов на постквантовые криптоалгоритмы можно считать весьма значительным событием в сфере асимметричной криптографии, а также принимая во внимание предполагаемый переход с традиционных на вышеупомянутые стандарты на горизонте в несколько лет (причем не только в США, но и в той значительной части мира, которая ориентируется на стандарты США), предлагаю вашему вниманию в данной статье описание (помимо описаний, я попытался схематично изобразить основные преобразования – под катом много схем с пояснениями) алгоритмов, на которых основаны постквантовые криптостандарты США, а также краткое обсуждение ближайших перспектив выхода новых стандартов на постквантовые криптоалгоритмы и рекомендаций по переходу с традиционных криптографических алгоритмов на постквантовые. Перечень текущих стандартов и рекомендаций NIST в части асимметричной криптографии со ссылками на их официальные публикации приведен в списке литературы к данной статье.

Приветствую, Хабр! Долгое время я принадлежал к числу тех, кто скептически относится к возможностям квантового криптоанализа в частности и квантовых вычислений вообще. Мое отношение к этому вопросу кардинально изменилось после того, как я услышал один из докладов на прошедшей конференции «РусКрипто», авторы которого очень четко показали преимущества криптоанализа на основе гибридных вычислений, совместно использующих традиционные и квантовые компьютеры, по сравнению с классическим криптоанализом.

Дальнейшие события прошедшего года, включающие в себя как усиление возможностей квантовых вычислений «в железе», а не только на бумаге, так и активные действия по разработке и стандартизации постквантовых криптоалгоритмов, показали, что далее игнорировать или относиться скептически к квантовым вычислениям/криптоанализу губительно.

Предлагаю вашему вниманию статью с анализом степени срочности перехода на постквантовые алгоритмы. Справедливости ради, я приведу и недавние высказывания известных экспертов-скептиков, но основная мысль статьи состоит в том, что откладывать далее переход на постквантовые криптоалгоритмы невозможно – начинать их реализацию и думать об их внедрении необходимо прямо сейчас, чтобы, скажем, через 5 лет такой переход был уже осуществлен. Иначе можем опоздать (прежде всего, из-за усиливающихся с каждым годом возможностей гибридных вычислений).

Подробности – далее.

Приветствую, Хабр! Хотелось бы этой статьей продолжить обзор нефинансовых применений блокчейн-технологий, начатый мной ранее на примере использования блокчейна для хранения идентификационных данных. Рассмотрим здесь существующие подходы по применению блокчейна в системах Интернета вещей различного назначения.

Казалось бы, между ресурсоемким по своей природе блокчейном и Интернетом вещей, построенном на использовании устройств с ограниченными ресурсами, лежит огромная пропасть. Однако многие из свойств блокчейна оказались настолько востребованными в Интернете вещей, что появилось целое направление блокчейн-технологий – низкоресурсный блокчейн (Lightweight Blockchain, LWB), в рамках которого было предложено множество подходов к созданию блокчейнов с пониженными требованиями к ресурсам и, следовательно, к их адаптации для реализации в системах Интернета вещей и, в частности, в устройствах с низкими вычислительными ресурсами.

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

Приветствую уважаемых читателей, случайно или нет наткнувшихся на эту статью. Адресована она всем тем, кто исследует распределение разнообразных эмпирических данных.
В моей публикации вас ждут: небольшой ликбез по теории вероятностей, развивающий её интуитивное и практическое понимание; детективная история о том, как решение дифференциального уравнения привело нас к двум важнейшим статистическим характеристикам выборочных последовательностей; ревизионизм в области проверки распределений на соответствие гауссовскому и объяснение пресловутого p-value с нуля за 5 минуты.

Приветствую уважаемую публику Хабра от лица условно анонимного представителя компании «Актив», занимающейся производством небезызвестных средств аутентификации и электронной подписи.

В этой статье хотелось бы рассказать об одном из менее известных направлений деятельности подразделения Рутокен, связанного с обеспечением киберфизической безопасности. В рамках данного направления компания уже не первый год производит встраиваемые в управляющее и управляемое оборудование устройства линейки Рутокен Модуль. Не так давно в эти устройства (а заодно в токены и смарт-карты Рутокен ЭЦП 3.0) добавилась поддержка протокола CRISP, и это отличный повод рассказать и о самом протоколе, и о принципах интеграции устройств Рутокен Модуль, и об организации процессов разработки в компании.

Приветствую, Хабр! Моя предыдущая статья была посвящена формализованным критериям выбора базовой технологии хранения и обработки данных, совокупность которых позволяла ответить на вопрос, использовать ли в конкретной системе блокчейн-технологии или ограничиться хорошо изученными СУБД. При этом ответ на данный вопрос при использовании формализованных методов выбора мог быть получен именно на основе технических факторов, не принимая во внимание различные «политические» аспекты выбора, такие как, например, повышенный информационный шум, продолжающийся вокруг блокчейна.

Приведенная в предыдущей статье классификация известных применений блокчейн-технологий позволила проиллюстрировать, с одной стороны, их широту, а с другой – тот факт, что применения блокчейн-технологий значительно различаются по степени полезности данных технологий для систем, в которых они могут использоваться.

Одним из известных направлений применения блокчейн-технологий является хранение идентификационных данных граждан. Предлагаю далее рассмотреть варианты хранения идентификационных данных на основе блокчейн-технологий и традиционных баз данных и сравнить подобные решения для формулировки вывода об оптимальной технологии для данного применения.

Технические писатели создают текстовые документы, но что если для процесса одного текста мало? Тогда приходится учиться монтировать и делать видеоинструкции.

В этой статье я рассказала, как и зачем в Компании «Актив» мы делаем видеоинструкции на примере одного важного кейса: здесь про цели, сценарий, запись звука и программы для монтажа.

Должно быть интересно!

Добрый день, Хабр! 

В данной заметке я постараюсь сравнить два разных подхода к задаче запутывания машинного кода – это протектор и обфускатор, построенный на базе LLVM-фреймворка. Нам пришлось с этим столкнуться, когда возникла задача защиты библиотек Guardant под разные операционные системы и разные ARM-архитектуры. Для x86/x64 мы используем протектор Guardant Armor, который является полностью нашей разработкой. В случае ARM-архитектуры было принято решение параллельно посмотреть в сторону открытых обфускаторов на базе LLVM с целью их модификации и использования для защиты своих продуктов.

Приветствую, Хабр! В очередной раз возникло желание обсудить блокчейн‑технологии, хотя им и было посвящено уже немало публикаций на Хабре (да и, несомненно, их еще будет много в дальнейшем).

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

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

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

В этой статье мы рассмотрим достоинства и недостатки блокчейн‑технологий и попытаемся классифицировать сферы их применения, после чего дадим обзор формализованных методов выбора: «блокчейн или не блокчейн».

Привет, Хабр! Недавно мы с коллегами стали вспоминать, как выглядела работа с электронной подписью (ЭП) и ключевые носители, когда мы только начали работать в этой области. Мы искренне удивились тому, как за такое короткое время технологии шагнули вперед. Так родилась идея для этой статьи. Она для всех, кто когда‑нибудь имел дело с настройкой компьютера для работы с ЭП, отправкой отчетности в контролирующие органы, знает, что такое токены, оказывал техническую поддержку по работе с электронным документооборотом. Особенно для тех, кто помнит Windows XP, шариковые мышки и дискеты.

Очень надеюсь, что этот материал вызовет у вас такую же теплую ностальгию, которую ощутили мы с коллегами, когда вспоминали, как это было.

Муки самоопределения, кринжовые стажировки и собеседования, первый опыт, портфолио редактора...или как филолог искала работу в ИТ.

В этой статье — об увлекательно случайной истории пути от стажера-копирайтера до технического писателя. Как мне тут работается, почему не хочется уходить и помогает ли мне образование филолога. Отвечаем вместе на вопрос "Есть ли гуманитариям место в ИТ?".

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

Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.

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

Приветствую, Хабр! Меня зовут Сергей Панасенко, я работаю в компании «Актив» директором по научной работе. По роду занятий мне достаточно часто требуется знание (а иногда и решение вопросов практического применения) нормативных документов регуляторов в области ИБ, в том числе приказов ФСТЭК России, которые устанавливают требования по защите данных в информационных системах различного назначения (подробнее о них – под катом), а также меры по защите информации, применимые для обеспечения соответствия данным требованиям. Одна из таких мер – контроль перемещения машинных носителей информации за пределы контролируемой зоны, вызвала мой  особый интерес. Данная мера выглядит важной для обеспечения безопасности, но ее реализация напрямую (проверка сотрудников на выходе с предприятий) выглядит весьма затруднительной: носители (для определенности – USB-флешки) становятся всё более миниатюрными, и проверка их отсутствия у выходящего с территории сотрудника может превратиться в проблему и для сотрудников, и для проверяющих.

Вместо этого возникла идея определения местонахождения носителей внутри контролируемой зоны по принципу «белого списка», которой захотелось поделиться с вами. Буду признателен за обратную связь и полезные замечания.

Итак, начнем.

Привет, Хабр! Я Анастасия Дмитриева, работаю ведущим техническим писателем в компании “Актив”. Долгое время я была единственным техническим писателем в компании. Но в какой-то момент мне стало понятно, что задач очень много, и одной мне просто не справиться. Я начала поиск junior-а. Особой спешки не было, и я понимала, что я могу потратить какое-то время и научить его всему. 

В этой статье я опишу первый этап поиска: формирование требований к кандидатам и просмотр их резюме. Здесь вы увидите только моё мнение, и я не возражаю, если в комментариях появится ваше личное видение процесса поиска. Мне также хочется рассказать молодым специалистам про профессию “технический писатель”. Может, кто-то увидит себя в ней. 

Наша компания в первую очередь занимается разработкой системного программного обеспечения, драйверов, созданием программно-аппаратных решений. Однако мы также разрабатываем собственные информационные системы для автоматизации наших внутренних бизнес-процессов и задач наших крупных клиентов.

При проектировании нового программного решения была поставлена задача выбрать язык и фреймворк. По результатам проведенного исследования был выбран язык Go, как обеспечивающий высокую производительность вместе со скоростью разработки, а также фреймворк Flamingo для реализации принципов Domain Driven Design. Всем, кому интересно узнать, что же за птица такая Flamingo, приглашаю под кат.

Концепция предметно-ориентированного проектирования, она же DDD (Domain Driven Design), описанная Эриком Эвансом, активно используется при построении информационных систем для предприятий. Не стоит пересказывать основные принципы DDD, благо, помимо книги самого Эванса, они описаны в большом количестве статей. Нам важно другое. Эти принципы гораздо проще реализовать в своей информационной системе, если они поддерживаются фреймворком.

Для .Net, например, есть ASP.NET Boilerplate (https://aspnetboilerplate.com/), полностью реализующая все компоненты DDD – Entity, Value, Repository, Domain Service, Unit of Work и еще много всего. Но мы для одной из своих внутренних информационных систем используем Go. 

Мы решили использовать фреймворк Flamingo, распространяемый под лицензией MIT. Он разработан немецкой компанией AOE GmbH в 2018 году и к настоящему моменту “дорос” до версии 3.4 и до 331 звезды на Github. Flamingo используется в информационных системах аэропортов Окланда, Франкфурта и Хитроу, а также в T-Mobile.

Данный текст не является руководством по внедрению двухфакторной аутентификации в Linux на основе токенов / смарт-карт. Подобные (и весьма подробные) руководства вы сможете найти как на сайтах производителей токенов, так и операционных систем. Я лишь хочу перечислить возможные варианты реализации 2ФА, а заодно побудить ответственных за информационную безопасность предприятия реализовать столь необходимую защиту от кражи паролей пользователей.