#cryptopro — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cryptopro, aggregated by home.social.
-
«А трактор случайно не в залоге?» — история одной интеграции с ФЦИИТ
«— А трактор случайно не в залоге?» — с такого вопроса обычно и начинался рабочий день сотрудников департамента залогового обеспечения в нашем банке. За ним стоит однотипная рутина, на которую раньше уходила большая часть времени: открыть Реестр уведомлений о залоге движимого имущества, ввести данные клиента, подождать результат, проанализировать, принять решение — и так по каждому. Проверка одного заемщика занимает не больше пяти минут, но, когда за час приходит сотня заявок, ручной режим превращается в узкое горлышко. Так в 2024 году перед нами встала задача: автоматизировать выгрузку данных о залогах движимого имущества из реестра, оператором которого является Федеральная нотариальная палата. Я выступала системным аналитиком от системы, отвечающей за взаимодействие банка с внешними сервисами, — оказалась в самом интересном месте: между банком и внешним миром. В этой статье расскажу, как мы подружили банк с ФЦИИТ, с какими трудностями столкнулись и что из этого вышло. Материал будет полезен системным и бизнес-аналитикам, которые только начинают проектировать интеграции с внешними системами.
https://habr.com/ru/articles/1025346/
#финтех #банковская_безопасность #интеграция #api #залог #cryptopro #ipsec #системный_анализ
-
Интеграция .NET-приложения с внешним API по ГОСТ TLS через CryptoPro
Всем привет. Представлюсь - меня зовут Евгений Думчев и я Team Lead .NET разработки в DDPlanet. В какой-то момент в моей практике появилась задача по интеграции с внешним API. Для взаимодействия требовалось применять предоставленный публичный доверенный сертификат сервера .cer и клиентский .pfx сертификат. Особенность в том, что .pfx сертификат был выпущен через CryptoPro CSP - а это вносит свои тонкости в процесс интеграции…
https://habr.com/ru/articles/938244/
#cryptopro #tls #pfx #сертификаты #net #nginx #безопасность_вебприложений #api #интеграция #dockerfile
-
Интеграция .NET-приложения с внешним API по ГОСТ TLS через CryptoPro
Всем привет. Представлюсь - меня зовут Евгений Думчев и я Team Lead .NET разработки в DDPlanet. В какой-то момент в моей практике появилась задача по интеграции с внешним API. Для взаимодействия требовалось применять предоставленный публичный доверенный сертификат сервера .cer и клиентский .pfx сертификат. Особенность в том, что .pfx сертификат был выпущен через CryptoPro CSP - а это вносит свои тонкости в процесс интеграции…
https://habr.com/ru/articles/938244/
#cryptopro #tls #pfx #сертификаты #net #nginx #безопасность_вебприложений #api #интеграция #dockerfile
-
Интеграция .NET-приложения с внешним API по ГОСТ TLS через CryptoPro
Всем привет. Представлюсь - меня зовут Евгений Думчев и я Team Lead .NET разработки в DDPlanet. В какой-то момент в моей практике появилась задача по интеграции с внешним API. Для взаимодействия требовалось применять предоставленный публичный доверенный сертификат сервера .cer и клиентский .pfx сертификат. Особенность в том, что .pfx сертификат был выпущен через CryptoPro CSP - а это вносит свои тонкости в процесс интеграции…
https://habr.com/ru/articles/938244/
#cryptopro #tls #pfx #сертификаты #net #nginx #безопасность_вебприложений #api #интеграция #dockerfile
-
Интеграция .NET-приложения с внешним API по ГОСТ TLS через CryptoPro
Всем привет. Представлюсь - меня зовут Евгений Думчев и я Team Lead .NET разработки в DDPlanet. В какой-то момент в моей практике появилась задача по интеграции с внешним API. Для взаимодействия требовалось применять предоставленный публичный доверенный сертификат сервера .cer и клиентский .pfx сертификат. Особенность в том, что .pfx сертификат был выпущен через CryptoPro CSP - а это вносит свои тонкости в процесс интеграции…
https://habr.com/ru/articles/938244/
#cryptopro #tls #pfx #сертификаты #net #nginx #безопасность_вебприложений #api #интеграция #dockerfile
-
Настройка КриптоПро HSM Client на Suse/RedHat/ROSA Linux и Мир будущего
В новой публикации я покажу, как разработчику информационных систем со встроенными СКЗИ настроить интеграцию с программно-аппаратным криптографическим модулем КриптоПро HSM. Научимся использовать HSM, как самостоятельный криптографический провайдер с выполнением всей математики на борту или только в качестве надежного хранилища ключевого материала. И в завершении затронем важные вопросы ответственности и этики, которые неизбежно возникают при работе с данными технологиями и инструментами.
https://habr.com/ru/companies/alfa/articles/917198/
#linux #криптопро #hsm #cryptopro #pki #криптопровайдер #криптография #электронная_подпись #ключи_шифрования #альфабанк
-
Как и в любой сфере вокруг криптографии полно новостей из ничего. Претендующих не столько на сенсации, сколько выпускаемых в мир лишь для создания в дальнейшем псевдо-правдоподобного маркетинга. Как смешать всё в кучу и якобы обосновано объявить использование ряда алгоритмов небезопасными?
TL;DR: пост о том, чем именно определяется реально используемая на практике криптография. А крики и суета ориентированы на аудиторию понятия не имеющей о стандартах и регламентирующих документах.
Имеет ли смысл при всём этом раскладе ставить использование «Магма» в один ряд с использованием таких же «устаревших» #Triple-DES / #3DES и #Blowfish? Только потому, что они все используют при шифровании блоки длиной 64-бит, но при этом имеют более чем разумную длину ключа? Обосновывая это устаревание киванием в сторону #SWEET32 атаки?
Это определяется режимом использования любого из этих шифров:- какой режим шифрования выбран
- какой «padding mode»
- использование «key meshing» / KDF при этом.
Громогласно и с каждого утюга рассказывалось о чём-то вроде #SWEET32 атаки. Если что-то и пояснялось, то весьма путано и заумно, не для обывателей. Суть при этом сводилась и сводится к тому что:- Для получения возможности угадать содержимое HTTP-cookies надо мониторить долго существующее HTTPS-соединение между браузером и сайтом, сохранив 785 гигабайт трафика.
- Надо создавать внутри этого соединения большое число запросов для заранее предсказуемых данных в ответах, а токен аутентификации должен передаваться в каждом http-запросе.
- Подчёркивать, успешное подтверждение, мол исследователям удалось сделать это меньше чем за пару дней с помощью специального JavaScript-кода для генерации трафика.
А ничего, что никакие вменяемые библиотеки шифруют массивы данных постоянно меняя сессионный ключ?
В крайнем случае #TLS библиотеки ограничивают продолжительность сессий TLS-соединений вообще в целом, а не только для 64-битных шифров, заново устанавливая соединение.
А тот же #OpenVPN давно содержит принудительный повторный выпуск ключей (reneg-bytes 64000000).
Использование ротации ключей для ГОСТ 28147-89 / «Магма» регламентируются официальными документами (использование KDF определяется рекомендациями 1323565.1.022-2018 и 50.1.113-2016) без соответствия этим требованиям в РФ не получить сертификат о корректно реализованной криптографии.
Да и более скоростной вариант такой ротации — key meshing — изменении ключа каждые 1024 байта восходит аж к 2006 году и описан в RFC 4357.
Который именно про ГОСТ 28147-89 и в целом определяет:- режимы шифрования,
- алгоритм усложнения ключей (key meshing),
- режим заполнения (padding mode),
- S-box таблицы перестановок (S-преобразования);
Однако, про RFC 4357 чаще всего вспоминают в несколько ином контексте (см. в конце). И такие вещи как padding mode и key meshing из этого RFC на всём фоне суеты с узлами замены (S-Box) конечно же теряются. Однако, описанный key meshing является гораздо более производительным вариантом классической ротации ключей посредством KDF. Однако в инициативе #КриптоПро имеется одно упущение — не упомянуто каким именно образом изменяется вектор инициализации (IV) во время этого key meshing.
В тоже время, при использовании в TLS 1.2 российского алгоритма «Магма» необходимо реализовывать способ работы с ключами согласно рекомендациях по стандартизации 1323565.1.020-2018).
И сам по себе подход используемого key meshing выполняется исходя из режима шифрования. Для примера можно ознакомиться с режимами #CTR-ACPKM и #OMAC-ACPKM.
Т.е. ACPKM — это Advance Cryptographic Prolongation of Key Material
а CTR-ACPKM делает возможным работа блочного шифра в поточном режиме (вместо потокового).
и OMAC-ACPKM относится к обычным #MAC (выработка имитовставки) — средствам проверки и обеспечения целостности данных.
Эти режимы в России описаны в рекомендациях по стандартизации 1323565.1.017-2018.
И вот у кого после этого всего сохранится впечатление дремучей отсталости РФ в вопросах собственной криптографии на фоне работ прогрессивного мирового сообщества по выведению из эксплуатации устаревших блочных алгоритмов в 64-битными блоками?
«Кузнечик» появился в ГОСТ 34.12-2015 отнюдь не потому, что ГОСТ 28147-89 якобы устарел, потому что нужно вводить развиваться, вводя в обиход и оборот нечто более современное. Поскольку само собой на ровном месте не появится нечто способное когда-нибудь в дальнейшем заменить ГОСТ 28147-89 в лице «Магма».
—————————
Про суету вокруг RFC 4357 — именно в нём были обозначены параметры таблицы перестановок, предложенные #CryptoPro:- OID: 1.2.643.2.2.31.4 (id-Gost28147-89-CryptoPro-D-ParamSet)
- OID: 1.2.643.2.2.31.3 (id-Gost28147-89-CryptoPro-C-ParamSet)
- OID: 1.2.643.2.2.31.2 (id-Gost28147-89-CryptoPro-B-ParamSet)
- OID: 1.2.643.2.2.31.1 (id-Gost28147-89-CryptoPro-A-ParamSet)
Это восходит к тому, что сам по себе ГОСТ 28147-89 позволяет использование различных наборов S-Box'ов, описывая тем самым не один алгоритм, а целое семейство.
И только через десять лет после RFC 4357, уже в ГОСТ 34.12-2015, на государственном уровне оказался официально зафиксирован набор S-Box'ов для однозначного определения шифра «Магма» — один конкретный вариант из множества реализаций ГОСТ 28147-89.
Соответственно, так же создал и RFC 7836 хорошо известным ТК 26 Росстандарта (Техническим комитетом по стандартизации «Криптографическая защита информации»). Описываемый набор S-Box'ов получил обозначение OID: 1.2.643.7.1.2.5.1.1, id-tc26-gost-28147-param-Z.
#маркетинг #криптография #шифры #crypto #cryptography #KDF #инфобез #infosec @Russia