message GetMechanismListRequest {
    }
    message GetMechanismListResponse {
      repeated uint64 Mechs = 2;
    }
    

    CK_RV m_GetMechanismList (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE_PTR mechs, CK_ULONG_PTR mechslen,
      target_t 대상
    );
    

C_GetMechanismList는 토큰으로 지원되는 메커니즘 유형의 목록을 가져오는 데 사용됩니다. SlotID는 토큰의 슬롯 ID이고, pulCount는 메커니즘 수를 수신하는 위치를 가리킵니다.

애플리케이션이 C_GetMechanismList를 호출하는 두 가지 방법은 다음과 같습니다.

1. pMechanismList가 NULL_PTR이면 C_GetMechanismList에서 수행하는 모든 항목은 메커니즘의 목록을 리턴하지 않고 메커니즘 수를 리턴합니다(*pulCount에서). 이 경우 C_GetMechanismList에 대한 항목의 *pulCount 컨텐츠는 의미가 없으며, 호출은 CKR_OK 값을 리턴합니다.
2. pMechanismList가 NULL_PTR이 아닌 경우 *pulCount에 pMechanismList가 지시하는 버퍼 크기(CK_MECHANISM_TYPE 요소 측면에서)가 포함되어 있어야 합니다. 해당 버퍼가 메커니즘의 목록을 보유할 정도로 대형 버퍼이면 목록이 리턴되고 CKR_OK가 리턴됩니다. 그렇지 않으면 C_GetMechanismList에 대한 호출은 CKR_BUFFER_TOO_SMALL 값을 리턴합니다. 두 경우 모두 *pulCount 값은 메커니즘의 수를 유지하도록 설정됩니다.

C_GetMechanismList의 경우 자체 공간을 할당하지 않기 때문에 애플리케이션에서 C_GetMechanismList를 두 번 호출하는 경우도 있습니다. 그러나 이 동작은 절대 필수가 아닙니다.

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismList)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE_PTR pMechanismList,
      CK_ULONG_PTR pulCount
    );
    

    message GetMechanismInfoRequest {
      uint64 Mech = 2;
    }
    message GetMechanismInfoResponse {
      MechanismInfo MechInfo = 3;
    }
    

    CK_RV m_GetMechanismInfo (
      CK_SLOT_ID slot,
      CK_MECHANISM_TYPE mech,
      CK_MECHANISM_INFO_PTR mechInfo,
      target_t 대상
    );
    

C_GetMechanismInfo에는 토큰에서 지원되는 특정 메커니즘에 대한 정보가 포함되어 있습니다. slotID는 토큰 슬롯의 ID이고, type은 메커니즘의 유형이며, pInfo는 메커니즘 정보를 수신하는 위치를 지시합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_GetMechanismInfo)(
      CK_SLOT_ID slotID,
      CK_MECHANISM_TYPE type,
      CK_MECHANISM_INFO_PTR pInfo
    );
    

    message GenerateKeyRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> Template = 6;
    }
    message GenerateKeyResponse {
      bytes KeyBytes = 4;
      bytes CheckSum = 5;
    }
    

PKCS #11 C_GenerateKey의 구현입니다.

TDES 키는 호스트에서 관찰할 수 없는 적절한 패리티로 생성됩니다. 하지만 적절한 상호 운용성을 위해서는 다른 PKCS #11 구현에서 패리티 문제점이 존재하는 DES키를 거부해야 합니다.

오브젝트가 세션에 연결되어 있는 경우 해당 세션에 대한 로그인에서 (pin, plen)이 리턴되어야 합니다. pin NULL을 그대로 두면 로그인 세션에 바인드되지 않은 공용 오브젝트가 작성됩니다.

(key, klen)에서는 키 2진 대형 오브젝트를 리턴합니다. (csum, clen)에는 키의 체크섬(즉, 해당 키로 암호화된 모든 영(0) 블록의 가장 중요한 바이트)이 포함되어 있습니다. 예를 들어, NULL clen은 CKA_CHECK_VALUE 매개변수(예: RC4)가 없는 대칭-키 메커니즘에 가능합니다.

ptempl은 키 길이(즉, CKA_VALUE_LEN 속성)가 메커니즘에 필요한 경우에만 사용됩니다. 메커니즘이 내재적으로 키 크기를 지정하면 ptempl은 크기에 대해 확인되지 않습니다.

DSA 및 DH 매개변수 생성은 (csum, clen)을 무시하며, 매개변수 구조만 생성합니다.

DSA, DH 매개변수(CKM_DSA_PARAMETER_GEN): 속성의 CKA_PRIME_BITS에 있는 모듈 비트 수를 전달합니다. 일반 텍스트 출력으로 P,Q,G 구조를 씁니다(즉, blob가 아님).

pin blob는 Login의 출력입니다.

PKCS #11 phKey는 EP11 매개변수로 맵핑되지 않습니다. (호스트 라이브러리는 랩핑된 키를 핸들에 바인드해야 합니다.)

    CK_RV m_GenerateKey (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
      const unsigned char *pin, size_t pinlen,
      unsigned char * 키, size_t * keylen,
      unsigned char *checkSum, size_t *checkSumlen,
      target_t 대상
      );
    

C_GenerateKey는 새 오브젝트 작성 시 비밀 키 또는 도메인 매개변수 세트를 생성합니다. hSession은 세션의 핸들이고, pMechanism은 생성 메커니즘을 지시하고, pTemplate는 새 키 또는 도메인 매개변수 세트에 대한 템플리트를 지시하고, ulCount는 템플리트의 속성 수이며, phKey는 새 키 또는 도메인 매개변수 세트의 핸들을 수신하는 위치를 지시합니다.

생성 메커니즘이 도메인 매개변수 생성을 위한 것인 경우 CKA_CLASS 속성의 값이 CKO_DOMAIN_PARAMETERS이고, 그렇지 않을 경우 해당 값이 CKO_SECRET_KEY입니다.

생성될 키 또는 도메인 매개변수 유형이 생성 메커니즘에 내제되어 있으므로 템플리트는 키 유형을 제공할 필요가 없습니다. 생성 메커니즘과 일치하지 않는 키 유형을 제공하는 경우 C_GenerateKey가 실패하고 CKR_TEMPLATE_INCONSISTENT오류 코드가 리턴됩니다. CKA_CLASS 속성은 동일한 방식으로 처리됩니다.

C_GenerateKey에 대한 호출에서 제공된 템플리트를 정확하게 지원할 수 없는 경우 오브젝트가 작성되지 않은 상태로 실패하고 리턴합니다.

C_GenerateKey에 대한 호출이 성공하면서 작성된 오브젝트의 경우 CKA_LOCAL 속성이 CK_TRUE로 설정됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKey)(
      CK_SESSION_HANDLE hSession
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pTemplate,
      CK_ULONG ulCount,
      CK_OBJECT_HANDLE_PTR phKey
      );
    

    message GenerateKeyPairRequest {
      Mechanism Mech = 1;
      map<uint64,AttributeValue> PrivKeyTemplate = 7;
      map<uint64,AttributeValue> PubKeyTemplate = 8;
      }
    message GenerateKeyPairResponse {
      bytes PrivKeyBytes = 5;
      bytes PubKeyBytes = 6;
    }
    

PKCS #11 C_GenerateKeyPair의 구현입니다

키 쌍 매개변수는 pmech, ppublic 및 pprivate 매개변수에서 수신됩니다. RSA 키의 경우 ppublic은 모듈러스 크기를 지정합니다.

FIPS 모드에서는 1024+256 n비트의 RSA 모듈만 지원됩니다(정수 n). 비FIPS 모드는 메커니즘 매개변수 목록의 한계 사이에서 짝수로 된 비트 키를 생성할 수 있습니다.

공개 키는 대부분의 라이브러리가 읽어들일 수 있는 표준 SPKI(주제 공개 키 정보)로 형식화됩니다. 이는 SPKI 자체의 일부가 아닌 전송 키 특정 MAC으로 보호되는 무결성입니다. DSA 매개변수 생성은 공용 키 필드에서 비SPKI 구조를 리턴합니다.

오브젝트를 세션에 연결하는 경우 해당 세션에 대한 로그인에서 (pin, plen)이 리턴되어야 합니다. pin NULL을 그대로 두는 경우 로그인 세션 간에 그대로 유지되는 공용 오브젝트가 작성됩니다.

랩핑된 개인 키를 (pubkey, pklen)에서 MAC화된 ASN.1/DER 구조로서 (key, klen)인 공개 키로 리턴합니다.

PKCS #11에서 설명한 것 이외에도 다음과 같이 특수 참고사항이 포함된 지원되는 매개변수 조합이 존재합니다.

RSA 키는 17(0x11) 미만의 공개 지수를 거부합니다. 제어점은 허용된 최소값을 추가로 제한할 수 있습니다. Fermat4 지수인 0x10001은 FIPS 186-3의 공개 지수 제한사항(B.3.1 절)과 일치하는 특정 제어점으로 제어됩니다.

