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

ты в чат гпт писал и промахнулся?

(1) Нейронки уже все сделали, мне интересно что сообщество может предложить :)

(2) вот и поделился бы решением, если оно рабочее

(0) А где будет аппаратный ключ стоять?

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

(5) Вас не смущает, что в отчеты вы зашифрованные поля не вытащите просто так? Точнее вытащите в зашифрованном виде. Знать бы цели задачи. Явно же шифрование не является целью.

(3) Решение рабочее но выглядит ненадежно, ии собрал мне приложение обертку для вызова из командной строки, с интерфейсом управления для вызова из 1С. Это приложение создает заполняет и читает базы данных keepass зашифрованные аппаратным рутокеном, базы хранятся в РСВ в связке со своими объектами. юзер один раз вводит пин-код ключа, дальше 1с читает, заполняет шифрует и расшифровывает данные объектов. В СКД даже работает.
Поделиться готовым решением не могу, заказчик возражает.

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

(6) Там шифруются какие-то финансовые данные, строки, это не ресурсы регистров а в крайнем случае какие-то реквизиты объектов, в скд кстати довольно шустро все расшифровывается при выводе.

(7) [ии собрал мне приложение]
задай ИИ промт-описать решение языком понятным мисте на уровне исключающем раскрытие коммерческой тайны

