Типы ключей, алгоритмы и операции

  • Статья

Key Vault поддерживает два типа ресурсов: хранилища и управляемые модули HSM. Оба типа ресурсов поддерживают несколько типов ключей шифрования. Чтобы просмотреть сводку поддерживаемых типов ключей, типы защиты по каждому типу ресурсов см. в разделе "Сведения о ключах".

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

Типы ключей, размеры и кривые Шифрование, расшифровка
(Упаковка, распаковка)		 Подписывание, проверка
EC-P256, EC-P256K, EC-P384, EC-P521 Неприменимо ES256
ES256K
ES384
ES512
RSA 2K, 3K, 4K RSA1_5
RSA-OAEP
RSA-OAEP-256		 PS256
PS384
PS512
RS256
RS384
RS512
RSNULL
AES 128-разрядная, 256-разрядная
(Только для управляемых устройств HSM)		 AES-KW
AES-GCM;
AES-CBC		 Неприменимо

Алгоритмы EC

Для ключей EC-HSM поддерживаются приведенные ниже идентификаторы алгоритма.

Типы кривых

  • P-256 — кривая NIST P-256, определенная в документе DSS FIPS PUB 186-4.
  • P-256K — кривая SEC SECP256K1, определенная в документе SEC 2: Recommended Elliptic Curve Domain Parameters (SEC 2: рекомендованные параметры домена эллиптической кривой).
  • P-384 — кривая NIST P-384, определенная в документе DSS FIPS PUB 186-4.
  • P-521 — кривая NIST P-521, определенная в документе DSS FIPS PUB 186-4.

SIGN/VERIFY

  • ES256 — ECDSA для хэшей SHA-256 и ключей, созданных на основе кривой P-256. Этот алгоритм описан в документации по RFC7518.
  • ES256K — ECDSA для хэшей SHA-256 и ключей, созданных на основе кривой P-256K. Этот алгоритм находится на этапе ожидания стандартизации.
  • ES384 — ECDSA для хэшей SHA-384 и ключей, созданных на основе кривой P-384. Этот алгоритм описан в документации по RFC7518.
  • ES512 — ECDSA для хэшей SHA-512 и ключей, созданных на основе кривой P-521. Этот алгоритм описан в документации по RFC7518.

Алгоритмы RSA

Для ключей EC-HSM в Key Vault поддерживаются приведенные ниже идентификаторы алгоритма.

WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT

  • RSA1_5 — это шифрование ключа RSAES-PKCS1-V1_5 [RFC3447].
  • RSA-OAEP — алгоритм RSAES, использующий оптимальное асимметричное шифрование с дополнением (OAEP) [RFC3447], с параметрами по умолчанию, указанными в RFC 3447 в разделе A.2.1. В этих параметрах по умолчанию используется хэш-функция SHA-1 и функция генерации маски MGF1 с помощью SHA-1.
  • RSA-OAEP-256 — RSAES с использованием OAEP (оптимальное асимметричное шифрование с дополнением), хэш-функции SHA-256 и функции MGF1 для создания маски с поддержкой SHA-256.

SIGN/VERIFY

  • PS256 — RSASSA-PSS с помощью SHA-256 и MGF1 с SHA-256, как описано в RFC7518.
  • PS384 — RSASSA-PSS с помощью SHA-384 и MGF1 с SHA-384, как описано в RFC7518.
  • PS512 — RSASSA-PSS с помощью SHA-512 и MGF1 с SHA-512, как описано в RFC7518.
  • RS256 — RSASSA-PKCS-v1_5, использующий SHA-256. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-256 и иметь длину в 32 байта.
  • RS384 — RSASSA-PKCS-v1_5, использующий SHA-384. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-384 и иметь длину в 48 байтов.
  • RS512 — RSASSA-PKCS-v1_5, использующий SHA-512. Предоставленное приложением значение хэш-кода должно быть вычислено с помощью SHA-512 и иметь длину в 64 байта.
  • RSNULL — специализированный вариант использования для реализации определенных сценариев TLS (см. RFC2437).