EC 키(CKM_EC_KEY_PAIR_GEN): 곡선 매개변수는 OID 또는 기호 이름(namedCurve 변수)로 지정될 수 있습니다. 지원되는 기호 이름은 NIST 커브의 경우 "P-nnn"(nnn은 지원되는 프라임 비트 수이며 192-521임)이며 일반 BP 곡선의 경우 "BP-nnnR"입니다. (이름은 0으로 종료되지 않는 ASCII 문자열로 제공되어야 합니다.)

DSA 키(CKM_DSA_KEY_PAIR_GEN): 공용 속성 중 CKA_IBM_STRUCT_PARAMS 속성으로 P,Q,G 구조를 전달합니다. 개별 P, Q, G 매개변수는 일반 PKCS #11 매개변수를 통해 전달되지 않을 수 있으며 단일 구조로 결합되어야 합니다.

DH 키(CKM_DH_PKCS_KEY_PAIR_GEN): 공용 속성 중 CKA_IBM_STRUCT_PARAMS 속성으로 P,Q,G 구조를 전달합니다. 개별 P, G 매개변수는 일반 PKCS #11 매개변수를 통해 전달되지 않을 수 있으며 단일 구조로 결합되어야 합니다. 개인 키(X) 비트 수를 선택하는 경우 XCP_U32_VALUE_BITS 속성을 사용하십시오. 존재하지 않거나 명시적인 0이 제공되면 비트 수는 P 비트 수를 기반으로 선택됩니다.

세션(로그인) 상태를 사용하는 경우 세션의 표준 사용이 대체됩니다. 맵핑이 라이브러리 범위를 벗어났습니다.

pin blob는 Login의 출력입니다.

PKCS #11 hSession은 EP11 매개변수로 맵핑되지 않습니다. (호출은 세션과 직접 연관되지 않습니다.)

PKCS #11 phPublicKey는 EP11 매개변수로 맵핑되지 않습니다. (호스트 라이브러리는 공개 키(SPKI)를 핸들과 연관시켜야 합니다.)

PKCS #11 phPrivateKey는 EP11 매개변수로 맵핑되지 않습니다. (호스트 라이브러리는 개인 키를 핸들과 연관시켜야 합니다.)

    CK_RV m_GenerateKeyPair (
      CK_MECHANISM_PTR mech,
      CK_ATTRIBUTE_PTR pubKeyTemplate, CK_ULONG pubKeyTemplatelen,
      CK_ATTRIBUTE_PTR privKeyTemplate, CK_ULONG privKeyTemplatelen,
      const unsigned char *pin, size_t pinlen,
      unsigned char *privKey, size_t *privKeylen,
      unsigned char *pubKey, size_t *pubKeylen,
      target_t 대상
      );
    

C_GenerateKeyPair는 새 키 오브젝트 작성 시 공개 키 및 개인 키 쌍을 생성합니다. hSession은 세션의 핸들이고, pMechanism은 키 생성 메커니즘을 지시하고, pPublicKeyTemplate는 공개 키의 템플리트를 지시하고, ulPublicKeyAttributeCount는 공개 키 템플리트의 속성 수이고, pPrivateKeyTemplate는 개인 키의 템플리트를 지시하고, ulPrivateKeyAttributeCount는 개인 키 템플리트의 속성 수이고, phPublicKey는 새 공개 키의 핸들을 수신하는 위치를 지시하며, phPrivateKey는 새 개인 키의 핸들을 수신하는 위치를 지시합니다.

생성될 키 유형이 키 쌍 생성 메커니즘에 내제되어 있으므로 템플리트는 키 유형을 제공할 필요가 없습니다. 템플리트 중 하나에서 키 생성 메커니즘과 일치하지 않는 키 유형을 제공하는 경우 C_GenerateKeyPair는 실패하고 CKR_TEMPLATE_INCONSISTENT 오류 코드가 리턴됩니다. CKA_CLASS 속성은 유사하게 처리됩니다.

C_GenerateKeyPair에 대한 호출에서 제공된 정확한 템플리트가 지원되지 않을 경우 키 오브젝트가 작성되지 않은 상태로 해당 호출이 실패하고 리턴됩니다.

C_GenerateKeyPair에 대한 호출에서 하나의 키만 작성하고 리턴하는 경우는 없습니다. 호출이 실패하고 키를 작성하지 않거나, 호출이 성공하고 일치하는 공용 및 개인 키 쌍을 작성할 수 있습니다.

C_GenerateKeyPair에 대한 정상적인 호출을 통해 작성된 키 오브젝트의 경우 CKA_LOCAL 속성이 CK_TRUE로 설정되어 있습니다.

C_GenerateKeyPair에 대한 인수의 순서에 유의하십시오. 마지막 두 인수의 순서는 원래 Cryptoki 버전 1.0 문서의 순서와 동일하지 않습니다. 이 두 가지 인수의 순서에서 약간의 불행한 혼란이 야기되었습니다.

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateKeyPair)(
      CK_SESSION_HANDLE hSession,
      CK_MECHANISM_PTR pMechanism,
      CK_ATTRIBUTE_PTR pPublicKeyTemplate,
      CK_ULONG ulPublicKeyAttributeCount,
      CK_ATTRIBUTE_PTR pPrivateKeyTemplate,
      CK_ULONG ulPrivateKeyAttributeCount,
      CK_OBJECT_HANDLE_PTR phPublicKey,
      CK_OBJECT_HANDLE_PTR phPrivateKey
      );
    

    message DeriveKeyRequest {
        Mechanism Mech = 1;
        bytes BaseKey = 3;
        bytes Data = 4;
        map<uint64,AttributeValue> Template = 8;
    }
    message DeriveKeyResponse {
        bytes NewKeyBytes = 6;
        bytes CheckSum = 7;
    }
    

PKCS #11 C_DeriveKey의 구현입니다.

basekey,bklen blob는 PKCS #11 hBaseKey 매개변수에서 맵핑되어야 합니다.

PKCS #11 hSession은 EP11 매개변수로 맵핑되지 않습니다. (호출은 세션과 직접 연관되지 않습니다.)

PKCS #11 phKey는 EP11 매개변수로 맵핑되지 않습니다. (호스트 라이브러리는 리턴된 키를 핸들에 바인드해야 합니다.)

    CK_RV m_DeriveKey (
        CK_MECHANISM_PTR mech,
        CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        const unsigned char *baseKey, size_t baseKeylen,
        const unsigned char *data, size_t datalen,
        const unsigned char *pin, size_t pinlen,
        unsigned char *newKey, size_t *newKeylen,
        unsigned char *checkSum, size_t *checkSumlen,
        target_t 대상
    );
    

C_DeriveKey는 새 키 오브젝트 작성 시 기본 키에서 키를 파생시킵니다. hSession은 세션의 핸들이고, pMechanism은 키 파생 메커니즘을 지정하는 구조를 지시하고, hBaseKey는 기본 키의 핸들이고, pTemplate는 새 키의 템플리트를 지시하고, ulAttributeCount는 템플리트의 속성 수이며, phKey는 파생된 키의 핸들을 수신하는 위치를 지시합니다.

기본 키에 대한 CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE 및 KA_NEVER_EXTRACTABLE 속성의 값은 이러한 속성이 새로 파생된 키에 대해 보유할 수 있는 값에 영향을 미칩니다. 이 유형의 제한조건에 대해서는 PKCS #11 API 스펙의 5.16.2 절에 있는 각각의 특정 키 파생 메커니즘에 대한 설명을 참조하십시오.

C_DeriveKey에 대한 호출에서 제공된 정확한 템플리트가 지원되지 않을 경우 키 오브젝트가 작성되지 않은 상태로 해당 호출이 실패하고 리턴됩니다.

C_DeriveKey에 대한 성공적인 호출로 작성된 키 오브젝트의 경우 CKA_LOCAL 속성이 CK_FALSE로 설정되어 있습니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DeriveKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hBaseKey,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message WrapKeyRequest {
        bytes Key = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 4;
    }
    message WrapKeyResponse {
        bytes Wrapped = 5;
    }
    

    CK_RV m_WrapKey (
        const unsigned char *key, size_t keylen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const CK_MECHANISM_PTR mech,
        CK_BYTE_PTR wrapped, CK_ULONG_PTR wrappedlen,
        target_t 대상
    );
    

C_WrapKey는 개인 또는 시크릿 키를 랩핑(즉, 암호화)합니다. hSession은 세션의 핸들이고, pMechanism은 랩핑 메커니즘을 지시하고, hWrappingKey는 랩핑 키의 핸들이고, hKey는 랩핑할 키의 핸들이고, pWrappedKey는 랩핑된 키를 수신하는 위치를 지시하며, pulWrappedKeyLen은 랩핑된 키의 길이를 수신하는 위치를 지시합니다.

C_WrapKey는 출력 생성 시 PKCS #11 API 스펙의 5.2절에서 설명하는 규칙을 사용합니다.

키가 랩핑을 지원하는지를 표시하는 랩핑 키의 CKA_WRAP 속성은 CK_TRUE여야 합니다. 랩핑될 키의 CKA_EXTRACTABLE 속성도 CK_TRUE여야 합니다.

