[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Key import\n\nThis topic covers conceptual information about importing keys into\nCloud Key Management Service as new key versions. For step-by-step instructions, see\n[importing a key version](/kms/docs/importing-a-key).\n\nIntroduction\n------------\n\nYou may be using existing cryptographic keys that were created on your premises\nor in an external key management system. If you migrate an application to\nGoogle Cloud or if you add cryptographic support to an existing\nGoogle Cloud application, you can import the relevant keys into\nCloud KMS.\n\n- You can import into Cloud HSM keys or software keys in Cloud KMS.\n- Key material is wrapped for protection in transit. You can use the Google Cloud CLI to automatically wrap the key, or you can [wrap the key manually](/kms/docs/wrapping-a-key).\n- Google Cloud has access to the wrapping key only within the scope of the import job. For Cloud HSM keys, the wrapping key never resides outside of Cloud HSM.\n\nThis topic provides details about limitations and requirements for\nimporting keys, and gives an overview of\n[how key import works](#key_import_flow).\n\nLimitations and requirements\n----------------------------\n\nReview these sections to verify that your keys can be imported into\nCloud KMS.\n\n### Supported key formats\n\n- **Symmetric keys for encryption** : Imported symmetric keys must be 16 bytes (for [raw symmetric encryption](/kms/docs/raw-encryption) only) or 32 bytes of binary data, and must *not* be encoded. If your key is hex-encoded or base64-encoded, then you must decode it before attempting to import it.\n- **Symmetric keys for signing (MAC keys)** : Imported HMAC signing keys must have a length equal to the output length of the cryptographic hash function being used (for example, HMAC-SHA256 keys must have a length of 32 bytes), and must *not* be encoded. If your key is hex-encoded or base64-encoded, then you must decode it before attempting to import it.\n- **Asymmetric keys for encryption or signing** : Imported asymmetric keys must be in PKCS #8 format and must be DER-encoded. PCKS #8 format is defined in [RFC 5208](https://tools.ietf.org/html/rfc5208). DER encoding is defined in [International\n Telecommunications Union X.680](https://www.itu.int/rec/T-REC-X.680/en). Asymmetric keys must use one of the [length and algorithm combinations](/kms/docs/algorithms) supported by Cloud KMS.\n\n| **Important:** An RSA key's public exponent must be 65,537 or higher. This is a Digital Signature Standard (DSS) requirement noted in the Criteria for IFC Key Pairs section of [FIPS PUB 186-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf), Section B.3.1\n\nSome aspects of a key, such as the key's length, cannot be changed after the key\nis created. In these cases, the key cannot be imported into Cloud KMS.\n\nTo verify and reformat your key for import, see\n[Formatting keys for import](/kms/docs/formatting-keys-for-import).\n\n### Supported protection levels\n\nYou can import a key into either a Cloud KMS key or a Cloud HSM key, by setting the key's [protection level](/kms/docs/algorithms#protection_levels) to either `SOFTWARE` or `HSM`. Cloud HSM keys incur additional [costs](/kms/pricing). You can't import into a Cloud External Key Manager key.\n\n\u003cbr /\u003e\n\n### Supported wrapping key sizes\n\nWhen you create an import job, you can control the size of the wrapping key used\nto protect your key in transit to Google Cloud by setting the import job's\n*import method*. The default size for the wrapping key is 3072. If you have\nspecific requirements, you can configure the import job to use a 4096-bit key\ninstead.\n\nYou can learn more about the algorithms used for\n[key wrapping](/kms/docs/key-wrapping) or about\n[configuring an import job](/kms/docs/importing-a-key#create_importjob).\n\nHow key import works\n--------------------\n\nThis section illustrates what happens when you import a key. Some parts of the\nflow are different if you use automatic wrapping or manually wrap the key. Using\nautomatic wrapping is recommended. For specific instructions, see\n[Import a key version](/kms/docs/importing-a-key). For specific instructions\nabout manually wrapping your key before import, see\n[Wrapping a key using OpenSSL on Linux](/kms/docs/wrapping-a-key).\n\nThe following diagram illustrates the key import process using automatic key\nwrapping. The phases shown in the diagram are described in this section.\n\n1. Get ready to import keys.\n\n 1. First, you [create a target key ring and\n key](/kms/docs/importing-a-key#create_targets) that will eventually\n contain the import job and the imported key material. At this point, the\n target key contains no key versions.\n\n 2. Next, you\n [create an import job](/kms/docs/importing-a-key#create_importjob). The\n import job defines the target key ring and key for the imported key\n material. The import job also defines the import method, which is the\n algorithm used to create the wrapping key that protects the key material\n during import requests.\n\n - The public key is used to wrap the key to be imported on the client.\n - The private key is stored within Google Cloud and is used to unwrap the key after it reaches the Google Cloud project.\n\n This separation prevents Google from being able to unwrap your key\n material outside of the scope of the import job.\n 3. The key must be cryptographically wrapped before transmitting it to\n Google. Most users can use the gcloud CLI to automatically\n wrap, transmit, and import the key, as described in the next step. If\n you have compliance or regulatory requirements to\n [wrap the key manually](/kms/docs/wrapping-a-key), you can do it at this\n time. To wrap the key manually on the local system:\n\n 1. Configure OpenSSL.\n 2. Once per import job, download the wrapping key associated with the import job.\n 3. Once per key, set several environment variables and wrap the key.\n2. For up to three days, until the import job expires, you can use it to\n [make import requests](/kms/docs/importing-a-key#request_import) to import\n one or more keys. During an import request:\n\n 1. If the key was not manually wrapped, the Google Cloud CLI downloads the import job's public key from Google Cloud to the local system, then uses the public key, along with a private key associated with the client, to wrap the local key material.\n 2. The wrapped key material is transmitted to the Google Cloud project.\n 3. The key material is unwrapped using the import job's private key and is inserted as a new version of the target key on the target key ring. This is an atomic operation.\n 4. For symmetric keys, you set the imported key version to be the primary key version.\n\n | **Note:** The imported key version is not automatically set to be the primary key version.\n\nAfter the import request completes successfully, you can use the imported key\nversion to protect data in Google Cloud.\n\nWhat's next\n-----------\n\n- [Import a key version](/kms/docs/importing-a-key)\n- [Encrypt and decrypt data using a symmetric key](/kms/docs/encrypt-decrypt)\n- [Encrypt and decrypt data using an asymmetric\n key](/kms/docs/encrypt-decrypt-rsa)\n- Learn about [Creating and validating digital\n signatures](/kms/docs/create-validate-signatures)"]]
