Запас прочности

Запас прочности

В рамках вех, предусмотренных направлением «Информационная безопасность» программы «Цифровая экономика», утвержденной Распоряжением Правительства Российской Федерации от 28 июля 2017 года № 1632-р, предусматривается создание системы стимулов использования национальной платежной системы. Разделом IV программы «Цифровая экономика» определено, что реализация мероприятий должна базироваться на основополагающих принципах информационной безопасности, включающих использование российских технологий и преимущественное использование отечественного программного обеспечения и оборудования, а также технологий защиты информации с использованием российских криптографических стандартов.

ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ ПО БЕЗОПАСНОСТИ

В рамках Плана мероприятий по направлению «Информационная безопасность» программы «Цифровая экономика» предусмотрена разработка технических требований по безопасности к компонентам платежной инфраструктуры (изделиям микроэлектроники, а также всему комплексу средств ИТ и ИБ) на основании гармонизации зарубежных и национальных требований по безопасности (далее – технические требования) в период с января 2018 года по июль 2019 года. Разработка данных технических требований должна быть осуществлена совместными усилиями Минпромторга России (ответственный исполнитель), Минкомсвязи России, ФСТЭК России, ФСБ России и Банка России.

УКАЗАНИЕ БАНКА РОССИИ № 3342-У

В настоящее время требования к информационным технологиям, используемым операторами услуг платежной инфраструктуры, для целей признания платежной системы национально значимой платежной системой, определяются Указанием Банка России от 25 июля 2014 года № 3342-У (далее – Указание). Данные требования можно логически разделить на следующие группы:

- требования к разработчикам программных средств;

- требования к материальным носителям платежных карт;

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

- требования к процессу изготовления (сборки) платежных карт;

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

В части материальных носителей платежных карт Указание ссылается на требования национальных стандартов Российской Федерации, разработанных в процессе гармонизации с одноименными международными стандартами ISO/IEC 7810, ISO/IEC 7811 и ISO/IEC 7816. Следует отметить, что некоторые из определенных в Указании национальных стандартов в настоящее время не актуализированы с соответствующими международными стандартами. Например, гармонизация национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 7811-2-2002 датируется 2002 годом, а в 2014 году был разработан новый международный стандарт ISO/IEC 7811-2:2014.

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

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

КОМПОНЕНТЫ ПЛАТЕЖНОЙ ИНФРАСТРУКТУРЫ

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

- платежные карты;

- POS-терминалы (Point-of-Sale);

- аппаратные модули защиты (Hardware Security Modules –HSM).

Производство данных элементов осуществляется международными и российскими компаниями. Например, производство платежных карт осуществляется компаниями - «Gemalto», АО «НоваКард» и др., производство POS-терминалов осуществляется компаниями - «HyperCom», «CyberNet», «VeriFone» и др., производство HSM осуществляется компаниями - «Gemalto», «Thales» и др.

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

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

ЗАРУБЕЖНЫЕ ТРЕБОВАНИЯ

Технические требования к реализуемым механизмам информационной безопасности и криптографической защиты информации к таким компонентам определяются различными документами по стандартизации, например, Payment Card Industry Data Security Standards (PCI DSS).

Данные стандарты разрабатываются советом - PCI Security Standards Council. Членами учредителями данного совета являются American Express, Discover Financial Services, JBC International, MasterCard и Visa Inc. Аффиллированными членами совета являются региональные и национальные платежные системы - Австралийская платежная ассоциация, Датская платежная ассоциация, Национальная платежная система Индии, а также Национальная система платежных карт (Платежная система «МИР») и другие.

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

В июне 2016 году PCI Security Standards Council опубликовало третью версию требования по безопасности к аппаратным модулям защиты (HSM) – «Payment Card Industry. PIN Transaction Security. Hardware Security Module. Modular Security Requirements» Version 3.0 (далее - Modular Security Requirements). По заявлению авторов Modular Security Requirements, данные требования являются минимально приемлемыми для снижения риска возможности проведения успешных атак. Таким образом, выдвигаемые в Modular Security Requirements требования не могут блокировать всевозможные угрозы безопасности информации, но направлены на снижение вероятности таких угроз и локализации их последствий в случае их успешного проведения.

