| ||||
| ||||
| В одном из блогов ЖЖ был встречен следующий комментарий (речь шла об отчетности черещ интеренет): [quote] Теперь пара мыслей насчет сертификации. Насколько я понимаю, сертификация должна подтвердить, что прога удовлетворят определенным требованиям в плане защиты информации, а это как минимум означает, что ее поведение полностью документировано, известно и контролируемо. Особенно это должно относится к работе с ключами, поскольку одна чуть-чуть некорректно написанная процедура _запросто_ может привести к тому, что приватные ключи будут лежать в файле подкачки =) Или к ненадежной инициализации ГСЧ, что способно поставить раком любую криптозащиту, независимо от ее навороченности и размеров ключей. Стоит отметить, что кроме КриптоПро и ActiveX-компонентов, написанных собственно разработчиками системы, все остальное - компоненты от Microsoft. Особо меня интересует вопрос, используются ли в КриптоПро функции Microsoft CryptoAPI. Дело в том, что большинство эти компонентов - системные, а следовательно обновляемые, в частности через широко известный Windows Update. Таким образом, после любого обновления встает вопрос, а остается ли сертификация в силе (я говорю сейчас только о технической сторонне вопроса), если большая часть требуемых компонентов была заменена другими версиями, которые явно сертификацию не проходили. И если M$ CryptoAPI используется (а этот API весьма скудно документирован и глубоко интегрирован в windows), то мы уже не можем после обновления венды 100%-но утверждать, что с нашими ключами работают 100%-но сертифицированные компоненты. Второй момент связан с тем, что конкретно сертифицирут. Я честно говоря так до конца и не понял, должны ли быть для юридически значимого документооборота сертифицированы все компоненты, участвующие в работе с ключами и передаваемыми данными, или же только криптографические средства. Если первое, то мы приходим к необходимости сертифицировать строго определенный набор софта строго определенных билдов, вплоть до заверения отдельной ЭЦП списка хэш-функций всех системных программ и библиотек. Система с другим билдом advapi32.dll или crypt32.dll должна будет считаться в этом случае несертифицированной. В случае же сертификации только криптографического ядра остается открытым вопрос надежности и безопасности среды исполнения. Использование даже самых надежных криптосредств в ненадежной среде (например, при не совсем корректно работающем CryptoAPI) резко снижает стойкость. [/quote] Естественно, никакого ответа на этот комментарий (пока?) не последовало... Подозреваю, доля правды тут есть, но но хотелось бы узнать поподробнее, получить подтверждение/опровержение приведенным словам от специалистов работающих в данной области. Заранее спасибо! |
Дмитрий