Примечание.

DigestInfo создается на стороне сервера для операций подписи, которые создают алгоритмы RS256, RS384 и RS512.

Алгоритмы симметричных ключей (только для управляемых устройств HSM)

  • AES-KW — обертка ключа AES (RFC3394).
  • AES-GCM — шифрование AES в режиме счетчика с аутентификацией Галуа (NIST 800-38d).
  • AES-CBC — шифрование AES в режиме сцепления блоков шифра (NIST SP 800-38a).

Примечание.

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

Операции с ключами

Key Vault, включая управляемый модуль HSM, поддерживает следующие операции с объектами ключей:

  • Создание. Клиенты могут создавать ключи в Key Vault. Значение ключа создается в Key Vault и хранится в нем. Оно не выдается клиенту. В Key Vault можно создать асимметричные ключи.
  • Импорт. Клиенты могут импортировать имеющиеся ключи в Key Vault. Асимметричные ключи можно импортировать в Key Vault с помощью нескольких различных методов упаковки в конструкции JWK.
  • Обновление. Клиенты с достаточными разрешениями могут изменять метаданные (атрибуты ключей), связанные с ключами, ранее сохраненными в Key Vault.
  • Удаление. Клиенты с достаточными разрешениями могут удалять ключи из Key Vault.
  • Вывод списка. Клиенты могут вывести список всех ключей в данном Key Vault.
  • Вывод списка версий. Клиенты могут вывести список всех версий данного ключа в данном Key Vault.
  • Получение. Клиенты могут извлечь открытые части данного ключа в Key Vault.
  • Резервное копирование. Экспорт ключей в защищенной форме.
  • Восстановление. Импорт ранее заархивированного ключа.
  • Выпуск: безопасное освобождение ключа для авторизованного кода, выполняемого в конфиденциальной вычислительной среде. Для этого требуется аттестация, которая соответствует требованиям release_policy ключа доверенной среды выполнения (TEE).
  • Смена: изменение существующего ключ путем создания новой версии ключа (только для Key Vault).

Дополнительные сведения о работе с ключами см. в справочнике по работе с Azure Key Vault с помощью REST API.

После создания ключа в Key Vault с его использованием можно выполнять следующие криптографические операции:

  • Подпись и проверка. Строго говоря, эта операция является подписью или проверкой хэша, так как Key Vault не поддерживает хэширование содержимого в рамках создания подписи. Приложения должны хэшировать данные для подписи локально, а затем запрашивать подпись хэша в Key Vault. Проверка подписанных хэшей поддерживается в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для максимальной производительности приложений операции VERIFY следует выполнять локально.
  • Шифрование и упаковка ключа. Ключ, хранимый в Key Vault, можно использовать для защиты другого ключа, как правило, симметричного ключа шифрования содержимого (CEK). Если ключ в Azure Key Vault асимметричен, используется шифрование ключа. Например RSA-OAEP, а операции WRAPKEY/UNWRAPKEY эквивалентны операциям ENCRYPT/DECRYPT. Если ключ в Azure Key Vault симметричен, применяется упаковка ключа. Например, AES-KW. Операция WRAPKEY поддерживается в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для оптимизации производительности приложений рекомендуется выполнять операции WRAPKEY локально.
  • Шифрование и расшифровка. Ключ, хранимый в Azure Key Vault, можно использовать для шифрования или расшифровки одного блока данных, размер которого определяется типом ключа и выбранным алгоритмом шифрования. Операция шифрования предоставляется в качестве удобного механизма для приложений, у которых нет доступа к материалам открытого ключа. Для оптимизации производительности приложений операции ENCRYPT нужно выполнять локально.

Хотя операции WRAPKEY и UNWRAPKEY с использованием асимметричных ключей могут показаться излишними (так как они эквивалентны операции ENCRYPT и DECRYPT), важно использовать различные операции. Это обеспечивает разделение семантики и авторизации этих операций, а также целостность в случаях, когда служба поддерживает другие типы ключей.