Основными разделами Modular Security Requirements являются следующие:

- Core Requirements («Основные требования»), содержит подразделы:

- A – Physical Security Requirements («Требования к физической безопасности»);

- B - Logical Security Requirements («Требования к логической безопасности»);

- C – Policy and Procedures («Политика и процедуры»);

- Key-Loading Devices («Устройства ввода-вывода»), содержит подраздел:

- D – Key-Loading Devices («Устройства ввода-вывода»);

- Remote Administration («Удаленное администрирование»), содержит подразделы:

- E - Logical Security («Логическая безопасность»);

- F – Devices with Message Authentication Functionality («Изделия с функцией аутентификации сообщений»);

- G – Devices with Key-Generation Functionality («Изделия с функцией генерации ключей»);

- H – Devices with Digital Signature Functionality («Изделия с функцией электронной подписи»);

- Device Management Security Requirements («Требования к безопасности устройств»), содержит подразделы:

- I - Device Security Requirements During Manufacturing («Требования к безопасности изделий в процессе производства»);

- J - Device Security Requirements Between Manufacturer and Point of Initial Deployment («Требования к безопасности изделий между производителем и местом первоначального развертывания»).

ОТЕЧЕСТВЕННЫЕ ПРИНЦИПЫ

Приказом Федерального агентства по техническому регулированию и метрологии (Росстандарт) от 22 декабря 2017 года № 2068-ст утверждены рекомендации по стандартизации 1323565.1.012-2017 «Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации» (далее – Принципы), которые вводятся в действие с 1 мая 2018 года. Принципы разработаны на площадке технического комитета по стандартизации «Криптографическая защита информации» (ТК 026), с участием федерального органа исполнительной власти, уполномоченного в области обеспечения безопасности, а также организаций членов ТК 026, и аккумулировали и систематизировали накопленный опыт создания и разработки шифровальных (криптографических) средств защиты информации, не содержащей сведений, составляющих государственную тайну (далее — СКЗИ).

Данный документ носит методический характер и содержит в себе принципы, на которых должна основываться разработка и/или модернизация действующих СКЗИ. Настоящие Принципы позволяют сориентироваться и ознакомиться с:

- проблемами, возникающими при разработке (модернизации) и эксплуатации СКЗИ;

- правилами классификации классов разрабатываемых СКЗИ, а также совокупностями возможностей, которые могут быть использованы при создании способов, подготовке и проведении атак, для каждого класса защищенности;

- перечнем необходимых для создания и/или модернизации СКЗИ работ.

СУЩЕСТВЕННЫЕ ОСОБЕННОСТИ

При более детальном рассмотрение Modular Security Requirements и его сравнительном анализе с существующими отечественными нормативно-методическим документами в области криптографической защиты информации, в том числе Принципами, можно сделать несколько существенных замечаний:

1. Некоторые требования, определенные Modular Security Requirements, основаны на американских требованиях FIPS PUB 140-2 «Security Requirements for Cryptographic Modules», которые определяют общие требования к СКЗИ, сертифицируемые NIST.

2. Проанализировав структуру Modular Security Requirements, представленную выше, можно сделать вывод о том, что по аналогии с существующей отечественной практикой[1] средства криптографической защиты информации, в том числе, разделяются на средства имитозащиты (подраздел F), средства электронной цифровой подписи (подраздел H) и средства изготовления ключевых документов (подраздел G).

ПЕРЕСЕЧЕНИЯ

3. При более детальном ознакомлении с Modular Security Requirements и Принципами, нетрудно заметить, что множество требований, определенных Modular Security Requirements, и соответствующее множество, определенное Принципами, в значительной части пересекаются или практически дословно совпадают. Так, например:

