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

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-256_K — кривая SEC SECP256K1, определенная в стандарте SEC 2: Recommended Elliptic Curve Domain Parameters (Рекомендуемые параметры домена для эллиптических кривых).
  • 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 можно создать асимметричные ключи.
  • Import: Позволяет клиентам импортировать имеющиеся ключи в Key Vault. В Key Vault можно импортировать асимметричные ключи с помощью нескольких различных способов упаковки внутри конструкции JWK.
  • Обновление. Позволяет клиентам с достаточными разрешениями изменять метаданные (атрибуты ключей), связанные с ключами, сохраненными ранее в 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 локально.
  • Шифрование и расшифровка. Ключ, хранимый в 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. Указывает, является ли ключ активным и подходит ли для операций шифрования. Атрибут enabled используется в сочетании с nbf и exp. При возникновении операции между nbf и exp она будет разрешена, только если для enabled установлено значение true. Операции вне окна nbf / exp автоматически запрещаются, за исключением определенных типов операции в разделе определенных условий.
  • nbf. Необязательный атрибут со значением в формате IntDate, значение по умолчанию — now. Атрибут nbf (не ранее) определяет время, до которого ключ не должен использоваться для криптографических операций, за исключением определенных типов операций в разделе определенных условий. Обработка атрибута nbf требует, чтобы текущая дата и время наступали позже или соответствовали дате и времени, перечисленным в атрибуте nbf. Key Vault может предоставить кратковременную отсрочку, обычно не более чем несколько минут, чтобы учесть разницу в показаниях часов. Нужно указать число, содержащее значение IntDate.
  • exp. Необязательный атрибут со значением в формате IntDate, значение по умолчанию — forever. Атрибут exp (время окончания срока действия) определяет время, до которого или после которого ключ не должен использоваться для криптографических операций, за исключением определенных типов операций в разделе определенных условий. Обработка атрибута exp требует, чтобы текущая дата и время наступали раньше или соответствовали дате и времени, перечисленным в атрибуте exp. Key Vault может предоставить кратковременную отсрочку, обычно не более чем несколько минут, чтобы учесть разницу в показаниях часов. Нужно указать число, содержащее значение IntDate.

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

  • Создано. Необязательное значение в формате IntDate. Атрибут created указывает, когда была создана эта версия ключа. Это значение равно NULL для ключей, созданных перед добавлением данного атрибута. Нужно указать число, содержащее значение IntDate.
  • Обновлено. Необязательное значение в формате IntDate. Атрибут updated указывает, когда была обновлена эта версия ключа. Это значение равно NULL для ключей, которые в последний раз обновлялись перед добавлением данного атрибута. Нужно указать число, содержащее значение IntDate.

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

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

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

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

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

Теги ключей

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

Примечание

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

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

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

Следующие разрешения могут быть предоставлены на каждого пользователя или субъект-службу в записи управления доступом к ключам в хранилище. Эти разрешения точно отражают операции, разрешенные для объекта ключа. Предоставление доступа к субъекту-службе в хранилище ключей является разовой операцией и остается одинаковой для всех подписок Azure. Ее можно использовать для развертывания требуемого количества сертификатов.

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

    • 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). Сведения об установке разрешений см. в статьях Vaults — Create Or Update (Хранилища. Создание или обновление) и Vaults — Update Access Policy (Хранилища. Обновление политики доступа).

Дальнейшие действия