Azure Key Vault не поддерживает операции EXPORT. Как только ключ подготовлен в системе, нельзя извлечь его или изменить его материал. Однако пользователям Key Vault ключ может потребоваться для других вариантов использования, например при его удалении. В этом случае они могут использовать операции BACKUP и RESTORE для экспорта или импорта ключей в защищенной форме. Ключи, созданные в ходе операции BACKUP, не могут использоваться за пределами Key Vault. Кроме того, в различных экземплярах Key Vault также можно использовать операцию IMPORT.

Пользователи могут ограничивать любую из криптографических операций, поддерживаемых Key Vault, для каждого ключа с помощью свойства key_ops объекта JWK.

Дополнительные сведения об объектах JWK см. в статье о веб-ключе JSON (JWK).

Операции политики смены ключа

Автоматическую смену ключей для Key Vault можно задать путем настройки политики автоматической смены ключей. Эта возможность доступна только для ресурсов Key Vault.

  • Получение политики поворота: получение конфигурации политики поворота.
  • Настройка политики поворота: настройка конфигурации политики поворота.

Атрибуты ключей

В дополнение к материалу ключа можно указать следующие атрибуты. В запросе JSON ключевое слово атрибутов и кавычки "{' '}" необходимы, даже если атрибуты не указаны.

  • enabled. Необязательный атрибут с логическим значением, по умолчанию — true. Указывает, является ли ключ активным и подходит ли для операций шифрования. Атрибут включено используется с nbf и exp. Если операция возникает между nbf и exp, она будет разрешена только в том случае, если включено значение true. Операции вне окна nbf / exp автоматически запрещаются, за исключением расшифровки, выпуска, отмены и проверки.
  • nbf. Необязательный атрибут со значением в формате IntDate, значение по умолчанию — "now". Атрибут nbf (не раньше) определяет время, до которого ключ НЕ ДОЛЖЕН использоваться для криптографических операций, за исключением расшифровки, выпуска, распаковки и проверки. Обработка атрибута nbf требует, чтобы текущая дата и время наступали позже или соответствовали дате и времени, перечисленным в атрибуте nbf. Key Vault может предоставить кратковременную отсрочку, обычно не более чем несколько минут, чтобы учесть разницу в показаниях часов. Нужно указать число, содержащее значение IntDate.
  • exp. Необязательный атрибут со значением в формате IntDate, значение по умолчанию — "forever". Атрибут exp (time time) определяет время окончания срока действия или после чего ключ не должен использоваться для криптографической операции, за исключением расшифровки, выпуска, отмены и проверки. Обработка атрибута exp требует, чтобы текущая дата и время наступали раньше или соответствовали дате и времени, перечисленным в атрибуте exp. Key Vault может предоставить кратковременную отсрочку, обычно не более чем несколько минут, чтобы учесть разницу в показаниях часов. Нужно указать число, содержащее значение IntDate.

Существуют более доступные только для чтения атрибуты, включенные в любой ответ, включающий ключевые атрибуты:

  • created. Необязательный атрибут со значением в формате IntDate. Атрибут created указывает, когда была создана эта версия ключа. Это значение равно NULL для ключей, созданных перед добавлением данного атрибута. Нужно указать число, содержащее значение IntDate.
  • updated. Необязательный атрибут со значением в формате IntDate. Атрибут updated указывает, когда была обновлена эта версия ключа. Это значение равно NULL для ключей, которые в последний раз обновлялись перед добавлением данного атрибута. Нужно указать число, содержащее значение IntDate.
  • hsmPlatform: строка, необязательно. Базовая платформа HSM, которая защищает ключ.
    • Значение hsmPlatform 2 означает, что ключ защищен нашей последней платформой FIPS 140 уровня 3, проверенной платформой HSM.
    • Значение hsmPlatform со значением 1 означает, что ключ защищен нашей предыдущей платформой HSM уровня 140 FIPS 2.
    • Значение hsmPlatform 0 означает, что ключ защищен криптографическим модулем FIPS 140 уровня 1 HSM.
    • Если этот параметр не задан управляемым пулом HSM, он защищен нашей последней платформой HSM уровня 140 FIPS 3.

