Ключевые типы, алгоритмы и операции (управляемый HSM)

Управляемый HSM поддерживает ключи RSA, Elliptic Curve и симметричные (AES). Все ключи защищены HSM. Общие сведения см. в статье О ключах в управляемом HSM.

В следующей таблице приведены поддерживаемые типы ключей и алгоритмы в управляемом 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

Следующие идентификаторы алгоритма поддерживаются с помощью ключей RSA-HSM.

Ключи обертывания/разобертывания (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.

Алгоритмы симметричного ключа (AES)

Следующие идентификаторы алгоритма поддерживаются с ключами oct-HSM.

Ключи обертывания/разобертывания (WRAPKEY/UNWRAPKEY), шифрование/дешифрование (ENCRYPT/DECRYPT)

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

При использовании с 256-разрядными ключами эти алгоритмы считаются квантово-устойчивыми согласно Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ.

ПОДПИСАТЬ/ПРОВЕРИТЬ (HMAC)

• HS256 — HMAC с помощью SHA-256, как описано в RFC7518.
• HS384 — HMAC с помощью SHA-384, как описано в RFC7518.
• HS512 — HMAC с помощью SHA-512, как описано в RFC7518.

Значения пропускной способности для каждого размера ключа AES и типа операции см. в руководстве по масштабированию управляемого HSM. Чтобы задать минимальный размер ключа AES с помощью Политика Azure, см. Политика Azure для Управляемого HSM.

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

Следующие операции поддерживаются в ключевых объектах:

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

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

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

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

Служба не поддерживает операции EXPORT. После того как ключ подготовлен, вы не сможете извлечь его или изменить его ключевой материал. Чтобы переместить ключ, используйте операции BACKUP и RESTORE для экспорта или импорта ключа в защищенной форме. Ключи, созданные backup, нельзя использовать вне службы.

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

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

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

Вращать

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

Ключевые атрибуты

Помимо материала ключа, можно указать следующие атрибуты. В запросе JSON необходимо включить attributes ключевое слово и фигурные скобки ({}), даже если атрибуты не указаны.

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

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

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

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

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

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

Ключи привязаны к управляемому экземпляру HSM, в рамках которого они были созданы. Невозможно перенести или передать ключ между экземплярами; Сведения о переносе рабочей нагрузки на новый ключ см. в статье "Как перенести ключевые рабочие нагрузки". Дополнительные сведения о IntDate и других типах данных см. в разделе "Типы данных".

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

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

Управление доступом

Managed HSM использует локальную модель управления доступом на основе ролей (RBAC) на уровне плоскости данных, отдельную от Azure RBAC на уровне плоскости управления. Встроенные роли, такие как управляемый пользователь шифрования HSM и управляемый специалист по шифрованию HSM , управляют ключевыми операциями и могут быть назначены в области HSM или на уровне ключа; более широкие административные роли, такие как управляемый администратор HSM , управляют доменом безопасности, резервным копированием и восстановлением и управлением ролями, а не ключевыми операциями. Дополнительные сведения см. в статьях Встроенные роли локальной модели RBAC для управляемого HSM и Управление доступом к управляемому HSM.

Связанный контент

• Сведения о ключах в управляемом HSM
• Управление ключами в управляемом HSM
• Импорт защищенных модулем HSM ключей в Управляемый модуль HSM (BYOK)
• Проверка ключей с помощью аттестации ключей
• Рекомендации по масштабированию управляемого HSM
• Политика Azure для управляемого HSM
• Контроль доступа к Managed HSM