| ||||
| ||||
| Здравствуйте! Возможно весьма глупый вопрос, но хотелось бы узнать мнение экспертов. Наконец осуществил ЭЦП/шифрование средствами CryptoAPI через сертификаты - вроде работает. Конечной целью является организация защищенного документооборота. Меня интересует как данные криптографические операции правильно применить в данной задачи. Нет ли каких стандартов? Вот описание моей реализации. Сертификаты открытых ключей хранятся как X.509 файлы в «центральном хранилище». Отправитель: - Подписывает документ (файл/буфер) закрытым ключом (ключ извлекается из контейнера) – на выходе получает файл с подписью (бинарник 64 байта). - Шифрование. Получает контекст сертификата получателя (сертификат в файле, который выбирается при выборе получателя), получает сессионный ключ, экспортирует сессионный ключ на ключе согласования, получает вектор инициализации, шифрует. На выходе получаем зашифрованный документ, экспортированный сессионный ключ, вектор инициализации + ЭЦП – допустим все это записываю в файлы, каждый из которых преобразую в Base64 и передаю получателю. Получатель: - Выполняет преобразование полученных зашифрованного документа / сессионного ключа / VI / подписи из Base64 в бинарный формат. - Расшифровывает документ: открытый ключ отправителя (для получения ключа согласования и импорта сессионного ключа) получает из файла сертификата, импортирует сессионный ключ, получает переданный вектор инициализации, расшифровывает. - Проверяет цифровую подпись. Все ли я сделал правильно? Будет ли такая схема считаться «юридически значимой»? Что тут можно доработать/улучшить? | ||||
| Ответы: | ||||
| ||||
| >Все ли я сделал правильно? Будет ли такая схема считаться «юридически значимой»? Что тут можно доработать/улучшить? "Юридически значимой" схема будет лишь в случае соответствия закону "Об ЭЦП" (создан УЦ, сертификат УЛ УЦ зарегистрирован в ЕГР, применяются сертифицированные СКЗИ, в сертификатах ключей подписи указываются "сведения об отношениях" и т.п. организационно-правовые и технико-технологические процедуры) | ||||
| ||||
| Спасибо, Вадим! Вы писали: "в сертификатах ключей подписи указываются "сведения об отношениях" и т.п. организационно-правовые и технико-технологические процедуры" Не могли бы вы прояснить, что вы имели ввиду под "организационно-правовые и технико-технологические процедуры"? - особенно технико-технологические Накладываются ли какие нибудь требования/органичения на "формат" передаваемых данных? Нет ли необходимости передавать зашифрованный документ/сессионный ключ/IV/подпись "упакованными" в какой либо формат и нет ли каких стандартов на этот счет? | ||||
| ||||
| Извините за назойливость, но не могли бы вы ответить хотябы на последнюю часть моего вопроса. Мне было бы удобнее защированный документ/iv/session key/подпись перегонять в base64, класть все это в xml-ку и так передавать получателю. Но нет ли более правильного/удобного/стандартизованного способа передачи подписанного и зашированного документа. | ||||
| ||||
| Конечно есть - PKCS7, высокоуровневые функции CryptoAPI кладут туда все что нужно. Удобно использовать если Вам непринципиально использовать XML. | ||||
| ||||
| Я использую низкоуровневые функции CryptoAPI (от высокоуровневых функций пришлось отказаться хотябы из-за необходимости загружать полностью файл в память при шифровании, файлы могут быть и большими, low-level Crypto API позволяют шировать "кусками"). Нет ли в числе low-level Crypto API функций которые позволяли паковать результат в PKCS7? Мне было бы _удобнее_ передавать документ описанным выше способом (упаковка в xml), но не будет ли это противоречить каким либо стандартам/законодательству? Опять же вопрос о юридической значимости передачи зашифрованного документа как xml... или необходимо все же PKCS7 (или что то подобное) - либо этот момент вообще не принципиален и на остается усмотрение разработчиков? | ||||
| ||||
| Как раз lowlevel CryptMsg* функции и работают с PKCS7. | ||||
| ||||
| Пользую еще "более low-level" CryptSignHash, CryptVerifySignature, CryptEncrypt, CryptDecrypt, etc. Есть ли что к ним для работы с PKCS7? | ||||
| ||||
| Нет. Пользуйтесь CryptMsg* | ||||
Максим