[Архитектура] Безопасное хранение конфиденциальных данных в 1С: интеграция с KeePass и аппаратными токенами RuToken (PKCS#11)
Проблема:
Стандартные механизмы шифрования 1С (ХранилищеЗначения) не всегда удовлетворяют строгим политикам ИБ. Возникает потребность хранить отдельные реквизиты справочников и документов (пароли, ключи, персональные данные) в криптографически стойких контейнерах сторонних менеджеров паролей (KeePass), при этом доступ к базам должен аппаратно ограничиваться токенами RuToken.

Требовалось сделать механизм «прозрачным» для разработчика конфигурации: чтобы вынос данных за периметр 1С не требовал написания уникального кода для каждой формы.

Стек технологий:

Платформа: 1С:Предприятие 8.3.27
Менеджер паролей: KeePass 2.x (формат KDBX 4)
Аппаратный ключ: RuToken (интерфейс PKCS#11)
Middleware (Прокси): C# (.NET Framework 4.8)
Библиотеки C#: KeePassLib (официальный NuGet), Pkcs11Interop (v4.x), System.Text.Json
Архитектура решения
Прямое использование COM-объектов или встроенных средств 1С для работы с PKCS#11 и форматом KDBX невозможно или крайне нестабильно (проблемы с разрядностью, утечки памяти).

Было принято решение реализовать изолированный C# CLI-прокси, который запускается как дочерний процесс и общается с 1С через стандартные потоки ввода/вывода (StdIn / StdOut), обмениваясь JSON-сообщениями.

Почему не HTTP API (микросервис)?
Даже на localhost HTTP-трафик может быть перехвачен локальными снифферами. StdIn/StdOut (pipes) работает в рамках памяти процесса-родителя, что исключает сетевой перехват конфиденциальных данных при передаче.

Жизненный цикл сессии (Stateful Proxy):

1С запускает прокси через WScript.Shell.Exec().
Отправляет команду init_token с ПИН-кодом от Рутокен.
Прокси открывает сессию с токеном (держит её в памяти) и ждет команд.
1С отправляет команды на создание/чтение/запись баз.
При закрытии формы 1С отправляет команду exit, прокси очищает память и завершает процесс.
Ключевые технические узлы и интересные находки
1. Изоляция мастер-пароля
Критически важное требование ИБ: мастер-пароль от базы KDBX никогда не должен попадать в память процесса 1С.
В прокси реализована логика: 1С передает только метку ключа на токене (например, "wish"). C#-прокси сам обращается к PKCS#11, считывает значение объекта CKO_DATA по метке, формирует CompositeKey и открывает базу. В 1С возвращаются только сами данные записей.

2. Хранение файлов баз (KDBX) внутри 1С
Базы KeePass не должны валяться на диске сервера в виде файлов. Файл .kdbx хранится в регистре сведений 1С в реквизите типа ХранилищеЗначения.
Алгоритм работы:

1С выгружает базу из ХранилищеЗначения во временный файл на диске.
Передает путь к файлу в C# прокси.
Прокси модифицирует базу и сохраняет её на диск.
1С считывает измененный файл и кладет обратно в ХранилищеЗначения.
Таким образом, база существует на диске сервера лишь доли секунды во время транзакции.
3. Метаданные и универсальный драйвер форм (1С)
Чтобы не писать код для каждой формы, реализован паттерн поиска по метаданным.
Разработчик конфигурации добавляет реквизиту или табличной части префикс хд_ (например, хд_СекретныйКлюч, хд_ИсторияДоступа).
Универсальная общая команда на сервере:

Рефлексивно обходит метаданные переданного объекта.
Извлекает все свойства с префиксом хд_.
Сериализует их (скалярные типы — в строку, табличные части и ссылки — через ЗначениеВСтрокуВнутр()).
Формирует массив JSON и отправляет прокси одной транзакцией.
4. Подводные камни Pkcs11Interop и KeePassLib
В процессе разработки столкнулись с несколькими неочевидными проблемами:

Смена API Pkcs11Interop: Библиотека версии 5.x перешла на фабрики (Factories), что ломает обратную совместимость. Для простоты CLI-утилит было решено зафиксировать версию на 4.1.2, где API проще (new Pkcs11(), new Session()). Кроме того, поиск объектов на токене в 4.x строго требует трех шагов: FindObjectsInit -> FindObjects -> FindObjectsFinal. Пропуск Final блокирует сессию токена.
Нативная криптография KeePass (Argon2): Начиная с KeePass 2.54, по умолчанию используется алгоритм хеширования Argon2, требующий нативных (C/C++) библиотек KeePassLibN.x64.dll. Чистый управляемый KeePassLib из NuGet не сможет открыть новые базы без этих DLL. Решение: собирать прокси под .NET Framework (для 100% совместимости с KeePassLib), компилировать под x64 и класть нативные DLL от самого KeePass рядом с exe-файлом прокси.
Разрядность драйверов Рутокен: Драйверы Рутокен ставятся раздельно для x86 и x64. Папка Program Files (x86) и SysWOW64 содержит 32-битные DLL (rtPKCS11ECP.dll). 64-битная версия лежит в System32 и Program Files. Чтобы не зависеть от установленных драйверов на сервере, мы применяем Local Deployment: нужная разрядность rtPKCS11ECP.dll просто лежит в папке с приложением прокси. Функция LoadLibrary Windows сначала ищет DLL в каталоге запуска EXE.
5. Случайное распределение ключей
При создании новой защищенной базы для объекта, система рандомно выбирает один из 24 предзагруженных ключей на токене (передается массив меток). Это позволяет распределить нагрузку и соблюсти принцип "не хранить все яйца в одной корзине" на уровне аппаратного ключа.

Итог
Получился надежный механизм, удовлетворяющий параноидальным требованиям ИБ:

Данные не хранятся в 1С в открытом виде.
Мастер-пароли не пересекают границы доверенной зоны (C#).
Доступ невозможен без физического токена.
Для внедрения в новые объекты 1С разработчику достаточно добавить префикс к реквизиту — код форм не меняется.

(0)[Прокси модифицирует базу и сохраняет её на диск.
1С считывает измененный файл и кладет обратно в ХранилищеЗначения.
Таким образом, база существует на диске сервера лишь доли секунды во время транзакции.]
где процедура гарантированного затирания данных в удаленном файле ?

(12) Зачем, там ключи 512бит, эти базы вообще можно не стирать с диска.

(13) т.е. это не расшифрованная база, из которой потом СКД тащит данные ?

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

"Решение рабочее но выглядит ненадежно"
"Получилось довольно безопасно"

(16) есть вероятность что процесс 1с завершится, а запись в базу и ее сохранение нет, поэтому ненадежно.

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

Применять такое разумно только когда есть прямой доступ к базе левыми людьми (например база в облаке, а шифрование/дешифрование идет локально на клиенте)
Но нафига давать такой доступ?

Просто храните базу в защищенном месте без доступа левых напрямую
И доступ разруливайте на уровне прав, не связывайтесь с шифрованием

(18) [Но нафига давать такой доступ?]
это твой, т.е. 1С-ника доступ с полными правами + админов права на сиквеле/его бэкапы

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

(18) Алгоритмы шифрования давно всем известны keepass работает с популярными алгоритмами, база биткоина и других криптовалют публично лежит в открытом доступе и никто ее не пытается стереть или спрятать алгоритмы шифрования тоже всем известны, пожалуйста открывайте и забирайте "если есть ключ". При этом биткоин использует 256бит ключи. В наше время многие держат базы 1С на облачных серверах, а кто ее там может скопировать вообще неизвестно, а в 1С ничего не зашифровано все в открытом доступе.

Если аппаратный ключ накроется, то теряем колонки в базе?

(22) Кто ж его не экспортируемым будет делать? Можно конечно и проверку на срок действия сертификата спросить...

Тут другой вопрос, если ключ доступен, то и все данные доступны всем на основании прав 1С?

"StdIn/StdOut (pipes) работает в рамках памяти процесса-родителя, что исключает сетевой перехват конфиденциальных данных при передаче. "

Счастье - в неведении.

Простейший createremotethread() и сплайсинг winapi функций работы с pipes будут читать ваши трубы, не привлекая внимание.

(25) Примерно про это и пытался намекнуть
И можно сам ключик перехватить, и далее не привлекая внимание фигачить что угодно

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

(22) хранить копию ключа надо в сейфе

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

(22) это рутокен, можно сделать резервные копии, хранить в разных местах, в целом да такой риск тоже имеется.
(23) железный ключ доступен в одном сеансе, после подключения  к сеансу 1с прокладка кешируется для одного сеанса, например через модуль с повторным возвратом значений для сеанса.
(25)(26) Спасибо за инфу, ии тоже говорил про этот риск, называя такой способ маловероятным но возможным. Буду думать что с этим делать. Клиент работает в изолированной системе, там даже интернета нет. От основных рисков такой подход защищает, - перехваты паролей утечка базы, вывод информации другими "сотрудниками" у которых оказались права и доступ к базе.
Всем спасибо за комментарии и интерес к теме!

(2)> мне интересно что сообщество может предложить :)
Как видишь, оно тебе может предложить только идею, что все, что ты сделал - не нужно.

работает только под вин?

(26) > Все способы шифрования держатся на неведении незашифрованных данных

> А еще точно зная данные внутри - расшифровать нет особых проблем

какой-то бред

все распоследние способы шЫфрования держатся на магии больших простых чисел

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

(31) "вся надежда на квантовые компуктеры" с ними тоже не все так просто. Они, в теории, выдают сразу все возможные ответы, и какой-нибудь шифр "0012 2540 2571 2587..." можно расшифровать одновременно как "Мама мыла Раму", "Хрен по 2.50 на рынке", "Зеленый вкуснее вдвойне" и еще куча вариантов.

(31) Ты попутал направленные функции, которые в одну сторону легко а в другую слишком сложно вплоть до полного перебора/подбора

(32) Правильно
Но когда знаешь оба сообщения и шифрованное и до шифрования - все левые варианты отсекаются
И можно легко читать прочие сообщения с тем же шифрованием и ключем
Даже если ключ слегка поменялся - можно зная несколько ключей подряд вычислить следующий

(33) я не попутал, а у вас бред написан "про неведение незашифрованных данных и про зная точно данные внутре"

(34) если знаешь, то квантовый не нужен. а если не знаешь, то квантовый бесполезен.

вот тут для крестьян коротенько

(много букв и не все понятные)

https://thecode.media/5-encrypts/

а так да, магия больших простых чисел

ИИчко

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

Несколько фактов о рекордсмене:

Длина: Число состоит из 41024320 десятичных знаков. Если его распечатать, оно займет более 10 тысяч страниц.

Класс: Относится к так называемым простым числам Мерсенна

Открытие: Было найдено 12 октября 2024 года математиком Люком Дюраном в рамках проекта Great Internet Mersenne Prime Search (GIMPS) с использованием облачных сетей.
Простые числа используются в современных алгоритмах шифрования.
За нахождение еще более крупных чисел проектом GIMPS предусмотрены денежные премии.

(33) у вас вот недавно ИИчко помогало расшифровать для нафигатора.

у вас и данные внутре были известны и вроде бы не сильно зашЫфрован файл был

как успехи?

(38) В том и проблема у меня что данные внутри неизвестны
Я даже не знаю сколько камер скорости внутри и какие именно
Ибо источники данных совсем разные
Понятно что большая часть камер должны пересекаться
Но хз например двухсторонняя камера кодируется одной с двумя направлениями или как две рядом каждая с одним направлением и т.д.

(38) Имхо судя по "вроде бы не сильно зашЫфрован файл был" - успехи с пониманием этих вот больших чисел у кого то плохие
Ибо это нифига не магия а обычная математика

Даже на обычном XOR можно сделать надежное шифрование
Которое хрен вскроешь (за разумный срок) не имея пар сообщений (открытых и закрытых)
Если даже не знаем языка внутри, или точно имеющихся слов/наименований - не получается использовать статистические методы, типа частот букв в некоем языке и т.д.

(36) ну не совсем так
У меня вот был проект по созданию APS системы планирования, расчет производился математическим солвером, довольно сложный и длительный.  и тут есть важный факт - результат мы 100% можем очень бьыстро проверить и убедится что он верный, но вычислить мы его можем только за длительное время
Квантовый же компьютер может его посчитать сразу и мы сразу, довольно простыми методами можем убедится что он посчитал правильно.
по этому это не совсем корректное утверждение

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

(40) вброшу еще про хэш-функцию (не обязательно хранить пороли,  можно хранить этот самый хэш)

у меня нормально с пониманием этих вот больших простых чисел

главный вопрос математики: а не всё ли равно?

(42) В курсе что любая хэш-функция имеет коллизии?
И теоретически для любой хеш-функции можно подобрать входной набор соответствующий заданному хэшу?
И для md5 уже научились это делать практически
Т.е. если сперли базу хэшей паролей в md5 - считай что сама база исходных паролей ушла

(37) Криптография основана не только на одном алгоритме больших простых чисел
Это всего лишь один из примеров односторонних ("однонаправленных") функций
Причем обычно используются не просто простые числа, а разложение на простые множители

(41) Шифрование — это обратимое изменение данных таким образом, чтобы другие люди не могли их прочитать или понять...

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

геном человеков научились читать (считай расшифровали), а вот с пониманием что-то не очень (The Human Genome Project, HGP)

(43) > И теоретически для любой хеш-функции можно подобрать входной набор соответствующий заданному хэшу?

теоретически можно найти самое большое простое число и даже найти последние четыре цифры отношения длины любой окружности к ее диаметру

(46)
Ты точно умеешь в математику? Уже давно wiki:Теорема_Евклида доказана

(47) пока что самое большое число найдено в 2024 году :) поиски продолжаются

плоские шутки от Юрия Лозы

(46) А вот насчет длины wiki:Пи_(число)
Точнее периодичности все сложно
Если наш четырехмерный мир все же симуляция - значит есть некий генератор псевдослучайных чисел, пусть и очень надежный
Значит число Пи теоретически начнет повторяться после запятой - значит можно "даже найти последние четыре цифры" цикла

ключи от телеги

(49) можно сгенерировать апериодическую последовательность, которая никогда не будет повторяться глобально (отдельные фрагменты сколь угодно большой длины могут повторяться, но вся последовательность никогда).

(49) + Точка Фейнмана
wiki:Точка_Фейнмана

(51) это ничего не меняет особо
даже если с помощью одного или нескольких генераторов задавать начальные параметры для других генераторов - это только оттягивает конец ))