Важно отметить, что ключи привязаны к HSM, в котором они были созданы. Новые ключи легко создаются и хранятся в новых виртуальных машинах HSM. Хотя нет способа переноса или передачи ключей, новые версии ключей автоматически находятся на новых виртуальных машинах HSM. Дополнительные сведения о миграции на новый ключ см. в статье "Как перенести ключевые рабочие нагрузки".

Дополнительные сведения об IntDate и других типах данных в руководстве о [ключах, секретах и сертификатах: Типы данных

Операции, зависящие от даты и времени

Недействительная и истекшая срок действия ключей вне окна nbf / exp будет работать для расшифровки, выпуска, отмены и проверки операций (не возвращается 403, запрещено). Основной причиной использования ключа в состоянии "еще не проверено" является возможность проверить ключ перед использованием в рабочей среде. Основная причина использования ключа в состоянии "истекший срок действия" — возможность выполнения операций восстановления в данных, которые были созданы, когда ключ был допустим. Кроме того, можно отключить доступ к ключу с помощью политик Key Vault или изменения значения атрибута ключа enabled на false.

Дополнительные сведения о типах данных см. в этом разделе.

Дополнительные сведения о других возможных атрибутах см. в разделе о веб-ключе JSON (JWK).

Теги ключей

Можно указать дополнительные метаданные, относящиеся к приложению, в виде тегов. Key Vault поддерживает до 15 тегов, каждый из которых может иметь имя и значение длиной 256 знаков.

Примечание.

Теги могут быть прочитаны вызывающим объектом, если у него есть права list или get на соответствующий ключ.

Контроль доступа к ключам

Контроль доступа к ключам, управляемым Key Vault, предоставляется на уровне хранилища ключей, которое выступает в роли контейнера ключей. Вы можете управлять доступом к ключам с помощью управления доступом на основе ролей Key Vault (рекомендуется) или старой модели разрешений политики доступа к хранилищу. Модель разрешений на основе ролей имеет три предопределенные роли для управления ключами: "Сотрудник по шифрованию Key Vault", "Пользователь шифрования key Vault", "Пользователь шифрования службы Key Vault" и может быть область для подписки, группы ресурсов или уровня хранилища.

Разрешения модели разрешений политики доступа хранилища:

  • Разрешения для операций управления ключами

    • get. Чтение открытой части ключа и его атрибутов.
    • list. Вывод списка ключей или версий ключа, хранимых в хранилище ключей.
    • update. Обновление атрибутов ключей.
    • create. Создание ключей.
    • import. Импорт ключа в хранилище ключей.
    • delete. Удаление объектов ключей.
    • recover. Восстановление удаленного ключа.
    • backup. Архивация ключа в хранилище ключей.
    • restore. Восстановление заархивированного ключа в хранилище ключей.

  • Разрешения для криптографических операций

    • decrypt. Использование ключа для снятия защиты с последовательности байтов.
    • encrypt. Использование ключа для защиты произвольной последовательности байтов.
    • unwrapKey. Использование ключа для снятия защиты с упакованных симметричных ключей.
    • wrapKey. Использование ключа для защиты симметричного ключа.
    • verify. Использование ключа для проверки хэш-кодов.
    • sign. Использование ключа для подписи хэш-кодов.

  • Разрешения для привилегированных операций

    • purge. Очистка (удаление без возможности восстановления) удаленных ключей.
    • выпуск: выпуск ключа в конфиденциальной вычислительной среде, которая соответствует release_policy ключа

  • Разрешения для операций политики смены

    • смена: меняет существующий ключ путем создания новой версии ключа (только для Key Vault).
    • получение политики смены: конфигурация получения политики смены
    • установка политики смены: конфигурация установки политики смены

Дополнительные сведения о работе с ключами см. в статье Azure Key Vault REST API reference (Справочник по REST API для Azure Key Vault).

Следующие шаги