랩핑될 키가 몇 가지 토큰의 특정한 이유로 인해 랩핑될 수 없으면 CKA_EXTRACTABLE 속성이 CK_TRUE로 설정된 경우에도 C_WrapKey가 CKR_KEY_NOT_WRAPPABLE 오류 코드와 함께 실패합니다. 길이로 인해 지정된 랩핑 키와 메커니즘만으로 랩핑될 수 없으면 C_WrapKey는 CKR_KEY_SIZE_RANGE 오류 코드와 함께 실패합니다.

C_WrapKey는 다음 상황에서 사용될 수 있습니다.

• 비밀 키를 암호화 및 복호화를 지원하는 공개 키로 랩핑합니다.
• 비밀 키를 기타 비밀 키로 랩핑합니다. 키 크기 및 메커니즘 강도에 대한 고려사항이 제공되어야 합니다. 그렇지 않으면 토큰이 오퍼레이션을 허용하지 않을 수 있습니다.
• 개인 키를 비밀 키로 랩핑합니다.

토큰은 키 유형이 어떠한 메커니즘으로 랩핑될 수 있는지에 따라 달라집니다.

추출 가능한 키의 서브세트만 랩핑할 수 있도록 랩핑 키를 파티션하기 위해 랩핑 키에 CKA_WRAP_TEMPLATE 속성을 사용하여 랩핑할 키의 속성과 비교할 수 있는 속성 세트를 지정할 수 있습니다. 속성 일치의 C_FindObject 규칙에 따라 모든 속성이 일치하는 경우 랩핑 조작이 진행됩니다. 이 속성의 값은 속성 템플리트이고 크기는 CK_ATTRIBUTE 크기의 템플리트 배수로 된 항목 수의 규모에 해당합니다. 이 속성이 제공되지 않으면 템플리트는 허용되지 않습니다. 속성이 존재하지 않을 경우 확인하지 않습니다. 키를 랩핑하려고 시도하는 중에 속성 불일치가 발생하는 경우 해당 함수에서 CKR_KEY_HANDLE_INVALID가 리턴됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_WrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hWrappingKey,
        CK_OBJECT_HANDLE hKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG_PTR pulWrappedKeyLen
    );
    

    message UnwrapKeyRequest {
        bytes Wrapped = 1;
        bytes KeK = 2;
        bytes MacKey = 3;
        Mechanism Mech = 5;
        map<uint64,AttributeValue> Template = 9;
    }
    message UnwrapKeyResponse {
        bytes UnwrappedBytes = 7;
        bytes CheckSum = 8;
    }
    

PKCS #11 C_UnwrapKey의 구현입니다.

uwmech는 랩핑된 데이터를 복호화하기 위해 사용되는 암호화 메커니즘을 지정합니다. ptempl은 랩핑되지 않은 데이터를 새 키로 변환하는 방법을 지정하는 키(쌍) 매개변수 목록입니다( CKA_KEY_TYPE이 포함되어야 함).

생성된 오브젝트는 blob로서 (unwrapped, uwlen) 하에서 리턴됩니다. 대칭 키는 (csum, cslen) 하에서 키 체크섬(3바이트)을 리턴하고, 공개 키 오브젝트는 (csum, cslen)에서 SPKI로서 공개 키를 리턴합니다. 두 양식은 4바이트 빅엔디안 값 뒤에 표시되며, 랩핑 해제된 키의 비트 수를 인코딩합니다.

SPKI가 MACed SPKI로 변형되는 경우 CKM_IBM_TRANSPORTKEY를 랩핑되지 않은 메커니즘으로 사용해야 합니다. 이 모드는 랩핑 해제된 데이터로서 원시 SPKI를 제공하며 KEK를 무시합니다.

UnwrapKey는 패리티 조정 DES 키를 생성하지만(blob 내에서) 올바르지 않은 패리티가 포함된 입력이 허용됩니다.

    CK_RV m_UnwrapKey (
        const CK_BYTE_PTR wrapped, CK_ULONG wrappedlen,
        const unsigned char *keK, size_t keKlen,
        const unsigned char *macKey, size_t macKeylen,
        const unsigned char *pin, size_t pinlen,
        const CK_MECHANISM_PTR mech,
        const CK_ATTRIBUTE_PTR template, CK_ULONG templatelen,
        unsigned char * unwrapped, size_t * unwrappedlen,
        CK_BYTE_PTR checkSum, CK_ULONG *checkSumlen,
        target_t 대상
    );
    

C_UnwrapKey는 새 개인 키 또는 시크릿 키 오브젝트 작성 시 키를 랩핑 해제(즉, 복호화)합니다. hSession은 세션의 핸들이고, pMechanism은 랩핑 해제 메커니즘을 지시하고, hUnwrappingKey는 랩핑 해제 키의 핸들이고, pWrappedKey는 랩핑된 키를 지시하고, ulWrappedKeyLen은 랩핑된 키의 길이이고, pTemplate는 새 키의 템플리트를 지시하고, ulAttributeCount는 템플리트의 속성 수이며, phKey는 복구된 키의 핸들을 수신하는 위치를 지시합니다.

키가 랩핑 해제를 지원하는지를 표시하는 랩핑 해제 키의 CKA_UNWRAP 속성은 CK_TRUE여야 합니다.

새 키에서 CKA_ALWAYS_SENSITIVE 속성은 CK_FALSE로 설정되고 CKA_NEVER_EXTRACTABLE 속성은 CK_FALSE로 설정되어 있습니다. 기본적으로 CKA_EXTRACTABLE 속성은 CK_TRUE로 설정됩니다.

일부 메커니즘은 수정되거나 수정을 시도할 수 있습니다. 키가 랩핑 해제된 동시에 pMechanism 구조의 컨텐츠입니다.

C_UnwrapKey에 대한 호출에서 제공된 정확한 템플리트가 지원되지 않을 경우 키 오브젝트가 작성되지 않은 상태에서 해당 호출이 실패하고 리턴됩니다.

C_UnwrapKey에 대한 성공적인 호출로 작성된 키 오브젝트의 경우 CKA_LOCAL 속성이 CK_FALSE로 설정되어 있습니다.

키의 서브세트만 랩핑 해제할 수 있도록 랩핑 해제 키를 파티션하기 위해 랩핑 해제 키에 CKA_UNWRAP_TEMPLATE 속성을 사용하여 랩핑 해제할 키의 속성에 추가되는 속성 세트를 지정할 수 있습니다. 속성이 사용자 제공 속성 템플리트와 충돌하지 않을 경우 pTemplate에서 랩핑 해제 조작이 진행됩니다. 이 속성의 값은 속성 템플리트이고 크기는 CK_ATTRIBUTE 크기의 템플리트 배수로 된 항목 수의 규모에 해당합니다. 이 속성이 랩핑 해제 키에 없으면 추가 속성이 추가되지 않습니다. 키를 랩핑 해제하려고 시도할 때 속성 충돌이 발생하는 경우 SHALL 함수에서 CKR_TEMPLATE_INCONSISTENT가 리턴됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_UnwrapKey)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hUnwrappingKey,
        CK_BYTE_PTR pWrappedKey,
        CK_ULONG ulWrappedKeyLen,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulAttributeCount,
        CK_OBJECT_HANDLE_PTR phKey
    );
    

    message RewrapKeyBlobRequest {
    	bytes WrappedKey = 1;
    }
    message RewrapKeyBlobResponse {
    	bytes RewrappedKey = 1;
    }
    

    message GetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message GetAttributeValueResponse {
        map<uint64,AttributeValue> Attributes = 4;
    }
    

PKCS #11 C_GetAttributeValue의 구현입니다.

세션(blob의 파트)를 표시하거나 필요로 하지 않습니다. 그러므로 hSession 매개변수를 사용하지 않습니다.

EP11은 더 일반적인 방식 대신 실제 값을 열거하는 등 보다 직접적인 디코딩 방법을 사용합니다.

    CK_RV m_GetAttributeValue (
        const unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        target_t 대상
    );
    

C_GetAttributeValue는 하나 이상의 오브젝트 속성 값을 확보합니다. hSession은 세션의 핸들이고, hObject는 오브젝트 핸들이고, pTemplate는 확보할 속성 값을 지정하는 템플리트를 지시하고 속성 값을 수신하며, ulCount는 템플리트의 속성 수입니다.

템플리트에 있는 각각의 세 항목 즉, type, pValue, ulValueLen에서 C_GetAttributeValue가 다음 알고리즘을 수행합니다.

1. 오브젝트가 민감하거나 추출할 수 없는 이유로 오브젝트에 대해 지정된 속성(즉, 필드 유형에서 제공된 속성)이 표시될 수 없으면 해당하는 세 항목의 ulValueLen 필드는 CK_UNAVAILABLE_INFORMATION 값을 보유하도록 수정됩니다.
2. 오브젝트에 대해 지정된 값이 올바르지 않으면(오브젝트가 이러한 속성을 처리하지 않음) 해당하는 세 항목의 ulValueLen 필드가 CK_UNAVAILABLE_INFORMATION 값을 보유하도록 수정됩니다.
3. pValue 필드에 NULL_PTR 값이 있으면 ulValueLen 필드는 오브젝트에 대해 지정된 속성의 정확한 길이를 보유하도록 수정됩니다.
4. 반면 ulValueLen에 지정된 길이가 오브젝트에 대해 지정된 속성의 값을 보유할 수 있을 만큼 충분히 큰 경우 해당 속성이 pValue에 있는 버퍼로 복사되고 ulValueLen 필드는 해당 속성의 정확한 길이를 보유하도록 수정됩니다.
5. ulValueLen 필드는 CK_UNAVAILABLE_INFORMATION 값을 보유하도록 수정됩니다.