- требование B6 Modular Security Requirements говорит о том, что устройство должно автоматически очищать или повторно инициализировать свои внутренние буферы, которые хранят конфиденциальную информацию до повторного использования буфера[2]. Пункт 6.1.11 Принципов определяет, что в состав СКЗИ должны входить компоненты, обеспечивающие очистку областей памяти, используемых СКЗИ для хранения защищаемой, ключевой, исходной ключевой и криптографически опасной информации, при освобождении и/или перераспределении областей памяти, путем записи в области памяти случайной информации, вырабатываемой датчиком случайных чисел;

- требование B10 Modular Security Requirements говорит о том, что устройство должно использовать разрешенные криптографические алгоритмы, режимы и размеры ключей[3]. В качестве допустимых к использованию криптографических алгоритмов Пункт 5.1.1 Принципов определяет, что при разработке (модернизации) СКЗИ должны использоваться криптографические механизмы, утвержденные в качестве национальных стандартов Российской Федерации или рекомендаций по стандартизации Росстандарта.

Определенные выше требования достаточно схожи по смыслу и у читателя возможно создается ощущение, что требования Modular Security Requirements не настаивают на использовании каких-либо определенных криптографических алгоритмов. Однако, это заблуждение. В технических комментариях к данным требованиям «Payment Card Industry. PTS HSM Security Requirements. Technical FAQs», опубликованных в июне 2016 года, определяется[4], что для обеспечения безопасности любых данных приемлемы только криптографические алгоритмы TDES, RSA, ECC, DSA и AES для операций шифрования или формирования/проверки электронной подписи, функции SHA256 или выше могут также использоваться для хэширования. Таким образом, с точки зрения Modular Security Requirements, в качестве разрешенных к реализации в HSM криптографических алгоритмов допускаются к использованию только зарубежные криптографические алгоритмы, некоторые из которых уже давно не обладают «абсолютными» криптографическими характеристиками;

- требование B13 Modular Security Requirements определяет, что устройство должно гарантировать, что каждый криптографический ключ используется только для одной криптографической функции[5]. Пункт 5.4.7 Принципов определяет, что для различных криптографических механизмов необходимо использовать различную ключевую информацию;

- требование I2 Modular Security Requirements говорит о том, что сертифицированное программное обеспечение должно быть защищено от несанкционированного изменения в течение его жизненного цикла, например, с использованием процедур дублирующего контроля или стандартизированных процедур аутентификации[6]. Пункт 6.1.9 Принципов определяет, что должен быть обеспечен контроль целостности СКЗИ на этапах хранения, транспортирования, ввода в эксплуатацию и эксплуатации всего жизненного цикла СКЗИ, а также контроль целостности среды функционирования СКЗИ на этапе эксплуатации СКЗИ. При этом для СКЗИ, начиная с класса KC3, рекомендуется использование криптографических механизмов контроля целостности.

Список пересекающихся требований Modular Security Requirements и Принципов можно продолжить далее. Такие пересечения не ограничиваются приведенными выше несколькими примерами.

4. По мнению автора, Принципы являются более общим документом, так как не ограничивают область применения и форм-фактор разрабатываемых СКЗИ, а требования Modular Security Requirements определяют только требования HSM, предполагаемых к использованию в платежных системах для защиты финансовых транзакций. Поэтому некоторые положения, заданные в Принципах, могут являться либо более жесткими по отношению к аналогичным требованиям, определенными Modular Security Requirements, либо не содержаться в Modular Security Requirements.

СИНТЕЗ МЕХАНИЗМОВ

В части методического обеспечения криптографических решений для платежных систем в рамках Подкомитета 3 «Криптографические алгоритмы и механизмы в национальной платежной системе Российской Федерации» экспертами ТК 026 с 2016 года проводятся работы по синтезу российских криптографических механизмов во всех сегментах платежной системы, а также исследования по их анализу. Решение данной задачи осложнялось отсутствием возможности внесения радикальных изменений в существующие протоколы функционирования платежных систем.

