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

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

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

Алгоритмы EC

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

Типы кривых

• P-256 — кривая NIST P-256, определенная в DSS FIPS PUB 186-4.
• P-256K — кривая SEC SECP256K1, определенная в 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)

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

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 — см. RFC2437 специализированный вариант использования для включения определенных сценариев TLS.

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

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

Эти алгоритмы при использовании с 256-разрядными ключами являются устойчивыми к квантовым атакам в соответствии с набором алгоритмов коммерческой национальной безопасности 2.0 и FAQ по квантовым вычислениям.

Ключевые операции

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

• Создание: позволяет клиенту создавать ключ в Key Vault. Значение ключа создается в Key Vault и хранится в нем. Оно не выдается клиенту. В Key Vault можно создать асимметричные ключи.
• Импорт. Позволяет клиенту импортировать существующий ключ в Key Vault. Асимметричные ключи можно импортировать в Key Vault с помощью нескольких различных методов упаковки в конструкции JWK.
• Обновление. Позволяет клиенту с достаточными разрешениями изменять метаданные (ключевые атрибуты), связанные с ключом, ранее хранящимся в Key Vault.
• Удаление. Позволяет клиенту с достаточными разрешениями удалить ключ из Key Vault.
• Список. Позволяет клиенту перечислять все ключи в определенном Хранилище ключей.
• Список версий: позволяет клиенту перечислять все версии заданного ключа в определенном Key Vault.
• Get: позволяет клиенту получать общедоступные части заданного ключа в 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 ключевое слово атрибутов и кавычки "{' '}" необходимы, даже если атрибуты не указаны.

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

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

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

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

Дополнительные сведения о IntDate и других типах данных см. в разделе "Сведения о ключах, секретах и сертификатах: типы данных".

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

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

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

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

Ключевые теги

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

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

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

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

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

  • get: чтение открытой части ключа, а также его атрибутов
  • список ключей или версий ключа, хранящихся в хранилище ключей.
  • обновление. Обновление атрибутов ключа
  • create: Создание новых ключей
  • импорт: импорт ключа в хранилище ключей
  • удалить: удалить ключевой объект
  • восстановление: восстановление удаленного ключа
  • резервное копирование: резервное копирование ключа в хранилище ключей
  • восстановление. Восстановление резервного копирования ключа в хранилище ключей

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

  • расшифровка: используйте ключ для отмены защиты последовательности байтов
  • шифрование: используйте ключ для защиты произвольной последовательности байтов
  • unwrapKey: используйте ключ для распаковки защищенных симметричных ключей
  • wrapKey: используйте ключ для защиты симметричного ключа
  • проверить: Используйте ключ для проверки дайджестов
  • знак: используйте ключ для подписывания дайджестов

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

  • Очистка: очистка (окончательное удаление) удаленного ключа
  • выпуск: освобождение ключа в защищенной вычислительной среде, которая соответствует release_policy ключа

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

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

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

Дальнейшие шаги

• Сведения о Key Vault
• Сведения о службе "Управляемое устройство HSM"
• О секретах
• Сведения о сертификатах
• Обзор REST API Key Vault
• Аутентификация, запросы и ответы
• Руководство разработчика Azure Key Vault