요청된 속성에 케이스 1이 적용되는 경우 해당 호출에서 CKR_ATTRIBUTE_SENSITIVE 값을 리턴해야 합니다. 요청된 속성에 케이스 2가 적용되는 경우 해당 호출에서 CKR_ATTRIBUTE_TYPE_INVALID 값을 리턴해야 합니다. 요청된 속성에 케이스 5가 적용되는 경우 해당 호출에서 CKR_BUFFER_TOO_SMALL 값을 리턴해야 합니다. 일반적으로, 이 오류 코드 중 두 개 이상이 적용되면 Cryptoki가 오류 코드를 리턴할 수 있습니다. 요청된 속성 중 어느 것도 적용되지 않을 경우에만 CKR_OK가 리턴됩니다.

해당 값이 속성의 배열인 특수한 속성에서는(예: 널이 아닌 pValue로 전달되는 CKA_WRAP_TEMPLATE) 배열 내 요소의 pValue가 NULL_PTR인 경우 배열 내 요소의 ulValueLen이 필요한 길이로 설정됩니다. 배열 내 요소의 pValue가 NULL_PTR이 아니면 배열 내 속성의 ulValueLen 요소가 해당 pValue가 가리키고 충분한 공간이 있는 경우 pValue가 입력된 공간을 반영해야 합니다. 따라서 이러한 배열 값을 가져오기 위해 C_GetAttributeValue 가 호출되기 전에 버퍼의 컨텐츠를 초기화하는 것이 중요합니다. 배열 내에 있는 ulValueLen이 충분히 크지 않을 경우 pTemplate 인수의 ulValueLen이 너무 작은 경우와 마찬가지로 CK_UNAVAILABLE_INFORMATION으로 설정되고 해당 함수에서 CKR_BUFFER_TOO_SMALL이 리턴됩니다. 값이 속성의 배열인 속성은 속성 유형의 CKF_ARRAY_ATTRIBUTE 세트를 통해 식별할 수 있습니다.

오류 코드 CKR_ATTRIBUTE_SENSITIVE, CKR_ATTRIBUTE_TYPE_INVALID및 CKR_BUFFER_TOO_SMALL 은 C_GetAttributeValue에 대한 실제 오류를 나타내지 않습니다. C_GetAttributeValue에 대한 호출에서 이러한 세 개의 값 중 하나가 리턴되는 경우에도 해당 호출에서 C_GetAttributeValue에 제공된 템플리트의 모든 속성을 처리해야 합니다. C_GetAttributeValue에 대한 호출에서 값이 리턴될 수 있는 템플리트의 각 속성은 C_GetAttributeValue에 대한 호출에서 리턴됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_GetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message SetAttributeValueRequest {
        bytes Object = 1;
        map<uint64,AttributeValue> Attributes = 3;
    }
    message SetAttributeValueResponse {
        bytes Object = 1;
    }
    

PKCS #11 C_SetAttributeValue의 구현입니다.

속성 팩킹은 _GetAttrValue를 참조하십시오.

헌재 Ep11은 부울 속성만 전송하며 기타 모든 속성은 호스트에서 처리합니다(또한 WRAP_TEMPLATE와 같은 배열 수정을 하지 않음).

세션(blob의 파트)를 표시하거나 필요로 하지 않습니다. 그러므로 PKCS #11 hSession 매개변수를 사용하지 않습니다.

    CK_RV m_SetAttributeValue (
        unsigned char *object, size_t objectlen,
        CK_ATTRIBUTE_PTR attributes, CK_ULONG attributeslen,
        target_t 대상
    );
    

C_SetAttributeValue는 하나 이상의 오브젝트 속성 값을 수정합니다. hSession은 세션의 핸들이고, hObject는 오브젝트 핸들이고, pTemplate는 수정할 속성 값 및 새 값을 지정하는 템플리트를 지시하며, ulCount는 템플리트의 속성 수입니다.

특정 오브젝트는 수정될 수 있습니다. 이러한 오브젝트에서 C_SetAttributeValue를 호출하는 경우 CKR_ACTION_PROHIBITED 오류 코드가 발생합니다. 애플리케이션은 오브젝트의 수정 여부를 결정하기 위해 오브젝트의 CKA_MODIFIABLE 속성을 참고할 수 있습니다.

읽기 전용 세션 중에는 세션 오브젝트만 수정될 수 있습니다.

템플리트는 수정될 수 있는 오브젝트의 속성에 대한 새 값을 지정할 수 있습니다. 템플리트에서 기존의 다른 오브젝트 속성과 호환되지 않는 속성 값을 지정하는 경우 리턴 코드 CKR_TEMPLATE_INCONSISTENT와 함께 호출이 실패합니다.

일부 속성은 수정할 수 없습니다. 자세한 정보는 PKCS #11 API 스펙의 4.1.2절을 참조하십시오.

    CK_DEFINE_FUNCTION(CK_RV, C_SetAttributeValue)(
        CK_SESSION_HANDLE hSession,
        CK_OBJECT_HANDLE hObject,
        CK_ATTRIBUTE_PTR pTemplate,
        CK_ULONG ulCount
    );
    

    message GenerateRandomRequest {
        uint64 Len = 1;
    }
    message GenerateRandomResponse {
        bytes Rnd = 1;
    }
    

PKCS #11 C_GenerateRandom의 구현입니다.

GenerateRandom은 원래 PKCS #11 함수와 동등합니다. 내부적으로, 하드웨어 시드된 엔트로피는 FIPS 호환 DRNG(ANSI X9.31/ISO 18031, Clic 버전에 따라 달라짐)을 통해 전달됩니다.

호스트 라이브러리는 적합한 기능이 호스트에서 사용 가능한 경우 백엔드에 디스패치하지 않고 난수를 생성할 수 있습니다. 이는 현재 구현에서 수행되지 않습니다.

이 함수는 크기 조회를 지원하지 않습니다.

    CK_RV m_GenerateRandom (
        CK_BYTE_PTR rnd, CK_ULONG rndlen,
        target_t 대상
    );
    

    CK_DEFINE_FUNCTION(CK_RV, C_GenerateRandom)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pRandomData,
        CK_ULONG ulRandomLen
    );
    

    message EncryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message EncryptInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_EncryptInit의 구현입니다.

(key, klen) blob는 공개 키 오브젝트 또는 비밀 키 blob일 수 있습니다. 키 유형은 pmech와 일치해야 합니다.

공개 키 메커니즘의 경우 (key, klen)에는 SPKI가 포함되어야 합니다. 이 SPKI는 GenerateKeyPair 또는 대신 UnwrapKey로 리턴된 대로 MAC 키로 무결성 보호됩니다. 암호화 상태는 세션 제한사항 없이 작성됩니다.

비밀 키 메커니즘의 경우 암호화 상태는 (key, klen)에서 오브젝트 세션 제한사항을 상속합니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

(key, klen)은 키 blob이어야 합니다.

    CK_RV m_EncryptInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        target_t 대상
    );
    

C_EncryptInit는 암호화 조작을 초기화합니다. hSession은 세션의 핸들이고, pMechanism은 암호화 메커니즘을 지시하며, hKey는 암호화 키의 핸들입니다.

키가 암호화를 지원하는지를 표시하는 암호화 키의 CKA_ENCRYPT 속성은 CK_TRUE여야 합니다.

애플리케이션이 C_EncryptInit를 호출한 후 애플리케이션은 C_Encrypt를 호출하여 단일 파트에서 데이터를 암호화하거나 C_DigestFinal 뒤에 표시되는 C_EncryptUpdate를 0번 이상 호출하여 다중 파트에서 데이터를 암호화할 수 있습니다. 암호화 오퍼레이션은 애플리케이션이 암호문의 마지막 부분을 가져오기 위해 C_Encrypt 또는 C_EncryptFinal에 대한 호출을 사용할 때까지 활성 상태입니다. 추가 데이터를 처리하려면(단일 또는 다중 파트에서) 애플리케이션에서 C_EncryptInit를 다시 호출해야 합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message EncryptRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptResponse {
        bytes Ciphered = 3;
    }
    

PKCS #11 C_Encrypt의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 EncryptInit의 출력입니다.

    CK_RV m_Encrypt (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t 대상
    );
    

C_Encrypt는 단일 파트 데이터를 암호화합니다. hSession은 세션의 핸들이고, pData는 데이터를 지시하고, ulDataLen은 데이터의 길이(바이트)이고, pEncryptedData는 암호화된 데이터를 수신하는 위치를 지시하며, pulEncryptedDataLen은 암호화된 데이터의 길이(바이트)를 보관하는 위치를 지시합니다.

C_Encrypt는 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

암호화 조작은 C_EncryptInit를 사용하여 초기화해야 합니다. C_Encrypt에 대한 호출은 CKR_BUFFER_TOO_SMALL이 리턴되거나 암호 텍스트를 보관하기 위해 필요한 버퍼의 길이를 판별하는 성공적인 호출(즉, CKR_OK이 리턴되는 호출)이 아닌 한 항상 활성 암호화 조작을 종료합니다.