(51) фраза "никогда" должна быть подкреплена математическим доказательством

(54) есть пределы доказуемости по всей строгости :) какое-то "Число Ω"

https://elementy.ru/nauchno-populyarnaya_biblioteka/430319/Predely_dokazuemosti

(55) вот именно по этой причине, нельзя произносить слово "никогда" применительно к недоказанной теории

(51) обычные ряды для расчета какого-нибудь корня n степени из простого числа. Чем больше добавляешь в ряд членов, тем длиннее получаешь неповторяющуюся последовательность. Так как ряды по определению бесконечны, последовательность тоже будет бесконечной.

АПИ на локал хост легко перехватить. Типа юзеру с аппаратным ключом подсунуть внешний отчет или изменить, что то что он использует в конфе 1с  чтобы вытянулись данные незаметно для юзера большая проблема.

(58) Они не от юзера защищаться хотят а от хостинга, который полный доступ физический к базе имеет и кстати к АПИ
Так что не проблема весь обмен с ключом перехватить и банально его сдампить

(59) А это что-то меняет? Что хостингу может помешать подменить в какой то момент конфу или отчет и вытащить эти данные в расшифрованном  виде уже при последующей работе юзера?

(60) О том и речь что ничего не мешает
То что хочет ТС совершенно ненадежно
И нафик не нужно
Надо просто хостера поменять или закрыть ему доступ на физическом уровне

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

хостер буквально место в серверной и вышестоящий канал связи предоставляет и все

Может не стоит хранить в базе то, что нужно зашифровать? Сделать отдельное приложение, откуда будут браться данные и расшифровываться при необходимости.