В течение 2016-2017 гг. были предложены соответствующие криптографические механизмы, которые базируются на существующих национальных стандартах в области криптографической защиты информации. В отношении данных решений были проведены необходимые исследования как посредством изучения применимости конкретных классов методов криптографического анализа, так и в парадигме доказуемой стойкости. Данный анализ проводился в моделях нарушителя, релевантных для практики использования разрабатываемых протоколов. Для всех протокольных решений удалось получить полный комплект обоснований, некоторые из полученных научных результатов[7] докладывались на конференциях РусКрипто’2017 и CTCrypt 2017.

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

В результате этой деятельности, в конце 2017 года – начале 2018 года ТК 026 был завершен комплекс работ, позволивший своевременно обеспечить утверждение восьми рекомендаций по стандартизации, определяющих наиболее актуальные криптографические механизмы в платежных системах:

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

- алгоритмы блочного шифрования при формировании проверочного параметра платежной карты и проверочного значения PIN;

- функции диверсификации для формирования производных ключей платежного приложения;

- режимы алгоритма блочного шифрования в защищенном обмене сообщениями между эмитентом и платежным приложением;

- алгоритмы согласования ключа и блочного шифрования при офлайновой проверке PIN;

- режимы алгоритма блочного шифрования в протоколе защищенного обмена сообщениями в процессе эмиссии платежных карт;

- режимы алгоритма блочного шифрования, алгоритмов электронной подписи и функции хэширования в процедуре офлайновой аутентификации платежного приложения;

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

ГАРМОНИЗАЦИЯ

На основании проведенного анализа, можно сделать вывод, что в отношении HSM процесс разработки технических требований по безопасности к ним целесообразно осуществлять на основании гармонизации зарубежных требований - «Payment Card Industry. PIN Transaction Security. Hardware Security Module. Modular Security Requirements» и отечественных рекомендаций по стандартизации, в том числе - «Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации».

В заключение, стоит отметь, что значительная часть механизмов криптографической защиты информации, реализуемых в современных отечественных HSM, спроектированных и разработанных в соответствии с Принципами, реализована с существенным запасом прочности и потенциально может соответствовать большинству положений международных требований «Payment Card Industry. PIN Transaction Security. Hardware Security Module. Modular Security Requirements». В настоящее время, на отечественном рынке средств защиты информации ряд российских компаний предлагают аппаратные модули доверия - HSM, которые имеют действующие сертификаты соответствия ФСБ России по требованиям к безопасности.

[1]                      Приказ ФСБ России от 9 февраля 2005 г. № 66 «Об утверждении положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ — 2005)».

[2]                      The device must automatically clear or reinitialize its internal buffers that hold sensitive information prior to reuse of the buffer.

[3]              The device uses accepted cryptographic algorithms, modes, and key sizes.

[4]                      Q 24. September 2015. What are the algorithms and associated minimum key lengths that are acceptable for use with the default operation of any open protocol used in a HSM?

The minimum requirements for cryptographic algorithms use to provide security to any confidential data, including transmitted using open protocols, is specified in DTR B11. Only TDES, RSA, ECC, DSA and AES are acceptable for encryption or signing operations. SHA256 or above may also be used for hashing purposes.

[5]              The device ensures that each cryptographic key is only used for a single cryptographic function.

[6]                      The certified firmware is protected and stored in such a manner as to preclude unauthorized modification during its entire manufacturing lifecycle – e.g., using dual control or standartdized cryptographic authentication procedures.

[7]                      Liliya Ahmetzyanova, Evgeny Alekseev, Grigory Karpunin, Stanislav Smyshlyaev. On cryptographic properties of the CVV and PVV parameters generation procedures in payment systems. CTCrypt 2017 proceedings, pp. 10-35.