C_Encrypt는 다중 파트 오퍼레이션을 종료하는 데 사용될 수 없으며 C_EncryptUpdate 호출 개입 없이 C_EncryptInit 후에 호출되어야 합니다.

일부 암호화 메커니즘의 경우 입력 일반 텍스트 데이터에는 특정 길이 제한조건이 있습니다 (메커니즘이 상대적으로 짧은 일반 텍스트 조각만 암호화할 수 있거나 메커니즘의 입력 데이터가 정수 블록 수로 구성되어야 하기 때문). 이러한 제한조건이 충족되지 않을 경우 리턴 코드 CKR_DATA_LEN_RANGE와 함께 C_Encrypt가 실패합니다.

일반 텍스트 및 암호문은 동일한 위치에 있을 수 있습니다. 즉, pData 및 pEncryptedData 가 동일한 위치를 가리키는 경우에도 가능합니다.

대부분의 메커니즘의 경우 C_Encrypt는 C_EncryptFinal 뒤에 표시되는 C_EncryptUpdate 오퍼레이션의 순서와 동등합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_Encrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG_PTR pulEncryptedDataLen
    );
    

    message EncryptUpdateRequest {
        bytes State = 1;
        bytes Plain = 2;
    }
    message EncryptUpdateResponse {
        bytes State = 1;
        bytes Ciphered = 3;
    }
    

PKCS #11 C_EncryptUpdate의 구현입니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 EncryptInit의 출력입니다.

    CK_RV m_EncryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t 대상
    );
    

C_EncryptUpdate는 다른 데이터 파트 처리 시 다중 파트 암호화 조작을 계속 진행합니다. hSession은 세션의 핸들이고, pPart는 데이터 파트를 지시하고, ulPartLen은 데이터 파트의 길이이고, pEncryptedPart는 암호화된 데이터 파트를 수신하는 위치를 지시하며, pulEncryptedPartLen은 암호화된 데이터 파트의 길이(바이트)를 보관하는 위치를 지시합니다.

C_EncryptUpdate는 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

암호화 조작은 C_EncryptInit를 사용하여 초기화해야 합니다. 이 함수는 연속해서 횟수 제한 없이 호출될 수 있습니다. CKR_BUFFER_TOO_SMALL 이외의 오류가 발생하는 C_EncryptUpdate에 대한 호출은 현재 암호화 오퍼레이션을 종료합니다.

plaintext 및 ciphertext는 동일한 위치에 있을 수 있습니다. 즉, pPart 및 pEncryptedPart가 동일한 위치를 가리키는 경우에도 문제가 없습니다.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG_PTR pulEncryptedPartLen
    );
    

    message EncryptFinalRequest {
        bytes State = 1;
    }
    message EncryptFinalResponse {
        bytes Ciphered = 2;
    }
    

PKCS #11 C_EncryptFinal의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 EncryptInit, EncryptUpdate의 출력입니다.

    CK_RV m_EncryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t 대상
    );
    

C_EncryptFinal는 다중 파트 암호화 조작을 완료합니다. hSession은 세션의 핸들이고, pLastEncryptedPart는 마지막으로 암호화된 데이터 파트(존재하는 경우)를 수신하는 위치를 지시하며, pulLastEncryptedPartLen은 마지막으로 암호화된 데이터 파트의 길이를 보관하는 위치를 지시합니다.

C_EncryptFinal은 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

암호화 조작은 C_EncryptInit를 사용하여 초기화해야 합니다. C_EncryptFinal에 대한 호출은 CKR_BUFFER_TOO_SMALL이 리턴되거나 암호문을 보유하는 데 필요한 버퍼의 길이를 판별하기 위한 성공적인 호출(즉, CKR_OK가 리턴됨)이 아닌 경우 항상 활성 암호화 오퍼레이션을 종료합니다.

일부 다중 파트 암호화 메커니즘의 경우 메커니즘의 입력 데이터가 정수 블록 수로 구성되어야 하므로 입력 일반 텍스트 데이터에는 특정 길이 제한조건이 있습니다. 이러한 제한조건이 충족되지 않을 경우 C_EncryptFinal은 리턴 코드 CKR_DATA_LEN_RANGE와 함께 실패합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_EncryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastEncryptedPart,
        CK_ULONG_PTR pulLastEncryptedPartLen
    );
    

    message EncryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Plain = 3;
    }
    message EncryptSingleResponse {
        bytes Ciphered = 4;
    }
    

Encrypt의 비표준 변형입니다. 한 번 호출하여 원패스(one pass)로 데이터를 처리합니다. 상태를 호스트에 리턴하지 않고 암호화된 데이터만 리턴합니다.

이는 XCP 인식 애플리케이션용 원패스(one pass)로 데이터를 암호화할 때 선호되는 방법입니다. 기능상 Encrypt 뒤에 바로 표시되는 EncryptInit와 동등하지만 라운드트립, 랩핑 및 랩핑 해제를 저장합니다.

백엔드가 상주 키를 지원하는 경우 키는 상주 키 핸들일 수 있습니다.

Encrypt, EncryptInit, DecryptSingle도 참조하십시오.

key blob는 GenerateKey, UnwrapKey의 출력입니다.

    CK_RV m_EncryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR plain, CK_ULONG plainlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t 대상
    );
    

    message ReencryptSingleRequest {
        bytes DecKey = 1;
        bytes EncKey = 2;
        Mechanism DecMech = 3;
        Mechanism EncMech = 4;
        bytes Ciphered = 5;
    }
    message ReencryptSingleResponse {
        bytes Reciphered = 6;
    }
    

Encrypt의 비표준 변형입니다. 한 번 호출하여 원패스(one pass)로 데이터를 처리합니다. 상태를 호스트에 리턴하지 않고 다시 암호화된 데이터만 리턴합니다.

원래 키를 사용하여 데이터를 복호화한 후 클라우드 HSM 내에서 다른 키를 사용하여 원시 데이터를 암호화합니다.

    CK_RV m_ReencryptSingle (
        const unsigned char * dkey, size_t dkeylen,
        const unsigned char * ekey, size_t ekeylen,
        CK_MECHANISM_PTR decmech,
        CK_MECHANISM_PTR encmech,
        CK_BYTE_PTR in, CK_ULONG inlen,
        CK_BYTE_PTR ciphered, CK_ULONG_PTR cipheredlen,
        target_t 대상
    );
    

    message DecryptInitRequest {
        Mechanism Mech = 2;
        bytes Key = 3;
    }
    message DecryptInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_DecryptInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *key, size_t keylen,
        target_t 대상
    );
    

C_DecryptInit는 복호화 조작을 초기화합니다. hSession은 세션의 핸들이고, pMechanism은 복호화 메커니즘을 지시하며, hKey는 복호화 키의 핸들입니다.

키가 복호화를 지원하는지를 표시하는 복호화 키의 CKA_DECRYPT 속성은 CK_TRUE여야 합니다.

애플리케이션에서 C_DecryptInit를 호출한 후에는 해당 애플리케이션에서 C_Decrypt를 호출하여 단일 파트의 데이터를 복호화하거나 C_DecryptUpdate를 0번 이상 호출한 후 C_DecryptFinal을 호출하여 다중 파트의 데이터를 복호화할 수 있습니다. 복호화 오퍼레이션은 애플리케이션이 일반 텍스트의 마지막 부분을 가져오기 위해 C_Decrypt 또는 C_DecryptFinal에 대한 호출을 사용할 때까지 활성 상태입니다. 추가 데이터를 처리하려면(단일 또는 다중 파트에서) 애플리케이션에서 C_DecryptInit를 다시 호출해야 합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptInit)(
        K_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message DecryptRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptResponse {
       bytes Plain = 3;
    }
    

PKCS #11 C_Decrypt의 구현입니다. (state, slen)은 업데이트하지 않습니다.

state, slen 2진 대형 오브젝트(BLOB)는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. state BLOB는 DecryptInit의 출력입니다.

    CK_RV m_Decrypt (const unsigned char *state, size_t slen,
        CK_BYTE_PTR cipher, CK_ULONG clen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plen,
        target_t 대상
    );
    

C_Decrypt는 단일 파트에서 암호화된 데이터를 복호화합니다.

• hSession은 세션 핸들입니다.
• pEncryptedData는 암호화된 데이터를 가리킵니다.
• ulEncryptedDataLen은 암호화된 데이터의 길이입니다.
• pData는 복구된 데이터를 수신하는 위치를 가리킵니다.
• pulDataLen은 복구된 데이터의 길이를 보유하는 위치를 가리킵니다.

C_Decrypt는 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

복호화 조작은 C_DecryptInit를 사용하여 초기화해야 합니다. C_Decrypt 에 대한 호출은 CKR_BUFFER_TOO_SMALL 을 리턴하거나 일반 텍스트를 보유하는 데 필요한 버퍼의 길이를 판별하기 위해 리턴된 CKR_OK 를 사용한 성공적인 호출이 아닌 경우 항상 활성 복호화 조작을 종료합니다.

C_Decrypt는 다중 파트 조작을 종료하기 위해 사용할 수 없으며 C_DecryptUpdate 호출이 개입되지 않은 상태로 C_DecryptInit 이후에 호출해야 합니다.

암호문 및 일반 텍스트는 동일한 위치에 있을 수 있습니다. 이는 pEncryptedData및 pData 가 동일한 위치를 가리키는 경우에 허용됨을 의미합니다.

입력 암호문 데이터가 올바르지 않은 길이로 인해 복호화될 수 없는 경우 CKR_ENCRYPTED_DATA_INVALID 또는 CKR_ENCRYPTED_DATA_LEN_RANGE가 리턴될 수 있습니다.

    CK_DEFINE_FUNCTION(CK_RV, C_Decrypt)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedData,
        CK_ULONG ulEncryptedDataLen,
        CK_BYTE_PTR pData,
        CK_ULONG_PTR pulDataLen
    );
    

    message DecryptUpdateRequest {
        bytes State = 1;
        bytes Ciphered = 2;
    }
    message DecryptUpdateResponse {
        bytes State = 1;
        bytes Plain = 3;
    }
    

PKCS #11 C_DecryptUpdate의 구현입니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 DecryptInit의 출력입니다.

    CK_RV m_DecryptUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t 대상
    );
    

C_DecryptUpdate는 다른 암호화된 데이터 파트 처리 시 다중 파트 복호화 조작을 계속 진행합니다. hSession은 세션의 핸들이고, pEncryptedPart는 암호화된 데이터 파트를 지시하고, ulEncryptedPartLen은 암호화된 데이터 파트의 길이이고, pPart는 복구된 데이터 파트를 수신하는 위치를 지시하며, pulPartLen은 복구된 데이터 파트의 길이를 보관하는 위치를 지시합니다.

C_DecryptUpdate는 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

복호화 조작은 C_DecryptInit를 사용하여 초기화해야 합니다. 이 함수는 연속해서 횟수 제한 없이 호출될 수 있습니다. CKR_BUFFER_TOO_SMALL 이외의 오류가 발생하는 C_DecryptUpdate에 대한 호출은 현재 복호화 오퍼레이션을 종료합니다.

암호문 및 일반 텍스트는 동일한 위치에 있을 수 있습니다. 즉, pEncryptedPart 및 pPart 가 동일한 위치를 가리키는 경우에도 가능합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pEncryptedPart,
        CK_ULONG ulEncryptedPartLen,
        CK_BYTE_PTR pPart,
        CK_ULONG_PTR pulPartLen
    );
    

    message DecryptFinalRequest {
        bytes State = 1;
    }
    message DecryptFinalResponse {
        bytes Plain = 2;
    }
    

PKCS #11 C_DecryptFinal의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 DecryptInit, DecryptUpdate의 출력입니다.

    CK_RV m_DecryptFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t 대상
    );
    

C_DecryptFinal은 다중 파트 복호화 조작을 완료합니다. hSession은 세션의 핸들이고, pLastPart는 마지막으로 복구된 데이터 파트(존재하는 경우)를 수신하는 위치를 지시하며, pulLastPartLen은 마지막으로 복구된 데이터 파트의 길이를 보관하는 위치를 지시합니다.

C_DecryptFinal은 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

복호화 조작은 C_DecryptInit를 사용하여 초기화해야 합니다. C_DecryptFinal 에 대한 호출은 일반 텍스트를 보유하는 데 필요한 버퍼의 길이를 판별하기 위해 작은 버퍼 를 리턴하거나 성공적인 호출 (즉, CKR_OK를 리턴합니다.) 이 아닌 경우 항상 활성 복호화 조작을 종료합니다.

입력 암호문 데이터가 올바르지 않은 길이로 인해 복호화될 수 없는 경우 CKR_ENCRYPTED_DATA_INVALID 또는 CKR_ENCRYPTED_DATA_LEN_RANGE가 리턴될 수 있습니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DecryptFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pLastPart,
        CK_ULONG_PTR pulLastPartLen
    );
    

    message DecryptSingleRequest {
        bytes Key = 1;
        Mechanism Mech = 2;
        bytes Ciphered = 3;
    }
    message DecryptSingleResponse {
        bytes Plain = 4;
    }
    

Decrypt의 비표준 변형입니다. 한 번 호출하여 원패스(one pass)로 데이터를 처리합니다. 상태를 호스트에 리턴하지 않고 복호화된 데이터만 리턴합니다.

이는 XCP 인식 애플리케이션용 원패스(one pass)로 데이터를 암호화할 때 선호되는 방법입니다. 기능상 Decrypt 뒤에 바로 표시되는 DecryptInit와 동등하지만 라운드트립, 랩핑 및 랩핑 해제를 저장합니다.

백엔드가 상주 키를 지원하는 경우 키는 상주 키 핸들일 수 있습니다.

Decrypt, DecryptInit, EncryptSingle도 참조하십시오.

key blob는 GenerateKey, UnwrapKey의 출력입니다.

    CK_RV m_DecryptSingle (
        const unsigned char *key, size_t keylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR ciphered, CK_ULONG cipheredlen,
        CK_BYTE_PTR plain, CK_ULONG_PTR plainlen,
        target_t 대상
    );
    

    message SignInitRequest {
        Mechanism Mech = 2;
        bytes PrivKey = 3;
    }
    message SignInitResponse {
        bytes State = 1;
    }
    

    CK_RV m_SignInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *privKey, size_t privKeylen,
        target_t 대상
    );
    

C_SignInit는 서명 조작을 초기화합니다. 여기서 서명은 데이터에 대한 부록입니다. hSession은 세션의 핸들이고, pMechanism은 서명 메커니즘을 지시하며, hKey는 서명 키의 핸들입니다.

키가 서명(부록 포함)을 지원하는지를 표시하는 서명 키의 CKA_SIGN 속성은 CK_TRUE여야 합니다.

애플리케이션이 C_SignInit를 호출한 후 애플리케이션은 C_Sign를 호출하여 단일 파트에서 서명하거나 C_SignFinal 뒤에 표시되는 C_SignUpdate를 한 번 이상 호출하여 다중 파트에서 데이터를 서명할 수 있습니다. 서명 오퍼레이션은 애플리케이션이 서명을 가져오기 위해 C_Sign 또는 C_SignFinal에 대한 호출을 사용할 때까지 활성 상태입니다. 추가 데이터를 처리하려면(단일 또는 다중 파트에서) 애플리케이션에서 C_SignInit를 다시 호출해야 합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_SignInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message SignRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignResponse {
        bytes Signature = 3;
    }
    

PKCS #11 C_Sign의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 SignInit의 출력입니다.

    CK_RV m_Sign (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t 대상
    );
    

C_Sign은 서명이 데이터에 대한 부록인 단일 파트의 데이터에 서명합니다. hSession은 세션의 핸들이고, pData는 데이터를 지시하고, ulDataLen은 데이터의 길이이고, pSignature는 서명을 수신하는 위치를 지시하며, pulSignatureLen은 서명의 길이를 보관하는 위치를 지시합니다.

C_Sign은 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

서명 조작은 C_SignInit를 사용하여 초기화해야 합니다. C_Sign에 대한 호출의 경우 CKR_BUFFER_TOO_SMALL이 리턴되거나 서명을 보유하는 데 필요한 버퍼의 길이를 판별하기 위한 성공적인 호출(즉, CKR_OK가 리턴됨)이 아닌 경우 항상 활성 서명 조작을 종료합니다.

C_Sign은 다중 파트 오퍼레이션을 종료하는 데 사용될 수 없으며 C_SignUpdate 호출 개입 없이 C_SignInit 후에 호출되어야 합니다.

대부분의 메커니즘의 경우 C_Sign은 C_SignFinal 뒤에 표시되는 C_SignUpdate 오퍼레이션의 순서와 동등합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_Sign)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message SignUpdateResponse {
        bytes State = 1;
    }
    

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 SignInit의 출력입니다.

    CK_RV m_SignUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t 대상
    );
    

C_SignUpdate는 다른 데이터 파트 처리 시 다중 파트 서명 조작을 계속 진행합니다. hSession은 세션의 핸들이고, pPart는 데이터 파트를 지시하며, ulPartLen은 데이터 파트의 길이입니다.

서명 조작은 C_SignInit를 사용하여 초기화해야 합니다. 이 함수는 연속해서 횟수 제한 없이 호출될 수 있습니다. 오류가 발생하는 C_SignUpdate에 대한 호출은 현재 서명 오퍼레이션을 종료합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_SignUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message SignFinalRequest {
        bytes State = 1;
    }
    message SignFinalResponse {
        bytes Signature = 2;
    }
    

PKCS #11 C_SignFinal의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 SignInit, SignUpdate의 출력입니다.

    CK_RV m_SignFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t 대상
    );
    

C_SignFinal은 서명 리턴 시 다중 파트 서명 조작을 완료합니다. hSession은 세션의 핸들이고, pSignature는 서명을 수신하는 위치를 지시하며, pulSignatureLen은 서명의 길이를 보관하는 위치를 지시합니다.

C_SignFinal은 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

서명 조작은 C_SignInit를 사용하여 초기화해야 합니다. C_SignFinal에 대한 호출은 CKR_BUFFER_TOO_SMALL이 리턴되거나 서명을 보유하는 데 필요한 버퍼의 길이를 판별하기 위한 성공적인 호출(즉, CKR_OK가 리턴됨)이 아닌 경우 항상 활성 서명 조작을 종료합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_SignFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG_PTR pulSignatureLen
    );
    

    message SignSingleRequest {
        bytes PrivKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
    }
    message SignSingleResponse {
        bytes Signature = 4;
    }
    

비표준 확장이며 SignInit 및 Sign의 조합으로 되어 있습니다. 한 번 호출하여 중간 요약 상태를 구성하지 않고 원패스(one pass)로 데이터를 서명하거나 MAC화합니다. 상태를 호스트에 리턴하지 않고 결과만 리턴합니다.

이 방법은 추가 라운드트립, 암호화 및 복호화 없이 선호되는 서명 방법입니다. 기능상 SignSingle은 Sign 뒤에 바로 표시되는 SignInit와 동등합니다.

(key, klen) blob 및 pmech 메커니즘은 함께 SignInit에 전달할 수 있어야 합니다.

HMAC 및 CMAC 서명에 대한 다중 데이터 요청이 지원됩니다(하위 변형 2 및 3).

SignInit, Sign, VerifySingle도 참조하십시오.

    CK_RV m_SignSingle (
        const unsigned char *privKey, size_t privKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG_PTR signaturelen,
        target_t 대상
    );
    

    message VerifyInitRequest {
        Mechanism Mech = 2;
        bytes PubKey = 3;
    }
    message VerifyInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_VerifyInit의 구현입니다. 키 blob (key, klen)가 제공되면 (state, slen)에서 확인 세션 상태를 초기화하십시오. 키 blob는 공개 키 오브젝트 또는 HMAC 키 바이트일 수 있습니다. 키 blob 유형은 pmech와 일치해야 합니다.

공개 키 메커니즘의 경우 (key, klen)에는 SPKI가 포함되어야 합니다. 이 SPKI CKA_UNWRAP은 MAC화되거나(예를 들어, GenerateKeyPair에서 이전에 리턴됨) SPKI 자체일수 있습니다(인증서와 같은 외부 소스에서 가져온 경우).

HMAC 오퍼레이션이 초기화되는 경우 Verify 오브젝트의 세션 제한사항이 HMAC 키에서 상속됩니다. SPKI가 세션에 결합되어 있지 않으므로 공개 키 확인 상태는 세션 없음입니다.

key,klen blob는 PKCS #11 hKey 매개변수에서 맵핑되어야 합니다.

참고: SignInit 및 VerifyInit 는 내부적으로 HMAC및 기타 symmetric/MAC 메커니즘에 대해 동일합니다.

    CK_RV m_VerifyInit (
        unsigned char * state, size_t * statelen,
        CK_MECHANISM_PTR mech,
        const unsigned char *pubKey, size_t pubKeylen,
        target_t 대상
    );
    

C_VerifyInit는 검증 조작을 초기화합니다. 여기서 서명은 데이터에 대한 부록입니다. hSession은 세션의 핸들이고, pMechanism은 검증 메커니즘을 지정하는 구조를 지시하며, hKey는 검증 키의 핸들입니다.

키가 확인을 지원하는지를 표시하는(여기서, 서명은 데이터에 대한 부록임) 확인 키의 CKA_VERIFY 속성은 CK_TRUE여야 합니다.

애플리케이션이 C_VerifyInit를 호출한 후 애플리케이션은 C_Verify를 호출하여 단일 파트에서 데이터의 서명을 확인하거나 C_SignFinal 뒤에 표시되는 C_VerifyUpdate를 한 번 이상 호출하여 다중 파트에서 데이터의 서명을 확인할 수 있습니다. 확인 오퍼레이션은 애플리케이션이 C_Verify 또는 C_VerifyFinal을 호출할 때까지 활성입니다. 추가 데이터를 처리하려면(단일 또는 다중 파트에서) 애플리케이션에서 C_VerifyInit를 다시 호출해야 합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism,
        CK_OBJECT_HANDLE hKey
    );
    

    message VerifyRequest {
        bytes State = 1;
        bytes Data = 2;
        bytes Signature = 3;
    }
    message VerifyResponse {
    }
    

PKCS #11 C_Verify의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

데이터 및 서명의 상대적 순서가 상대적으로 반대입니다. VerifySingle로 변경하십시오.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 VerifyInit의 출력입니다.

    CK_RV m_Verify (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t 대상
    );
    

C_Verify는 단일 파트 조작에서 서명을 검증합니다. 여기서 서명은 데이터에 대한 부록입니다. hSession은 세션의 핸들이고, pData는 데이터를 지시하고, ulDataLen은 데이터의 길이이고, pSignature는 서명을 지시하며, ulSignatureLen은 서명의 길이입니다.

검증 조작은 C_VerifyInit를 사용하여 초기화해야 합니다. C_Verify에 대한 호출은 항상 활성 확인 오퍼레이션을 종료합니다.

C_Verify에 대한 성공적인 호출의 경우 CKR_OK 값(제공된 서명이 유효함을 나타냄) 또는 CKR_SIGNATURE_INVALID(제공된 서명이 유효하지 않음을 나타냄)를 리턴해야 합니다. 서명에서 순전히 해당 길이가 유효하지 않을 경우 CKR_SIGNATURE_LEN_RANGE가 리턴되어야 합니다. 해당 경우 활성 서명 오퍼레이션이 종료됩니다.

C_Verify는 다중 파트 오퍼레이션을 종료하는 데 사용될 수 없으며 C_VerifyUpdate 호출 개입 없이 C_VerifyInit 후에 호출되어야 합니다.

대부분의 메커니즘의 경우 C_Verify는 C_VerifyFinal 뒤에 표시되는 C_VerifyUpdate 오퍼레이션의 순서와 동등합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_Verify)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifyUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message VerifyUpdateResponse {
        bytes State = 1;
    }
    

PKCS #11 C_VerifyUpdate의 구현입니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 VerifyInit의 출력입니다.

    CK_RV m_VerifyUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t 대상
    );
    

C_VerifyUpdate는 다른 데이터 파트 처리 시 다중 파트 검증 조작을 계속 진행합니다. hSession은 세션의 핸들이고, pPart는 데이터 파트를 지시하며, ulPartLen은 데이터 파트의 길이입니다.

검증 조작은 C_VerifyInit를 사용하여 초기화해야 합니다. 이 함수는 연속해서 횟수 제한 없이 호출될 수 있습니다. C_VerifyUpdate에 대한 호출에서 오류가 발생하는 경우 현재 검증 조작이 종료됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message VerifyFinalRequest {
        bytes State = 1;
        bytes Signature = 2;
    }
    message VerifyFinalResponse {
    }
    

PKCS #11 C_VerifyFinal의 구현입니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 VerifyInit, VerifyUpdate의 출력입니다.

    CK_RV m_VerifyFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t 대상
    );
    

C_VerifyFinal은 서명 확인 시 다중 파트 검증 조작을 완료합니다. hSession은 세션의 핸들이고, pSignature는 서명을 지시하며, ulSignatureLen은 서명의 길이입니다.

검증 조작은 C_VerifyInit를 사용하여 초기화해야 합니다. C_VerifyFinal에 대한 호출은 항상 활성 확인 오퍼레이션을 종료합니다.

C_VerifyFinal에 대한 성공적인 호출의 경우 CKR_OK 값(제공된 서명이 유효함을 나타냄) 또는 CKR_SIGNATURE_INVALID(제공된 서명이 유효하지 않음을 나타냄)를 리턴해야 합니다. 서명에서 해당 길이가 유효하지 않은 경우 CKR_SIGNATURE_LEN_RANGE를 리턴해야 합니다. 해당 경우 활성 확인 오퍼레이션이 종료됩니다.

    CK_DEFINE_FUNCTION(CK_RV, C_VerifyFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pSignature,
        CK_ULONG ulSignatureLen
    );
    

    message VerifySingleRequest {
        bytes PubKey = 1;
        Mechanism Mech = 2;
        bytes Data = 3;
        bytes Signature = 4;
    }
    message VerifySingleResponse {
    }
    

비표준 확장이며 VerifyInit 및 Verify의 조합으로 되어 있습니다. 한 번 호출하여 중간 요약 상태를 구성하지 않고 원패스(one pass)로 데이터를 서명하거나 MAC화합니다. 상태를 호스트에 리턴하지 않고 확인 결과만 리턴합니다. 이 함수가 부울을 리턴하지 않으므로 크기 조회를 사용할 수 없습니다.

이 방법은 추가적인 라운드트립, 암호화, 복호화 없이 서명을 검증하는 선호 방식입니다. 기능상 VerifySingle은 Verify 뒤에 바로 표시되는 VerifyInit와 동등합니다.

(key, klen) blob 및 pmech 메커니즘은 함께 VerifyInit에 전달할 수 있어야 합니다.

공개 키 메커니즘의 경우 (key, klen)에는 SPKI가 포함되어야 합니다. 이 SPKI는 MAC화할 수 있거나(예를 들어, GenerateKeyPair에서 공개 키로 리턴됨) SPKI 자체일 수 있습니다(인증서와 같은 외부 소스에서 가져온 경우).

VerifyInit, Verify, SignSingle도 참조하십시오.

    CK_RV m_VerifySingle (
        const unsigned char *pubKey, size_t pubKeylen,
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR signature, CK_ULONG signaturelen,
        target_t 대상
    );
    

    message DigestInitRequest {
        Mechanism Mech = 2;
    }
    message DigestInitResponse {
        bytes State = 1;
    }
    

PKCS #11 C_DigestInit의 구현입니다.

랩핑된 요약 상태를 작성합니다.

참고: 크기 조회가 지원되지만 랩핑된 상태는 대부분의 크기 조회와는 달리 항상 백엔드로 리턴됩니다(실제 출력 대신 출력 크기를 리턴함). Digest 상태는 눈에 띄는 전송 오버헤드를 발생시키지 않을 정도로 충분히 소형 상태입니다.

크기 조회 중에 호스트는 리턴된 상태만 삭제하고 blob 크기(len)를 보고합니다. blob을 리턴할 때 len은 리턴된 크기에 대해 확인합니다.

state,len blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 blob를 세션에 결합시켜야 합니다.)

    CK_RV m_DigestInit (
        unsigned char * state, size_t * len,
        const CK_MECHANISM_PTR mech,
        target_t 대상
    );
    

C_DigestInit는 메시지 요약 조작을 초기화합니다. hSession은 세션의 핸들이며, pMechanism은 수집 메커니즘을 지시합니다.

애플리케이션이 C_DigestInit를 호출한 후 애플리케이션은 C_Digest를 호출하여 단일 파트에서 데이터를 요약하거나 C_DigestFinal 뒤에 표시되는 C_DigestUpdate를 0번 이상 호출하여 다중 파트에서 데이터를 요약할 수 있습니다. 메시지 요약 조작은 애플리케이션에서 C_Digest 또는 C_DigestFinal에 대한 호출을 사용하여 메시지 요약을 확보할 때까지 활성 상태가 됩니다. 추가 데이터를 처리하려면(단일 또는 다중 파트에서) 애플리케이션에서 1C_DigestInit1을 다시 호출해야 합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestInit)(
        CK_SESSION_HANDLE hSession,
        CK_MECHANISM_PTR pMechanism
    );
    

    message DigestRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestResponse {
        bytes Digest = 3;
    }
    

PKCS #11 C_Digest의 구현입니다.

요약 오브젝트에 0바이트 전송에 대한 임의의 조합으로 작성된 후에 추가된 정확히 0(영) 바이트가 존재하는 경우 엄격한 구현에서는 거부해야 하는 경우에도 여전히 원패스 요약을 수행할 수 있습니다.

(state, slen)을 업데이트하지 않습니다.

구현이 수행할 수 있는 DigestUpdate, DigestFinal또는 Digest 는 호스트 코드에서 일반 텍스트 요약 오브젝트를 호출하며 HSM 백엔드를 모두 무시합니다. 이 선택사항은 호스트 코드에 표시되거나 표시되지 않을 수 있으며, 오퍼레이션의 보안에 영향을 주지 않을 수 있습니다(일반 오브젝트는 민감한 데이터를 요약할 수 없으므로).

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. state blob는 DigestInit의 출력입니다.

    CK_RV m_Digest (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t 대상
    );
    

C_Digest는 단일 파트의 데이터를 요약합니다. hSession은 세션의 핸들이고, pData는 데이터를 지시하고, ulDataLen은 데이터의 길이이고, pDigest는 메시지 요약을 수신하는 위치를 지시하며, pulDigestLen은 메시지 요약의 길이를 보관하는 위치를 지시합니다.

C_Digest는 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

요약 조작은 C_DigestInit를 사용하여 초기화해야 합니다. C_Digest에 대한 호출은 CKR_BUFFER_TOO_SMALL이 리턴되거나 메시지 요약을 보유하는 데 필요한 버퍼의 길이를 판별하기 위한 성공적인 호출(즉, CKR_OK가 리턴됨)이 아닌 경우 활성 요약 조작을 종료합니다.

C_Digest는 다중 파트 오퍼레이션을 종료하는 데 사용될 수 없으며 C_DigestUpdate 호출 개입 없이 C_DigestInit 후에 호출되어야 합니다.

입력 데이터 및 요약 출력은 동일한 위치에 있을 수 있습니다. 즉, pData 및 pDigest가 동일한 위치를 가리키는 경우에도 문제가 없습니다.

C_Digest는 C_DigestFinal 뒤에 표시되는 C_DigestUpdate 오퍼레이션의 순서와 동등합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_Digest)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pData,
        CK_ULONG ulDataLen,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestUpdateRequest {
        bytes State = 1;
        bytes Data = 2;
    }
    message DigestUpdateResponse {
        bytes State = 1;
    }
    

PKCS #11 C_DigestUpdate의 구현입니다.

DigestUpdate 는 다형성입니다. 동일한 형식으로 상태를 업데이트하여 랩핑되거나 정리된 요약 오브젝트를 둘 다 허용합니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다. (호스트 라이브러리는 세션을 저장된 상태로 맵핑해야 합니다.)

state blob는 DigestInit, DigestUpdate, DigestKey의 출력입니다.

DigestInit도 참조하십시오.

    CK_RV m_DigestUpdate (
        unsigned char *state, size_t statelen,
        CK_BYTE_PTR data, CK_ULONG datalen,
        target_t 대상
    );
    

C_DigestUpdate는 다른 데이터 파트 처리 시 다중 파트 메시지 요약 조작을 계속 진행합니다. hSession은 세션의 핸들이고, pPart는 데이터 파트를 지시하며, ulPartLen은 데이터 파트의 길이입니다.

메시지 요약 조작은 C_DigestInit를 사용하여 초기화해야 합니다. 이 함수 및 C_DigestKey에 대한 호출은 순서 또는 횟수에 관계 없이 배치될 수 있습니다. 오류가 발생하는 C_DigestUpdate에 대한 호출은 현재 요약 오퍼레이션을 종료합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestUpdate)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pPart,
        CK_ULONG ulPartLen
    );
    

    message DigestFinalRequest {
        bytes State = 1;
    }
    message DigestFinalResponse {
        bytes Digest = 2;
    }
    

PKCS #11 C_DigestFinal의 구현입니다.

DigestFinal은 다형적이므로, 랩핑되거나 일반 요약 오브젝트를 모두 허용합니다.

(state, slen)을 업데이트하지 않습니다.

state,slen blob는 PKCS #11 hSession 매개변수에서 맵핑되어야 합니다.

state blob는 DigestInit, DigestUpdate, DigestKey의 출력입니다.

    CK_RV m_DigestFinal (
        const unsigned char *state, size_t statelen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t 대상
    );
    

C_DigestFinal은 메시지 요약 리턴 시 다중 파트 메시지 요약 조작을 완료합니다. hSession은 세션의 핸들이고, pDigest는 메시지 요약을 수신하는 위치를 지시하며, pulDigestLen은 메시지 요약의 길이를 보관하는 위치를 지시합니다.

C_DigestFinal은 출력 생성 시 PKCS #11 API 스펙의 5.2절에 설명된 규칙을 사용합니다.

요약 조작은 C_DigestInit를 사용하여 초기화해야 합니다. C_DigestFinal에 대한 호출은 CKR_BUFFER_TOO_SMALL을 리턴하거나 메시지 요약을 보유하기 위해 필요한 버퍼 길이를 결정하기 위한 성공적인 호출(즉, CKR_OK를 리턴하는 호출)이 아닌 경우 항상 활성 요약 조작을 종료합니다.

    CK_DEFINE_FUNCTION(CK_RV, C_DigestFinal)(
        CK_SESSION_HANDLE hSession,
        CK_BYTE_PTR pDigest,
        CK_ULONG_PTR pulDigestLen
    );
    

    message DigestSingleRequest {
        Mechanism Mech = 1;
        bytes Data = 2;
    }
    message DigestSingleResponse {
        bytes Digest = 3;
    }
    

비표준 확장이며 DigestInit 및 Digest의 조합으로 되어 있습니다. 한 번 호출하여 중간 요약 상태와 불필요한 라운드트립을 구성하지 않고 원패스(one pass)로 데이터를 요약합니다.

이는 XCP 인식 애플리케이션용 일반 텍스트를 요약할 때 선호되는 방법입니다. 기능상 DigestSingle은 Digest 뒤에 바로 표시되는 DigestInit와 동등합니다 .

키가 요약되어야 하는 경우 DigestInit 및 DigestKey를 사용해야 합니다. 이 함수는 기본 blob를 처리하지 않기 때문입니다.

상태를 호스트에 리턴하지 않고 요약 결과만 리턴합니다. 모든 것이 PKCS #11 호출에서 직접 사용되지 않으므로 PKCS #11 이외의 매개변수는 없습니다.

    CK_RV m_DigestSingle (
        CK_MECHANISM_PTR mech,
        CK_BYTE_PTR data, CK_ULONG datalen,
        CK_BYTE_PTR digest, CK_ULONG_PTR digestlen,
        target_t 대상
    );